From: Rusty Russell <rusty@rustcorp.com.au>
To: Andre Hedrick <andre@linux-ide.org>
Cc: Alan Cox <alan@redhat.com>,
linux-kernel@vger.kernel.org, Vojtech Pavlik <vojtech@suse.cz>
Subject: Re: [PATCH] Experimental IDE oops dumper v0.1
Date: Wed, 18 Sep 2002 14:19:53 +1000 [thread overview]
Message-ID: <20020918044012.C77212C075@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 17 Sep 2002 00:42:56 MST." <Pine.LNX.4.10.10209170028370.11597-100000@master.linux-ide.org>
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.
next prev parent reply other threads:[~2002-09-18 4:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-16 11:52 [PATCH] Experimental IDE oops dumper v0.1 Rusty Russell
2002-09-16 12:18 ` Alan Cox
2002-09-16 12:39 ` jbradford
2002-09-16 9:43 ` Rob Landley
2002-09-16 15:14 ` jbradford
2002-09-16 19:55 ` Vojtech Pavlik
2002-09-16 19:52 ` Vojtech Pavlik
2002-09-16 22:22 ` Alan Cox
2002-09-17 0:49 ` Rusty Russell
2002-09-17 7:42 ` Andre Hedrick
2002-09-17 9:57 ` Alan Cox
2002-09-18 4:19 ` Rusty Russell [this message]
2002-09-18 6:00 ` Andre Hedrick
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=20020918044012.C77212C075@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=alan@redhat.com \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/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