Hi,
we've a couple of different systems here that all experience the same problem - Network cards get configured correctly during the install but when you reboot, the devices get re-detected every time. We've been able to reproduce the problem with the KT600 integrated VIA-Rhine and realtek 8139 cards.
I've looked at the issue quite a bit and the problem seems to be that the ioctl calls for the hwaddress detection fail if the interface is not up. You can verify that by booting the system in single user mode, loading the drivers by hand and then run kudzu. it will try to reconfigure the device. Ignore that. Then use ifconfig to up the device (no IP required) and then rerun kudzu.. it should work this time - at least on the 2 cards I've tried that fixed the problem.
The code that acutally fails is in kudzu.c getNetInfo (790-810). I've no problems fixing it and sending in a patch but to do so I'd like to
A) Know that this really is the issue and if it happens on other cards. B) The best way of fixing this. I see several options... 1) Have a list of drivers (the driver is known at that time) that can't handle this ioctl call and then just not detect the hwaddress 2) Have a list of drivers and just bring the interface up if it isnt 3) Just simply gracefully fail and make an entry in the netdev list that is returned by getNetInfo with a special null entry for the hw address and then modify the compareDevices code to handle that special value.
Any input/ideas?
Peter.
On Friday, May 14, 2004, at 03:21 PM, Peter Arremann wrote:
Hi,
we've a couple of different systems here that all experience the same problem - Network cards get configured correctly during the install but when you reboot, the devices get re-detected every time. We've been able to reproduce the problem with the KT600 integrated VIA-Rhine and realtek 8139 cards.
I've looked at the issue quite a bit and the problem seems to be that the ioctl calls for the hwaddress detection fail if the interface is not up. You can verify that by booting the system in single user mode, loading the drivers by hand and then run kudzu. it will try to reconfigure the device. Ignore that. Then use ifconfig to up the device (no IP required) and then rerun kudzu.. it should work this time - at least on the 2 cards I've tried that fixed the problem.
The code that acutally fails is in kudzu.c getNetInfo (790-810). I've no problems fixing it and sending in a patch but to do so I'd like to
A) Know that this really is the issue and if it happens on other cards.
I'm not sure about Fedora, but I have 10 machines that I installed RHEL clones ( Whitebox & Tao) on, they experience this same problem, not a single machine is identical, though there are many similar cards (at least similar modules ie realtek etc..) I've turned kudzu off because of this.
I didn't know fedora had this same problem. I had a couple machines as fedora, and still have one dev machine as it though it has been off for quite awhile because of other priorities.
On Friday 14 May 2004 19:01, Nathanael Noblet wrote:
I'm not sure about Fedora, but I have 10 machines that I installed RHEL clones ( Whitebox & Tao) on, they experience this same problem, not a single machine is identical, though there are many similar cards (at least similar modules ie realtek etc..) I've turned kudzu off because of this.
I didn't know fedora had this same problem. I had a couple machines as fedora, and still have one dev machine as it though it has been off for quite awhile because of other priorities.
Hi,
I've the same problem with kudzu on Centos (RHEL 3.0 respin) and Fedora... This list is just listed as the right place to ask on the kudzu webpage :-)
Peter.
On Fri, May 14, 2004 at 06:21:39PM -0400, Peter Arremann wrote:
the drivers by hand and then run kudzu. it will try to reconfigure the device. Ignore that. Then use ifconfig to up the device (no IP required) and then rerun kudzu.. it should work this time - at least on the 2 cards I've tried that fixed the problem.
Gak.. does lspci -vxx show the cards are in D3 (sleeping) state at this point (post the dump for the chip please). Could be there are cases where we need power management to turn on the chip before using it
Alan,
The chip we're looking at is a RealTek 8139... here is the lspci -vxx output you asked for on bootup (hacked the init script so it ran just before kudzu started).
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b800 [size=256] Memory at ee800000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00: ec 10 39 81 07 00 90 02 10 00 00 02 00 20 00 00 10: 01 b8 00 00 00 00 80 ee 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 20 40
Peter.
On Monday 17 May 2004 13:52, Alan Cox wrote:
On Fri, May 14, 2004 at 06:21:39PM -0400, Peter Arremann wrote:
the drivers by hand and then run kudzu. it will try to reconfigure the device. Ignore that. Then use ifconfig to up the device (no IP required) and then rerun kudzu.. it should work this time - at least on the 2 cards I've tried that fixed the problem.
Gak.. does lspci -vxx show the cards are in D3 (sleeping) state at this point (post the dump for the chip please). Could be there are cases where we need power management to turn on the chip before using it
-
Alan Cox -
Nathanael D. Noblet -
Peter Arremann