ide controller ordering on 2.4.26 - Setup

This is a discussion on ide controller ordering on 2.4.26 - Setup ; Whilst attempting to upgrade to the latest kernel (2.4.26) I re-encountered a problem I had years ago which was that with an additional PCI IDE controller card in the machine, Linux re-assigns the drives (possibly based on the order it ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: ide controller ordering on 2.4.26

  1. ide controller ordering on 2.4.26

    Whilst attempting to upgrade to the latest kernel (2.4.26) I
    re-encountered a problem I had years ago which was that with an
    additional PCI IDE controller card in the machine, Linux re-assigns the
    drives (possibly based on the order it detects the controllers at boot)
    such that the onboard drives (hda->hdd) become hde-hdh instead of the
    PCI. In older kernels, I got round this with the parameter 'ide0=0x1f0
    ide1=0x170' but this appears to be deprecated in the newer kernels.

    Here is the relevant info from the booting kernel:

    Uniform Multi-Platform E-IDE driver
    ide: Assuming 33MHz system bus speed for PIO modes; override with
    idebus=xx
    SiI680: IDE controller (0x1095:0x0680 rev 0x02) at PCI slot
    0000:00:0a.0

    ^^^ PCI card controller

    ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 18
    SiI680: BASE CLOCK == 133
    SiI680: 100% native mode on irq 18
    ide0: MMIO-DMA
    ide1: MMIO-DMA
    ide0 at 0xd0818080-0xd0818087,0xd081808a on irq 18
    ide1 at 0xd08180c0-0xd08180c7,0xd08180ca on irq 18
    VP_IDE: IDE controller (0x1106:0x0571 rev 0x06) at PCI slot
    0000:00:11.1

    ^^^ onboard controller

    ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20
    ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20
    ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [ALKA] -> GSI 20 (level,
    low) -> IRQ 20
    VP_IDE: not 100% native mode: will probe irqs later
    VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
    ide2: BM-DMA at 0xc000-0xc007
    ide3: BM-DMA at 0xc008-0xc00f

    hde: FUJITSU MPE3136AT, ATA DISK drive

    ^^^ attached to onboard controller so *should* be hda

    hdf: Maxtor 6L200P0, ATA DISK drive
    hde: drive side 80-wire cable detection failed, limiting max speed to
    UDMA33
    hde: UDMA/33 mode selected
    hdf: UDMA/133 mode selected
    hdg: CD-540E, ATAPI CD/DVD-ROM drive
    hdg: UDMA/33 mode selected
    ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
    ide3 at 0x170-0x177,0x376 on irq 15

    This also seems to conflict with the (new) documentation in ide/ide.txt:

    "This is the multiple IDE interface driver, as evolved from hd.c.

    It supports up to 9 IDE interfaces per default, on one or more IRQs
    (usually
    14 & 15). There can be up to two drives per interface, as per the ATA-6
    spec.

    Primary: ide0, port 0x1f0; major=3; hda is minor=0; hdb is minor=64
    Secondary: ide1, port 0x170; major=22; hdc is minor=0; hdd is minor=64
    Tertiary: ide2, port 0x1e8; major=33; hde is minor=0; hdf is minor=64
    Quaternary: ide3, port 0x168; major=34; hdg is minor=0; hdh is minor=64
    fifth.. ide4, usually PCI, probed
    sixth.. ide5, usually PCI, probed"

    Reading this then, I would expect the off board card (which doesn't
    appear at *any* of these addresses) to be assigned ide4 & ide5.

    So I guess the question here is what is the "new" method of forcing the
    drive assignements?

    rgs,


    Jon.

    --
    == jon bird - software engineer
    ==
    ==
    == posted as: news 'at' onastick 'dot' clara.co.uk


  2. Re: ide controller ordering on 2.4.26

    jon bird wrote:
    > Whilst attempting to upgrade to the latest kernel (2.4.26)


    That is hardly the latest kernel. I do not know what the latest one is, but
    I am running 2.6.18-92.1.6.el5PAE that is the latest one on Red Hat
    Enterprise Linux 5. And since the version numbers on RHEL releases lag
    behind, the latest must be higher than 2.6.18. 2.4 kernels are all way behind.

    I have never had to reassign device numbers, but that may be because I use
    two SCSI interfaces for my six hard drives. Each computer I have used have
    less devices on IDE. My latest machine (4 years old) has a dual EIDE
    controller that would support 4 devices. Originally I had two hard drives on
    the first IDE and my CD-ROM drive on the second. But I took those drives off
    the IDE and put SCSI drives in there instead. That machine now has 6 SCSI
    hard drives and they do not seem to move around.

    I do not know if they make SCSI CD-ROM or DVD-ROM drives, but since I use
    them so seldom, I guess it does not matter.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 07:50:01 up 9:30, 4 users, load average: 4.08, 4.04, 4.07

  3. Re: ide controller ordering on 2.4.26

    jon bird wrote:
    > Whilst attempting to upgrade to the latest kernel (2.4.26) I
    > re-encountered a problem I had years ago which was that with an
    > additional PCI IDE controller card in the machine, Linux re-assigns the
    > drives (possibly based on the order it detects the controllers at boot)
    > such that the onboard drives (hda->hdd) become hde-hdh instead of the
    > PCI. In older kernels, I got round this with the parameter 'ide0=0x1f0
    > ide1=0x170' but this appears to be deprecated in the newer kernels.


    There have been historic reasons for this. Promise, for example, who make a
    lot of the low-end ATA and PATA chipsets, published an absolutely crappy set
    of Linux drivers that hard-coded their controllers as being /dev/hda and
    /dev/hdb, no matter what else you did. Hard-coding ATA drivers into a kernel,
    instead of loading them dynamically, can also cause specific types of devices
    to be detected first. (I saw this used to hard-code network ports as eth0 and
    eth1, much to my dismay, in an old jobrole.) And many modern BIOS's can be
    configured to detect first one, then the other set of IDE devices to keep
    things in a well-defined order.

    The contemporary use of LVM and 'e2label' named ext3 filesystems, eases this
    quite a bit. But making sure that /boot is correctly identified can be a bit
    of an adventure, especially when doing kernel upgrades.

    > Reading this then, I would expect the off board card (which doesn't
    > appear at *any* of these addresses) to be assigned ide4 & ide5.
    >
    > So I guess the question here is what is the "new" method of forcing the
    > drive assignements?


    Use named filesystems in ext3, or named partitions in LVM. And you can use a
    'rescue' or 'live' CD with most contemporary Linux releases to determine what
    the OS will think they are. And you can review your BIOS settings to cooperate
    with this.

  4. ide controller ordering on 2.6.26

    In article <%PFgk.116$X2.5@trnddc03>, Jean-David Beyer
    writes
    >jon bird wrote:
    >> Whilst attempting to upgrade to the latest kernel (2.4.26)

    >
    >That is hardly the latest kernel. I do not know what the latest one is, but
    >I am running 2.6.18-92.1.6.el5PAE that is the latest one on Red Hat
    >Enterprise Linux 5. And since the version numbers on RHEL releases lag
    >behind, the latest must be higher than 2.6.18. 2.4 kernels are all way behind.
    >


    sorry that should read 2.6.26... That should make things a bit
    clearer....


    --
    == jon bird - software engineer
    ==
    ==
    == posted as: news 'at' onastick 'dot' clara.co.uk


  5. ide controller ordering on 2.6.26

    In article <48835DF9.8030206@gmail.com>, Nico Kadel-Garcia
    writes
    >jon bird wrote:
    >> Whilst attempting to upgrade to the latest kernel (2.4.26) I
    >>re-encountered a problem I had years ago which was that with an
    >>additional PCI IDE controller card in the machine, Linux re-assigns
    >>the drives (possibly based on the order it detects the controllers at
    >>boot) such that the onboard drives (hda->hdd) become hde-hdh instead
    >>of the PCI. In older kernels, I got round this with the parameter
    >>'ide0=0x1f0 ide1=0x170' but this appears to be deprecated in the newer kernels.

    >
    >There have been historic reasons for this. Promise, for example, who
    >make a lot of the low-end ATA and PATA chipsets, published an
    >absolutely crappy set of Linux drivers that hard-coded their
    >controllers as being /dev/hda and /dev/hdb, no matter what else you
    >did. Hard-coding ATA drivers into a kernel, instead of loading them
    >dynamically, can also cause specific types of devices to be detected
    >first. (I saw this used to hard-code network ports as eth0 and eth1,
    >much to my dismay, in an old jobrole.) And many modern BIOS's can be
    >configured to detect first one, then the other set of IDE devices to
    >keep things in a well-defined order.
    >

    Having established its 2.6.26 we're talking about here... [oops].

    Well I can see that hardcoding devices into drivers is a *bad* idea as
    is putting them into the kernel but I still don't quite understand why
    the option for me to choose to hard code it has been removed and also my
    comment on the documentation stands - it does suggest ide0,1 are
    reserved for the ID channels found at 0x170, 0x1f0 ie. the 'standard' IO
    ports.

    >The contemporary use of LVM and 'e2label' named ext3 filesystems, eases
    >this quite a bit. But making sure that /boot is correctly identified
    >can be a bit of an adventure, especially when doing kernel upgrades.
    >
    >> Reading this then, I would expect the off board card (which doesn't
    >>appear at *any* of these addresses) to be assigned ide4 & ide5.
    >> So I guess the question here is what is the "new" method of forcing
    >>the drive assignements?

    >
    >Use named filesystems in ext3, or named partitions in LVM. And you can
    >use a 'rescue' or 'live' CD with most contemporary Linux releases to
    >determine what the OS will think they are. And you can review your BIOS
    >settings to cooperate with this.


    Ok, well I think I can see how to modify the system to do this although
    there are a few holes I can see - partitions that are not ext3 for
    example ("swap" plus I also have a DOS partition which is user mountable
    in my fstab...) So I'd still like to leave it as is (as a preference).


    --
    == jon bird - software engineer
    ==
    ==
    == posted as: news 'at' onastick 'dot' clara.co.uk


+ Reply to Thread