Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 17 Dec 2003 11:16:04 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: 2.6 and IDE "geometry" |
| |
On Wed, 17 Dec 2003, Wakko Warner wrote:
> > > I believe parted does not. Nor any of the libparted frontends. I may be > > > wrong though. > > > > If so, I consider it a missing feature in parted - why should the BIOS > > geometry resemble the disk it describes at all? Some machines have no > > user-definable drive types, forcing you to use an incorrect geometry > > if you install a disk which is not in the table of supported drives. > > > > This is no problem for recent Linux kernels, and doesn't even prevent > > you booting from that disk. > > I think noone has really understood why I want it. The machines in question > will not ever boot linux from the hard disk. Only from the CD that I built. > The OS that is installed from the CD is one of the windows OSs which depend > on the bios geometry definition to boot properly. The kernel doesn't care > about the geometry, that's all well and good except when I create the > partitions. Most of the pcs I work with use */255/63 notation, > occasionally, I'll come across one that uses */128/63 notation. Never one > with */16/63 notation. The smallest disk I work with would be a 1.2gb disk. > > I have tried to make this CD as simple to use as possible, which means > passing the geometry on the command line is out of the question and setting > it for every invocation of *fdisk is pretty much out as well. I liked the > "bogus bios"geometry the kernel was able to get from the bios. Out of the > hundreds of PCs I've used this on, not one has ever failed me. > > I have stuck with 2.4.x for now, but at some point, it'll have to be > upgraded due to hardware support. 2.4 will eventtually become with 2.0 is > now, stable, no new drives, only critial bug fixes. As time progresses, the > kernel will not support newer hardware (For instance network drivers which > is used havily in this CD as well). > > All I really want is to beable to get the kernel to get the bios parameters > for me. If this means a patch or something, that's fine. (I don't know > anything about the ide drivers to do this) > > This CD has made my life easier at my job and it's not something I want to > give up while I still have this job =) >
The problem is that this phony geometry is only available in "real-mode" from the BIOS. One needs to execute interrupt 0x13, function-code 0x15, to get a pointer to the drive parameter table. This is all 16-bit, BIOS residual stuff. In the "olden- days" Linux had an "elevator" procedure for ordering read/writes to drives. This required that Linux "know" about the geometry. Once developers learned that the drives "know" better than anybody else how to order reads/writes, this code was removed. The code necessary to get the drive parameters from the BIOS, when still in real-mode, was also removed because it has no use anymore.
So, if you need to use that BIOS information now, you really need to write it down. It's really that simple. Certainly you don't expect an operating system to retrieve parameters upon startup that might be useful to another operating system, do you? If you MUST get that information for a program, you can still get that information, but YOU, not the operating system, needs to get it.
There are major problems obtaining this real-mode information even from a custom driver (module). However, the old interrupt table remains, starting at offset 0. Each table entry contains an offset and a segment (4 bytes). You can therefore take 0x15 and shift it left twice to get the offset into the interrupt table. Most of the segments will be 0x40. The offset will be the offset off the segment value (0x40). That's 16 times 0x40 = 0x400. You add the offset to that, to get the absolute offset of the table from C:, from a BIOS book, you can find what each of the table entries mean. These can be returned to your program. You actually don't need a driver to do this, you can mmap() offset 0 without any NULL-pointer problems. My simple debugger does this (like DOS debug, but 32-bit mode). Note that Intel has the low byte in the lowest memory location, also the lowest word is in the lowest memory location.
0x15 * 4 = 0x54
Script started on Wed Dec 17 11:03:15 2003 # ./debug -d 0 00000000 01 00 00 00 6F EF 00 F0-C3 E2 00 F0 6F EF 00 F0 ....o.......o... 00000010 6F EF 00 F0 54 FF 00 F0-08 80 00 F0 6F EF 00 F0 o...T.......o... 00000020 A5 FE 00 F0 87 E9 00 F0-6F EF 00 F0 6F EF 00 F0 ........o...o... 00000030 6F EF 00 F0 6F EF 00 F0-57 EF 00 F0 6F EF 00 F0 o...o...W...o... 00000040 75 57 00 C0 4D F8 00 F0-41 F8 00 F0 64 25 00 C8 uW..M...A...d%.. 00000050 39 E7 00 F0 59 F8 00 F0-2E E8 00 F0 D2 EF 00 F0 9...Y........... ^^^^^^^^^^^ Table is at f000:f859 = ff859
00000060 A4 E7 00 F0 F2 E6 00 F0-6E FE 00 F0 53 FF 00 F0 ........n...S... 00000070 53 FF 00 F0 A4 F0 00 F0-C7 EF 00 F0 C8 5B 00 C0 S............[.. 00000080 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 00000090 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000A0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000B0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000C0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000D0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000E0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... 000000F0 6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0 o...o...o...o... -q # exit exit Script done on Wed Dec 17 11:04:11 2003
Cheers, Dick Johnson Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction.
- 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/
| ![\](/images/icornerr.gif) |