Opened 10 years ago

Closed 3 months ago

#2801 closed bug (fixed)

rtl8169 stops responding after a while

Reported by: tqh Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Network/rtl81xx Version: R1/pre-alpha1
Keywords: Cc: umccullough@…, fredrik.holmqvist@…, alienglaude@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Change History (18)

comment:1 Changed 10 years ago by axeld

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

comment:2 Changed 10 years ago by tqh

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

comment:3 Changed 10 years ago by umccullough

Cc: umccullough@… added

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

comment:4 Changed 10 years ago by tqh

Cc: fredrik.holmqvist@… added

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.

comment:5 Changed 10 years ago by 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...

comment:6 Changed 9 years ago by tqh

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

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by tqh

Resolution: fixed
Status: newclosed

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

comment:9 Changed 9 years ago by phoudoin

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

comment:10 Changed 9 years ago by 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.

comment:11 in reply to:  10 Changed 9 years ago by 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 ;-)

comment:12 Changed 9 years ago by tqh

Resolution: fixed
Status: closedreopened

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

comment:13 Changed 9 years ago by 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.

comment:14 Changed 9 years ago by 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?

comment:15 Changed 7 years ago by diver

Component: Drivers/NetworkDrivers/Network/rtl81xx

comment:16 Changed 5 years ago by AlienSoldier

Cc: alienglaude@… added

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.

Last edited 5 years ago by AlienSoldier (previous) (diff)

comment:17 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: reopenedassigned

comment:18 Changed 3 months ago by waddlesplash

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.