Am 23.08.23 um 10:47 schrieb Fiona Ebner: > Am 17.02.23 um 22:22 schrieb Mike Maslenkin: >> I can not tell anything about dma-reentracy issues, but yes, i would >> start to look at check_cmd() function call sequence. >> The most interesting is why Sector Count = 1. I thought about race >> with IDE reset where registers initialized with >> value SATA_SIGNATURE_DISK = 0x00000101, but this means LBA=1 as well... >> > > You got it! Since we got another report (after half a year of nothing) > and also because of Simon's mail, I gave it another shot too and was > finally able to reproduce the issue (with our patched QEMU 8.0, but > patches shouldn't affect IDE code). See below for the traces that > confirm your theory. The reason the write goes to sector 0 and not 1 is > because ide_dma_cb() uses sector_num = ide_get_sector(s); and that will > evaluate to 0 after a reset. > > So the issue is indeed that ide_dma_cb can get called with an IDEState > just after that state was reset. Can we somehow wait for pending > requests before proceeding with the reset, or can we force an error > return for callbacks that are still pending during reset? >
I noticed that ide_bus_reset() does the reset first and then cancels the aiocb. Maybe it's already enough to switch those around? Best Regards, Fiona
