Hi, If the driver is doing something daft like DELAY(x) in a fast interrupt handler which would lead to that behaviour, it should be fixed.
If it's doing a DELAY(x) in a critical section, it shuld be fixed. Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can preempt that. I don't agree with this behaviour, but it's possible. Now, it's quite likely you hit some kind of ata(4) bug which kept it in a tight loop without some kind of "too many errors; bailing" behaviour. I'm not an ata driver person; i have no idea why it's doing that. The driver shouldn't be disabling interrupts for other devices. That happens in critical sections and when doing lock operations. ata(4) doesn't call critical_* in the driver code. So it was likely just spun in some high priority loop that nothing lower-priority could really do anything about. The next time it happens, please break into the debugger and grab some debugging output. Show alllocks, ps, should be a good couple of things to start with. Alternately - please find a currently actively maintained SATA chipset. (Or Alternatively - step up and help migrate the nvidia chipset support out of ata(4).) Adrian _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
