From: Al Boldi <a1426z@gawab.com>
To: linux-kernel@vger.kernel.org
Subject: Re: LibPATA/ATA Errors Continue - Will there be a fix for this?
Date: Tue, 20 Jun 2006 18:15:54 +0300 [thread overview]
Message-ID: <200606201815.54318.a1426z@gawab.com> (raw)
Justin Piszcz wrote:
> On Tue, 20 Jun 2006, Mark Lord wrote:
> > Justin Piszcz wrote:
> >> Should someone comment this code out that produces the printk()'s as
> >> these are useless information as there is no problem with the disk?
> >
> > MMm.. probably "barrier" commands that the drive doesn't like.
> > Pity those messages don't also dump the failed opcode.
> >
> >> Jun 20 03:14:20 p34 kernel: [4339456.678000] ata3: status=0x51 {
> >> DriveReady SeekComplete Error }
> >> Jun 20 03:14:20 p34 kernel: [4339456.678000] ata3: error=0x04 {
> >> DriveStatusError }
> >> Jun 20 03:36:44 p34 kernel: [4340801.772000] ata3: no sense translation
> >> for status: 0x51
> >> Jun 20 03:36:44 p34 kernel: [4340801.772000] ata3: status=0x51 {
> >> DriveReady SeekComplete Error }
>
> Mark, what would be the proper direction to move towards? Is Jeff or
> another SATA/ATA maintainer going to have to look at this or is there
> something else I can do, or?
I once sent a patch to -mm:
Mark Lord wrote:
> Al Boldi wrote:
>> Also apply this one to get rid of this message:
>>
>> hdb: set_drive_speed_status: status=0x40 { DriveReady }
>> ide: failed opcode was: unknown
>>
>> Maybe someone on the ide list can comment on this first though.
>>
>> --- 16/include/linux/ide.h.orig 2006-03-31 19:12:51.000000000 +0300
>> +++ 16/include/linux/ide.h 2006-04-23 13:06:32.000000000 +0300
>> @@ -120,7 +120,7 @@ typedef unsigned char byte; /* used ever
>> #define IDE_BCOUNTL_REG IDE_LCYL_REG
>> #define IDE_BCOUNTH_REG IDE_HCYL_REG
>>
>> -#define OK_STAT(stat,good,bad) (((stat)&((good)|(bad)))==(good))
>> +#define OK_STAT(stat,good,bad) (((stat)&((good)|(bad)))==((stat)&(good)))
>> #define BAD_R_STAT (BUSY_STAT | ERR_STAT)
>> #define BAD_W_STAT (BAD_R_STAT | WRERR_STAT)
>> #define BAD_STAT (BAD_R_STAT | DRQ_STAT)
>
> Assuming hdb is a CDROM/optical drive, then this change makes sense for
> that. But I don't think it is a valid (good) change for regular ATA disks.
>
> A more complex patch is required, one which correctly handles each drive
> type.
Thanks!
--
Al
next reply other threads:[~2006-06-20 15:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 15:15 Al Boldi [this message]
2006-06-20 15:48 ` Justin Piszcz
2006-06-20 16:25 ` Mark Lord
-- strict thread matches above, loose matches on Subject: below --
2006-06-20 12:17 Justin Piszcz
2006-06-20 13:01 ` Mark Lord
2006-06-20 13:03 ` Justin Piszcz
2006-06-20 14:23 ` David Greaves
2006-06-20 15:45 ` David Greaves
2006-06-20 15:46 ` Justin Piszcz
2006-06-20 22:20 ` David Greaves
2006-06-20 22:22 ` Justin Piszcz
2006-06-21 11:39 ` Justin Piszcz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200606201815.54318.a1426z@gawab.com \
--to=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®