Re: [PATCH] Experimental IDE oops dumper v0.1

[Andre Hedrick]

On Wed, 18 Sep 2002, Rusty Russell wrote:

> In message <[e-mail]> 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.

You may pull this off on /dev/hda or /dev/hdb, but Linux has set a policy
to default to CHS regardless if LBA should be used.  What really needs to
be fixed is to default to LBA and not CHS.  The problem is everybody will
scream bloody murder.

This is why 48-bit devices killed CHS, it is too brain dead to survive but
for the life of me it continues.

> 
> 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.

Heads up!

If the device is 48-bit capable, but the swap area to dump to is inside
the 28-bit addressable region, you can call it with 28-bit commands.

> 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.

OIC, that is nice to know you are not able to tank the driver even when
abusing it.

> Thanks for reading,
> Rusty.
> --
>   Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
> 

Andre Hedrick
LAD Storage Consulting Group