On Mon, Oct 27, 2003, Robert Watson wrote: > > Bumped into this panic on a kernel from Oct 4 running on my notebook. > Unfortunately, I don't have a good trace because I didn't have access to a > serial console, or a debugging kernel :-(. It might well already be > fixed, but I figured I'd post about it just in case. Basically, I was > shutting down my notebook, and did a "shutdown -p NOW". During the > shutdown, the system panicked. > > panic: ata_dmasetup: transfer active on this device! > ... > ata_dmastart+0x26 > ata_pci_dmastart+0x29 > ata_transaction+0x999 > ata_start+0x1c9 > ata_completed+0x230 > taskqueue_run+... I have had this problem since the day ATAng was committed. I last verified that it was still an issue about two weeks ago, but I'm reluctant to continue testing on my main machine (the only one that triggers the bug) because it leads to random data corruption. The configuration that *consistently* produces this bug within five minutes of operation involves two 36GB SATA disks mirrored with ccd(4). My best guess is that there's a race in the ATAng code that is exacerbated by ccd(4). By brief inspection, it appears that there are a number of problems with the locking. For instance, ata_interrupt() does an ATA_UNLOCK_CH() with no matching ATA_LOCK_CH(). (This is not detected by witness because ATAng uses its own locking primitives, which have sleep/wakeup races among other things...) Unfortunately, I don't understand the code well enough to fix it and I don't have the time to understand it. If you ever find that this problem has gone away, please let me know so I can sync the ATA driver in my tree.Received on Mon Oct 27 2003 - 18:34:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:26 UTC