Red Hat Bugzilla – Bug 167331
via-rhine link down never up again
Last modified: 2007-11-30 17:11:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
if for any reason (i.e. I turn off the switch) the link goes down, the only way of making it come up again is to 'rmmod via-rhine; modprobe via-rhine'
It did not happen with fc3 and does not happen on other machines with identical SW but different eth card.
PS: reporting this bug has been a real show-stopper, at every page firefox-1.0.6-1.1.fc4 has given me the warning 'error in encrypted connection to www.redhat.com: -5990' and it took 10 secs (timeout ?) to load each page! On top left sidebar was wrong! My problem???????
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. turn off the switch or disconnect eth cable
2. turn on the switch or reconnect the eth cable
3. link does not come up, no packets in/out eth
Actual Results: link come back up, packets exchanged
Expected Results: no traffic
running '2.6.12-1.1447_FC4 #1 Fri Aug 26 20:29:51 EDT 2005 i686 athlon i386 GNU/Linux', fully updated fc4, with dmesg output
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKG] -> GSI 5 (level, low) -> IRQ 5
eth0: VIA Rhine II at 0xed800000, 00:0c:6e:db:8d:85, IRQ 5.
eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
Re: PS. I think I understood what is wrong with firefox-1.0.6-1.1.fc4 and
https://bugzilla.redhat.com/ In firefox I had set "Use OSCP to validate only
certificates that specify an OSCP service URL" but at the same time I use a
proxy to reach internet. https://bugzilla.redhat.com/ specifies an OSCP service
URL, which is 22.214.171.124:80 but firefox tried to reach it directly and NOT
through the proxy! Indeed if in firefox I digit http://126.96.36.199 I get to
the OSCP responder thorugh the proxy, but if I try https://bugzilla.redhat.com/
the firewall stops the direct connection. I'll see if to file a bug to firefox.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
Sorry but the bug is still there. Exactly the same behaviour with
2.6.13-1.1526_FC4, so BUG STILL OPEN.
I have the feeling that it is something that has happened between kernel 2.6.11
Let's start with an update to the current upstream via-rhine driver. Test
kernels w/ such an update are available here:
Please try those and verify that the problem still exists there...thanks!
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Something has changed, with 2.6.14-1.1637_FC4 via-rhine checks if the link is up
only when you start the module, so if at boot the link is up, via-rhine never
realizes if later it goes down/up ecc., and if at boot the link is down, it will
remain down until your rmmod and then modprobe again the module. Before it was
going down, but never up again, I do not know what is better :-)
It almost seems like your interrupts aren't being properly routed. Have you
tried booting w/ "acpi=off" or "acpi=noirq"?
Tried with "acpi=off", "acpi=noirq" and "pci=routeirq", nothing!! Still does not
On the other side, I guess you are pointing to the right direction since also
some hot-pluggable things are not working as expected since kernel-2.6.12,
everything was working correctly with kernel-2.6.11 (for example, sometimes when
I insert a dvd or a cd it does not start playing automatically as if it has not
realized I put it in, and so on; but these cases are more random, sometimes it
works, other it doesn't). It could be a hw/sw interaction, but what leaves me
more puzzled is that up to kernel-2.6.11 included, everything was working perfectly.
Hmmm...well, it might be worthwhile for you to attach the output of running
"sysreport" on the box in question.
Also, what kind of system/motherboard is it? Thanks!
Created attachment 121354 [details]
If it is good for you, I attach:
most interesting should be lspci and dmesg. System is
AMD Athlon(TM) XP 2000+
Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
Subsystem: ASUSTeK Computer Inc. A7V8X-X Motherboard
Created attachment 121355 [details]
Created attachment 121356 [details]
Created attachment 121357 [details]
Created attachment 121358 [details]
Created attachment 121359 [details]
Are you forcing the link configuration? Could you attach the output of
running ethtool on the link in question? Thanks!
Yes: in /etc/sysconfig/network-scripts/ifcfg-eth0 there is
ETHTOOL_OPTS="speed 10 duplex half autoneg off"
~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: No
Supports Wake-on: pumbg
Current message level: 0x00000001 (1)
Link detected: yes
Created attachment 122962 [details]
Test kernels w/ the above patch are available here:
Please give those a try and post the results here...thanks!
OK, now it works again! Thanks Andrea
PS. Will this patch go in the vanilla kernel sooner or later?
I expect that it will. I'll certainly post it, probably in the next few days.
Thanks for the testing!
Patch posted to firstname.lastname@example.org on 1/24/2006...sorry for the delay!
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Re-posted patch to email@example.com on 2/9/2006, with long rebuttal to
previous rejection...cross your fingers...
Well, my patch was never accepted. But, someone else posted a patch aimed at
fixing the same problem. I have incorporated it into the FC4 test kernels at
the same location as in comment 21.
If you are still using FC4, please give them a try and post the results here.
Otherwise, please let me know which release (FC5, rawhide) and I'll try to get
some appropriate test kernels posted as soon as possible...thanks!
Sorry, I switched all my boxes to FC5. If you can prepare a kernel for FC5 I
will test it, no problem. Andrea
FC5 test kernels available here:
Just manage to test it. It works fine, all OK. Andrea