Re: Freeze after disabling write cache with hdparm -W0 /dev/sda

[Simon Farnsworth <simon.farnsworth@onelan.co.uk>]

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