I think what's happening is that the controller is being told to stop DMAing before it's done. The controller tells the disk to abort the DMA, but the disk has already scheduled an event in the future to do the transfer. It sets itself up to not do a DMA, the event goes off, and the panic gets called. What is the right way to fix this? The chunk of trace I'm basing this on is below and ends at the point of the panic. A regular DMA is next for comparison. Note how eot is 0 until the DMA completes. In the first case, it's still zero when the DMA is stopped, and in the second it becomes 0x8000 first.
Gabe 2792590196000: system.pc.south_bridge.ide: Write from offset: 0x80000000000001f7 size: 0x1 data: 0xca 2792590712000: system.pc.south_bridge.ide: Read from offset: 0x8000000000001000 size: 0x1 data: 0 2792590722500: system.pc.south_bridge.ide.primary: Starting DMA transfer 2792590722500: system.pc.south_bridge.ide: Write from offset: 0x8000000000001000 size: 0x1 data: 0x1 2792590802501: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x776cc00 (0x776cc00) byteCount:1024 (6) eot:0 sector:426053 2792590802501: system.pc.south_bridge.ide.disks0: doDmaRead, diskDelay: 1000000 totalDiskDelay: 1000002 2792591027500: system.pc.south_bridge.ide: Read from offset: 0x8000000000001002 size: 0x1 data: 0x65 2792591142000: system.pc.south_bridge.ide: Read from offset: 0x8000000000001000 size: 0x1 data: 0x1 2792591151000: system.pc.south_bridge.ide.primary: Stopping DMA transfer 2792591151000: system.pc.south_bridge.ide.disks0: Posting Interrupt 2792591151000: system.pc.south_bridge.ide: Write from offset: 0x8000000000001000 size: 0x1 data: 0 2792591157500: system.pc.south_bridge.ide: Read from offset: 0x8000000000001002 size: 0x1 data: 0x64 2792591168500: system.pc.south_bridge.ide: Write from offset: 0x8000000000001002 size: 0x1 data: 0x66 2792591205000: system.pc.south_bridge.ide.disks0: Clearing Interrupt 2792591205000: system.pc.south_bridge.ide.disks0: Read to disk at offset: 0x7 data 0x50 2792591205000: system.pc.south_bridge.ide: Read from offset: 0x80000000000001f7 size: 0x1 data: 0x50 2789322130500: system.pc.south_bridge.ide: Write from offset: 0x80000000000001f7 size: 0x1 data: 0xc8 2789322646500: system.pc.south_bridge.ide: Read from offset: 0x8000000000001000 size: 0x1 data: 0x8 2789322657000: system.pc.south_bridge.ide.primary: Starting DMA transfer 2789322657000: system.pc.south_bridge.ide: Write from offset: 0x8000000000001000 size: 0x1 data: 0x9 2789322737001: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7d9e000 (0x7d9e000) byteCount:4096 (56) eot:0 sector:568405 2789322737001: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789323897009: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7dbd000 (0x7dbd000) byteCount:4096 (48) eot:0 sector:568413 2789323897009: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789325057017: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7d75000 (0x7d75000) byteCount:4096 (40) eot:0 sector:568421 2789325057017: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789326217025: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7ca5000 (0x7ca5000) byteCount:4096 (32) eot:0 sector:568429 2789326217025: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789327377033: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7d90000 (0x7d90000) byteCount:4096 (24) eot:0 sector:568437 2789327377033: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789328537041: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7b46000 (0x7b46000) byteCount:4096 (16) eot:0 sector:568445 2789328537041: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789329697049: system.pc.south_bridge.ide.disks0: PRD: baseAddr:0x7caa000 (0x7caa000) byteCount:4096 (8) eot:0x8000 sector:568453 2789329697049: system.pc.south_bridge.ide.disks0: doDmaWrite, diskDelay: 1000000 totalDiskDelay: 1000008 2789330777057: system.pc.south_bridge.ide.disks0: Posting Interrupt 2789331068500: system.pc.south_bridge.ide: Read from offset: 0x8000000000001002 size: 0x1 data: 0x64 2789331183000: system.pc.south_bridge.ide: Read from offset: 0x8000000000001000 size: 0x1 data: 0x8 2789331192000: system.pc.south_bridge.ide: Write from offset: 0x8000000000001000 size: 0x1 data: 0x8 2789331198500: system.pc.south_bridge.ide: Read from offset: 0x8000000000001002 size: 0x1 data: 0x64 2789331209500: system.pc.south_bridge.ide: Write from offset: 0x8000000000001002 size: 0x1 data: 0x66 2789331246000: system.pc.south_bridge.ide.disks0: Clearing Interrupt Gabe Black wrote: > panic: Inconsistent DMA transfer state: dmaState = 2 devState = 0 > > I think the 2 is correct. It's the same device/vendor ID but the BARs > work a little differently to be compatible with legacy IO ranges on PCs. > The chunk of log below makes me believe it's being identified as the > right device, so it's probably be the accesses. I'll compare with Alpha > and see if I can figure it out. Thanks! > > Gabe > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > PIIX4: IDE controller at PCI slot 0000:00:04.0 > PIIX4: chipset revision 0 > PIIX4: 100% native mode on irq 14 > ide0: BM-DMA at 0x1000-0x1007, BIOS settings: hda:DMA, hdb:DMA > ide1: BM-DMA at 0x1008-0x100f, BIOS settings: hdc:DMA, hdd:DMA > hda: M5 IDE Disk, ATA DISK drive > hdb: M5 IDE Disk, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > > Ali Saidi wrote: > >> It's a panic that is supposed to check that the state machine in >> operating correctly. To start a dma transfer the device is supposed to >> be in Transfer_Data_Dma (which some device access writes put in in) >> and the dmaState is supposed to be in Dma_Transfer (as opposed to some >> other phase of the DMA). Which one is incorrect in the panic? >> >> Are you identifying the device (PCI device/vendor IDs) exactly as we >> do for Alpha (it ends up being a Intel PIIX IDE controller or >> something). If you're not you might be stumbling on some un- >> implemented feature. If you are, then I would guess that it's >> something to do with I/O writes not getting to the device correctly >> (either order or just disappearing). You can boot the Alpha version >> with DPRINTFs and see the correct sequence of commands and then >> compare that to the DMA that dies for some more insight. >> >> Ali >> >> >> >> On Apr 8, 2009, at 5:46 PM, Steve Reinhardt wrote: >> >> >> >>> I don't know much about IDE either, but it may have more to do with >>> DMA in general than with IDE specifically. What is the specific >>> panic that you're getting (i.e., the actual output)? >>> >>> Steve >>> >>> On Wed, Apr 8, 2009 at 1:36 AM, Gabe Black <[email protected]> >>> wrote: >>> Anybody? The ATA spec I have is -really- long and I'm not feeling >>> ambitious enough to read it :). I don't know if this would be >>> covered in >>> there anyway. >>> >>> Gabe >>> >>> Gabe Black wrote: >>> >>> >>>> I have an SMP kernel booting and running the init process, but >>>> >>>> >>> I'm >>> >>> >>>> getting the following panic from the IDE disk on line 321 in >>>> dev/ide_disk.cc: >>>> >>>> void >>>> IdeDisk::doDmaTransfer() >>>> { >>>> if (dmaState != Dma_Transfer || devState != Transfer_Data_Dma) >>>> panic("Inconsistent DMA transfer state: dmaState = %d >>>> >>>> >>> devState = >>> >>> >>>> %d\n", >>>> dmaState, devState); >>>> >>>> >>>> I'm not familiar with the details of IDE. Could someone please >>>> >>>> >>> give me a >>> >>> >>>> 30 second explanation of what this is checking? >>>> >>>> Gabe >>>> _______________________________________________ >>>> m5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>>> >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
