Messages in this thread | | | From | (Tom Crane) | Subject | Re: [2.3.3x] ALI M15x3 chipset support (EXPERIMENTAL) | Date | 19 Jan 00 21:47:58 GMT |
| |
In article <fa.d2j3fcv.f3ks2g@ifi.uio.no>, Luca Montecchiani <m.luca@teamfab.it> writes: > Andrzej Krzysztofowicz wrote:
Thanks for all the followups.
> >> Unless your BIOS does set an apropriate PCI cinfiguration register properly. >> Mine does not. Whatever PCI clock I set (jumpers) on the MoBo I always get 33 >> MHz from /proc/ide/ali ... > > Agree, jumpers will never died ;)
I get 33MHz from /proc/ide/ali. AFAICT there are no jumpers on my MB for setting this.
>> Chih-Jen Tsai <cjtsai@ali.com.tw> suggested that UDMA problems are WD drives >> specyfic and disappear when CRC errors are ignored. I'm not sure if it is >> easy to ignore CRC errors for specyfic hardware combinations only, but if it >> is - it could be a workaround of the problem. > > Well, WDC disks are safely detected and driver fall back to dma2, for some > strange reasons that I can't remember my first hack failed to detect a WDC > and bonnie eat the filesystem, after that I've also put an extra hdparm -d0 /dev/hdc > to my rc.local ;) > >> Could you send me the patch you use for Rev.20/UDMA, please ? > > patch ? Around line 413 (2.3.40-4+minor_patch): > > - if (m5229_revision <= 0x20) { > + if (m5229_revision < 0x20) {
I tried this, briefly, under a light I/O load, after a full-backup of my root disc. It worked with the Maxtor 90680D4 HD going into UDMA at boot time. I did get lots of CRC errors, eg.
Jan 19 19:51:15 mklab kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 19 19:51:15 mklab kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
I turned on some of the other optimisations with, hdparm -c 1 -d 1 -m 16 -u 1 -a 8
and get the following messages (presumably due to the m16??)
Jan 19 19:57:42 mklab kernel: hda: multwrite: count=8, current=0 Jan 19 19:58:22 mklab last message repeated 53 times Jan 19 19:59:23 mklab last message repeated 115 times
The root FS checked-out OK after this expt.
Here are some disc timing results. With UDMA turned on the Maxtor gives, Timing buffer-cache reads: 128 MB in 2.97 seconds =43.10 MB/sec Timing buffered disk reads: 64 MB in 5.95 seconds =10.76 MB/sec
Turning it off gives, Timing buffer-cache reads: 128 MB in 3.18 seconds =40.25 MB/sec Timing buffered disk reads: 64 MB in 12.17 seconds = 5.26 MB/sec
Turning on the other enhancements (hdparm, as above) Timing buffer-cache reads: 128 MB in 3.04 seconds =42.11 MB/sec Timing buffered disk reads: 64 MB in 6.17 seconds =10.37 MB/sec
Turning off the hack and returning to MWDMA gives, Timing buffer-cache reads: 128 MB in 3.07 seconds =41.69 MB/sec Timing buffered disk reads: 64 MB in 11.76 seconds = 5.44 MB/sec
Staying with MWDMA and turning on the other optimisations gives, Timing buffer-cache reads: 128 MB in 3.12 seconds =41.03 MB/sec Timing buffered disk reads: 64 MB in 10.41 seconds = 6.15 MB/sec
If it is safe to run the Maxtor in UDMA, is there a recommended patch for the CRC errors? - something in ide.c? Any comments on the 'multwrite' diagnostics - Are these benign?
Best Regards Tom.
-- Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill, Egham, Surrey, TW20 0EX, England. Email: uhap023@vms.rhbnc.ac.uk SPAN: 19.875 Fax: 01784 472794
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |