I'm having an odd problem with my ATAPI driver, and I'm not sure how to proceed. The bug is that after reading one LBA successfully, the drive IRQ stops firing. The PIT still fires, so IRQs haven't stopped all together, and I've made sure I acknowledge the interrupt to both the master and slave PIC. What's really confusing is that it works fine in Bochs, but not in QEMU on on real hardware. So can anyone think of something Bochs might be doing to make it work, that wouldn't be happening in QEMU?
Any help is much appreciated!
Luns
Consecutive reads to an ATAPI device fail
Re: Consecutive reads to an ATAPI device fail
Hia,
Are you sending an EOI to both PIC's? And also, does your driver work properly when you pull the status register?
To poll the status register, you need to read the Regular Status port until bit 7 (BSY, value = 0x80) clears, and bit 3 (DRQ, value =
sets - or until bit 0 (ERR, value = 1) or bit 5 (DF, value = 0x20) sets. If neither error bit is set, the device is ready right then.
Greets,
Bietje
Are you sending an EOI to both PIC's? And also, does your driver work properly when you pull the status register?
To poll the status register, you need to read the Regular Status port until bit 7 (BSY, value = 0x80) clears, and bit 3 (DRQ, value =
sets - or until bit 0 (ERR, value = 1) or bit 5 (DF, value = 0x20) sets. If neither error bit is set, the device is ready right then.Greets,
Bietje
Re: Consecutive reads to an ATAPI device fail
Thanks for replying,
Yes, I send the EOI to both PICs.
According to the specifications I have here, after issuing the command packet I wait until BSY clears, and then the device should generate an interrupt to indicate the status register is ready with the result of the command. Depending on the operation, DRQ may set as well after BSY clears but before the interrupt is generated.
This all works fine the first read (and seek, which occurs before the read), but the second time the interrupt never comes. BSY does clear after issuing the seek command.
e: Any perhaps I should note that the status register after the successful read is normal, and while I wait for the interrupt during the second seek the Error Information register is normal as well.
e2: Success! My problem was that I set the max byte count to 2048, and then would only request to read 100 bytes. Since max byte count was 2048, that's the size it expected to give to me. When I only read 100 bytes, the next time I tried to read it was still trying to send the next 1948 bytes - and therefore didn't ever send an interrupt.
Luns
Yes, I send the EOI to both PICs.
According to the specifications I have here, after issuing the command packet I wait until BSY clears, and then the device should generate an interrupt to indicate the status register is ready with the result of the command. Depending on the operation, DRQ may set as well after BSY clears but before the interrupt is generated.
This all works fine the first read (and seek, which occurs before the read), but the second time the interrupt never comes. BSY does clear after issuing the seek command.
e: Any perhaps I should note that the status register after the successful read is normal, and while I wait for the interrupt during the second seek the Error Information register is normal as well.
e2: Success! My problem was that I set the max byte count to 2048, and then would only request to read 100 bytes. Since max byte count was 2048, that's the size it expected to give to me. When I only read 100 bytes, the next time I tried to read it was still trying to send the next 1948 bytes - and therefore didn't ever send an interrupt.
Luns