OSDev.org

Hi osdevers,

I've got a problem while coding a driver for RTL8139 Ethernet card.
The thing is that after receiving a packet when I am acknowledging the reception I got an exception of type "Segment not present."
If I decoded the error correctly it means that there is a mess up in the IDT, but I don't know why. RTL8139's IRQ number which I read from PCI configuration space is 11 and I add to it 32 (in irq managemet routine, https://github.com/narke/Aragveli/blob/ ... /irq.c#L45), 11+32=43 but in the error message it seems that there is an issue with an IDT entry 47, I don't know why.

This all happens when the following line is being executed:

https://github.com/narke/Aragveli/blob/ ... 8139.c#L57
Here status is always 1.

Here is the source file for the driver: https://github.com/narke/Aragveli/blob/ ... /rtl8139.c

You will not see mapping() because I use flat space memory organization without paging for the moment.

I debugged it for hours but I think that I am not seeing a little detail that you me see obviously.
I will be very grateful for an advice.

I run the .iso image with:


To configure network bridging on Linux:







To build:

I could not see anything oviously wrong with your code, which means the code is non-obviously wrong So, what could it be? "Segment not present" sort of hints at a problem with the P bits. So in your case, maybe dump the gate descriptor from the exception handler? I dislike bitfields because I never know how they're going to be laid out in memory, which is sort-of important for CPU structures.

Another thing that occurred to me, is that the exception has the same number as the IRQ. But if it were a misdelivery, you would not get an error code. At least not one that fits your situation, so I guess that's not it.

The 'P' bit is active in IDT descriptor and there the fact that the exception number and the IRQ are same is just a coincidence. I would be very thankful if someone has any idea.

Set up an interrupt handler and see if it's a spurious IRQ.

That can't be it. Spurious IRQs, also known as "default IRQ 7" in the PIC datasheet, only happen in IRQ 7 (or IRQ 15 for the second PIC), and they trigger an IRQ, not an exception.



Did you confirm that with a memory dump? And yes, I know it is just a coincidence. But what if your second PIC somehow thought its interrupt base was 8? You would almost exactly see the behavior you have, except of course that that would not push an error code. I think, at least. External interrupt in the exceptions is undefined behavior, technically. It might just push whatever segment selector was on the CPU's mind.

Right, but only when the IDT entry for that IRQ is valid. When the IDT entry is marked not present, it causes an exception.

nullplan and Octocontrabass, you are geniuses!
In fact I was sending an EOI before calling the interrupt handler and thus before clearing the PCI interrupt status.

Thank you very much, it now works!

This is an interesting topic about the order of handling PCI interrupts and EOI sending: viewtopic.php?f=1&t=32320