Opened 15 years ago

Closed 5 years ago

Last modified 4 years ago

#2801 closed bug (fixed)

rtl8169 stops responding after a while

Reported by: tqh Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: Drivers/Network/rtl81xx Version: R1/pre-alpha1
Keywords: Cc: umccullough@…, fredrik.holmqvist@…, alienglaude@…
Blocked By: Blocking:
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 (19)

comment:1 by axeld, 15 years ago

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

comment:2 by tqh, 15 years ago

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

comment:3 by umccullough, 15 years ago

Cc: umccullough@… added

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

comment:4 by tqh, 15 years ago

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 by phoudoin, 15 years ago

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 by tqh, 14 years ago

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

comment:7 by tqh, 14 years ago

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 by tqh, 14 years ago

Resolution: fixed
Status: newclosed

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

comment:9 by phoudoin, 14 years ago

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

comment:10 by tqh, 14 years ago

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.

in reply to:  10 comment:11 by phoudoin, 14 years ago

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 by tqh, 14 years ago

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 by tqh, 14 years ago

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 by tqh, 14 years ago

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 by diver, 12 years ago

Component: Drivers/NetworkDrivers/Network/rtl81xx

comment:16 by AlienSoldier, 10 years ago

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 10 years ago by AlienSoldier (previous) (diff)

comment:17 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: reopenedassigned

comment:18 by waddlesplash, 5 years ago

Resolution: fixed
Status: assignedclosed

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

comment:19 by nielx, 4 years ago

Milestone: R1R1/beta2

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

Note: See TracTickets for help on using tickets.