linux 2.4.19-preX IDE bugs

linux 2.4.19-preX IDE bugs

[Nick Evgeniev]

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.

Re: linux 2.4.19-preX IDE bugs

[Alan Cox]

On Tue, 2002-06-04 at 16:28, Nick Evgeniev wrote: 
> 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

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

On 4 Jun 2002, Alan Cox wrote:

> On Tue, 2002-06-04 at 16:28, Nick Evgeniev wrote: 
> > 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

> 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

Re: linux 2.4.19-preX IDE bugs

[Nick Evgeniev]

Hi,

> > 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_.

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

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.

On Tue, 11 Jun 2002, Nick Evgeniev wrote:

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

Re: linux 2.4.19-preX IDE bugs

[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.
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
>---------------------------------------------------------------------------
----------------------------------
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:
>---------------------------------------------------------------------------
--------------------------------------------------------------
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




> 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.
>
> On Tue, 11 Jun 2002, Nick Evgeniev wrote:
>
> > Hi,
> >
> > > > 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
> LAD Storage Consulting Group
>
>

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

On Thu, 13 Jun 2002, Nick Evgeniev wrote:

> 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.

> 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


> 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
> >---------------------------------------------------------------------------
> ----------------------------------
> 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:
> >---------------------------------------------------------------------------
> --------------------------------------------------------------
> 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
> 
> 
> 
> 
> > 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.
> >
> > On Tue, 11 Jun 2002, Nick Evgeniev wrote:
> >
> > > Hi,
> > >
> > > > > 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
> > LAD Storage Consulting Group
> >
> >
> 

Re: linux 2.4.19-preX IDE bugs

[Nick Evgeniev]

Hi,

> > 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 :-/.

>
> 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.

Re: linux 2.4.19-preX IDE bugs

[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.

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,

On Fri, 14 Jun 2002, Nick Evgeniev wrote:

> Hi,
> 
> > > 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 :-/.
> 
> >
> > 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.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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

Re: linux 2.4.19-preX IDE bugs

[Vojtech Pavlik]

On Fri, Jun 14, 2002 at 01:20:34AM -0700, Andre Hedrick wrote:
> 
> 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.

> 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,
> 
> On Fri, 14 Jun 2002, Nick Evgeniev wrote:
> 
> > Hi,
> > 
> > > > 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 :-/.
> > 
> > >
> > > 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.
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

On Fri, 14 Jun 2002, Vojtech Pavlik wrote:

> On Fri, Jun 14, 2002 at 01:20:34AM -0700, Andre Hedrick wrote:
> > 
> > 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.

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

Re: linux 2.4.19-preX IDE bugs

[Vojtech Pavlik]

On Fri, Jun 14, 2002 at 01:45:20AM -0700, Andre Hedrick wrote:

> On Fri, 14 Jun 2002, Vojtech Pavlik wrote:
> > On Fri, Jun 14, 2002 at 01:20:34AM -0700, Andre Hedrick wrote:

> > > 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.

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

> 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.  ;)

> 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. 

-- 
Vojtech Pavlik
SuSE Labs

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

On Fri, 14 Jun 2002, Vojtech Pavlik wrote:

> > 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.  ;)
> 
> > 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

Re: linux 2.4.19-preX IDE bugs

[Bartlomiej Zolnierkiewicz]

On Fri, 14 Jun 2002, Andre Hedrick wrote:

> On Fri, 14 Jun 2002, Vojtech Pavlik wrote:
>
> > > 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...

> >
> > > 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

Re: linux 2.4.19-preX IDE bugs

[Bartlomiej Zolnierkiewicz]

> 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

Re: linux 2.4.19-preX IDE bugs

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Hi Andre!

> > > 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.
> 
> 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...

-- 

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: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

On Fri, 14 Jun 2002, Abraham vd Merwe wrote:
> 
> 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

Re: linux 2.4.19-preX IDE bugs

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Hi Andre!

> > 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.

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.

-- 

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: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: linux 2.4.19-preX IDE bugs

[Nick Evgeniev]

Hi,

> 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..

> 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).

> 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 :(

> 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.
>
> 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.
>
> 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...

>
> 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.

Re: linux 2.4.19-preX IDE bugs

[Jason C. Pion]

On Tue, 11 Jun 2002, Nick Evgeniev wrote:

> 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> 
> 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

Re: linux 2.4.19-preX IDE bugs

[Tomas Szepe]

> 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.

T.

Re: linux 2.4.19-preX IDE bugs

[Jason C. Pion]

On Tue, 11 Jun 2002, Tomas Szepe wrote:

> > 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

Re: linux 2.4.19-preX IDE bugs

[Bill Davidsen]

On Tue, 11 Jun 2002, Jason C. Pion wrote:


> 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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: linux 2.4.19-preX IDE bugs

[Jason C. Pion]

On Fri, 14 Jun 2002, Bill Davidsen wrote:

> 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!

> 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

Re: linux 2.4.19-preX IDE bugs

[Bill Davidsen]

On Tue, 11 Jun 2002, Nick Evgeniev wrote:

> 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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

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

On Tue, 11 Jun 2002, Bill Davidsen wrote:

> On Tue, 11 Jun 2002, Nick Evgeniev wrote:
> 
> > 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.
> 
> -- 
> bill davidsen <davidsen@tmr.com>
>   CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.

Re: linux 2.4.19-preX IDE bugs

[Alan Cox]

>   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.

Re: linux 2.4.19-preX IDE bugs

[Bill Davidsen]

On Wed, 12 Jun 2002, Alan Cox wrote:

> >   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 :-(

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: linux 2.4.19-preX IDE bugs

[Andre Hedrick]

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,

On Wed, 12 Jun 2002, Bill Davidsen wrote:

> On Wed, 12 Jun 2002, Alan Cox wrote:
> 
> > >   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 :-(
> 
> -- 
> bill davidsen <davidsen@tmr.com>
>   CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
> 

Andre Hedrick
LAD Storage Consulting Group

Re: linux 2.4.19-preX IDE bugs

[Bill Davidsen]

On Wed, 12 Jun 2002, Andre Hedrick wrote:

> 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.
 
> > On Wed, 12 Jun 2002, Alan Cox wrote:

> > > 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. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: linux 2.4.19-preX IDE bugs

[Alan Cox]

> 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

Re: linux 2.4.19-preX IDE bugs

[Mikael Pettersson]

On Tue, 11 Jun 2002 19:31:48 +0400, Nick Evgeniev wrote:
>> > 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.

I don't know what your problem with the Promise driver is, but
my experience is the opposite. I have never had any problems with
the 2.4 (or 2.2 + Andre's IDE patch) pdc202xx driver and my
Ultra100 (20267) card, which sits in a 24/7 News server and
receives, stores, and sends many gigabytes of data between reboots.
(And it's only rebooted once a month or so because I prefer using
uptodate kernels. Currently running 2.4.19-pre9.)

/Mikael

Re: linux 2.4.19-preX IDE bugs

[Mikael Pettersson]

On Thu, 13 Jun 2002 15:28:13 +0400, Nick Evgeniev wrote:
>Are you using it in SMP config?
>
>> >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 don't know what your problem with the Promise driver is, but
>> my experience is the opposite. I have never had any problems with
>> the 2.4 (or 2.2 + Andre's IDE patch) pdc202xx driver and my
>> Ultra100 (20267) card, which sits in a 24/7 News server and

No, UP (ASUS 440BX board).

Instead of blasting out "the driver doesn't work, remove it!" when
it obviously does work in many cases, you should investigate
(perhaps through a poll on LKML) which configurations work and
which ones do not. That may provide enough clues to identify and
hopefully fix the problem.

/Mikael

Re: linux 2.4.19-preX IDE bugs

[Anssi Saari]

On Fri, 14 Jun 2002, Andre Hedrick wrote: 

> 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. 

Do you have recommendations for chipsets for AMD CPUs, especially from
Linux IDE driver guy's point of view and especially regarding Linux
support for them? ALi, AMD, nVidia or SiS?

It seems hard to find any comparisons between current VIA and non-VIA
motherboards on the net. 

Re: linux 2.4.19-preX IDE bugs

[Vojtech Pavlik]

On Sat, Jun 15, 2002 at 08:12:47PM +0300, Anssi Saari wrote:
> On Fri, 14 Jun 2002, Andre Hedrick wrote: 
> 
> > 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. 
> 
> Do you have recommendations for chipsets for AMD CPUs, especially from
> Linux IDE driver guy's point of view and especially regarding Linux
> support for them? ALi, AMD, nVidia or SiS?
> 
> It seems hard to find any comparisons between current VIA and non-VIA
> motherboards on the net. 

ALi: don't know.
AMD: Works fine. UDMA100 max. I like these best.
nVidia: Only in 2.5 kernels.
SiS: don't know.
VIA: Works fine. If you're unlucky and get a bad board, then, well,
	you're unlucky. Currently the fastest Athlon solution.

-- 
Vojtech Pavlik
SuSE Labs