Hi! I got a kernel BUG at fs/btrfs/disk-io.c:2311 when testing the 2.6.37-rc5 kernel today. The system crashed while doing really nothing for a few minutes. Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
> Hi! I got a kernel BUG at
>
> fs/btrfs/disk-io.c:2311
>
> when testing the 2.6.37-rc5 kernel today.
It''s good to mention which line this is, since the line numbers are
always changing. This is:
if (total_errors > max_errors) {
printk(KERN_ERR "btrfs: %d errors while writing
supers\n",
total_errors);
BUG();
}
in write_all_supers(). Does dmesg say anything about the nature of
the errors above the BUG() line?
- Chris.
--
Chris Ball <cjb@laptop.org>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi!> > Hi! I got a kernel BUG at > > > > fs/btrfs/disk-io.c:2311 > > > > when testing the 2.6.37-rc5 kernel today. > > It''s good to mention which line this is, since the line numbers are > always changing. This is: > > if (total_errors > max_errors) { > printk(KERN_ERR "btrfs: %d errors while writing supers\n", > total_errors); > BUG(); > } > > in write_all_supers(). Does dmesg say anything about the nature of > the errors above the BUG() line?The message was output to the console of the crashed system - so I''m sorry I cannot supply further informations. But exactly the same crash happened again some minutes ago. (I''m now back to my old kernel.) Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michael, >> in write_all_supers(). Does dmesg say anything about the nature >> of the errors above the BUG() line? > The message was output to the console of the crashed system - so > I''m sorry I cannot supply further informations. Ah, okay. You could consider installing kgdb/kdb -- it will let you drop to the kdb shell after the crash and run dmesg through a pager. Just: CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set CONFIG_KGDB_LOW_LEVEL_TRAP=y CONFIG_KGDB_KDB=y CONFIG_KDB_KEYBOARD=y and then boot with "kgdboc=kms,kbd" added. > But exactly the same crash happened again some minutes ago. (I''m > now back to my old kernel.) Not sure I understand. Do you mean that the same crash happens on your older kernel now, or that you''ve reverted to your older kernel because you had another -rc5 crash? If the crash happens on -rc5 but not the older kernel (what revision is the older kernel?), that''s extremely interesting. Josef/Chris, any knowledge about hitting this BUG() on -rc5? - Chris. -- Chris Ball <cjb@laptop.org> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Chris!> > But exactly the same crash happened again some minutes ago. (I''m > > now back to my old kernel.) > > Not sure I understand. Do you mean that the same crash happens on > your older kernel now, or that you''ve reverted to your older kernel > because you had another -rc5 crash? If the crash happens on -rc5 but > not the older kernel (what revision is the older kernel?), that''s > extremely interesting.It happened again on -rc5. But the reason for the crashes could also be a hardware problem - today I used (unintentionally) another USB-port (USB 2.0) for the drive containing the btrfs-file-system then I used (for several month) before (USB 3.0). Currently I''m running with -rc7. If the system still runs tomorrow morning I will do another test with -rc5 - this time on the USB 3.0 port. This should show whether this is a hardware or software problem. Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, > Currently I''m running with -rc7. If the system still runs > tomorrow morning I will do another test with -rc5 - this time on > the USB 3.0 port. This should show whether this is a hardware or > software problem. Thanks, sounds good. Yes, the location of the BUG() does suggest a hardware problem, assuming it''s coded correctly. dmesg would tell us for sure, because the I/O error would be reported above the BUG() output. - Chris. -- Chris Ball <cjb@laptop.org> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! It seems that in my case the bug (fs/btrfs/disk-io.c:2311) was caused by a hardware problem. I plugged by accident an usb-3.0-drive (that worked quite well for several weeks) into an usb-2.0-port (which worked quite well for several years). It seems that the two didn''t like each other and caused these crashes after some time of idling (it seems that the idling is necessary for the crash, cause it never crashed while I was actually working). Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Sat, 25 Dec 2010 10:50:28 +0100 schrieb "Michael Niederle" <mniederle@gmx.at>:> Hi! > > It seems that in my case the bug (fs/btrfs/disk-io.c:2311) was caused > by a hardware problem. > > I plugged by accident an usb-3.0-drive (that worked quite well for > several weeks) into an usb-2.0-port (which worked quite well for > several years). It seems that the two didn''t like each other and > caused these crashes after some time of idling (it seems that the > idling is necessary for the crash, cause it never crashed while I was > actually working). > > Greetings, Michaelyes looks the same case here too, I only wanted to point out that this has to be fixed *someday*, Retrying after a bus reset, mounting the filesystem readonly or block all IO on the filesystem, but not bring down the kernel. Christian -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html