Re: ohci & ads pyro card
Brought to you by:
aeb,
bencollins
From: Sebastien R. <Seb...@sy...> - 2000-03-18 05:12:19
|
>>>>> "Jeffrey" == Jeffrey B Mulligan <jb...@vi...> writes: Jeffrey> I went to the link you sent me (at your site) and it sent me to Jeffrey> sourceforge... I got the latest 2.2.14 patch from there (the Jeffrey> february one), but the behavior is pretty much the same as I was Jeffrey> seeing with the january patch. The basic problem is that the driver Jeffrey> sees the card but doesn't see any nodes. No no... don't get only the patch, get the latest ohci module from the cvs tree ! Just follow the instructions on how to download using cvs, and then you should be able to stay up to date with the latest changes. Jeffrey> One thing I noticed is that the interrupt handler is getting called a Jeffrey> lot with event=0... the IRQ is shared with other cards, does that Jeffrey> mean that handler will be called when one of the other sharing boards Jeffrey> generates an interrupt? I am not completely sure about that. If the interrupt handler is called with event=0, then nothing should happen and so no problem should be generated. But I thought that even if the interrupt is shared with another device, the interrupt handler is only called when the corresponding device generate an interrupt... I should verify that in the doc. Jeffrey> I also noticed that the node count gets set after an interrupt occurs Jeffrey> with a selfid complete event... I couldn't determine what is Jeffrey> supposed to make this happen, but it never does. There is a known bug in the driver (documented in the top of the file). If you load the modules when no devices are connected on the bus, then later on when you plug a device, the self-ids might not be received properly. I haven't found the cause for this yet, but as a result the node count is not incremented. But if you load the ohci1394 module when at least one device is plugged, then it should be fine afterwards... Jeffrey> Perhaps the wrong irq is being detected? On my system the irq's get Jeffrey> remapped to numbers > 16. This caused me some problems with another Jeffrey> driver I was working with (for an analog frame grabber), which was Jeffrey> reading the irq from the pci config space register, instead of using Jeffrey> the new improved method of getting it from the system's pci_dev Jeffrey> struct. I see that this is done correctly in the ohci driver, Jeffrey> though... IRQ > 15 ... Don't know about that either (I am not a real linux kernel guru). what does the /proc/interrupts say ? What does the dmesg say after you load the ohci module. Jeffrey> One other possibility - I am running on a dual-processor motherboard Jeffrey> with SMP enabled. Has the driver been tested under SMP? I suppose I Jeffrey> could rebuild my kernel with SMP turned off and see if it makes any Jeffrey> difference. Everything else involving SMP has worked so well I am Jeffrey> doubtful that this is the culprit. I also have a dual PIII here with SMP enabled, and the ohci driver runs fine so far. Jeffrey> I also discovered /proc/ohci but I don't really understand yet how to Jeffrey> interpret the output... It is just a way for me to easily debug the driver. Its main role is to print the ohci registers, plus some internal variables of the driver... you can modify its behavior to print whatever you want. Jeffrey> Any suggestions you can provide will be greatly appreciated; I Jeffrey> prepared to try a different card if that might help... First download the latest ohci module from cvs at sourceforge. Then plug a 1394 device to your card. Then load the ohci module into the kernel and see what dmesg says. If you still have trouble contact me (and forward your post to the list). -- Sebastien Rougeaux RSISE, The Australian National University |