On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko <igor.v.kovale...@gmail.com> wrote: > On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl <blauwir...@gmail.com> wrote: >> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman <nick.couch...@seakr.com> >> wrote: >>> In working to try to get Sparc64 system emulation developed, we seem to >>> have run into an issue with the IDE code in Qemu. The OpenBIOS folks have >>> been working quite a few issues with the OpenBIOS code that need to be >>> resolved in order to boot 64-bit Solaris kernels correctly, but the most >>> recent issue indicates that the IDE code for the Sparc64 emulator is >>> reading from and writing to the wrong memory locations. The end result is >>> the following output when trying to boot off an ISO image in Qemu: >> >>> bmdma_cmd_writeb: 0x00000054 >>> bmdma: writeb 0x701 : 0xd7 >>> bmdma: writeb 0x702 : 0x79 >>> bmdma: writeb 0x703 : 0xfe >>> bmdma_addr_writew: 0x0000ddef >>> bmdma_addr_writew: 0x0000b12b >>> bmdma_cmd_writeb: 0x000000da >>> bmdma: writeb 0x709 : 0x95 >>> Segmentation fault >> >> I can't reproduce this with milaX 0.3.1, QEMU git HEAD and OpenBIOS >> svn r644. The bug could be that the BMDMA address may need BE to LE >> conversion, or OpenBIOS could just clobber BMDMA registers with >> garbage (the DMA address candidates 0xddefb12b and 0xb12bddef do not >> look valid). >> >> Another possibility is that the PCI host bridge should have an IOMMU >> which is not implemented yet, but I doubt we are at that stage. >> >> Could you run QEMU in a GDB session and send the backtrace from the segfault? >> > > There seems to be an issue with pci_from_bm cast: bm->unit is not > assigned anywhere > in the code so it is zero for second unit, and pci_from_bm returns > wrong address. > Crash happens writing to address mapped for second unit.
This appears to be a regression in cmd646. After removal of pci_dev from BMDMAState structure we cannot do much to work around this issue. The problem here is that we cannot rely on bm->unit value since it is getting changed while dma operations are in progress, f.e. it is set to -1 on dma cancel. Thus we cannot get to pci_dev from BMDMAState passed to i/o read/write callbacks. Juan, can you please take a look at this issue? -- Kind regards, Igor V. Kovalenko
