[Solved] RTL8139 Ethernet driver hangs after packet incoming

[narke]

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:

Code: Select all

outw(rtl8139_device.io_base + ISR, status);

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:

Code: Select all

sudo qemu-system-i386 -m 32 -machine accel=kvm \
                           -cpu host \
                           -netdev bridge,br=br0,id=net0 \
                           -device rtl8139,netdev=net0 \
                           -cdrom aragveli.iso

To configure network bridging on Linux:

Code: Select all

narke@apex ~> cat /etc/qemu/bridge.conf 
allow br0

Code: Select all

narke@apex ~> sudo brctl addbr br0

To build:

Code: Select all

narke@apex ~> git clone https://github.com/narke/Aragveli.git

narke@apex ~> cd Aragveli/src/kernel/

narke@apex ~> make

[nullplan]

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.

[narke]

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.

[Octocontrabass]

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

[nullplan]

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.

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.

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.

[Octocontrabass]

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.

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

[narke]

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