Neil Brown wrote:
Ok, so the difference is CONFIG_SYSFS_DEPRECATED. If that is not
defined, the kernel locks up. There's not a lot of code under
#ifdef/#ifndef CONFIG_SYSFS_DEPRECATED, but since I'm not familiar with
any of it I don't expect trying to locate the bug on my own would be
very
Corey Hickey wrote:
When I get home (late) tonight I'll try running dd and badblocks on the
corresponding drives and partitions.
Well, I haven't been able to reproduce the problem that way. I tried the
following:
$ dd id=/dev/hda of=/dev/null
$ badblocks /dev/hda
$ badblocks -n /dev/hda
On Thursday February 15, [EMAIL PROTECTED] wrote:
I think I have found an easily-reproducible bug in Linux 2.6.20. I have
already applied the Fix various bugs with aligned reads in RAID5
patch, and that had no effect. It appears to be related to the resync
process, and makes the system lock
Neil Brown wrote:
On Thursday February 15, [EMAIL PROTECTED] wrote:
I think I have found an easily-reproducible bug in Linux 2.6.20. I have
already applied the Fix various bugs with aligned reads in RAID5
patch, and that had no effect. It appears to be related to the resync
process, and makes
Neil Brown wrote:
On Thursday February 15, [EMAIL PROTECTED] wrote:
I think I have found an easily-reproducible bug in Linux 2.6.20. I have
already applied the Fix various bugs with aligned reads in RAID5
patch, and that had no effect. It appears to be related to the resync
process, and makes
I think I have found an easily-reproducible bug in Linux 2.6.20. I have
already applied the Fix various bugs with aligned reads in RAID5
patch, and that had no effect. It appears to be related to the resync
process, and makes the system lock up, hard.
The steps to reproduce are:
1. Be running
