lkml.org 
[lkml]   [2004]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: ide errors in 7-rc1-mm1 and later
    Date
    On Friday 04 of June 2004 14:01, Jens Axboe wrote:
    > On Fri, Jun 04 2004, Bartlomiej Zolnierkiewicz wrote:
    > > On Friday 04 of June 2004 13:32, Jens Axboe wrote:
    > > > On Fri, Jun 04 2004, Ed Tomlinson wrote:
    > > > > On June 4, 2004 05:42 am, Jens Axboe wrote:
    > > > > > On Thu, Jun 03 2004, Andrew Morton wrote:
    > > > > > > Ed Tomlinson <edt@aei.ca> wrote:
    > > > > > > > Hi,
    > > > > > > >
    > > > > > > > I am still getting these ide errors with 7-rc2-mm2. I get the
    > > > > > > > errors even if I mount with barrier=0 (or just defaults). It
    > > > > > > > would seem that something is sending my drive commands it does
    > > > > > > > not understand...
    > > > > > > >
    > > > > > > > May 27 18:18:05 bert kernel: hda: drive_cmd: status=0x51 {
    > > > > > > > DriveReady SeekComplete Error } May 27 18:18:05 bert kernel:
    > > > > > > > hda: drive_cmd: error=0x04 { DriveStatusError }
    > > > > > > >
    > > > > > > > How can we find out what is wrong?
    > > > > > > >
    > > > > > > > This does not seem to be an error that corrupts the fs, it just
    > > > > > > > slows things down when it hits a group of these. Note that
    > > > > > > > they keep poping up - they do stop (I still get them hours
    > > > > > > > after booting).
    > > > > > >
    > > > > > > Jens, do we still have the command bytes available when this
    > > > > > > error hits?
    > > > > >
    > > > > > It's not trivial, here's a hack that should dump the offending
    > > > > > opcode though.
    > > > >
    > > > > Hi Jens,
    > > > >
    > > > > I applied the patch below and booted into the new kernel (the boot
    > > > > message showed the new compile time). The error messages remained
    > > > > the same - no extra info. Is there another place that prints this
    > > > > (or (!rq) is true)?
    > > >
    > > > !rq should not be true, strange... are you sure it just doesn't to go
    > > > /var/log/messages, it should be there in dmesg. Alternatively, add a
    > > > KERN_ERR to that printk.
    > >
    > > Probably !rq is true.
    >
    > Don't think so, see my other mail. It's the crap duplicate dump_status()
    > functions.
    >
    > > Hint: this is what you get for playing tricks with hwrgroup->wrq
    > > (do you now understand why it is evil?).
    >
    > Oh give it up, the code is complete crap in so many places as it is.
    > ->rq would just point to &wrq instead. Testament to how hard it is just

    Yep, you are right, sorry.

    > to provide a dump opcode (and that you missed it to) is how convoluted
    > it is. And almost a handful of different command types, with as many
    > ways to submit it.
    >
    > This is not blaming you btw, just the code. You've done some nice
    > cleanups. The main culprit is no longer active :)

    Well, thanks but I still think that your patch suits crappy code perfectly
    (you know all the complains).

    Cheers,
    Bartlomiej

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:2.493 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site