Date: Fri, 07 Apr 2000 00:13:31 +0200 From: Palle Girgensohn <girgen@partitur.se> To: freebsd-stable@freebsd.org Subject: ATA and UDMA Message-ID: <38ED0C0B.124AB415@partitur.se>
next in thread | raw e-mail | index | archive | help
Hi! i read the thead a while back on udma. here's something pretty strange. I have two disk, each on a separate channel. Same controller (a rather old intel server board, running with one (out of two possible) pentium pro. The two disk are identical, bought together, and I use vinum with them, so the load should be about the same. What happens is, after booting. the second drive give timeouts, and at the end the system degradese it (fallback to PIO mode). Hence, a sysctl hw.atamodes give "dma,---,pio,---". Now, the disk are identical. After this initial boot problem, not much has happened. I have done a number of buildworlds on the machine to stress it, and it seems to be running fine. Just for sports (this machine is not important to me at the moment :) I tried to force the second drive back to dma, and it immediately locked up so much that I had a hard time getting pio back due to system freezes (at least for remote usage :). It never went down, though, just spitted out many timeout messages. I have set both drives to pio for now... Here's some lines from the dmesg: atapci0: <Intel PIIX3 ATA controller> port 0xf000-0xf00f at device 7.1 on pci0 ... ad0: 9641MB <IBM-DTTA-371010> [19590/16/63] at ata0-master using WDMA2 ad1: 9641MB <IBM-DTTA-371010> [19590/16/63] at ata1-master using WDMA2 Mounting root from ufs:/dev/ad0s1a vinum: loaded de0: enabling 100baseTX port ad1: READ command timeout - resetting ata1: resetting devices .. done ad1: READ command timeout - resetting ata1: resetting devices .. done ad1: READ command timeout - resetting ata1: resetting devices .. done ad1: READ command timeout - resetting ata1-master: WARNING: WAIT_READY active=ATA_ACTIVE_ATA ad1: trying fallback to PIO mode ata1: resetting devices .. done Has anyone been able to shed light on this bug? Is there any other way, apart from sysctl, to force pio until it is fixed? Cheers! Palle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38ED0C0B.124AB415>