login
Search
This message contains a list of some regressions from 2.6.25, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.If you know of any other unresolved regressions from 2.6.25, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2008-06-07 125 48 33
2008-05-31 115 52 31
2008-05-24 94 47 28
2008-05-18 80 51 37
2008-05-11 53 46 34Unresolved regressions
----------------------Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10873
Subject : serial/bfin_5xx.c build error
Submitter : Adrian Bunk <bunk@kernel.org>
Date : 2008-06-06 09:24 (2 days old)
References : http://lkml.org/lkml/2008/6/6/277
Handled-By : Adrian Bunk <bunk@kernel.org>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
Subject : x86_64 boot hang when CONFIG_NUMA=n
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2008-06-05 21:50 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
Handled-By : Yinghai Lu <yhlu.kernel@gmail.com>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10868
Subject : Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter : Adam Williamson <awilliamson@mandriva.com>
Date : 2008-06-05 17:39 (3 days old)Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter : Lior Dotan <liodot@gmail.com>
Date : 2008-06-05 15:04 (3 days old)
Referen...
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9791
Subject : Clock is running too fast^Wslow using acpi_pm clocksource
Submitter : tosn00j02@sneakemail.com
Date : 2008-05-03 05:09 (36 days old)--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10861
Subject : 2.6.26-rc4-git2 - long pause during boot
Submitter : Chris Clayton <chris2553@googlemail.com>
Date : 2008-06-01 4:15 (7 days old)
References : http://marc.info/?l=linux-kernel&m=121229382917834&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10865
Subject : i get the following oops trying to mount an ntfs partition on thinkpad
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Date : 2008-06-05 14:47 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121267834421414&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter : Lior Dotan <liodot@gmail.com>
Date : 2008-06-05 15:04 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4--
Where are we regarding this entry in the 2.6.26-rc regression list?
I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix
and not a 2.6.26-rc regression.Does anyone disagree with this?
I'm not sure whether this was Lior's problem or another issue I'm seeing
on my computer (static /dev, no udev):/dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this
a functional regression of the new drivers.Could this be fixed?
cu
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
I don't know if it helps you to decide but the way I got to this
configuration is by copying my working 2.6.25 .config file and running
make oldconfig. I think this scenario is common when upgrading to a
newer version so you should make sure it doesn't generate an invalid
configuration.Lior.
--
cu
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
Here it is:
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not setDo note that my 2.6.25 kernel was from Gentoo but none of the patches
there seem related to RTC.Lior.
--
That means the support for the PC RTC is disabled.
Honestly, I do not think we can handle all possible misconfigurations
cu
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
Cheers,
Lior.
--
Cheers,
Lior
--
It doesn't! "No /dev/rtc" is a perfectly valid config. And it's
not uncommon that new kernels require config tweaks.To repeat what's in the bug database: your old config didn't use
one of the valid RTC configs: legacy *OR* new style (else neither).Mixing the two was never supported ... it caused various bugs, and
much confusion. You might not have observed with your old .config
on your hardware (or might have ignored it), but other folk did.I'm not sure anyone would have wanted to merge any patches that
would have let the two frameworks coexist/overlap, but that's a
moot point since nobody (including you) submitted such patches.
What was submitted was a patch that rejected an invalid config.- Dave
--
The bug scenario is rather simple: /dev/rtc existed with that config in
prior kernels and now, after "make oldconfig" it does not exist, it's athat's wrong - 'make oldconfig' must work smoothly and in an expected
way.If you argue that the new kernel should come up with a non-existent
/dev/rtc, then you are wrong and you go against established regression
handling policies of the kernel. Smooth migration via "make oldconfig"
is a must, otherwise we'd lose testers and users.The old /dev/rtc might indeed have been unbelievably "bad" in various
ways and you dont even want to think about that code now, but it's your
code now that is used so you might as well think about the other 98% of
users who used the old /dev/rtc with old kernels. (not because they
wanted to use bad code, but because simply that was the default)Ingo
--
Yes, but "smooth" doesn't mean there's never a need to cope
with kernel updates by running "xconfig" (or whatever).In my own experience, several times a year I need to go back
and patch up a mess that "oldconfig" made. Things drop out,
things get added ... it's the things that get *added* withoutThey can continue working just fine with *only* the legacy RTC.
If they stuck with defaults, no problems appear. (Modulo the
fact that bitrot is setting in.)The only thing that causes the least hiccup is someone who was
for a while using a bogus (and non-default) configuration.Given a bogus configuration, how should it be fixed? There
can be several solutions, and the right answer for one system
will always be the right one for another. So any approach
that doesn't expect a human to select options sometimes will
be inherently wrong in various cases.- Dave
--
you are arguing against the facts - just look at the report - /dev/rtc
broke and that shouldnt have happened and should be fixed. No amount ofi have hit 1400 kernel bugs in the past 6 months alone on my
testsystems. That does not mean kernel bugs are the norm and it does notuhm, there's no such thing as a "bogus configuration". The Kconfig rules
for RTC (authored by you too) allowed it. If it "makes no sense" it's
because you coded it so - deal with it, it's not hard. But instead of
solving it (it is trivial) you are trying to push the blame to the userthis is not rocket science. The solution is to turn on the fine RTC
code, if the old config option is enabled too. I.e. be more careful
about compatibility. It's still possible to solve this problem and allow
the RTC code to be compiled out completely.and note that you are hurting users who tried out _your_ RTC code (which
was default off in the past) previously. Yes, while experimenting with
your code they might have created the "wrong" mix of config options but
that's not a problem - this isnt some esoteric embedded platform where
only real men are allowed to configure the kernel and who are left out
in the cold if they mess up - this is Linux where we encourage (and beg)
actual user to test our kernels. So please show some basic respect
towards them and dont arbitrarily declare configs "broken" that were
working in the past.Ingo
--
On Fri, 13 Jun 2008 15:38:54 -0700
I agree with david. oldconfig cannot be made to fix every possible
manual misconfiguration that has been introduced by the user, even
those that, by chance, just worked.The actual Kconfig will handle pretty well the transition from
a good config. where good is different from working-by-chance.There are far too many people that just keep pressing Y
when a new kernel option appears without even considering what would
happen or reading the help.--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy--
If Lior's problem was due to something like CONFIG_RTC_CLASS=y,
CONFIG_RTC_DRV_CMOS=n that's a kernel configuration that would
anyway break when the old driver gets removed, and it just broke
earlier.Everyone seems to focus on this kconfig related case, what about my
point of no /dev/rtc with a static /dev ? When talking about existingcu
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
On Sat, 14 Jun 2008 14:18:06 +0300
I haven't seen the .config, but CONFIG_RTC_CLASS=y
and CONFIG_RTC_DRV_CMOS=n is perfectly legal.It just don't have to be put in the default x86 config maybe,
the device node creation is yet another option of the
rtc class. it should be on by default in any defconfig, I'd guess.But then you'll get /dev/rtc0 without any specific device node.
As I said in the past, I'd accept a patch to handle this special
case of having /dev/rtc with a specific major and minor, but I'm against
it.It would be better to upgrade your userspace when such big changes
happens in the kernel. In fact, it the first time that the rtc
has been touched in the last.. 10 year? I think it's not unreasonable to
ask to upgrade userspace.wrto embedded systems, having worked with them for years, you are expected
to check every detail of every new kernel you want to use before releasing
it or, say, uploading it to your lander on the moon :)--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
Subject : x86_64 boot hang when CONFIG_NUMA=n
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2008-06-05 21:50 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
Handled-By : Yinghai Lu <yhlu.kernel@gmail.com>--
I'll try to test x86/tip today.
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10868
Subject : Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter : Adam Williamson <awilliamson@mandriva.com>
Date : 2008-06-05 17:39 (3 days old)--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10874
Subject : blackfin drivers/net/smc91x.c build error
Submitter : Adrian Bunk <bunk@kernel.org>
Date : 2008-06-06 09:25 (2 days old)
References : http://lkml.org/lkml/2008/6/6/278
Handled-By : Adrian Bunk <bunk@kernel.org>
Patch : revert commit 099c736a470c8080a166e7a089f1e48e15f9947c--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10873
Subject : serial/bfin_5xx.c build error
Submitter : Adrian Bunk <bunk@kernel.org>
Date : 2008-06-06 09:24 (2 days old)
References : http://lkml.org/lkml/2008/6/6/277
Handled-By : Adrian Bunk <bunk@kernel.org>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10864
Subject : [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
Submitter : Németh Márton <nm127@freemail.hu>
Date : 2008-06-03 5:18 (5 days old)
References : http://marc.info/?l=linux-kernel&m=121247101601790&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10863
Subject : kvm causing memory corruption? now 2.6.26-rc4
Submitter : Dave Hansen <dave@linux.vnet.ibm.com>
Date : 2008-06-02 22:30 (6 days old)
References : http://marc.info/?l=linux-kernel&m=121244588705277&w=4
Handled-By : Avi Kivity <avi@qumranet.com>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10862
Subject : forcedeth: lockdep warning on ethtool -s
Submitter : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Date : 2008-06-01 8:37 (7 days old)
References : http://marc.info/?l=linux-kernel&m=121230964032247&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10860
Subject : total system freeze at boot with 2.6.26-rc
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2008-06-05 12:38 (3 days old)--
I looked at the bugzilla entry, but it said not to post any replies in
there. I hope it's okay to reply here, because I couldn't find the
original discussion on LKML.Christian, did you try the nmi watchdog parameter on boot? It is
really quite simple -- add nmi_watchdog=1 to the kernel parameters.
When the machine freezes, leave it for a minute or two in that state.
The NMI watchdog code might be able to give us a backtrace and tell us
exactly where the machine is hanging. While waiting, you can prepare
the camera... ;-)(BTW, why isn't this nmi watchdog trick the "standard" reply to hung
kernels? It seems that very few are actually aware of it, or using it
to debug these cases.)Anyway, good luck with that! :-)
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
That was an Andrew's message targeted at the people who were on its CC list.
Of course you can update the Bugzilla entry. :-)
Thanks,
Rafael
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10830
Subject : two different oopses with 2.6.26-rc4
Submitter : Alejandro Riveira Fernández <alejandro.riveira@gmail.com>
Date : 2008-05-28 9:50 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121196833026310&w=4
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Andrew Morton <akpm@linux-foundation.org>
Peter Zijlstra <a.p.zijlstra@chello.nl>
Patch : http://lkml.org/lkml/2008/5/20/683--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10843
Subject : Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter : Frans Pop <elendil@planet.nl>
Date : 2008-05-31 14:04 (8 days old)--
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10828
Subject : [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error
Submitter : Rufus & Azrael <rufus-azrael@numericable.fr>
Date : 2008-05-04 10:24 (35 days old)
References : http://lkml.org/lkml/2008/5/4/37
Handled-By : Ingo Molnar <mingo@elte.hu>
H. Peter Anvin <hpa@zytor.com>
Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch : http://lkml.org/lkml/2008/5/29/371--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10823
Subject : stuck localhost TCP connections, v2.6.26-rc3+
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2008-05-26 11:56 (13 days old)
References : http://marc.info/?l=linux-kernel&m=121180311931349&w=4
Handled-By : Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>--
> Handled-By : Ilpo J
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10827
Subject : 2.6.26rc4 GFS2 oops.
Submitter : Dave Jones <davej@redhat.com>
Date : 2008-05-27 15:44 (12 days old)
References : http://lkml.org/lkml/2008/5/27/297--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10826
Subject : NFS oops in 2.6.26rc4
Submitter : Dave Jones <davej@redhat.com>
Date : 2008-05-27 19:04 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191548915522&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10825
Subject : appletouch after wakeup
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2008-05-27 3:29 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
http://lkml.org/lkml/2008/5/31/193
http://lkml.org/lkml/2008/5/31/193
Handled-By : Oliver Neukum <oliver@neukum.org>--
A patch is available but not yet in mainline.
Regards
Oliver
--
Cool; just an update, I've suspended the system numerous times it
seems appletouch is behaving correctly, in fact
I think better, why: when I start the system I have two finger scroll
functionality, then when suspending the system
after waking up the two finger scroll is still functional.
regards;--
Justin P. Mattock
--
With last week's patch or today's patch?
Regards
Oliver--
Last weeks patch.
regards;--
Justin P. Mattock
--
Could you also try today's patch?
Regards
Oliver--
Sure, where is it located.
regards;--
Justin P. Mattock
--
Didn't I mail it to you? Anyway, here it is.
Regards
Oliver----
--- linux-2.6.26-rc5/drivers/usb/core/quirks.c 2008-06-05 13:45:57.000000000 +0200
+++ linux-2.6.26-rc5-btusb/drivers/usb/core/quirks.c 2008-06-06 08:12:10.000000000 +0200
@@ -47,6 +47,9 @@ static const struct usb_device_id usb_qu
/* Edirol SD-20 */
{ USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },+ /* appletouch */
+ { USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* Avision AV600U */
{ USB_DEVICE(0x0638, 0x0a13), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
--- linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c.alt 2008-06-09 10:40:00.000000000 +0200
+++ linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c 2008-06-09 10:40:03.000000000 +0200
@@ -589,6 +589,20 @@ static void atp_close(struct input_dev *
dev->open = 0;
}+static int handle_geyser(struct atp *dev)
+{
+ struct usb_device *udev = dev->udev;
+
+ if (!atp_is_fountain(dev)) {
+ /* switch to raw sensor mode */
+ if (atp_geyser_init(udev))
+ return -EIO;
+
+ printk(KERN_INFO "appletouch: Geyser mode initialized.\n");
+ }
+ return 0;
+}
+
static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id)
{
struct atp *dev;
@@ -744,6 +758,20 @@ static void atp_disconnect(struct usb_in
printk(KERN_INFO "input: appletouch disconnected\n");
}+static int recover_dev(struct atp *dev)
+{
+ int rv;
+
+ rv = handle_geyser(dev);
+ if (rv < 0)
+ return rv;
+
+ if (dev->open && usb_submit_urb(dev->urb, GFP_NOIO))
+ return -EIO;
+
+ return 0;
+}
+
static int atp_suspend(struct usb_interface *iface, pm_message_t message)
{
struct atp *dev = usb_get_intfdata(iface);
@@ -764,12 +792,20 @@ static int atp_resume(struct usb_interfa
return 0;
}+static int atp_reset_resume(struct usb_interface *iface)
+{
+ struct atp *dev = usb_get_intfdata(iface);
+
+ return recover_dev(dev);
+}
+
static stru...
You probably did, I'll apply this and let you know.
regards;--
Justin P. Mattock
--
O.K. This is smaller than last weeks? anyways I applied the patch, and
am not seeing appletouch freak out like it did, also
two finger scroll is still active upon wakeup(FWIW). Cool, and thanks
for the help.
regards;--
Justin P. Mattock
--
Dmitry, Greg,
we have confirmation. Would you take the patch for 2.6.26 and stable?
Regards
Oliver
--
Please ignore the two finger scroll part(even though it seems to
work), I have been ignoring my xorg.conf for sometime and need to
configure it so I can have all functionality back, and then I'll let
you know what the status is.
regards;--
Justin P. Mattock
--
You can easily test with 'evtest' utility to see the data that are really
comming out of a kernel for your particular device, to filter out any
mangling that X does on these events.--
Jiri Kosina
SUSE Labs
--
Cool; Thanks for the help.
--
Justin P. Mattock
--
I'm not seeing appletouch react this way after applying the patches.
regards;--
Justin P. Mattock
--
Still, have the patches reached the Linus' tree yet?
Rafael
--
I'm not sure if they did or not, I think Oliver was working on that,
but am unsure.
regards;--
Justin P. Mattock
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10819
Subject : Fatal DMA error with b43 driver since 2.6.26
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2008-05-29 13:16 (10 days old)--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
Subject : rt25xx: lock dependancy warning, association failure, and kmalloc corruption
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2008-05-29 14:30 (10 days old)--
Ivo, can you look at this 2.6.26-rc regression?
TIA
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
Sure, both issues should have been fixed in 2.6.26-rc5 :)
Ivo
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10816
Subject : vt/fbcon: fix background color on line feed
Submitter : thunder7 <thunder7@xs4all.nl>
Date : 2008-05-27 19:33 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191733218735&w=4
Handled-By : Jan Engelhardt <jengelh@medozas.de>
Patch : http://marc.info/?l=linux-kernel&m=121199453010047&w=4--
is upstream 774533b3e86fa52941c79aa80ab3f0cc511bba7f.
--
Thanks, closed.
Rafael
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2008-05-27 09:23 (12 days old)
References : http://lkml.org/lkml/2008/5/27/9
Handled-By : Oleg Nesterov <oleg@tv-sign.ru>
Linus Torvalds <torvalds@linux-foundation.org>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Patch : http://lkml.org/lkml/2008/5/28/16--
What happened with this issue?
It is currently listed as 2.6.26-rc regression.
Is this correct?And if this patch is required it might not be a good idea to allow the
use to disable the new code.cu
Adrian--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--
The patch listed above works for me, passes rcutorture, &c. However,
I never have been able to reproduce the original problem, so cannot say
whether it qualifies as a fix.--
I doubt very much RCU was the reason of this problem.
Alexey, how did you trigger this problem?
Oleg.
--
Although I very much appreciate your confidence in my code, it is new
One of them involved running LTP while doing 170 kernel builds in
parallel.Thanx, Paul
--
My gut feeling is that find_pid_ns oops, __d_lookup oops and
__call_for_each_cic oops are the same bug.And rcutorture failures I've mentioned to Paul privately.
Oleg, debugging you've posted never triggered.
kerneloops suggests that I'm alone. :-(
--
Yep, running rcutorture in parallel with LTP, which didn't reproduce
for me either.Assuming that the above patch didn't help... As a desperation measure,
I could suggest the following patch.Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---rcupreempt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)diff -urpNa -X dontdiff linux-2.6.26-rc4/kernel/rcupreempt.c linux-2.6.26-rc4-alexey/kernel/rcupreempt.c
--- linux-2.6.26-rc4/kernel/rcupreempt.c 2008-05-30 04:39:01.000000000 -0700
+++ linux-2.6.26-rc4-alexey/kernel/rcupreempt.c 2008-06-14 20:24:53.000000000 -0700
@@ -77,7 +77,7 @@
*
* GP in GP_STAGES stands for Grace Period ;)
*/
-#define GP_STAGES 2
+#define GP_STAGES 3
struct rcu_data {
spinlock_t lock; /* Protect rcu_data fields. */
long completed; /* Number of last completed batch. */
--
Both patches (independently) do not help with rcutortures failures:
[ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
[ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
[ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
[ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
[ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
[ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5--
And the repeat-by is simply running LTP in parallel with rcutorture?
This is a one-hour run of rcutorture or thereabouts?Thanx, Paul
--
I also tried running LTP in parallel with rcutorture on POWER, and I
cannot reproduce on that platform either.Thanx, Paul
--
Should we mark PREEMPT_RCU as BROKEN for now? I don't know if anybody
really enables it, but it might be a good idea to make sure people don't
do so thinking it's good..Linus
--
If that is the right thing to do. I would feel better about it if I
could reproduce the failure.Thanx, Paul
--
Is there some configuration thing that might make it happen for Alexey but
not for you? The only obvious one is the normal PREEMPT thing, but
PREEMPT_RCU obviously depends on that, so there must be something else.CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
of config options that change scheduling details..Linus
--
The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
SCHED_MC.All of this doesn't help, but SMP=n does.
--
Maybe this is a stupid suggestion, but SLUB _is_ involved here (in
poisoning the object when it is freed). Do you have SLUB_DEBUG_ON=y or
did you check whether it matters if you have these options on or off?Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
Attached is the compressed config file I used for a run on a POWER
machine. I have used similar config files for x86. For this run, I built
LTP, installed it, started rcutorture, ran LTP, then ended rcutorture.The only other thing I can think of is that Alexey's machines are
somehow managing to nest NMIs or something. I can produce a fix for
that, but have no way of testing it.Thoughts?
Thanx, Paul
No NMIs here according to /proc/interrupts .
CPU0 CPU1
0: 42 0 IO-APIC-edge timer
1: 8 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
16: 0 0 IO-APIC-fasteoi ahci, uhci_hcd:usb1
17: 35 0 IO-APIC-fasteoi pata_jmicron, uhci_hcd:usb2
18: 0 0 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb6
19: 6238 0 IO-APIC-fasteoi ata_piix, ata_piix, uhci_hcd:usb5
22: 278 0 IO-APIC-fasteoi HDA Intel
23: 2802 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb7, eth1
319: 5126 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 66777 66036 Local timer interrupts
RES: 3031 3403 Rescheduling interrupts
CAL: 17 62 function call interrupts
TLB: 671 900 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0--
OK, thank you for the information. Looking elsewhere...
Thanx, Paul
--
[rcutorture failures with PREEMPT_RCU]
Status update:
* bug is reproduced on another box with the very same symptoms:
SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
Also Core 2 Duo, x86_64 [1]Race is wide -- 60 seconds of rcutorture is enough.
So far tried without effect:
not doing SMP-alternatives
NO_HZ=y/n
HIGH_RES_TIMERS=y/n
compiling with gcc 3.4.6/4.1.2
different HZ
s/asm/asm volatile/g at percpu asm code and PDA asm code
turning on and off varying CONFIG_DEBUG_ options
CONFIG_DEBUG_PREEMPT
softlockup on/off
making x86_64 cpu_idle() same as 32-bit one wrt rcu_pending et al
sched_setaffinity() in __synchronize_sched doesn't failProbably forgot something, but not a single thing that can remove the
bug in SMP=y case.Using SMP percpu stuff for UP case miserably failed because of some hard
hang due to incomplete patch, but I still leave this for doomsday.I'm going to try 32-bit setup and reading rcupreempt disassembly with
microscope.[1]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 4791.74
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de...
Good point!!! Would either you or Nick be willing to send me either
the vmlinux or a disassembly of the relevant portions?--
This is interesting. The bug occurs on a single CPU, so the bug cannot
involve memory ordering (because CPUs see their own accesses in order)
or preemptions from one CPU to another (as there is but one CPU).It might involve ordering issues in __rcu_read_lock() or
__rcu_read_unlock(), though the code generated by gcc version 4.1.2 is
ordered correctly on x86.The code for raw_smp_processor_id() differs in the two cases, but should
give zero in all cases either way, given that there is but one CPU.
Locking goes awayin SMP=n, but the grace-period code disables irqs,
which should act as a good and sufficient lock in the single-CPU caseThis is rcutorture by itself, or in parallel with LTP/kernbench?
(I have mostly been running on 4-CPU boxes without failure either way,
so will try a dual-CPU box.)--
FYI, i've been running rcutorture for days on lots of testboxes ranging
all across the x86 spectrum from single CPU, through dual-core, to
dual-socket, dual-socket HT, 8-way and 16-way - both 32-bit and 64-bit
x86.Not a single failure has been detected in thousands of bootups of random
kernels (rcu-preempt + rcutorture was a frequent combination tested). I
added a WARN_ON() to rcutorture failures so it should show up very
clearly.This makes me suspect that it might be some special environment issue -
gcc for example. I'm using gcc 4.2.2 on most of the testboxes.Ingo
--
And running rcutorture overnight on an Opteron system (9.7M updates) showed
no failures.Thanx, Paul
--
Very odd how you can reproduce it - now on two machines - but it doesn't
seem to happen for others. You've tried different compilers, you've tried
different config options, what the heck is left?And it's not like Core 2 Duo is an "odd" setup. Even any timer differences
should have been largely flushed out with HIGH_RES_TIMERS=y/n.Is there *anything* odd about those machines?
Linus
--
The PREEMPT_RCU thing? I've reproduced it. It hits lockless pagecache,
but I've also reproduced the same problem in dentry cache shrinking.
I'm sure it is a free-before-grace bug.I've been using DEBUG_PAGEALLOC to make it easier to spot.
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10765
Subject : iwl3945/mac80211: association times out since 2.6.26-rc1
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2008-05-20 22:46 (19 days old)
Handled-By : Zhu Yi <yi.zhu@intel.com>
Johannes Berg <johannes@sipsolutions.net>
Patch : http://article.gmane.org/gmane.linux.kernel.wireless.general/15177--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10799
Subject : sky2 general protection fault
Submitter : Nicolas Mailhot <Nicolas.Mailhot@LaPoste.net>
Date : 2008-05-26 11:05 (13 days old)--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10794
Subject : mips: CONF_CM_DEFAULT build error
Submitter : Adrian Bunk <adrian.bunk@movial.fi>
Date : 2008-05-25 10:11 (14 days old)
References : http://lkml.org/lkml/2008/5/25/168
Patch : http://lkml.org/lkml/2008/6/1/125--
cu
Adrian
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10787
Subject : pcie hotplug bootup crash fix
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2008-05-24 16:58 (15 days old)
References : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
Handled-By : Ingo Molnar <mingo@elte.hu>
Patch : http://marc.info/?l=linux-kernel&m=121164842212038&w=4--
This is fixed (workaround for now) in 2.6.26-rc5.
Thanks,
Kenji Kaneshige--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10764
Subject : some serial configurations are now broken
Submitter : Russell King <rmk+lkml@arm.linux.org.uk>
Date : 2008-05-20 7:35 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121126931810706&w=2
Handled-By : Javier Herrero <jherrero@hvsistemas.es>
Russell King <rmk+lkml@arm.linux.org.uk>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject : 2.6.26-rc3 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <cavokz@gmail.com>
Date : 2008-05-22 16:14 (17 days old)
References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10761
Subject : hackbench regression with 2.6.26-rc2 on tulsa machine
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2008-05-20 8:09 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121127121813708&w=2
http://lkml.org/lkml/2008/6/2/10
Handled-By : Mike Galbraith <efault@gmx.de>--
The fingered patchlet and the code it touched were reverted, so I think
this is a stale entry.-Mike
--
Thanks, closed.
Rafael
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10748
Subject : dhclient fails to run; capabilities error
Submitter : Amit Shah <shahamit@gmail.com>
Date : 2008-05-19 06:25 (20 days old)--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10760
Subject : PCIEHP breakage in 2.6.26-rc1,2.6.26-rc2,2.6.26-rc3
Submitter : Ryan Hope <rmh3093@gmail.com>
Date : 2008-05-19 17:47 (20 days old)
References : http://marc.info/?l=linux-pci&m=121121926401755&w=2
Handled-By : Matthew Wilcox <matthew@wil.cx>--
I believe this was fixed in 2.6.26-rc5. Could anyone please confirm it?
Unfortunately, I don't have the reproduction environment.Thanks,
Kenji Kaneshige--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10741
Subject : bug in `tty: BKL pushdown'?
Submitter : Johannes Weiner <hannes@saeurebad.de>
Date : 2008-05-18 2:16 (21 days old)
References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10730
Subject : build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'
Submitter : Toralf Förster <toralf.foerster@gmx.de>
Date : 2008-05-16 17:06 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095777616792&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10726
Subject : x86-64 NODES_SHIFT compile failure.
Submitter : Dave Jones <davej@codemonkey.org.uk>
Date : 2008-05-16 12:54 (23 days old)
References : http://lkml.org/lkml/2008/5/16/312
Handled-By : Mike Travis <travis@sgi.com>
Patch : http://lkml.org/lkml/2008/5/16/343--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
Subject : ACPI: EC: GPE storm detected, disabling EC GPE
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2008-05-16 6:17 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
http://lkml.org/lkml/2008/5/18/168
http://lkml.org/lkml/2008/5/25/195
http://lkml.org/lkml/2008/5/25/195
Patch : debug EC GPE
debug EC GPE
debug EC GPE
debug EC GPE
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
debug EC GPE</a>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject : Write protect on on
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2008-05-16 14:55 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject : Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter : Balbir Singh <balbir@linux.vnet.ibm.com>
Date : 2008-05-14 12:57 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121076917429133&w=4--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10711
Subject : BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2008-05-14 11:23 (25 days old)
References : http://lkml.org/lkml/2008/5/14/111--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10686
Subject : critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700
Submitter : Len Brown <len.brown@intel.com>
Date : 2008-05-12 20:04 (27 days old)
Handled-By : Robert Moore <Robert.Moore@intel.com>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10670
Subject : BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
Submitter : Karol Lewandowski <lmctlx@gmail.com>
Date : 2008-05-08 23:12 (31 days old)
References : http://marc.info/?l=linux-kernel&m=121028841527994&w=4
http://lkml.org/lkml/2008/5/12/12
Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16153&action=view--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10669
Subject : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
Submitter : Vegard Nossum <vegard.nossum@gmail.com>
Date : 2008-05-06 16:09 (33 days old)
References : http://marc.info/?l=linux-acpi&m=121009034825514&w=4
Handled-By : Lin Ming <ming.m.lin@intel.com>
Ming Lin <ming.m.lin@intel.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16199&action=view--
I'm sorry, I have no idea why this fix isn't going upstream. I tested
the patch and it's completely fine with regards to kmemcheck. And the
patch it fixes was already upstream so I don't see what's stopping it
from going back in + the fix.So the question is if this should go in now, or whether it should wait
till 2.6.26. In either case, the regression itself was solved by the
means of a revert, and that's quite a long time ago, so the current
kernel should be fine in this regard, though I think the original
patch fixed some errors on its own.Ming Lin, will you resubmit the original patch plus the fix for
re-inclusion in mainline? There's no point in having this regression
entry around when it has been fixed by either/both the revert or/and
the extra "fix" patch.Thanks! :-)
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2008-05-05 09:59 (34 days old)
References : http://lkml.org/lkml/2008/5/5/28
Handled-By : Paul E. McKenney <paulmck@linux.vnet.ibm.com>--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10642
Subject : general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2008-05-07 16:03 (32 days old)
References : http://lkml.org/lkml/2008/5/7/48--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10616
Subject : Horrendous Audio Stutter - current git
Submitter : Parag Warudkar <parag.warudkar@gmail.com>
Date : 2008-05-02 20:14 (37 days old)
References : http://lkml.org/lkml/2008/5/1/440
http://lkml.org/lkml/2008/5/11/230
http://lkml.org/lkml/2008/5/18/178
Handled-By : Peter Zijlstra <peterz@infradead.org>
Patch : http://lkml.org/lkml/2008/5/2/126--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10606
Subject : 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
Submitter : NIgel Cunningham <nigel@suspend2.net>
Date : 2008-05-05 18:11 (34 days old)
References : http://lkml.org/lkml/2008/5/18/328
http://lkml.org/lkml/2008/5/26/3
http://lkml.org/lkml/2008/6/2/524
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16061&action=view--
This message has been generated automatically as a part of a report
of recent regressions.The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10493
Subject : mips BCM47XX compile error
Submitter : Adrian Bunk <adrian.bunk@movial.fi>
Date : 2008-04-20 17:07 (49 days old)
References : http://lkml.org/lkml/2008/4/20/34
http://lkml.org/lkml/2008/5/12/30
http://lkml.org/lkml/2008/5/18/131
http://lkml.org/lkml/2008/5/31/202
Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2--
cu
Adrian
--
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| David Miller | Slow DOWN, please!!! |
| Jared Hulbert | [PATCH 00/10] AXFS: Advanced XIP filesystem |
| Alan Cox | Re: TALPA - a threat model? well sorta. |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Corey Minyard | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
git: | |
