Messages in this thread | | | Date | Tue, 17 Sep 2002 23:00:41 -0700 (PDT) | From | Andre Hedrick <> | Subject | Re: [PATCH] Experimental IDE oops dumper v0.1 |
| |
On Wed, 18 Sep 2002, Rusty Russell wrote:
> 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.
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
- 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/
| |