ata interrupt routines

[blackoil]

Hi, all.

when I do a ata_read_sector(), the code stops at "hlt' instruction to wait for the sector data. If a keyboard interrupt occurs, then after keyboard iret, will PC be back to the ata "hlt" instruction?

Code: Select all

ata_read_sector:
{
...    // some inits.
hlt    // wait for the ata interrupt.
...    // get data.
}


kb_interrupt:
iret
ata_interrupt:
iret

[bluemoon]

You should read the manual for the HLT instruction, the exact behavior is well documented.

[blackoil]

I use this hlt method, it works fine though, I can read/write sector data. But I am not 100% sure it is safe.
I test it in BOCHS, but I can't remember If I tried in real machine before, the test machine is broken now.

My thought is:
When stops at ata hlt instruction, if kb interrupt occurs, the cpu goes to kb interrupt routine, then back to ata hlt instruction with kb iret.
because kb interrupt has higher priority.

[Nable]

> My thought is:
"Assumption is the mother of all fsckups".

Just read the manual, because this is the case when giving exact answer is a bad thing (in context of learning).

[blackoil]

I read the document, the document says the EIP points to the next instruction after HLT, whichever interrupt comes.
Of couse you can use classic method to deal with interruption routines.

I just want to try the "HLT" method here, if it does't work, how to explain the correct ata sector data, instead of garbage one.

[bluemoon]

If the manual is not clear enough, HLT will resume the core upon _any_ interrupt (and some other cases).
So, after HLT you need to check the cause (or validate ata status), you may not assume the core is awake due to something is read from ATA.

how to explain the correct ata sector data, instead of garbage one.

It work (in some case) does not mean it has no bug; say, if a timer interrupt happen at the right time you may get garbage.

[blackoil]

It looks like there's no ata IRQ asserted, HLT state is waked up by other IRQs, but the ata device finished the data.

[blackoil]

I found the cause: I set the wrong bits in secondary 8259PIC for ata devices, in REVERSE order.
It's verified with HLT instruction and only ATA IRQ enabled.