lkml.org 
[lkml]   [2002]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Experimental IDE oops dumper v0.1
Date
In message <Pine.LNX.4.10.10209170028370.11597-100000@master.linux-ide.org> you
write:
> > if (!(hdid.capability & (1 << 1))) {
> > fprintf(stderr, "Drive does not support LBA\n");
> > exit(1);
> > }
>
> Wrong answer, you do CHS.

I can't test that, so safe answer is to refuse to arm the oopser.
Since LBA is most common, that's my first priority.

> > The code always does a read sector then a write: if the sector doesn't
> > contain the right magic, it stops. But the more robust the better.
>
> You need a read-modify-write caller.
> You need to remember setfeatures need to be hammered on flushcache and
> writecache disabled.
> You need to be able to walk your buffer and best only if you do single
> sector transactions and not multimode.
>
> > Patches appreciated 8)
>
> I'll try, but time is tight for me.

Me too 8(. The oopser is allowed to (a) refuse to arm at arming time,
or (b) refuse to dump at dumping time, but it'd be nice if it worked
on the widest range of stuff possible (ie. CHS and LBA48 at least).
Of course, it can't use any external routines, and must be small too.

The IDE layer does a great job (on my hardware) from recovering after
we rudely steal the device from it, but no doubt the oopser could be
nicer about it.

Thanks for reading,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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 12:52    [W:0.052 / U:9.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site