Call For Testers - x86 BIOS Enhanced Disk Drive Services
x86 systems suffer from a disconnect between what BIOS believes is the
boot disk, and what Linux thinks BIOS thinks is the boot disk. This
manifests itself in multi-disk systems - it's quite possible to
install a distribution, only to fail on reboot - the disk installed to
is not the disk BIOS is booting from.
BIOS Enhanced Disk Device Services (EDD) 3.0 provides the ability for
disk adapter BIOSs to tell the OS what it believes is the boot disk.
While this isn't widely implemented in BIOSs yet, it's time that Linux
received support to be ready as BIOSs with this feature do become
available. At a minimum, LSI MegaRAID cards support this properly
today. I'm taking reports of success/failure at
http://domsch.com/linux/edd30/results.html.
EDD works by providing the bus (PCI, PCI-X, ISA, InfiniBand, PCI
Express, or HyperTransport) location (e.g. PCI 02:01.0) and interface
(ATAPI, ATA, SCSI, USB, 1394, FibreChannel, I2O, RAID, SATA) location
(e.g. SCSI ID 5 LUN 0) information for each BIOS int13 device.
The patch below creates CONFIG_EDD, that when defined, makes the real
mode BIOS int13 calls (setup.S) to retrieve and store this information. The
data is copied to a safe place (setup.c), and the edd module exports
it via driverfs. This currently makes symlinks for PCI controllers
and SCSI disks - IDE disks will be added once their driverfs changes
settle down a bit (you can still get the disk info, just no symlinks.)
*** Call for Testers ***
I'd like to see this included in 2.5.x, and need some testers. I
believe it to be safe and stable, though I know there are BIOSs that
either:
a) claim to support this and do it right (excellent!)
b) don't claim to support this (fine, they get ignored),
c) claim to support this but do so incorrectly (these are the ones
I've heard concerns about)
In all cases I've tried, the real mode int13 calls succeeded (none
locked a machine), and the expected amount of data was returned. When
displaying the data, all cases of incorrect data I've come across are
flagged with warnings or errors when printing the 'raw_data' file for
the particular device. When the data appears to be good, and referrs
to a PCI controller, a symlink in driverfs is made for that. If it's
good and a SCSI disk, a symlink is made for that as well. So far, no
tools (e.g. distro installers) make use of these symlinks or any of
the other reported data, so regardless what BIOS returns, there can be
no harm because we're only displaying it, not relying on it. I'm
counting on human-generated reports to tell if this can generally be
useful, and which BIOS vendors I need to go flog.
Please try the patch, enable CONFIG_EDD=m, and load the 'edd' module.
You should see a 'bios' top-level directory in /driverfs, with each
BIOS-handled device listed under there. Please see
http://domsch.com/linux/edd30/results.html for success/failure
reports, and send your own reports as described there.
*** Call for Testers ***
Here's a sample driverfs tree with two BIOS int13 devices - dev 80 has
incorrect PCI bus information, thus no symlinks are made, but as much
info as possible is presented. Dev 81 has correct PCI and SCSI
information, thus symlinks are made to the actual disc device.
/driverfs
|-- bios
| |-- int13_dev80
| | |-- extensions
| | |-- host_bus
| | |-- info_flags
| | |-- interface
| | |-- raw_data
| | |-- sectors
| | `-- version
| `-- int13_dev81
| |-- extensions
| |-- host_bus
| |-- info_flags
| |-- interface
| |-- pci_dev -> ../../root/pci2/02:0c.0/03:00.0/04:00.0
| |-- raw_data
| |-- disc -> ../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
| |-- sectors
| `-- version
|-- bus
| |-- scsi
| | |-- devices
| | | |-- 4:0:0:0 -> ../../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
`-- root
|-- pci2
| |-- 02:0c.0
| | |-- 03:00.0
| | | |-- 04:00.0
| | | | `-- scsi4
| | | | |-- 4:0:0:0
(Yes, the 'bios' top-level directory isn't the right place,
and Patrick has promised to make something there in the future,
at which point this can be moved.)
The 'raw_data' file contains the full set of information returned by
BIOS with extra error reporting. This exists for vendor BIOS
debugging purposes. This is what I'm most interested in.
The 'host-bus' file contains the PCI (or ISA, HyperTransport, ...)
identifying information, as BIOS knows it.
The 'interface' file contains the SCSI (or IDE, USB, ...) identifying
information, as BIOS knows it.
The 'version' file lists the EDD version. To have device path
information, this must be 0x30 or above. Earlier EDD versions exist
without the device path - as much information as is available is presented.
At most 6 BIOS devices are reported. In general you only care about device
80h, though for software RAID1 knowing what 81h is might be useful also.
Known issues:
- edd module unload leaves a directory around. Seems related to
creating symlinks in that directory. Seen on kernel 2.5.41.
TODO:
- Add IDE and USB disk device symlinks
- refcounting of struct device objects could be improved.
- when driverfs model of discs and partitions changes,
update symlink accordingly.
- Get symlink creator helper functions exported from
drivers/base instead of duplicating them here.
- move edd.[ch] to better locations if/when one is decided
The patch changes these files:
Documentation/i386/zero-page.txt | 2
arch/i386/Config.help | 8
arch/i386/boot/setup.S | 47 +
arch/i386/config.in | 4
arch/i386/defconfig | 1
arch/i386/kernel/Makefile | 1
arch/i386/kernel/edd.c | 984 +++++++++++++++++++++++++++++++++++++
arch/i386/kernel/i386_ksyms.c | 6
arch/i386/kernel/setup.c | 18
include/asm-i386/edd.h | 168 ++++++
include/asm-i386/setup.h | 2
11 files changed, 1241 insertions
BK:
http://mdomsch.bkbits.net/linux-2.5-edd-tolinus
EDD: x86 BIOS Enhanced Disk Drive support <[email protected]> (02/10/09 1.714.7.1)
Patch (against 2.5.{41,42}) (was also sent to l-k on 2002-10-09):
http://domsch.com/linux/edd30/edd-driverfs-6.patch
http://domsch.com/linux/edd30/edd-driverfs-6.patch.sign
Thanks for testing!
-Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Sure! Will I get paid? Cause I sure as hell am not working for free.
This sounds like one of those cases where you want us to do your work
for you Mr. "Sr. Software Engineer, Lead Engineer, Architect" of Dell
Computer Corporation.
You've got a bigger budget for software and hardware testing than we do.
(The nerve of some people.)
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Matt Domsch
Sent: Saturday, October 12, 2002 10:55 PM
To: [email protected]
Subject: [CFT][PATCH 2.5] x86 BIOS Enhanced Disk Drive services
Call For Testers - x86 BIOS Enhanced Disk Drive Services
x86 systems suffer from a disconnect between what BIOS believes is the
boot disk, and what Linux thinks BIOS thinks is the boot disk. This
manifests itself in multi-disk systems - it's quite possible to
install a distribution, only to fail on reboot - the disk installed to
is not the disk BIOS is booting from.
BIOS Enhanced Disk Device Services (EDD) 3.0 provides the ability for
disk adapter BIOSs to tell the OS what it believes is the boot disk.
While this isn't widely implemented in BIOSs yet, it's time that Linux
received support to be ready as BIOSs with this feature do become
available. At a minimum, LSI MegaRAID cards support this properly
today. I'm taking reports of success/failure at
http://domsch.com/linux/edd30/results.html.
EDD works by providing the bus (PCI, PCI-X, ISA, InfiniBand, PCI
Express, or HyperTransport) location (e.g. PCI 02:01.0) and interface
(ATAPI, ATA, SCSI, USB, 1394, FibreChannel, I2O, RAID, SATA) location
(e.g. SCSI ID 5 LUN 0) information for each BIOS int13 device.
The patch below creates CONFIG_EDD, that when defined, makes the real
mode BIOS int13 calls (setup.S) to retrieve and store this information.
The
data is copied to a safe place (setup.c), and the edd module exports
it via driverfs. This currently makes symlinks for PCI controllers
and SCSI disks - IDE disks will be added once their driverfs changes
settle down a bit (you can still get the disk info, just no symlinks.)
*** Call for Testers ***
I'd like to see this included in 2.5.x, and need some testers. I
believe it to be safe and stable, though I know there are BIOSs that
either:
a) claim to support this and do it right (excellent!)
b) don't claim to support this (fine, they get ignored),
c) claim to support this but do so incorrectly (these are the ones
I've heard concerns about)
In all cases I've tried, the real mode int13 calls succeeded (none
locked a machine), and the expected amount of data was returned. When
displaying the data, all cases of incorrect data I've come across are
flagged with warnings or errors when printing the 'raw_data' file for
the particular device. When the data appears to be good, and referrs
to a PCI controller, a symlink in driverfs is made for that. If it's
good and a SCSI disk, a symlink is made for that as well. So far, no
tools (e.g. distro installers) make use of these symlinks or any of
the other reported data, so regardless what BIOS returns, there can be
no harm because we're only displaying it, not relying on it. I'm
counting on human-generated reports to tell if this can generally be
useful, and which BIOS vendors I need to go flog.
Please try the patch, enable CONFIG_EDD=m, and load the 'edd' module.
You should see a 'bios' top-level directory in /driverfs, with each
BIOS-handled device listed under there. Please see
http://domsch.com/linux/edd30/results.html for success/failure
reports, and send your own reports as described there.
*** Call for Testers ***
Here's a sample driverfs tree with two BIOS int13 devices - dev 80 has
incorrect PCI bus information, thus no symlinks are made, but as much
info as possible is presented. Dev 81 has correct PCI and SCSI
information, thus symlinks are made to the actual disc device.
/driverfs
|-- bios
| |-- int13_dev80
| | |-- extensions
| | |-- host_bus
| | |-- info_flags
| | |-- interface
| | |-- raw_data
| | |-- sectors
| | `-- version
| `-- int13_dev81
| |-- extensions
| |-- host_bus
| |-- info_flags
| |-- interface
| |-- pci_dev -> ../../root/pci2/02:0c.0/03:00.0/04:00.0
| |-- raw_data
| |-- disc ->
../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
| |-- sectors
| `-- version
|-- bus
| |-- scsi
| | |-- devices
| | | |-- 4:0:0:0 ->
../../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
`-- root
|-- pci2
| |-- 02:0c.0
| | |-- 03:00.0
| | | |-- 04:00.0
| | | | `-- scsi4
| | | | |-- 4:0:0:0
(Yes, the 'bios' top-level directory isn't the right place,
and Patrick has promised to make something there in the future,
at which point this can be moved.)
The 'raw_data' file contains the full set of information returned by
BIOS with extra error reporting. This exists for vendor BIOS
debugging purposes. This is what I'm most interested in.
The 'host-bus' file contains the PCI (or ISA, HyperTransport, ...)
identifying information, as BIOS knows it.
The 'interface' file contains the SCSI (or IDE, USB, ...) identifying
information, as BIOS knows it.
The 'version' file lists the EDD version. To have device path
information, this must be 0x30 or above. Earlier EDD versions exist
without the device path - as much information as is available is
presented.
At most 6 BIOS devices are reported. In general you only care about
device
80h, though for software RAID1 knowing what 81h is might be useful also.
Known issues:
- edd module unload leaves a directory around. Seems related to
creating symlinks in that directory. Seen on kernel 2.5.41.
TODO:
- Add IDE and USB disk device symlinks
- refcounting of struct device objects could be improved.
- when driverfs model of discs and partitions changes,
update symlink accordingly.
- Get symlink creator helper functions exported from
drivers/base instead of duplicating them here.
- move edd.[ch] to better locations if/when one is decided
The patch changes these files:
Documentation/i386/zero-page.txt | 2
arch/i386/Config.help | 8
arch/i386/boot/setup.S | 47 +
arch/i386/config.in | 4
arch/i386/defconfig | 1
arch/i386/kernel/Makefile | 1
arch/i386/kernel/edd.c | 984
+++++++++++++++++++++++++++++++++++++
arch/i386/kernel/i386_ksyms.c | 6
arch/i386/kernel/setup.c | 18
include/asm-i386/edd.h | 168 ++++++
include/asm-i386/setup.h | 2
11 files changed, 1241 insertions
BK:
http://mdomsch.bkbits.net/linux-2.5-edd-tolinus
EDD: x86 BIOS Enhanced Disk Drive support <[email protected]>
(02/10/09 1.714.7.1)
Patch (against 2.5.{41,42}) (was also sent to l-k on 2002-10-09):
http://domsch.com/linux/edd30/edd-driverfs-6.patch
http://domsch.com/linux/edd30/edd-driverfs-6.patch.sign
Thanks for testing!
-Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
"Joseph D. Wagner" wrote:
>
> Sure! Will I get paid? Cause I sure as hell am not working for free.
>
External testing by the long-suffering body of well-meaning users
is a critical factor in kernel development.
I see no reason why a prospective contribution from a Dell employee
should be denied that.
As someone once said: "In case you've forgotten, this is the Linux
Kernel Development List, for DEVELOPERS. Take your cyber-political,
cyber-theology, and cyber-philosophy elsewhere!"
Oh. That was you.