I am working on a Linux-based boot disk for my project (http://unattended.sourceforge.net/), and I have hit a snag. Under Linux 2.6, the kernel (via HDIO_GETGEO) always reports the C/H/S geometry of an IDE drive as X/16/63. But most BIOSes want to use the geometry Y/255/63. Most partitioning tools (including Parted) will take clues from an existing partition table and adapt to the BIOS values. But if there is no existing partition table, they cannot do that. This matters because I am installing Windows while running Linux, not unlike this other person: http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/0230.html I can confirm that if I create a partition under Linux, format it, and run the Windows installer under dosemu, Windows is not able to boot. If I create the partition table under real DOS first, everything works fine. Now for the on-topic part of this message. What I want to do is invoke INT13/AH=08H in real mode to obtain the BIOS's idea of the geometry of disk 0x80, then boot Linux and pass that information in as a kernel command-line parameter. My question is, can I do this with COMBOOT? If not, does anybody have any other ideas? This is a real show-stopper for me... Thanks! - Pat
Patrick J. LoPresti wrote:> > Now for the on-topic part of this message. What I want to do is > invoke INT13/AH=08H in real mode to obtain the BIOS's idea of the > geometry of disk 0x80, then boot Linux and pass that information in as > a kernel command-line parameter. >This is odd, because the kernel already does this. You may want to make sure you have enabled EDD support in your kernel. If you have EDD support in your kernel enabled, and this happens, I think you should file a bug report against the kernel. This is plain broken. -hpa
I have run into exactly this problem on several occasions, and it certainly does suck. The way I fixed it was to write a small "force_255_heads" patch. It works for all IDE. I've also submitted a patch to libata so that all SATA drives have this geometry. This sounds slightly more useful. -- Michael On Thu, 2004-02-26 at 18:49, Patrick J. LoPresti wrote:> I am working on a Linux-based boot disk for my project > (http://unattended.sourceforge.net/), and I have hit a snag. > > Under Linux 2.6, the kernel (via HDIO_GETGEO) always reports the C/H/S > geometry of an IDE drive as X/16/63. But most BIOSes want to use the > geometry Y/255/63. > > Most partitioning tools (including Parted) will take clues from an > existing partition table and adapt to the BIOS values. But if there > is no existing partition table, they cannot do that. > > This matters because I am installing Windows while running Linux, not > unlike this other person: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/0230.html > > I can confirm that if I create a partition under Linux, format it, and > run the Windows installer under dosemu, Windows is not able to boot. > If I create the partition table under real DOS first, everything works > fine. > > Now for the on-topic part of this message. What I want to do is > invoke INT13/AH=08H in real mode to obtain the BIOS's idea of the > geometry of disk 0x80, then boot Linux and pass that information in as > a kernel command-line parameter. > > My question is, can I do this with COMBOOT? > > If not, does anybody have any other ideas? This is a real > show-stopper for me... > > Thanks! > > - Pat > > _______________________________________________ > SYSLINUX mailing list > Submissions to SYSLINUX at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. >
Michael_E_Brown at Dell.com
2004-Feb-27 04:04 UTC
[syslinux] BIOS disk geometry and Linux 2.6
Yes, it may give you this info, but that info is absolutely useless. Here is why (and just to be fair, I'll even tell you how to fix it) Problem: Once you have booted Linux, you have absolutely, positively, no way of determining which Linux device the geometry that you got from BIOS refers to. You know that BIOS device 0x80 has geometry xxxx/255/63. But you do _not_ know with any certainty which exact Linux /dev/hdX or /dev/sdX that corresponds to. You may think you do, but there exist many, many exceptions that will absolutely kill you. Here is how you fix it: Unfortunately, you cannot fix it without a little help from userspace. You need a way of knowing which Linux device bios disk 0x80 is. There are two ways to do this. First, BIOS EDD 3.0. The thing that EDD 3.0 gives you is PCI bus/dev/fun information. You can write a small userspace utility to parse this info and find the matching linux device. You then 'fix' the geometry from userspace. Failing EDD 3.0 (assuming EDD 1.0), you can use the disksig patch (recently accepted into both 2.4 and 2.6). This is less reliable, and you may have to write to disks and reboot. What happens is that Linux early 16-bit boot reads bios dev 0x80 and stores the 32 bits at offset 0x1B8, which is reserved for a "unique" signature. It stores this info in empty-zero-page and exports this info in /proc or /sysfs. Userspace can then search all linux devices at this offset for this signature. IFF you find exactly one disk with a matching signature, you can then fixup the geometry. This is the short version. Hopefully I have been clear enough. Search linux-kernel for disksig to find recent discussion from when Matt Domsch submitted the patch to l-k. -- Michael -----Original Message----- From: H. Peter Anvin [mailto:hpa at zytor.com] Sent: Thursday, February 26, 2004 9:00 PM To: Brown, Michael E Cc: Patrick J. LoPresti; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael Brown wrote:> The vast majority of bios/adapters do not support EDD at this time.Probably not EDD 3.0, but you should only need EDD 1.0 (which they pretty much all support) in order to get the geometry info, right? -hpa
Patrick J. LoPresti wrote:> >>Now, from the looks of it, you actually have a system which does >>support EDD3, and it gives the wrong answers. > > I do not think so. The EDD data is reporting the geometry from > INT13/AH=48h (the "get drive parameters" call of the INT13 > extensions). That geometry is different than the one reported by the > legacy INT13/AH=08h call. And it is the legacy geometry which the > partition table needs to use. >I would consider that a shortcoming in the current EDD patch. After all, that is the geometry that anyone actually cares about. -hpa
Michael_E_Brown at Dell.com
2004-Feb-27 18:27 UTC
[syslinux] BIOS disk geometry and Linux 2.6
Hmm... Writing to the disk from your bootloader. I can think of all kinds of situations where we completely screw the system doing this. You would have to have some kind of very rigorously controlled environment to have a hope of not messing things up. -- Michael -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of H. Peter Anvin Sent: Friday, February 27, 2004 11:37 AM To: Patrick J. LoPresti Cc: syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 I just had a sick idea. Imagine an MBR which examines the partition table using the LBA values in the partition table, fixes them up, and then overwrites itself with data taken e.g. from Sector 1. That way you could create your filesystems under Linux and completely ignore the geometry, then they would be fixed up. Okay, so that won't work. How about this: a COMBOOT/COM32 program queries for BIOS geometry and writes them into Sector 1 of the hard disk together with a signature Then you can read them from there. Again, since you're actually writing the data to the disk, the BIOS:Linux drive mapping problem becomes trivial. -hpa _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Michael_E_Brown at Dell.com
2004-Feb-27 18:28 UTC
[syslinux] BIOS disk geometry and Linux 2.6
>From my notes:"""This function will put a boot record into a _partition_ containing a FAT32 filesystem. The first 32 sectors of the partition are reserved by FAT32 for the partition boot record. The DOS7 boot record occupies: sector 0: boot sector 1: FSINFO sector 2: boot (continued) sector 6: backup boot sector 7: backup FSINFO sector 8: backup boot(cont) sector 12: Windows 2000 boot(continued) use putDosMbr() to put the actual MBR, this function will only modify/read/write the partition boot sector """ It is not safe to write to sector 1. -- Michael -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of Patrick J. LoPresti Sent: Friday, February 27, 2004 11:58 AM To: H. Peter Anvin Cc: syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 "H. Peter Anvin" <hpa at zytor.com> writes:> How about this: a COMBOOT/COM32 program queries for BIOS geometry and > writes them into Sector 1 of the hard disk together with a signature > Then you can read them from there. Again, since you're actually > writing the data to the disk, the BIOS:Linux drive mapping problem > becomes trivial.This still does not let you do the mapping in general. Any drive might have been moved from any machine. Or do you clobber sector 1 on every attached drive? Seems risky... And don't some boot loaders use sector 1? Just out of curiosity, why is it such a bad idea to pass the geometry as a kernel parameter? I suppose it might be better just to add a field to the EDD data and fill it in from setup.S... Hm. I still think the geometry issue and the device mapping issue are completely independent and need to be solved separately. The geometry issue is critical for me, and it can be solved without any scribbling on the disk just by asking the BIOS a few questions. The device mapping issue is harder, but on the other hand it is about 1000 times less important. Almost all of my users only have one drive; for the rest, I am happy to tell them "use a newer BIOS or choose the boot device manually". And even without EDD 3, I can take a pretty good guess at the boot device. - Pat _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Michael_E_Brown at Dell.com wrote:> Hmm... > > Writing to the disk from your bootloader. > > I can think of all kinds of situations where we completely screw the system > doing this. You would have to have some kind of very rigorously controlled > environment to have a hope of not messing things up. >This is not for a general boot loader, remember. This is for an *installer*, which will wipe disks anyway. -hpa
Michael_E_Brown at Dell.com
2004-Feb-27 18:30 UTC
[syslinux] BIOS disk geometry and Linux 2.6
EDD author == Matt Domsch. Matt_Domsch at dell.com. He is open to suggestions. Unfortunately, he has a new baby and is out for a few weeks. -- Michael -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of H. Peter Anvin Sent: Friday, February 27, 2004 12:02 PM To: Patrick J. LoPresti Cc: syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Patrick J. LoPresti wrote:> > This still does not let you do the mapping in general. Any drive > might have been moved from any machine.And then you need to install, so you have to make sure this program runs> Or do you clobber sector 1 on every attached drive? Seems risky...That's the idea.> And don't some boot loaders use sector 1?None that I know of. I know someone on this list (Murali?) is successfully using it for some installation stuff.> Just out of curiosity, why is it such a bad idea to pass the geometry > as a kernel parameter?It just doesn't buy you anything.> I suppose it might be better just to add a field to the EDD data and > fill it in from setup.S... Hm.I believe this is the right thing to do.> I still think the geometry issue and the device mapping issue are > completely independent and need to be solved separately. > > The geometry issue is critical for me, and it can be solved without > any scribbling on the disk just by asking the BIOS a few questions. > > The device mapping issue is harder, but on the other hand it is about > 1000 times less important. Almost all of my users only have one > drive; for the rest, I am happy to tell them "use a newer BIOS or > choose the boot device manually". And even without EDD 3, I can take > a pretty good guess at the boot device.Well, what you should do, then, is ask the EDD patch authors to make the data available even if it's incomplete. -hpa _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Michael_E_Brown at Dell.com
2004-Feb-27 18:32 UTC
[syslinux] BIOS disk geometry and Linux 2.6
Even then, not good. I am the principle architect for Dell Server Assitant 8.0. It is an installer that Dell ships with every server we sell. The new version is based on Linux and uses isolinux. We must always ask permission from the user before we change a block on the disk. Asking for this permission from the boot loader would not be an acceptable user interface (our marketing people would freak out). -- Michael -----Original Message----- From: H. Peter Anvin [mailto:hpa at zytor.com] Sent: Friday, February 27, 2004 12:29 PM To: Brown, Michael E Cc: patl at users.sourceforge.net; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael_E_Brown at Dell.com wrote:> Hmm... > > Writing to the disk from your bootloader. > > I can think of all kinds of situations where we completely screw the > system doing this. You would have to have some kind of very rigorously > controlled environment to have a hope of not messing things up. >This is not for a general boot loader, remember. This is for an *installer*, which will wipe disks anyway. -hpa
Michael_E_Brown at Dell.com
2004-Feb-27 18:33 UTC
[syslinux] BIOS disk geometry and Linux 2.6
You are indeed correct. Thanks for the correction. -- Michael -----Original Message----- From: H. Peter Anvin [mailto:hpa at zytor.com] Sent: Friday, February 27, 2004 12:30 PM To: Brown, Michael E Cc: patl at users.sourceforge.net; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael_E_Brown at Dell.com wrote:>>From my notes: > > """This function will put a boot record into a _partition_ > containing a FAT32 filesystem. > > The first 32 sectors of the partition are reserved by FAT32 > for the partition boot record. > > The DOS7 boot record occupies: > sector 0: boot > sector 1: FSINFO > sector 2: boot (continued) > > sector 6: backup boot > sector 7: backup FSINFO > sector 8: backup boot(cont) > > sector 12: Windows 2000 boot(continued) > > use putDosMbr() to put the actual MBR, this function > will only modify/read/write the partition boot sector > """ > > It is not safe to write to sector 1. >You're confusing sector 1 of a filesystem (partition) with sector 1 of the unpartitioned disk. -hpa
Michael_E_Brown at Dell.com
2004-Feb-27 18:39 UTC
[syslinux] BIOS disk geometry and Linux 2.6
Just do the int13 calls in setup.S and save the results in empty-zero-page. Make the data available via sys/proc. Write a user program to use this in conjunction with disksig/EDD to fixup the /proc/ide/xxx/settings file after finding the correct one. This is the only way to do this reliably that I can see. And it is not that hard. Copy the disksig code (a couple dozen lines). I have a 2 dozen line python lib that does the disksig finding. This is not that hard of a problem. -- Michael -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of Brown, Michael E Sent: Friday, February 27, 2004 12:33 PM To: hpa at zytor.com Cc: patl at users.sourceforge.net; syslinux at zytor.com Subject: RE: [syslinux] BIOS disk geometry and Linux 2.6 Even then, not good. I am the principle architect for Dell Server Assitant 8.0. It is an installer that Dell ships with every server we sell. The new version is based on Linux and uses isolinux. We must always ask permission from the user before we change a block on the disk. Asking for this permission from the boot loader would not be an acceptable user interface (our marketing people would freak out). -- Michael -----Original Message----- From: H. Peter Anvin [mailto:hpa at zytor.com] Sent: Friday, February 27, 2004 12:29 PM To: Brown, Michael E Cc: patl at users.sourceforge.net; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael_E_Brown at Dell.com wrote:> Hmm... > > Writing to the disk from your bootloader. > > I can think of all kinds of situations where we completely screw the > system doing this. You would have to have some kind of very rigorously > controlled environment to have a hope of not messing things up. >This is not for a general boot loader, remember. This is for an *installer*, which will wipe disks anyway. -hpa _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Michael_E_Brown at Dell.com
2004-Feb-27 18:42 UTC
[syslinux] BIOS disk geometry and Linux 2.6
You are correct, Peter. I'm just trying to see if I can get people to do this the "right" way. (outlined in my previous msg) This would provide a general purpose, guaranteed correct and guaranteed safe method to do this rather than a special purpose hack that only works if you squint the right way. The right way does not involve a whole lot of extra work. I can post the code I have that uses disksig to find disks, if anybody is interested. All that needs to be written is the export of int13 geometry info. -- Michael -----Original Message----- From: H. Peter Anvin [mailto:hpa at zytor.com] Sent: Friday, February 27, 2004 12:38 PM To: Brown, Michael E Cc: patl at users.sourceforge.net; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael_E_Brown at Dell.com wrote:> Even then, not good. > > I am the principle architect for Dell Server Assitant 8.0. It is an > installer that Dell ships with every server we sell. The new version > is based on Linux and uses isolinux. > > We must always ask permission from the user before we change a block > on the disk. Asking for this permission from the boot loader would not > be an acceptable user interface (our marketing people would freak > out). >Then don't use it... we're not exactly suggesting a general-use facility here... -hpa
I am with Michael on this one. My current installation system prompts before making any changes to the disk. Scribbling on sectors on unrelated disks is simply not an option. - Pat Michael_E_Brown at Dell.com writes:> Even then, not good. > > I am the principle architect for Dell Server Assitant 8.0. It is an > installer that Dell ships with every server we sell. The new version is > based on Linux and uses isolinux. > > We must always ask permission from the user before we change a block on the > disk. Asking for this permission from the boot loader would not be an > acceptable user interface (our marketing people would freak out). > > -- > Michael
Michael_E_Brown at Dell.com
2004-Feb-27 21:16 UTC
[syslinux] BIOS disk geometry and Linux 2.6
Matt, Some EDD changes. Please see the archives for syslinux mailing list for discussion. Patrick can provide more commentary on this, but it appears that EDD is returning the wrong geometry. Patric, You should talk directly with Matt about this patch. I'd rather not be a bottleneck, since I am now in a different group than Matt. Also, please be aware that Matt is out for a couple of weeks with a new baby, so please re-ping him if there is no response soon. -- Michael -----Original Message----- From: Patrick J. LoPresti [mailto:patl at users.sourceforge.net] Sent: Friday, February 27, 2004 2:30 PM To: Brown, Michael E Cc: hpa at zytor.com; syslinux at zytor.com Subject: Re: [syslinux] BIOS disk geometry and Linux 2.6 Michael_E_Brown at Dell.com writes:> Just do the int13 calls in setup.S and save the results in > empty-zero-page. Make the data available via sys/proc.OK, below is my initial attempt at a patch. It creates new nodes under /sys/firmware/edd/int13_devXX named legacy_cylinders, legacy_heads, and legacy_sectors. The values within are the maximum cylinder number, maximum head number, and maximum sector number as returned by the legacy INT13/AH=08h "get drive parameters" call (http://www.ctyme.com/intr/rb-0621.htm). In general, I tried to follow the coding style already present. But I make no claims about the quality of my code, especially the assembly portion. It works on my test systems, so I am good to go. Thank you for the help, Michael and Peter! Note that these files hold the literal values returned by the BIOS. If I understand correctly, you have to add 1 to "legacy_heads" before the value is useful (i.e., before you set it as the bios_head value in /proc/sys/.../settings). We could do that arithmetic here, but I think it is cleaner to worry about it in userspace. Michael, you may want to ask Matt to push this change or something like it through to the Linux folks. - Pat diff -u -r linux-2.6.3-orig/arch/i386/boot/setup.S linux-2.6.3/arch/i386/boot/setup.S --- linux-2.6.3-orig/arch/i386/boot/setup.S 2004-02-17 22:58:11.000000000 -0500 +++ linux-2.6.3/arch/i386/boot/setup.S 2004-02-27 14:58:46.000000000 -0500 @@ -650,6 +650,31 @@ int $0x13 # make the call # Don't check for fail return # it doesn't matter. +edd_get_legacy_chs: + xorw %ax, %ax + movw %ax, %ds:-8(%si) + movw %ax, %ds:-6(%si) + # Ralf Brown's Interrupt List says to set ES:DI to + # 0000h:0000h "to guard against BIOS bugs" + pushw %es + movw %ax, %es + movw %ax, %di + pushw %dx # legacy call clobbers %dl + movb $LEGACYGETDEVICEPARAMETERS, %ah # Function 08 + int $0x13 # make the call + popw %es + jc edd_legacy_done # failed + movb %cl, %al # Low 6 bits are max + andb $0x3F, %al # sector number + movb %al, %ds:-5(%si) # Record max sect + movb %dh, %ds:-6(%si) # Record max head number + movb %ch, %al # Low 8 bits of max cyl + shr $6, %cl + movb %cl, %ah # High 2 bits of max cyl + movw %ax, %ds:-8(%si) + +edd_legacy_done: + popw %dx movw %si, %ax # increment si addw $EDDPARMSIZE+EDDEXTSIZE, %ax movw %ax, %si diff -u -r linux-2.6.3-orig/arch/i386/kernel/edd.c linux-2.6.3/arch/i386/kernel/edd.c --- linux-2.6.3-orig/arch/i386/kernel/edd.c 2004-02-17 22:57:22.000000000 -0500 +++ linux-2.6.3/arch/i386/kernel/edd.c 2004-02-27 14:22:12.000000000 -0500 @@ -321,6 +321,45 @@ } static ssize_t +edd_show_legacy_cylinders(struct edd_device *edev, char *buf) { + struct edd_info *info = edd_dev_get_info(edev); + char *p = buf; + if (!edev || !info || !buf) { + return -EINVAL; + } + + p += snprintf(p, left, "0x%x\n", info->legacy_cylinders); + return (p - buf); +} + +static ssize_t +edd_show_legacy_heads(struct edd_device *edev, char *buf) +{ + struct edd_info *info = edd_dev_get_info(edev); + char *p = buf; + if (!edev || !info || !buf) { + return -EINVAL; + } + + p += snprintf(p, left, "0x%x\n", info->legacy_heads); + return (p - buf); +} + +static ssize_t +edd_show_legacy_sectors(struct edd_device *edev, char *buf) +{ + struct edd_info *info = edd_dev_get_info(edev); + char *p = buf; + if (!edev || !info || !buf) { + return -EINVAL; + } + + p += snprintf(p, left, "0x%x\n", info->legacy_sectors); + return (p - buf); +} + +static ssize_t edd_show_default_cylinders(struct edd_device *edev, char *buf) { struct edd_info *info = edd_dev_get_info(edev); @@ -384,6 +423,33 @@ */ static int +edd_has_legacy_cylinders(struct edd_device *edev) +{ + struct edd_info *info = edd_dev_get_info(edev); + if (!edev || !info) + return -EINVAL; + return info->legacy_cylinders > 0; +} + +static int +edd_has_legacy_heads(struct edd_device *edev) +{ + struct edd_info *info = edd_dev_get_info(edev); + if (!edev || !info) + return -EINVAL; + return info->legacy_heads > 0; +} + +static int +edd_has_legacy_sectors(struct edd_device *edev) +{ + struct edd_info *info = edd_dev_get_info(edev); + if (!edev || !info) + return -EINVAL; + return info->legacy_sectors > 0; +} + +static int edd_has_default_cylinders(struct edd_device *edev) { struct edd_info *info = edd_dev_get_info(edev); @@ -452,6 +518,12 @@ static EDD_DEVICE_ATTR(extensions, 0444, edd_show_extensions, NULL); static EDD_DEVICE_ATTR(info_flags, 0444, edd_show_info_flags, NULL); static EDD_DEVICE_ATTR(sectors, 0444, edd_show_sectors, NULL); +static EDD_DEVICE_ATTR(legacy_cylinders, 0444, edd_show_legacy_cylinders, + edd_has_legacy_cylinders); +static EDD_DEVICE_ATTR(legacy_heads, 0444, edd_show_legacy_heads, + edd_has_legacy_heads); +static EDD_DEVICE_ATTR(legacy_sectors, 0444, edd_show_legacy_sectors, + edd_has_legacy_sectors); static EDD_DEVICE_ATTR(default_cylinders, 0444, edd_show_default_cylinders, edd_has_default_cylinders); static EDD_DEVICE_ATTR(default_heads, 0444, edd_show_default_heads, @@ -478,6 +550,9 @@ /* These attributes are conditional and only added for some devices. */ static struct edd_attribute * edd_attrs[] = { + &edd_attr_legacy_cylinders, + &edd_attr_legacy_heads, + &edd_attr_legacy_sectors, &edd_attr_default_cylinders, &edd_attr_default_heads, &edd_attr_default_sectors_per_track, diff -u -r linux-2.6.3-orig/include/asm-i386/edd.h linux-2.6.3/include/asm-i386/edd.h --- linux-2.6.3-orig/include/asm-i386/edd.h 2004-02-17 22:57:12.000000000 -0500 +++ linux-2.6.3/include/asm-i386/edd.h 2004-02-27 14:21:01.000000000 -0500 @@ -34,10 +34,11 @@ in empty_zero_block - treat this as 1 byte */ #define EDDBUF 0x600 /* addr of edd_info structs in empty_zero_block */ #define EDDMAXNR 6 /* number of edd_info structs starting at EDDBUF */ -#define EDDEXTSIZE 4 /* change these if you muck with the structures */ +#define EDDEXTSIZE 8 /* change these if you muck with the structures */ #define EDDPARMSIZE 74 #define CHECKEXTENSIONSPRESENT 0x41 #define GETDEVICEPARAMETERS 0x48 +#define LEGACYGETDEVICEPARAMETERS 0x08 #define EDDMAGIC1 0x55AA #define EDDMAGIC2 0xAA55 @@ -162,6 +163,9 @@ } __attribute__ ((packed)); struct edd_info { + u16 legacy_cylinders; + u8 legacy_heads; + u8 legacy_sectors; u8 device; u8 version; u16 interface_support;