2.6.20-mm2
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/ - There are IDE- and Xen-related module linkage errors during allmodconfig builds. These have been reported. - Quite a lot of less-popular architectures are broken by the utrace merge. They will stay that way while the maintainers ponder http://people.redhat.com/roland/utrace/utrace-arch-porting-howto.txt - Added the LED development tree to the -mm lineup as git-leds.patch (Richard Purdie <[EMAIL PROTECTED]>) - git-parisc.patch is back for a while - git-audit.patch is back for a while - git-drm.patch is still in disgrace - Added Xen domain-U support - 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: Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.20-mm1: origin.patch git-acpi.patch git-alsa.patch git-arm.patch git-audit-master.patch git-avr32.patch git-cifs.patch git-powerpc.patch git-dvb.patch git-hid.patch git-ia64.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-leds.patch git-libata-all.patch git-ide.patch git-lxdialog.patch git-md-accel.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-netdev-all.patch git-backlight.patch git-bluetooth.patch git-ioat.patch git-ocfs2.patch git-parisc.patch git-pciseg.patch git-s390.patch git-sh.patch git-scsi-misc.patch git-block.patch git-unionfs.patch git-v9fs.patch git-wireless.patch git-ipwireless_cs.patch git-gccbug.patch git trees -gpio-core-documentation.patch -build-errors-uevent-with-config_sysfs=n.patch -mincore-config_swap=n-fix.patch -mincore-fill-in-results-properly.patch -mincore-vma-crossing-fix.patch -acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi.patch -ifdef-acpi_future_usage-acpi_os_readable.patch -at91-correct-value-for-at91_rstc_key.patch -powerpc-rtas-msi-support-fix.patch -fix-cut-and-paste-breakage-in-arch-powerpc-platforms-pseries-pseriesh.patch -powerpc-export-of_find_property.patch -libata-add-a-host-flag-to-indicate-lack-of-iordy.patch -add-delay-around-sl82c105_reset_engine-calls.patch -sata_nv-add-back-some-verbosity-into-adma-error_handler-tidy.patch -sata_nv-handle-serror-status-indication.patch -ata-convert-gsi-to-irq-on-ia64.patch -git-md-accel-fixes.patch -git-md-accel-warning-fixes.patch -git-md-accel-fix.patch -revert-drivers-net-tulip-dmfe-support-basic-carrier-detection.patch -fix-atl1-braino.patch -net-wan-pc300tooc-pci_module_init-to-pci_register_driver.patch -atl1-drop-net_pci-from-kconfig.patch -atl1-read-mac-address-from-register.patch -atl1-remove-unused-define.patch -atl1-add-l1-device-id-to-pci_ids-then-use-it.patch -atl1-bump-version-number.patch -atm-use-array_size-macro-when-appropriate.patch -bugfixes-and-new-hardware-support-for-arcnet-driver.patch -git-backlight-sony-fix.patch -parisc-fix-module_param-iommu-permission.patch -pa-risc-fix-bogus-warnings-from-modpost.patch -use-__u64-rather-than-u64-in-parisc-statfs-structs.patch -pci-add-systems-for-automatic-breadth-first-device-sorting-update.patch -x86-fix-dev_to_node-for-x86-and-x86_64.patch -remove-extra-newline-from-info-message.patch -fix-scsi-scsi_transporth-compile-error.patch -pci_module_init-convertion-in-the-legacy-megaraid-driver.patch -scsi-handle-bad-inquiry-responses.patch -scsi-megaraid_sas-donot-process-cmds-if-hw_crit_error-is-set.patch -scsi-megaraid_sas-added-bios_pa
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
> > > > 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(&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
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
> 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
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
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
- 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/
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
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
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
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
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 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
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() > > >
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, Mich
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 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 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
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
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
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: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: 0000 [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 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 #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-handl
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:[]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
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
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
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
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 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 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: 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: 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: 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: 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: 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: 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/
2.6.20-mm2: BLOCK=n compile error
On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-mm1: >... > git-block.patch >... > git trees >... This causes the following compile error with CONFIG_BLOCK=n: <-- snip --> ... CC kernel/sched.o /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/kernel/sched.c:1835: warning: no previous prototype for 'schedule_tail' /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/kernel/sched.c: In function 'schedule': /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/kernel/sched.c:3466: error: dereferencing pointer to incomplete type /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/kernel/sched.c:3467: error: implicit declaration of function 'blk_replug_current_nested' make[2]: *** [kernel/sched.o] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
2.6.20-mm2 CONFIG_ACPI_BAY=y: undefined reference to `is_dock_device'
Hello all, make-kpkg kernel_image bombed with: LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `bay_is_dock_device': drivers/acpi/bay.c:261: undefined reference to `is_dock_device' drivers/acpi/bay.c:261: undefined reference to `is_dock_device' drivers/built-in.o: In function `bay_add': drivers/acpi/bay.c:308: undefined reference to `register_hotplug_dock_device' drivers/built-in.o: In function `bay_exit': drivers/acpi/bay.c:384: undefined reference to `is_dock_device' drivers/acpi/bay.c:385: undefined reference to `unregister_hotplug_dock_device' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/linux-2.6.20-mm2' Famous last words: CONFIG_ACPI_DOCK=m... Andreas Mohr - 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/
2.6.20-mm2: Oops in generic_make_request not git-block.patches fault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I rebuild the kernel, without the git-block patches 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 but i still get: BUG: unable to handle kernel NULL pointer dereference at virtual address 000 4 printing eip: c01f369b *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:1d.3/usb5/5-0:1.0/bInterfaceProtoco l Modules linked in: fglrx(P) arc4 ecb blkcipher cryptomgr crypto_algapi ieee80211 _crypt_wep ipw2200 ieee80211 ieee80211_crypt sk98lin intel_agp agpgart CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00210297 (2.6.20-tEwaN1 #4) EIP is at __make_request+0xeb/0x2d7 eax: ebx: ecx: edx: 00010585 esi: dff497d4 edi: c1974d54 ebp: c1947200 esp: ec6b1b1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firefox-bin (pid: 10937, ti=ec6b task=c1938540 task.ti=ec6b) Stack: c1947200 dff4c494 0008 0100 c1947200 dff497d4 c01f1778 ef4c15c0 00672810 ef07c9a0 0008 ef7de6b8 c1948d8c 00200202 c192dc00 000112d0 00200202 c017c700 0001 c1947200 Call Trace: [] generic_make_request+0x18d/0x1bb [] do_mpage_readpage+0x44e/0x454 [] submit_bio+0xc3/0xca [] ext3_get_block+0xa8/0xbe [] mpage_end_io_read+0x0/0x61 [] mpage_bio_submit+0x19/0x1d [] do_mpage_readpage+0x34c/0x454 [] bio_add_page+0x31/0x37 [] ext3_get_block+0x0/0xbe [] add_to_page_cache+0x37/0xa7 [] mpage_readpages+0xb2/0x119 [] ext3_get_block+0x0/0xbe [] ata_qc_issue_prot+0xfe/0x234 [] ata_qc_issue+0x43b/0x48d [] ata_scsi_rw_xlat+0x126/0x19c [] ext3_readpages+0x0/0x15 [] __do_page_cache_readahead+0x16a/0x237 [] ext3_get_block+0x0/0xbe [] scsi_prep_fn+0x1b5/0x227 [] radix_tree_scan_hole_backward+0x17/0x2d [] try_context_based_readahead+0x307/0x336 [] __switch_to+0x161/0x17b [] ra_submit+0xb9/0xc5 [] page_cache_readahead_adaptive+0x2d3/0x4a4 [] io_schedule+0x4e/0x57 [] file_read_actor+0x79/0xca [] do_generic_mapping_read+0x1a4/0x4f3 [] generic_file_aio_read+0x1af/0x1f6 [] file_read_actor+0x0/0xca [] elv_next_request+0x105/0x114 [] do_sync_read+0xc7/0x10a [] scsi_next_command+0x25/0x2f [] wake_bit_function+0x0/0x44 [] sys_fstat64+0x1e/0x23 [] do_sync_read+0x0/0x10a [] vfs_read+0x88/0x10a [] sys_read+0x41/0x67 [] sysenter_past_esp+0x5f/0x85 [] inet6_synq_hash+0xe0/0xf5 === Code: 83 f8 02 75 0d 89 e9 89 da 89 f0 e8 82 ec ff ff eb 0e 48 75 13 89 e9 89 da 89 f0 e8 f0 e9 ff ff 85 c0 0f 85 e5 01 00 00 8b 5b 04 <8b> 43 04 0f 18 00 90 8d 47 14 39 c3 75 be fa 89 e0 25 00 e0 ff EIP: [] __make_request+0xeb/0x2d7 SS:ESP 0068:ec6b1b1c Ths time i had to wait a few hours till the Bug jumped on. I am trying to make a bisection search, without the patches, but i am not that experienced. HTH Oli - -- This email is intended for the person specified at the beginning of this message. It is confidential and may contain legally privileged information. If you have received this in error please let us know. You should note that you may not copy this email or use any information contained within it. Messages sent by email over the Internet are not necessarily completely secure. We accept no responsibility for changes made to this email after we sent it. You should be aware of these risks if you communicate with us by email. If you are unsure about how to act on this email please contact the person sending it to you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5XxnTvJ2Ft8Rz5cRAlVlAJ9jWSrE1Jf6KS476LNgHBr5nUjGOgCcDR34 SNFSeDQx6IhF4I1HWe25N1c= =00jf -END PGP SIGNATURE- - 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/
2.6.20-mm2: Oops in generic_make_request not git-block.patch's fault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I rebuild the kernel, without the git-block patches Mr. Piotrowski wrote: 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 but i still get: BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c01f369b *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:1d.3/usb5/5-0:1.0/bInterfaceProtoco l Modules linked in: fglrx(P) arc4 ecb blkcipher cryptomgr crypto_algapi ieee80211 _crypt_wep ipw2200 ieee80211 ieee80211_crypt sk98lin intel_agp agpgart CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00210297 (2.6.20-mm2 #4) EIP is at __make_request+0xeb/0x2d7 eax: ebx: ecx: edx: 00010585 esi: dff497d4 edi: c1974d54 ebp: c1947200 esp: ec6b1b1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firefox-bin (pid: 10937, ti=ec6b task=c1938540 task.ti=ec6b) Stack: c1947200 dff4c494 0008 0100 c1947200 dff497d4 c01f1778 ef4c15c0 00672810 ef07c9a0 0008 ef7de6b8 c1948d8c 00200202 c192dc00 000112d0 00200202 c017c700 0001 c1947200 Call Trace: [] generic_make_request+0x18d/0x1bb [] do_mpage_readpage+0x44e/0x454 [] submit_bio+0xc3/0xca [] ext3_get_block+0xa8/0xbe [] mpage_end_io_read+0x0/0x61 [] mpage_bio_submit+0x19/0x1d [] do_mpage_readpage+0x34c/0x454 [] bio_add_page+0x31/0x37 [] ext3_get_block+0x0/0xbe [] add_to_page_cache+0x37/0xa7 [] mpage_readpages+0xb2/0x119 [] ext3_get_block+0x0/0xbe [] ata_qc_issue_prot+0xfe/0x234 [] ata_qc_issue+0x43b/0x48d [] ata_scsi_rw_xlat+0x126/0x19c [] ext3_readpages+0x0/0x15 [] __do_page_cache_readahead+0x16a/0x237 [] ext3_get_block+0x0/0xbe [] scsi_prep_fn+0x1b5/0x227 [] radix_tree_scan_hole_backward+0x17/0x2d [] try_context_based_readahead+0x307/0x336 [] __switch_to+0x161/0x17b [] ra_submit+0xb9/0xc5 [] page_cache_readahead_adaptive+0x2d3/0x4a4 [] io_schedule+0x4e/0x57 [] file_read_actor+0x79/0xca [] do_generic_mapping_read+0x1a4/0x4f3 [] generic_file_aio_read+0x1af/0x1f6 [] file_read_actor+0x0/0xca [] elv_next_request+0x105/0x114 [] do_sync_read+0xc7/0x10a [] scsi_next_command+0x25/0x2f [] wake_bit_function+0x0/0x44 [] sys_fstat64+0x1e/0x23 [] do_sync_read+0x0/0x10a [] vfs_read+0x88/0x10a [] sys_read+0x41/0x67 [] sysenter_past_esp+0x5f/0x85 [] inet6_synq_hash+0xe0/0xf5 === Code: 83 f8 02 75 0d 89 e9 89 da 89 f0 e8 82 ec ff ff eb 0e 48 75 13 89 e9 89 da 89 f0 e8 f0 e9 ff ff 85 c0 0f 85 e5 01 00 00 8b 5b 04 <8b> 43 04 0f 18 00 90 8d 47 14 39 c3 75 be fa 89 e0 25 00 e0 ff EIP: [] __make_request+0xeb/0x2d7 SS:ESP 0068:ec6b1b1c This time i had to wait a few hours till the Bug jumped on. I am trying to make a bisection search, without the patches, but i am not that experienced. HTH Oli My .config is as follows: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-mm2 # Wed Feb 28 04:18:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Blo
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 -- 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, 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: 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: [] mutex_lock+0x19/0x20 but task is already holding lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x19/0x20 other info that might help us debug this: 3 locks held by beagled/4786: #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x19/0x20 #1: (&REISERFS_I(inode)->xattr_sem){}, at: [] reiserfs_setxattr+0x79/0x150 #2: (&REISERFS_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: 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: [] mutex_lock+0x19/0x20 > > but task is already holding lock: > (&inode->i_mutex){--..}, at: [] mutex_lock+0x19/0x20 > > other info that might help us debug this: > 3 locks held by beagled/4786: > #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x19/0x20 > #1: (&REISERFS_I(inode)->xattr_sem){}, at: [] > reiserfs_setxattr+0x79/0x150 > #2: (&REISERFS_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
[-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): [] 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_dir
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/
2.6.20-mm2 -- tifm/0/1919 is trying to release lock (&fm->lock) at: [] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1]
Hello, When I pull my SD card out of my laptop, I get the following: tifm_7xx1: demand removing card from socket 3 = [ BUG: bad unlock balance detected! ] - tifm/0/1919 is trying to release lock (&fm->lock) at: [] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1] but there are no more locks to release! other info that might help us debug this: no locks held by tifm/0/1919. stack backtrace: [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] print_unlock_inbalance_bug+0xec/0xf9 [] lock_release+0x9b/0x17c [] _spin_unlock_irqrestore+0x19/0x3c [] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1] [] kthread+0xa3/0xcf [] kernel_thread_helper+0x7/0x10 - 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/