I have a HP Omnibook 500 with a 3Com 556B miniPCI ethernet/modem combo. Try
as I might, I can't seem to get the card to connect to the network. My
question is, how do I figure out what is the problem here? At this point, I
do not know if the card or the kernel is at fault. Please CC me as I am not
subscribed to the list.
Thanks for your help,
Rahul
P.S. This is on RedHat 7.2 with kernel 2.4.9-31. Please let me know if I
should upgrade to the stock kernel.
Here is the output from "modprobe 3c59x debug=7":
Mar 19 22:24:30 quicksilver kernel: Enabling bus-master transmits and
whole-frame receives.
Mar 19 22:24:30 quicksilver kernel: 00:0b.0: scatter/gather enabled. h/w
checksums enabled
Mar 19 22:24:30 quicksilver kernel: eth0: Media override to transceiver 8
(Autonegotiate).
Mar 19 22:24:30 quicksilver kernel: eth0: MII #0 status 7849, link partner
capability 0001, info1 0010, setting half-duplex.
Mar 19 22:25:58 quicksilver kernel: eth0: vortex_error(), status=0xe081
Mar 19 22:26:30 quicksilver dhcpcd[1634]: timed out waiting for a valid DHCP
server response
The following is the output from vortex-diag:
[root@quicksilver root]# ./vortex-diag -af
vortex-diag.c:v2.05 5/15/2001 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a 3c566 Laptop Tornado adapter at 0x1400.
Initial window 7, registers values by window:
Window 0: 0000 0000 e720 0000 0000 01f5 00aa 0000.
Window 1: 0000 0028 0700 0000 0000 007f 0000 2000.
Window 2: 0400 4d76 3fda 0000 0000 0000 0000 4000.
Window 3: 0040 0080 05ea 0000 0040 1000 0800 6000.
Window 4: 0000 0000 0000 0050 0003 8000 0000 8000.
Window 5: 1ffc 0000 0000 0600 0805 0000 06c6 a000.
Window 6: 0000 0000 0000 0000 0000 0000 0000 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x1400
0x1410: 00000000 00000000 00000093 00000000
0x1420: 00000020 00000000 00080000 00000004
0x1430: 00000000 3ef5c10b 00000000 00080004
Indication enable is 06c6, interrupt enable is 0000.
No interrupt sources are pending.
Transceiver/media interfaces available: MII.
Transceiver type in use: Autonegotiate.
MAC settings: half-duplex.
Station address set to 00:04:76:4d:da:3f.
Configuration options 0000.
Finally, mii-diag:
[root@quicksilver root]# ./mii-diag -v
mii-diag.c:v2.03 11/5/2001 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x7849 ... 7849.
Link status: not established.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
End of basic transceiver information.
MII PHY #0 transceiver registers:
3000 7849 0022 561b 01e1 0001 0004 2001
ffff ffff ffff ffff ffff ffff ffff ffff
01c0 0000 0000 8020 4f02 0304 0026 0000
0000 bfbf 0000 ffff ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x7849 ... 7849.
Link status: not established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 00:08:95:--:--:--, model 33 rev. 11.
Vendor/Part: AdHoc Technology AH101LF.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0001:.
Negotiation did not complete.
TDK format vendor-specific registers 16..18 are 0x01c0 0x0000 0x0000
Link polarity is detected as normal.
Auto-negotiation complete, 10Mbps half duplex.
Rx link in fail state, PLL locked.
No new link status events.
Rahul Karnik wrote:
>
> I have a HP Omnibook 500 with a 3Com 556B miniPCI ethernet/modem combo. Try
> as I might, I can't seem to get the card to connect to the network. My
> question is, how do I figure out what is the problem here? At this point, I
> do not know if the card or the kernel is at fault. Please CC me as I am not
> subscribed to the list.
>
Seems that link negotiation didn't go right.
> Mar 19 22:24:30 quicksilver kernel: eth0: Media override to transceiver 8
> (Autonegotiate).
How did you manage to get this message to come out with a modular
driver? Are there other driver options in modules.conf?
First-up you should avoid using any special negotiation and
transceiver options and just let the card work it out.
> ...
> Transceiver type in use: Autonegotiate.
> MAC settings: half-duplex.
Do you expect half-duplex?
> ...
> Able to perform Auto-negotiation, negotiation not complete.
> ...
> Link partner capability is 0001:.
> Negotiation did not complete.
Lots of bad things there. Remove any special options, then
re-run mii-diag and vortex-diag. If your cables and peer
are behaving then you should see happy output indicating the
desired duplex, speed and negotiation status.
If it still doesn't work, try statically assigning the IP
address (get rid of DHCP somehow). There were some workarounds
in later drivers for strange interactions between some hardware
combinations and some DHCP clients.
If it *still* doesn't work then it's time to sniff the connection
and try to see those arp messages.
And try different cables, different link peers.
And try another you-know-which operating system. If that works OK
then we know the hardware's good.
-
Andrew,
> How did you manage to get this message to come out with a modular
> driver? Are there other driver options in modules.conf?
I used modprobe 3c59x options=8 debug=7, as recommended by you (or maybe
Bogdan) on the vortex mailing list. This was after I had tried it without
the options argument.
>> Transceiver type in use: Autonegotiate.
>> MAC settings: half-duplex.
>
> Do you expect half-duplex?
Nope, it is connected to a Linksys BEFSR41 4-port 100Mbps router, and my
desktop connects at full-duplex to the same router.
> Lots of bad things there. Remove any special options, then
> re-run mii-diag and vortex-diag. If your cables and peer
> are behaving then you should see happy output indicating the
> desired duplex, speed and negotiation status.
As I stated above, I tried the special options only after I was not able to
connect without them.
> If it still doesn't work, try statically assigning the IP
> address (get rid of DHCP somehow). There were some workarounds
> in later drivers for strange interactions between some hardware
> combinations and some DHCP clients.
Tried this, it did not help.
> If it *still* doesn't work then it's time to sniff the connection
> and try to see those arp messages.
How would I do this?
> And try different cables, different link peers.
I am able to connect successfully with a 3Com Cardbus card to the same
router , using the same cable.
> And try another you-know-which operating system. If that works OK then
> we know the hardware's good.
This would be my last effort, but I am afraid it might be my only option. At
this point, the link light never comes on, and I am afraid that I might have
installed the card incorrectly. OTOH, there seem to be several unresolved
bug reports regarding this card on the vortex mailing list, where the card
works correctly with Windows but not under Linux. Do we know of people using
this card (the 3C556B version, not the vanilla 3C556) successfully?
Thanks for your help, and please let me know if you need any other
information.
-Rahul
Andrew,
> And try another you-know-which operating system. If that works OK then
> we know the hardware's good.
Finally bit the bullet and installed Windows 2000 on the laptop. Now the
card works fine. This means the hardware is good (Thank God!), and that the
vortex driver needs to be fixed.
By the way, I contacted some of the other people who noted similar behavior
with this card on the vortex mailing list and they confirmed that their
problems continue. Being a developer, I would really like to ditch the
Windows install; how can I help debug this problem?
Thanks,
Rahul
Rahul Karnik wrote:
>
> Andrew,
>
> > And try another you-know-which operating system. If that works OK then
> > we know the hardware's good.
>
> Finally bit the bullet and installed Windows 2000 on the laptop. Now the
> card works fine. This means the hardware is good (Thank God!), and that the
> vortex driver needs to be fixed.
>
> By the way, I contacted some of the other people who noted similar behavior
> with this card on the vortex mailing list and they confirmed that their
> problems continue. Being a developer, I would really like to ditch the
> Windows install; how can I help debug this problem?
Well, please work off current 2.4.18/2.4.19-pre kernels.
Apply http://www.zip.com.au/~akpm/3c59x.patch so that
we're in sync.
Have a BIOS fiddle - disable any power management options,
disable APM/ACPI in kernel config, etc.
Then please go through the steps in the final section of
vortex.txt and send me all the output.
The 556 and 556B documentation has never been sighted,
but it's probably something silly. Also please send
me the `lspci -vvvxxx' output when the card is fully
initialised, so I can compare it with my 556b.
Thanks.
-