EDD enhanchement patch

This patch add support for DTPE data in EDD and mbr_signature. This patch do not solve fdisk problems but can help these programs to compute correct head count.

freddy77

Thanks!

(Please, do not gzip - it is much easier to look at the patch when it is not gzipped, and not hidden in an attachment. Also for later, for searching things with Google or so, simple letters are preferable.)

See that Matt Domsch looked at the code. Good. He wrote
"I don't think this is quite ready to include yet,
but I'm not philosophically opposed to it, so let's work it out. First, I want to understand what information in the DPTE you need. I assume byte offset 4, bit 6 (LBA enable), and bytes 10-11 bit 3 (CHS translation enabled) and bit 4 (LBA translation enabled), yes? How are you expecting tools like fdisk to use this information?"

Let me give my answers. No I am not opposed to it, philosophically
or otherwise. It is easiest not to think about what parts might be useful - next week you might think of some other use. Just fetch all available information and make it available to user space without looking at it. (There is a checksum. A revision number. A bit "removable". A Master/Slave bit...)

All this stuff is not very useful. But in some cases it helps.

Long ago I did something similar. Let me see whether I can retrieve that. Ah, yes. "Collection of BIOS disk info, aeb, Feb 1999"
See http://ftp.cwi.nl/aeb/getbios/2.2.2.patch-HDIO_GETBIOS

+! Try to collect all disk information the BIOS can give us. +! Such information is difficult to interpret:
+! We don't know whether hd0, hd1, ... are IDE or SCSI disks. +! Some disks may not be mentioned in the BIOS setup and will +! probably not be seen here.
+! So, instead of trying to make sense of this, we make the +! collected information available by ioctl to user space. +!
+! Layout collected disk data (where DD stands for disk_data) +! 0x0080-0x008f: hd0 data, from int 41
+! 0x0090-0x009f: hd1 data, from int 46
+! DD[0x000-0x02f]: data following int 41 table, possibly hd1..3 +! DD[0x030-0x0af]: hd0..15 geometry, from int 13, fn 15, 8 +! DD[0x0b0-0x1f8]: hd0..3 Phoenix data, from int 13, fn 41,48 +! Phoenix data has extensive info but takes a lot of space +! For the moment for 4 disks only

It looks like this is about what Matt and Patrick and you have. Matt also has something new and very useful: these 4-byte disk signatures. As additional info I had this "data following int 41 table". Marginally useful, but it sometimes helps.

There is a difference in philosophy: I made all of the garbage extracted from the BIOS available to user space without any attempt at validating or interpreting it in the kernel. A user space routine sniffed the data and tried to construct the BIOS-Linux disk correspondence, using ordering and sizes and geometry of the disks.

I never pushed this - had hoped for something that would identify the correspondence with high probability, but the results were disappointing.

Not many BIOSes implemented Phoenix 3.0, so the much better data provided by that did not help so much.

I saw mail by Matt Domsch two weeks ago or so, saying "I've got a huge number of reports, and virtually all show that EDD 3.0 is not supported, or if supported, is likely implemented in ways contrary to the spec."
So, it seems things have not improved much in these five years.

Of course, one can do a much better job when disk I/O is allowed. For example, read the first 256 sectors and compute an md5sum. Reading the MBR signature falls into this category.

There are complications for RAID, even when EDD 3.0 is supported.

Andries

An example.
------------------------------------------------------------------------------------

hd0:  C/H/S= 1020/200/62
hd1:  C/H/S= 1024/255/63
hd00: C/H/S= 1024/255/63
hd01: garbage
hd02: garbage
disk 0: len=0
disk 1: len=0
disk 2: len=0
disk 3: len=0

Found 7 Linux disks

hda: Size  33750864 LinuxCHS=2721/200/62 FdiskCHS=-/16/63
  LBASize  33750864 CurSize  33750864  RawCHS=33483/16/63 CurCHS=2721/200/62
hdb: Size  23547888 LinuxCHS=23361/16/63 FdiskCHS=-/16/63
  LBASize  23547888 CurSize  23547888  RawCHS=23361/16/63 CurCHS=23361/16/63

hdc: Size 417792 LinuxCHS=1024/12/34 FdiskCHS=-/12/34
LBASize 0 CurSize 417792 RawCHS=1024/12/34 CurCHS=1024/12/34
sda: Size 12657717 LinuxCHS=1020/200/62 FdiskCHS=-/200/62
sdb: Size 17755792 LinuxCHS=8669/64/32 FdiskCHS=-/0/0
sdc: Size 4226725 LinuxCHS=2063/64/32 FdiskCHS=-/64/32
sdd: Size 3517856 LinuxCHS=1717/64/32 FdiskCHS=-/64/32

Found 5 BIOS disks

0 of 5: 12648000 sectors, C/H/S 1020 / 200 / 62 OK
1 of 5: 16450560 sectors, C/H/S 1024 / 255 / 63 OK
2 of 5: 2097152 sectors, C/H/S 1024 / 64 / 32 OK
3 of 5: 2097152 sectors, C/H/S 1024 / 64 / 32 OK
4 of 5: 4292876420 sectors, C/H/S 1023 / 16 / 63 C*H*S=1031184

hda: 0x84?
hdb: 0x84?
hdc:not in BIOS
sda: 0x80
sdb: 0x81
sdc: 0x82
sdd: 0x83

This is a machine booted from SCSI with

hda: Maxtor 91728D8, 16479MB w/512kB Cache, CHS=2721/200/62, (U)DMA

        RawCHS=16383/16/63, CurCHS=16383/16/63, CurSects=16514064, LBAsects=33750864
hdb: QUANTUM Bigfoot TX12.0AT, 11497MB w/69kB Cache, CHS=23361/16/63, (U)DMA
        RawCHS=16383/16/63, CurCHS=16383/16/63, CurSects=16514064, LBAsects=23547888
hdc: ST3243A, 204MB w/32kB Cache, CHS=1024/12/34
        RawCHS=1024/12/34, LBA=no.

hd0 reports sda (and the kernel mistakes it for hda) hd1 reports sdb, I suppose
------------------------------------------------------------------------------------

This was an example without INT 13 extensions. One with:

------------------------------------------------------------------------------------
disk 0: len=26
flags 0, phys CHS 0/0/0, totsecs 12594960, seclen 512 disk 1: len=26
flags 0, phys CHS 0/0/0, totsecs 6306048, seclen 512 disk 2: len=26
flags 0, phys CHS 0/0/0, totsecs 13269690, seclen 512 disk 3: len=26
flags 0, phys CHS 0/0/0, totsecs 13269690, seclen 512

Found 5 Linux disks

hda: Size 12594960 LinuxCHS=13328/15/63 FdiskCHS=-/0/63
LBASize 12594960 CurSize 12594960 RawCHS=13328/15/63 CurCHS=13328/15/63
hdb: Size 6306048 LinuxCHS=782/128/63 FdiskCHS=-/128/63
LBASize 6306048 CurSize 6306048 RawCHS=6256/16/63 CurCHS=782/128/63

hdc: Size  13281408 LinuxCHS=13176/16/63 FdiskCHS=-/0/63
  LBASize  13281408 CurSize  13281408  RawCHS=13176/16/63 CurCHS=13176/16/63
hdd: Size  13281408 LinuxCHS=13176/16/63 FdiskCHS=-/0/0
  LBASize  13281408 CurSize  13281408  RawCHS=13176/16/63 CurCHS=13176/16/63

hdh: Size 196608 LinuxCHS=32/64/96 FdiskCHS=-/0/0
LBASize 0 CurSize 0 RawCHS=0/0/0 CurCHS=0/0/0

Found 8 BIOS disks

0 of 4: 12578895 sectors, C/H/S 783 / 255 / 63 OK
1 of 4: 6297984 sectors, C/H/S 781 / 128 / 63 OK
2 of 4: 13253625 sectors, C/H/S 825 / 255 / 63 OK
3 of 4: 13253625 sectors, C/H/S 825 / 255 / 63 OK

4 of 4:      20740 sectors, C/H/S 305 / 4 / 17 OK
5 of 4:      20740 sectors, C/H/S 305 / 4 / 17 OK
6 of 4:      20740 sectors, C/H/S 305 / 4 / 17 OK
7 of 4:      20740 sectors, C/H/S 305 / 4 / 17 OK

hda: 0x80?
hdb: 0x81
hdc: 0x80? 0x82? 0x83?
hdd: 0x80? 0x82? 0x83?
hdh:not in BIOS

Here the IBM extensions report the same size as Linux does
for the Quantum Fireballs, but for the Maxtors we have:
Linux 13281408, IBM extensions 13269690, BIOS 13253625.
The BIOS value is derived from 825*255*63, the IBM extensions value from 826*255*63, so that the BIOS here decides that the last cylinder is a test cylinder.
The BIOS did not return an error when we asked for disks 4-7 but says that there are only 4 disks (0-3), and the data for 4-7 is not meaningful. Thus, Ralf Brown (INT 13, AH=8) is incomplete when he suggests to use INT 13, AH=15 to check on INT 13, AH=8: in this case both succeeded.
--------------------------------------------------------------------------------

I can imagine that we sooner or later would like to have a preinitrd, configurable, describing all things that should be done in real mode before actually starting the kernel. The main problem would be how to communicate.

Il mer, 2004-07-07 alle 19:40, Andries Brouwer ha scritto:

Updated online patch sent.

Did anyone forget about first fields? base-port and control-port ? It you have an IDE disks they correspond with IDE port and with slave bit you can know exactly witch disk is. EDD 3.0 it's not required cause it's EDD 2.0 (supported by most recent BIOSes).

2.4 read also CMOS. Just a bit of story: first BIOSes only support fixed disks settings. Later on they introduced dynamic settings (manually enter physical C/H/S values). EIDE introduce C/H/S detection. When disks raise in size BIOSes introduced C/H/S translation. Newer BIOS introduced setting to select if init first SCSI or IDE, which IDE disk to start, cdrom, USB, LS-120 and even pcmcia!! SCSI it's always a BIOS extension (another peace of code) even if integrated on motherboard. Usually BIOS assign disk number in order (hda that hdb and so on).

Good. However HDIO_GETGEO still report a type of information that Linux do not prefer..

Did you refer to RAID IDE where the controller store informations on disks??

1020/200/62 matches exactly so it's
sda <-> 0x80
For order we should continue with SCSI. Also 0x82 and 0x83 match exactly with sdc and sdd and you can exclude IDE (translation always use higher values), so it's
sdb <-> 0x81
sdc <-> 0x82
sdd <-> 0x83

For 0x84 it must be cause it's the first IDE.
I know that some boot loader can however change disk order. Does anyone know how they can do this? Is there a BIOS interface for this purpose?

I know Ralf Brown's list is remembered as a bible however I don't think Ralf can collect all BIOSes bug in PC story :)

I already see this "test cylinder" before..

Here Linux has some problem with hdh..
hdh: Size 196608 LinuxCHS=32/64/96 FdiskCHS=-/0/0
LBASize 0 CurSize 0 RawCHS=0/0/0 CurCHS=0/0/0
lba 0 ?? cursize 0 ?? sector > 63 ??
IMHO this disk doesn't exist...

hdb must be 0x81 (no 1024 limit and LBA match) hda must be 0x80 (LBA size and 825 / 255 / 63 can't fit) hdc 0x82 and hdd 0x83 just for order...

A good way would be to call int13 from Linux a emulated real-mode and catch port used (not that easy however...).

Here I really don't catch you...
initrd it's executed after kernel init, before real mode there is only setup.S code (and it starts before kernel).

freddy77

True. Below a simple example for hda and hdb.
Yes, having EDD 2.0 helps.

It was hdh: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive, with geometry (probably 96/64/32, don't know why C and S are interchanged) obtained from HDIO_GET_IDENTITY.

hda or hdb. Since that system boots from SCSI there is no reason to prefer seeing the first or second IDE disk in the BIOS setup. (Don't know anymore what the truth was.)

Also Linux can change disk order with boot option "ide=reverse".

Andries

----------------------------------------------------------------------------------------
disk 0: len=30 api=0x1
flags 2, phys CHS 2100/255/63, totsecs 33736500, seclen 512
iobase 0x1f0 controlport 0x3f6 irq 14 sector_count 16 dma 32 pio 4
flags: 0xe0: LBA, Master; revision 1.1

disk 1: len=30 api=0x1
flags 2, phys CHS 2100/255/63, totsecs 33736500, seclen 512
iobase 0x1f0 controlport 0x3f6 irq 14 sector_count 16 dma 32 pio 4
flags: 0xf0: LBA, Slave; revision 1.1

Found 2 Linux disks

hda: Size  33750864 LinuxCHS=2100/255/63 FdiskCHS=*/0/63
  LBASize  33750864 CurSize  33750864  RawCHS=33483/16/63 CurCHS=2100/255/63
hdb: Size  33750864 LinuxCHS=2100/255/63 FdiskCHS=*/255/63
  LBASize  33750864 CurSize  33750864  RawCHS=33483/16/63 CurCHS=2100/255/63

Found 2 BIOS disks

0 of 2: 33720435 sectors, C/H/S 1024 / 255 / 63 C*H*S=16450560
1 of 2: 33720435 sectors, C/H/S 1024 / 255 / 63 C*H*S=16450560

hda: 0x80
hdb: 0x81
----------------------------------------------------------------------------------------