Evgeni Golov <sargentd@xxxxxxxxxxxx> wrote:
> On Wed, 05 Nov 2008 19:55:44 +0100 Elias Oltmanns wrote:
>
>> # hdparm --idle-immediate /dev/sda
>> # hdparm --idle-unload /dev/sda
>> # hdparm --idle-immediate /dev/sda
>> # echo 1000 > /sys/block/sda/device/unload_heads
>> # hdparm --idle-immediate /dev/sda
>
> Here come my test results:
>
[...]
> shinkupaddo# ./hdparm --idle-unload /dev/sda
>
> /dev/sda:
> issuing idle_immediate_unload command
> shinkupaddo# dmesg -c
> ata1.00: SError: 0x0
[...]
> shinkupaddo# echo 1000 > /sys/block/sda/device/unload_heads
> shinkupaddo# dmesg -c
> 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
> ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
> ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
> ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
> ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
> ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> ata1.00: configured for UDMA/100
> ata1.00: configured for UDMA/100
> ata1: EH complete
> sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors: (100 GB/93.1 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors: (100 GB/93.1 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[...]
> Any additional
> shinkupaddo# echo 1000 > /sys/block/sda/device/unload_heads
>
> Gives only
> ata1.00: SError: 0x0
Now there's an interesting thing. Even though these results don't
exactly confirm my theory I posted just now, they certainly do throw
some light on the matter. It looks to me as if the hard reset is not at
all related to head parking, after all. It's just that echo 1000 >
/sys/.../unload_heads triggers EH and during link autopsy some stale
phyrdy | commwake bits in SError are discovered and acted upon. As to
how those bits got set in the first place, I suspect that some other
action in a previous EH cycle triggered a phyrdy event that didn't get
cleared because event notification was disabled (see my earlier post). I
don't think this is expected behaviour and in particular I have no idea,
right now, what actually may have triggered this event, Tejun?
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
