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

[Tejun Heo <htejun@gmail.com>]

Simon Farnsworth wrote:
> 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.

That's automatically done.  libata snoops cache on/off and triggers
revalidation but you can request manual rescan by echoing "- - -" to
/sys/class/scsi_host/hostX/scan.

-- 
tejun