Hi,
I appear to have an issue with the detection order of IDE devices,
such that on-board IDE controllers get detected in the wrong order,
causing grief.
Details: Soyo Dragon+ motherboard (KT266A-based) with Promise
PDC20265 ATA100 controller on the motherboard. The Via and Promise
IDE controllers can be enabled simultaneously, and I have the
Promise chip in normal IDE (i.e. not RAID) mode. I have three hard
drives on the Via chip, and a CDROM on the first cable of the
Promise controller.
With the PDC20265 disabled, boot-up messages are thus, and the world
is fine with respect to loading Linux properly off of hda:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
hda: MAXTOR 6L080J4, ATA DISK drive
hdb: IC35L060AVER07-0, ATA DISK drive
hdc: ST380021A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=9732/255/63, UDMA(100)
hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100)
hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
ide-floppy driver 0.97.sv
Partition check:
hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
hdb: hdb1 < hdb5 >
hdc: unknown partition table
(Note that hdc is as yet unformatted so don't sweat that partition
table warning up there.)
Now, when I enable the Promise controller in the BIOS, problems
ensue with respect to the ordering of the assignments of ide0/1 and
ide3/4:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20265: IDE controller on PCI bus 00 dev 68
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:pio, hdb:DMA
ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:pio, hdd:pio
VP_IDE: IDE controller on PCI bus 00 dev 89
PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdg:DMA, hdh:pio
hde: MAXTOR 6L080J4, ATA DISK drive
hdf: IC35L060AVER07-0, ATA DISK drive
hdg: ST380021A, ATA DISK drive
hda: Pioneer DVD-ROM ATAPIModel DVD-114 0110, ATAPI CD/DVD-ROM drive
ide0 at 0x1400-0x1407,0xc802 on irq 5
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
ide3 at 0x170-0x177,0x376 on irq 15
And so, things go downhill from there ending in a kernel panic since
it can't find the root Linux partition, which is now unfortunately
located on what it's calling hde instead of hda. This is just too
bad.
And finally, the only "fix" I've found so far, which is to stick an
append="ide0=0x1f0,0x3f6 ide1=0x170,0x376"
in lilo.conf. This results in a successful boot with everything
back where I'd expect:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20265: IDE controller on PCI bus 00 dev 68
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:DMA
ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller on PCI bus 00 dev 89
PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:DMA, hdd:pio
hda: MAXTOR 6L080J4, ATA DISK drive
hdb: IC35L060AVER07-0, ATA DISK drive
hdc: ST380021A, ATA DISK drive
hde: Pioneer DVD-ROM ATAPIModel DVD-114 0110, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x1400-0x1407,0xc802 on irq 5
hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=9732/255/63, UDMA(100)
hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100)
hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
hde: ATAPI DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
ide-floppy driver 0.97.sv
Partition check:
hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
hdb: hdb1 < hdb5 >
hdc: unknown partition table
So, to summarize, my question is: Why the heck is it assigning the
first and second IDE channels, which are properly on ports 0x1f0 and
0x170, to ide2 and ide3 instead of ide0 and ide1? This seems at
odds with the IDE docs I've looked at.
True, I have a workaround, but that's quite a kernel parameter to
have to lug around from now on. I'd rather it just "do the right
thing", which seems to me to always put the Via controller on 0x1f0
and 0x170 to ide0/ide1. Anyone have any suggestions? Looks kind of
like a bug to me, but it could be a misunderstanding on my part.
Thanks!
Dan Hopper
append="ide=reverse"
Various Mainboard manufacturers do things to place the FAKE-RAID in front
of the the legacy south bridge. This is classic Windows spoofing.
> PDC20265: IDE controller on PCI bus 00 dev 68
> VP_IDE: IDE controller on PCI bus 00 dev 89
In the past, PDC20265 was wrongly assumed to be offboard componets.
The reality is it is an onboard componet exclusive.
I can make a fix (breakage) but it will mess things up if you want to
install to it in the future.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Tue, 19 Mar 2002, Dan Hopper wrote:
> Hi,
>
> I appear to have an issue with the detection order of IDE devices,
> such that on-board IDE controllers get detected in the wrong order,
> causing grief.
>
> Details: Soyo Dragon+ motherboard (KT266A-based) with Promise
> PDC20265 ATA100 controller on the motherboard. The Via and Promise
> IDE controllers can be enabled simultaneously, and I have the
> Promise chip in normal IDE (i.e. not RAID) mode. I have three hard
> drives on the Via chip, and a CDROM on the first cable of the
> Promise controller.
>
> With the PDC20265 disabled, boot-up messages are thus, and the world
> is fine with respect to loading Linux properly off of hda:
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 89
> PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
> hda: MAXTOR 6L080J4, ATA DISK drive
> hdb: IC35L060AVER07-0, ATA DISK drive
> hdc: ST380021A, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=9732/255/63, UDMA(100)
> hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100)
> hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
> ide-floppy driver 0.97.sv
> Partition check:
> hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
> hdb: hdb1 < hdb5 >
> hdc: unknown partition table
>
> (Note that hdc is as yet unformatted so don't sweat that partition
> table warning up there.)
>
>
> Now, when I enable the Promise controller in the BIOS, problems
> ensue with respect to the ordering of the assignments of ide0/1 and
> ide3/4:
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PDC20265: IDE controller on PCI bus 00 dev 68
> PDC20265: chipset revision 2
> PDC20265: not 100% native mode: will probe irqs later
> PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:pio, hdb:DMA
> ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:pio, hdd:pio
> VP_IDE: IDE controller on PCI bus 00 dev 89
> PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
> ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:DMA, hdf:DMA
> ide3: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdg:DMA, hdh:pio
> hde: MAXTOR 6L080J4, ATA DISK drive
> hdf: IC35L060AVER07-0, ATA DISK drive
> hdg: ST380021A, ATA DISK drive
> hda: Pioneer DVD-ROM ATAPIModel DVD-114 0110, ATAPI CD/DVD-ROM drive
> ide0 at 0x1400-0x1407,0xc802 on irq 5
> ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide3 at 0x170-0x177,0x376 on irq 15
>
> And so, things go downhill from there ending in a kernel panic since
> it can't find the root Linux partition, which is now unfortunately
> located on what it's calling hde instead of hda. This is just too
> bad.
>
>
> And finally, the only "fix" I've found so far, which is to stick an
> append="ide0=0x1f0,0x3f6 ide1=0x170,0x376"
> in lilo.conf. This results in a successful boot with everything
> back where I'd expect:
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PDC20265: IDE controller on PCI bus 00 dev 68
> PDC20265: chipset revision 2
> PDC20265: not 100% native mode: will probe irqs later
> PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:DMA
> ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:pio, hdh:pio
> VP_IDE: IDE controller on PCI bus 00 dev 89
> PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
> ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:DMA, hdd:pio
> hda: MAXTOR 6L080J4, ATA DISK drive
> hdb: IC35L060AVER07-0, ATA DISK drive
> hdc: ST380021A, ATA DISK drive
> hde: Pioneer DVD-ROM ATAPIModel DVD-114 0110, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x1400-0x1407,0xc802 on irq 5
> hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=9732/255/63, UDMA(100)
> hdb: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(100)
> hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(100)
> hde: ATAPI DVD-ROM drive, 512kB Cache
> Uniform CD-ROM driver Revision: 3.12
> ide-floppy driver 0.97.sv
> Partition check:
> hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 >
> hdb: hdb1 < hdb5 >
> hdc: unknown partition table
>
>
> So, to summarize, my question is: Why the heck is it assigning the
> first and second IDE channels, which are properly on ports 0x1f0 and
> 0x170, to ide2 and ide3 instead of ide0 and ide1? This seems at
> odds with the IDE docs I've looked at.
>
> True, I have a workaround, but that's quite a kernel parameter to
> have to lug around from now on. I'd rather it just "do the right
> thing", which seems to me to always put the Via controller on 0x1f0
> and 0x170 to ide0/ide1. Anyone have any suggestions? Looks kind of
> like a bug to me, but it could be a misunderstanding on my part.
>
> Thanks!
> Dan Hopper
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick <[email protected]> remarked:
>
> append="ide=reverse"
You're right, this works, too, and is a lot easier to remember than
the override I used before.
> Various Mainboard manufacturers do things to place the FAKE-RAID in front
> of the the legacy south bridge. This is classic Windows spoofing.
>
> > PDC20265: IDE controller on PCI bus 00 dev 68
> > VP_IDE: IDE controller on PCI bus 00 dev 89
So, the I/O port assignments don't in fact properly determine the
assignment order? I'm gathering from what you're saying that the
current behavior is related to PCI bus location?
Thanks,
Dan
Hi Martin,
You kind of missed a few points and issues, so I would like to offer you
some help.
This is easily address by applying the exclusive rule of the seeking the
SouthBridge device. Once this is found, one generally assumes this to be
the PCI_BASE_CLASS_BRIDGE + PCI_CLASS_BRIDGE_ISA or 601h. It will
(should future unknown) have a function number of 0 "zero". Once the
location of the SB has been determined one seeks for function 1 "one".
Once SB + func 1 is found, tests for device class PCI_BASE_CLASS_STORAGE +
PCI_CLASS_STORAGE_IDE or 101h.
Unless otherwise specifed this shall always be the INT13 device; however,
one does not exclude SCSI/RAID or any other device class having rights to
INT13 hooks. Since linux does not support these type of BIOS services the
fore mentioned is the preferred ruleset.
This would have been applied to 2.5 but you are now free to do so
yourself. As for all other booting devices under INT19 calls to load
option roms, which in the past have been considered valid, permit
ATA-HBA's to gain access to the priviledge hwgroup pair ide0/ide1.
This is all a design of detection ordering to override the nasty tricks
played by chipset venders attempting to do have their secondary host or
hba to be the preferred hardware to use.
The history of this problem is a result of HBA's coming to market before
system chipset. Also people who have very good and useful systems who
want to boost their storage performance tend to drift to the HBA world.
Others who load the system up with every toy in the market place run out
of interrupts early (past w/ ISA physical slots), they find it useful and
practical to disable the legacy host to gain back an additional interrupt
but not loose the total storage device count before the addition of the
HBA.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Wed, 20 Mar 2002, Martin Dalecki wrote:
> Dan Hopper wrote:
> > Andre Hedrick <[email protected]> remarked:
> >
> >>append="ide=reverse"
> >
> >
> > You're right, this works, too, and is a lot easier to remember than
> > the override I used before.
> >
> >
> >>Various Mainboard manufacturers do things to place the FAKE-RAID in front
> >>of the the legacy south bridge. This is classic Windows spoofing.
> >>
> >>
> >>>PDC20265: IDE controller on PCI bus 00 dev 68
> >>>VP_IDE: IDE controller on PCI bus 00 dev 89
> >>
> >
> > So, the I/O port assignments don't in fact properly determine the
> > assignment order? I'm gathering from what you're saying that the
> > current behavior is related to PCI bus location?
>
> Precisely: The PCI bus detection order matters.
>
Andre Hedrick wrote:
> Hi Martin,
>
> You kind of missed a few points and issues, so I would like to offer you
> some help.
I don't think so. It is the order on the devices on the PCI bus
which matters for the detection order, since linux is just going
over the devices in the same order they are reported by the BIOS supplied
PCI tables, which are most propably manipulated by the on board BIOS-es
of the Fake-RAID controllers.
> This is easily address by applying the exclusive rule of the seeking the
> SouthBridge device. Once this is found, one generally assumes this to be
> the PCI_BASE_CLASS_BRIDGE + PCI_CLASS_BRIDGE_ISA or 601h. It will
> (should future unknown) have a function number of 0 "zero". Once the
> location of the SB has been determined one seeks for function 1 "one".
> Once SB + func 1 is found, tests for device class PCI_BASE_CLASS_STORAGE +
> PCI_CLASS_STORAGE_IDE or 101h.
Yes this would actually make sense. However nowadays
I would rather love to encourage everybody to just use partition
labels for mount point discrimination instead of plain device
names:
Look for example:
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
Becouse there are some other occasions where the kernel will have
to iterate over PCI devices (suspend/resume comes to mind) and where
a different iteration order on behalf of the IDE subsystem may/could
introduce subtile missinteractions.
Dan using disk labels would be the most convenient solutions to
your problem anyway ;-).
However if I think about it again - I'm not at all sure whatever
the root device can be recognized by a label? If not - the grock
partitions code has to be extendid accordingly!
> Unless otherwise specifed this shall always be the INT13 device; however,
> one does not exclude SCSI/RAID or any other device class having rights to
> INT13 hooks. Since linux does not support these type of BIOS services the
> fore mentioned is the preferred ruleset.
>
> This would have been applied to 2.5 but you are now free to do so
> yourself. As for all other booting devices under INT19 calls to load
> option roms, which in the past have been considered valid, permit
> ATA-HBA's to gain access to the priviledge hwgroup pair ide0/ide1.
>
> This is all a design of detection ordering to override the nasty tricks
> played by chipset venders attempting to do have their secondary host or
> hba to be the preferred hardware to use.
>
> The history of this problem is a result of HBA's coming to market before
> system chipset. Also people who have very good and useful systems who
> want to boost their storage performance tend to drift to the HBA world.
> Others who load the system up with every toy in the market place run out
> of interrupts early (past w/ ISA physical slots), they find it useful and
> practical to disable the legacy host to gain back an additional interrupt
> but not loose the total storage device count before the addition of the
> HBA.
>
> Cheers,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> On Wed, 20 Mar 2002, Martin Dalecki wrote:
>
>
>>Dan Hopper wrote:
>>
>>>Andre Hedrick <[email protected]> remarked:
>>>
>>>
>>>>append="ide=reverse"
>>>
>>>
>>>You're right, this works, too, and is a lot easier to remember than
>>>the override I used before.
>>>
>>>
>>>
>>>>Various Mainboard manufacturers do things to place the FAKE-RAID in front
>>>>of the the legacy south bridge. This is classic Windows spoofing.
>>>>
>>>>
>>>>
>>>>>PDC20265: IDE controller on PCI bus 00 dev 68
>>>>>VP_IDE: IDE controller on PCI bus 00 dev 89
>>>>
>>>So, the I/O port assignments don't in fact properly determine the
>>>assignment order? I'm gathering from what you're saying that the
>>>current behavior is related to PCI bus location?
>>
>>Precisely: The PCI bus detection order matters.
Dan Hopper wrote:
> Andre Hedrick <[email protected]> remarked:
>
>>append="ide=reverse"
>
>
> You're right, this works, too, and is a lot easier to remember than
> the override I used before.
>
>
>>Various Mainboard manufacturers do things to place the FAKE-RAID in front
>>of the the legacy south bridge. This is classic Windows spoofing.
>>
>>
>>>PDC20265: IDE controller on PCI bus 00 dev 68
>>>VP_IDE: IDE controller on PCI bus 00 dev 89
>>
>
> So, the I/O port assignments don't in fact properly determine the
> assignment order? I'm gathering from what you're saying that the
> current behavior is related to PCI bus location?
Precisely: The PCI bus detection order matters.
On Wed, 20 Mar 2002, Martin Dalecki wrote:
> Andre Hedrick wrote:
> > Hi Martin,
> >
> > You kind of missed a few points and issues, so I would like to offer you
> > some help.
>
> I don't think so. It is the order on the devices on the PCI bus
> which matters for the detection order, since linux is just going
> over the devices in the same order they are reported by the BIOS supplied
> PCI tables, which are most propably manipulated by the on board BIOS-es
> of the Fake-RAID controllers.
Unlikely, look at the classic ABIT case in the original BP6. It has an
exclusive way of preventing the real HBA's from ever being used if it is
assumed to be a valid INT19 (virtual HBA). This is present on the TYAN
251x series. All of the OEM NB/SB manufacturers specify the ordering of
their devices. It is the random board manufacturers who spoof the OS and
force the need to play hunt and peck for granting access to the primary
hwgroup pair. Again, if Linux could support EDDS 2.0 or high much of
these issues would go away.
> > This is easily address by applying the exclusive rule of the seeking the
> > SouthBridge device. Once this is found, one generally assumes this to be
> > the PCI_BASE_CLASS_BRIDGE + PCI_CLASS_BRIDGE_ISA or 601h. It will
> > (should future unknown) have a function number of 0 "zero". Once the
> > location of the SB has been determined one seeks for function 1 "one".
> > Once SB + func 1 is found, tests for device class PCI_BASE_CLASS_STORAGE +
> > PCI_CLASS_STORAGE_IDE or 101h.
>
> Yes this would actually make sense. However nowadays
> I would rather love to encourage everybody to just use partition
> labels for mount point discrimination instead of plain device
> names:
In theory maybe, in practice it fails (at the current time).
Real world has shown the act of updating to a kernel which is not approved
by the OEM distro general breaks on labels. Now apply this to the upgrade
path between distro release which you preserve partition in the process.
Labels fail totally in that case, since they are not set or updated.
> Look for example:
>
> LABEL=/ / ext3 defaults 1 1
> LABEL=/boot /boot ext3 defaults 1 2
>
> Becouse there are some other occasions where the kernel will have
> to iterate over PCI devices (suspend/resume comes to mind) and where
> a different iteration order on behalf of the IDE subsystem may/could
> introduce subtile missinteractions.
>
> Dan using disk labels would be the most convenient solutions to
> your problem anyway ;-).
>
> However if I think about it again - I'm not at all sure whatever
> the root device can be recognized by a label? If not - the grock
> partitions code has to be extendid accordingly!
Yes please to ponder this again and hit it w/ LILO and see the fun.
However, GRUB may survive better, not sure about so I will ponder GRUB.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
> > Unless otherwise specifed this shall always be the INT13 device; however,
> > one does not exclude SCSI/RAID or any other device class having rights to
> > INT13 hooks. Since linux does not support these type of BIOS services the
> > fore mentioned is the preferred ruleset.
> >
> > This would have been applied to 2.5 but you are now free to do so
> > yourself. As for all other booting devices under INT19 calls to load
> > option roms, which in the past have been considered valid, permit
> > ATA-HBA's to gain access to the priviledge hwgroup pair ide0/ide1.
> >
> > This is all a design of detection ordering to override the nasty tricks
> > played by chipset venders attempting to do have their secondary host or
> > hba to be the preferred hardware to use.
> >
> > The history of this problem is a result of HBA's coming to market before
> > system chipset. Also people who have very good and useful systems who
> > want to boost their storage performance tend to drift to the HBA world.
> > Others who load the system up with every toy in the market place run out
> > of interrupts early (past w/ ISA physical slots), they find it useful and
> > practical to disable the legacy host to gain back an additional interrupt
> > but not loose the total storage device count before the addition of the
> > HBA.
> >
> > Cheers,
> >
> > Andre Hedrick
> > LAD Storage Consulting Group
> >
> > On Wed, 20 Mar 2002, Martin Dalecki wrote:
> >
> >
> >>Dan Hopper wrote:
> >>
> >>>Andre Hedrick <[email protected]> remarked:
> >>>
> >>>
> >>>>append="ide=reverse"
> >>>
> >>>
> >>>You're right, this works, too, and is a lot easier to remember than
> >>>the override I used before.
> >>>
> >>>
> >>>
> >>>>Various Mainboard manufacturers do things to place the FAKE-RAID in front
> >>>>of the the legacy south bridge. This is classic Windows spoofing.
> >>>>
> >>>>
> >>>>
> >>>>>PDC20265: IDE controller on PCI bus 00 dev 68
> >>>>>VP_IDE: IDE controller on PCI bus 00 dev 89
> >>>>
> >>>So, the I/O port assignments don't in fact properly determine the
> >>>assignment order? I'm gathering from what you're saying that the
> >>>current behavior is related to PCI bus location?
> >>
> >>Precisely: The PCI bus detection order matters.
>