- From: Patrick Allison <barawn_at_psu.edu>
- Date: 05 Jun 2002 10:19:53 -0400
On Tue, 2002-06-04 at 19:30, David Schleef wrote: > However, this is not good. The driver doesn't do anything about > this, although it could. I tried playing with setpci on my > machine, and managed to get my board into the condition yours > is in, so I assume that setpci can get it out of this condition > as well. I preferred the easier "reboot". Ah, I so wish that just rebooting would work in my case... :) > > "setpci -s 0:a COMMAND=0x0017" is probably a good place to start. I'll give that a try tomorrow. I was looking around to try to find out exactly what the bits were, but I couldn't find it anywhere (lspci calls it "Status", and apparently it's the "Command" register - thanks, I wouldn't've figured that out myself. :) ) > This is very bad. I agree. :) > I'm guessing a lot of this is your BIOS's fault, and Linux and/or > Comedi is not cleaning up the mess. Or, it could just be a bug > in your particular choice of Linux version. It's just stock Debian/Woody, but I'll try a couple things tomorrow - updating the BIOS (which is moderately out of date) and updating the Linux kernel and seeing what happens. It's like an adventure! Change one thing, watch ten others change! Incidentally, one question to ask: is it really a good idea for the MITE driver to happily accept reading 0x0000 0000 from the BAR0 and BAR1 PCI registers (i.e., it's assuming that BAR0 and BAR1 do actually contain memory addresses)? Yes, it remaps them, but they're DEFINITELY not correct (right?), and it should probably complain about it. Part of the problem that I had locating this issue was that the MITE driver and the ni_pcidio drivers seemed perfectly happy with the state the machine was in. I might've caught it earlier if MITE had noticed invalid addresses and completely bailed. Maybe some sanity checking would be helpful? Patrick
Received on 2002-06-05Z13:19:53