Re: Odd behaviour of device in response to idleimmediate with unload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Evgeni Golov <sargentd@xxxxxxxxxxxx> wrote:
> On Mon, 10 Nov 2008 12:35:20 +0100 Elias Oltmanns wrote:
>
>> Evgeni Golov <sargentd@xxxxxxxxxxxx> wrote:
>> > On Mon, 10 Nov 2008 18:00:18 +0900 Tejun Heo wrote:
>> >
>> >> Is the phy event before or after head unloading?
>> >
>> > How do I check this?
>> 
>> # dmesg
>> # echo 3000 > /sys/block/sda/device/unload_heads &
>> # dmesg
>> 
>> The first call to dmesg is only to make sure that it is in the cache so
>> the second won't be blocked by the park request.
>
> Okay, I get the following as soon I issue unload:
> ata1: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
> ata1: SError: { PHYRdyChg CommWake }
> ata1: hard resetting link
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: SError: 0x0
>
> The rest comes a bit later.

Right, that settles it: the reset sequence is initiated even before the
unload command is issued for the first time. This means that head
parking is not part of the picture except for the fact that it provides
the means to initiate EH from userspace and makes the problem easily
reproducible. On the other hand, it remains to be a mystery to me what
actually sets those bits in SError in the first place without event
notification taking care of it. I'll have to think about this for a
while. Perhaps Tejun has another idea?

Regards,

Elias
--
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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux