On Wed, Aug 23, 2023 at 12:17 PM Fiona Ebner <f.eb...@proxmox.com> wrote: > > 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
Great job! Patch looks good to me. Since the reason is known now, It can be easier to reproduce original case again, but with disabled NCQ. There is no command line argument, so it is required to rebuild qemu without announcing HOST_CAP_NCQ capability. I'd expect this greatly increase chances to catch original corruption. Best Regards, Mike.
