HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Hello.
[1.] One line summary of the problem:    
Intermittent corruption of 4 bytes in SMP kernels using HPT366

[2.] Full description of the problem/report:
First noticed in 2.3.99-preX; but hard to track down then.
When the system was under load - e.g. cp /usr/src/linux /usr/src/l2,
it would occasionally and randomly corrupt some files; possibly multiple
times per file; possibly multiple files. always exactly 4 bytes would be
altered per corruption.
Nothing shows up in logs; no oopses; no messages.
Tests on 2.3.99 found the problem to be unreproducable on UP kernels
Tests on the current kernel found the problem to be unreproducable on
the BX chipset's own ATA33 controller.

[3.] Keywords (i.e., modules, networking, kernel):
IDE, HPT366, EXT2, SMP, Corruption, Worrying

[4.] Kernel version (from /proc/version):
#cat /proc/version 
Linux version 2.4.0-test11-ac4-smp (root@midnight) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Tue Nov 28
22:38:21 NZDT 2000

[5.]
Nada

[6.] A small shell script or example program which triggers the
     problem (if possible)
cp /usr/src/linux /usr/src/l2 ; diff -dur /usr/src/linux /usr/src/l2
shows the problem up if diff produces any output
system may 'survive' two copies (I tend to use a different, uncached
kernel for each attempt - to rule out/minimise the effect of caching)
but 'fail' the third.
where 'survive' = no corruption; 'fail' = some / lots of corruption.
High memory usage increases likelihood; hitting swap at ALL seems to
increase likelihood (swap on same drive)

[7.] Environment
Redhat 6.2 basis.
Abit BP6 Motherboard.
Dual Celeron 466's
128 Mb ram; 13.6 Gb Seagate Barracuda HDD
"hda: ST313620A, ATA DISK drive"
CD-ROM on hdd

[7.1.] Software (add the output of the ver_linux script here)

-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux midnight 2.4.0-test11-ac4-smp #2 SMP Tue Nov 28 22:38:21 NZDT 2000
i686 unknown
Kernel modules         2.3.13
Gnu C                  egcs-2.91.66
Gnu Make               3.78.1
Binutils               2.9.5.0.22
Linux C Library        2.1.3
Dynamic linker         ldd (GNU libc) 2.1.3
Procps                 2.0.6
Mount                  2.10q
Net-tools              1.54
Console-tools          0.3.3
Sh-utils               2.0

[7.2.] Processor information (from /proc/cpuinfo):

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 6
model name      : Celeron (Mendocino)
stepping        : 5
cpu MHz         : 467.000741
cache size      : 128 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
bogomips        : 933.89

processor       : 0
vendor_id       : GenuineIntel
...

[7.3.] Module information (from /proc/modules):
Doesn't Impact Problem.

[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)
#cat /proc/ioports 
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0220-022f : soundblaster
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
  03c0-03df : matrox
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
  5000-5007 : piix4-smbus
d000-d01f : Intel Corporation 82371AB PIIX4 USB
d400-d4ff : Realtek Semiconductor Co., Ltd. RTL-8139
  d400-d4ff : eth0
d800-d807 : Triones Technologies, Inc. HPT366
dc00-dc03 : Triones Technologies, Inc. HPT366
e000-e0ff : Triones Technologies, Inc. HPT366
  e000-e007 : ide2
  e010-e0ff : HPT366
e400-e407 : Triones Technologies, Inc. HPT366 (#2)
e800-e803 : Triones Technologies, Inc. HPT366 (#2)
ec00-ecff : Triones Technologies, Inc. HPT366 (#2)
  ec00-ec07 : ide3
  ec10-ecff : HPT366
f000-f00f : Intel Corporation 82371AB PIIX4 IDE
  f000-f007 : ide0
  f008-f00f : ide1

#cat /proc/iomem   
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-07ffffff : System RAM
  00100000-0021232f : Kernel code
  00212330-002239ff : Kernel data
e0000000-e3ffffff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
e4000000-e4003fff : Matrox Graphics, Inc. MGA 1064SG [Mystique]
  e4000000-e4003fff : matroxfb MMIO
e5000000-e57fffff : Matrox Graphics, Inc. MGA 1064SG [Mystique]
  e5000000-e57fffff : matroxfb FB
e6000000-e67fffff : Matrox Graphics, Inc. MGA 1064SG [Mystique]
e9000000-e90000ff : Realtek Semiconductor Co., Ltd. RTL-8139
  e9000000-e90000ff : eth0
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved


[7.5.] PCI information ('lspci -vvv' as root)
===
#lspci -vvv | less
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03
)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort+ >SERR- <PERR-
        Latency: 32 set
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03) 
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 64 set
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fff00000-000fffff
        Prefetchable memory behind bridge: fff00000-000fffff
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B+

00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0 set

00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
(prog-if 80 
[Master])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 set
        Region 4: I/O ports at f000 [size=16]
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
(prog-if 00
 [UHCI])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 set
        Interrupt: pin D routed to IRQ 19
        Region 4: I/O ports at d000 [size=32]

00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-

00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG
[Mystique] (
rev 02) (prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping+ SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 set
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at e4000000 (32-bit, non-prefetchable)
[size=16K]
        Region 1: Memory at e5000000 (32-bit, prefetchable) [size=8M]
        Region 2: Memory at e6000000 (32-bit, non-prefetchable)
[size=8M]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 min, 64 max, 32 set
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at d400 [size=256]
        Region 1: Memory at e9000000 (32-bit, non-prefetchable)
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
        Capabilities: [60] Vital Product Data
00:13.0 Unknown mass storage controller: Triones Technologies, Inc.
HPT366 (rev 
01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 8 min, 8 max, 120 set, cache line size 08
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at d800 [size=8]
        Region 1: I/O ports at dc00 [size=4]
        Region 4: I/O ports at e000 [size=256]
        Expansion ROM at e8000000 [disabled] [size=128K]

00:13.1 Unknown mass storage controller: Triones Technologies, Inc.
HPT366 (rev 
01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 8 min, 8 max, 120 set, cache line size 08
        Interrupt: pin B routed to IRQ 18
        Region 0: I/O ports at e400 [size=8]
        Region 1: I/O ports at e800 [size=4]
        Region 4: I/O ports at ec00 [size=256]
===

[7.6.] SCSI information (from /proc/scsi/scsi)
Nada

[7.7.]
snippets from dmesg:
=== <hard drive on hde> ===
HPT366: onboard version of chipset, pin1=1 pin2=2 
HPT366: IDE controller on PCI bus 00 dev 98 
PCI: Enabling device 00:13.0 (0005 -> 0007) 
HPT366: chipset revision 1 
HPT366: not 100% native mode: will probe irqs later 
    ide2: BM-DMA at 0xe000-0xe007, BIOS settings: hde:DMA, hdf:pio 
HPT366: IDE controller on PCI bus 00 dev 99 
HPT366: chipset revision 1 
HPT366: not 100% native mode: will probe irqs later 
    ide3: BM-DMA at 0xec00-0xec07, BIOS settings: hdg:pio, hdh:pio 
hdd: FX240S, ATAPI CDROM drive 
hde: ST313620A, ATA DISK drive 
ide1 at 0x170-0x177,0x376 on irq 15 
ide2 at 0xd800-0xd807,0xdc02 on irq 18 
hde: 26692776 sectors (13667 MB) w/512KiB Cache, CHS=26480/16/63,
UDMA(66) 
=== </hard drive on hde> ===

=== <hard drive on hda> ===
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
PCI: Enabling device 00:13.0 (0005 -> 0007)
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xe000-0xe007, BIOS settings: hde:pio, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
    ide3: BM-DMA at 0xec00-0xec07, BIOS settings: hdg:pio, hdh:pio
hda: ST313620A, ATA DISK drive
hdd: FX240S, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 26692776 sectors (13667 MB) w/512KiB Cache, CHS=1661/255/63,
UDMA(33)
=== </hard drive on hda> ===


[X.] Other notes, patches, fixes, workarounds:

Only current workaround is to avoid the HPT chip :(

I can't help but worry that (especially after the volume of this email)
it's a simple problem / my fault - however; I have not seen anything
specific to this in the past few months.

I can offer to help debug; but my time is limited due to the twin evils
of Work and Sleep; and I don't have too many leads what with no error
output; just silent corruption :(


Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gnea]

On Sat, 02 Dec 2000 00:04:27 +1300, Gerard Sharp blurted forth:

> Hello.
>  [1.] One line summary of the problem:    
>  Intermittent corruption of 4 bytes in SMP kernels using HPT366
[snip]
>  [7.] Environment
>  Redhat 6.2 basis.
>  Abit BP6 Motherboard.
>  Dual Celeron 466's
>  128 Mb ram; 13.6 Gb Seagate Barracuda HDD
>  "hda: ST313620A, ATA DISK drive"
>  CD-ROM on hdd
[snip]

Have you tried updating the bios on the bp6? This solved a LOT of
problems for me, and afaik, ru is the latest... if you need a hand with
it, i've put together a dos boot disk with everything you'll need at:
http://garson.org/~gnea/bp6-biosupdate.img

just dd if=bp6-biosupdate.img of=/dev/fd0 and boot it, run awdflash.exe
and tell it to use bp6_ru.bin when it asks for a file... have it back
up the current bios (just in case) and reboot when ready.. you'll of
course need to go into the bios on reboot and reset everything to
defaults, then go thru and re-tweak (this is the proper method.. not
doing so can create further problems) all of your settings until it's
satisfactorily set... also, the overclocking might be a bad thing in
this case unless you have the proper cooling for it (lm-sensors is
great for this sort of thing :) there's a neat wm applet called wmbp6
too) so u may want to try clocking it straight at 300 for awhile and
see what effect that has.. hope this helps

-- 
	.oO gnea at rochester dot rr dot com Oo.
	    .oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Gnea wrote:
> >  [1.] One line summary of the problem:
> >  Intermittent corruption of 4 bytes in SMP kernels using HPT366
> [snip]
> Have you tried updating the bios on the bp6? This solved a LOT of
> problems for me, and afaik, ru is the latest... 

RU seems the latest. Flashed bios as per your nicely detailed
instructions.
No improvement in condition, alas.

> also, the overclocking might be a bad thing in this case unless you 
> have the proper cooling for it (lm-sensors is great for this sort of
> thing :) there's a neat wm applet called wmbp6 too) so u may want to 
> try clocking it straight at 300 for awhile and see what effect that 
> has.. hope this helps

Err. "300(66)" probably won't help too much. The cpu's are multiplier
locked (love that one, Intel); so will run at 7 * 66 (466) when set to
chip defaults - which I currently am - to rule out flaky / stressed
hardware.

Temperatures are a nice frosty 30 deg C across all the temperature
sensors lm_sensors offers; and the thermal probe I have dangling in the
psu exhaust :)
[this is with two rc5des clients running - loadavg of 2 - btw]

Back to the original topic, I've done some more 'research'; and I'm not
_certain_ of my findings, but there's a few coincidences here...

I think I'll make a more general post to lkml direct in a minute.


Gerard Sharp
Two penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Hello Again

Some more details, now that I scraped a few minutes on the weekend to
look into this.
Same hardware configuration as my earlier post; with a newer bios
version on the motherboard; with no improvement.

Some long winded test results, and my conclusions:
[abridged] output from diff for one flawed copy:
===
linux/fs/cramfs/inflate/inffixed.h
-    {{{84,7}},99}, {{{0,8}},127}, {{{0,8}},63}, {{{0,9}},223},
+    {{{84,7}},99}, {{{0,8}},127}{0,8}},63}, {{{0,9}},223},
linux/fs/jffs/intrep.c
-                       jffs_fmfree_partly(fmc, fm, total_data_size);
-                       jffs_fm_write_unlock(fmc);
+                       jffs_fmfree_partly(fmc, fm,
total_data_sizport                  jffs_fm_write_unlock(fmc);
linux/kernel/resource.c
-int allocate_resource(struct resource *root, struct resource *new,
+int allocate_rrce(struct resource *root, struct resource *new,
===
Closer inspection of the three "corrupt" files, using the command
od -tc <file> | less
revealed that in all cases, the corruption was the four bytes
immediately preceding an exact multiple of 4096 - the block size for the
(ext2) fs...
I may well go back and read the "corruption" thread which gave me the
idea for the comparison when I wake up :(
for inffixed.h, the correct dump reads
0017740   {   {   {   8   4   ,   7   }   }   ,   9   9   }   ,       { 
0017760   {   {   0   ,   8   }   }   ,   1   2   7   }   ,       {   { 
0020000   {   0   ,   8   }   }   ,   6   3   }   ,       {   {   {   0 
0020020   ,   9   }   }   ,   2   2   3   }   ,  \n                   { 
and the flawed dump reads
0017740   {   {   {   8   4   ,   7   }   }   ,   9   9   }   ,       { 
0017760   {   {   0   ,   8   }   }   ,   1   2   7   }  \0  \0  \0  \0 
0020000   {   0   ,   8   }   }   ,   6   3   }   ,       {   {   {   0 
0020020   ,   9   }   }   ,   2   2   3   }   ,  \n                   { 
0x0020000 -> 131072 -> 32 x 4k

likewise for intrep.c
0177740   r   t   l   y   (   f   m   c   ,       f   m   ,       t   o 
0177760   t   a   l   _   d   a   t   a   _   s   i   z   e   )   ;  \n 
0200000  \t  \t  \t   j   f   f   s   _   f   m   _   w   r   i   t   e 
0200020   _   u   n   l   o   c   k   (   f   m   c   )   ;  \n  \t  \t 
and the flawed dump reads
0177740   r   t   l   y   (   f   m   c   ,       f   m   ,       t   o 
0177760   t   a   l   _   d   a   t   a   _   s   i   z   p   o   r   t 
0200000  \t  \t  \t   j   f   f   s   _   f   m   _   w   r   i   t   e 
0200020   _   u   n   l   o   c   k   (   f   m   c   )   ;  \n  \t  \t 
0x0200000 -> 2097152 -> 512 x 4k


I have a couple more examples; the corruption is still present after a
reboot; but I have yet to see what fsck makes of it...
[Addendum: corruption is still present after fsck]

So, in summary; when using the HPT366 controller with my claimed ATA66
drive; using an SMP kernel with two Celeron 466's (at 466), under load I
find intermittant corruption of the ext2 filesystem.
always four bytes; and apparently commonly (maybe always?) the four
before an exact multiple of 4096 bytes - the filesystem block size.
The values that are written instead of the correct data do not appear to
be random; but rather data from the (memory) cache; I've noticed one or
two previously that look "familiar"; but that may just be my tired eyes.

That's all I can think (ramble?) of at this time; Awaiting bright ideas;
or more free time to fiddle more. Thanks in Advance (for all the bright
ideas :) )


Gerard Sharp 
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Dan Hollis]

On Tue, 5 Dec 2000, Gerard Sharp wrote:
> Gnea wrote:
> > >  [1.] One line summary of the problem:
> > >  Intermittent corruption of 4 bytes in SMP kernels using HPT366
> > [snip]
> > Have you tried updating the bios on the bp6? This solved a LOT of
> > problems for me, and afaik, ru is the latest...
> RU seems the latest. Flashed bios as per your nicely detailed
> instructions.
> No improvement in condition, alas.

HPT366 on BP6 is just broken. Corruption and lockups happen under
microsoft-windoze as well.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Richard Torkar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Hollis wrote:

> On Tue, 5 Dec 2000, Gerard Sharp wrote:
> > Gnea wrote:
> > > >  [1.] One line summary of the problem:
> > > >  Intermittent corruption of 4 bytes in SMP kernels using HPT366
> > > [snip]
> > > Have you tried updating the bios on the bp6? This solved a LOT of
> > > problems for me, and afaik, ru is the latest...
> > RU seems the latest. Flashed bios as per your nicely detailed
> > instructions.
> > No improvement in condition, alas.
>
> HPT366 on BP6 is just broken. Corruption and lockups happen under
> microsoft-windoze as well.
>

Not my experience Dan.

I've used my BP6 + HPT366 for a while now and I haven't had on lockup.
No corruption either.

Presently I use 2.4.0-test11-p4 and I have been following the 2.3.* kernel
since the day I got the BP6.

I have two Celeron 500 which are *not* o/c.
I have seti@home running on this box 24/7.
I use the latest BIOS.

I guess I'm lucky *grin*



/Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6LAwsUSLExYo23RsRAtY+AKCOuqpfcSa73zzpHQfddSY/7JG8IACffPRe
UzfNUJ7t3y2jdsS4jmS4Ggg=
=FdqO
-----END PGP SIGNATURE-----


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Dan Hollis]

On Mon, 4 Dec 2000, Richard Torkar wrote:
> Dan Hollis wrote:
> > On Tue, 5 Dec 2000, Gerard Sharp wrote:
> > > Gnea wrote:
> > > > >  [1.] One line summary of the problem:
> > > > >  Intermittent corruption of 4 bytes in SMP kernels using HPT366
> > > > [snip]
> > > > Have you tried updating the bios on the bp6? This solved a LOT of
> > > > problems for me, and afaik, ru is the latest...
> > > RU seems the latest. Flashed bios as per your nicely detailed
> > > instructions.
> > > No improvement in condition, alas.
> > HPT366 on BP6 is just broken. Corruption and lockups happen under
> > microsoft-windoze as well.
> Not my experience Dan.
> I've used my BP6 + HPT366 for a while now and I haven't had on lockup.
> No corruption either.
> I guess I'm lucky *grin*

Your 1 success out of maybe 500-1000 peoples failures. Not exactly a great
average for this motherboard. BP6 is notorious for instability, HPT366 on
it is about 50% of the problems.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Mike Dresser]

Agreed.  I've got one of these beasts running NT Server, dual 433 non o/c,
4x12.7 gig software raid. Before i put the Promise Ultra/33 card in, i was
using the HPT366.  Random lockups every couple weeks.  Stopped using the
HPT366, machine is stable now.  In hindsight, I think the HPT366 was the cause
of the Onstream 50 gig drive that locked up frequently too, before i shipped
that back to Onstream.  One thing that did help on stability was putting a cpu
fan on the chipset.

Dan Hollis wrote:

>
> Your 1 success out of maybe 500-1000 peoples failures. Not exactly a great
> average for this motherboard. BP6 is notorious for instability, HPT366 on
> it is about 50% of the problems.
>
> -Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Winfried Truemper]

What helped me was to use old IDE cables to enforce UDMA-33.
Switching to an 80-conductor cable makes the machine freeze
regardless of what I set in the HPT-BIOS.

Upgrading the MB BIOS, fans on the chipset and a 435 watts   :)
power supply are reported to help some cases. I had no luck.


Regards
-Winfried


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Dan Hollis wrote:

> > No improvement in condition, alas.
> HPT366 on BP6 is just broken. Corruption and lockups happen under
> microsoft-windoze as well.

I think I'll run with leaving the HDD on the ATA-33 controller. 
After all; the "100% speedup" isn't really that 
A) noticable, or 
B) worth this.

> -Dan

Thanks to all the little people that helped - Appreciated :)


Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[kernel]

On 2.2.17 I had good luck with BP6.

EX:

[root@animal /root]# uptime
  3:17am  up 51 days, 20:17,  2 users,  load average: 0.00, 0.04, 0.02

from /proc/pci:

Unknown mass storage controller: Triones Technologies, Inc. HPT366 IDE
Ultra
DMA/66 (rev 1).
      Medium devsel.  IRQ 5.  Master Capable.  Latency=120.  Min Gnt=8.Max
Lat=8
.
      I/O at 0xd400 [0xd401].
      I/O at 0xd800 [0xd801].
      I/O at 0xdc00 [0xdc01].
  Bus  0, device  19, function  1:

Can you post/e-mail any additional details about the lockups. I am very
curious about this. We have a huge mosix cluster in production with BP6
mobo's and have plans to upgrade to 2.4 as soon as an official stable
kernel is released.

kernel@netravi.net 
On Wed, 6 Dec 2000, Gerard Sharp wrote:

> Dan Hollis wrote:
> 
> > > No improvement in condition, alas.
> > HPT366 on BP6 is just broken. Corruption and lockups happen under
> > microsoft-windoze as well.
> 
> I think I'll run with leaving the HDD on the ATA-33 controller. 
> After all; the "100% speedup" isn't really that 
> A) noticable, or 
> B) worth this.
> 
> > -Dan
> 
> Thanks to all the little people that helped - Appreciated :)
> 
> 
> Gerard Sharp
> Two Penguins at 1024x768
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

"kernel@netravi.net" wrote:
> On 2.2.17 I had good luck with BP6.

Never tried the 2.2 series with this controller - probably should get
around to doing that this weekend. :S

> EX:
> [root@animal /root]# uptime
>   3:17am  up 51 days, 20:17,  2 users,  load average: 0.00, 0.04, 0.02

Uptime proves nothing alas; I could get 30+ days if I wanted :S

> Can you post/e-mail any additional details about the lockups. I am very
> curious about this. We have a huge mosix cluster in production with BP6
> mobo's and have plans to upgrade to 2.4 as soon as an official stable
> kernel is released.

The problem is not one of lockups. The system in question doesn't lock;
it doesn't crash; it doesn't even log anything at the time - not even
APIC errors.
Instead it quietly and silently corrupts exactly four bytes at a time;
mostly on the last four bytes of a 4096 block...

I can most easily cause the corruption by copying a large amount of
known data across the disk, and then checking for differences:
cp -aR /usr/src/linux /usr/src/l2 ; diff -dur /usr/src/linux /usr/src/l2

When it does corrupt in this manner, it is not so much of a concern - I
can detect, delete, and recopy the corrupted file(s).
What is more worrying is, what if it is quietly silently and happily
corrupting other data - when I'm NOT staring at it with a paranoid
concern; for example, compiling binaries; or altering large data
files...

As such, I cannot at this time reduce the problem to one of Software or
Hardware Error; and while it is A Major Problem in my eyes; I avoid it
currently by not using the hpt366 controller :)


Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Hello again

I have performed some tests; and reached the following conclusions
regarding this matter.
As always, UniProcessor kernels have no problems; only SMP ones.

kernel 2.2.17 + idepatches, hde (i.e., on the HPT366) at UDMA(66):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(66):
Corrupted first test.

kernel 2.4.0-test11-ac4, hda at UDMA(33):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(33) [i.e., using a 40 way cable]:
I was unable to cause any corruption despite my best efforts

Or, in table form:
Kernel  Controller  Mode    Status:
2.2.17	HPT366      UDMA66  WorksForMe<tm>
2.4.0   PIIX4       UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA66  Corruption


Further details:
The drive in question is a Seagate Barracuda 7200 rpm "ata66" 13.6gig
drive
hdparm v3.6 identifies it as

/dev/hde

 Model=ST313620A, FwRev=3.07, SerialNo=7BW0QXYA
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=0(?), BuffSize=512kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=65535/1/63, CurSects=-4128706, LBA=yes, LBAsects=26692776
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2 
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 *mode2 mode3 mode4 

The system is the infamous BP6, with the latest bios and two celeron 466
cpu's, clocked at 7 * 66 MHz (=466).

The "tests" I used were crude but effective;
cp -aR /usr/src/linux /usr/src/testing/one
diff -dur /usr/src/linux /usr/src/testing/one
looking for any differences (of which there should be zero)

This was repeated for a system which was very unloaded (i.e., just
booted);
then with various other tasks running - X, Netscape, a simple program
that mallocs 100 Mb. Since the machine has 128 Mb, this program should
force the computer to the edge of swap - which I have previously noted
to alter the rate of corruption.
Also two simultaneous cp's were run to further load the hdd system :)


As an interesting observation; Linux 2.4 is more "aggressive" about swap
than 2.2; 2.2 leaves all of the 100 Mb program resident, and uses ~18 Mb
of cache. 2.4 swaps some of it out, to offer more cache. 2.4 is also
more "usable" with the HDD thrashing than 2.2; response times are
snappier, etc. etc.
Well done.


Since there doesn't appear to be any corruption in UDMA66 mode in 2.2, I
don't feel the hardware to be totally broken; instead I feel the 2.4
driver is not-quite-right. I will remain at UDMA33 on the HPT controller
in 2.4 for the time being; although I am amiable to testing UDMA66 some
more :)


Goodnight And Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Andre Hedrick]

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


This has the missing ide-pci code from 2.2.
It stablized my BP6 on the HPT core.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

[-- Attachment #2: Type: text/plain, Size: 19701 bytes --]

diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/cs5530.c linux-2.4.0-t12-7/drivers/ide/cs5530.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/cs5530.c	Tue Jun 20 07:52:36 2000
+++ linux-2.4.0-t12-7/drivers/ide/cs5530.c	Fri Dec  8 00:14:55 2000
@@ -257,6 +257,14 @@
 	unsigned short pcicmd = 0;
 	unsigned long flags;
 
+#if defined(DISPLAY_CS5530_TIMINGS) && defined(CONFIG_PROC_FS)
+	if (!cs5530_proc) {
+		cs5530_proc = 1;
+		bmide_dev = dev;
+		cs5530_display_info = &cs5530_get_info;
+	}
+#endif /* DISPLAY_CS5530_TIMINGS && CONFIG_PROC_FS */
+
 	pci_for_each_dev (dev) {
 		if (dev->vendor == PCI_VENDOR_ID_CYRIX) {
 			switch (dev->device) {
@@ -326,14 +334,6 @@
 	pci_write_config_byte(master_0, 0x43, 0xc1);
 
 	restore_flags(flags);
-
-#if defined(DISPLAY_CS5530_TIMINGS) && defined(CONFIG_PROC_FS)
-	if (!cs5530_proc) {
-		cs5530_proc = 1;
-		bmide_dev = dev;
-		cs5530_display_info = &cs5530_get_info;
-	}
-#endif /* DISPLAY_CS5530_TIMINGS && CONFIG_PROC_FS */
 
 	return 0;
 }
diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/hpt366.c linux-2.4.0-t12-7/drivers/ide/hpt366.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/hpt366.c	Tue Nov  7 11:02:24 2000
+++ linux-2.4.0-t12-7/drivers/ide/hpt366.c	Fri Dec  8 00:14:55 2000
@@ -346,6 +346,9 @@
 
 static int hpt3xx_tune_chipset (ide_drive_t *drive, byte speed)
 {
+	if ((drive->media != ide_disk) && (speed < XFER_SW_DMA_0))
+		return -1;
+
 	if (!drive->init_speed)
 		drive->init_speed = speed;
 
@@ -428,6 +431,9 @@
 	byte ultra66		= eighty_ninty_three(drive);
 	int  rval;
 
+	if ((drive->media != ide_disk) && (speed < XFER_SW_DMA_0))
+		return ((int) ide_dma_off_quietly);
+
 	if ((id->dma_ultra & 0x0020) &&
 	    (!check_in_drive_lists(drive, bad_ata100_5)) &&
 	    (HPT370_ALLOW_ATA100_5) &&
@@ -617,8 +623,14 @@
 		pci_write_config_byte(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
 
 	pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &test);
+
+#if 0
 	if (test != 0x08)
 		pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, 0x08);
+#else
+	if (test != (L1_CACHE_BYTES / 4))
+		pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
+#endif
 
 	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &test);
 	if (test != 0x78)
diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/ide-dma.c linux-2.4.0-t12-7/drivers/ide/ide-dma.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/ide-dma.c	Thu Jul 27 16:40:57 2000
+++ linux-2.4.0-t12-7/drivers/ide/ide-dma.c	Fri Dec  8 00:50:04 2000
@@ -90,6 +90,8 @@
 #include <asm/io.h>
 #include <asm/irq.h>
 
+#undef CONFIG_BLK_DEV_IDEDMA_TIMEOUT
+
 extern char *ide_dmafunc_verbose(ide_dma_action_t dmafunc);
 
 #ifdef CONFIG_IDEDMA_NEW_DRIVE_LISTINGS
@@ -515,9 +517,17 @@
 			return check_drive_lists(drive, (func == ide_dma_good_drive));
 		case ide_dma_verbose:
 			return report_drive_dmaing(drive);
+		case ide_dma_timeout:
+#ifdef CONFIG_BLK_DEV_IDEDMA_TIMEOUT
+			/*
+			 * Have to issue an abort and requeue the request
+			 * DMA engine got turned off by a goofy ASIC, and
+			 * we have to clean up the mess, and here is as good
+			 * as any.  Do it globally for all chipsets.
+			 */
+#endif /* CONFIG_BLK_DEV_IDEDMA_TIMEOUT */
 		case ide_dma_retune:
 		case ide_dma_lostirq:
-		case ide_dma_timeout:
 			printk("ide_dmaproc: chipset supported %s func only: %d\n", ide_dmafunc_verbose(func),  func);
 			return 1;
 		default:
diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/ide-pci.c linux-2.4.0-t12-7/drivers/ide/ide-pci.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/ide-pci.c	Tue Nov  7 11:02:24 2000
+++ linux-2.4.0-t12-7/drivers/ide/ide-pci.c	Fri Dec  8 00:14:55 2000
@@ -753,6 +753,12 @@
 			if (hpt363_shared_pin && hpt363_shared_irq) {
 				d->bootable = ON_BOARD;
 				printk("%s: onboard version of chipset, pin1=%d pin2=%d\n", d->name, pin1, pin2);
+#if 1
+				/* I forgot why I did this once, but it fixed something. */
+				pci_write_config_byte(dev2, PCI_INTERRUPT_PIN, dev->irq);
+				printk("PCI: %s: Fixing interrupt %d pin %d to ZERO \n", d->name, dev2->irq, pin2);
+				pci_write_config_byte(dev2, PCI_INTERRUPT_LINE, 0);
+#endif
 			}
 			break;
 		}
diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/osb4.c linux-2.4.0-t12-7/drivers/ide/osb4.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/osb4.c	Thu Oct 26 14:11:39 2000
+++ linux-2.4.0-t12-7/drivers/ide/osb4.c	Fri Dec  8 00:14:56 2000
@@ -60,14 +60,13 @@
 #include <linux/stat.h>
 #include <linux/proc_fs.h>
 
-static byte osb4_revision = 0;
 static struct pci_dev *bmide_dev;
 
-static int osb4_get_info(char *, char **, off_t, int, int);
-extern int (*osb4_display_info)(char *, char **, off_t, int, int); /* ide-proc.c */
+static int osb4_get_info(char *, char **, off_t, int);
+extern int (*osb4_display_info)(char *, char **, off_t, int); /* ide-proc.c */
 extern char *ide_media_verbose(ide_drive_t *);
 
-static int osb4_get_info (char *buffer, char **addr, off_t offset, int count, int dummy)
+static int osb4_get_info (char *buffer, char **addr, off_t offset, int count)
 {
 	char *p = buffer;
 	u32 bibma = pci_resource_start(bmide_dev, 4);
@@ -113,116 +112,202 @@
 }
 #endif  /* defined(DISPLAY_OSB4_TIMINGS) && defined(CONFIG_PROC_FS) */
 
+static byte osb4_revision = 0;
+
 byte osb4_proc = 0;
 
 extern char *ide_xfer_verbose (byte xfer_rate);
 
-static void osb4_tune_drive (ide_drive_t *drive, byte pio)
-{
-        /* command/recover widths */
-	byte timings[]	= { 0x5d, 0x47, 0x34, 0x22, 0x20 };
-	int port		= HWIF(drive)->index ? 0x42 : 0x40;
-
-	pio = ide_get_best_pio_mode(drive, pio, 4, NULL);
-	if (&HWIF(drive)->drives[0] == drive)  /* master drive */
-		port++;
-	pci_write_config_byte(HWIF(drive)->pci_dev, port, timings[pio]);
-}
+static struct pci_dev *isa_dev;
 
-#if defined(CONFIG_BLK_DEV_IDEDMA) && defined(CONFIG_BLK_DEV_OSB4)
 static int osb4_tune_chipset (ide_drive_t *drive, byte speed)
 {
+	byte udma_modes[]	= { 0x00, 0x01, 0x02 };
+	byte dma_modes[]	= { 0x77, 0x21, 0x20 };
+	byte pio_modes[]	= { 0x5d, 0x47, 0x34, 0x22, 0x20 };
+
 	ide_hwif_t *hwif	= HWIF(drive);
 	struct pci_dev *dev	= hwif->pci_dev;
-	byte is_slave           = (&HWIF(drive)->drives[1] == drive) ? 1 : 0;
-	byte bit8, enable;
-	int err;
-	
-	/* clear udma register if we don't want udma */
-	if (speed < XFER_UDMA_0) {
-		enable = 0x1 << (is_slave + (hwif->channel ? 2 : 0));
-		pci_read_config_byte(dev, 0x54, &bit8);
-		pci_write_config_byte(dev, 0x54, bit8 & ~enable);
-	}
-
+	byte unit		= (drive->select.b.unit & 0x01);
 #ifdef CONFIG_BLK_DEV_IDEDMA
-	if (speed >= XFER_MW_DMA_0) {
-		byte channel = hwif->channel ? 0x46 : 0x44;
-		if (!is_slave)
-			channel++;
+	unsigned long dma_base	= hwif->dma_base;
+#endif /* CONFIG_BLK_DEV_IDEDMA */
+	int err;
 
-		switch (speed) {
-		case XFER_MW_DMA_0:
-			bit8 = 0x77;
-			break;
-		case XFER_MW_DMA_1:
-			bit8 = 0x21;
-			break;
-		case XFER_MW_DMA_2:
+	byte drive_pci		= 0x00;
+	byte drive_pci2		= 0x00;
+	byte drive_pci3		= hwif->channel ? 0x57 : 0x56;
+
+	byte ultra_enable	= 0x00;
+	byte ultra_timing	= 0x00;
+	byte dma_timing		= 0x00;
+	byte pio_timing		= 0x00;
+
+	byte pio	= ide_get_best_pio_mode(drive, 255, 5, NULL);
+
+        switch (drive->dn) {
+		case 0: drive_pci = 0x41; drive_pci2 = 0x45; break;
+		case 1: drive_pci = 0x40; drive_pci2 = 0x44; break;
+		case 2: drive_pci = 0x43; drive_pci2 = 0x47; break;
+		case 3: drive_pci = 0x42; drive_pci2 = 0x46; break;
 		default:
-			bit8 = 0x20;
-			break;
-		}
-		pci_write_config_byte(dev, channel, bit8);
+			return -1;
 	}
 
-	if (speed >= XFER_UDMA_0) {
-		byte channel = hwif->channel ? 0x57 : 0x56;
-		int slave = is_slave ? 4 : 0;
+	pci_read_config_byte(dev, drive_pci, &pio_timing);
+	pci_read_config_byte(dev, drive_pci2, &dma_timing);
+	pci_read_config_byte(dev, drive_pci3, &ultra_timing);
+	pci_read_config_byte(dev, 0x54, &ultra_enable);
+
+#ifdef DEBUG
+	printk("%s: UDMA 0x%02x DMAPIO 0x%02x PIO 0x%02x ",
+		drive->name, ultra_timing, dma_timing, pio_timing);
+#endif
 
-		pci_read_config_byte(dev, channel, &bit8);
-		bit8 &= ~(0xf << slave);
-		switch (speed) {
-		case XFER_UDMA_0:
+	pio_timing	&= ~0xFF;
+	dma_timing	&= ~0xFF;
+	ultra_timing	&= ~(0x0F << (4*unit));
+	ultra_enable	&= ~(0x01 << drive->dn);
+
+	switch(speed) {
+		case XFER_PIO_4:
+		case XFER_PIO_3:
+		case XFER_PIO_2:
+		case XFER_PIO_1:
+		case XFER_PIO_0:
+			pio_timing |= pio_modes[speed - XFER_PIO_0];
 			break;
-		case XFER_UDMA_1:
-			bit8 |= 0x1 << slave;
+#ifdef CONFIG_BLK_DEV_IDEDMA
+		case XFER_MW_DMA_2:
+		case XFER_MW_DMA_1:
+		case XFER_MW_DMA_0:
+			pio_timing |= pio_modes[pio];
+			dma_timing |= dma_modes[speed - XFER_MW_DMA_0];
 			break;
+
+//		case XFER_UDMA_5:
+//		case XFER_UDMA_4:
+//		case XFER_UDMA_3:
 		case XFER_UDMA_2:
+		case XFER_UDMA_1:
+		case XFER_UDMA_0:
+			pio_timing |= pio_modes[pio];
+			dma_timing |= dma_modes[2];
+			ultra_timing |= ((udma_modes[speed - XFER_UDMA_0]) << (4*unit));
+			ultra_enable |= (0x01 << drive->dn);
+#endif
 		default:
-			bit8 |= 0x2 << slave;
 			break;
-		}
-		pci_write_config_byte(dev, channel, bit8);
-
-		enable = 0x1 << (is_slave + (hwif->channel ? 2 : 0));
-		pci_read_config_byte(dev, 0x54, &bit8);
-		pci_write_config_byte(dev, 0x54, bit8 | enable);
 	}
+
+#ifdef DEBUG
+	printk("%s: UDMA 0x%02x DMAPIO 0x%02x PIO 0x%02x ",
+		drive->name, ultra_timing, dma_timing, pio_timing);
 #endif
 
 #if OSB4_DEBUG_DRIVE_INFO
 	printk("%s: %s drive%d\n", drive->name, ide_xfer_verbose(speed), drive->dn);
 #endif /* OSB4_DEBUG_DRIVE_INFO */
+
 	if (!drive->init_speed)
 		drive->init_speed = speed;
+
+	pci_write_config_byte(dev, drive_pci, pio_timing);
+#ifdef CONFIG_BLK_DEV_IDEDMA
+	pci_write_config_byte(dev, drive_pci2, dma_timing);
+	pci_write_config_byte(dev, drive_pci3, ultra_timing);
+	pci_write_config_byte(dev, 0x54, ultra_enable);
+	
+	if (speed > XFER_PIO_4) {
+		outb(inb(dma_base+2)|(1<<(5+unit)), dma_base+2);
+	} else {
+		outb(inb(dma_base+2) & ~(1<<(5+unit)), dma_base+2);
+	}
+#endif /* CONFIG_BLK_DEV_IDEDMA */
+
 	err = ide_config_drive_speed(drive, speed);
 	drive->current_speed = speed;
 	return err;
 }
 
-static int osb4_config_drive_for_dma (ide_drive_t *drive)
+static void config_chipset_for_pio (ide_drive_t *drive)
+{
+	unsigned short eide_pio_timing[6] = {960, 480, 240, 180, 120, 90};
+	unsigned short xfer_pio = drive->id->eide_pio_modes;
+	byte			timing, speed, pio;
+
+	pio = ide_get_best_pio_mode(drive, 255, 5, NULL);
+
+	if (xfer_pio> 4)
+		xfer_pio = 0;
+
+	if (drive->id->eide_pio_iordy > 0) {
+		for (xfer_pio = 5;
+			xfer_pio>0 &&
+			drive->id->eide_pio_iordy>eide_pio_timing[xfer_pio];
+			xfer_pio--);
+	} else {
+		xfer_pio = (drive->id->eide_pio_modes & 4) ? 0x05 :
+			   (drive->id->eide_pio_modes & 2) ? 0x04 :
+			   (drive->id->eide_pio_modes & 1) ? 0x03 :
+			   (drive->id->tPIO & 2) ? 0x02 :
+			   (drive->id->tPIO & 1) ? 0x01 : xfer_pio;
+	}
+
+	timing = (xfer_pio >= pio) ? xfer_pio : pio;
+
+	switch(timing) {
+		case 4: speed = XFER_PIO_4;break;
+		case 3: speed = XFER_PIO_3;break;
+		case 2: speed = XFER_PIO_2;break;
+		case 1: speed = XFER_PIO_1;break;
+		default:
+			speed = (!drive->id->tPIO) ? XFER_PIO_0 : XFER_PIO_SLOW;
+			break;
+	}
+	(void) osb4_tune_chipset(drive, speed);
+	drive->current_speed = speed;
+}
+
+static void osb4_tune_drive (ide_drive_t *drive, byte pio)
+{
+	byte speed;
+	switch(pio) {
+		case 4:		speed = XFER_PIO_4;break;
+		case 3:		speed = XFER_PIO_3;break;
+		case 2:		speed = XFER_PIO_2;break;
+		case 1:		speed = XFER_PIO_1;break;
+		default:	speed = XFER_PIO_0;break;
+	}
+	(void) osb4_tune_chipset(drive, speed);
+}
+
+#ifdef CONFIG_BLK_DEV_IDEDMA
+static int config_chipset_for_dma (ide_drive_t *drive)
 {
 	struct hd_driveid *id	= drive->id;
 	byte			speed;
 
+#if 0
 	byte udma_66		= eighty_ninty_three(drive);
 	/* need specs to figure out if osb4 is capable of ata/66/100 */
 	int ultra100		= 0;
 	int ultra66		= 0;
-	int ultra		= 1;
 
 	if ((id->dma_ultra & 0x0020) && (udma_66) && (ultra100)) {
 		speed = XFER_UDMA_5;
-	} else if ((id->dma_ultra & 0x0010) && (ultra)) {
+	} else if (id->dma_ultra & 0x0010) {
 		speed = ((udma_66) && (ultra66)) ? XFER_UDMA_4 : XFER_UDMA_2;
-	} else if ((id->dma_ultra & 0x0008) && (ultra)) {
+	} else if (id->dma_ultra & 0x0008) {
 		speed = ((udma_66) && (ultra66)) ? XFER_UDMA_3 : XFER_UDMA_1;
-	} else if ((id->dma_ultra & 0x0004) && (ultra)) {
+	} else if (id->dma_ultra & 0x0004) {
+#else
+	if (id->dma_ultra & 0x0004) {
+#endif
 		speed = XFER_UDMA_2;
-	} else if ((id->dma_ultra & 0x0002) && (ultra)) {
+	} else if (id->dma_ultra & 0x0002) {
 		speed = XFER_UDMA_1;
-	} else if ((id->dma_ultra & 0x0001) && (ultra)) {
+	} else if (id->dma_ultra & 0x0001) {
 		speed = XFER_UDMA_0;
 	} else if (id->dma_mword & 0x0004) {
 		speed = XFER_MW_DMA_2;
@@ -243,45 +328,87 @@
 						     ide_dma_off_quietly);
 }
 
+static int config_drive_xfer_rate (ide_drive_t *drive)
+{
+	struct hd_driveid *id = drive->id;
+	ide_dma_action_t dma_func = ide_dma_on;
+
+	if (id && (id->capability & 1) && HWIF(drive)->autodma) {
+		/* Consult the list of known "bad" drives */
+		if (ide_dmaproc(ide_dma_bad_drive, drive)) {
+			dma_func = ide_dma_off;
+			goto fast_ata_pio;
+		}
+		dma_func = ide_dma_off_quietly;
+		if (id->field_valid & 4) {
+			if (id->dma_ultra & 0x002F) {
+				/* Force if Capable UltraDMA */
+				dma_func = config_chipset_for_dma(drive);
+				if ((id->field_valid & 2) &&
+				    (dma_func != ide_dma_on))
+					goto try_dma_modes;
+			}
+		} else if (id->field_valid & 2) {
+try_dma_modes:
+			if ((id->dma_mword & 0x0007) ||
+			    (id->dma_1word & 0x007)) {
+				/* Force if Capable regular DMA modes */
+				dma_func = config_chipset_for_dma(drive);
+				if (dma_func != ide_dma_on)
+					goto no_dma_set;
+			}
+		} else if (ide_dmaproc(ide_dma_good_drive, drive)) {
+			if (id->eide_dma_time > 150) {
+				goto no_dma_set;
+			}
+			/* Consult the list of known "good" drives */
+			dma_func = config_chipset_for_dma(drive);
+			if (dma_func != ide_dma_on)
+				goto no_dma_set;
+		} else {
+			goto fast_ata_pio;
+		}
+	} else if ((id->capability & 8) || (id->field_valid & 2)) {
+fast_ata_pio:
+		dma_func = ide_dma_off_quietly;
+no_dma_set:
+		config_chipset_for_pio(drive);
+	}
+	return HWIF(drive)->dmaproc(dma_func, drive);
+}
+
 static int osb4_dmaproc(ide_dma_action_t func, ide_drive_t *drive)
 {
 	switch (func) {
 		case ide_dma_check:
-			 return ide_dmaproc((ide_dma_action_t) osb4_config_drive_for_dma(drive), drive);
+			return config_drive_xfer_rate(drive);
 		default :
 			break;
 	}
 	/* Other cases are done by generic IDE-DMA code. */
 	return ide_dmaproc(func, drive);
 }
-#endif /* defined(CONFIG_BLK_DEV_IDEDMA) && (CONFIG_BLK_DEV_OSB4) */
+#endif /* CONFIG_BLK_DEV_IDEDMA */
 
 unsigned int __init pci_init_osb4 (struct pci_dev *dev, const char *name)
 {
-	u16 word;
-	byte bit8;
+	unsigned int reg64;
 
 	pci_read_config_byte(dev, PCI_REVISION_ID, &osb4_revision);
 
-	/* setup command register. just make sure that bus master and
-	 * i/o ports are on. */
-	pci_read_config_word(dev, PCI_COMMAND, &word);
-	if ((word & (PCI_COMMAND_MASTER | PCI_COMMAND_IO)) !=
-	     (PCI_COMMAND_MASTER | PCI_COMMAND_IO))
-		pci_write_config_word(dev, PCI_COMMAND, word |
-				      PCI_COMMAND_MASTER | PCI_COMMAND_IO);
-	
-	/* make sure that we're in pci native mode for both the primary
-	 * and secondary channel. */
-	pci_read_config_byte(dev, PCI_CLASS_PROG, &bit8);
-	if ((bit8 & 0x5) != 0x5)
-		pci_write_config_byte(dev, PCI_CLASS_PROG, bit8 | 0x5);
-
-	/* setup up our latency. the default is 255 which is a bit large.
-	 * set it to 64 instead. */
-	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &bit8);
-	if (bit8 != 0x40)
-	    pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x40);
+	isa_dev = pci_find_device(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_OSB4, NULL);
+
+	pci_read_config_dword(isa_dev, 0x64, &reg64);
+#ifdef DEBUG
+	printk("%s: reg64 == 0x%08x\n", name, reg64);
+#endif
+	reg64 &= ~0x0000A000;
+#ifdef CONFIG_SMP
+	reg64 |= 0x00008000;
+#endif
+	pci_write_config_dword(isa_dev, 0x64, reg64);
+
+	pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x40);
 
 #if defined(DISPLAY_OSB4_TIMINGS) && defined(CONFIG_PROC_FS)
 	if (!osb4_proc) {
@@ -304,19 +431,22 @@
 		hwif->irq = hwif->channel ? 15 : 14;
 
 	hwif->tuneproc = &osb4_tune_drive;
-	hwif->drives[0].autotune = 1;
-	hwif->drives[1].autotune = 1;
-
-	if (!hwif->dma_base)
-		return;
+	hwif->speedproc = &osb4_tune_chipset;
 
 #ifndef CONFIG_BLK_DEV_IDEDMA
+	hwif->drives[0].autotune = 1;
+	hwif->drives[1].autotune = 1;
 	hwif->autodma = 0;
+	return;
 #else /* CONFIG_BLK_DEV_IDEDMA */
-#ifdef CONFIG_BLK_DEV_OSB4
-	hwif->autodma = 1;
-	hwif->dmaproc = &osb4_dmaproc;
-	hwif->speedproc = &osb4_tune_chipset;
-#endif /* CONFIG_BLK_DEV_OSB4 */
+
+	if (hwif->dma_base) {
+		hwif->autodma = 1;
+		hwif->dmaproc = &osb4_dmaproc;
+	} else {
+		hwif->autodma = 0;
+		hwif->drives[0].autotune = 1;
+		hwif->drives[1].autotune = 1;
+	}
 #endif /* !CONFIG_BLK_DEV_IDEDMA */
 }
diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/piix.c linux-2.4.0-t12-7/drivers/ide/piix.c
--- linux-2.4.0-t12-7-pristine/drivers/ide/piix.c	Fri Jul  7 15:55:24 2000
+++ linux-2.4.0-t12-7/drivers/ide/piix.c	Fri Dec  8 00:14:56 2000
@@ -399,11 +399,65 @@
 						     ide_dma_off_quietly);
 }
 
+static void config_chipset_for_pio (ide_drive_t *drive)
+{
+	piix_tune_drive(drive, ide_get_best_pio_mode(drive, 255, 5, NULL));
+}
+
+static int config_drive_xfer_rate (ide_drive_t *drive)
+{
+	struct hd_driveid *id = drive->id;
+	ide_dma_action_t dma_func = ide_dma_on;
+
+	if (id && (id->capability & 1) && HWIF(drive)->autodma) {
+		/* Consult the list of known "bad" drives */
+		if (ide_dmaproc(ide_dma_bad_drive, drive)) {
+			dma_func = ide_dma_off;
+			goto fast_ata_pio;
+		}
+		dma_func = ide_dma_off_quietly;
+		if (id->field_valid & 4) {
+			if (id->dma_ultra & 0x002F) {
+				/* Force if Capable UltraDMA */
+				dma_func = piix_config_drive_for_dma(drive);
+				if ((id->field_valid & 2) &&
+				    (dma_func != ide_dma_on))
+					goto try_dma_modes;
+			}
+		} else if (id->field_valid & 2) {
+try_dma_modes:
+			if ((id->dma_mword & 0x0007) ||
+			    (id->dma_1word & 0x007)) {
+				/* Force if Capable regular DMA modes */
+				dma_func = piix_config_drive_for_dma(drive);
+				if (dma_func != ide_dma_on)
+					goto no_dma_set;
+			}
+		} else if (ide_dmaproc(ide_dma_good_drive, drive)) {
+			if (id->eide_dma_time > 150) {
+				goto no_dma_set;
+			}
+			/* Consult the list of known "good" drives */
+			dma_func = piix_config_drive_for_dma(drive);
+			if (dma_func != ide_dma_on)
+				goto no_dma_set;
+		} else {
+			goto fast_ata_pio;
+		}
+	} else if ((id->capability & 8) || (id->field_valid & 2)) {
+fast_ata_pio:
+		dma_func = ide_dma_off_quietly;
+no_dma_set:
+		config_chipset_for_pio(drive);
+	}
+	return HWIF(drive)->dmaproc(dma_func, drive);
+}
+
 static int piix_dmaproc(ide_dma_action_t func, ide_drive_t *drive)
 {
 	switch (func) {
 		case ide_dma_check:
-			 return ide_dmaproc((ide_dma_action_t) piix_config_drive_for_dma(drive), drive);
+			return config_drive_xfer_rate(drive);
 		default :
 			break;
 	}

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Andre Hedrick wrote:
> This has the missing ide-pci code from 2.2.
> It stablized my BP6 on the HPT core.

The patch had a large amount of ^M's (about 1 per line), but applied
cleanly after being passed through "sed" :)

Unfortunately, it has NOT fixed the problem :(
> 
> Cheers,
> 
> Andre Hedrick
> CTO Timpanogas Research Group
> EVP Linux Development, TRG
> Linux ATA Development
> 
>   ------------------------------------------------------------------------
>                                    Name: ide.2.4.0-t12-7.1207.patch.1
>    ide.2.4.0-t12-7.1207.patch.1    Type: Plain Text (text/plain)
>                                Encoding: base64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Andre Hedrick wrote:

> This has the missing ide-pci code from 2.2.
> It stablized my BP6 on the HPT core.

The patch contained a large number of ^M's (about 1 per line), but
applied cleanly after being passed through "sed"

It, however, has NOT corrected the problem :( :(
Corruption still occurs, now under 2.4.0-test12-pre7

> Cheers,
> Andre Hedrick


Good Day and Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Hakan Lennestal]

In message <3A32F7F5.28557718@ihug.co.nz>, Gerard Sharp writes:
> Andre Hedrick wrote:
> > This has the missing ide-pci code from 2.2.
> > It stablized my BP6 on the HPT core.
> 
> The patch had a large amount of ^M's (about 1 per line), but applied
> cleanly after being passed through "sed" :)
> 
> Unfortunately, it has NOT fixed the problem :(

Hi !

For what it's worth, I did try out this patch for my problem also
without any noticable difference.

The problem being that the kernel hangs after a dma timeout in the
partition detection phase during bootup for speeds higher than udma 44.
This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
motherboard.

/Håkan


---------------------------------------
e-mail: Hakan.Lennestal@lu.erisoft.se |
     or Hakan.Lennestal@cdt.luth.se   |
---------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[David Woodhouse]

On Sun, 10 Dec 2000, Hakan Lennestal wrote:

> The problem being that the kernel hangs after a dma timeout in the
> partition detection phase during bootup for speeds higher than udma 44.
> This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
> motherboard.

Until we manage to get a response from HPT on what they changed in the
1.26 version of their BIOS to accomodate these drives, we shouldn't
attempt to run them at that speed on the HPT366.

Linus, please apply.

--- linux-test/drivers/ide/hpt366.c	Tue Dec  5 13:30:40 2000
+++ linux-2.4/drivers/ide/hpt366.c	Tue Nov 21 13:42:40 2000
@@ -55,6 +55,9 @@
 };

 const char *bad_ata66_4[] = {
+	"IBM-DTLA-307075",
+	"IBM-DTLA-307045",
+	"IBM-DTLA-307030",
 	"WDC AC310200R",
 	NULL
 };


-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Andre Hedrick]

On Sun, 10 Dec 2000, Hakan Lennestal wrote:

> The problem being that the kernel hangs after a dma timeout in the
> partition detection phase during bootup for speeds higher than udma 44.
> This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
> motherboard.

Well try the latest out there...test12-pre7.

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Hakan Lennestal]

In message <Pine.LNX.4.10.10012100916360.8764-100000@master.linux-ide.org>, And
re Hedrick writes:
> On Sun, 10 Dec 2000, Hakan Lennestal wrote:
> 
> > The problem being that the kernel hangs after a dma timeout in the
> > partition detection phase during bootup for speeds higher than udma 44.
> > This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
> > motherboard.
> 
> Well try the latest out there...test12-pre7.

Hi !

This is with test12-pre7 and HPT-bios 1.27.

Regards.

/Håkan


---------------------------------------
e-mail: Hakan.Lennestal@lu.erisoft.se |
     or Hakan.Lennestal@cdt.luth.se   |
---------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Hakan Lennestal wrote:

> > Well try the latest out there...test12-pre7.
> This is with test12-pre7 and HPT-bios 1.27.

My system is test12-pre7 also; but the bios is only 1.22 - but I am
using the 'RU' bp6 bios, which I thought to be the latest. Any pointers
on how to get a newer HPT-bios?

> Regards.
> /Håkan


Good Day and Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Andre Hedrick]

On Sun, 10 Dec 2000, Hakan Lennestal wrote:

> In message <Pine.LNX.4.10.10012100916360.8764-100000@master.linux-ide.org>, And
> re Hedrick writes:
> > On Sun, 10 Dec 2000, Hakan Lennestal wrote:
> > 
> > > The problem being that the kernel hangs after a dma timeout in the
> > > partition detection phase during bootup for speeds higher than udma 44.
> > > This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
> > > motherboard.
> > 
> > Well try the latest out there...test12-pre7.
> 
> Hi !
> 
> This is with test12-pre7 and HPT-bios 1.27.

test12-pre8 and 2.2.18 is out and I do not chase BIOS revs in general.
I work off the originals HPT366 1.07 this is because the lowest comman
variable must be addressed and hope that the new stuff will not fail the
backwards compatablity issue.

Cheers,


Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/