linux 2.4.19-preX IDE bugs

DISCUSSION Nick Evgeniev 9 participants 31 messages Jun 4, 2002 – Jun 14, 2002

Share & tools

Nick Evgeniev

author

2002-06-04 15:28 UTC #0 lore raw

Hi,

A few days ago I wrote about ide & raid0 bugs in 2.4.19-pre8-ac5 and below (plain 2.4.18 just trashes fs in a few hours)... Then I was asked about my hardware configuration & then was .... ignored silently. Does it mean that nobody cares about ide support in Linux kernel?!

Could someone bring light on what's wrong with promise IDE & ultra ata-100 hdds??? (It was working under 2.4.7)

PS: right now I moved mailspool & oracle redo logs (located on raw devices) out of ide-raid0... & I don't see error messages in logs not because ide driver works, but because of significally reduced IO... OS w/o working ide driver
is a real enjoyment.

Alan Cox

2002-06-04 15:35 UTC #1 lore raw

Quoted 4 lines · Nick Evgeniev

A few days ago I wrote about ide & raid0 bugs in 2.4.19-pre8-ac5 and below (plain 2.4.18 just trashes fs in a few hours)... Then I was asked about my hardware configuration & then was .... ignored silently. Does it mean that nobody cares about ide support in Linux kernel?!

You don't seem to have a paid 24hr response contract with me.

I added it to the collection of IDE oddities I'm looking at. There are also some promise requested changes due to get merged at the end of this week. Then we can see where we stand

Andre Hedrick

2002-06-08 19:54 UTC #2 lore raw

Quoted 7 lines · Alan Cox

Quoted 4 lines · Nick Evgeniev
A few days ago I wrote about ide & raid0 bugs in 2.4.19-pre8-ac5 and below (plain 2.4.18 just trashes fs in a few hours)... Then I was asked about my hardware configuration & then was .... ignored silently. Does it mean that nobody cares about ide support in Linux kernel?!
You don't seem to have a paid 24hr response contract with me.

Ditto

Quoted 3 lines

I added it to the collection of IDE oddities I'm looking at. There are also some promise requested changes due to get merged at the end of this week. Then we can see where we stand

Also, it is hard to answer email without connectivity in the air.

Andre Hedrick
LAD Storage Consulting Group

Nick Evgeniev

author

2002-06-11 15:32 UTC #3 lore raw

Hi,

Quoted 5 lines

Quoted 3 lines
I added it to the collection of IDE oddities I'm looking at. There are also some promise requested changes due to get merged at the end of this week. Then we can see where we stand
Also, it is hard to answer email without connectivity in the air.

Agreed. But all what I see is that STABLE Linux kernel DOESN'T has working driver for promise controller (including latest ac patches) for SEVERAL MONTHS.
And as for now there is no any progress in fixing it. I don't blame on you, or Alan,
or whoever else. All I have to suggest is to drop promise support in stable kernel,
then rewrite/fix it in 2.5 tree... and then backport it to 2.4.

I don't want to make experiments in production environment anymore... And it's
unfair to the rest of Linux users to keep broken drivers in stable kernel... Because
nobody expects that stable kernel will rip your fs _daily_.

Andre Hedrick

2002-06-11 16:55 UTC #4 lore raw

Well be more specific on the hardware.
Remember Promise came in and started dorking the driver.
Next they will not admit to an asic bug even thought I have called them on the existance. 2.5 can not fix it, it will only blow up in 2.5. Hell it is possiblely blowing up in 2.4 but less likely.

So spell out the hardware in question.

The new chip hardware lost its interrupt parse because promise took it out of the pci space and it made the driver less stable because the hardware is less stable.

Quoted 17 lines · Nick Evgeniev

Hi,
Quoted 5 lines
Quoted 3 lines
I added it to the collection of IDE oddities I'm looking at. There are also some promise requested changes due to get merged at the end of this week. Then we can see where we stand
Also, it is hard to answer email without connectivity in the air.
Agreed. But all what I see is that STABLE Linux kernel DOESN'T has working driver for promise controller (including latest ac patches) for SEVERAL MONTHS.
And as for now there is no any progress in fixing it. I don't blame on you, or Alan,
or whoever else. All I have to suggest is to drop promise support in stable kernel,
then rewrite/fix it in 2.5 tree... and then backport it to 2.4.

Quoted 8 lines

I don't want to make experiments in production environment anymore... And it's
unfair to the rest of Linux users to keep broken drivers in stable kernel... Because
nobody expects that stable kernel will rip your fs _daily_.

Andre Hedrick
LAD Storage Consulting Group

Nick Evgeniev

author

2002-06-13 11:16 UTC #5 lore raw

Hi,

First of all I have to claim that it's a driver fault not a hardware! Because after switching
the same cable on different (VIA UDMA66) controller everything seems to work ok for last 3 days.
And I have no kernel errors. Hence I conclude that it's a DRIVER bug.

Well, lets get to hardware... I've got dual PIII MSI motheboard based on VIA chipset with extra IDE controller (promise) on board.
Details:
1. CPU

Quoted 1 line

---------------------------------------------------------------------------

----------------------------------
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 600.027
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips : 1199.30
2. PCI info:

Quoted 1 line

---------------------------------------------------------------------------

--------------------------------------------------------------
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
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 0: Memory at d0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
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
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000f000-00000fff
Memory behind bridge: d4000000-dbffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
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:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
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
Region 4: I/O ports at 9000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
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, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
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, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
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 ? routed to IRQ 9
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20)
Subsystem: VIA Technologies, Inc. AC97 Audio Controller
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 C routed to IRQ 18
Region 0: I/O ports at 9c00 [size=256]
Region 1: I/O ports at a000 [size=4]
Region 2: I/O ports at a400 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0c.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev
02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
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
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at ac00 [size=8]
        Region 1: I/O ports at b000 [size=4]
        Region 2: I/O ports at b400 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at bc00 [size=64]
        Region 5: Memory at dd100000 (32-bit, non-prefetchable) [size=128K]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [58] 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:0d.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI])
Subsystem: Texas Instruments: Unknown device 8020
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 (750ns min, 1000ns max), cache line size 08
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dd125000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at dd120000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] 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:0e.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corp. EtherExpress PRO/100+ 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 16
Region 0: Memory at dd124000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at c000 [size=64]
Region 2: Memory at dd000000 (32-bit, non-prefetchable) [size=1M] 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-

01:00.0 VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 02) (prog-if 00 [VGA])
Subsystem: S3 Inc. Trio3D/2X
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)
Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] 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-
Capabilities: [80] AGP version 1.0
Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x2

Quoted 6 lines

Well be more specific on the hardware.
Remember Promise came in and started dorking the driver.
Next they will not admit to an asic bug even thought I have called them on the existance. 2.5 can not fix it, it will only blow up in 2.5. Hell it is possiblely blowing up in 2.4 but less likely.

Quoted 11 lines

So spell out the hardware in question.
The new chip hardware lost its interrupt parse because promise took it out of the pci space and it made the driver less stable because the hardware is less stable.
Quoted 3 lines · Nick Evgeniev
Hi,
Quoted 1 line
Quoted 1 line
I added it to the collection of IDE oddities I'm looking at. There

are

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
also some promise requested changes due to get merged at the end of

this

Quoted 5 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
week. Then we can see where we stand
Also, it is hard to answer email without connectivity in the air.
Agreed. But all what I see is that STABLE Linux kernel DOESN'T has

working

Quoted 3 lines

Quoted 3 lines
driver for promise controller (including latest ac patches) for SEVERAL MONTHS.
And as for now there is no any progress in fixing it. I don't blame on

you,

Quoted 2 lines

Quoted 2 lines
or Alan,
or whoever else. All I have to suggest is to drop promise support in

stable

Quoted 4 lines

Quoted 4 lines
kernel,
then rewrite/fix it in 2.5 tree... and then backport it to 2.4.
I don't want to make experiments in production environment anymore...

And

Quoted 2 lines

Quoted 2 lines
it's
unfair to the rest of Linux users to keep broken drivers in stable

kernel...

Quoted 10 lines

Quoted 5 lines
Because
nobody expects that stable kernel will rip your fs _daily_.
Andre Hedrick
LAD Storage Consulting Group

Andre Hedrick

2002-06-14 07:04 UTC #6 lore raw

Quoted 6 lines · Nick Evgeniev

Hi,
First of all I have to claim that it's a driver fault not a hardware! Because after switching
the same cable on different (VIA UDMA66) controller everything seems to work ok for last 3 days.

That sounds more like USER ERROR. If you still had the error after switching cable, I would still suspect hardware given it is VIA. It also still may be hardware, since cables can come odd or even in grounding.

Quoted 1 line

And I have no kernel errors. Hence I conclude that it's a DRIVER bug.

If you had connected them correct the first time like they are now, you would not have had a complaint. Next, maybe spend more money to get quality hardware, since VIA hardware has a history of being poorly intergrated.

Now think for two seconds or longer if needed.

It now works and the driver has not changed.

Conclusion, it is not the driver!

Have a good day,

Andre Hedrick
LAD Storage Consulting Group

Quoted 268 lines

Well, lets get to hardware... I've got dual PIII MSI motheboard based on VIA chipset with extra IDE controller (promise) on board.
Details:
1. CPU
Quoted 1 line
---------------------------------------------------------------------------
----------------------------------
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 600.027
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips : 1199.30
2. PCI info:
Quoted 1 line
---------------------------------------------------------------------------
--------------------------------------------------------------
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
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 0: Memory at d0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
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
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000f000-00000fff
Memory behind bridge: d4000000-dbffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
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:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
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
Region 4: I/O ports at 9000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
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, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
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, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
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 ? routed to IRQ 9
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20)
Subsystem: VIA Technologies, Inc. AC97 Audio Controller
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 C routed to IRQ 18
Region 0: I/O ports at 9c00 [size=256]
Region 1: I/O ports at a000 [size=4]
Region 2: I/O ports at a400 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0c.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev
02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
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
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at ac00 [size=8]
        Region 1: I/O ports at b000 [size=4]
        Region 2: I/O ports at b400 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at bc00 [size=64]
        Region 5: Memory at dd100000 (32-bit, non-prefetchable) [size=128K]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [58] 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:0d.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI])
Subsystem: Texas Instruments: Unknown device 8020
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 (750ns min, 1000ns max), cache line size 08
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dd125000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at dd120000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] 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:0e.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corp. EtherExpress PRO/100+ 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 16
Region 0: Memory at dd124000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at c000 [size=64]
Region 2: Memory at dd000000 (32-bit, non-prefetchable) [size=1M] 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-
01:00.0 VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 02) (prog-if 00 [VGA])
Subsystem: S3 Inc. Trio3D/2X
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)
Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] 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-
Capabilities: [80] AGP version 1.0
Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x2
Quoted 6 lines
Well be more specific on the hardware.
Remember Promise came in and started dorking the driver.
Next they will not admit to an asic bug even thought I have called them on the existance. 2.5 can not fix it, it will only blow up in 2.5. Hell it is possiblely blowing up in 2.4 but less likely.
Quoted 11 lines
So spell out the hardware in question.
The new chip hardware lost its interrupt parse because promise took it out of the pci space and it made the driver less stable because the hardware is less stable.
Quoted 3 lines · Nick Evgeniev
Hi,
Quoted 1 line
Quoted 1 line
I added it to the collection of IDE oddities I'm looking at. There
are
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
also some promise requested changes due to get merged at the end of
this
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
week. Then we can see where we stand
Also, it is hard to answer email without connectivity in the air.
Agreed. But all what I see is that STABLE Linux kernel DOESN'T has
working
Quoted 3 lines
Quoted 3 lines
driver for promise controller (including latest ac patches) for SEVERAL MONTHS.
And as for now there is no any progress in fixing it. I don't blame on
you,
Quoted 2 lines
Quoted 2 lines
or Alan,
or whoever else. All I have to suggest is to drop promise support in
stable
Quoted 4 lines
Quoted 4 lines
kernel,
then rewrite/fix it in 2.5 tree... and then backport it to 2.4.
I don't want to make experiments in production environment anymore...
And
Quoted 2 lines
Quoted 2 lines
it's
unfair to the rest of Linux users to keep broken drivers in stable
kernel...
Quoted 10 lines
Quoted 5 lines
Because
nobody expects that stable kernel will rip your fs _daily_.
Andre Hedrick
LAD Storage Consulting Group

Nick Evgeniev

author

2002-06-14 07:53 UTC #7 lore raw

Hi,

Quoted 6 lines

Quoted 1 line
And I have no kernel errors. Hence I conclude that it's a DRIVER bug.
If you had connected them correct the first time like they are now, you would not have had a complaint. Next, maybe spend more money to get quality hardware, since VIA hardware has a history of being poorly intergrated.

What are you talking about?! My system was working perfectly for more than 1 year...
And then after changing kernel, my cabels magically becomes "wrong plugged"?!
WONDERFULL explanation :-/.

Quoted 4 lines

Now think for two seconds or longer if needed.
It now works and the driver has not changed.

Yeah... Best driver is not used... wait a second... even not compiled driver. Am I right?
Well anyway, I plan to change hardware shortly to avoid participation in never-ending
promise driver testing cycle.

Andre Hedrick

2002-06-14 08:23 UTC #8 lore raw

Nick,

http://www.tecchannel.de/hardware/817/index.html

Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.

OIC, it worked perfectly in wonder kernel but not in the latest. Did you check to see if there were other changes in the kernel which could effect the behavior and operations?
A real simple test is to undo the changes to the Promise code and does the problem still exist? If it does then it is not the driver it self.

However the other changes in conjuntion could cause problems, that is a fair point to be made.

So how about including which kernel was the last working version.

For kicks I would back port the driver to prove it is not the driver, or allow you to prove it is.

Cheers,

Quoted 27 lines · Nick Evgeniev

Hi,
Quoted 6 lines
Quoted 1 line
And I have no kernel errors. Hence I conclude that it's a DRIVER bug.
If you had connected them correct the first time like they are now, you would not have had a complaint. Next, maybe spend more money to get quality hardware, since VIA hardware has a history of being poorly intergrated.
What are you talking about?! My system was working perfectly for more than 1 year...
And then after changing kernel, my cabels magically becomes "wrong plugged"?!
WONDERFULL explanation :-/.
Quoted 4 lines
Now think for two seconds or longer if needed.
It now works and the driver has not changed.
Yeah... Best driver is not used... wait a second... even not compiled driver. Am I right?
Well anyway, I plan to change hardware shortly to avoid participation in never-ending
promise driver testing cycle.

Quoted 6 lines

-
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
LAD Storage Consulting Group

Nick Evgeniev

author

2002-06-14 09:08 UTC #9 lore raw

Hi,

Quoted 6 lines

Nick,
http://www.tecchannel.de/hardware/817/index.html
Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.

Ok. Thanks... But it's not my case. Article talks about ata-133 not ata-100..

Quoted 1 line

OIC, it worked perfectly in wonder kernel but not in the latest.

I had 2.4.7 kernel, it was working just fine for me... Then I changed it to 2.4.18/2.4.19-preX
(with all problems I wrote about).

Quoted 2 lines

Did you check to see if there were other changes in the kernel which could effect the behavior and operations?

It's a little bit hard for non-kernel developer to track changes between 10 kernel versions, sorry :(

Quoted 2 lines

A real simple test is to undo the changes to the Promise code and does the problem still exist? If it does then it is not the driver it self.

As I wrote already... I'm in process of changing hardware... and office location.

Quoted 3 lines

However the other changes in conjuntion could cause problems, that is a fair point to be made.

Sure.. But I reported problem as I've seen it in kernel logs.

Quoted 2 lines

So how about including which kernel was the last working version.

2.4.7 Sorry, it's old enough, but usually I don't change kernel till it works...

Quoted 4 lines

For kicks I would back port the driver to prove it is not the driver, or allow you to prove it is.

Actually, no need to do this. As I wrote I'm changing hardware and will try to avoid promise, via, and may be ide :)
Hope it solves the problem :) at least for me.

Vojtech Pavlik

2002-06-14 08:37 UTC #10 lore raw

In reply to Nick Evgeniev

Quoted 7 lines · Andre Hedrick

Nick,
http://www.tecchannel.de/hardware/817/index.html
Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.

Hmm, I don't want to interfere in this nicely-growing flamethrowing, but Andre, you might have noticed, that Nick is saying that it actually *works* on the VIA controller and doesn't on the Promise one. Plus older kernels do work on the Promise controller. That's clearly a software problem.

Quoted 60 lines

OIC, it worked perfectly in wonder kernel but not in the latest. Did you check to see if there were other changes in the kernel which could effect the behavior and operations?
A real simple test is to undo the changes to the Promise code and does the problem still exist? If it does then it is not the driver it self.
However the other changes in conjuntion could cause problems, that is a fair point to be made.
So how about including which kernel was the last working version.
For kicks I would back port the driver to prove it is not the driver, or allow you to prove it is.
Cheers,
Quoted 27 lines · Nick Evgeniev
Hi,
Quoted 6 lines
Quoted 1 line
And I have no kernel errors. Hence I conclude that it's a DRIVER bug.
If you had connected them correct the first time like they are now, you would not have had a complaint. Next, maybe spend more money to get quality hardware, since VIA hardware has a history of being poorly intergrated.
What are you talking about?! My system was working perfectly for more than 1 year...
And then after changing kernel, my cabels magically becomes "wrong plugged"?!
WONDERFULL explanation :-/.
Quoted 4 lines
Now think for two seconds or longer if needed.
It now works and the driver has not changed.
Yeah... Best driver is not used... wait a second... even not compiled driver. Am I right?
Well anyway, I plan to change hardware shortly to avoid participation in never-ending
promise driver testing cycle.
Quoted 6 lines
-
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
LAD Storage Consulting Group
-
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/

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Andre Hedrick

2002-06-14 08:48 UTC #11 lore raw

Quoted 6 lines · Vojtech Pavlik

Quoted 5 lines · Andre Hedrick
Nick,
http://www.tecchannel.de/hardware/817/index.html

Quoted 8 lines

Quoted 2 lines
Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.
Hmm, I don't want to interfere in this nicely-growing flamethrowing, but Andre, you might have noticed, that Nick is saying that it actually *works* on the VIA controller and doesn't on the Promise one. Plus older kernels do work on the Promise controller. That's clearly a software problem.

Well if you have not read, I offered to export the changes to the kernel he states works as a way to isolate the driver from other changes. We have Promise adding their two cents, also.

How about you rewriting the driver an take my name out of it too. Then you can have all the credit be yours.

Regards,

Andre Hedrick
LAD Storage Consulting Group

Vojtech Pavlik

2002-06-14 08:55 UTC #12 lore raw

In reply to Vojtech Pavlik

Quoted 12 lines · Andre Hedrick

Quoted 10 lines · Vojtech Pavlik
Quoted 2 lines · Andre Hedrick
Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.
Hmm, I don't want to interfere in this nicely-growing flamethrowing, but Andre, you might have noticed, that Nick is saying that it actually *works* on the VIA controller and doesn't on the Promise one. Plus older kernels do work on the Promise controller. That's clearly a software problem.

Quoted 3 lines

Well if you have not read, I offered to export the changes to the kernel he states works as a way to isolate the driver from other changes. We have Promise adding their two cents, also.

Yes, but only after you sent him to hell for "user error".

Quoted 1 line

How about you rewriting the driver an take my name out of it too.

Not such a bad idea after all. But the Promise hardware has way too many quirks only the Promise people know for my tastes, even more than VIA. And, after all, as far as I know Bartek is rewriting it right now. ;)

Quoted 1 line

Then you can have all the credit be yours.

And all blame and responsibility - which, I think should make you quite happy. Also note that you're still credited in the rewritten drivers.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs

Andre Hedrick

2002-06-14 09:02 UTC #13 lore raw

Quoted 10 lines · Vojtech Pavlik

Quoted 1 line
How about you rewriting the driver an take my name out of it too.
Not such a bad idea after all. But the Promise hardware has way too many quirks only the Promise people know for my tastes, even more than VIA. And, after all, as far as I know Bartek is rewriting it right now. ;)
Quoted 1 line
Then you can have all the credit be yours.
And all blame and responsibility - which, I think should make you quite happy. Also note that you're still credited in the rewritten drivers.

I would rather not be associated with your careless and thoughtless rework. Funny how you got put on notice for over driving hardware. It is clear you do not understand it so I would prefer to be disassociated from your disasters.

IIRC, gee it must to 133 even though the docs says it does not.

Nice, with any luck pATA will be dead before 2.6 is released so people will not have to suffer data losses from overclocked drivers and main loops issuing "low-level format" command codes to the hardware at boot.

Have a good day,

Andre Hedrick
LAD Storage Consulting Group

Bartlomiej Zolnierkiewicz

2002-06-14 09:15 UTC #14 lore raw

Quoted 7 lines · Andre Hedrick

Quoted 5 lines · Vojtech Pavlik
Quoted 1 line
How about you rewriting the driver an take my name out of it too.
Not such a bad idea after all. But the Promise hardware has way too many quirks only the Promise people know for my tastes, even more than VIA. And, after all, as far as I know Bartek is rewriting it right now. ;)

Cleanup is finished, rewrite is stalled due to lack of spec and hardware... wont spoil anything...

Quoted 13 lines

Quoted 5 lines
Quoted 2 lines
Then you can have all the credit be yours.
And all blame and responsibility - which, I think should make you quite happy. Also note that you're still credited in the rewritten drivers.
I would rather not be associated with your careless and thoughtless rework. Funny how you got put on notice for over driving hardware. It is clear you do not understand it so I would prefer to be disassociated from your disasters.
IIRC, gee it must to 133 even though the docs says it does not.

Quoted 8 lines

Nice, with any luck pATA will be dead before 2.6 is released so people will not have to suffer data losses from overclocked drivers and main loops issuing "low-level format" command codes to the hardware at boot.
Have a good day,
Andre Hedrick
LAD Storage Consulting Group

--
Bartlomiej

Bartlomiej Zolnierkiewicz

2002-06-14 09:19 UTC #15 lore raw

In reply to Andre Hedrick

Quoted 4 lines

Nice, with any luck pATA will be dead before 2.6 is released so people will not have to suffer data losses from overclocked drivers and main loops issuing "low-level format" command codes to the hardware at boot.

It wasn't sending "low-level format"...
It was bug in ide-scsi, and was fixed immediately by Martin...

--
Bartlomiej

Abraham vd Merwe

2002-06-14 08:57 UTC #16 lore raw

In reply to Vojtech Pavlik

Hi Andre!

Quoted 11 lines

Quoted 10 lines
Quoted 4 lines
http://www.tecchannel.de/hardware/817/index.html
Read about the JUNK hardware base you are working with. This is one of the reasons people avoid VIA.
Hmm, I don't want to interfere in this nicely-growing flamethrowing, but Andre, you might have noticed, that Nick is saying that it actually *works* on the VIA controller and doesn't on the Promise one. Plus older kernels do work on the Promise controller. That's clearly a software problem.

Quoted 6 lines

Well if you have not read, I offered to export the changes to the kernel he states works as a way to isolate the driver from other changes. We have Promise adding their two cents, also.
How about you rewriting the driver an take my name out of it too. Then you can have all the credit be yours.

Maybe I shouldn't stick my nose into this, but Andre, you've really got to work on that attitude man. Sarcastic responses are only amusing for so long...

Signature · 15 lines

Regards
 Abraham

The reason they're called wisdom teeth is that the experience makes you wise.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: [email protected]         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Andre Hedrick

2002-06-14 09:11 UTC #17 lore raw

Quoted 5 lines · Abraham vd Merwe

Regards
Abraham
The reason they're called wisdom teeth is that the experience makes you wise.

Mine were removed, and does this count for "sarcastic response".

I am happy not to be in 2.5.

But in a serious note "linux 2.4.19-preX" is a very lose term. Unless otherwise noted, only Alan Cox has been adopting code as a shake down before it goes to Marcelo. So if these are straight 2.4.19-preX kernels, I have not sent anything to Marcelo for offical inclusion. If these are 2.4.19-preX-acX that is a different story.

And yes, maybe I have lost the joy of public kernel development. Then again, I do not have anyone giving me a cakewalk employment package to just write code for kicks now. The net result is vendors who have an interest in customer based support are seeking to offer direct support to get direct support.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Abraham vd Merwe

2002-06-14 09:22 UTC #18 lore raw

In reply to Abraham vd Merwe

Hi Andre!

Quoted 3 lines

Quoted 1 line
The reason they're called wisdom teeth is that the experience makes you wise.
Mine were removed, and does this count for "sarcastic response".

Quoted 8 lines

I am happy not to be in 2.5.
But in a serious note "linux 2.4.19-preX" is a very lose term. Unless otherwise noted, only Alan Cox has been adopting code as a shake down before it goes to Marcelo. So if these are straight 2.4.19-preX kernels, I have not sent anything to Marcelo for offical inclusion. If these are 2.4.19-preX-acX that is a different story.

Quoted 5 lines

And yes, maybe I have lost the joy of public kernel development. Then again, I do not have anyone giving me a cakewalk employment package to just write code for kicks now. The net result is vendors who have an interest in customer based support are seeking to offer direct support to get direct support.

I think you misunderstood my comment. I wasn't commenting about the thread above in particular. I'm sure everyone (I definitely do) appreciate your work and if one of your patches gets dropped in favour of someone else's I'm sure it's nothing personal.

It is just disappointing to see you get into fights with just about everyone about the simplest little differences. Sometimes it just does a lot more good if you show your disagreement in a better tone.

Signature · 16 lines

Regards
 Abraham

If I am elected, the concrete barriers around the WHITE HOUSE will be
replaced by tasteful foam replicas of ANN MARGARET!

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: [email protected]         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Jason C. Pion

2002-06-11 18:55 UTC #19 lore raw

In reply to Nick Evgeniev

Quoted 3 lines · Nick Evgeniev

Agreed. But all what I see is that STABLE Linux kernel DOESN'T has working driver for promise controller (including latest ac patches) for SEVERAL MONTHS.

<SNIP>

Quoted 5 lines

I don't want to make experiments in production environment anymore... And it's
unfair to the rest of Linux users to keep broken drivers in stable kernel... Because
nobody expects that stable kernel will rip your fs _daily_.

It sounds to me like you've got some flakey hardware. Don't try to save the rest of us. I've been using the Promise drivers with my Ultra 133TX2 for quite a while now and haven't had _ANY_ problems with it. I've used all of the 2.4.19preXX kernels so far with now issues. This "problem" isn't as wide-spread as you think.

Later,
Jason

Bill Davidsen

2002-06-14 12:40 UTC #20 lore raw

Quoted 5 lines · Jason C. Pion

It sounds to me like you've got some flakey hardware. Don't try to save the rest of us. I've been using the Promise drivers with my Ultra 133TX2 for quite a while now and haven't had _ANY_ problems with it. I've used all of the 2.4.19preXX kernels so far with now issues. This "problem" isn't as wide-spread as you think.

Clearly *any* problem which only happens with SMP isn't as wide-spread, and if you are running uni then there should not be a problem. Given that earlier and later similar chipset have a sticky bit and no problem, I think it would be reasonable to protect people in a stable kernel. If the config file needed to be patched and there were a warning on the next line, that would certainly assure they knew they were taking a risk.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Jason C. Pion

2002-06-14 14:24 UTC #21 lore raw

Quoted 2 lines · Bill Davidsen

Clearly *any* problem which only happens with SMP isn't as wide-spread, and if you are running uni then there should not be a problem. Given that

This system is a Tyan S2460 with 2 AMD 1600+ processors. I am not booting with the "noapic" option. (Haven't needed to) The Promise Ultra133TX2 (20269) runs very happily with the AMD7411 that is on the mobo. The Promise BIOS recognizes both attached drives as UDMA(133) and the kernel sets them up and uses them properly. I do not need to do anything special at boot time either. It just works!

Quoted 4 lines

earlier and later similar chipset have a sticky bit and no problem, I think it would be reasonable to protect people in a stable kernel. If the config file needed to be patched and there were a warning on the next line, that would certainly assure they knew they were taking a risk.

I agree that some kind of warning (maybe the "EXPERIMENTAL" note in menuconfig) is appropriate for drivers that have known issues with certain pieces of hardware. However, I can not condone pulling the driver from the kernel. If it is working perfectly for some people, we would be penalizing them.

Later,
Jason

Tomas Szepe

2002-06-11 19:35 UTC #22 lore raw

In reply to Nick Evgeniev

Quoted 3 lines

It sounds to me like you've got some flakey hardware. Don't try to save the rest of us. I've been using the Promise drivers with my Ultra 133TX2 for quite a while now and haven't had _ANY_ problems with it.

Yup, with the exception of the "have to boot with ide2=ata66 to get udma 3/4/5 to work" bug, it seems to work perfectly.

Jason C. Pion

2002-06-11 19:50 UTC #23 lore raw

Quoted 6 lines · Tomas Szepe

Quoted 3 lines
It sounds to me like you've got some flakey hardware. Don't try to save the rest of us. I've been using the Promise drivers with my Ultra 133TX2 for quite a while now and haven't had _ANY_ problems with it.
Yup, with the exception of the "have to boot with ide2=ata66 to get udma 3/4/5 to work" bug, it seems to work perfectly.

Actually, mine doesn't require any boot params for ide. The attached disks are both detected and setup as UDMA(133) right from the get go. Works quite well.

Later,
Jason

Bill Davidsen

2002-06-11 22:55 UTC #24 lore raw

In reply to Nick Evgeniev

Quoted 4 lines · Nick Evgeniev

I don't want to make experiments in production environment anymore... And it's unfair to the rest of Linux users to keep broken drivers in stable kernel... Because nobody expects that stable kernel will rip your fs _daily_.

I remember when SMP started, if used with certain filesystem types it
would regularly eat the f/s data. The argument was made that it should be commented out of the config file, so you really had to work at getting it turned on. In spite of that a number of (from memory early 2.2) kernels had the defect and led to people thinking that Linux was unreliable in general.

I agree that if it has known problems which destroy data it should be
unavailable in the stable kernel. It certainly sounds as if that's the case, and the driver could be held out until 2.4.20 or so when it can be fixed, or if it can't be fixed it can just go away.

A stable kernel release should be, well... stable. Give the enemies of
Linux no ammunition, they make up enough crap as it is.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Andre Hedrick

2002-06-12 00:35 UTC #25 lore raw

Oh lets just comment and delete the whole driver.
Everyone knows I am the king of tosser code and driver writing. Everyone knows that I am a fraud and clear can not write a storage driver. Surely it has to be the Maintainer's fault, because everyone is capable of installing hardware and getting connection correct. Nobody ever buy cheap crappy mainboards, cause they do not exist. Obviously the hardware is always perfect, and the code is pathetic an whoafully buggy and I should just quit attempting to be something I can't.

Well, I am damn close to orphaning the driver. Maybe we should just copy 2.5 back into 2.4 and be done!

Regards,

Andre Hedrick
LAD Storage Consulting Group

Quoted 26 lines · Bill Davidsen

Quoted 4 lines · Nick Evgeniev
I don't want to make experiments in production environment anymore... And it's unfair to the rest of Linux users to keep broken drivers in stable kernel... Because nobody expects that stable kernel will rip your fs _daily_.
I remember when SMP started, if used with certain filesystem types it
would regularly eat the f/s data. The argument was made that it should be commented out of the config file, so you really had to work at getting it turned on. In spite of that a number of (from memory early 2.2) kernels had the defect and led to people thinking that Linux was unreliable in general.
I agree that if it has known problems which destroy data it should be
unavailable in the stable kernel. It certainly sounds as if that's the case, and the driver could be held out until 2.4.20 or so when it can be fixed, or if it can't be fixed it can just go away.
A stable kernel release should be, well... stable. Give the enemies of
Linux no ammunition, they make up enough crap as it is.
Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Alan Cox

2002-06-12 07:13 UTC #26 lore raw

In reply to Bill Davidsen

Quoted 4 lines

I agree that if it has known problems which destroy data it should be
unavailable in the stable kernel. It certainly sounds as if that's the case, and the driver could be held out until 2.4.20 or so when it can be fixed, or if it can't be fixed it can just go away.

Then I suggest you give up computing, because PC hardware doesnt make your grade. BTW the general open promise bugs *dont* include data corruption so I suspect it may be your h/w thats hosed.

Bill Davidsen

2002-06-12 14:03 UTC #27 lore raw

Quoted 8 lines · Alan Cox

Quoted 4 lines
I agree that if it has known problems which destroy data it should be
unavailable in the stable kernel. It certainly sounds as if that's the case, and the driver could be held out until 2.4.20 or so when it can be fixed, or if it can't be fixed it can just go away.
Then I suggest you give up computing, because PC hardware doesnt make your grade. BTW the general open promise bugs *dont* include data corruption so I suspect it may be your h/w thats hosed.

Mine, and the original poster? And the "me too?" I understood the author to say that the new board needed a driver change, and if that's the case why not hold off the driver until he gets to it? Nobody if faulting him for lack of time, but it seems not to work.

Guess it must be my hardware, two boards, two systems, corruption only on the drives on the new... hell with it, obviously if you don't have the problem the original poster and I must be clueless whiners.

I'll drop this discussion and scrap the board, restores cost more than controllers :-(

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Andre Hedrick

2002-06-12 18:48 UTC #28 lore raw

Bill,

The hardware changed and the interrupt parser feature that stablized the old chipsets under SMP is gone. The new chipsets (20268 and above) do not have a location with sticky bits. So in some cases I expect things to go south, but in general they should not. Otherwise promise would be all over the issue.

Cheers,

Quoted 16 lines · Bill Davidsen

Quoted 8 lines · Alan Cox
Quoted 4 lines
I agree that if it has known problems which destroy data it should be
unavailable in the stable kernel. It certainly sounds as if that's the case, and the driver could be held out until 2.4.20 or so when it can be fixed, or if it can't be fixed it can just go away.
Then I suggest you give up computing, because PC hardware doesnt make your grade. BTW the general open promise bugs *dont* include data corruption so I suspect it may be your h/w thats hosed.
Mine, and the original poster? And the "me too?" I understood the author to say that the new board needed a driver change, and if that's the case why not hold off the driver until he gets to it? Nobody if faulting him for lack of time, but it seems not to work.

Quoted 12 lines

Guess it must be my hardware, two boards, two systems, corruption only on the drives on the new... hell with it, obviously if you don't have the problem the original poster and I must be clueless whiners.
I'll drop this discussion and scrap the board, restores cost more than controllers :-(
Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Andre Hedrick
LAD Storage Consulting Group

Bill Davidsen

2002-06-12 20:35 UTC #29 lore raw

Quoted 5 lines · Andre Hedrick

The hardware changed and the interrupt parser feature that stablized the old chipsets under SMP is gone. The new chipsets (20268 and above) do not have a location with sticky bits. So in some cases I expect things to go south, but in general they should not. Otherwise promise would be all over the issue.

Okay, thanks, that clarifies it, and if I read it right this may be a
permanent restriction. If the system is running noapic so the ints all go to CPU0 does that help the situation? In a sane system I agree with Alan that this is not a performance hit, or at least not significant.

Quoted 8 lines

Quoted 5 lines · Alan Cox
Quoted 4 lines
Then I suggest you give up computing, because PC hardware doesnt make your grade. BTW the general open promise bugs *dont* include data corruption so I suspect it may be your h/w thats hosed.
Andre Hedrick
LAD Storage Consulting Group

Guys, I wasn't questioning anyone's competence, just agreeing with the original poster that if this is going to be an ongoing issue of stability it might be held back for a version until there is time to either program around it or characterize the conditions under which it causes problems. And if that means that I can't trust it SMP, I don't think I'm a bad guy to suggest the config drop the driver if SMP support is selected.

I don't mind moving a card to another system, and even if I didn't have another system I would rather not take that particular risk. And if it won't work reliably SMP then perhaps Promise should be taking some action. There are SMP W2k machines out there, too.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Alan Cox

2002-06-12 07:15 UTC #30 lore raw

In reply to Nick Evgeniev

Quoted 3 lines

Agreed. But all what I see is that STABLE Linux kernel DOESN'T has working driver for promise controller (including latest ac patches) for SEVERAL MONTHS.

I think you have hosed hardware. Vendors ship a lot of Linux and get almost no such reports. Things like the LBA48 hang and VIA hardware bug showed up well - promise disk corruption -no