This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when
This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when
Robert Hancock wrote:
The ATA ones are more of a pain in that regard than SCSI though - SCSI
has all distinct error codes for different errors, whereas ATA has
bitmasks for everything..
That should not affect implementation. Either way, a table-driven
approach can easily work.
I favor
Tejun Heo wrote:
Chuck Ebbert wrote:
Robert Hancock wrote:
+ ehc->i.serror & SERR_TRANS_ST_ERROR ? "TransStatTransErr "
: "",
+ ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecogFIS " : "",
+ ehc->i.serror & SERR_DEV_XCHG ? "DevExchanged " : "" );
I'm not really convinced
Chuck Ebbert wrote:
> Robert Hancock wrote:
+ ehc->i.serror & SERR_TRANS_ST_ERROR ? "TransStatTransErr "
: "",
+ ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecogFIS " : "",
+ ehc->i.serror & SERR_DEV_XCHG ? "DevExchanged " : "" );
>>> I'm not really
Robert Hancock wrote:
>>> + ehc->i.serror & SERR_TRANS_ST_ERROR ? "TransStatTransErr "
>>> : "",
>>> + ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecogFIS " : "",
>>> + ehc->i.serror & SERR_DEV_XCHG ? "DevExchanged " : "" );
>>
>> I'm not really convinced whether this is
Robert Hancock wrote:
+ ehc-i.serror SERR_TRANS_ST_ERROR ? TransStatTransErr
: ,
+ ehc-i.serror SERR_UNRECOG_FIS ? UnrecogFIS : ,
+ ehc-i.serror SERR_DEV_XCHG ? DevExchanged : );
I'm not really convinced whether this is necessary. The human readable
form
Chuck Ebbert wrote:
Robert Hancock wrote:
+ ehc-i.serror SERR_TRANS_ST_ERROR ? TransStatTransErr
: ,
+ ehc-i.serror SERR_UNRECOG_FIS ? UnrecogFIS : ,
+ ehc-i.serror SERR_DEV_XCHG ? DevExchanged : );
I'm not really convinced whether this is necessary. The
Tejun Heo wrote:
Chuck Ebbert wrote:
Robert Hancock wrote:
+ ehc-i.serror SERR_TRANS_ST_ERROR ? TransStatTransErr
: ,
+ ehc-i.serror SERR_UNRECOG_FIS ? UnrecogFIS : ,
+ ehc-i.serror SERR_DEV_XCHG ? DevExchanged : );
I'm not really convinced whether this is
Robert Hancock wrote:
The ATA ones are more of a pain in that regard than SCSI though - SCSI
has all distinct error codes for different errors, whereas ATA has
bitmasks for everything..
That should not affect implementation. Either way, a table-driven
approach can easily work.
I favor
> Scrollback rarely works as planned, for me. Overall, a balance must be
> found.
>
> More information is more helpful. But.
>
> There are downsides to spewing everything possible, upon error. You
> cause logging to the possibly problematic disk, you push older messages
> out of the printk
Robert Hancock wrote:
I don't think this is as big of a deal here as in other cases, like oops
output. With libata errors, if they're at the console (which they'd have
to be to see these messages), unless something has actually caused a
panic the scrollback buffer should still be functional
Jeff Garzik wrote:
Mark Lord wrote:
If we're compiling the messages into the kernel regardless,
then it doesn't really make much sense to NOT show all of them
on the error paths.
Not true. Uncontrolled message spewage inevitably results in critical
information scrolling off the screen,
Tejun Heo wrote:
+if (ehc->i.serror)
+ata_port_printk(ap, KERN_ERR,
+ "SError: {%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s}\n",
+ ehc->i.serror & SERR_DATA_RECOVERED ? "RecovDataErr " : "",
+ ehc->i.serror & SERR_COMM_RECOVERED ? "RecovCommErr " : "",
+
Mark Lord wrote:
If we're compiling the messages into the kernel regardless,
then it doesn't really make much sense to NOT show all of them
on the error paths.
Not true. Uncontrolled message spewage inevitably results in critical
information scrolling off the screen, before a user can take
Jeff Garzik wrote:
Mark Lord wrote:
Same here, but I would like to see it in there under a
CONFIG_DEBUG_LIBATA
kernel build option or something. Kind of like the
"FANCY_STATUS_DUMPS" flag
that drivers/ide used to have for this kind of stuff.
The long term goal is to enable verbose output
Mark Lord wrote:
Same here, but I would like to see it in there under a CONFIG_DEBUG_LIBATA
kernel build option or something. Kind of like the "FANCY_STATUS_DUMPS"
flag
that drivers/ide used to have for this kind of stuff.
The long term goal is to enable verbose output with a module option
Tejun Heo wrote:
Robert Hancock wrote:
This adds human-readable decoding of the ATA status and error registers
(similar
to what drivers/ide does) as well as the SATA Serror register to libata
...
I'm not really convinced whether this is necessary. The human readable
form is also a bit
Robert Hancock wrote:
> This adds human-readable decoding of the ATA status and error registers
> (similar
> to what drivers/ide does) as well as the SATA Serror register to libata
> error
> handling output. This prevents the need to pore through standards documents
> to figure out the meaning of
Robert Hancock wrote:
This adds human-readable decoding of the ATA status and error registers
(similar
to what drivers/ide does) as well as the SATA Serror register to libata
error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the
Tejun Heo wrote:
Robert Hancock wrote:
This adds human-readable decoding of the ATA status and error registers
(similar
to what drivers/ide does) as well as the SATA Serror register to libata
...
I'm not really convinced whether this is necessary. The human readable
form is also a bit
Mark Lord wrote:
Same here, but I would like to see it in there under a CONFIG_DEBUG_LIBATA
kernel build option or something. Kind of like the FANCY_STATUS_DUMPS
flag
that drivers/ide used to have for this kind of stuff.
The long term goal is to enable verbose output with a module option
Jeff Garzik wrote:
Mark Lord wrote:
Same here, but I would like to see it in there under a
CONFIG_DEBUG_LIBATA
kernel build option or something. Kind of like the
FANCY_STATUS_DUMPS flag
that drivers/ide used to have for this kind of stuff.
The long term goal is to enable verbose output
Mark Lord wrote:
If we're compiling the messages into the kernel regardless,
then it doesn't really make much sense to NOT show all of them
on the error paths.
Not true. Uncontrolled message spewage inevitably results in critical
information scrolling off the screen, before a user can take
Tejun Heo wrote:
+if (ehc-i.serror)
+ata_port_printk(ap, KERN_ERR,
+ SError: {%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s}\n,
+ ehc-i.serror SERR_DATA_RECOVERED ? RecovDataErr : ,
+ ehc-i.serror SERR_COMM_RECOVERED ? RecovCommErr : ,
+ ehc-i.serror
Jeff Garzik wrote:
Mark Lord wrote:
If we're compiling the messages into the kernel regardless,
then it doesn't really make much sense to NOT show all of them
on the error paths.
Not true. Uncontrolled message spewage inevitably results in critical
information scrolling off the screen,
Robert Hancock wrote:
I don't think this is as big of a deal here as in other cases, like oops
output. With libata errors, if they're at the console (which they'd have
to be to see these messages), unless something has actually caused a
panic the scrollback buffer should still be functional
Scrollback rarely works as planned, for me. Overall, a balance must be
found.
More information is more helpful. But.
There are downsides to spewing everything possible, upon error. You
cause logging to the possibly problematic disk, you push older messages
out of the printk ring
This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when
This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when
30 matches
Mail list logo
