Tejun Heo wrote: > Simon Farnsworth wrote: >> From a machine that's just done this freeze: > [--snip--] >> BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted) >> [<c042afff>] local_bh_enable+0x45/0x96 >> [<c0603cde>] cond_resched_softirq+0x2d/0x43 >> [<c05d55bf>] established_get_first+0x17/0xac >> [<c05d8f93>] tcp_seq_next+0x71/0x86 >> [<c048c004>] seq_read+0x181/0x268 >> [<c048be83>] seq_read+0x0/0x268 >> [<c0476651>] vfs_read+0xab/0x15a >> [<c0476fb7>] sys_read+0x41/0x67 >> [<c0404ecc>] syscall_call+0x7/0xb >> ======================= > > Hmmmm.. This is the only suspicious looking part of the kernel log and > doesn't have too much to do with ATA freeze. 30sec - 2min delay sounds > awfully like something caused by ATA commands timing out but libata > always complains verbosely about those. Can you check dmesg again after > the freeze? > This is a dmesg output from after the freeze. On machines that don't freeze, the following appears in dmesg after the hdparm -W0 command: ata3.00: configured for UDMA/100 ata3: EH complete SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA Note that the freeze appears to be drive specific; we've seen it with SATA Samsung drives on ata_piix, and with newer PATA Maxtor drives on pata_via, but not with SATA Seagates on ata_piix, or with older PATA Maxtor drives on pata_via. Just a thought; is it possible to trigger libata EH from userspace? If so, we could write a small utility to disable write cache, then force EH to detect the change. -- Any ideas for resolving this are welcome. Simon Farnsworth - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
