Re: Scary Intel SATA problem: "frozen"

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

 



On 11/28/06, Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> wrote:
Hello.

Mark Lord wrote:

> Bit #4, when actually implemented, is a rotational seek indicator,
> which can be used for timing purposes.

    Hm, I thought it was DSC (drive seek complete) set by the SEEK command
completion, and it's always implemented. Didn't you mean IDX (bit 1, IIRC)?

0x50 is the standard, non queueing "device is ready" status.  It used
to have those special meanings, but they're pretty obsolete today as I
understand it.

0x40 is used for queueing, because bit 4 was the service bit for PATA TCQ.

> But when BUSY (bit #7) is set, the rest are generally nonsense.

    Indeed...

WBR, Sergei

Typically, 0x80 as the busy state indicates the device is in POR
reset.  Once the firmware is up and running in the device, it often
switches from 0x80 to 0xD0 during POR.

0xD0 is the busy state you'd get to if you were 0x50 and received a
command, so this is reported typically after the device is up and
running.

0x7F usually is hardware indicating nothing is attached to the port,
and isn't supposed to infer a non-busy state.

You're right, while not meaningful according to spec, you can derive
some information from the reported status even when you're only
supposed to look at one bit.
-
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