rtl8169 stops responding after a while

[tqh]

rtl8169 driver stops receiving data after 5-10 mins. Usually it can be resolved by ifconfig down/up but sometimes it reports 'device busy'.

Pinging while this happens: Checking ints in debug I see rtl is alone handling int10 and it seems to continue to handle interrupts as number of handled interrupts increases and still no unhandled.

This is a gcc4 built Haiku, currently hrev27864

[axeld]

Can you try if this also happens with a GCC2 build?

[tqh]

Tested a gcc2 build (with gcc4 libs) of hrev28839 and it seems to be the same there.

[umccullough]

My rtl8168 chip using this driver also seems to experience the same issues.

[tqh]

I enabled debug in the driver, but all I can see is that writes start to timeout 'rtl8169_write timeout' or similar. Otherwise it's mostly read write read .. and so on. Dunno how to track this down or test this so ideas welcome.

[phoudoin]

My rtl8168 doesn't stay stable while connected with a gigabit switch: link goes up & down. Timeout start to occurs, and all network access stall.

When connected to a fast ethernet switch, it's stable and works as expected. Maybe it's related. When PHY start to goes up & down it's no surprise network doesn't work as it should in such condition...

[tqh]

I'll see if that is the case for me as well.

[tqh]

It looks like it is FIFO overflow problems. At least it prints a lot of INT_FOVW, and by cross-refing with the FreeBSD driver I can see that it is described as:

#define RL_ISR_FIFO_OFLOW       0x0040  /* 8139 only */

I wonder why it says 8139 only though.

[tqh]

This should probably be fixed by hrev34667. Reopen if not.

[phoudoin]

I will connect my rtl8168 back to a gigabit switch to see if the issue remains or not.

[tqh]

It might be that you and I have different issues if it still behaves that way. So far I havn't had any more networking problems.

I think that enabling debug in the driver and turn of those read/write messages will let yoi see what happens at the driver level quite easily.

[phoudoin]

Replying to tqh:

It might be that you and I have different issues if it still behaves that way. So far I havn't had any more networking problems.

it's confirmed, I've a different issue: when connected on Gigabit switch, the link is still not stable. But in Fast Ethernet mode, it now works stable as a rock.

Well, fast ethernet is named fast for a reason, who am I to ask for gigabit anyway ;-)

[tqh]

I'm still seeing FIFO overflow interrupts after a while, even though it takes much longer. Not sure why that is.

[tqh]

This is on hrev35882 and I'm pretty sure it's something with the driver. I added

    write8(REG_TPPOLL, read8(REG_TPPOLL) | TPPOLL_NPQ);

under

  if (stat & (INT_TOK | INT_TER)) {

as FreeBSD states that some chips (PCIe) will ignore a second TX request while in progress, but it didn't help that issue, although it seemed to helped with very slow responses I have sometimes, often to the webkit nightlies.

[tqh]

Documentation suggest poor pci performance, pci bus overloaded or Rx descriptor unavailable. I wonder if this might give a hint for the other similar bugs for other network cards.

How would one measure the first two cases?

[AlienSoldier]

My main PC have that card (a P4 if that matter). I never tested much haiku on that one before so i don't remember if it did this in the past.

I not just have the card stop (i was not able to completely download an haiku image from haiku files). While it is downloading everything seem normal, then it freeze solid the whole PC. The only thing that remain is the picture on the screen froze in time. If music is playing at the same time it can loop a very annoying small sample. On some occasion it froze just loading a website. It froze with webpositive and also wget, so it is not browser related.

I changed the card for a realtek 8139 and it never have that problem.

With R5, the rtl8169 never gave me any problem.

[waddlesplash]

rtl8169 is now supported by FreeBSD's rtl81xx driver, not our own rtl8169 driver, so this is fixed now.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone