Never mind. There's some x86 memory weirdness going on where Linux is tricked into servicing the completion interrupt twice.
Gabe Gabriel Michael Black wrote: > Or to rephrase, should the event be descheduled, or should it still > happen and the IDE disk just deal with it. > > Gabe > > Quoting Gabe Black <[email protected]>: > > >> 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 >> >> > > > _______________________________________________ > 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
