Re: ASUS TUSL2-C and Promise Ultra100 TX2

Re: ASUS TUSL2-C and Promise Ultra100 TX2

[Robbert Kouprie]

Cajoline writes:
 
> I recently setup a box with the following components:
> Intel Celeron 1300 MHz
> ASUS TUSL2-C motherboard
> 2 x Promise Ultra100 TX2 controllers

I have a CUSL2-C board, P3-800 Coppermine and a Ultra133TX2 controller.

> Any 2.4 kernel I have tried on this machine displays this strange
> a
> behavior: any drives attached to the PDC controllers only work at udma
> mode 2 (UDMA33).

I have the same problem. This is a known problem in the vanilla kernels
(still in 2.4.20-pre11). You can force the right UDMA setting by giving
a "ideX=ata66" kernel boot parameter, where the "X" is your interface
number. This is fixed in recent -ac kernels (I tested with
2.4.20-pre10-ac2).

> What's even funnier is that if I try to copy files from a 
> filesystem on
> a
> 
> drive attached to a PDC20268 and a drive attached to the motherboard
> controller (PIIX4 chipset), the system eventually locks up 
> (after about
> 3
> GB).
> What I mean by this is that there are no errors whatsoever, from the
> kernel ide driver, from the filesystem, nothing at all. It just stops
> responding to anything: login at the console, shell commands, network
> daemons, everything stops working. You can't even reboot it - a hard
> reset
> is required.

This is nasty, I experience this too. This is different from the problem
you describe earlier. I already checked different recent kernels, BIOS
versions, NICs, memory, processors, and still it hangs. I suspect it's a
unknown bug in the driver or a hardware bug in the controller. The
problem is that it hangs completely dead, giving no information to start
debugging. :(

> So I have come to the conclusion there must be some rather bizarre
> 
> incompatibility between the PDCs and this motherboard.
> Let me note that the PDC controllers do work just fine with 
> other older
> motherboards.

Like you, I also have other boxes with Promise Ultra66/100/133
controllers, with _different_ motherboards, which indeed don't have such
problem, so the combination of motherboard <-> controller looks
important here.

> And another thing, during boot-up, the PDCs do show the
> drives attached to it, detected at the right udma mode.

Ditto.
 
> I was wondering if anyone has come across this specific problem. I
> browsed
> 
> thoroughly through the list archives, but I didn't find any mention of
> the
> specific motherboard, or even the PIIX4 chipset and these controllers.
> I know there is probably no way I can get this hardware to work
> together,
> yet I'm curious to know if this has occurred to someone else as well.

Well, it has. And I'm still hoping to solve this one. I an open to any
suggestions, patches or tests.

Regards,
- Robbert Kouprie

Re: ASUS TUSL2-C and Promise Ultra100 TX2

[Cajoline]

On Sat, 26 Oct 2002, Robbert Kouprie wrote:

> Cajoline writes:
>
> > I recently setup a box with the following components:
> > Intel Celeron 1300 MHz
> > ASUS TUSL2-C motherboard
> > 2 x Promise Ultra100 TX2 controllers
>
> I have a CUSL2-C board, P3-800 Coppermine and a Ultra133TX2 controller.

This board should be rather similar to mine, with the main difference
being suport for Coppermine/Tualatin processors. Does your motherboard
also use the PIIX4 onboard IDE chipset?

>
> > Any 2.4 kernel I have tried on this machine displays this strange
> > a
> > behavior: any drives attached to the PDC controllers only work at udma
> > mode 2 (UDMA33).
>
> I have the same problem. This is a known problem in the vanilla kernels
> (still in 2.4.20-pre11). You can force the right UDMA setting by giving
> a "ideX=ata66" kernel boot parameter, where the "X" is your interface

Indeed, that could be a workaround, but I'm afraid it's not that good
after all, because not all the drives have the same capabilities, it's
still slower than udma 5 (UDMA100) and from my tests, with such a
forced setting, the performance is still poor even for this udma mode.

> number. This is fixed in recent -ac kernels (I tested with
> 2.4.20-pre10-ac2).

This is interesting. Excuse my ignorance, but do you know what has
actually changed exactly regarding PDC20268 and PDC20269? Especially
considering these controllers have been already supported in standard
kernels for some time now, and they do actually work, except for unusual
cases like this, obviously.
I looked through the patch, but I can't say I did quite understand.

>
> > What's even funnier is that if I try to copy files from a
> > filesystem on
> > a
> >
> > drive attached to a PDC20268 and a drive attached to the motherboard
> > controller (PIIX4 chipset), the system eventually locks up
> > (after about
> > 3
> > GB).
> > What I mean by this is that there are no errors whatsoever, from the
> > kernel ide driver, from the filesystem, nothing at all. It just stops
> > responding to anything: login at the console, shell commands, network
> > daemons, everything stops working. You can't even reboot it - a hard
> > reset
> > is required.
>
> This is nasty, I experience this too. This is different from the problem
> you describe earlier. I already checked different recent kernels, BIOS
> versions, NICs, memory, processors, and still it hangs. I suspect it's a
> unknown bug in the driver or a hardware bug in the controller. The
> problem is that it hangs completely dead, giving no information to start
> debugging. :(

OK fine, I agree, but how do you explain this only happens when running on
this motherboard? For some reason I can not explain, I still think it is
related to the specific setup. Otherwise it should eventually occur
under different configurations, yet it never has, at least not for me,
even though I have done quite a number of such tests.

>
> > So I have come to the conclusion there must be some rather bizarre
> >
> > incompatibility between the PDCs and this motherboard.
> > Let me note that the PDC controllers do work just fine with
> > other older
> > motherboards.
>
> Like you, I also have other boxes with Promise Ultra66/100/133
> controllers, with _different_ motherboards, which indeed don't have such
> problem, so the combination of motherboard <-> controller looks
> important here.

Indeed. The same controllers work just fine on a P3 600 + QDI Advance 10F
motherboard (with onboard VIA vt82c686a IDE UDMA66 controller).

>
> > And another thing, during boot-up, the PDCs do show the
> > drives attached to it, detected at the right udma mode.
>
> Ditto.
>
> > I was wondering if anyone has come across this specific problem. I
> > browsed
> >
> > thoroughly through the list archives, but I didn't find any mention of
> > the
> > specific motherboard, or even the PIIX4 chipset and these controllers.
> > I know there is probably no way I can get this hardware to work
> > together,
> > yet I'm curious to know if this has occurred to someone else as well.
>
> Well, it has. And I'm still hoping to solve this one. I an open to any
> suggestions, patches or tests.

Same here.

>
> Regards,
> - Robbert Kouprie
>

Thanks for writing. Now at least I know I'm not the only one experiencing
such bizarre behavior from this hardware :)

Regards,
Cajoline Leblanc

RE: ASUS TUSL2-C and Promise Ultra100 TX2

[Robbert Kouprie]

> This board should be rather similar to mine, with the main difference
> being suport for Coppermine/Tualatin processors.
> also use the PIIX4 onboard IDE chipset?

>From the Asus website, the motherboards are very similar, both have the
Intel 815 north bridge, and both have the ICH2 (Intel 82801BA Enhanced
I/O Controller Hub 2) IDE controller onboard. This chip is handled by
the piix.c driver.

> Indeed, that could be a workaround, but I'm afraid it's not that good
> after all, because not all the drives have the same capabilities, it's
> still slower than udma 5 (UDMA100) and from my tests, with such a
> forced setting, the performance is still poor even for this udma mode.

Note that "ata66" actually means UDMA66 and up (it actually means that
you use 80-conductor cables), so with this parameter your drive _will_
run at UDMA 100 if that's supported by the drive and controller. I have
several boxes which need this parameter with the Linus kernel tree, and
they all have disks running at UDMA100 with this boot parameter. Also,
my tests show good speeds on these drives. 

> This is interesting. Excuse my ignorance, but do you know what has
> actually changed exactly regarding PDC20268 and PDC20269?

LBA48 support (for disks > 127Gb) I think was added.

> > > What's even funnier is that if I try to copy files from a
> > > filesystem on
> > > a
> > >
> > > drive attached to a PDC20268 and a drive attached to the 
> motherboard
> > > controller (PIIX4 chipset), the system eventually locks up
> > > (after about
> > > 3
> > > GB).

This night, I experienced another hang on my box. Even magic sysreq
doesn't do anything anymore. Do you have a reproducible testcase to
trigger this?

> OK fine, I agree, but how do you explain this only happens 
> when running on
> this motherboard?

Maybe we should start blaming the onboard ICH2 controller, or the piix.c
driver in this case, because that's the only common thing in our faulty
setups. I also noticed that the ICH2 on the Asus TUSL2-C and CUSL2-C
boards have its own PCI device id in the pci.ids file. So this could
mean they have something different than regular ICH2 chips. I'll include
my full lspci -vvvx for anyone who is interested.

> Indeed. The same controllers work just fine on a P3 600 + QDI 
> Advance 10F
> motherboard (with onboard VIA vt82c686a IDE UDMA66 controller).

Did you also try this motherboard with a different brand add-on PCI
controller (like a CMD one)? 

Regards,
- Robbert


Lspci -vvvx:
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and
Memory Controller Hub (rev 02)
        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [88] #09 [f104]
        Capabilities: [a0] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 86 80 30 11 06 00 90 20 02 00 00 06 00 00 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02)
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000e000-0000dfff
        Memory behind bridge: f7b00000-f7bfffff
        Prefetchable memory behind bridge: f7f00000-f7ffffff
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
00: 86 80 31 11 07 00 20 00 02 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 a0 22
20: b0 f7 b0 f7 f0 f7 f0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 01)
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
        I/O behind bridge: 0000b000-0000dfff
        Memory behind bridge: f0000000-f7afffff
        Prefetchable memory behind bridge: f7c00000-f7efffff
        BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
00: 86 80 4e 24 07 01 80 00 01 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 20 b0 d0 80 22
20: 00 f0 a0 f7 c0 f7 e0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 00

00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
00: 86 80 40 24 0f 01 80 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 01) (prog-if 80
[Master])
        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 4: I/O ports at a800 [size=16]
00: 86 80 4b 24 05 00 80 02 01 80 01 01 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 a8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 01)
        Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 11
        Region 4: I/O ports at e800 [size=16]
00: 86 80 43 24 01 00 80 02 01 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00

02:09.0 Unknown mass storage controller: Promise Technology, Inc. 20269
(rev 02) (prog-if 85)
        Subsystem: Promise Technology, Inc.: Unknown device 4d68
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1000ns min, 4500ns max), cache line size 08
        Interrupt: pin A routed to IRQ 4
        Region 0: I/O ports at d800 [size=8]
        Region 1: I/O ports at d400 [size=4]
        Region 2: I/O ports at d000 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b400 [size=16]
        Region 5: Memory at f7000000 (32-bit, non-prefetchable)
[size=16K]
        Expansion ROM at <unassigned> [disabled] [size=16K]
        Capabilities: [60] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 69 4d 07 00 30 04 02 85 80 01 08 20 00 00
10: 01 d8 00 00 01 d4 00 00 01 d0 00 00 01 b8 00 00
20: 01 b4 00 00 00 00 00 f7 00 00 00 00 5a 10 68 4d
30: 00 00 00 00 60 00 00 00 00 00 00 00 04 01 04 12

02:0b.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 09)
        Subsystem: Intel Corp. EtherExpress PRO/100 S Management Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min, 14000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 3
        Region 0: Memory at f6800000 (32-bit, non-prefetchable)
[size=4K]
        Region 1: I/O ports at b000 [size=64]
        Region 2: Memory at f6000000 (32-bit, non-prefetchable)
[size=128K]
        Expansion ROM at <unassigned> [disabled] [size=1M]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 86 80 29 12 17 00 90 02 09 00 00 02 08 20 00 00
10: 00 00 80 f6 01 b0 00 00 00 00 00 f6 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 11 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 03 01 08 38

02:0e.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06)
(prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1000ns min, 63750ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at f0000000 (32-bit, non-prefetchable)
[size=64M]
        Expansion ROM at f7cf0000 [disabled] [size=64K]
00: 33 53 31 56 07 00 00 02 06 00 00 03 00 20 00 00
10: 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 cf f7 00 00 00 00 00 00 00 00 0a 01 04 ff

RE: ASUS TUSL2-C and Promise Ultra100 TX2

[Cajoline]

On Sat, 26 Oct 2002, Robbert Kouprie wrote:

> > This board should be rather similar to mine, with the main difference
> > being suport for Coppermine/Tualatin processors.
> > also use the PIIX4 onboard IDE chipset?
>
> >From the Asus website, the motherboards are very similar, both have the
> Intel 815 north bridge, and both have the ICH2 (Intel 82801BA Enhanced
> I/O Controller Hub 2) IDE controller onboard. This chip is handled by
> the piix.c driver.

Right, it is ICH2. However, when I boot on Red Hat's 2.4.18 kernels, the
chipset is always reported as PIIX4, not as ICH2, but for example on the
2.4.19 stock kernel I compiled, it is reported as ICH2; yet the two
kernels display the same behavior regarding this issue.
This difference couldn't be a problem though, right?

> > Indeed, that could be a workaround, but I'm afraid it's not that good
> > after all, because not all the drives have the same capabilities, it's
> > still slower than udma 5 (UDMA100) and from my tests, with such a
> > forced setting, the performance is still poor even for this udma mode.
>
> Note that "ata66" actually means UDMA66 and up (it actually means that
> you use 80-conductor cables), so with this parameter your drive _will_
> run at UDMA 100 if that's supported by the drive and controller. I have
> several boxes which need this parameter with the Linus kernel tree, and
> they all have disks running at UDMA100 with this boot parameter. Also,
> my tests show good speeds on these drives.

I'm sorry, I made a mistake; I meant to write I tried the idebus=66 kernel
parameter, not the one you mentioned. The idebus option didn't have any
effect. I will try the ideX=66 one soon.

> > This is interesting. Excuse my ignorance, but do you know what has
> > actually changed exactly regarding PDC20268 and PDC20269?
>
> LBA48 support (for disks > 127Gb) I think was added.

Somehow I believe LBA48 is already supported in 2.4.19 and even 2.4.18. I
have a 160 GB Maxtor drive attached to one of the PDCs (which have already
been flashed with the latest bios that supports LBA48) and it operates
at its' full capacity.

> This night, I experienced another hang on my box. Even magic sysreq
> doesn't do anything anymore. Do you have a reproducible testcase to
> trigger this?

No unfortunately not, that's the whole point here, I don't have any sign
whatsoever of what causes this and where the problem is, since I also
don't get any error or diagnostic whatsoever. Otherwise I would perhaps be
able to narrow it down.
I have noticed this always occurs when reading (copying) from the devices
on the PDCs to another disk. Actually, the disks on the PDCs are all part
in a logical volume (LVM) together with hdc (on the ICH2). I try to copy
files from the LV (ext3 fs) to hdb1 (vfat), and the system always hangs at
some point, which I can not even determine.
I haven't been able to cause the same problem when writing to the LV.
I doubt the LVM code could have something to do with this, but I should
try this with a single partition on a disk attached to the PDC anyway.
Will do very soon.

> > OK fine, I agree, but how do you explain this only happens
> > when running on
> > this motherboard?
>
> Maybe we should start blaming the onboard ICH2 controller, or the piix.c
> driver in this case, because that's the only common thing in our faulty
> setups. I also noticed that the ICH2 on the Asus TUSL2-C and CUSL2-C
> boards have its own PCI device id in the pci.ids file. So this could
> mean they have something different than regular ICH2 chips. I'll include
> my full lspci -vvvx for anyone who is interested.

I will also send the output of lspci soon enough, in case it makes any
sense to your or anyone else. I just can't do it right away.

> > Indeed. The same controllers work just fine on a P3 600 + QDI
> > Advance 10F
> > motherboard (with onboard VIA vt82c686a IDE UDMA66 controller).
>
> Did you also try this motherboard with a different brand add-on PCI
> controller (like a CMD one)?

No, I don't have any other brand cards to use. I remember I also tried one
Ultra66 controller on this board and it worked fine.

Thanks for your help and comments - they have been quite helpful.
I will try the current -ac tree patches, as well as everything noted
above, and write back asap with my findings.

Regards,
CJ Leblanc

ASUS TUSL2-C and Promise Ultra100 TX2

[Cajoline]

Hello.

I recently setup a box with the following components:
Intel Celeron 1300 MHz
ASUS TUSL2-C motherboard
2 x Promise Ultra100 TX2 controllers

Any 2.4 kernel I have tried on this machine displays this strange
behavior: any drives attached to the PDC controllers only work at udma
mode 2 (UDMA33).
I have tried removing either one of the controllers, removing display and
network adapters, changing PCI slots, anything I could think of. It
doesn't make any difference.
I even tried to force udma 5, for example, with hdparm -X69 /dev/hdX, but
that didn't work either.
I finally tried another Promise Ultra66 controller I have. That works as
expected: the drives are detected as udma 4 (UDMA66).

What's even funnier is that if I try to copy files from a filesystem on a
drive attached to a PDC20268 and a drive attached to the motherboard
controller (PIIX4 chipset), the system eventually locks up (after about 3
GB).
What I mean by this is that there are no errors whatsoever, from the
kernel ide driver, from the filesystem, nothing at all. It just stops
responding to anything: login at the console, shell commands, network
daemons, everything stops working. You can't even reboot it - a hard reset
is required.

And apart from this, there are no errors in general, nothing out of the
ordinary in the boot messages, except for the fact that hard disks are
detected as UDMA(33).

So I have come to the conclusion there must be some rather bizarre
incompatibility between the PDCs and this motherboard.
Let me note that the PDC controllers do work just fine with other older
motherboards. And another thing, during boot-up, the PDCs do show the
drives attached to it, detected at the right udma mode.

I was wondering if anyone has come across this specific problem. I browsed
thoroughly through the list archives, but I didn't find any mention of the
specific motherboard, or even the PIIX4 chipset and these controllers.
I know there is probably no way I can get this hardware to work together,
yet I'm curious to know if this has occurred to someone else as well.

Regards,
Cajoline Leblanc

Re: ASUS TUSL2-C and Promise Ultra100 TX2

[Mikael Pettersson]

Cajoline writes:
 > I recently setup a box with the following components:
 > Intel Celeron 1300 MHz
 > ASUS TUSL2-C motherboard
 > 2 x Promise Ultra100 TX2 controllers

Those have the 20268 chip, right?

 > Any 2.4 kernel I have tried on this machine displays this strange
 > behavior: any drives attached to the PDC controllers only work at udma
 > mode 2 (UDMA33).

I've recently installed a Ultra133 TX2 (PDC 20269) in a box, and it
also only does UDMA33 in 2.4.20-pre11. 2.5.44 with the PDC driver
for "new" chips does UDMA100, however. (The disk is only UDMA100.)

The latest 2.4.20-pre-ac is supposed to have new IDE drivers, but
I haven't had time to test it myself.

 > So I have come to the conclusion there must be some rather bizarre
 > incompatibility between the PDCs and this motherboard.

Unlikely.

 > Let me note that the PDC controllers do work just fine with other older
 > motherboards. And another thing, during boot-up, the PDCs do show the
 > drives attached to it, detected at the right udma mode.

Did those boards also use standard 2.4 kernels?

/Mikael

Re: ASUS TUSL2-C and Promise Ultra100 TX2

[Cajoline]

On Fri, 25 Oct 2002, Mikael Pettersson wrote:

> Cajoline writes:
>  > I recently setup a box with the following components:
>  > Intel Celeron 1300 MHz
>  > ASUS TUSL2-C motherboard
>  > 2 x Promise Ultra100 TX2 controllers
>
> Those have the 20268 chip, right?

Yes it is the 20268 chip.

>
>  > Any 2.4 kernel I have tried on this machine displays this strange
>  > behavior: any drives attached to the PDC controllers only work at udma
>  > mode 2 (UDMA33).
>
> I've recently installed a Ultra133 TX2 (PDC 20269) in a box, and it
> also only does UDMA33 in 2.4.20-pre11. 2.5.44 with the PDC driver
> for "new" chips does UDMA100, however. (The disk is only UDMA100.)
>
> The latest 2.4.20-pre-ac is supposed to have new IDE drivers, but
> I haven't had time to test it myself.

I tested with up to 2.4.19, with the same results. Since there were no
errors and I couldn't find any relevant information in LKML, I didn't
bother to try 2.4.20 test or ac kernels.

This is interesting information, however it still looks very strange to
me, since this is not exactly brand-spanking-new hardware (Ultra 100 TX2
has been around for quite some time) and it does work just fine with other
boards (see below). Also, how come there are absolutely no
errors? Finally, could the motherboard's IDE chipset really have such a
huge impact on the performance of the PDC driver? I mean, after all, PIIX4
is a very widely used chipset, afaik.

>
>  > So I have come to the conclusion there must be some rather bizarre
>  > incompatibility between the PDCs and this motherboard.
>
> Unlikely.
>
>  > Let me note that the PDC controllers do work just fine with other older
>  > motherboards. And another thing, during boot-up, the PDCs do show the
>  > drives attached to it, detected at the right udma mode.
>
> Did those boards also use standard 2.4 kernels?

I can assure you the controllers work just fine on some older QDI
Advance 10F motherboard (VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66
controller), but there were others too.

And yes, I am talking about the same kernels: stock 2.4.18, .19, and Red
Hat's 2.4.18 kernels, among others.

>
> /Mikael
>

I appreciate your insight & help on this. I hope my questions are not too
naive, but I was totally in the dark on this issue until now.

Regards,
Cajoline Leblanc