Whenever I tried using the PDC202xx driver in
2.4-test11 I kept receiving the line in dmsg:
PDC20267: neither IDE port enabled (BIOS)
I traced this to ide-pci.c, line 606:
if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp)
|| (tmp & e->mask) != e->val))
continue; /* port not enabled */
This if was returning true, and skipping the rest of the loop
(which sets up the ioports...)
So it looks like to me that it's not enabling the IOPorts
for this chipset. This seems like a really bad thing, considering
that I can gain no access to the drives currently using this driver.
Any suggestions?
Thanks,
--James Lamanna
<4>ide: Assuming 33MHz system bus speed for PIO modes
<4>AMD7409: IDE controller on PCI bus 00 dev 39
<4>AMD7409: chipset revision 7
<4>AMD7409: not 100% native mode: will probe irqs later
<4> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
<4> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
<4>PDC20267: IDE controller on PCI bus 00 dev 48
<4>PDC20267: chipset revision 2
<4>PDC20267: not 100% native mode: will probe irqs later
<4>PDC20267: ROM enabled at 0xe8000000
<4>PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
<4> ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:DMA, hdf:pio
<4> ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:DMA, hdh:pio
<4>hda: QUANTUM FIREBALL CX13.0A, ATA DISK drive
<4>hdb: QUANTUM FIREBALL CR4.3A, ATA DISK drive
<4>hdc: ATAPI CD ROM DRIVE 50X MAX, ATAPI CDROM drive
<4>hde: Maxtor 91536H2, ATA DISK drive
<4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
<4>ide1 at 0x170-0x177,0x376 on irq 15
<4>ide2 at 0xc400-0xc407,0xc802 on irq 11
Nope you have a chipset that is designed wrong.
On Wed, 6 Dec 2000, James Lamanna wrote:
> Whenever I tried using the PDC202xx driver in
> 2.4-test11 I kept receiving the line in dmsg:
> PDC20267: neither IDE port enabled (BIOS)
>
> I traced this to ide-pci.c, line 606:
> if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp)
> || (tmp & e->mask) != e->val))
> continue; /* port not enabled */
>
> This if was returning true, and skipping the rest of the loop
> (which sets up the ioports...)
> So it looks like to me that it's not enabling the IOPorts
> for this chipset. This seems like a really bad thing, considering
> that I can gain no access to the drives currently using this driver.
> Any suggestions?
>
> Thanks,
> --James Lamanna
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
On Wed, 6 Dec 2000, Andre Hedrick wrote:
> Nope you have a chipset that is designed wrong.
Who makes an on-board chipset (not southbridge) which is designed right?
Highpoint makes HPT370, but after HPT366 fiasco I'm not sure I trust them
anymore...
-Dan
So you are saying that the Promise Fasttrak 100 chipset is
designed wrong? Because that's exactly what I have.
and isn't this driver supposed to support it?
Or are you saying the IDE controller on the MB is wrong?
Andre Hedrick wrote:
>
> <4>ide: Assuming 33MHz system bus speed for PIO modes
> <4>AMD7409: IDE controller on PCI bus 00 dev 39
> <4>AMD7409: chipset revision 7
> <4>AMD7409: not 100% native mode: will probe irqs later
> <4> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> <4> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> <4>PDC20267: IDE controller on PCI bus 00 dev 48
> <4>PDC20267: chipset revision 2
> <4>PDC20267: not 100% native mode: will probe irqs later
> <4>PDC20267: ROM enabled at 0xe8000000
> <4>PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> <4> ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:DMA, hdf:pio
> <4> ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:DMA, hdh:pio
> <4>hda: QUANTUM FIREBALL CX13.0A, ATA DISK drive
> <4>hdb: QUANTUM FIREBALL CR4.3A, ATA DISK drive
> <4>hdc: ATAPI CD ROM DRIVE 50X MAX, ATAPI CDROM drive
> <4>hde: Maxtor 91536H2, ATA DISK drive
> <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> <4>ide1 at 0x170-0x177,0x376 on irq 15
> <4>ide2 at 0xc400-0xc407,0xc802 on irq 11
>
> Nope you have a chipset that is designed wrong.
>
On Wed, 6 Dec 2000, James Lamanna wrote:
> So you are saying that the Promise Fasttrak 100 chipset is
> designed wrong? Because that's exactly what I have.
> and isn't this driver supposed to support it?
> Or are you saying the IDE controller on the MB is wrong?
Clarify things first.
PDC20267 is the Ultra100 core.
PDC20267 w/ a pull-up resistor reports its device class as RAID, Fasttrak100.
Now if you have a device that reports it storage class as RAID then it may
misbehave. Otherwise, if it is reporting "Unknown Mass Storage" then you
have an Ultra/ATA controller.
There are two different BIOS cores for each design.
Linux cleanly supports the BIOS cores know as "Ultra" and not the ones
know as "Fasttrak".
Because there are different PCI config space setups for each core then we
have a problem unless we go and poke around for storage classes.
Does that help?
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
Here is an excerpt from /proc/pci:
Bus 0, device 11, function 0:
RAID bus controller: Promise Technology, Inc. 20267 (rev 2).
IRQ 10.
Master Capable. Latency=32.
I/O at 0x9400 [0x9407].
I/O at 0x9000 [0x9003].
I/O at 0x8800 [0x8807].
I/O at 0x8400 [0x8403].
I/O at 0x8000 [0x803f].
Non-prefetchable 32 bit memory at 0xd5000000 [0xd501ffff].
Bus 0, device 17, function 0:
Unknown mass storage controller: Promise Technology, Inc. 20265 (rev
2).
IRQ 10.
Master Capable. Latency=32.
I/O at 0x7800 [0x7807].
I/O at 0x7400 [0x7403].
I/O at 0x7000 [0x7007].
I/O at 0x6800 [0x6803].
I/O at 0x6400 [0x643f].
Non-prefetchable 32 bit memory at 0xd4800000 [0xd481ffff].
> Now if you have a device that reports it storage class as RAID then it may
> misbehave. Otherwise, if it is reporting "Unknown Mass Storage" then you
> have an Ultra/ATA controller.
It would seem that it reports itself as both.
>
> There are two different BIOS cores for each design.
> Linux cleanly supports the BIOS cores know as "Ultra" and not the ones
> know as "Fasttrak".
Is there a plan to support the Fasttrak BIOS core at some point (I
hope..)
So I guess I'm stuck with loading their proprietary module whenever I
want
to use the drive....
But thanks for the clarification.
On Wed, 6 Dec 2000, James Lamanna wrote:
> Here is an excerpt from /proc/pci:
>
> Bus 0, device 11, function 0:
> RAID bus controller: Promise Technology, Inc. 20267 (rev 2).
> IRQ 10.
> Master Capable. Latency=32.
> I/O at 0x9400 [0x9407].
> I/O at 0x9000 [0x9003].
> I/O at 0x8800 [0x8807].
> I/O at 0x8400 [0x8403].
> I/O at 0x8000 [0x803f].
> Non-prefetchable 32 bit memory at 0xd5000000 [0xd501ffff].
> Bus 0, device 17, function 0:
> Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 2).
> IRQ 10.
> Master Capable. Latency=32.
> I/O at 0x7800 [0x7807].
> I/O at 0x7400 [0x7403].
> I/O at 0x7000 [0x7007].
> I/O at 0x6800 [0x6803].
> I/O at 0x6400 [0x643f].
> Non-prefetchable 32 bit memory at 0xd4800000 [0xd481ffff].
No each device reports itself differently here.
Bus 0, device 11, function 0: == 20267
Bus 0, device 17, function 0: == 20265
You bought a Fasttrak 100 and your mainboard came with an Ultra 100
>
> Is there a plan to support the Fasttrak BIOS core at some point (I hope..)
> So I guess I'm stuck with loading their proprietary module whenever I want
> to use the drive....
Yep, until they realize that their simple IP is nothing, and want to
export the raid calls to the Linux Raid Engine, you are "stuck".
> But thanks for the clarification.
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development