OSDev.org

Yes, I aligned the virtual addresses too, but nothing changed

So, i rewrite the driver again, because i noticed some problems in allocation in my posted code, and i can't use aligned virtual memory propertly, now using the code from wiki, i allocate the address space for AHCI at kernel boot, align it to 1KiB, the CI is clears, but i don't see the DMA transfer from the controller, did my aligment is incorrect again?

EDIT: Fixed some structure issues and i got error 0x7f from PxTFD register before issusing new command

Do you mean the error field contains the value 0x7F, or the entire register contains 0x7F? If it's the entire register, the drive hasn't sent a status update since the controller was reset.

i fixed the issue about the 0x7f value. I tested the reading from AHCI. Also after enabling the interrupts i got continuislly the interrupt from IRQ 0x2b, but the PCI device interrupt line reports that the IRQ is 0x10b, i read the interrupt line using PciRead32, can the interrupts caused by non handled previously interrupts from the controller? Also runned on real hardware, got port hung error and some wierd(for me) values of port registers: serr - 0x4050000, tfd - 0x80

You're receiving IRQ11. You've configured the PICs to map IRQ11 to interrupt vector 0x2B.


PCI IRQs are level-triggered. If you send an EOI without acknowledging the IRQ in the AHCI HBA, you will immediately receive another interrupt.


PxTFD indicates you sent a FIS to the drive and the HBA is waiting for the drive to respond. PxSERR doesn't show any errors, but it does say the SATA link state changed since the last time it was cleared.

It sounds like the drive doesn't think it needs to respond to the FIS you're sending.

Understood, thanks



can it be caused by non handled interruptions from HBA and what I should do in this situation?

EDIT: I added interrupt handler, and noticed that on real HW the 0x80 of TFD register is set after some ms after controller reset and stay remain, i reset it using this code:

Okay, it’s looks like the reset busy stuff is likely controller specific. Okay, I still have few questions about hard drives, a specially: I currently also writing PCI IDE driver and tests it on my notebook and virtual machines. So on VM the driver perfectly works, but on my notebook that use SATA controller IDE mode I got the IRQ10 interrupt and if I read the first successfully detected drive status register I got 0x7f. The read/write code works fine. So did anyone know why I got there interrupts and how correctly process there interrupts? Also i got there interrupts continuosly

AHCI is supposed to process commands completely automatically, so an unhandled interrupt shouldn't get in the way of command processing. There's probably still something wrong somewhere, but I've looked through your code a few times and haven't found the problem.

You don't need to enable all of the different AHCI interrupts if you're not sure how to handle them. Also, PCI allows interrupt sharing, so you need to check whether the interrupt is coming from your AHCI HBA when you handle it.


Usually that status means no drive is connected, but you may also see strange values if you're using DMA and not reading the status registers in the correct order. The PCI IDE specifications explain how your driver is expected to work with the hardware, although the explanations assume you're already familiar with legacy ISA IDE.


Without more information, it's impossible to say where the interrupts are coming from.


If you send an EOI to the interrupt controller before you acknowledge the PCI device, you will receive another interrupt. If you never acknowledge the PCI device, you will receive interrupts from it continuously.

Thanks for this information. About ATA, I think to post here about that to not create new topic, so after some verbose loging I can say that the interrupts fired from the SATA controller itself(or IDE controller because it’s in IDE mode) after sending IDENTIFY command. Also after reading the wiki about PCI IDE and IDE PIO I don’t fully understand how my driver must reply to there device IRQ. So can I do something based on this information? On QEMU the IRQ (0x2e) fired on IDENTIFY command too, but only one time

The interrupt is to tell you the drive is done processing the command. Read the drive's status register to acknowledge the interrupt and see what you need to do next.

Okay, my interrupt handler reads the status register, and this register is 0x58, and error register is zero, what I should do with this(because I really don’t get it). Writing back the status register doesn’t help, I still get the interrupt

There are no errors and the drive is ready for you to transfer data. Since you used the IDENTIFY DEVICE command, the drive is expecting you to read 512 bytes.


Did you read the status register before or after the EOI? You must read the status register before the EOI.

I rewrite the IRQ handler, so the EOI will sent after the IRQ handler exited, and still the same

Is another PCI device using the same IRQ? PCI IRQs can be shared.

After checking each PCI device IRQ line, the first IDE PCI device IRQ line used also by Signal Processing Unit and second PCI IDE device. So how I can correctly add the interrupt handler or what I must do in this situation?