An error occurred fetching the project authors.
  1. 09 Oct, 2002 1 commit
    • Matt Domsch's avatar
      EDD: x86 BIOS Enhanced Disk Drive support · 7df2bda6
      Matt Domsch authored
      The major changes implemented in this patch:
      arch/i386/boot/setup.S - int13 real mode calls store results in empty_zero_page
      arch/i386/kernel/setup.c - copy results from empty_zero_page to local storage
      arch/i386/kernel/edd.c - module exports results via driverfs
      
      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.  Dell restricts our possible
      standard factory installed Linux offerings to "disks on no more than
      one controller" to avoid this problem, but mechanisms now exist to
      solve it and allow such configurations.
      
      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 today.
      
      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
      BIOS int13 calls to retrieve and store this information.  The data is
      copied to a safe place in setup.c, and exported via driverfs.
      
      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
      |   |   `-- drivers
      |   |       `-- sd
      `-- root
          |-- pci2
          |   |-- 02:0c.0
          |   |   |-- 03:00.0
          |   |   |   |-- 04:00.0
          |   |   |   |   |-- irq
          |   |   |   |   |-- name
          |   |   |   |   |-- power
          |   |   |   |   |-- resource
          |   |   |   |   `-- scsi4
          |   |   |   |       |-- 4:0:0:0
          |   |   |   |       |   |-- 4:0:0:0::p1
          |   |   |   |       |   |   |-- kdev
          |   |   |   |       |   |   |-- name
          |   |   |   |       |   |   |-- power
          |   |   |   |       |   |   `-- type
          |   |   |   |       |   |-- 4:0:0:0:disc
          |   |   |   |       |   |   |-- kdev
          |   |   |   |       |   |   |-- name
          |   |   |   |       |   |   |-- power
          |   |   |   |       |   |   `-- type
          |   |   |   |       |   |-- name
          |   |   |   |       |   |-- power
          |   |   |   |       |   `-- type
      
      
      (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.
      
      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 'extensions' file lists the BIOS EDD extensions per spec.
      The 'info_flags' file lists the BIOS EDD device information flags per spec.
      The 'sectors' file reports the number of sectors BIOS believes this
      device has.
      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, as that fills the space that's
      left in the empty_zero_page.  In general you only care about device
      80h, though for software RAID1 knowing what 81h is might be useful also.
      
      
      
      Known issues:
      - module unload leaves a directory around.  Seems related to
        creating symlinks in that directory.  Seen on kernel 2.5.41.
      - refcounting of struct device objects could be improved.
      
      TODO:
      - Add IDE and USB disk device support
      - 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
      
      I'd also like to acknowledge the help and comments received from Greg
      KH and Patrick Mochel.  This isn't something driverfs was originally
      conceived to handle, their assistance has been invaluable.
      
      Please pull from:
      
      BK:
          http://mdomsch.bkbits.net/linux-2.5-edd-tolinus
      
      Patch (against 2.5.41+BK-current):
          http://domsch.com/linux/edd30/edd-driverfs-6.patch
          http://domsch.com/linux/edd30/edd-driverfs-6.patch.sign
      
      Thanks,
      Matt
      
      -- 
      Matt Domsch
      Sr. Software Engineer, Lead Engineer, Architect
      Dell Linux Solutions www.dell.com/linux
      Linux on Dell mailing lists @ http://lists.us.dell.com
      7df2bda6
  2. 03 Sep, 2002 2 commits
    • Andrew Morton's avatar
      [PATCH] discontigmem support for ia32 NUMA · 0d0bdc8e
      Andrew Morton authored
       - All the support macros which assume a linear mem_map[] have been
         wrapped in !CONFIG_DISCONTIGMEM.  pfn_to_page, page_to_pfn,
         page_to_phys, pmd_page, kern_addr_valid.
      
       - Move some initialsation macros into setup.h so they can be used in
         the i386 discontig.c (INITRD_START, INITRD_SIZE).
      
       - Alternate version of the bootmem allocator
      
       - add i386 discontig support and numaq support.
      0d0bdc8e
    • Andrew Morton's avatar
      [PATCH] reorganise setup_arch() for ia32 discontigmem · b9ba3a05
      Andrew Morton authored
      This restructures setup_arch() for i386 to make it easier to include the
      i386 numa changes (for CONFIG_DISCONTIGMEM) I've been working on.  It
      also makes setup_arch() easier to read.  A version of this patch is the
      in 2.4 aa tree.
      
      This does not depend on the other patches I'm submitting today, but my
      discontigmem patch does depend on this one.
      
      I've tested this patch on the following configurations: UP, SMP, SMP
      PAE, multiquad, multiquad PAE.
      b9ba3a05
  3. 05 Feb, 2002 1 commit