Messages in this thread |  | | Date | Sun, 27 Aug 2000 14:07:42 -0300 | Subject | Re: [patch] vt82cxxx.c v1.9 - Re: UDMA trouble in VT82C586 IDE | From | Cesar Eduardo Barros <> |
| |
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.
dmesg: [...] 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 [...]
/proc/ide/via: ----------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 -------------------drive0----drive1----drive2----drive3----- BMDMA enabled: yes no no no Transfer Mode: UDMA DMA/PIO DMA/PIO DMA/PIO 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 cesarb@nitnet.com.br cesarb@dcc.ufrj.br - 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/
|  |