[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] vt82cxxx.c v1.9 - Re: UDMA trouble in VT82C586 IDE
On Sun, Aug 27, 2000 at 10:59:20AM +0200, Vojtech Pavlik wrote:
> > Now if your board is one of these boards, then I would expect it to not
> > work.
> >
> > On Sat, 26 Aug 2000, Cesar Eduardo Barros wrote:
> >
> > >
> > > It works great now. I got a month-old full rewrite of via82cxxx.c from
> > > Vojtech Pavlik in the lkml archives and compiled it.
> > >
> > > Linus: I think it should be included. The old driver is messy, hairy, and fails
> > > to work here. The new one is clean, neat, and works fine. If you lost the
> >
> > Just because you have a newer wierder combination does not mean the old
> > and lousy is junk.

A FIC SD11 is not what I would call "wierder", btw. (and for the record, the
rewrite I got was the 1.1 version)

> Here goes a patch for 2.4.0-test7. [ 883 lines removed, 387 added ]
> Andre: Please approve it, you're the IDE maintainer.
> Linus: Please apply it if Andre approves it.

Well, since I was the one who started this thread, I *had* to test it.

Applied it on 2.4.0-test7 with Riel's 2.4.0-t7p4vmpatch2.

ide_setup: ide0=ata66
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
hda: ST320423A, ATA DISK drive
hdc: CR-2802TE, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=2490/255/63, UDMA(66)
Partition check:
hda: hda1

----------VIA BusMastering IDE Configuration----------------
South Bridge: VIA vt82c686a rev 0x1b
Command register: 0x7
Latency timer: 32
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
BMDMA enabled: yes no no no
Cycle (T): 15ns 30ns 30ns 30ns
Address Setup: --- 4T 4T 4T
Active Pulse: --- 11T 4T 11T
Recovery Time: --- 9T 2T 9T
Cycle Time: 2T 24T 10T 24T
Transfer Rate: 66.0MB/s 2.7MB/s 6.6MB/s 2.7MB/s

Works fine. The only problem I get (I had the same problem with the previous
patch) is that when there is intense disk activity (unpacking a kernel, fsck,
updatedb, and other disk abusive tasks) I get a burst of CRC errors:

Aug 27 13:39:31 flower kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Aug 27 13:39:31 flower kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Aug 27 13:40:08 flower kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Aug 27 13:40:08 flower kernel: hda: dma_intr: error=0x84 { DriveStatusError BadC
RC }
Aug 27 13:40:34 flower kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Aug 27 13:40:34 flower kernel: hda: dma_intr: error=0x84 { DriveStatusError BadC
RC }

They seem to be harmless (unless I get lots of them, which somehow seem to
disable UDMA). I think they're because of the weird places where the ATA66
cable is (over a Voodoo 3, near the PS, and then in the middle of the messy
drive cabling), but I don't understand why it only happens when there are lots
of nonstop disk activity.

Cesar Eduardo Barros
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.043 / U:1.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site