Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Apr 2000 20:03:24 -0400
From:      "C J Michaels" <cjm2@earthling.net>
To:        "Palle Girgensohn" <girgen@partitur.se>
Cc:        <freebsd-stable@FreeBSD.ORG>
Subject:   RE: ATA and UDMA
Message-ID:  <NDBBILKDCLLECBCLPMBIOEBOCAAA.cjm2@earthling.net>
In-Reply-To: <38ED0C0B.124AB415@partitur.se>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BFA002.CC10E020
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I had a similar problem.  I don't know if this will apply to you at all
but maybe it'll help.

1. System bios has drive listed as LBA.
2. Dangeriously dedicated disk.

The sytem would lock up and report a good number of those errors listed
below.  Timeouts and resets.  Well, after cvsupping and making world a
couple times it started complaining about an timeout error reading a
block, and it was a block near the end of the drive.  Also, I'd like to
note that where there's a BSD slice at the begining of the drive, the BIOS
never detects it right.

So... I wiped the disk and the mbr.  Explicitly set the drive to large in
the bios.  Re-installed and all my errors went away, using UDMA w/o any
troubles at all.  I dunno if this applies to you at all, but I thought I'd
make the post.

Just my 2 cents,

--
Chris

-----Original Message-----
From: owner-freebsd-stable@FreeBSD.ORG
[mailto:owner-freebsd-stable@FreeBSD.ORG]On Behalf Of Palle Girgensohn
Sent: Thursday, April 06, 2000 6:14 PM
To: freebsd-stable@FreeBSD.ORG
Subject: ATA and UDMA


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

------=_NextPart_000_0013_01BFA002.CC10E020
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvTCCAqEw
ggIKoAMCAQICAwJd6jANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx
OTk5LjkuMTYwHhcNMDAwNDA0MTEwODI1WhcNMDEwNDA0MTEwODI1WjBEMR8wHQYDVQQDExZUaGF3
dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJjam0yQGVhcnRobGluZy5uZXQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM5lx40uF+cAlXOfMgeto7Ajjl7UII/J8YsIYoiKeUjI
WMFNiOFBvqUFWl7+eURXoMpY3iP10kqwl+QjyG3pnLAAj3C9WmSUHJzT+xIb5VFtVr3r4UWFoL6N
Ov37j+WqaNyz1r09UhWbqE/sX+0LYKtr9Uk/Gmd8GOuAUjG5E7/pAgMBAAGjUDBOMB0GA1UdEQQW
MBSBEmNqbTJAZWFydGhsaW5nLm5ldDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFIir8WCDZlX0
5FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAIfGiPOf/H7t4bGtjun7S6DYvJ5juEDW1bnM
P13vEdv5dpzNlSgN5oE7fT5ZcADH8cJ07rfC78fBdcTm/QpcJo2OgZffqbW9zlZK5576wDl1bHdS
oR3sfZFxqvtj1f4MnJ/2RssJ/IN6d/DkuDOBUmIJf8C9WsGHpoSIdLM6a9OgMIIDFDCCAn2gAwIB
AgIBCzANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu
Y29tMB4XDTk5MDkxNjE0MDE0MFoXDTAxMDkxNTE0MDE0MFowgZQxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp
bCBSU0EgMTk5OS45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzaVqX1NAWC3q1xV3p
IZwjcs0STEv3fs/H+8pyJPRCUqxXleN7YXoXhOf9cjk4lLTq7WWnkgZeveBl9hm7lHl2TD65aHB1
hBz0EXQAvAUsTwkDFzHM9EHUcsamXeKIRLCLLsRN8fDWhT5s85WUeJF+QOmc0Y0VV47Cc+Uw3kb1
TwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX53
9IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAGvGWekx+um27LED2N9ycv6RYEjqxlXde/BnjsZhcOdt
wqU32J23FyhWBYvdXHVvxpGQxmxmcRPQEHxrkW+G4CE2LcHX6rIJrc8tbcaDUpv7u/6ch538t+l0
kuRcl678fqzKDW9yemcsa3P1hvmd9QBu9B0Hzp2egmMp75MJflXeMYICkjCCAo4CAQEwgZwwgZQx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxl
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2AgMCXeowCQYFKw4DAhoFAKCCAUswGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNDA3MDAwMDQ2WjAjBgkq
hkiG9w0BCQQxFgQUV3p1yAMx9+hL73caj8OCNFVSJcowPAYJKoZIhvcNAQkPMS8wLTAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBrQYJKwYBBAGCNxAEMYGfMIGc
MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52
aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG
A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAl3qMA0GCSqGSIb3DQEBAQUA
BIGAse0l7uhGBAxT85QOJs3PPIRHMhKIuKvIKUYL/zQwEBWysg3p5iRDY3hG3ILU5dKhSMJ6PK3U
f1SIabpZ3RIAZPTnkHo03i3zxofVzNZ3+JcnikVoq9gEYC2RNnVCbDUdLu+xSHPsdQkktszUpZPN
yCeuC60mtT/18XXuXv9LIP4AAAAAAAA=

------=_NextPart_000_0013_01BFA002.CC10E020--



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?NDBBILKDCLLECBCLPMBIOEBOCAAA.cjm2>