Hi,
last friday I found strange problem with 2.5.8-pre1 kernel
corrupting my data. Today I tracked it down to enabled (by
default) 32bit I/O. Problem occurs only in 2.5.x kernels
(2.5.8-pre1, 2.5.8-pre3) and does not occur in 2.4.x
(2.4.19-pre6, 2.4.18-pre4). My tests were done in
non-multicount mode:
/dev/hdc:
multcount = 0 (off)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
geometry = 4865/255/63, sectors = 78165360, start = 0
busstate = 1 (on)
/dev/hdc:
Model=WDC WD400BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6R1306991
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5
Problem is that if I write 4KB file SOURCE below with
dd of=/dev/hdc1 bs=512 count=8 to disk, it dies with
hdc: lost interrupt, and after reboot data shown in DEST below
are read from disk.
After looking through code up and down I found that first
sector is written in 32bit mode, while others in 16bit mode,
and VIA IDE interface does not cope with this correctly. Can
anybody explain me, what's wrong with patch at the end of this
message? As there is dozen of places where io_32bit is cleared,
I believe that there must be some reason for doing that... And
do not ask me why it worked in 2.4.x, as it cleared io_32bit
in task_out_intr too.
Thanks,
Petr Vandrovec
[email protected]
SOURCE:
000000 eb 3c 90 4d 53 57 49 4e 34 2e 31 00 02 08 01 00
[random stuff]
0001f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd 55 aa
000200 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
000210 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
[repeats 0..7F four times]
0003f0 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
000400 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
[...]
000470 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
001000
DEST:
000000 eb 3c 90 4d 53 57 49 4e 34 2e 31 00 02 08 01 00
[random stuff written correctly]
0001f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd 55 aa
000200 00 01 f6 f7 02 03 fa fb 04 05 55 aa 06 07 f2 f3
000210 08 09 f6 f7 0a 0b fa fb 0c 0d 55 aa 0e 0f f2 f3
000220 10 11 f6 f7 12 13 fa fb 14 15 55 aa 16 17 f2 f3
000230 18 19 f6 f7 1a 1b fa fb 1c 1d 55 aa 1e 1f f2 f3
[still same, lanes 2,3,6,7,a,b,e,f contains old data
from previous sector]
0003e0 70 71 f6 f7 72 73 fa fb 74 75 55 aa 76 77 f2 f3
0003f0 78 79 f6 f7 7a 7b fa fb 7c 7d 55 aa 7e 7f f2 f3
000400 00 01 1c 1d 55 aa 1e 1f f2 f3 20 21 f6 f7 22 23
000410 fa fb 24 25 55 aa 26 27 f2 f3 28 29 f6 f7 2a 2b
000420 fa fb 2c 2d 55 aa 2e 2f f2 f3 30 31 f6 f7 32 33
[now lanes 0,1,4,5,8,9,c,d contains old data...]
000590 fa fb 64 65 55 aa 66 67 f2 f3 68 69 f6 f7 6a 6b
0005a0 fa fb 6c 6d 55 aa 6e 6f f2 f3 70 71 f6 f7 72 73
0005b0 fa fb 74 75 55 aa 76 77 f2 f3 78 79 f6 f7 7a 7b
0005c0 fa fb 7c 7d 55 aa 7e 7f f2 f3 80 81 f6 f7 82 83
[here at 0x5CC finally begins data which should have
been at 0x400... still interleaved with garbage]
0005d0 fa fb 84 85 55 aa 86 87 f2 f3 88 89 f6 f7 8a 8b
0005e0 fa fb 8c 8d 55 aa 8e 8f f2 f3 90 91 f6 f7 92 93
0005f0 fa fb 94 95 55 aa 96 97 f2 f3 98 99 f6 f7 9a 9b
000600 55 aa b6 b7 f2 f3 b8 b9 f6 f7 ba bb fa fb bc bd
000610 55 aa be bf f2 f3 c0 c1 f6 f7 c2 c3 fa fb c4 c5
000620 55 aa c6 c7 f2 f3 c8 c9 f6 f7 ca cb fa fb cc cd
000630 55 aa ce cf f2 f3 d0 d1 f6 f7 d2 d3 fa fb d4 d5
000640 55 aa d6 d7 f2 f3 d8 d9 f6 f7 da db fa fb dc dd
000650 55 aa de df f2 f3 e0 e1 f6 f7 e2 e3 fa fb e4 e5
000660 55 aa e6 e7 f2 f3 e8 e9 f6 f7 ea eb fa fb ec ed
000670 55 aa ee ef f2 f3 f0 f1 f6 f7 f2 f3 fa fb f4 f5
000680 55 aa f6 f7 f2 f3 f8 f9 f6 f7 fa fb fa fb fc fd
000690 55 aa fe ff f2 f3 00 00 f6 f7 00 00 fa fb 00 00
0006a0 55 aa 00 00 f2 f3 00 00 f6 f7 00 00 fa fb 00 00
*
001000
/proc/ide/via:
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.34
South Bridge: VIA vt82c686a
Revision: ISA 0x22 IDE 0x10
Highest DMA rate: UDMA66
BM-DMA base: 0xd800
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: no yes
Post Write Buffer: no yes
Enabled: yes yes
Simplex only: no no
Cable Type: 40w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: PIO PIO PIO PIO
Address Setup: 30ns 120ns 30ns 120ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 330ns
Data Recovery: 30ns 270ns 30ns 270ns
Cycle Time: 120ns 600ns 120ns 600ns
Transfer Rate: 16.6MB/s 3.3MB/s 16.6MB/s 3.3MB/s
diff -urN linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c linux-2.5.8-pre3/drivers/ide/ide-taskfile.c
--- linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c Sun Apr 7 03:43:03 2002
+++ linux-2.5.8-pre3/drivers/ide/ide-taskfile.c Fri Apr 12 01:50:04 2002
@@ -602,7 +602,7 @@
rq = HWGROUP(drive)->rq;
pBuf = ide_map_rq(rq, &flags);
DTF("write: %p, rq->current_nr_sectors: %d\n", pBuf, (int) rq->current_nr_sectors);
- drive->io_32bit = 0;
+// drive->io_32bit = 0;
taskfile_output_data(drive, pBuf, SECTOR_WORDS);
ide_unmap_rq(rq, pBuf, &flags);
drive->io_32bit = io_32bit;
For me 2.5.8-pre2 and -pre3 (-pre1 not tested) both fail to boot on my VIA
chipset box. 2.5.7 works fine.
Best regards,
Anton
2.5.8-pre3 prints on serial console and then it just dies:
----snip----
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
VIA Technologies, Inc. Bus Master IDE: IDE controller on PCI slot 00:07.1
VIA Technologies, Inc. Bus Master IDE: chipset revision 6
VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe
irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L040AVER07-0, ATA DISK drive
----snip----
2.5.7 works fine and this is the relevant part from the boot sequence output:
----snip----
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
VIA Technologies, Inc. Bus Master IDE: IDE controller on PCI slot 00:07.1
VIA Technologies, Inc. Bus Master IDE: chipset revision 6
VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe
irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L040AVER07-0, ATA DISK drive
hdc: LITE-ON LTR-12102B, ATAPI CD/DVD-ROM drive
hdd: Maxtor 90288D2, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c04984cc, I/O limit 4095Mb (mask 0xffffffff)
hda: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=79780/16/63, UDMA(100)
blk: queue c0498d20, I/O limit 4095Mb (mask 0xffffffff)
hdd: 5627664 sectors (2881 MB) w/256KiB Cache, CHS=5583/16/63, UDMA(33)
Partition check:
hda: [PTBL] [5005/255/63] hda1 hda2 < hda5 hda6 hda7 >
hdd: [PTBL] [697/128/63] hdd1 hdd2 < hdd5 hdd6 hdd7 hdd8 hdd9 hdd10 >
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: LITE-ON Model: LTR-12102B Rev: NS1D
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
----snip----
/proc/ide/via shows on 2.5.7:
----snip----
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.34
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
Highest DMA rate: UDMA100
BM-DMA base: 0xd000
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes no
Post Write Buffer: yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: UDMA PIO DMA UDMA
Address Setup: 30ns 120ns 30ns 30ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 90ns
Data Recovery: 30ns 270ns 30ns 30ns
Cycle Time: 20ns 600ns 120ns 60ns
Transfer Rate: 99.9MB/s 3.3MB/s 16.6MB/s 33.3MB/s
---snip---
and lspci -xvv output on 2.5.7:
---snip---
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
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: 8
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Capabilities: <available only to root>
00: 06 11 05 03 06 00 10 22 03 00 00 06 00 08 00 00
10: 08 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (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
Memory behind bridge: d2000000-d4ffffff
Prefetchable memory behind bridge: d0000000-d1ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00
20: 00 d2 f0 d4 00 d0 f0 d1 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40)
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
Capabilities: <available only to root>
00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. VT82C586 IDE [Apollo]
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 d000 [size=16]
Capabilities: <available only to root>
00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 06 11 71 05
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
(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 5
Region 4: I/O ports at d400 [size=32]
Capabilities: <available only to root>
00: 06 11 38 30 07 00 10 02 16 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d4 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 05 04 00 00
00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
(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 5
Region 4: I/O ports at d800 [size=32]
Capabilities: <available only to root>
00: 06 11 38 30 07 00 10 02 16 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d8 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 05 04 00 00
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
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: <available only to root>
00: 06 11 57 30 00 00 90 02 40 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 57 30
30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
[Apollo Super AC97/Audio] (rev 50)
Subsystem: VIA Technologies, Inc.: Unknown device 4511
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 12
Region 0: I/O ports at dc00 [size=256]
Region 1: I/O ports at e000 [size=4]
Region 2: I/O ports at e400 [size=4]
Capabilities: <available only to root>
00: 06 11 58 30 01 00 10 02 50 00 01 04 00 00 00 00
10: 01 dc 00 00 01 e0 00 00 01 e4 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 11 45
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0c 03 00 00
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
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 (2500ns min, 2500ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e800 [size=128]
Region 1: Memory at d6100000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: <available only to root>
00: b7 10 00 92 07 00 10 02 78 00 00 02 08 20 00 00
10: 01 e8 00 00 00 00 10 d6 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 0a 0a
00:0b.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus
DVD Decoder (rev 02)
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 5
Region 0: Memory at d6000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: <available only to root>
00: 05 11 00 83 06 00 10 02 02 00 80 04 00 20 00 00
10: 00 00 00 d6 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev
04) (prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb
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 (4000ns min, 8000ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at d2000000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at d3000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: <available only to root>
00: 2b 10 25 05 07 00 90 02 04 00 00 03 08 20 00 00
10: 08 00 00 d0 00 00 00 d2 00 00 00 d3 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 79 21
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 10 20
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
IRC: #ntfs on irc.openprojects.net / ICQ: 8561279
WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, Apr 12, 2002 at 02:10:29AM +0200, Petr Vandrovec wrote:
> last friday I found strange problem with 2.5.8-pre1 kernel
> corrupting my data. Today I tracked it down to enabled (by
> default) 32bit I/O. Problem occurs only in 2.5.x kernels
> (2.5.8-pre1, 2.5.8-pre3) and does not occur in 2.4.x
> (2.4.19-pre6, 2.4.18-pre4). My tests were done in
> non-multicount mode:
>
> /dev/hdc:
> multcount = 0 (off)
> I/O support = 1 (32-bit)
> unmaskirq = 1 (on)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> nowerr = 0 (off)
> readonly = 0 (off)
> geometry = 4865/255/63, sectors = 78165360, start = 0
> busstate = 1 (on)
>
> After looking through code up and down I found that first
> sector is written in 32bit mode, while others in 16bit mode,
> and VIA IDE interface does not cope with this correctly. Can
> anybody explain me, what's wrong with patch at the end of this
> message? As there is dozen of places where io_32bit is cleared,
> I believe that there must be some reason for doing that... And
> do not ask me why it worked in 2.4.x, as it cleared io_32bit
> in task_out_intr too.
It's a very unwise thing to disable 32-bit mode on VIA and AMD chipsets,
AMD even has it in their errata (VIA has no documented errata, of
course). Thanks for the good find. Martin, can we do anything about
this?
> diff -urN linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c linux-2.5.8-pre3/drivers/ide/ide-taskfile.c
> --- linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c Sun Apr 7 03:43:03 2002
> +++ linux-2.5.8-pre3/drivers/ide/ide-taskfile.c Fri Apr 12 01:50:04 2002
> @@ -602,7 +602,7 @@
> rq = HWGROUP(drive)->rq;
> pBuf = ide_map_rq(rq, &flags);
> DTF("write: %p, rq->current_nr_sectors: %d\n", pBuf, (int) rq->current_nr_sectors);
> - drive->io_32bit = 0;
> +// drive->io_32bit = 0;
> taskfile_output_data(drive, pBuf, SECTOR_WORDS);
> ide_unmap_rq(rq, pBuf, &flags);
> drive->io_32bit = io_32bit;
--
Vojtech Pavlik
SuSE Labs
On Fri, Apr 12 2002, Petr Vandrovec wrote:
> I believe that there must be some reason for doing that... And
> do not ask me why it worked in 2.4.x, as it cleared io_32bit
> in task_out_intr too.
Because 2.4 doesn't use that path for fs requests. And be glad that it
doesn't otherwise _everybody_ would have much worse problems than you
are currently seeing.
--
Jens Axboe
Anton Altaparmakov wrote:
> For me 2.5.8-pre2 and -pre3 (-pre1 not tested) both fail to boot on my
> VIA chipset box. 2.5.7 works fine.
>
> Best regards,
>
> Anton
>
> 2.5.8-pre3 prints on serial console and then it just dies:
> ----snip----
> Uniform Multi-Platform E-IDE driver ver.:7.0.0
> ide: system bus speed 33MHz
> VIA Technologies, Inc. Bus Master IDE: IDE controller on PCI slot 00:07.1
> VIA Technologies, Inc. Bus Master IDE: chipset revision 6
> VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe
> irqs later
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: IC35L040AVER07-0, ATA DISK drive
> ----snip----
>
Does it crash dump thereafter? Could be that the code around
save_match doesn't get it right.
Vojtech Pavlik wrote:
> On Fri, Apr 12, 2002 at 02:10:29AM +0200, Petr Vandrovec wrote:
Cze?? koledzy :-).
>> After looking through code up and down I found that first
>>sector is written in 32bit mode, while others in 16bit mode,
>>and VIA IDE interface does not cope with this correctly. Can
>>anybody explain me, what's wrong with patch at the end of this
>>message? As there is dozen of places where io_32bit is cleared,
>>I believe that there must be some reason for doing that... And
>>do not ask me why it worked in 2.4.x, as it cleared io_32bit
>>in task_out_intr too.
>
>
> It's a very unwise thing to disable 32-bit mode on VIA and AMD chipsets,
> AMD even has it in their errata (VIA has no documented errata, of
> course). Thanks for the good find. Martin, can we do anything about
> this?
Agreed. The 16 bit transfer support is one legacy leftover from the
XT PC days which are of no relevance to Linux at all.
The disabling of 32 bit transfers was most propably intendid
to work around the fact that the SUPPORT_VLB_SYNC code was not
giving the desired results. The bugs it's supposed to work
around are only present if there are 32 bit transfers. This obscure
workaround code can't be found in any other ATA driver out there
I was looking at. And finally Jens has observed that the code in question
doesn't get used in 2.4 at all.
I tend therefore to the following measures:
1. Check whatever taskfile_output_data would indeed transfer the proper
amount of data if the below patch get's applied.
2. If yes - just kill the disabling alltogehter.
3. Make 32 bit PIO transfers the global default.
...
Now I have just looked at the places where taskfile_output_data
get's used. It's abvious that the code in question is a mistake
and the disabling of io_32bit should just be killed alltogether.
Good spotting Petr!!!!!!!!
>>diff -urN linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c linux-2.5.8-pre3/drivers/ide/ide-taskfile.c
>>--- linux-2.5.8-pre3.dist/drivers/ide/ide-taskfile.c Sun Apr 7 03:43:03 2002
>>+++ linux-2.5.8-pre3/drivers/ide/ide-taskfile.c Fri Apr 12 01:50:04 2002
>>@@ -602,7 +602,7 @@
>> rq = HWGROUP(drive)->rq;
>> pBuf = ide_map_rq(rq, &flags);
>> DTF("write: %p, rq->current_nr_sectors: %d\n", pBuf, (int) rq->current_nr_sectors);
>>- drive->io_32bit = 0;
>>+// drive->io_32bit = 0;
>> taskfile_output_data(drive, pBuf, SECTOR_WORDS);
>> ide_unmap_rq(rq, pBuf, &flags);
>> drive->io_32bit = io_32bit;
>
>
On Fri, 12 Apr 2002, Jens Axboe wrote:
> On Fri, Apr 12 2002, Petr Vandrovec wrote:
> > I believe that there must be some reason for doing that... And
> > do not ask me why it worked in 2.4.x, as it cleared io_32bit
> > in task_out_intr too.
>
> Because 2.4 doesn't use that path for fs requests. And be glad that it
> doesn't otherwise _everybody_ would have much worse problems than you
> are currently seeing.
Maybe if everyone ever bothered to look at the code base and not assume
they know everything ... and enjoying feable attempts to cast me as a
fool. Better yet maybe understand the hardware ...
ata_input_data
io_32bit = drive->io_32bit;
if (io_32bit)
insl(IDE_DATA_REG, buffer, wcount);
else
insw(IDE_DATA_REG, buffer, wcount<<1);
or
ata_output_data
io_32bit = drive->io_32bit;
if (io_32bit)
outsl(IDE_DATA_REG, buffer, wcount);
else
outsw(IDE_DATA_REG, buffer, wcount<<1);
WHOA is it not obvious it is the total number of calls to the same damn
DATA-TASKFILE-REGISTER-PORT
Which is only SIXTEEN BITS WIDE!
So please contine to write 32 bits to a 16 bit wide address...
Legacy or not the physical layer to the device, so please go look there.
Why do I even bother, all of you are so much smarter than me.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick wrote:
> On Fri, 12 Apr 2002, Jens Axboe wrote:
>
>
>>On Fri, Apr 12 2002, Petr Vandrovec wrote:
>>
>>>I believe that there must be some reason for doing that... And
>>>do not ask me why it worked in 2.4.x, as it cleared io_32bit
>>>in task_out_intr too.
>>
>>Because 2.4 doesn't use that path for fs requests. And be glad that it
>>doesn't otherwise _everybody_ would have much worse problems than you
>>are currently seeing.
>
>
> Maybe if everyone ever bothered to look at the code base and not assume
> they know everything ... and enjoying feable attempts to cast me as a
> fool. Better yet maybe understand the hardware ...
>
> ata_input_data
>
> io_32bit = drive->io_32bit;
>
> if (io_32bit)
> insl(IDE_DATA_REG, buffer, wcount);
> else
> insw(IDE_DATA_REG, buffer, wcount<<1);
>
> or
>
> ata_output_data
>
> io_32bit = drive->io_32bit;
>
> if (io_32bit)
> outsl(IDE_DATA_REG, buffer, wcount);
> else
> outsw(IDE_DATA_REG, buffer, wcount<<1);
>
>
> WHOA is it not obvious it is the total number of calls to the same damn
> DATA-TASKFILE-REGISTER-PORT
>
> Which is only SIXTEEN BITS WIDE!
>
> So please contine to write 32 bits to a 16 bit wide address...
> Legacy or not the physical layer to the device, so please go look there.
> Why do I even bother, all of you are so much smarter than me.
The physical register on the side of the device may very well be
only 16 bit's wide. Most propably it's simple implementation dependant.
I saw many 68000 derivatives on IDE controllers but those days there
are many 32 bit controllers there as well.
But please note that the ata host-chip xor the CPU (think 386sx)
is multiplexing the access to it. Otherwise it wouldn't be possible to do 32 bit
transfers over a cable with only 16 data lines at all.
Apparently you don't even understand the physical transport layer,
which explains the presence of the bug in question.
At 08:46 12/04/02, Martin Dalecki wrote:
>Anton Altaparmakov wrote:
>>For me 2.5.8-pre2 and -pre3 (-pre1 not tested) both fail to boot on my
>>VIA chipset box. 2.5.7 works fine.
>>Best regards,
>> Anton
>>2.5.8-pre3 prints on serial console and then it just dies:
>>----snip----
>>Uniform Multi-Platform E-IDE driver ver.:7.0.0
>>ide: system bus speed 33MHz
>>VIA Technologies, Inc. Bus Master IDE: IDE controller on PCI slot 00:07.1
>>VIA Technologies, Inc. Bus Master IDE: chipset revision 6
>>VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe
>>irqs later
>>VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
>> ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
>> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
>>hda: IC35L040AVER07-0, ATA DISK drive
>>----snip----
>
>Does it crash dump thereafter? Could be that the code around
>save_match doesn't get it right.
There is no other output of any kind anywhere. I am both on serial console
and on real console and both end with the hda line. If I can add something
somewhere or whatever to find out where it hangs I would be happy to...
(Remote gdb debugging is not setup yet as I have no idea how to do it...)
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
IRC: #ntfs on irc.openprojects.net / ICQ: 8561279
WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, Apr 12 2002, Andre Hedrick wrote:
> On Fri, 12 Apr 2002, Jens Axboe wrote:
>
> > On Fri, Apr 12 2002, Petr Vandrovec wrote:
> > > I believe that there must be some reason for doing that... And
> > > do not ask me why it worked in 2.4.x, as it cleared io_32bit
> > > in task_out_intr too.
> >
> > Because 2.4 doesn't use that path for fs requests. And be glad that it
> > doesn't otherwise _everybody_ would have much worse problems than you
> > are currently seeing.
>
> Maybe if everyone ever bothered to look at the code base and not assume
> they know everything ... and enjoying feable attempts to cast me as a
> fool. Better yet maybe understand the hardware ...
I didn't talk about the 32bit issue at all (as you can read from my mail
above), I simply said why it worked in 2.4 -- because that data path is
never hit for a file system request.
So maybe if you ever bothered to read the emails. Or better yet, not
assume you know everything.
--
Jens Axboe
On Fri, Apr 12, 2002 at 10:04:12AM +0200, Martin Dalecki wrote:
> 3. Make 32 bit PIO transfers the global default.
This is fine, as long as you allow some interfaces to say "I really want
to be 16-bit PIO only".
I *need* 16-bit transfers for many ARM-based IDE stuff. 32-bit is not
an option on many, if not all ARM-based PCMCIA stuff.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, Apr 13, 2002 at 11:12:29AM +0100, Russell King wrote:
> On Fri, Apr 12, 2002 at 10:04:12AM +0200, Martin Dalecki wrote:
> > 3. Make 32 bit PIO transfers the global default.
>
> This is fine, as long as you allow some interfaces to say "I really want
> to be 16-bit PIO only".
>
> I *need* 16-bit transfers for many ARM-based IDE stuff. 32-bit is not
> an option on many, if not all ARM-based PCMCIA stuff.
Basically it should work both ways - VIA and AMD interfaces *need*
32-bit in the same manner.
--
Vojtech Pavlik
SuSE Labs
Russell King wrote:
> On Fri, Apr 12, 2002 at 10:04:12AM +0200, Martin Dalecki wrote:
>
>>3. Make 32 bit PIO transfers the global default.
>
>
> This is fine, as long as you allow some interfaces to say "I really want
> to be 16-bit PIO only".
>
> I *need* 16-bit transfers for many ARM-based IDE stuff. 32-bit is not
> an option on many, if not all ARM-based PCMCIA stuff.
What I wan't to disable is just the *unconditional* fallback to 16 bit IO
at some places. This and not more. This doens't even affect the physical setup
between the host chip and the controller on disc.
The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
there of course.
So we have no issue here. OK?
Trimmed CC...
Additional issues not fully address are 8-bit transfers.
Lastly if a host can not do 16-bit transfers it is bad and broken and the
OEM needs to be railed for it. Defaulting to 32-bit with legacy hardware
still in the mix will eat somebodies data.
Much of this discussion as to expose a bogus policy of forcing hardware
to 32-bit and causing other problems that are not reported in the proper
light. When people put DOC or ATA-Flash in the onboard host it will mess
things up. Since there are people who think it is okay to set policies in
hardware and have gotten away with it, adding in the default to undo the
bogusity will point that most hardware does not need the is junk and let
it resided with the enduser.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Sat, 13 Apr 2002, Martin Dalecki wrote:
> Russell King wrote:
> > On Fri, Apr 12, 2002 at 10:04:12AM +0200, Martin Dalecki wrote:
> >
> >>3. Make 32 bit PIO transfers the global default.
> >
> >
> > This is fine, as long as you allow some interfaces to say "I really want
> > to be 16-bit PIO only".
> >
> > I *need* 16-bit transfers for many ARM-based IDE stuff. 32-bit is not
> > an option on many, if not all ARM-based PCMCIA stuff.
>
> What I wan't to disable is just the *unconditional* fallback to 16 bit IO
> at some places. This and not more. This doens't even affect the physical setup
> between the host chip and the controller on disc.
> The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
> there of course.
>
> So we have no issue here. OK?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> > The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
> > there of course.
> >
> > So we have no issue here. OK?
What if the user doesn't know the precise innards of their hardware. IDE
more than anything else has to automagically do the right thing. Given the
size of the PIO transfer loop and the way for some boards its weirdly
dependant on hardware magic and wonder is there any reason for not just
making the host controller provide the function or reference an ide library
function for "sane" hardware ?
On Sat, 13 Apr 2002, Alan Cox wrote:
> > > The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
> > > there of course.
> > >
> > > So we have no issue here. OK?
>
> What if the user doesn't know the precise innards of their hardware. IDE
> more than anything else has to automagically do the right thing. Given the
> size of the PIO transfer loop and the way for some boards its weirdly
> dependant on hardware magic and wonder is there any reason for not just
> making the host controller provide the function or reference an ide library
> function for "sane" hardware ?
You are making a nice case to not set 32-bit for PIO.
I never run 32-bit PIO in development because of the false results you end
up seeing.
For the formal record: The ATA interface data transfers are done 16-bits
(2 bytes) at a time in PIO and DMA.
PERIOD!
Andre Hedrick
LAD Storage Consulting Group
Alan Cox wrote:
>>>The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
>>>there of course.
>>>
>>>So we have no issue here. OK?
>>
>
> What if the user doesn't know the precise innards of their hardware. IDE
> more than anything else has to automagically do the right thing. Given the
> size of the PIO transfer loop and the way for some boards its weirdly
> dependant on hardware magic and wonder is there any reason for not just
> making the host controller provide the function or reference an ide library
> function for "sane" hardware ?
Alan - that's not the issue here.