Re: 2.6.20-mm2
On Friday, 23 February 2007 17:36, David Brownell wrote: > > > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > > > > Unable to handle kernel NULL pointer dereference at 0030 > > > > > RIP: > > > > > [] rtc_sysfs_remove_device+0x23/0x50 > > The bug isn't in rtc_cmos, but that's the only driver that would currently > show the bug. (Triggered by finding the IRQ claimed by the legacy driver, > result of a "but it should still be safe!" misconfiguration.) > > The following fixes this on my 2.6.21-rc1 system; same fix should apply > to MM2. > > = CUT HERE > Fix an oops on the rtc_device_unregister() path by waiting until the > last moment before nulling the rtc->ops vector. Fix some potential > oopses by having the rtc_class_open()/rtc_class_close() interface > increase the RTC's reference count while an RTC handle is available > outside the RTC framework. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> The patch fixes the Oops on my Asus L5D and allows it to suspend to disk (without it the problem is present in 2.6.21-rc1 and 2.6.21-rc2). I think it should go into 2.6.21. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Friday, 23 February 2007 17:36, David Brownell wrote: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [804032c3] rtc_sysfs_remove_device+0x23/0x50 The bug isn't in rtc_cmos, but that's the only driver that would currently show the bug. (Triggered by finding the IRQ claimed by the legacy driver, result of a but it should still be safe! misconfiguration.) The following fixes this on my 2.6.21-rc1 system; same fix should apply to MM2. = CUT HERE Fix an oops on the rtc_device_unregister() path by waiting until the last moment before nulling the rtc-ops vector. Fix some potential oopses by having the rtc_class_open()/rtc_class_close() interface increase the RTC's reference count while an RTC handle is available outside the RTC framework. Signed-off-by: David Brownell [EMAIL PROTECTED] The patch fixes the Oops on my Asus L5D and allows it to suspend to disk (without it the problem is present in 2.6.21-rc1 and 2.6.21-rc2). I think it should go into 2.6.21. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Hi Andrew, On Tue, 27 Feb 2007 12:25:51 -0800, Andrew Morton wrote: > > On Sun, 25 Feb 2007 14:15:30 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > > Hi Andrew, all, > > > > I appear to need the following fix to be able to build 2.6.20-mm2 on > > x86_64. Without the fix, my build attempt dies on: > > > > In file included from drivers/pci/quirks.c:532: > > include/asm/io_apic.h:61: error: "MAX_IO_APICS" undeclared here (not in a > > function) > > > > Not sure how nobody else was bitten by this one yet... i386 seems to > > need the same so I've fixed it as well. > > > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > > --- > > include/asm-i386/io_apic.h |1 + > > include/asm-x86_64/io_apic.h |1 + > > 2 files changed, 2 insertions(+) > > > > --- linux-2.6.20.orig/include/asm-i386/io_apic.h2007-02-25 > > 13:01:40.0 +0100 > > +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 > > +0100 > > @@ -3,6 +3,7 @@ > > > > #include > > #include > > +#include > > > > /* > > * Intel IO-APIC support for SMP and UP systems. > > --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h 2007-02-25 > > 13:01:43.0 +0100 > > +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 > > 13:54:31.0 +0100 > > @@ -3,6 +3,7 @@ > > > > #include > > #include > > +#include > > > > /* > > * Intel IO-APIC support for SMP and UP systems. > > > > erk. > > My problem is that I need to work out which patch in -mm broke the build so > that I can insert this patch in the appropriate position. > > Can you please send the offending .config so I can do that? I've bisected myself 2.6.20-mm2 instead. And the winners are: x86_64-mm-adjust-inclusion-of-asm-fixmap_h.patch x86_64-mm-adjust-inclusion-of-asm-vsyscall32_h.patch The former breaks the compilation in a different way. The latter fixes it but causes the breakage I reported originally. Does it really matter anyway? Even in mainline, include/asm-x86_64/io_apic.h uses MAX_IO_APICS, so it should include the header file which defines it, that is . It doesn't, that's a bug, let's just fix it. Same for i386. So what about pushing my patch to Linus right away? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Hi Andrew, On Tue, 27 Feb 2007 12:25:51 -0800, Andrew Morton wrote: On Sun, 25 Feb 2007 14:15:30 +0100 Jean Delvare [EMAIL PROTECTED] wrote: Hi Andrew, all, I appear to need the following fix to be able to build 2.6.20-mm2 on x86_64. Without the fix, my build attempt dies on: In file included from drivers/pci/quirks.c:532: include/asm/io_apic.h:61: error: MAX_IO_APICS undeclared here (not in a function) Not sure how nobody else was bitten by this one yet... i386 seems to need the same so I've fixed it as well. Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- include/asm-i386/io_apic.h |1 + include/asm-x86_64/io_apic.h |1 + 2 files changed, 2 insertions(+) --- linux-2.6.20.orig/include/asm-i386/io_apic.h2007-02-25 13:01:40.0 +0100 +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h 2007-02-25 13:01:43.0 +0100 +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 13:54:31.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. erk. My problem is that I need to work out which patch in -mm broke the build so that I can insert this patch in the appropriate position. Can you please send the offending .config so I can do that? I've bisected myself 2.6.20-mm2 instead. And the winners are: x86_64-mm-adjust-inclusion-of-asm-fixmap_h.patch x86_64-mm-adjust-inclusion-of-asm-vsyscall32_h.patch The former breaks the compilation in a different way. The latter fixes it but causes the breakage I reported originally. Does it really matter anyway? Even in mainline, include/asm-x86_64/io_apic.h uses MAX_IO_APICS, so it should include the header file which defines it, that is asm/apicdef.h. It doesn't, that's a bug, let's just fix it. Same for i386. So what about pushing my patch to Linus right away? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
> On Sun, 25 Feb 2007 14:15:30 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Andrew, all, > > I appear to need the following fix to be able to build 2.6.20-mm2 on > x86_64. Without the fix, my build attempt dies on: > > In file included from drivers/pci/quirks.c:532: > include/asm/io_apic.h:61: error: "MAX_IO_APICS" undeclared here (not in a > function) > > Not sure how nobody else was bitten by this one yet... i386 seems to > need the same so I've fixed it as well. > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > --- > include/asm-i386/io_apic.h |1 + > include/asm-x86_64/io_apic.h |1 + > 2 files changed, 2 insertions(+) > > --- linux-2.6.20.orig/include/asm-i386/io_apic.h 2007-02-25 > 13:01:40.0 +0100 > +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 > +0100 > @@ -3,6 +3,7 @@ > > #include > #include > +#include > > /* > * Intel IO-APIC support for SMP and UP systems. > --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h2007-02-25 > 13:01:43.0 +0100 > +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 13:54:31.0 > +0100 > @@ -3,6 +3,7 @@ > > #include > #include > +#include > > /* > * Intel IO-APIC support for SMP and UP systems. > erk. My problem is that I need to work out which patch in -mm broke the build so that I can insert this patch in the appropriate position. Can you please send the offending .config so I can do that? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sun, 25 Feb 2007 14:15:30 +0100 Jean Delvare [EMAIL PROTECTED] wrote: Hi Andrew, all, I appear to need the following fix to be able to build 2.6.20-mm2 on x86_64. Without the fix, my build attempt dies on: In file included from drivers/pci/quirks.c:532: include/asm/io_apic.h:61: error: MAX_IO_APICS undeclared here (not in a function) Not sure how nobody else was bitten by this one yet... i386 seems to need the same so I've fixed it as well. Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- include/asm-i386/io_apic.h |1 + include/asm-x86_64/io_apic.h |1 + 2 files changed, 2 insertions(+) --- linux-2.6.20.orig/include/asm-i386/io_apic.h 2007-02-25 13:01:40.0 +0100 +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h2007-02-25 13:01:43.0 +0100 +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 13:54:31.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. erk. My problem is that I need to work out which patch in -mm broke the build so that I can insert this patch in the appropriate position. Can you please send the offending .config so I can do that? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Hi Andrew, all, I appear to need the following fix to be able to build 2.6.20-mm2 on x86_64. Without the fix, my build attempt dies on: In file included from drivers/pci/quirks.c:532: include/asm/io_apic.h:61: error: "MAX_IO_APICS" undeclared here (not in a function) Not sure how nobody else was bitten by this one yet... i386 seems to need the same so I've fixed it as well. Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> --- include/asm-i386/io_apic.h |1 + include/asm-x86_64/io_apic.h |1 + 2 files changed, 2 insertions(+) --- linux-2.6.20.orig/include/asm-i386/io_apic.h2007-02-25 13:01:40.0 +0100 +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 +0100 @@ -3,6 +3,7 @@ #include #include +#include /* * Intel IO-APIC support for SMP and UP systems. --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h 2007-02-25 13:01:43.0 +0100 +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 13:54:31.0 +0100 @@ -3,6 +3,7 @@ #include #include +#include /* * Intel IO-APIC support for SMP and UP systems. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Hi Andrew, all, I appear to need the following fix to be able to build 2.6.20-mm2 on x86_64. Without the fix, my build attempt dies on: In file included from drivers/pci/quirks.c:532: include/asm/io_apic.h:61: error: MAX_IO_APICS undeclared here (not in a function) Not sure how nobody else was bitten by this one yet... i386 seems to need the same so I've fixed it as well. Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- include/asm-i386/io_apic.h |1 + include/asm-x86_64/io_apic.h |1 + 2 files changed, 2 insertions(+) --- linux-2.6.20.orig/include/asm-i386/io_apic.h2007-02-25 13:01:40.0 +0100 +++ linux-2.6.20/include/asm-i386/io_apic.h 2007-02-25 14:01:33.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. --- linux-2.6.20.orig/include/asm-x86_64/io_apic.h 2007-02-25 13:01:43.0 +0100 +++ linux-2.6.20/include/asm-x86_64/io_apic.h 2007-02-25 13:54:31.0 +0100 @@ -3,6 +3,7 @@ #include asm/types.h #include asm/mpspec.h +#include asm/apicdef.h /* * Intel IO-APIC support for SMP and UP systems. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
> > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> > > > Unable to handle kernel NULL pointer dereference at 0030
> > > > RIP:
> > > > [] rtc_sysfs_remove_device+0x23/0x50
The bug isn't in rtc_cmos, but that's the only driver that would currently
show the bug. (Triggered by finding the IRQ claimed by the legacy driver,
result of a "but it should still be safe!" misconfiguration.)
The following fixes this on my 2.6.21-rc1 system; same fix should apply
to MM2.
= CUT HERE
Fix an oops on the rtc_device_unregister() path by waiting until the
last moment before nulling the rtc->ops vector. Fix some potential
oopses by having the rtc_class_open()/rtc_class_close() interface
increase the RTC's reference count while an RTC handle is available
outside the RTC framework.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/rtc/class.c
===
--- g26.orig/drivers/rtc/class.c2007-02-21 12:03:20.0 -0800
+++ g26/drivers/rtc/class.c 2007-02-23 08:00:52.0 -0800
@@ -204,10 +204,16 @@ EXPORT_SYMBOL_GPL(rtc_device_register);
*/
void rtc_device_unregister(struct rtc_device *rtc)
{
- mutex_lock(>ops_lock);
- rtc->ops = NULL;
- mutex_unlock(>ops_lock);
- class_device_unregister(>class_dev);
+ if (class_device_get(>class_dev) != NULL) {
+ mutex_lock(>ops_lock);
+ /* remove innards of this RTC, then disable it, before
+* letting any rtc_class_open() users access it again
+*/
+ class_device_unregister(>class_dev);
+ rtc->ops = NULL;
+ mutex_unlock(>ops_lock);
+ class_device_put(>class_dev);
+ }
}
EXPORT_SYMBOL_GPL(rtc_device_unregister);
Index: g26/drivers/rtc/interface.c
===
--- g26.orig/drivers/rtc/interface.c2006-11-27 15:37:13.0 -0800
+++ g26/drivers/rtc/interface.c 2007-02-23 07:45:09.0 -0800
@@ -179,7 +179,7 @@ struct class_device *rtc_class_open(char
down(_class->sem);
list_for_each_entry(class_dev_tmp, _class->children, node) {
if (strncmp(class_dev_tmp->class_id, name, BUS_ID_SIZE) == 0) {
- class_dev = class_dev_tmp;
+ class_dev = class_device_get(class_dev_tmp);
break;
}
}
@@ -197,6 +197,7 @@ EXPORT_SYMBOL_GPL(rtc_class_open);
void rtc_class_close(struct class_device *class_dev)
{
module_put(to_rtc_device(class_dev)->owner);
+ class_device_put(class_dev);
}
EXPORT_SYMBOL_GPL(rtc_class_close);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
Unable to handle kernel NULL pointer dereference at 0030
RIP:
[804032c3] rtc_sysfs_remove_device+0x23/0x50
The bug isn't in rtc_cmos, but that's the only driver that would currently
show the bug. (Triggered by finding the IRQ claimed by the legacy driver,
result of a but it should still be safe! misconfiguration.)
The following fixes this on my 2.6.21-rc1 system; same fix should apply
to MM2.
= CUT HERE
Fix an oops on the rtc_device_unregister() path by waiting until the
last moment before nulling the rtc-ops vector. Fix some potential
oopses by having the rtc_class_open()/rtc_class_close() interface
increase the RTC's reference count while an RTC handle is available
outside the RTC framework.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/rtc/class.c
===
--- g26.orig/drivers/rtc/class.c2007-02-21 12:03:20.0 -0800
+++ g26/drivers/rtc/class.c 2007-02-23 08:00:52.0 -0800
@@ -204,10 +204,16 @@ EXPORT_SYMBOL_GPL(rtc_device_register);
*/
void rtc_device_unregister(struct rtc_device *rtc)
{
- mutex_lock(rtc-ops_lock);
- rtc-ops = NULL;
- mutex_unlock(rtc-ops_lock);
- class_device_unregister(rtc-class_dev);
+ if (class_device_get(rtc-class_dev) != NULL) {
+ mutex_lock(rtc-ops_lock);
+ /* remove innards of this RTC, then disable it, before
+* letting any rtc_class_open() users access it again
+*/
+ class_device_unregister(rtc-class_dev);
+ rtc-ops = NULL;
+ mutex_unlock(rtc-ops_lock);
+ class_device_put(rtc-class_dev);
+ }
}
EXPORT_SYMBOL_GPL(rtc_device_unregister);
Index: g26/drivers/rtc/interface.c
===
--- g26.orig/drivers/rtc/interface.c2006-11-27 15:37:13.0 -0800
+++ g26/drivers/rtc/interface.c 2007-02-23 07:45:09.0 -0800
@@ -179,7 +179,7 @@ struct class_device *rtc_class_open(char
down(rtc_class-sem);
list_for_each_entry(class_dev_tmp, rtc_class-children, node) {
if (strncmp(class_dev_tmp-class_id, name, BUS_ID_SIZE) == 0) {
- class_dev = class_dev_tmp;
+ class_dev = class_device_get(class_dev_tmp);
break;
}
}
@@ -197,6 +197,7 @@ EXPORT_SYMBOL_GPL(rtc_class_open);
void rtc_class_close(struct class_device *class_dev)
{
module_put(to_rtc_device(class_dev)-owner);
+ class_device_put(class_dev);
}
EXPORT_SYMBOL_GPL(rtc_class_close);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Thursday 22 February 2007 12:33 am, Rafael J. Wysocki wrote: > Unfortunately, the userland shipped with OpenSUSE refuses to talk to the new > one (or I don't know how to make it do that). Did your "udev" create a /dev/rtc0? If not, /sys/class/rtc-dev/rtc0/dev will give the right major/minor numbers. Given a /dev/rtc0, there are two simple solutions: (a) ln -s /dev/rtc0 /dev/rtc (b) upgrade your "hwclock" to one supporting "hwclock --file /dev/rtc0", since that should also try rtc0 when rtc can't be opened. I found a udev incantation "git whatchanged drivers/rtc/rtc-dev.c", which can automate (a): KERNEL=="rtc0", SYMLINK+="rtc" I'm not sure what the story is on hwclock updates, given the issue with "util-linux" maintainership. I sent a patch on 7-Aug-2006 to Adrian Bunk, which appears to have been disregarded, then to Karel Zak (for the new fork?) on 17-Nov-2006 ... but if there's been an announcement about a new util-linux repository with that patch, I missed it. The busybox patch I submitted 26-Jan-2007 hasn't yet been merged, but that's a lot more understandable. Basically it looks like userspace is almost a year behind the kernel support for this RTC framework. The problematic part is that it seems that the "util-linux" maintainership issues are preventing that issue from getting resolved ... so for now, I usually use workaround (a). > > Shoot. OK, I'll see if I can reproduce it myself. Is this system > > using a generic CMOS RTC? Or is HPET somehow involved? (That old > > RTC driver has HPET voodoo as well as normal RTC stuff.) > > How can I check that? If your boot messages say things about HPET, that's a start. :) I don't really know HPET; it hasn't ever come up on any system that I've used. ISTR that for various reasons BIOS would hide it on most systems, but that Linux has been working on un-hiding that hardware so it could be used. I'll read up on it. (As I implied, the source code comments leave a lot to be desired.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Thursday, 22 February 2007 04:57, David Brownell wrote: > On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote: > > > > Plus, I'd guess, the old rtc driver statically linked. > > > > Yes (mistakenly). > > Until someone merges the BSOD-for-Linux patch, I'll continue to > assume that oopsing is the wrong response to "user" mistakes. ;) > > Legacy drivers can be such a PITA. Unfortunately, the userland shipped with OpenSUSE refuses to talk to the new one (or I don't know how to make it do that). > > > What I see is a should-not-happen fault of some kind in a cleanup > > > path that's been tested with non-PNP rtc drivers. A quick glance > > > at the code left me puzzled. Would sleeping a second or two before > > > calling rtc_device_unregister() change that behavior? > > > > [tries] > > > > No. > > Shoot. OK, I'll see if I can reproduce it myself. Is this system > using a generic CMOS RTC? Or is HPET somehow involved? (That old > RTC driver has HPET voodoo as well as normal RTC stuff.) How can I check that? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Thursday, 22 February 2007 04:57, David Brownell wrote: On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote: Plus, I'd guess, the old rtc driver statically linked. Yes (mistakenly). Until someone merges the BSOD-for-Linux patch, I'll continue to assume that oopsing is the wrong response to user mistakes. ;) Legacy drivers can be such a PITA. Unfortunately, the userland shipped with OpenSUSE refuses to talk to the new one (or I don't know how to make it do that). What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? [tries] No. Shoot. OK, I'll see if I can reproduce it myself. Is this system using a generic CMOS RTC? Or is HPET somehow involved? (That old RTC driver has HPET voodoo as well as normal RTC stuff.) How can I check that? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Thursday 22 February 2007 12:33 am, Rafael J. Wysocki wrote: Unfortunately, the userland shipped with OpenSUSE refuses to talk to the new one (or I don't know how to make it do that). Did your udev create a /dev/rtc0? If not, /sys/class/rtc-dev/rtc0/dev will give the right major/minor numbers. Given a /dev/rtc0, there are two simple solutions: (a) ln -s /dev/rtc0 /dev/rtc (b) upgrade your hwclock to one supporting hwclock --file /dev/rtc0, since that should also try rtc0 when rtc can't be opened. I found a udev incantation git whatchanged drivers/rtc/rtc-dev.c, which can automate (a): KERNEL==rtc0, SYMLINK+=rtc I'm not sure what the story is on hwclock updates, given the issue with util-linux maintainership. I sent a patch on 7-Aug-2006 to Adrian Bunk, which appears to have been disregarded, then to Karel Zak (for the new fork?) on 17-Nov-2006 ... but if there's been an announcement about a new util-linux repository with that patch, I missed it. The busybox patch I submitted 26-Jan-2007 hasn't yet been merged, but that's a lot more understandable. Basically it looks like userspace is almost a year behind the kernel support for this RTC framework. The problematic part is that it seems that the util-linux maintainership issues are preventing that issue from getting resolved ... so for now, I usually use workaround (a). Shoot. OK, I'll see if I can reproduce it myself. Is this system using a generic CMOS RTC? Or is HPET somehow involved? (That old RTC driver has HPET voodoo as well as normal RTC stuff.) How can I check that? If your boot messages say things about HPET, that's a start. :) I don't really know HPET; it hasn't ever come up on any system that I've used. ISTR that for various reasons BIOS would hide it on most systems, but that Linux has been working on un-hiding that hardware so it could be used. I'll read up on it. (As I implied, the source code comments leave a lot to be desired.) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
Is this Problem still investigated? I got the same kernel bug a few minutes after booting my system with 2.6.20-mm2. As a student i am not yet as familiar with kernel programming as i want to be, but i will try, i promise. In the meantime, i always try to test the newest mm patches, and i have to say, this one is the first which doesent work right on my sys since 2.6.15-mm1. Thanks, keep up the good work an please help me with this Problem Greetz Oli On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > > >Temporarily at > > > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > > >Will appear later at > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > > runlevel 2 and wait less than one minute. > > > > Maybe this oops is related too? > > Looks that way. > > > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > > > BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 > > printing eip: > > c02206aa > > *pde = > > Oops: [#1] > > PREEMPT > > last sysfs file: /devices/pci:00/:00:00.0/class > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > > EIP is at __make_request+0x13a/0x390 > > eax: ebx: ecx: 042b0dd8 edx: 00010485 > > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 > >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 > >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 > > Call Trace: > > [] show_trace_log_lvl+0x1a/0x30 > > [] show_stack_log_lvl+0xa9/0xd0 > > [] show_registers+0x206/0x350 > > [] die+0x10e/0x210 > > [] do_page_fault+0x2d2/0x600 > > [] error_code+0x74/0x7c > > [] generic_make_request+0x15a/0x200 > > [] submit_bio+0x58/0xe0 > > [] metapage_writepage+0x18f/0x1b0 > > [] __writepage+0xb/0x30 > > [] write_cache_pages+0x22f/0x300 > > [] generic_writepages+0x23/0x30 > > [] do_writepages+0x5c/0x60 > > [] __filemap_fdatawrite_range+0x67/0x80 > > [] filemap_flush+0x25/0x30 > > [] lmLogSync+0x19d/0x230 > > [] lmLog+0x5e/0x190 > > [] txCommit+0x8c0/0x1010 > > [] jfs_create+0x324/0x370 > > [] vfs_create+0xaf/0x100 > > [] open_namei+0x58c/0x640 > > [] do_filp_open+0x2c/0x50 > > [] do_sys_open+0x47/0xe0 > > [] sys_open+0x1c/0x20 > > [] syscall_call+0x7/0xb > > Michal Piotrowski is hitting it too, and has bisected it down to > git-block.patch. > > I have bisected it down to this patches > revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch > git-block.patch > git-block-fixup.patch > git-block-dupe-definitions.patch > git-block-xfs-barriers-broke.patch > Regards, > Michal > -- > Michal K. K. Piotrowski > LTG - Linux Testers Group (PL) > (http://www.stardust.webpages.pl/ltg/) > LTG - Linux Testers Group (EN) > (http://www.stardust.webpages.pl/linux_testers_group_en/) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote: > > Plus, I'd guess, the old rtc driver statically linked. > > Yes (mistakenly). Until someone merges the BSOD-for-Linux patch, I'll continue to assume that oopsing is the wrong response to "user" mistakes. ;) Legacy drivers can be such a PITA. > > What I see is a should-not-happen fault of some kind in a cleanup > > path that's been tested with non-PNP rtc drivers. A quick glance > > at the code left me puzzled. Would sleeping a second or two before > > calling rtc_device_unregister() change that behavior? > > [tries] > > No. Shoot. OK, I'll see if I can reproduce it myself. Is this system using a generic CMOS RTC? Or is HPET somehow involved? (That old RTC driver has HPET voodoo as well as normal RTC stuff.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote: Plus, I'd guess, the old rtc driver statically linked. Yes (mistakenly). Until someone merges the BSOD-for-Linux patch, I'll continue to assume that oopsing is the wrong response to user mistakes. ;) Legacy drivers can be such a PITA. What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? [tries] No. Shoot. OK, I'll see if I can reproduce it myself. Is this system using a generic CMOS RTC? Or is HPET somehow involved? (That old RTC driver has HPET voodoo as well as normal RTC stuff.) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
Is this Problem still investigated? I got the same kernel bug a few minutes after booting my system with 2.6.20-mm2. As a student i am not yet as familiar with kernel programming as i want to be, but i will try, i promise. In the meantime, i always try to test the newest mm patches, and i have to say, this one is the first which doesent work right on my sys since 2.6.15-mm1. Thanks, keep up the good work an please help me with this Problem Greetz Oli On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[c02206aa]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [c01048ba] show_trace_log_lvl+0x1a/0x30 [c0104979] show_stack_log_lvl+0xa9/0xd0 [c0104ba6] show_registers+0x206/0x350 [c0104dfe] die+0x10e/0x210 [c0114652] do_page_fault+0x2d2/0x600 [c0351f84] error_code+0x74/0x7c [c021e0ca] generic_make_request+0x15a/0x200 [c0220318] submit_bio+0x58/0xe0 [c0205d0f] metapage_writepage+0x18f/0x1b0 [c014cc2b] __writepage+0xb/0x30 [c014d20f] write_cache_pages+0x22f/0x300 [c014d303] generic_writepages+0x23/0x30 [c014d36c] do_writepages+0x5c/0x60 [c0148307] __filemap_fdatawrite_range+0x67/0x80 [c0149785] filemap_flush+0x25/0x30 [c02080cd] lmLogSync+0x19d/0x230 [c020871e] lmLog+0x5e/0x190 [c020a360] txCommit+0x8c0/0x1010 [c01eecf4] jfs_create+0x324/0x370 [c016f38f] vfs_create+0xaf/0x100 [c017269c] open_namei+0x58c/0x640 [c0165b7c] do_filp_open+0x2c/0x50 [c0165be7] do_sys_open+0x47/0xe0 [c0165cbc] sys_open+0x1c/0x20 [c01041c0] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. I have bisected it down to this patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: possible recursive locking detected (reiserfs-related)
Am 20.02.2007 22:23 schrieb Rafael J. Wysocki:
> Looks like reiserfs has some locking problems:
>
> =
> [ INFO: possible recursive locking detected ]
> 2.6.20-mm2 #6
> -
> beagled/4786 is trying to acquire lock:
> (>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
>
> but task is already holding lock:
> (>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
>
> other info that might help us debug this:
> 3 locks held by beagled/4786:
> #0: (>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
> #1: (_I(inode)->xattr_sem){}, at: []
> reiserfs_setxattr+0x79/0x150
> #2: (_SB(s)->xattr_dir_sem){}, at: []
> reiserfs_setxattr+0xa0/0x150
This looks like the same I have been seeing in every release
since 2.6.18. I reported it a couple of times, and Srinivasa Ds
tried a few fixes on me during 2.6.19-rc4, but we never got to
the bottom of it.
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
Re: 2.6.20-mm2
On Tuesday, 20 February 2007 07:31, Andrew Morton wrote: > On Tue, 20 Feb 2007 02:20:21 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > On Sunday, 18 February 2007 20:43, Andrew Morton wrote: > > > On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL > > > PROTECTED]> wrote: > > > > > > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > > > > > > > Temporarily at > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > > > > > Will appear later at > > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > > > > > Two problems: > > > > > > > > 1) A showstopper with the root partition on RAID1: > > > > > > > > md: raid1 personality registered for level 1 > > > > [--snip--] > > > > md: multipath personality registered for level -4 > > > > register_blkdev: failed to get major for mdp > > > > [--snip--] > > > > VFS: Cannot open root device "md1" or unknown-block(0,0) > > > > > > Someone else reported that against mainline. Can you please debug it a > > > bit? > > > > For now I can only say 2.6.20 + origin.patch breaks. > > > > However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason. > > I'll check that tomorrow. > > Yes, Rolf says this goes away when you stop using gcc-4.1.0. > > I'm hoping that churning the code around like below makes things work > right. Yes, that helps. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 06:13, David Brownell wrote: > On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote: > > On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > > wrote: > > > > > > One more thing: > > > > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > > Unable to handle kernel NULL pointer dereference at 0030 RIP: > > > [] rtc_sysfs_remove_device+0x23/0x50 > > > ... > > > Call Trace: > > > [] class_device_del+0x86/0x180 > > > [] class_device_unregister+0x11/0x20 > > > [] rtc_device_unregister+0x3e/0x50 > > > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > > > [] pnp_device_probe+0xa1/0xe0 > > > ... > > > > How did you provoke that? modprobe rtc-cmos? > > Plus, I'd guess, the old rtc driver statically linked. Yes (mistakenly). > What I see is a should-not-happen fault of some kind in a cleanup > path that's been tested with non-PNP rtc drivers. A quick glance > at the code left me puzzled. Would sleeping a second or two before > calling rtc_device_unregister() change that behavior? [tries] No. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Rafael J. Wysocki wrote: FWIW, with CONFIG_PREEMPT unset (CONFIG_PREEMPT_VOLUNTARY is set instead), I'm unable to reproduce this problem on the box on which it is readily reproducible with CONFIG_PREEMPT set. I'm not surprised... I routinely tell people to turn it off, when debugging a problem. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: possible recursive locking detected (reiserfs-related)
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm2/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Looks like reiserfs has some locking problems:
=
[ INFO: possible recursive locking detected ]
2.6.20-mm2 #6
-
beagled/4786 is trying to acquire lock:
(>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
but task is already holding lock:
(>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
other info that might help us debug this:
3 locks held by beagled/4786:
#0: (>i_mutex){--..}, at: [] mutex_lock+0x19/0x20
#1: (_I(inode)->xattr_sem){}, at: []
reiserfs_setxattr+0x79/0x150
#2: (_SB(s)->xattr_dir_sem){}, at: []
reiserfs_setxattr+0xa0/0x150
stack backtrace:
Call Trace:
[] __lock_acquire+0xa9f/0xf30
[] mutex_lock+0x19/0x20
[] lock_acquire+0x88/0xc0
[] mutex_lock+0x19/0x20
[] __mutex_lock_slowpath+0xec/0x270
[] dentry_open+0x6a/0x80
[] mutex_lock+0x19/0x20
[] reiserfs_xattr_set+0x127/0x3d0
[] mark_held_locks+0x5d/0x90
[] __down_write_nested+0x38/0xb0
[] trace_hardirqs_on+0x13f/0x170
[] _spin_unlock_irq+0x2b/0x40
[] user_set+0x68/0x90
[] reiserfs_setxattr+0xb4/0x150
[] vfs_setxattr+0xb9/0x200
[] setxattr+0xea/0x110
[] trace_hardirqs_on+0x13f/0x170
[] poison_obj+0x42/0x60
[] kmem_cache_free+0xf5/0x110
[] trace_hardirqs_on+0x13f/0x170
[] putname+0x3f/0x50
[] __user_walk_fd+0x57/0x70
[] sys_lsetxattr+0x63/0x90
[] trace_hardirqs_on_thunk+0x35/0x37
[] trace_hardirqs_on+0x13f/0x170
[] trace_hardirqs_on_thunk+0x35/0x37
[] system_call+0x7e/0x83
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tuesday, 20 February 2007 01:04, Rafael J. Wysocki wrote: > On Monday, 19 February 2007 12:45, Michal Piotrowski wrote: > > On 19/02/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > On Monday, 19 February 2007 01:00, Andrew Morton wrote: > > > > On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL > > > > PROTECTED]> wrote: > > > > > > > > > > netconsole is good. > > > > > > > > > > I know. :-) > > > > > > > > > > In the meantime, I've got something worse on another x86_64 box: > > > > > > > > > > Asus Laptop ACPI Extras version 0.30 > > > > > L5D model detected, supported > > > > > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > > > > > general protection fault: [2] PREEMPT > > > > > last sysfs file: /class/net/eth2/carrier > > > > > CPU 0 > > > > > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > > > > > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > > > > > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > > > > > RIP: 0010:[] [] > > > > > __make_request+0x134/0x370 > > > > > RSP: :81005ed659a0 EFLAGS: 00010297 > > > > > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > > > > > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > > > > > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > > > > > R10: R11: R12: 810037b4dbb0 > > > > > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > > > > > FS: 2ad4a29e6d00() GS:805db000() > > > > > knlGS: > > > > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > > > > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > > > > > Process pdflush (pid: 178, threadinfo 81005ed64000, task > > > > > 810037b060c0) > > > > > Stack: 810002852540 0001 810037b4dbb0 > > > > > 8026be21 > > > > > 81005ed65a40 0008 810037b4dbb0 0800 > > > > > 0008 8100021d94e0 81005ed65a40 80348e7c > > > > > Call Trace: > > > > > [] mempool_alloc_slab+0x11/0x20 > > > > > [] generic_make_request+0x1ec/0x230 > > > > > > > > yeah. everyone except me is hitting that. > > > > > > FWIW, I don't see it on an SMP machine. > > > > > > > I can reproduce this on my SMT P4. > > > > CONFIG_SMP=y > > CONFIG_X86_PC=y > > CONFIG_MPENTIUM4=y > > CONFIG_NR_CPUS=2 > > CONFIG_SCHED_SMT=y > > It may be related to preemption. The box I'm not seeing it on runs a > non-preemptible kernel (CONFIG_PREEMPT_VOLUNTARY is set). FWIW, with CONFIG_PREEMPT unset (CONFIG_PREEMPT_VOLUNTARY is set instead), I'm unable to reproduce this problem on the box on which it is readily reproducible with CONFIG_PREEMPT set. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Feb 20 12:18:35 maciek kernel: [ 1443.641949] BUG: unable to handle kernel NULL pointer dereference at virtual address 003e Feb 20 12:18:35 maciek kernel: [ 1443.641974] printing eip: Feb 20 12:18:35 maciek kernel: [ 1443.641980] c01ede81 Feb 20 12:18:35 maciek kernel: [ 1443.641984] *pde = Feb 20 12:18:35 maciek kernel: [ 1443.641996] Oops: [#1] Feb 20 12:18:35 maciek kernel: [ 1443.642000] PREEMPT Feb 20 12:18:35 maciek kernel: [ 1443.642008] last sysfs file: /class/i2c-adapter/i2c-9191/9191-6000/temp3_max Feb 20 12:18:35 maciek kernel: [ 1443.642016] Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq 8250_pnp 8250 serial_core uhci_hcd snd_via82xx gameport snd_ac97_codec ide_cd cdrom ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart shpchp pci_hotplug snd_rawmidi snd_seq_device via686a snd i2c_isa via_agp soundcore 8139cp 8139too mii i2c_core usbcore agpgart parport_pc parport evdev unix Feb 20 12:18:36 maciek kernel: [ 1443.642136] CPU:0 Feb 20 12:18:36 maciek kernel: [ 1443.642139] EIP:0060:[] Not tainted VLI Feb 20 12:18:36 maciek kernel: [ 1443.642144] EFLAGS: 00010297 (2.6.20-mm2 #1) Feb 20 12:18:36 maciek kernel: [ 1443.642172] EIP is at __make_request+0x141/0x390 Feb 20 12:18:36 maciek kernel: [ 1443.642182] eax: ebx: 003a ecx: 01291753 edx: 00010485 Feb 20 12:18:36 maciek kernel: [ 1443.642192] esi: dbfb62a0 edi: dbc781f8 ebp: dbc61844 esp: dbf9dd10 Feb 20 12:18:36 maciek kernel: [ 1443.642201] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Feb 20 12:18:36 maciek kernel: [ 1443.642212] Process pdflush (pid: 113, ti=dbf9c000 task=dbf82580 task.ti=dbf9c000) Feb 20 12:18:36 maciek kernel: [ 1443.642218] Stack: 0001 dbc781e4 dbfb62a0 d6830b74 dbc61844 dbfb62a0 0008 0100 Feb 20 12:18:36 maciek kernel: [ 1443.642238]c01eb77b dbfd03e0 c13fd9e0 c014e690 0008 Feb 20 12:18:36 maciek kernel: [ 1443.642256]0046 0292 dbfe6860 00011200 dbfd02f8 0292 0008 dbfb62a0 Feb 20 12:18:36 maciek kernel: [ 1443.642274] Call Trace: Feb 20 12:18:36 maciek kernel: [ 1443.642291] [] generic_make_request+0x14b/0x1f0 Feb 20 12:18:36 maciek kernel: [ 1443.642309] [] handle_level_irq+0xb0/0x120 Feb 20 12:18:36 maciek kernel: [ 1443.642346] [] submit_bio+0x68/0x100 Feb 20 12:18:36 maciek kernel: [ 1443.642368] [] bio_alloc_bioset+0x81/0x160 Feb 20 12:18:36 maciek kernel: [ 1443.642393] [] submit_bh+0xb9/0x100 = Feb 20 12:19:07 maciek kernel: [ 1475.055159] BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 Feb 20 12:19:07 maciek kernel: [ 1475.064380] printing eip: Feb 20 12:19:07 maciek kernel: [ 1475.100792] c01ede81 Feb 20 12:19:07 maciek kernel: [ 1475.109234] *pde = Feb 20 12:19:07 maciek kernel: [ 1475.117432] Oops: [#2] Feb 20 12:19:07 maciek kernel: [ 1475.125573] PREEMPT Feb 20 12:19:07 maciek kernel: [ 1475.133589] last sysfs file: /class/i2c-adapter/i2c-9191/9191-6000/temp3_max Feb 20 12:19:07 maciek kernel: [ 1475.141953] Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq 8250_pnp 8250 serial_core uhci_hcd snd_via82xx gameport snd_ac97_codec ide_cd cdrom ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart shpchp pci_hotplug snd_rawmidi snd_seq_device via686a snd i2c_isa via_agp soundcore 8139cp 8139too mii i2c_core usbcore agpgart parport_pc parport evdev unix Feb 20 12:19:07 maciek kernel: [ 1475.188714] CPU:0 Feb 20 12:19:08 maciek kernel: [ 1475.188718] EIP:0060:[] Not tainted VLI Feb 20 12:19:08 maciek kernel: [ 1475.188722] EFLAGS: 00010297 (2.6.20-mm2 #1) Feb 20 12:19:08 maciek kernel: [ 1475.217051] EIP is at __make_request+0x141/0x390 Feb 20 12:19:08 maciek kernel: [ 1475.226423] eax: ebx: ecx: 016d4643 edx: Feb 20 12:19:08 maciek kernel: [ 1475.235950] esi: d6307d20 edi: dbc78978 ebp: dbc61844 esp: d5e09c7c Feb 20 12:19:08 maciek kernel: [ 1475.245535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Feb 20 12:19:08 maciek kernel: [ 1475.255156] Process kde-config (pid: 4675, ti=d5e08000 task=d6843a70 task.ti=d5e08000) Feb 20 12:19:08 maciek kernel: [ 1475.255504] Stack: dbc78964 d6307d20 d6f89494 dbc61844 d6307d20 0008 0100 Feb 20 12:19:08 maciek kernel: [ 1475.265489]c01eb77b 0004 d5e979d0 0014718f 0008 00150613 d62b8788 Feb 20 12:19:08
Re: 2.6.20-mm2
kernel BUG at block/ll_rw_blk.c:2782! invalid opcode: [#1] PREEMPT last sysfs file: /class/net/eth0/address Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_via82xx gameport 8250_pnp 8250 serial_core snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device via686a snd i2c_isa uhci_hcd soundcore ide_cd i2c_core usbcore shpchp pci_hotplug via_agp 8139cp 8139too mii cdrom parport_pc parport agpgart evdev unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210282 (2.6.20-mm2 #1) EIP is at bio_attempt_back_merge+0x22/0x70 eax: dbc62844 ebx: db4968f4 ecx: d71db720 edx: db4968f4 esi: d71db720 edi: dbc79fa8 ebp: dbc62844 esp: d46ebb4c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process gvim (pid: 3573, ti=d46ea000 task=d819b090 task.ti=d46ea000) Stack: db4968f4 d71db720 c01edea9 dbc79f94 d71db720 dbfd0300 dbc62844 d71db720 0008 0100 c01eb77b 2000 d71db720 c12216c0 004ff928 0008 c019b8c7 1000 0100 1000 0001 c019f9b6 Call Trace: [] __make_request+0x169/0x390 [] generic_make_request+0x14b/0x1f0 [] bio_add_page+0x37/0x50 [] do_mpage_readpage+0x336/0x590 [] submit_bio+0x68/0x100 [] mpage_end_io_read+0x0/0x80 [] mpage_bio_submit+0x19/0x20 [] mpage_readpages+0x85/0x140 [] ext3_get_block+0x0/0xf0 [] ext3_readpages+0x0/0x20 [] __do_page_cache_readahead+0x1e2/0x2e0 [] ext3_get_block+0x0/0xf0 [] sleep_on_buffer+0x0/0x10 [] out_of_line_wait_on_bit+0x7b/0x90 [] __find_get_block_slow+0x5f/0x120 [] ra_submit+0xeb/0x110 [] page_cache_readahead_adaptive+0x15a/0x580 [] __getblk+0x16/0x210 [] __d_lookup+0xc5/0x180 [] do_generic_mapping_read+0x512/0x5f0 [] generic_file_aio_read+0x104/0x240 [] file_read_actor+0x0/0x130 [] get_unused_fd+0xa4/0xd0 [] do_sync_read+0xd5/0x120 [] may_open+0x66/0x220 [] __dentry_open+0x17a/0x1f0 [] wake_bit_function+0x0/0x70 [] do_filp_open+0x4b/0x60 [] vfs_read+0xa1/0x140 [] do_sync_read+0x0/0x120 [] sys_read+0x41/0x70 [] syscall_call+0x7/0xb === Code: 90 90 90 90 90 90 90 90 90 56 89 ce 53 f6 42 14 d8 89 d3 75 16 83 7a 18 01 75 10 e8 89 e8 ff ff 31 d2 85 c0 75 09 5b 5e 89 d0 c3 <0f> 0b eb fe 8b 43 38 89 70 04 89 73 38 8b 46 1c c1 e8 09 03 43 EIP: [] bio_attempt_back_merge+0x22/0x70 SS:ESP 0068:d46ebb4c -- Maciej Rutecki <[EMAIL PROTECTED]> config-2.6.20-mm2.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data info.txt.gz Description: GNU Zip compressed data smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.20-mm2
Andrew Morton wrote: > - Judging by the number of times I get asked "is there a git tree for -mm", > nobody is reading the boilerplate. Here it is again: The git tree version of -mm seems to be sick. A fetch of the tag gives you something but it is "significantly" (200k lines of diff) away from what patching a virgin tree gives you. The 'last' patch seems to be: scsi-megaraid_sas-throttle-io-if-fw-is-busy -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Andrew Morton wrote: - Judging by the number of times I get asked is there a git tree for -mm, nobody is reading the boilerplate. Here it is again: The git tree version of -mm seems to be sick. A fetch of the tag gives you something but it is significantly (200k lines of diff) away from what patching a virgin tree gives you. The 'last' patch seems to be: scsi-megaraid_sas-throttle-io-if-fw-is-busy -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
kernel BUG at block/ll_rw_blk.c:2782! invalid opcode: [#1] PREEMPT last sysfs file: /class/net/eth0/address Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_via82xx gameport 8250_pnp 8250 serial_core snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device via686a snd i2c_isa uhci_hcd soundcore ide_cd i2c_core usbcore shpchp pci_hotplug via_agp 8139cp 8139too mii cdrom parport_pc parport agpgart evdev unix CPU:0 EIP:0060:[c01ec662]Not tainted VLI EFLAGS: 00210282 (2.6.20-mm2 #1) EIP is at bio_attempt_back_merge+0x22/0x70 eax: dbc62844 ebx: db4968f4 ecx: d71db720 edx: db4968f4 esi: d71db720 edi: dbc79fa8 ebp: dbc62844 esp: d46ebb4c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process gvim (pid: 3573, ti=d46ea000 task=d819b090 task.ti=d46ea000) Stack: db4968f4 d71db720 c01edea9 dbc79f94 d71db720 dbfd0300 dbc62844 d71db720 0008 0100 c01eb77b 2000 d71db720 c12216c0 004ff928 0008 c019b8c7 1000 0100 1000 0001 c019f9b6 Call Trace: [c01edea9] __make_request+0x169/0x390 [c01eb77b] generic_make_request+0x14b/0x1f0 [c019b8c7] bio_add_page+0x37/0x50 [c019f9b6] do_mpage_readpage+0x336/0x590 [c01eda58] submit_bio+0x68/0x100 [c019fc70] mpage_end_io_read+0x0/0x80 [c019f059] mpage_bio_submit+0x19/0x20 [c019fde5] mpage_readpages+0x85/0x140 [c01bc870] ext3_get_block+0x0/0xf0 [c01bbb00] ext3_readpages+0x0/0x20 [c015bab2] __do_page_cache_readahead+0x1e2/0x2e0 [c01bc870] ext3_get_block+0x0/0xf0 [c0198b10] sleep_on_buffer+0x0/0x10 [c02fb12b] out_of_line_wait_on_bit+0x7b/0x90 [c01980bf] __find_get_block_slow+0x5f/0x120 [c015bc9b] ra_submit+0xeb/0x110 [c015c46a] page_cache_readahead_adaptive+0x15a/0x580 [c0198516] __getblk+0x16/0x210 [c0188205] __d_lookup+0xc5/0x180 [c01550a2] do_generic_mapping_read+0x512/0x5f0 [c0157544] generic_file_aio_read+0x104/0x240 [c01542f0] file_read_actor+0x0/0x130 [c0174094] get_unused_fd+0xa4/0xd0 [c01759f5] do_sync_read+0xd5/0x120 [c017e796] may_open+0x66/0x220 [c017423a] __dentry_open+0x17a/0x1f0 [c0132260] wake_bit_function+0x0/0x70 [c01743bb] do_filp_open+0x4b/0x60 [c01762c1] vfs_read+0xa1/0x140 [c0175920] do_sync_read+0x0/0x120 [c0176721] sys_read+0x41/0x70 [c0104130] syscall_call+0x7/0xb === Code: 90 90 90 90 90 90 90 90 90 56 89 ce 53 f6 42 14 d8 89 d3 75 16 83 7a 18 01 75 10 e8 89 e8 ff ff 31 d2 85 c0 75 09 5b 5e 89 d0 c3 0f 0b eb fe 8b 43 38 89 70 04 89 73 38 8b 46 1c c1 e8 09 03 43 EIP: [c01ec662] bio_attempt_back_merge+0x22/0x70 SS:ESP 0068:d46ebb4c -- Maciej Rutecki [EMAIL PROTECTED] config-2.6.20-mm2.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data info.txt.gz Description: GNU Zip compressed data smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.20-mm2
Feb 20 12:18:35 maciek kernel: [ 1443.641949] BUG: unable to handle kernel NULL pointer dereference at virtual address 003e Feb 20 12:18:35 maciek kernel: [ 1443.641974] printing eip: Feb 20 12:18:35 maciek kernel: [ 1443.641980] c01ede81 Feb 20 12:18:35 maciek kernel: [ 1443.641984] *pde = Feb 20 12:18:35 maciek kernel: [ 1443.641996] Oops: [#1] Feb 20 12:18:35 maciek kernel: [ 1443.642000] PREEMPT Feb 20 12:18:35 maciek kernel: [ 1443.642008] last sysfs file: /class/i2c-adapter/i2c-9191/9191-6000/temp3_max Feb 20 12:18:35 maciek kernel: [ 1443.642016] Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq 8250_pnp 8250 serial_core uhci_hcd snd_via82xx gameport snd_ac97_codec ide_cd cdrom ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart shpchp pci_hotplug snd_rawmidi snd_seq_device via686a snd i2c_isa via_agp soundcore 8139cp 8139too mii i2c_core usbcore agpgart parport_pc parport evdev unix Feb 20 12:18:36 maciek kernel: [ 1443.642136] CPU:0 Feb 20 12:18:36 maciek kernel: [ 1443.642139] EIP:0060:[c01ede81] Not tainted VLI Feb 20 12:18:36 maciek kernel: [ 1443.642144] EFLAGS: 00010297 (2.6.20-mm2 #1) Feb 20 12:18:36 maciek kernel: [ 1443.642172] EIP is at __make_request+0x141/0x390 Feb 20 12:18:36 maciek kernel: [ 1443.642182] eax: ebx: 003a ecx: 01291753 edx: 00010485 Feb 20 12:18:36 maciek kernel: [ 1443.642192] esi: dbfb62a0 edi: dbc781f8 ebp: dbc61844 esp: dbf9dd10 Feb 20 12:18:36 maciek kernel: [ 1443.642201] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Feb 20 12:18:36 maciek kernel: [ 1443.642212] Process pdflush (pid: 113, ti=dbf9c000 task=dbf82580 task.ti=dbf9c000) Feb 20 12:18:36 maciek kernel: [ 1443.642218] Stack: 0001 dbc781e4 dbfb62a0 d6830b74 dbc61844 dbfb62a0 0008 0100 Feb 20 12:18:36 maciek kernel: [ 1443.642238]c01eb77b dbfd03e0 c13fd9e0 c014e690 0008 Feb 20 12:18:36 maciek kernel: [ 1443.642256]0046 0292 dbfe6860 00011200 dbfd02f8 0292 0008 dbfb62a0 Feb 20 12:18:36 maciek kernel: [ 1443.642274] Call Trace: Feb 20 12:18:36 maciek kernel: [ 1443.642291] [c01eb77b] generic_make_request+0x14b/0x1f0 Feb 20 12:18:36 maciek kernel: [ 1443.642309] [c014e690] handle_level_irq+0xb0/0x120 Feb 20 12:18:36 maciek kernel: [ 1443.642346] [c01eda58] submit_bio+0x68/0x100 Feb 20 12:18:36 maciek kernel: [ 1443.642368] [c019b381] bio_alloc_bioset+0x81/0x160 Feb 20 12:18:36 maciek kernel: [ 1443.642393] [c0197e09] submit_bh+0xb9/0x100 = Feb 20 12:19:07 maciek kernel: [ 1475.055159] BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 Feb 20 12:19:07 maciek kernel: [ 1475.064380] printing eip: Feb 20 12:19:07 maciek kernel: [ 1475.100792] c01ede81 Feb 20 12:19:07 maciek kernel: [ 1475.109234] *pde = Feb 20 12:19:07 maciek kernel: [ 1475.117432] Oops: [#2] Feb 20 12:19:07 maciek kernel: [ 1475.125573] PREEMPT Feb 20 12:19:07 maciek kernel: [ 1475.133589] last sysfs file: /class/i2c-adapter/i2c-9191/9191-6000/temp3_max Feb 20 12:19:07 maciek kernel: [ 1475.141953] Modules linked in: xt_tcpudp xt_limit xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables x_tables fuse ppdev lp thermal fan button processor ac battery tun ipv6 eeprom i2c_viapro usbhid snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq 8250_pnp 8250 serial_core uhci_hcd snd_via82xx gameport snd_ac97_codec ide_cd cdrom ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart shpchp pci_hotplug snd_rawmidi snd_seq_device via686a snd i2c_isa via_agp soundcore 8139cp 8139too mii i2c_core usbcore agpgart parport_pc parport evdev unix Feb 20 12:19:07 maciek kernel: [ 1475.188714] CPU:0 Feb 20 12:19:08 maciek kernel: [ 1475.188718] EIP:0060:[c01ede81] Not tainted VLI Feb 20 12:19:08 maciek kernel: [ 1475.188722] EFLAGS: 00010297 (2.6.20-mm2 #1) Feb 20 12:19:08 maciek kernel: [ 1475.217051] EIP is at __make_request+0x141/0x390 Feb 20 12:19:08 maciek kernel: [ 1475.226423] eax: ebx: ecx: 016d4643 edx: Feb 20 12:19:08 maciek kernel: [ 1475.235950] esi: d6307d20 edi: dbc78978 ebp: dbc61844 esp: d5e09c7c Feb 20 12:19:08 maciek kernel: [ 1475.245535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Feb 20 12:19:08 maciek kernel: [ 1475.255156] Process kde-config (pid: 4675, ti=d5e08000 task=d6843a70 task.ti=d5e08000) Feb 20 12:19:08 maciek kernel: [ 1475.255504] Stack: dbc78964 d6307d20 d6f89494 dbc61844 d6307d20 0008 0100 Feb 20 12:19:08 maciek kernel: [ 1475.265489]c01eb77b 0004 d5e979d0
Re: 2.6.20-mm2: possible recursive locking detected (reiserfs-related)
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Looks like reiserfs has some locking problems:
=
[ INFO: possible recursive locking detected ]
2.6.20-mm2 #6
-
beagled/4786 is trying to acquire lock:
(inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
but task is already holding lock:
(inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
other info that might help us debug this:
3 locks held by beagled/4786:
#0: (inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
#1: (REISERFS_I(inode)-xattr_sem){}, at: [80304c99]
reiserfs_setxattr+0x79/0x150
#2: (REISERFS_SB(s)-xattr_dir_sem){}, at: [80304cc0]
reiserfs_setxattr+0xa0/0x150
stack backtrace:
Call Trace:
[8024823f] __lock_acquire+0xa9f/0xf30
[80479df9] mutex_lock+0x19/0x20
[80248758] lock_acquire+0x88/0xc0
[80479df9] mutex_lock+0x19/0x20
[80479c5c] __mutex_lock_slowpath+0xec/0x270
[8028d63a] dentry_open+0x6a/0x80
[80479df9] mutex_lock+0x19/0x20
[803052c7] reiserfs_xattr_set+0x127/0x3d0
[80246ffd] mark_held_locks+0x5d/0x90
[8047add8] __down_write_nested+0x38/0xb0
[8024722f] trace_hardirqs_on+0x13f/0x170
[8047b96b] _spin_unlock_irq+0x2b/0x40
[80305698] user_set+0x68/0x90
[80304cd4] reiserfs_setxattr+0xb4/0x150
[802ad829] vfs_setxattr+0xb9/0x200
[802ada5a] setxattr+0xea/0x110
[8024722f] trace_hardirqs_on+0x13f/0x170
[8028a342] poison_obj+0x42/0x60
[8028aa75] kmem_cache_free+0xf5/0x110
[8024722f] trace_hardirqs_on+0x13f/0x170
[80298aef] putname+0x3f/0x50
[8029ac67] __user_walk_fd+0x57/0x70
[802adae3] sys_lsetxattr+0x63/0x90
[8047b020] trace_hardirqs_on_thunk+0x35/0x37
[8024722f] trace_hardirqs_on+0x13f/0x170
[8047b020] trace_hardirqs_on_thunk+0x35/0x37
[8020989e] system_call+0x7e/0x83
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 06:13, David Brownell wrote: On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote: On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [804032c3] rtc_sysfs_remove_device+0x23/0x50 ... Call Trace: [803c5786] class_device_del+0x86/0x180 [803c5891] class_device_unregister+0x11/0x20 [8040280e] rtc_device_unregister+0x3e/0x50 [880cd789] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [803988a1] pnp_device_probe+0xa1/0xe0 ... How did you provoke that? modprobe rtc-cmos? Plus, I'd guess, the old rtc driver statically linked. Yes (mistakenly). What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? [tries] No. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: possible recursive locking detected (reiserfs-related)
Am 20.02.2007 22:23 schrieb Rafael J. Wysocki:
Looks like reiserfs has some locking problems:
=
[ INFO: possible recursive locking detected ]
2.6.20-mm2 #6
-
beagled/4786 is trying to acquire lock:
(inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
but task is already holding lock:
(inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
other info that might help us debug this:
3 locks held by beagled/4786:
#0: (inode-i_mutex){--..}, at: [80479df9] mutex_lock+0x19/0x20
#1: (REISERFS_I(inode)-xattr_sem){}, at: [80304c99]
reiserfs_setxattr+0x79/0x150
#2: (REISERFS_SB(s)-xattr_dir_sem){}, at: [80304cc0]
reiserfs_setxattr+0xa0/0x150
This looks like the same I have been seeing in every release
since 2.6.18. I reported it a couple of times, and Srinivasa Ds
tried a few fixes on me during 2.6.19-rc4, but we never got to
the bottom of it.
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
Re: 2.6.20-mm2
On Tuesday, 20 February 2007 01:04, Rafael J. Wysocki wrote: On Monday, 19 February 2007 12:45, Michal Piotrowski wrote: On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 February 2007 01:00, Andrew Morton wrote: On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: netconsole is good. I know. :-) In the meantime, I've got something worse on another x86_64 box: Asus Laptop ACPI Extras version 0.30 L5D model detected, supported audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 general protection fault: [2] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370 RSP: :81005ed659a0 EFLAGS: 00010297 RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 R10: R11: R12: 810037b4dbb0 R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 FS: 2ad4a29e6d00() GS:805db000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) Stack: 810002852540 0001 810037b4dbb0 8026be21 81005ed65a40 0008 810037b4dbb0 0800 0008 8100021d94e0 81005ed65a40 80348e7c Call Trace: [8026be21] mempool_alloc_slab+0x11/0x20 [80348e7c] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. FWIW, I don't see it on an SMP machine. I can reproduce this on my SMT P4. CONFIG_SMP=y CONFIG_X86_PC=y CONFIG_MPENTIUM4=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y It may be related to preemption. The box I'm not seeing it on runs a non-preemptible kernel (CONFIG_PREEMPT_VOLUNTARY is set). FWIW, with CONFIG_PREEMPT unset (CONFIG_PREEMPT_VOLUNTARY is set instead), I'm unable to reproduce this problem on the box on which it is readily reproducible with CONFIG_PREEMPT set. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Rafael J. Wysocki wrote: FWIW, with CONFIG_PREEMPT unset (CONFIG_PREEMPT_VOLUNTARY is set instead), I'm unable to reproduce this problem on the box on which it is readily reproducible with CONFIG_PREEMPT set. I'm not surprised... I routinely tell people to turn it off, when debugging a problem. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tuesday, 20 February 2007 07:31, Andrew Morton wrote: On Tue, 20 Feb 2007 02:20:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 20:43, Andrew Morton wrote: On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Two problems: 1) A showstopper with the root partition on RAID1: md: raid1 personality registered for level 1 [--snip--] md: multipath personality registered for level -4 register_blkdev: failed to get major for mdp [--snip--] VFS: Cannot open root device md1 or unknown-block(0,0) Someone else reported that against mainline. Can you please debug it a bit? For now I can only say 2.6.20 + origin.patch breaks. However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason. I'll check that tomorrow. Yes, Rolf says this goes away when you stop using gcc-4.1.0. I'm hoping that churning the code around like below makes things work right. Yes, that helps. Thanks, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tue, 20 Feb 2007 02:20:21 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> > On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > > >
> > > > Temporarily at
> > > >
> > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > > >
> > > > Will appear later at
> > > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> > >
> > > Two problems:
> > >
> > > 1) A showstopper with the root partition on RAID1:
> > >
> > > md: raid1 personality registered for level 1
> > > [--snip--]
> > > md: multipath personality registered for level -4
> > > register_blkdev: failed to get major for mdp
> > > [--snip--]
> > > VFS: Cannot open root device "md1" or unknown-block(0,0)
> >
> > Someone else reported that against mainline. Can you please debug it a bit?
>
> For now I can only say 2.6.20 + origin.patch breaks.
>
> However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason.
> I'll check that tomorrow.
Yes, Rolf says this goes away when you stop using gcc-4.1.0.
I'm hoping that churning the code around like below makes things work
right.
From: Andrew Morton <[EMAIL PROTECTED]>
Several people have reported failures in dynamic major device number handling
due to the recent changes in there to avoid handing out the local/experimental
majors.
Rolf reports that this is due to a gcc-4.1.0 bug.
The patch refactors that code a lot in an attempt to provoke the compiler into
behaving.
Cc: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
block/genhd.c |9 ++---
drivers/base/core.c| 14 ++
fs/char_dev.c |8 ++--
include/linux/kdev_t.h |1 +
4 files changed, 19 insertions(+), 13 deletions(-)
diff -puN block/genhd.c~rework-reserved-major-handling block/genhd.c
--- a/block/genhd.c~rework-reserved-major-handling
+++ a/block/genhd.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,13 +62,7 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
+ if (is_lanana_major(index))
continue;
if (major_names[index] == NULL)
break;
diff -puN fs/char_dev.c~rework-reserved-major-handling fs/char_dev.c
--- a/fs/char_dev.c~rework-reserved-major-handling
+++ a/fs/char_dev.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -108,12 +109,7 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= i && i <= 63) || (120 <= i && i <= 127) ||
- (240 <= i && i <= 254))
+ if (is_lanana_major(i))
continue;
if (chrdevs[i] == NULL)
break;
diff -puN drivers/base/core.c~rework-reserved-major-handling drivers/base/core.c
--- a/drivers/base/core.c~rework-reserved-major-handling
+++ a/drivers/base/core.c
@@ -28,6 +28,20 @@ int (*platform_notify)(struct device * d
int (*platform_notify_remove)(struct device * dev) = NULL;
/*
+ * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
+ */
+bool is_lanana_major(unsigned int major)
+{
+ if (major >= 60 && major <= 63)
+ return 1;
+ if (major >= 120 && major <= 127)
+ return 1;
+ if (major >= 240 && major <= 254)
+ return 1;
+ return 0;
+}
+
+/*
* sysfs bindings for devices.
*/
diff -puN include/linux/kdev_t.h~rework-reserved-major-handling
include/linux/kdev_t.h
--- a/include/linux/kdev_t.h~rework-reserved-major-handling
+++ a/include/linux/kdev_t.h
@@ -87,6 +87,7 @@ static inline unsigned sysv_minor(u32 de
return dev & 0x3;
}
+bool is_lanana_major(unsigned int major);
#else /* __KERNEL__ */
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20-mm2
On Sunday, 18 February 2007 20:43, Andrew Morton wrote: > On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Two problems: > > > > 1) A showstopper with the root partition on RAID1: > > > > md: raid1 personality registered for level 1 > > [--snip--] > > md: multipath personality registered for level -4 > > register_blkdev: failed to get major for mdp > > [--snip--] > > VFS: Cannot open root device "md1" or unknown-block(0,0) > > Someone else reported that against mainline. Can you please debug it a bit? For now I can only say 2.6.20 + origin.patch breaks. However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason. I'll check that tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:00, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > > netconsole is good. > > > > I know. :-) > > > > In the meantime, I've got something worse on another x86_64 box: > > > > Asus Laptop ACPI Extras version 0.30 > > L5D model detected, supported > > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > > general protection fault: [2] PREEMPT > > last sysfs file: /class/net/eth2/carrier > > CPU 0 > > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > > RIP: 0010:[] [] > > __make_request+0x134/0x370 > > RSP: :81005ed659a0 EFLAGS: 00010297 > > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > > R10: R11: R12: 810037b4dbb0 > > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > > FS: 2ad4a29e6d00() GS:805db000() knlGS: > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > > Process pdflush (pid: 178, threadinfo 81005ed64000, task > > 810037b060c0) > > Stack: 810002852540 0001 810037b4dbb0 8026be21 > > 81005ed65a40 0008 810037b4dbb0 0800 > > 0008 8100021d94e0 81005ed65a40 80348e7c > > Call Trace: > > [] mempool_alloc_slab+0x11/0x20 > > [] generic_make_request+0x1ec/0x230 > > yeah. everyone except me is hitting that. An interesting variant: [ cut here ] kernel BUG at block/ll_rw_blk.c:2782! invalid opcode: [1] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod usbhid pcmcir Pid: 5060, comm: preload Not tainted 2.6.20-mm2 #4 RIP: 0010:[] [] bio_attempt_back_merge+0x2a/0xa0 RSP: 0018:810045819a58 EFLAGS: 00010202 RAX: 00010080 RBX: 810046946eb0 RCX: 02b26b42 RDX: 0001 RSI: 810046946eb0 RDI: 810037d74a90 RBP: 810045819a68 R08: 810046946eb0 R09: 0400 R10: R11: R12: 810046fcc330 R13: 81004a218770 R14: 810037d74a90 R15: 81004a218750 FS: 2acb9c6076f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2aaac000 CR3: 45855000 CR4: 06e0 Process preload (pid: 5060, threadinfo 810045818000, task 81004a12e140) Stack: 810046946eb0 810046fcc330 810045819ac8 8034b730 810046fcc330 0002 810046946eb0 0008 810046fcc330 0800 Call Trace: [] __make_request+0x100/0x370 [] generic_make_request+0x1ec/0x230 [] bio_alloc_bioset+0xeb/0x120 [] submit_bio+0xf6/0x110 [] bio_alloc+0x10/0x20 [] mpage_bio_submit+0x22/0x30 [] do_mpage_readpage+0x505/0x590 [] _write_unlock_irq+0x36/0x60 [] add_to_page_cache+0xbb/0xf0 [] get_page_from_freelist+0x120/0x430 [] mpage_readpages+0xbe/0x160 [] ext3_get_block+0x0/0x110 [] ext3_get_block+0x0/0x110 [] _spin_unlock+0x30/0x50 [] get_page_from_freelist+0x220/0x430 [] ext3_readpages+0x1a/0x20 [] __do_page_cache_readahead+0x20f/0x330 [] cp_new_stat+0xf8/0x120 [] force_page_cache_readahead+0x6d/0xb0 [] sys_fadvise64_64+0x143/0x1e0 [] sys_fadvise64+0x9/0x10 [] system_call+0x7e/0x83 Code: 0f 0b 0f 1f 40 00 eb fe 4c 89 e2 e8 f6 df ff ff 31 d2 85 c0 RIP [] bio_attempt_back_merge+0x2a/0xa0 RSP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 12:45, Michal Piotrowski wrote:
> On 19/02/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > On Monday, 19 February 2007 01:00, Andrew Morton wrote:
> > > On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > > netconsole is good.
> > > >
> > > > I know. :-)
> > > >
> > > > In the meantime, I've got something worse on another x86_64 box:
> > > >
> > > > Asus Laptop ACPI Extras version 0.30
> > > > L5D model detected, supported
> > > > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
> > > > general protection fault: [2] PREEMPT
> > > > last sysfs file: /class/net/eth2/carrier
> > > > CPU 0
> > > > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
> > > > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
> > > > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
> > > > RIP: 0010:[] []
> > > > __make_request+0x134/0x370
> > > > RSP: :81005ed659a0 EFLAGS: 00010297
> > > > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
> > > > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
> > > > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
> > > > R10: R11: R12: 810037b4dbb0
> > > > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
> > > > FS: 2ad4a29e6d00() GS:805db000()
> > > > knlGS:
> > > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
> > > > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
> > > > Process pdflush (pid: 178, threadinfo 81005ed64000, task
> > > > 810037b060c0)
> > > > Stack: 810002852540 0001 810037b4dbb0
> > > > 8026be21
> > > > 81005ed65a40 0008 810037b4dbb0 0800
> > > > 0008 8100021d94e0 81005ed65a40 80348e7c
> > > > Call Trace:
> > > > [] mempool_alloc_slab+0x11/0x20
> > > > [] generic_make_request+0x1ec/0x230
> > >
> > > yeah. everyone except me is hitting that.
> >
> > FWIW, I don't see it on an SMP machine.
> >
>
> I can reproduce this on my SMT P4.
>
> CONFIG_SMP=y
> CONFIG_X86_PC=y
> CONFIG_MPENTIUM4=y
> CONFIG_NR_CPUS=2
> CONFIG_SCHED_SMT=y
It may be related to preemption. The box I'm not seeing it on runs a
non-preemptible kernel (CONFIG_PREEMPT_VOLUNTARY is set).
BTW, on the box where I'm able to reproduce it, I have
(gdb) l *__make_request+0x134
0x8034b764 is in __make_request (include/asm/processor.h:411).
406 #define cpu_has_fpu 1
407
408 #define ARCH_HAS_PREFETCH
409 static inline void prefetch(void *x)
410 {
411 asm volatile("prefetcht0 %0" :: "m" (*(unsigned long *)x));
412 }
413
414 #define ARCH_HAS_PREFETCHW 1
415 static inline void prefetchw(void *x)
So I guess x is NULL somewhere ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:28, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > One more thing: > > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > Unable to handle kernel NULL pointer dereference at 0030 RIP: > > [] rtc_sysfs_remove_device+0x23/0x50 > > PGD 5e10c067 PUD 5dd58067 PMD 0 > > Oops: [1] PREEMPT > > last sysfs file: /devices/pnp0/00:04/id > > CPU 0 > > Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus > > snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc > > ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor > > Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 > > RIP: 0010:[] [] > > rtc_sysfs_remove_device+0x23/0x50 > > RSP: 0018:81005e3f9c18 EFLAGS: 00010202 > > RAX: RBX: 81005dabeea0 RCX: > > RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 > > RBP: 81005e3f9c28 R08: 0001 R09: > > R10: R11: R12: 81005dabeea0 > > R13: 810002890258 R14: 810002890268 R15: 810002890098 > > FS: 2ac610b906f0() GS:805db000() knlGS: > > CS: 0010 DS: ES: CR0: 8005003b > > CR2: 0030 CR3: 5e16d000 CR4: 06e0 > > Process modprobe (pid: 2960, threadinfo 81005e3f8000, task > > 81005e6a7140) > > Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 > > 81005dabeea0 81005dabf008 0008 > > 81005fe244e8 0008 81005e3f9c88 803c5891 > > Call Trace: > > [] class_device_del+0x86/0x180 > > [] class_device_unregister+0x11/0x20 > > [] rtc_device_unregister+0x3e/0x50 > > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > > [] pnp_device_probe+0xa1/0xe0 > > [] __driver_attach+0x0/0xa0 > > [] driver_probe_device+0x115/0x1c0 > > [] __driver_attach+0x0/0xa0 > > [] __driver_attach+0x63/0xa0 > > [] bus_for_each_dev+0x4f/0x80 > > [] driver_attach+0x1c/0x20 > > [] bus_add_driver+0x83/0x1d0 > > [] driver_register+0x89/0x90 > > [] pnp_register_driver+0x1c/0x20 > > [] :rtc_cmos:cmos_init+0x10/0x12 > > [] sys_init_module+0x158b/0x16f0 > > [] dnotify_parent+0x7a/0x90 > > [] file_read_actor+0x0/0x170 > > [] system_call+0x7e/0x83 > > > > > > Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 > > RIP [] rtc_sysfs_remove_device+0x23/0x50 > > RSP > > CR2: 0030 > > How did you provoke that? modprobe rtc-cmos? I've just booted OpenSUSE 10.2 with this kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, Feb 18 2007, Andrew Morton wrote: > On Sun, 18 Feb 2007 14:35:17 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > I guess I need to do a git-blockless -mm3 > > OK, this is looking like a pain - I'd have to drop or significantly redo > thirty or more patches. Jens, please fix it asap. Will get on it, I wonder what on earth broke this time :( This plugging stuff will really have to show some merrit in the performance arena, otherwise it'll go out again soon. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 03:08:03PM +0100, Michal Piotrowski wrote: > Michal Piotrowski napisał(a): > > Hi Frederik, > > > > On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: > >> Hi Michal, > >> > >> This seems to be a locking problem in __make_request, check_plug_merge() > >> should be called with the q->queue_lock held. > >> Could you try the following patch? It silenced the oops for me. > > > > For me too, but Jens dislikes this patch. > > Now I know why... > > Code: Bad EIP value. > EIP: [<6b6b6b6b>] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 :) It may not be related though. I think that my patch avoids the BUG_ON(!rq_mergeable(req)); in ll_rw_blk.c:2782. This looks like another beast to me. Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 02:34:53PM +0100, Jens Axboe wrote: > On Tue, Feb 20 2007, Frederik Deweerdt wrote: > > On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: > > > On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> > > > >wrote: > > > > > > > >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > > >> > Le 18.02.2007 06:51, Andrew Morton a ?crit : > > > >> > >Temporarily at > > > >> > > > > > >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > >> > > > > > >> > >Will appear later at > > > >> > > > > > >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > >> > > > > >> > Hello, I've got a fully reproducible Oops. I just have to boot to > > > >> > runlevel 2 and wait less than one minute. > > > >> > > > >> Maybe this oops is related too? > > > > > > > >Looks that way. > > > > > > Hi Michal, > > > > This seems to be a locking problem in __make_request, check_plug_merge() > > should be called with the q->queue_lock held. > > Could you try the following patch? It silenced the oops for me. > > Just back from travel... That is not correct, why do you think the queue > lock needs to be held there? The unprotected: check_plug_merge -> bio_attempt_back_merge -> ll_back_merge_fn -> q->last_merge = NULL made me think that. I don't know the code enough though. Regards, Frederik > > -- > Jens Axboe > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Michal Piotrowski napisał(a): > Hi Frederik, > > On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: >> Hi Michal, >> >> This seems to be a locking problem in __make_request, check_plug_merge() >> should be called with the q->queue_lock held. >> Could you try the following patch? It silenced the oops for me. > > For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [<6b6b6b6b>] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 note: ksmserver[20993] exited with preempt_count 2 BUG: sleeping function called from invalid context at /mnt/md0/devel/linux-mm/kernel/rwsem.c:20 in_atomic():1, irqs_disabled():1 no locks held by ksmserver/20993. irq event stamp: 0 hardirqs last enabled at (0): [<>] 0x0 hardirqs last disabled at (0): [] copy_process+0x539/0x137d softirqs last enabled at (0): [] copy_process+0x557/0x137d BUG: unable to handle kernel NULL pointer dereference at virtual address 0118 printing eip: c01f3f12 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210297 (2.6.20-mm2 #19) EIP is at blk_unplug_current+0x60/0x156 eax: f3f97298 ebx: 0001 ecx: c043db74 edx: esi: f3f97284 edi: ebp: dda39d94 esp: dda39d58 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process swriter.bin (pid: 20846, ti=dda38000 task=dda79510 task.ti=dda38000) Stack: dda79510 c03369fd dda79510 c03369fd dda39d90 f3f97298 c011e710 c7403fac 00200046 dda39d90 0001 c04abda0 06f75d80 dda39da8 c03339bb dda79f38 dda79f30 c7403f98 dda39db0 c0333a2f dda39db8 c015e380 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xac [] show_registers+0x1ed/0x34c [] die+0x11d/0x234 [] do_page_fault+0x47c/0x55b [] error_code+0x7c/0x84 [] io_schedule+0x3d/0x9a [] io_wait_schedule+0x17/0x1d [] sleep_on_page+0xa/0xc [] __wait_on_bit_lock+0x34/0x66 [] lock_page_blocking+0x2c/0x30 [] do_generic_mapping_read+0x29f/0x51a [] generic_file_aio_read+0x19a/0x1c8 [] do_sync_read+0xd7/0x114 [] vfs_read+0xcf/0x158 [] sys_read+0x3d/0x72 [] syscall_call+0x7/0xb === Code: 0b eb fe 8b 46 0c 48 89 46 0c 85 c0 0f 85 07 01 00 00 8b 7e 1c c7 46 1c 00 00 00 00 8d 46 14 89 45 e0 39 46 14 0f 84 d4 00 00 00 <8b> 87 18 01 00 00 e8 c0 26 14 00 c7 45 e4 00 00 00 00 8b 5e 14 EIP: [] blk_unplug_current+0x60/0x156 SS:ESP 0068:dda39d58 BUG: unable to handle kernel paging request at virtual address 6b6b6b6b printing eip: 6b6b6b6b *pde = Oops: [#2] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[<6b6b6b6b>]Not tainted VLI EFLAGS: 00210012 (2.6.20-mm2 #19) EIP is at 0x6b6b6b6b eax: dda79f38 ebx: dda79f38 ecx: edx: 0003 esi: 6b6b6b6b edi: 0001 ebp: f45f9c18 esp: f45f9bf8 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process ksmserver (pid: 20993, ti=f45f8000 task=f335b510 task.ti=f45f8000) Stack: c011b5e0 f45f9c44 0003 c7403f98 6b6b6b6b c7403f98 0001 00200292 f45f9c38 c011c3fb f45f9c44 0003 c7403f98 f7d71f4c f7d71f4c f45f9c50 c01353c3 f45f9c44 f7d71f4c 0002 0002 f45f9c60 c01353e0 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xac [] show_registers+0x1ed/0x34c [] die+0x11d/0x234 [] do_page_fault+0x47c/0x55b [] error_code+0x7c/0x84 [] __wake_up+0x31/0x42 [] __wake_up_bit+0x2e/0x34 [] wake_up_bit+0x17/0x1b [] unlock_buffer+0x12/0x14 [] do_get_write_access+0x185/0x657 [] journal_get_write_access+0x1b/0x2a [] __ext3_journal_get_write_access+0x19/0x3f [] ext3_reserve_inode_write+0x34/0x68 [] ext3_mark_inode_dirty+0x2a/0x41 [] ext3_dirty_inode+0x6a/0x7d [] __mark_inode_dirty+0x2a/0x16d [] touch_atime+0xc1/0xcb []
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Hi Frederik, On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q->queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Regards, Frederik Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Tue, Feb 20 2007, Frederik Deweerdt wrote: > On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: > > On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> > > >wrote: > > > > > >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > >> > Le 18.02.2007 06:51, Andrew Morton a ?crit : > > >> > >Temporarily at > > >> > > > > >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > >> > > > > >> > >Will appear later at > > >> > > > > >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > >> > > > >> > Hello, I've got a fully reproducible Oops. I just have to boot to > > >> > runlevel 2 and wait less than one minute. > > >> > > >> Maybe this oops is related too? > > > > > >Looks that way. > > > > Hi Michal, > > This seems to be a locking problem in __make_request, check_plug_merge() > should be called with the q->queue_lock held. > Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? I'll look into this tomorrow. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote:
> On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> >
> >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote:
> >> > Le 18.02.2007 06:51, Andrew Morton a �crit :
> >> > >Temporarily at
> >> > >
> >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> >> > >
> >> > >Will appear later at
> >> > >
> >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >> >
> >> > Hello, I've got a fully reproducible Oops. I just have to boot to
> >> > runlevel 2 and wait less than one minute.
> >>
> >> Maybe this oops is related too?
> >
> >Looks that way.
> >
Hi Michal,
This seems to be a locking problem in __make_request, check_plug_merge()
should be called with the q->queue_lock held.
Could you try the following patch? It silenced the oops for me.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 577f448..666f34e 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
blk_queue_bounce(q, );
+ spin_lock_irq(q->queue_lock);
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
if (!check_plug_merge(q, ioc, bio))
- goto out;
+ goto out_unlock;
- spin_lock_irq(q->queue_lock);
el_ret = elv_merge(q, , bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(>queuelist, >plugged_list);
}
-out:
return 0;
end_io_eopnotsupp:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On 19/02/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: On Monday, 19 February 2007 01:00, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > netconsole is good. > > > > I know. :-) > > > > In the meantime, I've got something worse on another x86_64 box: > > > > Asus Laptop ACPI Extras version 0.30 > > L5D model detected, supported > > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > > general protection fault: [2] PREEMPT > > last sysfs file: /class/net/eth2/carrier > > CPU 0 > > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > > RIP: 0010:[] [] __make_request+0x134/0x370 > > RSP: :81005ed659a0 EFLAGS: 00010297 > > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > > R10: R11: R12: 810037b4dbb0 > > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > > FS: 2ad4a29e6d00() GS:805db000() knlGS: > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > > Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) > > Stack: 810002852540 0001 810037b4dbb0 8026be21 > > 81005ed65a40 0008 810037b4dbb0 0800 > > 0008 8100021d94e0 81005ed65a40 80348e7c > > Call Trace: > > [] mempool_alloc_slab+0x11/0x20 > > [] generic_make_request+0x1ec/0x230 > > yeah. everyone except me is hitting that. FWIW, I don't see it on an SMP machine. I can reproduce this on my SMT P4. CONFIG_SMP=y CONFIG_X86_PC=y CONFIG_MPENTIUM4=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: compilation fix
On Monday, 19 February 2007 01:29, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:33:26 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > I think something like this is generally necessary: > > > > --- > > drivers/pci/quirks.c |1 + > > 1 file changed, 1 insertion(+) > > > > Index: linux-2.6.20-mm2/drivers/pci/quirks.c > > === > > --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c > > +++ linux-2.6.20-mm2/drivers/pci/quirks.c > > @@ -21,6 +21,7 @@ > > #include > > #include > > #include > > +#include > > #include "pci.h" > > > > /* The Mellanox Tavor device gives false positive parity errors > > Will break all non-x86. You're right, I should have put that somewhere under #ifdef > What are we trying to fix here? MAX_IO_APICS undefined. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:00, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > > netconsole is good. > > > > I know. :-) > > > > In the meantime, I've got something worse on another x86_64 box: > > > > Asus Laptop ACPI Extras version 0.30 > > L5D model detected, supported > > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > > general protection fault: [2] PREEMPT > > last sysfs file: /class/net/eth2/carrier > > CPU 0 > > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > > RIP: 0010:[] [] > > __make_request+0x134/0x370 > > RSP: :81005ed659a0 EFLAGS: 00010297 > > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > > R10: R11: R12: 810037b4dbb0 > > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > > FS: 2ad4a29e6d00() GS:805db000() knlGS: > > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > > Process pdflush (pid: 178, threadinfo 81005ed64000, task > > 810037b060c0) > > Stack: 810002852540 0001 810037b4dbb0 8026be21 > > 81005ed65a40 0008 810037b4dbb0 0800 > > 0008 8100021d94e0 81005ed65a40 80348e7c > > Call Trace: > > [] mempool_alloc_slab+0x11/0x20 > > [] generic_make_request+0x1ec/0x230 > > yeah. everyone except me is hitting that. FWIW, I don't see it on an SMP machine. On non-SMP it's reproducible, eg. by doing # echo testproc > /sys/power/disk and # echo disk > /sys/power/state for 3-4 times in a row. Probably "sync" for a couple of times in a row would be sufficient. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: compilation fix
On Monday, 19 February 2007 01:29, Andrew Morton wrote: On Mon, 19 Feb 2007 00:33:26 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ I think something like this is generally necessary: --- drivers/pci/quirks.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.20-mm2/drivers/pci/quirks.c === --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c +++ linux-2.6.20-mm2/drivers/pci/quirks.c @@ -21,6 +21,7 @@ #include linux/init.h #include linux/delay.h #include linux/acpi.h +#include asm/apicdef.h #include pci.h /* The Mellanox Tavor device gives false positive parity errors Will break all non-x86. You're right, I should have put that somewhere under #ifdef What are we trying to fix here? MAX_IO_APICS undefined. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:00, Andrew Morton wrote: On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: netconsole is good. I know. :-) In the meantime, I've got something worse on another x86_64 box: Asus Laptop ACPI Extras version 0.30 L5D model detected, supported audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 general protection fault: [2] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370 RSP: :81005ed659a0 EFLAGS: 00010297 RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 R10: R11: R12: 810037b4dbb0 R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 FS: 2ad4a29e6d00() GS:805db000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) Stack: 810002852540 0001 810037b4dbb0 8026be21 81005ed65a40 0008 810037b4dbb0 0800 0008 8100021d94e0 81005ed65a40 80348e7c Call Trace: [8026be21] mempool_alloc_slab+0x11/0x20 [80348e7c] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. FWIW, I don't see it on an SMP machine. On non-SMP it's reproducible, eg. by doing # echo testproc /sys/power/disk and # echo disk /sys/power/state for 3-4 times in a row. Probably sync for a couple of times in a row would be sufficient. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 February 2007 01:00, Andrew Morton wrote: On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: netconsole is good. I know. :-) In the meantime, I've got something worse on another x86_64 box: Asus Laptop ACPI Extras version 0.30 L5D model detected, supported audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 general protection fault: [2] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370 RSP: :81005ed659a0 EFLAGS: 00010297 RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 R10: R11: R12: 810037b4dbb0 R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 FS: 2ad4a29e6d00() GS:805db000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) Stack: 810002852540 0001 810037b4dbb0 8026be21 81005ed65a40 0008 810037b4dbb0 0800 0008 8100021d94e0 81005ed65a40 80348e7c Call Trace: [8026be21] mempool_alloc_slab+0x11/0x20 [80348e7c] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. FWIW, I don't see it on an SMP machine. I can reproduce this on my SMT P4. CONFIG_SMP=y CONFIG_X86_PC=y CONFIG_MPENTIUM4=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote:
On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote:
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote:
Le 18.02.2007 06:51, Andrew Morton a �crit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Hello, I've got a fully reproducible Oops. I just have to boot to
runlevel 2 and wait less than one minute.
Maybe this oops is related too?
Looks that way.
Hi Michal,
This seems to be a locking problem in __make_request, check_plug_merge()
should be called with the q-queue_lock held.
Could you try the following patch? It silenced the oops for me.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 577f448..666f34e 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
blk_queue_bounce(q, bio);
+ spin_lock_irq(q-queue_lock);
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
if (!check_plug_merge(q, ioc, bio))
- goto out;
+ goto out_unlock;
- spin_lock_irq(q-queue_lock);
el_ret = elv_merge(q, req, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(req-queuelist, ioc-plugged_list);
}
-out:
return 0;
end_io_eopnotsupp:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Tue, Feb 20 2007, Frederik Deweerdt wrote: On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a ?crit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? I'll look into this tomorrow. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Regards, Frederik Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Michal Piotrowski napisał(a): Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [6b6b6b6b] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 note: ksmserver[20993] exited with preempt_count 2 BUG: sleeping function called from invalid context at /mnt/md0/devel/linux-mm/kernel/rwsem.c:20 in_atomic():1, irqs_disabled():1 no locks held by ksmserver/20993. irq event stamp: 0 hardirqs last enabled at (0): [] 0x0 hardirqs last disabled at (0): [c0121bc6] copy_process+0x539/0x137d softirqs last enabled at (0): [c0121be4] copy_process+0x557/0x137d BUG: unable to handle kernel NULL pointer dereference at virtual address 0118 printing eip: c01f3f12 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[c01f3f12]Not tainted VLI EFLAGS: 00210297 (2.6.20-mm2 #19) EIP is at blk_unplug_current+0x60/0x156 eax: f3f97298 ebx: 0001 ecx: c043db74 edx: esi: f3f97284 edi: ebp: dda39d94 esp: dda39d58 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process swriter.bin (pid: 20846, ti=dda38000 task=dda79510 task.ti=dda38000) Stack: dda79510 c03369fd dda79510 c03369fd dda39d90 f3f97298 c011e710 c7403fac 00200046 dda39d90 0001 c04abda0 06f75d80 dda39da8 c03339bb dda79f38 dda79f30 c7403f98 dda39db0 c0333a2f dda39db8 c015e380 Call Trace: [c0105312] show_trace_log_lvl+0x1a/0x2f [c01053c4] show_stack_log_lvl+0x9d/0xac [c01055c0] show_registers+0x1ed/0x34c [c010583c] die+0x11d/0x234 [c011a8e1] do_page_fault+0x47c/0x55b [c0336d54] error_code+0x7c/0x84 [c03339bb] io_schedule+0x3d/0x9a [c0333a2f] io_wait_schedule+0x17/0x1d [c015e380] sleep_on_page+0xa/0xc [c0334217] __wait_on_bit_lock+0x34/0x66 [c015e372] lock_page_blocking+0x2c/0x30 [c015ebe2] do_generic_mapping_read+0x29f/0x51a [c0160daa] generic_file_aio_read+0x19a/0x1c8 [c017f300] do_sync_read+0xd7/0x114 [c017fc2a] vfs_read+0xcf/0x158 [c0180090] sys_read+0x3d/0x72 [c010432c] syscall_call+0x7/0xb === Code: 0b eb fe 8b 46 0c 48 89 46 0c 85 c0 0f 85 07 01 00 00 8b 7e 1c c7 46 1c 00 00 00 00 8d 46 14 89 45 e0 39 46 14 0f 84 d4 00 00 00 8b 87 18 01 00 00 e8 c0 26 14 00 c7 45 e4 00 00 00 00 8b 5e 14 EIP: [c01f3f12] blk_unplug_current+0x60/0x156 SS:ESP 0068:dda39d58 BUG: unable to handle kernel paging request at virtual address 6b6b6b6b printing eip: 6b6b6b6b *pde = Oops: [#2] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[6b6b6b6b]Not tainted VLI EFLAGS: 00210012 (2.6.20-mm2 #19) EIP is at 0x6b6b6b6b eax: dda79f38 ebx: dda79f38 ecx: edx: 0003 esi: 6b6b6b6b edi: 0001 ebp: f45f9c18 esp: f45f9bf8 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process ksmserver (pid: 20993, ti=f45f8000 task=f335b510 task.ti=f45f8000) Stack: c011b5e0 f45f9c44 0003 c7403f98 6b6b6b6b c7403f98 0001 00200292 f45f9c38 c011c3fb f45f9c44 0003 c7403f98 f7d71f4c f7d71f4c f45f9c50 c01353c3 f45f9c44 f7d71f4c 0002 0002 f45f9c60 c01353e0 Call Trace: [c0105312] show_trace_log_lvl+0x1a/0x2f [c01053c4] show_stack_log_lvl+0x9d/0xac [c01055c0] show_registers+0x1ed/0x34c [c010583c] die+0x11d/0x234 [c011a8e1] do_page_fault+0x47c/0x55b [c0336d54] error_code+0x7c/0x84 [c011c3fb] __wake_up+0x31/0x42 [c01353c3] __wake_up_bit+0x2e/0x34 [c01353e0] wake_up_bit+0x17/0x1b [c019ecbf] unlock_buffer+0x12/0x14 [c01ccad4] do_get_write_access+0x185/0x657 [c01ccfc1]
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 02:34:53PM +0100, Jens Axboe wrote: On Tue, Feb 20 2007, Frederik Deweerdt wrote: On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a ?crit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? The unprotected: check_plug_merge - bio_attempt_back_merge - ll_back_merge_fn - q-last_merge = NULL made me think that. I don't know the code enough though. Regards, Frederik -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 03:08:03PM +0100, Michal Piotrowski wrote: Michal Piotrowski napisał(a): Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [6b6b6b6b] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 :) It may not be related though. I think that my patch avoids the BUG_ON(!rq_mergeable(req)); in ll_rw_blk.c:2782. This looks like another beast to me. Regards, Frederik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, Feb 18 2007, Andrew Morton wrote: On Sun, 18 Feb 2007 14:35:17 -0800 Andrew Morton [EMAIL PROTECTED] wrote: I guess I need to do a git-blockless -mm3 OK, this is looking like a pain - I'd have to drop or significantly redo thirty or more patches. Jens, please fix it asap. Will get on it, I wonder what on earth broke this time :( This plugging stuff will really have to show some merrit in the performance arena, otherwise it'll go out again soon. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:28, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
One more thing:
rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
Unable to handle kernel NULL pointer dereference at 0030 RIP:
[804032c3] rtc_sysfs_remove_device+0x23/0x50
PGD 5e10c067 PUD 5dd58067 PMD 0
Oops: [1] PREEMPT
last sysfs file: /devices/pnp0/00:04/id
CPU 0
Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus
snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc
ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor
Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1
RIP: 0010:[804032c3] [804032c3]
rtc_sysfs_remove_device+0x23/0x50
RSP: 0018:81005e3f9c18 EFLAGS: 00010202
RAX: RBX: 81005dabeea0 RCX:
RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0
RBP: 81005e3f9c28 R08: 0001 R09:
R10: R11: R12: 81005dabeea0
R13: 810002890258 R14: 810002890268 R15: 810002890098
FS: 2ac610b906f0() GS:805db000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0030 CR3: 5e16d000 CR4: 06e0
Process modprobe (pid: 2960, threadinfo 81005e3f8000, task
81005e6a7140)
Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786
81005dabeea0 81005dabf008 0008
81005fe244e8 0008 81005e3f9c88 803c5891
Call Trace:
[803c5786] class_device_del+0x86/0x180
[803c5891] class_device_unregister+0x11/0x20
[8040280e] rtc_device_unregister+0x3e/0x50
[880cd789] :rtc_cmos:cmos_pnp_probe+0x219/0x240
[803988a1] pnp_device_probe+0xa1/0xe0
[803c4d20] __driver_attach+0x0/0xa0
[803c4bb5] driver_probe_device+0x115/0x1c0
[803c4d20] __driver_attach+0x0/0xa0
[803c4d83] __driver_attach+0x63/0xa0
[803c3e1f] bus_for_each_dev+0x4f/0x80
[803c497c] driver_attach+0x1c/0x20
[803c4233] bus_add_driver+0x83/0x1d0
[803c50d9] driver_register+0x89/0x90
[803985cc] pnp_register_driver+0x1c/0x20
[880d1010] :rtc_cmos:cmos_init+0x10/0x12
[8025199b] sys_init_module+0x158b/0x16f0
[802d09da] dnotify_parent+0x7a/0x90
[80268b80] file_read_actor+0x0/0x170
[80209a0e] system_call+0x7e/0x83
Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48
RIP [804032c3] rtc_sysfs_remove_device+0x23/0x50
RSP 81005e3f9c18
CR2: 0030
How did you provoke that? modprobe rtc-cmos?
I've just booted OpenSUSE 10.2 with this kernel.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 12:45, Michal Piotrowski wrote:
On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 19 February 2007 01:00, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL
PROTECTED] wrote:
netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[8034bce4] [8034bce4]
__make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000()
knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task
810037b060c0)
Stack: 810002852540 0001 810037b4dbb0
8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[8026be21] mempool_alloc_slab+0x11/0x20
[80348e7c] generic_make_request+0x1ec/0x230
yeah. everyone except me is hitting that.
FWIW, I don't see it on an SMP machine.
I can reproduce this on my SMT P4.
CONFIG_SMP=y
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_NR_CPUS=2
CONFIG_SCHED_SMT=y
It may be related to preemption. The box I'm not seeing it on runs a
non-preemptible kernel (CONFIG_PREEMPT_VOLUNTARY is set).
BTW, on the box where I'm able to reproduce it, I have
(gdb) l *__make_request+0x134
0x8034b764 is in __make_request (include/asm/processor.h:411).
406 #define cpu_has_fpu 1
407
408 #define ARCH_HAS_PREFETCH
409 static inline void prefetch(void *x)
410 {
411 asm volatile(prefetcht0 %0 :: m (*(unsigned long *)x));
412 }
413
414 #define ARCH_HAS_PREFETCHW 1
415 static inline void prefetchw(void *x)
So I guess x is NULL somewhere ...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Monday, 19 February 2007 01:00, Andrew Morton wrote: On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: netconsole is good. I know. :-) In the meantime, I've got something worse on another x86_64 box: Asus Laptop ACPI Extras version 0.30 L5D model detected, supported audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 general protection fault: [2] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370 RSP: :81005ed659a0 EFLAGS: 00010297 RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 R10: R11: R12: 810037b4dbb0 R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 FS: 2ad4a29e6d00() GS:805db000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) Stack: 810002852540 0001 810037b4dbb0 8026be21 81005ed65a40 0008 810037b4dbb0 0800 0008 8100021d94e0 81005ed65a40 80348e7c Call Trace: [8026be21] mempool_alloc_slab+0x11/0x20 [80348e7c] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. An interesting variant: [ cut here ] kernel BUG at block/ll_rw_blk.c:2782! invalid opcode: [1] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod usbhid pcmcir Pid: 5060, comm: preload Not tainted 2.6.20-mm2 #4 RIP: 0010:[80349b7a] [80349b7a] bio_attempt_back_merge+0x2a/0xa0 RSP: 0018:810045819a58 EFLAGS: 00010202 RAX: 00010080 RBX: 810046946eb0 RCX: 02b26b42 RDX: 0001 RSI: 810046946eb0 RDI: 810037d74a90 RBP: 810045819a68 R08: 810046946eb0 R09: 0400 R10: R11: R12: 810046fcc330 R13: 81004a218770 R14: 810037d74a90 R15: 81004a218750 FS: 2acb9c6076f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2aaac000 CR3: 45855000 CR4: 06e0 Process preload (pid: 5060, threadinfo 810045818000, task 81004a12e140) Stack: 810046946eb0 810046fcc330 810045819ac8 8034b730 810046fcc330 0002 810046946eb0 0008 810046fcc330 0800 Call Trace: [8034b730] __make_request+0x100/0x370 [803488fc] generic_make_request+0x1ec/0x230 [802b9a7b] bio_alloc_bioset+0xeb/0x120 [8034b266] submit_bio+0xf6/0x110 [802b9b10] bio_alloc+0x10/0x20 [802bd3f2] mpage_bio_submit+0x22/0x30 [802bdfe5] do_mpage_readpage+0x505/0x590 [80482cd6] _write_unlock_irq+0x36/0x60 [80268bfb] add_to_page_cache+0xbb/0xf0 [8026d950] get_page_from_freelist+0x120/0x430 [802be2be] mpage_readpages+0xbe/0x160 [8030fa20] ext3_get_block+0x0/0x110 [8030fa20] ext3_get_block+0x0/0x110 [804833b0] _spin_unlock+0x30/0x50 [8026da50] get_page_from_freelist+0x220/0x430 [8030eb8a] ext3_readpages+0x1a/0x20 [8027072f] __do_page_cache_readahead+0x20f/0x330 [80294d68] cp_new_stat+0xf8/0x120 [80270c7d] force_page_cache_readahead+0x6d/0xb0 [8026c533] sys_fadvise64_64+0x143/0x1e0 [8026c5d9] sys_fadvise64+0x9/0x10 [80209a0e] system_call+0x7e/0x83 Code: 0f 0b 0f 1f 40 00 eb fe 4c 89 e2 e8 f6 df ff ff 31 d2 85 c0 RIP [80349b7a] bio_attempt_back_merge+0x2a/0xa0 RSP 810045819a58 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 20:43, Andrew Morton wrote: On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Two problems: 1) A showstopper with the root partition on RAID1: md: raid1 personality registered for level 1 [--snip--] md: multipath personality registered for level -4 register_blkdev: failed to get major for mdp [--snip--] VFS: Cannot open root device md1 or unknown-block(0,0) Someone else reported that against mainline. Can you please debug it a bit? For now I can only say 2.6.20 + origin.patch breaks. However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason. I'll check that tomorrow. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Tue, 20 Feb 2007 02:20:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Two problems:
1) A showstopper with the root partition on RAID1:
md: raid1 personality registered for level 1
[--snip--]
md: multipath personality registered for level -4
register_blkdev: failed to get major for mdp
[--snip--]
VFS: Cannot open root device md1 or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
For now I can only say 2.6.20 + origin.patch breaks.
However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason.
I'll check that tomorrow.
Yes, Rolf says this goes away when you stop using gcc-4.1.0.
I'm hoping that churning the code around like below makes things work
right.
From: Andrew Morton [EMAIL PROTECTED]
Several people have reported failures in dynamic major device number handling
due to the recent changes in there to avoid handing out the local/experimental
majors.
Rolf reports that this is due to a gcc-4.1.0 bug.
The patch refactors that code a lot in an attempt to provoke the compiler into
behaving.
Cc: Rolf Eike Beer [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
block/genhd.c |9 ++---
drivers/base/core.c| 14 ++
fs/char_dev.c |8 ++--
include/linux/kdev_t.h |1 +
4 files changed, 19 insertions(+), 13 deletions(-)
diff -puN block/genhd.c~rework-reserved-major-handling block/genhd.c
--- a/block/genhd.c~rework-reserved-major-handling
+++ a/block/genhd.c
@@ -5,6 +5,7 @@
#include linux/module.h
#include linux/fs.h
#include linux/genhd.h
+#include linux/kdev_t.h
#include linux/kernel.h
#include linux/blkdev.h
#include linux/init.h
@@ -61,13 +62,7 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 = index index = 63) ||
- (120 = index index = 127) ||
- (240 = index index = 254))
+ if (is_lanana_major(index))
continue;
if (major_names[index] == NULL)
break;
diff -puN fs/char_dev.c~rework-reserved-major-handling fs/char_dev.c
--- a/fs/char_dev.c~rework-reserved-major-handling
+++ a/fs/char_dev.c
@@ -6,6 +6,7 @@
#include linux/init.h
#include linux/fs.h
+#include linux/kdev_t.h
#include linux/slab.h
#include linux/string.h
@@ -108,12 +109,7 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i 0; i--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 = i i = 63) || (120 = i i = 127) ||
- (240 = i i = 254))
+ if (is_lanana_major(i))
continue;
if (chrdevs[i] == NULL)
break;
diff -puN drivers/base/core.c~rework-reserved-major-handling drivers/base/core.c
--- a/drivers/base/core.c~rework-reserved-major-handling
+++ a/drivers/base/core.c
@@ -28,6 +28,20 @@ int (*platform_notify)(struct device * d
int (*platform_notify_remove)(struct device * dev) = NULL;
/*
+ * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
+ */
+bool is_lanana_major(unsigned int major)
+{
+ if (major = 60 major = 63)
+ return 1;
+ if (major = 120 major = 127)
+ return 1;
+ if (major = 240 major = 254)
+ return 1;
+ return 0;
+}
+
+/*
* sysfs bindings for devices.
*/
diff -puN include/linux/kdev_t.h~rework-reserved-major-handling
include/linux/kdev_t.h
--- a/include/linux/kdev_t.h~rework-reserved-major-handling
+++ a/include/linux/kdev_t.h
@@ -87,6 +87,7 @@ static inline unsigned sysv_minor(u32 de
return dev 0x3;
}
+bool is_lanana_major(unsigned int major);
#else /* __KERNEL__ */
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: 2.6.20-mm2
On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > One more thing: > > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > Unable to handle kernel NULL pointer dereference at 0030 RIP: > > [] rtc_sysfs_remove_device+0x23/0x50 > > ... > > Call Trace: > > [] class_device_del+0x86/0x180 > > [] class_device_unregister+0x11/0x20 > > [] rtc_device_unregister+0x3e/0x50 > > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > > [] pnp_device_probe+0xa1/0xe0 > > ... > > How did you provoke that? modprobe rtc-cmos? Plus, I'd guess, the old rtc driver statically linked. What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > One more thing: > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > Unable to handle kernel NULL pointer dereference at 0030 RIP: > [] rtc_sysfs_remove_device+0x23/0x50 > PGD 5e10c067 PUD 5dd58067 PMD 0 > Oops: [1] PREEMPT > last sysfs file: /devices/pnp0/00:04/id > CPU 0 > Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus > snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd > ehci_hcd evdev parport_pc lp parport fan thermal processor > Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 > RIP: 0010:[] [] > rtc_sysfs_remove_device+0x23/0x50 > RSP: 0018:81005e3f9c18 EFLAGS: 00010202 > RAX: RBX: 81005dabeea0 RCX: > RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 > RBP: 81005e3f9c28 R08: 0001 R09: > R10: R11: R12: 81005dabeea0 > R13: 810002890258 R14: 810002890268 R15: 810002890098 > FS: 2ac610b906f0() GS:805db000() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 0030 CR3: 5e16d000 CR4: 06e0 > Process modprobe (pid: 2960, threadinfo 81005e3f8000, task > 81005e6a7140) > Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 > 81005dabeea0 81005dabf008 0008 > 81005fe244e8 0008 81005e3f9c88 803c5891 > Call Trace: > [] class_device_del+0x86/0x180 > [] class_device_unregister+0x11/0x20 > [] rtc_device_unregister+0x3e/0x50 > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > [] pnp_device_probe+0xa1/0xe0 > [] __driver_attach+0x0/0xa0 > [] driver_probe_device+0x115/0x1c0 > [] __driver_attach+0x0/0xa0 > [] __driver_attach+0x63/0xa0 > [] bus_for_each_dev+0x4f/0x80 > [] driver_attach+0x1c/0x20 > [] bus_add_driver+0x83/0x1d0 > [] driver_register+0x89/0x90 > [] pnp_register_driver+0x1c/0x20 > [] :rtc_cmos:cmos_init+0x10/0x12 > [] sys_init_module+0x158b/0x16f0 > [] dnotify_parent+0x7a/0x90 > [] file_read_actor+0x0/0x170 > [] system_call+0x7e/0x83 > > > Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 > RIP [] rtc_sysfs_remove_device+0x23/0x50 > RSP > CR2: 0030 How did you provoke that? modprobe rtc-cmos? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: compilation fix
On Mon, 19 Feb 2007 00:33:26 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > I think something like this is generally necessary: > > --- > drivers/pci/quirks.c |1 + > 1 file changed, 1 insertion(+) > > Index: linux-2.6.20-mm2/drivers/pci/quirks.c > === > --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c > +++ linux-2.6.20-mm2/drivers/pci/quirks.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include "pci.h" > > /* The Mellanox Tavor device gives false positive parity errors Will break all non-x86. What are we trying to fix here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > netconsole is good. > > I know. :-) > > In the meantime, I've got something worse on another x86_64 box: > > Asus Laptop ACPI Extras version 0.30 > L5D model detected, supported > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > general protection fault: [2] PREEMPT > last sysfs file: /class/net/eth2/carrier > CPU 0 > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > RIP: 0010:[] [] > __make_request+0x134/0x370 > RSP: :81005ed659a0 EFLAGS: 00010297 > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > R10: R11: R12: 810037b4dbb0 > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > FS: 2ad4a29e6d00() GS:805db000() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) > Stack: 810002852540 0001 810037b4dbb0 8026be21 > 81005ed65a40 0008 810037b4dbb0 0800 > 0008 8100021d94e0 81005ed65a40 80348e7c > Call Trace: > [] mempool_alloc_slab+0x11/0x20 > [] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On 19/02/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
>
> > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > >
> > > Temporarily at
> > >
> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > >
> > > Will appear later at
> > >
> > >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >
> > Two problems:
> >
> > 1) A showstopper with the root partition on RAID1:
> >
> > md: raid1 personality registered for level 1
> > [--snip--]
> > md: multipath personality registered for level -4
> > register_blkdev: failed to get major for mdp
> > [--snip--]
> > VFS: Cannot open root device "md1" or unknown-block(0,0)
>
> Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
> I'd suggested reverting the recent changes in there:
>
> --- a/block/genhd.c~a
> +++ a/block/genhd.c
> @@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
> /* temporary */
> if (major == 0) {
> for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
> - /*
> - * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
> - * majors
> - */
> - if ((60 <= index && index <= 63) ||
> - (120 <= index && index <= 127) ||
> - (240 <= index && index <= 254))
> - continue;
> if (major_names[index] == NULL)
> break;
> }
> _
>
> but I don't see how they could cause this.
>
>
> > At the moment I have no serial console attached to the box, so I had to
rewrite
> > the messages manually.
>
> netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[] [] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[] mempool_alloc_slab+0x11/0x20
[] generic_make_request+0x1ec/0x230
[] submit_bio+0xf6/0x110
[] submit_bh+0x100/0x130
[] __block_write_full_page+0x1ca/0x2e0
[] blkdev_get_block+0x0/0x70
[] blkdev_get_block+0x0/0x70
[] block_write_full_page+0xf3/0x110
[] blkdev_writepage+0x13/0x20
[] __writepage+0x15/0x40
[] write_cache_pages+0x1f3/0x360
[] __writepage+0x0/0x40
[] generic_writepages+0x22/0x30
[] do_writepages+0x46/0x80
[] __writeback_single_inode+0x1d7/0x370
[] generic_sync_sb_inodes+0x35/0x2b0
[] generic_sync_sb_inodes+0x1d9/0x2b0
[] writeback_inodes+0x82/0x100
[] sync_sb_inodes+0x25/0x30
[] writeback_inodes+0x98/0x100
[] pdflush+0x0/0x1e0
[] wb_kupdate+0x94/0x110
[] pdflush+0x128/0x1e0
[] wb_kupdate+0x0/0x110
[] pdflush+0x0/0x1e0
[] kthread+0xd3/0x110
[] keventd_create_kthread+0x0/0x90
[] child_rip+0xa/0x12
[] _spin_unlock_irq+0x2b/0x60
[] restore_args+0x0/0x30
[] kthread+0x0/0x110
[] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [] __make_request+0x134/0x370
RSP
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
It looks familiar to me
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0646.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0821.html
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: 2.6.20-mm2: compilation fix
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ I think something like this is generally necessary: --- drivers/pci/quirks.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.20-mm2/drivers/pci/quirks.c === --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c +++ linux-2.6.20-mm2/drivers/pci/quirks.c @@ -21,6 +21,7 @@ #include #include #include +#include #include "pci.h" /* The Mellanox Tavor device gives false positive parity errors - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [] rtc_sysfs_remove_device+0x23/0x50 PGD 5e10c067 PUD 5dd58067 PMD 0 Oops: [1] PREEMPT last sysfs file: /devices/pnp0/00:04/id CPU 0 Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 RIP: 0010:[] [] rtc_sysfs_remove_device+0x23/0x50 RSP: 0018:81005e3f9c18 EFLAGS: 00010202 RAX: RBX: 81005dabeea0 RCX: RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 RBP: 81005e3f9c28 R08: 0001 R09: R10: R11: R12: 81005dabeea0 R13: 810002890258 R14: 810002890268 R15: 810002890098 FS: 2ac610b906f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0030 CR3: 5e16d000 CR4: 06e0 Process modprobe (pid: 2960, threadinfo 81005e3f8000, task 81005e6a7140) Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 81005dabeea0 81005dabf008 0008 81005fe244e8 0008 81005e3f9c88 803c5891 Call Trace: [] class_device_del+0x86/0x180 [] class_device_unregister+0x11/0x20 [] rtc_device_unregister+0x3e/0x50 [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [] pnp_device_probe+0xa1/0xe0 [] __driver_attach+0x0/0xa0 [] driver_probe_device+0x115/0x1c0 [] __driver_attach+0x0/0xa0 [] __driver_attach+0x63/0xa0 [] bus_for_each_dev+0x4f/0x80 [] driver_attach+0x1c/0x20 [] bus_add_driver+0x83/0x1d0 [] driver_register+0x89/0x90 [] pnp_register_driver+0x1c/0x20 [] :rtc_cmos:cmos_init+0x10/0x12 [] sys_init_module+0x158b/0x16f0 [] dnotify_parent+0x7a/0x90 [] file_read_actor+0x0/0x170 [] system_call+0x7e/0x83 Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 RIP [] rtc_sysfs_remove_device+0x23/0x50 RSP CR2: 0030 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > >
> > > Temporarily at
> > >
> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > >
> > > Will appear later at
> > >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >
> > Two problems:
> >
> > 1) A showstopper with the root partition on RAID1:
> >
> > md: raid1 personality registered for level 1
> > [--snip--]
> > md: multipath personality registered for level -4
> > register_blkdev: failed to get major for mdp
> > [--snip--]
> > VFS: Cannot open root device "md1" or unknown-block(0,0)
>
> Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
> I'd suggested reverting the recent changes in there:
>
> --- a/block/genhd.c~a
> +++ a/block/genhd.c
> @@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
> /* temporary */
> if (major == 0) {
> for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
> - /*
> - * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
> - * majors
> - */
> - if ((60 <= index && index <= 63) ||
> - (120 <= index && index <= 127) ||
> - (240 <= index && index <= 254))
> - continue;
> if (major_names[index] == NULL)
> break;
> }
> _
>
> but I don't see how they could cause this.
>
>
> > At the moment I have no serial console attached to the box, so I had to
> > rewrite
> > the messages manually.
>
> netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[] [] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[] mempool_alloc_slab+0x11/0x20
[] generic_make_request+0x1ec/0x230
[] submit_bio+0xf6/0x110
[] submit_bh+0x100/0x130
[] __block_write_full_page+0x1ca/0x2e0
[] blkdev_get_block+0x0/0x70
[] blkdev_get_block+0x0/0x70
[] block_write_full_page+0xf3/0x110
[] blkdev_writepage+0x13/0x20
[] __writepage+0x15/0x40
[] write_cache_pages+0x1f3/0x360
[] __writepage+0x0/0x40
[] generic_writepages+0x22/0x30
[] do_writepages+0x46/0x80
[] __writeback_single_inode+0x1d7/0x370
[] generic_sync_sb_inodes+0x35/0x2b0
[] generic_sync_sb_inodes+0x1d9/0x2b0
[] writeback_inodes+0x82/0x100
[] sync_sb_inodes+0x25/0x30
[] writeback_inodes+0x98/0x100
[] pdflush+0x0/0x1e0
[] wb_kupdate+0x94/0x110
[] pdflush+0x128/0x1e0
[] wb_kupdate+0x0/0x110
[] pdflush+0x0/0x1e0
[] kthread+0xd3/0x110
[] keventd_create_kthread+0x0/0x90
[] child_rip+0xa/0x12
[] _spin_unlock_irq+0x2b/0x60
[] restore_args+0x0/0x30
[] kthread+0x0/0x110
[] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [] __make_request+0x134/0x370
RSP
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
> > 2) On HPC nx6325 I get the following 100% of the time during the resume from
> > disk:
> >
> > BUG: at drivers/pci/pci.c:823 pcim_enable_device()
> >
> > Call Trace:
> > [] pcim_enable_device+0x93/0xb3
> > [] ata_pci_device_do_resume+0x21/0x5e
> > [] sil_pci_device_resume+0x1c/0x51
> > [] pci_device_resume+0x22/0x53
> > [] resume_device+0xca/0x131
> > [] dpm_resume+0x81/0xd3
> > [] device_resume+0x30/0x45
> > [] snapshot_ioctl+0x245/0x63e
> > [] do_ioctl+0x5e/0x77
> > [] vfs_ioctl+0x25c/0x279
> > [] sys_ioctl+0x5f/0x82
> >
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 14:35:17 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > I guess I need to do a git-blockless -mm3 OK, this is looking like a pain - I'd have to drop or significantly redo thirty or more patches. Jens, please fix it asap. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 13:47:44 -0800 "Miles Lane" <[EMAIL PROTECTED]> wrote: > It looks like there are some slight differences between the stack traces I > have and the ones that have already been posted. > I hope this helps, > Miles > > psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing > 1 bytes away. > BUG: unable to handle kernel paging request at virtual address 6b6b6b6f > printing eip: > c01f238c > *pde = > Oops: [#1] > PREEMPT SMP > last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > Modules linked in: ieee80211_crypt_wep binfmt_misc rfcomm l2cap bluetooth > ipv6 capability commoncap apm i915 drm acpi_cpufreq cpufreq_powersave > cpufreq_performance cpufreq_conservative video dock container button battery > ac nls_ascii nls_cp437 vfat fat nls_base fuse sbp2 parport_pc lp parport > pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss > snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi > snd_seq_midi_event snd_seq snd_timer snd_seq_device sdhci mmc_core tifm_7xx1 > tifm_core yenta_socket rsrc_nonstatic pcmcia_core snd soundcore ipw2200 > ieee80211 ieee80211_crypt firmware_class rtc snd_page_alloc iTCO_wdt > iTCO_vendor_support shpchp pci_hotplug sg sr_mod cdrom sd_mod ohci1394 > ieee1394 8139too mii ehci_hcd uhci_hcd usbcore thermal processor fan unix > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00210297 (2.6.20-mm2 #13) > EIP is at __make_request+0xeb/0x2ee Looks fairly similar. I guess I need to do a git-blockless -mm3 :( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > >Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > >Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > runlevel 2 and wait less than one minute. > > Maybe this oops is related too? Looks that way. > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 > printing eip: > c02206aa > *pde = > Oops: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:00.0/class > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > EIP is at __make_request+0x13a/0x390 > eax: ebx: ecx: 042b0dd8 edx: 00010485 > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xa9/0xd0 > [] show_registers+0x206/0x350 > [] die+0x10e/0x210 > [] do_page_fault+0x2d2/0x600 > [] error_code+0x74/0x7c > [] generic_make_request+0x15a/0x200 > [] submit_bio+0x58/0xe0 > [] metapage_writepage+0x18f/0x1b0 > [] __writepage+0xb/0x30 > [] write_cache_pages+0x22f/0x300 > [] generic_writepages+0x23/0x30 > [] do_writepages+0x5c/0x60 > [] __filemap_fdatawrite_range+0x67/0x80 > [] filemap_flush+0x25/0x30 > [] lmLogSync+0x19d/0x230 > [] lmLog+0x5e/0x190 > [] txCommit+0x8c0/0x1010 > [] jfs_create+0x324/0x370 > [] vfs_create+0xaf/0x100 > [] open_namei+0x58c/0x640 > [] do_filp_open+0x2c/0x50 > [] do_sys_open+0x47/0xe0 > [] sys_open+0x1c/0x20 > [] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. I have bisected it down to this patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > >Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > >Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > runlevel 2 and wait less than one minute. > > Maybe this oops is related too? Looks that way. > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0004 > printing eip: > c02206aa > *pde = > Oops: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:00.0/class > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > EIP is at __make_request+0x13a/0x390 > eax: ebx: ecx: 042b0dd8 edx: 00010485 > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 > 0008 >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 > 0100 >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e > c653db48 > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xa9/0xd0 > [] show_registers+0x206/0x350 > [] die+0x10e/0x210 > [] do_page_fault+0x2d2/0x600 > [] error_code+0x74/0x7c > [] generic_make_request+0x15a/0x200 > [] submit_bio+0x58/0xe0 > [] metapage_writepage+0x18f/0x1b0 > [] __writepage+0xb/0x30 > [] write_cache_pages+0x22f/0x300 > [] generic_writepages+0x23/0x30 > [] do_writepages+0x5c/0x60 > [] __filemap_fdatawrite_range+0x67/0x80 > [] filemap_flush+0x25/0x30 > [] lmLogSync+0x19d/0x230 > [] lmLog+0x5e/0x190 > [] txCommit+0x8c0/0x1010 > [] jfs_create+0x324/0x370 > [] vfs_create+0xaf/0x100 > [] open_namei+0x58c/0x640 > [] do_filp_open+0x2c/0x50 > [] do_sys_open+0x47/0xe0 > [] sys_open+0x1c/0x20 > [] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
>
> Two problems:
>
> 1) A showstopper with the root partition on RAID1:
>
> md: raid1 personality registered for level 1
> [--snip--]
> md: multipath personality registered for level -4
> register_blkdev: failed to get major for mdp
> [--snip--]
> VFS: Cannot open root device "md1" or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
> At the moment I have no serial console attached to the box, so I had to
> rewrite
> the messages manually.
netconsole is good.
> 2) On HPC nx6325 I get the following 100% of the time during the resume from
> disk:
>
> BUG: at drivers/pci/pci.c:823 pcim_enable_device()
>
> Call Trace:
> [] pcim_enable_device+0x93/0xb3
> [] ata_pci_device_do_resume+0x21/0x5e
> [] sil_pci_device_resume+0x1c/0x51
> [] pci_device_resume+0x22/0x53
> [] resume_device+0xca/0x131
> [] dpm_resume+0x81/0xd3
> [] device_resume+0x30/0x45
> [] snapshot_ioctl+0x245/0x63e
> [] do_ioctl+0x5e/0x77
> [] vfs_ioctl+0x25c/0x279
> [] sys_ioctl+0x5f/0x82
> [] sys_write+0x47/0x70
> [] system_call+0x7e/0x83
>
> Nevertheless, the system seems to be fully functional after the resume.
>
> [I've been observing it since 2.6.20-git10 and have reported it for a couple
> of times, but apparently nobody cares. :-(]
This is a Tejun thing - apparently it's due to swsusp calling suspend once
and resume twice (or is it vice versa). He'll be looking into it soon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Andrew Morton napisał(a):
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm2/
>
Slab corruption + oops yablb (yet another block layer bug)
Slab corruption: start=f3b8f654, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
060: 6b 6b 6b 6b 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=f3b8f598, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=f3b8f710, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
0xc0160f39 is in mempool_free_slab (/mnt/md0/devel/linux-mm/mm/mempool.c:295).
290
291 void mempool_free_slab(void *element, void *pool_data)
292 {
293 struct kmem_cache *mem = pool_data;
294 kmem_cache_free(mem, element);
295 }
296 EXPORT_SYMBOL(mempool_free_slab);
297
298 /*
299 * A commonly used alloc and free fn that kmalloc/kfrees the amount of
memory
quilt patches mm/mempool.c
patches/origin.patch
It's time to test 2.6.20-git14 with LTP.
BUG: unable to handle kernel paging request at virtual address 6b6b6b8f
printing eip:
c01f4618
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram evdev
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer intel_agp 8139too agpgart skge snd i2c_i801 mii soundcore sk98lin
snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010292 (2.6.20-mm2 #18)
EIP is at ll_back_merge_fn+0x9d/0x1ba
eax: 6b6b6b6b ebx: f5e6a2a8 ecx: 1000 edx: 0001
esi: f7cc1a14 edi: f5e6a2a8 ebp: ee7ebb34 esp: ee7ebb18
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process doio (pid: 11602, ti=ee7ea000 task=f339a070 task.ti=ee7ea000)
Stack: f306d394 1000 f7cb2e54 ee7ebb34 f5e6a2a8 f306d394 f7cc1a14 ee7ebb5c
c01f622f c020fad7 f5e6a2a8 f306d394 f306d394 ee7ebb5c f5e6a2a8 f7cc1a14
f306d394 ee7ebb94 c01f7a74 ee7ebb8c c013ea3c f339a5e8 0002 f339a070
Call Trace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_stack_log_lvl+0x9d/0xac
[] show_registers+0x1ed/0x34c
[] die+0x11d/0x234
[] do_page_fault+0x47c/0x55b
[] error_code+0x7c/0x84
[] bio_attempt_back_merge+0x40/0xe3
[] __make_request+0xe1/0x32e
[] generic_make_request+0x2e1/0x30f
[] submit_bio+0x132/0x13a
[] submit_bh+0xf6/0x113
[] __block_write_full_page+0x242/0x35c
[] block_write_full_page+0xc9/0xd1
[] ext3_ordered_writepage+0x100/0x1b1
[] __writepage+0xb/0x25
[] write_cache_pages+0x19d/0x2b4
[] generic_writepages+0x22/0x2a
[] do_writepages+0x36/0x48
[] __filemap_fdatawrite_range+0x5b/0x67
[] filemap_fdatawrite_range+0x22/0x29
[] sync_page_range+0x8c/0x107
[] generic_file_aio_write+0xbf/0xdb
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xd7/0x114
[] vfs_write+0xd1/0x15a
[] sys_write+0x3d/0x72
[] syscall_call+0x7/0xb
===
Code: ff 8b 45 e4 8b 50 0c 83 f2 08 c1 ea 03 83 e2 01 b8 20 e1 43 c0 e8 e5 bb
01 00 85 c0 74 0a 8b 55 e4 89 f0 e8 63 f4 ff ff 8b 47 38 <8b> 50 24 89 55 e8 8b
4d e4 8b 49 20 89 4d ec 0f b7 48 14 6b c9
EIP: [] ll_back_merge_fn+0x9d/0x1ba SS:ESP 0068:ee7ebb18
0xc01f4618 is in ll_back_merge_fn
(/mnt/md0/devel/linux-mm/block/ll_rw_blk.c:1421).
1416}
1417if (unlikely(!bio_flagged(req->biotail, BIO_SEG_VALID)))
1418blk_recount_segments(q, req->biotail);
1419if (unlikely(!bio_flagged(bio, BIO_SEG_VALID)))
1420blk_recount_segments(q, bio);
1421len = req->biotail->bi_hw_back_size + bio->bi_hw_front_size;
1422if (BIOVEC_VIRT_MERGEABLE(__BVEC_END(req->biotail),
__BVEC_START(bio)) &&
1423!BIOVEC_VIRT_OVERSIZE(len)) {
1424int mergeable = ll_new_mergeable(q, req, bio);
1425
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20-mm2/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > Le 18.02.2007 06:51, Andrew Morton a écrit : > >Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > >Will appear later at > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > Hello, I've got a fully reproducible Oops. I just have to boot to > runlevel 2 and wait less than one minute. Maybe this oops is related too? Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xa9/0xd0 [] show_registers+0x206/0x350 [] die+0x10e/0x210 [] do_page_fault+0x2d2/0x600 [] error_code+0x74/0x7c [] generic_make_request+0x15a/0x200 [] submit_bio+0x58/0xe0 [] metapage_writepage+0x18f/0x1b0 [] __writepage+0xb/0x30 [] write_cache_pages+0x22f/0x300 [] generic_writepages+0x23/0x30 [] do_writepages+0x5c/0x60 [] __filemap_fdatawrite_range+0x67/0x80 [] filemap_flush+0x25/0x30 [] lmLogSync+0x19d/0x230 [] lmLog+0x5e/0x190 [] txCommit+0x8c0/0x1010 [] jfs_create+0x324/0x370 [] vfs_create+0xaf/0x100 [] open_namei+0x58c/0x640 [] do_filp_open+0x2c/0x50 [] do_sys_open+0x47/0xe0 [] sys_open+0x1c/0x20 [] syscall_call+0x7/0xb === Code: 5d c3 8b 58 18 8b 43 04 0f 18 00 90 8b 7d e8 83 c7 14 39 fb 75 2 4 e9 2d ff ff ff 8d b6 00 00 00 00 48 0f 84 d9 00 00 00 8b 5b 04 <8b> 43 04 0f 18 00 90 39 fb 0f 84 0e ff ff ff 89 f2 89 d8 e8 2e EIP: [] __make_request+0x13a/0x390 SS:ESP 0068:c653dabc -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Two problems: 1) A showstopper with the root partition on RAID1: md: raid1 personality registered for level 1 [--snip--] md: multipath personality registered for level -4 register_blkdev: failed to get major for mdp [--snip--] VFS: Cannot open root device "md1" or unknown-block(0,0) At the moment I have no serial console attached to the box, so I had to rewrite the messages manually. 2) On HPC nx6325 I get the following 100% of the time during the resume from disk: BUG: at drivers/pci/pci.c:823 pcim_enable_device() Call Trace: [] pcim_enable_device+0x93/0xb3 [] ata_pci_device_do_resume+0x21/0x5e [] sil_pci_device_resume+0x1c/0x51 [] pci_device_resume+0x22/0x53 [] resume_device+0xca/0x131 [] dpm_resume+0x81/0xd3 [] device_resume+0x30/0x45 [] snapshot_ioctl+0x245/0x63e [] do_ioctl+0x5e/0x77 [] vfs_ioctl+0x25c/0x279 [] sys_ioctl+0x5f/0x82 [] sys_write+0x47/0x70 [] system_call+0x7e/0x83 Nevertheless, the system seems to be fully functional after the resume. [I've been observing it since 2.6.20-git10 and have reported it for a couple of times, but apparently nobody cares. :-(] Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Two problems: 1) A showstopper with the root partition on RAID1: md: raid1 personality registered for level 1 [--snip--] md: multipath personality registered for level -4 register_blkdev: failed to get major for mdp [--snip--] VFS: Cannot open root device md1 or unknown-block(0,0) At the moment I have no serial console attached to the box, so I had to rewrite the messages manually. 2) On HPC nx6325 I get the following 100% of the time during the resume from disk: BUG: at drivers/pci/pci.c:823 pcim_enable_device() Call Trace: [80325ff8] pcim_enable_device+0x93/0xb3 [803a974a] ata_pci_device_do_resume+0x21/0x5e [803b5e6c] sil_pci_device_resume+0x1c/0x51 [8032800d] pci_device_resume+0x22/0x53 [8039ae58] resume_device+0xca/0x131 [8039af40] dpm_resume+0x81/0xd3 [8039afc2] device_resume+0x30/0x45 [802a0792] snapshot_ioctl+0x245/0x63e [8023cfcc] do_ioctl+0x5e/0x77 [8022d2b3] vfs_ioctl+0x25c/0x279 [80246a80] sys_ioctl+0x5f/0x82 [80215586] sys_write+0x47/0x70 [8025711e] system_call+0x7e/0x83 Nevertheless, the system seems to be fully functional after the resume. [I've been observing it since 2.6.20-git10 and have reported it for a couple of times, but apparently nobody cares. :-(] Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[c02206aa]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [c01048ba] show_trace_log_lvl+0x1a/0x30 [c0104979] show_stack_log_lvl+0xa9/0xd0 [c0104ba6] show_registers+0x206/0x350 [c0104dfe] die+0x10e/0x210 [c0114652] do_page_fault+0x2d2/0x600 [c0351f84] error_code+0x74/0x7c [c021e0ca] generic_make_request+0x15a/0x200 [c0220318] submit_bio+0x58/0xe0 [c0205d0f] metapage_writepage+0x18f/0x1b0 [c014cc2b] __writepage+0xb/0x30 [c014d20f] write_cache_pages+0x22f/0x300 [c014d303] generic_writepages+0x23/0x30 [c014d36c] do_writepages+0x5c/0x60 [c0148307] __filemap_fdatawrite_range+0x67/0x80 [c0149785] filemap_flush+0x25/0x30 [c02080cd] lmLogSync+0x19d/0x230 [c020871e] lmLog+0x5e/0x190 [c020a360] txCommit+0x8c0/0x1010 [c01eecf4] jfs_create+0x324/0x370 [c016f38f] vfs_create+0xaf/0x100 [c017269c] open_namei+0x58c/0x640 [c0165b7c] do_filp_open+0x2c/0x50 [c0165be7] do_sys_open+0x47/0xe0 [c0165cbc] sys_open+0x1c/0x20 [c01041c0] syscall_call+0x7/0xb === Code: 5d c3 8b 58 18 8b 43 04 0f 18 00 90 8b 7d e8 83 c7 14 39 fb 75 2 4 e9 2d ff ff ff 8d b6 00 00 00 00 48 0f 84 d9 00 00 00 8b 5b 04 8b 43 04 0f 18 00 90 39 fb 0f 84 0e ff ff ff 89 f2 89 d8 e8 2e EIP: [c02206aa] __make_request+0x13a/0x390 SS:ESP 0068:c653dabc -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
Andrew Morton napisał(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Slab corruption + oops yablb (yet another block layer bug)
Slab corruption: start=f3b8f654, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [c0160f39](mempool_free_slab+0xe/0x10)
060: 6b 6b 6b 6b 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=f3b8f598, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [c0160f39](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=f3b8f710, len=176
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [c0160f39](mempool_free_slab+0xe/0x10)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
0xc0160f39 is in mempool_free_slab (/mnt/md0/devel/linux-mm/mm/mempool.c:295).
290
291 void mempool_free_slab(void *element, void *pool_data)
292 {
293 struct kmem_cache *mem = pool_data;
294 kmem_cache_free(mem, element);
295 }
296 EXPORT_SYMBOL(mempool_free_slab);
297
298 /*
299 * A commonly used alloc and free fn that kmalloc/kfrees the amount of
memory
quilt patches mm/mempool.c
patches/origin.patch
It's time to test 2.6.20-git14 with LTP.
BUG: unable to handle kernel paging request at virtual address 6b6b6b8f
printing eip:
c01f4618
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram evdev
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer intel_agp 8139too agpgart skge snd i2c_i801 mii soundcore sk98lin
snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[c01f4618]Not tainted VLI
EFLAGS: 00010292 (2.6.20-mm2 #18)
EIP is at ll_back_merge_fn+0x9d/0x1ba
eax: 6b6b6b6b ebx: f5e6a2a8 ecx: 1000 edx: 0001
esi: f7cc1a14 edi: f5e6a2a8 ebp: ee7ebb34 esp: ee7ebb18
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process doio (pid: 11602, ti=ee7ea000 task=f339a070 task.ti=ee7ea000)
Stack: f306d394 1000 f7cb2e54 ee7ebb34 f5e6a2a8 f306d394 f7cc1a14 ee7ebb5c
c01f622f c020fad7 f5e6a2a8 f306d394 f306d394 ee7ebb5c f5e6a2a8 f7cc1a14
f306d394 ee7ebb94 c01f7a74 ee7ebb8c c013ea3c f339a5e8 0002 f339a070
Call Trace:
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c01053c4] show_stack_log_lvl+0x9d/0xac
[c01055c0] show_registers+0x1ed/0x34c
[c010583c] die+0x11d/0x234
[c011a8e1] do_page_fault+0x47c/0x55b
[c0336d54] error_code+0x7c/0x84
[c01f622f] bio_attempt_back_merge+0x40/0xe3
[c01f7a74] __make_request+0xe1/0x32e
[c01f5128] generic_make_request+0x2e1/0x30f
[c01f7614] submit_bio+0x132/0x13a
[c019e063] submit_bh+0xf6/0x113
[c019f659] __block_write_full_page+0x242/0x35c
[c019fbcc] block_write_full_page+0xc9/0xd1
[c01c0788] ext3_ordered_writepage+0x100/0x1b1
[c01637db] __writepage+0xb/0x25
[c0163c6c] write_cache_pages+0x19d/0x2b4
[c0163da5] generic_writepages+0x22/0x2a
[c0163de3] do_writepages+0x36/0x48
[c015f176] __filemap_fdatawrite_range+0x5b/0x67
[c015f22b] filemap_fdatawrite_range+0x22/0x29
[c015f392] sync_page_range+0x8c/0x107
[c0160347] generic_file_aio_write+0xbf/0xdb
[c01bc94b] ext3_file_write+0x27/0x99
[c017f1ec] do_sync_write+0xd7/0x114
[c017fad2] vfs_write+0xd1/0x15a
[c0180102] sys_write+0x3d/0x72
[c010432c] syscall_call+0x7/0xb
===
Code: ff 8b 45 e4 8b 50 0c 83 f2 08 c1 ea 03 83 e2 01 b8 20 e1 43 c0 e8 e5 bb
01 00 85 c0 74 0a 8b 55 e4 89 f0 e8 63 f4 ff ff 8b 47 38 8b 50 24 89 55 e8 8b
4d e4 8b 49 20 89 4d ec 0f b7 48 14 6b c9
EIP: [c01f4618] ll_back_merge_fn+0x9d/0x1ba SS:ESP 0068:ee7ebb18
0xc01f4618 is in ll_back_merge_fn
(/mnt/md0/devel/linux-mm/block/ll_rw_blk.c:1421).
1416}
1417if (unlikely(!bio_flagged(req-biotail, BIO_SEG_VALID)))
1418blk_recount_segments(q, req-biotail);
1419if (unlikely(!bio_flagged(bio, BIO_SEG_VALID)))
1420blk_recount_segments(q, bio);
1421len = req-biotail-bi_hw_back_size + bio-bi_hw_front_size;
1422if (BIOVEC_VIRT_MERGEABLE(__BVEC_END(req-biotail),
__BVEC_START(bio))
1423!BIOVEC_VIRT_OVERSIZE(len)) {
1424int mergeable = ll_new_mergeable(q, req, bio);
1425
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20-mm2/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line unsubscribe
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[c02206aa]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [c01048ba] show_trace_log_lvl+0x1a/0x30 [c0104979] show_stack_log_lvl+0xa9/0xd0 [c0104ba6] show_registers+0x206/0x350 [c0104dfe] die+0x10e/0x210 [c0114652] do_page_fault+0x2d2/0x600 [c0351f84] error_code+0x74/0x7c [c021e0ca] generic_make_request+0x15a/0x200 [c0220318] submit_bio+0x58/0xe0 [c0205d0f] metapage_writepage+0x18f/0x1b0 [c014cc2b] __writepage+0xb/0x30 [c014d20f] write_cache_pages+0x22f/0x300 [c014d303] generic_writepages+0x23/0x30 [c014d36c] do_writepages+0x5c/0x60 [c0148307] __filemap_fdatawrite_range+0x67/0x80 [c0149785] filemap_flush+0x25/0x30 [c02080cd] lmLogSync+0x19d/0x230 [c020871e] lmLog+0x5e/0x190 [c020a360] txCommit+0x8c0/0x1010 [c01eecf4] jfs_create+0x324/0x370 [c016f38f] vfs_create+0xaf/0x100 [c017269c] open_namei+0x58c/0x640 [c0165b7c] do_filp_open+0x2c/0x50 [c0165be7] do_sys_open+0x47/0xe0 [c0165cbc] sys_open+0x1c/0x20 [c01041c0] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Two problems:
1) A showstopper with the root partition on RAID1:
md: raid1 personality registered for level 1
[--snip--]
md: multipath personality registered for level -4
register_blkdev: failed to get major for mdp
[--snip--]
VFS: Cannot open root device md1 or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 = index index = 63) ||
- (120 = index index = 127) ||
- (240 = index index = 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
At the moment I have no serial console attached to the box, so I had to
rewrite
the messages manually.
netconsole is good.
2) On HPC nx6325 I get the following 100% of the time during the resume from
disk:
BUG: at drivers/pci/pci.c:823 pcim_enable_device()
Call Trace:
[80325ff8] pcim_enable_device+0x93/0xb3
[803a974a] ata_pci_device_do_resume+0x21/0x5e
[803b5e6c] sil_pci_device_resume+0x1c/0x51
[8032800d] pci_device_resume+0x22/0x53
[8039ae58] resume_device+0xca/0x131
[8039af40] dpm_resume+0x81/0xd3
[8039afc2] device_resume+0x30/0x45
[802a0792] snapshot_ioctl+0x245/0x63e
[8023cfcc] do_ioctl+0x5e/0x77
[8022d2b3] vfs_ioctl+0x25c/0x279
[80246a80] sys_ioctl+0x5f/0x82
[80215586] sys_write+0x47/0x70
[8025711e] system_call+0x7e/0x83
Nevertheless, the system seems to be fully functional after the resume.
[I've been observing it since 2.6.20-git10 and have reported it for a couple
of times, but apparently nobody cares. :-(]
This is a Tejun thing - apparently it's due to swsusp calling suspend once
and resume twice (or is it vice versa). He'll be looking into it soon.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[c02206aa]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [c01048ba] show_trace_log_lvl+0x1a/0x30 [c0104979] show_stack_log_lvl+0xa9/0xd0 [c0104ba6] show_registers+0x206/0x350 [c0104dfe] die+0x10e/0x210 [c0114652] do_page_fault+0x2d2/0x600 [c0351f84] error_code+0x74/0x7c [c021e0ca] generic_make_request+0x15a/0x200 [c0220318] submit_bio+0x58/0xe0 [c0205d0f] metapage_writepage+0x18f/0x1b0 [c014cc2b] __writepage+0xb/0x30 [c014d20f] write_cache_pages+0x22f/0x300 [c014d303] generic_writepages+0x23/0x30 [c014d36c] do_writepages+0x5c/0x60 [c0148307] __filemap_fdatawrite_range+0x67/0x80 [c0149785] filemap_flush+0x25/0x30 [c02080cd] lmLogSync+0x19d/0x230 [c020871e] lmLog+0x5e/0x190 [c020a360] txCommit+0x8c0/0x1010 [c01eecf4] jfs_create+0x324/0x370 [c016f38f] vfs_create+0xaf/0x100 [c017269c] open_namei+0x58c/0x640 [c0165b7c] do_filp_open+0x2c/0x50 [c0165be7] do_sys_open+0x47/0xe0 [c0165cbc] sys_open+0x1c/0x20 [c01041c0] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. I have bisected it down to this patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 13:47:44 -0800 Miles Lane [EMAIL PROTECTED] wrote: It looks like there are some slight differences between the stack traces I have and the ones that have already been posted. I hope this helps, Miles psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. BUG: unable to handle kernel paging request at virtual address 6b6b6b6f printing eip: c01f238c *pde = Oops: [#1] PREEMPT SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Modules linked in: ieee80211_crypt_wep binfmt_misc rfcomm l2cap bluetooth ipv6 capability commoncap apm i915 drm acpi_cpufreq cpufreq_powersave cpufreq_performance cpufreq_conservative video dock container button battery ac nls_ascii nls_cp437 vfat fat nls_base fuse sbp2 parport_pc lp parport pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device sdhci mmc_core tifm_7xx1 tifm_core yenta_socket rsrc_nonstatic pcmcia_core snd soundcore ipw2200 ieee80211 ieee80211_crypt firmware_class rtc snd_page_alloc iTCO_wdt iTCO_vendor_support shpchp pci_hotplug sg sr_mod cdrom sd_mod ohci1394 ieee1394 8139too mii ehci_hcd uhci_hcd usbcore thermal processor fan unix CPU:0 EIP:0060:[c01f238c]Not tainted VLI EFLAGS: 00210297 (2.6.20-mm2 #13) EIP is at __make_request+0xeb/0x2ee Looks fairly similar. I guess I need to do a git-blockless -mm3 :( - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 14:35:17 -0800 Andrew Morton [EMAIL PROTECTED] wrote: I guess I need to do a git-blockless -mm3 OK, this is looking like a pain - I'd have to drop or significantly redo thirty or more patches. Jens, please fix it asap. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [804032c3] rtc_sysfs_remove_device+0x23/0x50 PGD 5e10c067 PUD 5dd58067 PMD 0 Oops: [1] PREEMPT last sysfs file: /devices/pnp0/00:04/id CPU 0 Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 RIP: 0010:[804032c3] [804032c3] rtc_sysfs_remove_device+0x23/0x50 RSP: 0018:81005e3f9c18 EFLAGS: 00010202 RAX: RBX: 81005dabeea0 RCX: RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 RBP: 81005e3f9c28 R08: 0001 R09: R10: R11: R12: 81005dabeea0 R13: 810002890258 R14: 810002890268 R15: 810002890098 FS: 2ac610b906f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0030 CR3: 5e16d000 CR4: 06e0 Process modprobe (pid: 2960, threadinfo 81005e3f8000, task 81005e6a7140) Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 81005dabeea0 81005dabf008 0008 81005fe244e8 0008 81005e3f9c88 803c5891 Call Trace: [803c5786] class_device_del+0x86/0x180 [803c5891] class_device_unregister+0x11/0x20 [8040280e] rtc_device_unregister+0x3e/0x50 [880cd789] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [803988a1] pnp_device_probe+0xa1/0xe0 [803c4d20] __driver_attach+0x0/0xa0 [803c4bb5] driver_probe_device+0x115/0x1c0 [803c4d20] __driver_attach+0x0/0xa0 [803c4d83] __driver_attach+0x63/0xa0 [803c3e1f] bus_for_each_dev+0x4f/0x80 [803c497c] driver_attach+0x1c/0x20 [803c4233] bus_add_driver+0x83/0x1d0 [803c50d9] driver_register+0x89/0x90 [803985cc] pnp_register_driver+0x1c/0x20 [880d1010] :rtc_cmos:cmos_init+0x10/0x12 [8025199b] sys_init_module+0x158b/0x16f0 [802d09da] dnotify_parent+0x7a/0x90 [80268b80] file_read_actor+0x0/0x170 [80209a0e] system_call+0x7e/0x83 Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 RIP [804032c3] rtc_sysfs_remove_device+0x23/0x50 RSP 81005e3f9c18 CR2: 0030 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: compilation fix
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ I think something like this is generally necessary: --- drivers/pci/quirks.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.20-mm2/drivers/pci/quirks.c === --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c +++ linux-2.6.20-mm2/drivers/pci/quirks.c @@ -21,6 +21,7 @@ #include linux/init.h #include linux/delay.h #include linux/acpi.h +#include asm/apicdef.h #include pci.h /* The Mellanox Tavor device gives false positive parity errors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [804032c3] rtc_sysfs_remove_device+0x23/0x50 PGD 5e10c067 PUD 5dd58067 PMD 0 Oops: [1] PREEMPT last sysfs file: /devices/pnp0/00:04/id CPU 0 Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 RIP: 0010:[804032c3] [804032c3] rtc_sysfs_remove_device+0x23/0x50 RSP: 0018:81005e3f9c18 EFLAGS: 00010202 RAX: RBX: 81005dabeea0 RCX: RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 RBP: 81005e3f9c28 R08: 0001 R09: R10: R11: R12: 81005dabeea0 R13: 810002890258 R14: 810002890268 R15: 810002890098 FS: 2ac610b906f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0030 CR3: 5e16d000 CR4: 06e0 Process modprobe (pid: 2960, threadinfo 81005e3f8000, task 81005e6a7140) Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 81005dabeea0 81005dabf008 0008 81005fe244e8 0008 81005e3f9c88 803c5891 Call Trace: [803c5786] class_device_del+0x86/0x180 [803c5891] class_device_unregister+0x11/0x20 [8040280e] rtc_device_unregister+0x3e/0x50 [880cd789] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [803988a1] pnp_device_probe+0xa1/0xe0 [803c4d20] __driver_attach+0x0/0xa0 [803c4bb5] driver_probe_device+0x115/0x1c0 [803c4d20] __driver_attach+0x0/0xa0 [803c4d83] __driver_attach+0x63/0xa0 [803c3e1f] bus_for_each_dev+0x4f/0x80 [803c497c] driver_attach+0x1c/0x20 [803c4233] bus_add_driver+0x83/0x1d0 [803c50d9] driver_register+0x89/0x90 [803985cc] pnp_register_driver+0x1c/0x20 [880d1010] :rtc_cmos:cmos_init+0x10/0x12 [8025199b] sys_init_module+0x158b/0x16f0 [802d09da] dnotify_parent+0x7a/0x90 [80268b80] file_read_actor+0x0/0x170 [80209a0e] system_call+0x7e/0x83 Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 RIP [804032c3] rtc_sysfs_remove_device+0x23/0x50 RSP 81005e3f9c18 CR2: 0030 How did you provoke that? modprobe rtc-cmos? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: compilation fix
On Mon, 19 Feb 2007 00:33:26 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 18 February 2007 06:51, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ I think something like this is generally necessary: --- drivers/pci/quirks.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.20-mm2/drivers/pci/quirks.c === --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c +++ linux-2.6.20-mm2/drivers/pci/quirks.c @@ -21,6 +21,7 @@ #include linux/init.h #include linux/delay.h #include linux/acpi.h +#include asm/apicdef.h #include pci.h /* The Mellanox Tavor device gives false positive parity errors Will break all non-x86. What are we trying to fix here? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Two problems:
1) A showstopper with the root partition on RAID1:
md: raid1 personality registered for level 1
[--snip--]
md: multipath personality registered for level -4
register_blkdev: failed to get major for mdp
[--snip--]
VFS: Cannot open root device md1 or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index 0; index--) {
- /*
- * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
- * majors
- */
- if ((60 = index index = 63) ||
- (120 = index index = 127) ||
- (240 = index index = 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
At the moment I have no serial console attached to the box, so I had to
rewrite
the messages manually.
netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[8026be21] mempool_alloc_slab+0x11/0x20
[80348e7c] generic_make_request+0x1ec/0x230
[8034b7e6] submit_bio+0xf6/0x110
[802b60f0] submit_bh+0x100/0x130
[802b788a] __block_write_full_page+0x1ca/0x2e0
[802bc040] blkdev_get_block+0x0/0x70
[802bc040] blkdev_get_block+0x0/0x70
[802b7a93] block_write_full_page+0xf3/0x110
[802baeb3] blkdev_writepage+0x13/0x20
[8026eb85] __writepage+0x15/0x40
[8026f1e3] write_cache_pages+0x1f3/0x360
[8026eb70] __writepage+0x0/0x40
[8026f372] generic_writepages+0x22/0x30
[8026f3c6] do_writepages+0x46/0x80
[802b1f67] __writeback_single_inode+0x1d7/0x370
[802b2355] generic_sync_sb_inodes+0x35/0x2b0
[802b24f9] generic_sync_sb_inodes+0x1d9/0x2b0
[802b29f2] writeback_inodes+0x82/0x100
[802b25f5] sync_sb_inodes+0x25/0x30
[802b2a08] writeback_inodes+0x98/0x100
[8026fd40] pdflush+0x0/0x1e0
[8026f934] wb_kupdate+0x94/0x110
[8026fe68] pdflush+0x128/0x1e0
[8026f8a0] wb_kupdate+0x0/0x110
[8026fd40] pdflush+0x0/0x1e0
[80240863] kthread+0xd3/0x110
[80240700] keventd_create_kthread+0x0/0x90
[8020a3f8] child_rip+0xa/0x12
[80483e5b] _spin_unlock_irq+0x2b/0x60
[80209fb0] restore_args+0x0/0x30
[80240790] kthread+0x0/0x110
[8020a3ee] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [8034bce4] __make_request+0x134/0x370
RSP 81005ed659a0
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
2) On HPC nx6325 I get the following 100% of the time during the resume
Re: 2.6.20-mm2
On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Two problems:
1) A showstopper with the root partition on RAID1:
md: raid1 personality registered for level 1
[--snip--]
md: multipath personality registered for level -4
register_blkdev: failed to get major for mdp
[--snip--]
VFS: Cannot open root device md1 or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index 0; index--) {
- /*
- * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
- * majors
- */
- if ((60 = index index = 63) ||
- (120 = index index = 127) ||
- (240 = index index = 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
At the moment I have no serial console attached to the box, so I had to
rewrite
the messages manually.
netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[8026be21] mempool_alloc_slab+0x11/0x20
[80348e7c] generic_make_request+0x1ec/0x230
[8034b7e6] submit_bio+0xf6/0x110
[802b60f0] submit_bh+0x100/0x130
[802b788a] __block_write_full_page+0x1ca/0x2e0
[802bc040] blkdev_get_block+0x0/0x70
[802bc040] blkdev_get_block+0x0/0x70
[802b7a93] block_write_full_page+0xf3/0x110
[802baeb3] blkdev_writepage+0x13/0x20
[8026eb85] __writepage+0x15/0x40
[8026f1e3] write_cache_pages+0x1f3/0x360
[8026eb70] __writepage+0x0/0x40
[8026f372] generic_writepages+0x22/0x30
[8026f3c6] do_writepages+0x46/0x80
[802b1f67] __writeback_single_inode+0x1d7/0x370
[802b2355] generic_sync_sb_inodes+0x35/0x2b0
[802b24f9] generic_sync_sb_inodes+0x1d9/0x2b0
[802b29f2] writeback_inodes+0x82/0x100
[802b25f5] sync_sb_inodes+0x25/0x30
[802b2a08] writeback_inodes+0x98/0x100
[8026fd40] pdflush+0x0/0x1e0
[8026f934] wb_kupdate+0x94/0x110
[8026fe68] pdflush+0x128/0x1e0
[8026f8a0] wb_kupdate+0x0/0x110
[8026fd40] pdflush+0x0/0x1e0
[80240863] kthread+0xd3/0x110
[80240700] keventd_create_kthread+0x0/0x90
[8020a3f8] child_rip+0xa/0x12
[80483e5b] _spin_unlock_irq+0x2b/0x60
[80209fb0] restore_args+0x0/0x30
[80240790] kthread+0x0/0x110
[8020a3ee] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [8034bce4] __make_request+0x134/0x370
RSP 81005ed659a0
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
It looks familiar to me
Re: 2.6.20-mm2
On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: netconsole is good. I know. :-) In the meantime, I've got something worse on another x86_64 box: Asus Laptop ACPI Extras version 0.30 L5D model detected, supported audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 general protection fault: [2] PREEMPT last sysfs file: /class/net/eth2/carrier CPU 0 Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 RIP: 0010:[8034bce4] [8034bce4] __make_request+0x134/0x370 RSP: :81005ed659a0 EFLAGS: 00010297 RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 R10: R11: R12: 810037b4dbb0 R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 FS: 2ad4a29e6d00() GS:805db000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) Stack: 810002852540 0001 810037b4dbb0 8026be21 81005ed65a40 0008 810037b4dbb0 0800 0008 8100021d94e0 81005ed65a40 80348e7c Call Trace: [8026be21] mempool_alloc_slab+0x11/0x20 [80348e7c] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote: On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [804032c3] rtc_sysfs_remove_device+0x23/0x50 ... Call Trace: [803c5786] class_device_del+0x86/0x180 [803c5891] class_device_unregister+0x11/0x20 [8040280e] rtc_device_unregister+0x3e/0x50 [880cd789] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [803988a1] pnp_device_probe+0xa1/0xe0 ... How did you provoke that? modprobe rtc-cmos? Plus, I'd guess, the old rtc driver statically linked. What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
On Sun, 18 Feb 2007 17:18:14 +1100 "Dave Airlie" <[EMAIL PROTECTED]> wrote: > > - git-drm.patch is still in disgrace > > > > Okay I think I've fixed it up, some of the locking code from the DRM > git devel repo was completely integrated.. > yep, my X server is happy now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
- git-drm.patch is still in disgrace Okay I think I've fixed it up, some of the locking code from the DRM git devel repo was completely integrated.. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
