Date: Sun, 5 Apr 1998 14:32:01 -0800 From: Parag Patel <parag@cgt.com> To: "freebsd-current" <freebsd-current@FreeBSD.ORG> Cc: "Thomas J. Merritt" <tjm@codegen.com> Subject: Questions for PCI-IDE driver owner Message-ID: <199804052230.PAA18915@mail1.sirius.com>
next in thread | raw e-mail | index | archive | help
--Emailer_-1319507113
Content-Type: text/plain; charset="US-ASCII"
I'm not sure who's currently working or "owning" the current PCI-IDE
drivers, but I have a number of questions and problems about the current
code that I'd like to discuss. I hope this is the right list.
I am trying to get a CMD PCI646U2 chip to work under FreeBSD-CURRENT
(3.0). This is a new PCI Ultra-DMA IDE chip with two controllers (up to
4 drives). I've been modifying the pci_ide.c file to add support for
this part. Programmed I/O was easy to bring up, but I'm having some
difficulties getting DMA to work correctly.
I have a single 3Gb Quantum UIDE drive as a master on my CMD evaluation
card. There are no other drives plugged into this card. I boot the 486
entirely over NFS and then exercise the driver so I can utterly trash the
disk and not care, plus I don't have to fsck after reboot. :-)
In sys/pci/ide_pci.c:
1) ide_pci_dmainit() needs to always call the vendor_dmainit() routine
for the CMD part. Reset sometimes leaves the part in a funny state and
it doesn't appear to work correctly without making sure the right bits
are turned on. The problem may be related to the following problems.
For now, I've commented out the "if" to check to see if DMA has already
been enabled.
Is it OK to always call dmainit() for other parts, or should I add the
necessary code during the device probing? (The probe code has to be
modified much like the Promise controller.)
2) ide_pci_camdma() seems to return the wrong cookie to the i386/isa/wd.c
driver. My drive should be cp->ctlr=0 and cp->unit=0, but because of the
order the cookies are created, ied_pci_candma() always returns
cp->unit=1, which is the first matching cookie it finds. The loop
compares cp->ctlr with the parameter "unit" but it's not clear to me if
this is supposed to be the controller number, the unit number, or if an
additional drive number should also be passed in.
This affects the CMD part since I can turn on DMA for each of the
master/slave drives independently, and I had initially coded the
cmd646_dmainit() to use cp->unit to determine which one to turn on. It
would, of course, turn on a nonexistent drive when given the wrong
cookie. For now, I've simply turned both on as I only have one drive on
the controller. Clearly, this is not the right thing to do. :-)
I'm wondering why getting the wrong cookie would work for the other PCI
IDE controllers, or if I've just missed something important during
probing.
3) The i386/isa/wd.c driver calls ide_pci_status() in pci_ide.c.
ide_pci_status() looks at the BMISTA_INTERRUPT bit to see if there has
been a DMA interrupt or not. However, at bootup, ide_pci_status() is
called from wd.c without a preceding call to ide_pci_dmastart(), so there
is no DMA activity and BMISTA_INTERRUPT is never set on the CMD part.
My hack to workaround this is to check another CMD register for any
interrupt (not just DMA) and return WDDS_INTERRUPT if either interrupt
flag is set. This test is only done once - the first time
ide_pci_status() is called. Thereafter, it only checks the
BMISTA_INTERRUPT bit. This lets it get past the bootup initialization
sequence and it appears to run fine afterward.
Without this hack, the driver essentially hangs waiting for a DMA
interrupt that never arrives, and eventually it's time for the
three-fingered salute.
The question is, why is the wd.c driver calling ide_pci_status() *and*
waiting for an interrupt when it has not started a DMA transaction? Do
other IDE controllers always set the DMA interrupt bit even when the
interrupt has nothing to do with DMA? Is some other IDE transaction
expected to turn on the DMA interrupt bit?
For your amusement, I've enclosed the dmesg output from a session where I
simply logged in and ran "fdisk" a few times. I've inserted debug
printfs in all the ide_pci.c routines to see what order things are
called. I print out the ctrl:unit numbers in most of the output so it's
clear the wrong cookie is being used.
Any help would be much appreciated. Thanks in advance.
-- Parag Patel <parag@cgt.com>
--Emailer_-1319507113
Content-Type: application/octet-stream; name="dmesg.SIT";
x-mac-type="53495444";
x-mac-creator="53495421"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="dmesg.SIT"
U0lUIQABAAAQR3JMYXUC3QAAABbd3QANBWRtZXNnAACgI/4CAAADNNvQA1X3EAATOAIDOiykA1Uv
ngmGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////1RFWFRSKmNoAQCxTUMvsU1DvgAAAAAAALVI
AAAAAAAAD8EAAEz8AAAAAAAAxMgOTlkEJcCEd+Q2PXL0DD/q7AhfOdlrg66VcB1wasc7siWbUILP
s8ITtp4Xx38NOEE/eoEAbv2eX/RrjR/++HVUtsl6Zfbm8aT4TbjkNtnHAMheyXoAKwAW8PldtW5E
ZJKqV4xyRVWpyexgl9kuLTxjUcDaFVoKu4eR39pNaMaZJbVc1ubxw6LHEWOLjWWqB07ho39hWNoc
/1UUv8r8V1kVv/QJzKOtXUabrMWCJKbQowTH24G/x6LYTw75P5bstu+FUeDbBaq12yTQY4pYzKI9
5k4rNiywXlDml7Y3N1fWtuh3WrlCjV5Aw+uNilHCF20sb/HiWRMu/onCMPlj1xf/LHTtyG4VnNDl
BcXvTmWhF0cLvQUPFWjG7kIcOQvxYbyAv3b9NltYXKmtfbZSW562HfqgGdmJH7TIaYfOs5l4lgqF
AvmWZhr9v1RIVcu6YSr02TdTpKef72w3VnbqnGBnqfa0vrhZ26qvr1EQJhR3meN7PnNpnnoxx3aZ
Z/faCaGaX/dY4BxOGLf8DnPCXpCwiD4WpfqYjgFEvVRLQ72InDBOSC9TEE9rt7FdId+wirT8Z4Nm
cDDvtO045n+cverddSiJH1CVPn7Cgp4fsDqK1EZ16i7+pBwYlkLUSFgX3d2qKldMj5md9CBNVeVA
/+Txxvbcl6srn05ujpjdpg7rhNEhAV7XTdMwdI1mdK1UtD6n5mHC4mlZN3YPY985hnF2ewFXisrk
buVAwUfFNzpeHJY9fOaoaKpa0egXgWZUs0xdu/WyHhxDK2pHTKrnuYJJVxUDpVWGVCUTZzdY9p7t
H9UY/aJohgIamtHKpq696ZfHkCaXFuvrDXRbA47Cdxgt+xFzEo7GL4Nw2Qlq5ymK17SsqRCsBImo
Cy5tuppCM4PbcTZLsDt7/L9ETxmXH3Xa1kt1USSCTwKZqEfTNae1WIelivqXx34r6OsTebzuU1Go
LW3U0caDz+TC328EG7cXdh1/J+yyYEadrTzqwDuRSrbrRtQNI3hMiIbjWbPkx6i5BSTNMoxbLHvA
pfaFmTPwD0cbnk2lggM5XsvZZTBaj1wmpEJBsTTSycDdXwkDUlWKnOiv9NWuG1X5ASrHe5DRjO9W
FaNcVBW9fCXmUdjkvgv2F96L88IjB0IMmj20w7R/RaPPf/pojwVuiHoccPg5joMzXow5mI89XpgD
fapEj4ZFnlcUfM0RqpwcdhmnwWnHE2QTEGfX7yoV+qThN8gyHVTiU14JNLmu8iqj3ZSCWZiinNfY
1HV9WGPL8lCXYY2vFGlYY/1DjR/5QQL3WLXnyI++rpanV3bs7lfKXyvEgQlBSmQHLUY6QpamHTOC
jxCfOaj5N4w0c8K017JFp+lUhkdqRXZ313dish2HtRkihTAath5UESUjm5eLykdtqKr/7kPuJY+0
BtbyuA9V7U0fqtKBPlSv7vyuEY3zRuRNyJV+0Ig0DYwEk/pzc3OjfMcUOBFvbvwkU3csVbHJs+NE
VSh2Yn/Y2Kp20tj471FnIxO7gez4QXwYOFXNRPPZB/0zBQ4Ch6HnxVULuV+R3P0wcmNYlChO5hAl
RR3kEW4HdUGQdwqrZbA8cWqzeUgJc+eIOzlyIxuBTX3zC5zwiPCGBcYvsbmZ5C3BT1kyexYcprej
jewgGNowYLQY4kelUCjSzJcadduaAVldULUF1TgzdT9VZN/2RZLHmURRhv4uCQnVSdpsghI7sIEK
TwNEoYQnnFzruOLOwe39isLEthGGXl8PvakvrtLS8uYq/Lii0+JfNNg3oWom+qsT7tnNNqPGUqNO
Z0qfMS0tz2+ur9Kr69aWNunrnh8946Z+CvkKzObCthuFQdiLpyoBffhDQryJeHrNlXty6fdeqQxZ
HXilonHiy5UzjzfiOfFKxo1XugA59UpnocDFnVOvBDM49DVnkwEZ05FX+pEJfmnINFUAwaSNmfRf
66SPmYxf62SMmcxjprM8bMTku2yHWz5o99LqMg+RIDLbGm23k8he0HWqL68ggke+GLaRChwlAua3
xvE4mVGfRzOX1Ij0xAwBd27C5hyzIsl66Tw6Lmq2Ay+X9GJcWVFQpJYf89kCt9fpnuVhIwbxAS9A
uOKiH8u8m0oEV4wuRbn5h/vwaxgVMPiARhXn0KTBgT48MJSpiPa5+zDm4Gpeq5ODQdGuYfQ+zAlD
8VsYA85NVZrXMMY5zOjgGsZUKg46jDkGBldwwg8HlIODNzBF3s1ibEElnufyUOZ9ZUpKxdPRsIZi
8WPLVXEwyNxw4GIigpnOg1apMkutGpi0Ck+QOsgOuSOjoXJh8MeLwo6YxujPdaDjpyb2iAoH3Krt
2sgEGWI8GD/Pb2EMxRXx1/JqDfM6YkLlFypVGkB1qtaqbM1Z6nIBtU5hcrUewZxr1dhZpgXJtSqF
ybUqhcm1KoXJtSqFybUqhZGiaNX3zlI9cpYo0HNnaU+ofpyL4+l7vQHbB7gJReygZfidTi+KMFdJ
z9hhM7Qj99tkEoPaHRsTonygFCUypqrzrOn6YYWW67Una+uNlWG9oapvbt9aaWztfL64vLOxvrl1
jHAlyAOEzZXGimCAP8DUJ7fILgODN+2xc4ajEtjT69Fc/SnVIia3DopePz7mXdoJ+TCkaLRXTSqG
VzELwULcjhKexfLZxV8+qR15o5h6XR5eh/ssmu91JwgYo1ctPiwFoer/wqQL/6VRsUSmR4bH78D0
ummSpZ7Nl4yQmh6pHmfA1YpLCtcU8VWCaFPZIYuR5ZEGbA9TRVdIZbJ18gQVtB/F4VUyCB5Oxa8S
6RYfqtdt0pukO1Mk3SUd0wZAcgQVDqxhoYZfvCFE9UD+qh1PWlg7G1m47mHMfwk14NL/GkSu0Mni
S37SyX9rSgxzNBl2RAyiN6lTX0bhfrzDRzFZUpmmLUfN7IRtdO4nmN7c86Okh4FNmOA4bLN4jry2
3eIzdsrZJosREesPF2Iiz+LOTyv3rZ/JrZ8fT60jCMS0EMY0Mc+I5FipNI2KplVYs8LYXH8mam1F
7JSYQcGafjJ71SB+OCiN7lkojY6+4qVBvs0LjP/152JfVonTDOd4i6ap1F7eidUGojlEBbRBBfRb
bPUeu91NhoUvicKX+til19gcoYIFQZD7qNdN5sUUFzfTUXJ1Oy7fWtpYqG9gWLIrRkMxVMYiz3bO
ZiVH93vuME3QPS4qulcSBcSoMX5pr8vocWlRC4axuohlQKYfvI6wdjDliRnm/iSPH/IxvJ19t8qn
GqkX+ElVIceLqsNA7xQMy1POwfaPqsoheEqiwksMtchWPI9//1DcEY/EoFBDMFD5AEAes1pvbNWq
xenlg7T6+d3Uw392uFesYoraD/tHBnX2j//3mu9mzmrE8D4NT2HyNDyFydPwFCZPw1OYPA1PYY7T
cAjUqzQ8hcnT8BSmn4b3s++bNPwHxUdZ9l2Ycy5vM7Ni0p8H2ZjADWIPisX/x+MUYyp93EBUhKaj
pjOAm8Vs7xfbtbWt7VV6XN9cWaw9fUqNLb2g1T6d4xNRWLukzcMvYx4ce7z8+SZfGjavFl/VTldK
ZVinGchYUTEs1I+vSYpnsSJKM4vkHLYRF8CS86txUtSpsbA1R1gfRYsLZ3NYGWVtq0b1tS+2UUHa
w9YzsY4Lcozp+I7d4csl+B+w8GmObBiH/r+x74UbisFVE9SgeyDs/k95dHorjDAWyKHMqYe9MFEY
f3gGg9JEwSBtlgKdQ5aBHXc4LSlKE/P2AVYIDE8nSCIIfcLCDksin53PPFzIGeIUXXFKHo+eCoWS
pVRLyNXQuD72bEToWfxL1UpVFQHZoItVrLrQq+jlQbdfYfLlMmLrm4gEJ1cu9/cpDaf4sOcOvenB
M8a7z5f8XXQm28ceEvlAjy0hBYP/jbhKrz1uiHV/5C2c74UY3c3v21xf30LkUNYKatEqwJDgW6uI
PYCuHz9DvhbvcKZrnMafaliudY+jnUzLtUMsvcNcB+pCT9ef1NewFKU3S9j5hz7ZO7VEmnkZB7hh
wJBJCe+NXGGQNjQ7Vb6cgFv9pfXV6ukSGw2J3QcXf8Hwm4vPYB5cfAbz4OIzmAcXn8E8uPgM5mGm
LYN5cPEZzNDFv51pu4A50T/sIPK9QxgO2/V6Z9tVXlwew/33uviLfFU1xS4uKavufZeWGD/q3+mO
SNmj/vENAOX/6h8S/Xg4sYYRJ2wsE5sYi8jrsfkOcb2BDeBaCStpxSozcaqWCHuLP7+m047omlig
18cTGBbC3z5jf14B8wKCUVORcGMR6jXjvYJLMBxsSS6g4ClMruApTK7gKUyu4ClMruApTK7gKczD
Do8LmJu8c3z5u7xzBHOvmmlrSBdV8zbvlDzq3l3eOda9PO+UQPq+N3mnHED/pKa5x2VaaMkF0sIR
zL1qjhjeq2YKk6tmCpOrZgqTq2YKk6tmCpOrZgqTq2YKk6vmC+F7mxZKHnXvLi0c616eFsoB9K8s
F9C/FCbXvxQm178UJte/FCbXvxQm178UJte/FCZPC0cwN2nJ+PJ3ackIRrKomm9c4wvhe5uWyMF0
T8c7dyQCupfBPOheBvOQllzA/C8tuWC607+syA/6l8E86F8G86B/GcyD/mUwkhX9e5eWSAL079T/
ySD1Tybg//6RFr64/DYtlIuq5tu0UPaoe3KatDB9gmmufylMrn8pTK5/KUyufylMrn8pTK5/KUye
Fo5gJAKb5zI6qcDmuQvGD3nniOlewdM2leQp+BsHO9a/y7xzfPm7vFNGp5pygde8ZTC5av78QrZf
8k4pwCv2suLmuicXeBdbBpPrnlzgXWwZTK57coF3sckVdO8u7xzrXp53Sh717y7vlAPon2TS/8kG
co/LtPBFaHKbFkpFVVPGlhbKBV4mmcHkunf5Msm7tPDvzzr7LS2cvMzzn/onF3iZZwaT659c4GWe
GUyuf3KBl3lKPPTvLi0c699lWjK+/F1aIoFUTZmAa7xNSySPuifdTUukBG8AumC61z+5wBuAMphc
/+QCr3jKYHL9kwu84imDyfVPLvCKpwwmzz3+8+a5F5e/SwtlJ6opF3gLRwaTq6Zc4C0cGUyumnKB
t3BkMLlqSgXeAHTBcq97coE3oGQwcjLdu0sLpQRvAJI96t9dWjiCkQlsnkvp5AKb56QErxiSQSq4
TMDBXuadcoE3z8lFVfM275QCvOLmguG97skFXjGUweS6Jxd4xVAGk+ueXOAVQxlMrntygVcMXcB8
yDslj/p3l3fKAfRPMun/7nKPsf5dpoVygTfPyUVVU/qXFsoFXq+VweRp4fj1WnlaKAV4xVZW5Fz/
5AKv2Mpgcv2TC7xiK4PJ9U8u8HozuYL+3aWF/3nz3IvL36UlJzDxYdwOW26F2IGf+EGLwgBDkq3A
bpNqfvR/
--Emailer_-1319507113--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804052230.PAA18915>