Knoppix using NatSemi DP83815 stopped working

Quote:

---

Originally Posted by H1ghlander

I've got an HP ZE5185 (2.4G P4, 512M, 20G drive, with the Nat Semi network port),
and I've got the same problem with the network, it just doesn't configure. Possibly, because
I'm on a shared 10mb network, maybe the autonegotiation isn't working, but the card
works on the same network in both XP and Solaris 9/X86 (with a non-sun driver)

---

You're right about it being an autonegoitation issue; when I picked through what had been done to the eeprom I found that the eeprom settings were in a configuration that would screw up autonegotiation. But it really didn't matter what network I tried it on; I ran it to a 10/100 switch that would have negoiated anything the NIC wanted to talk and it just couldn't work anything out. I also ran it into a 10 mbit hub that only runs at 10 mbit, and the NIC couldn't work that out either. Wouldn't talk to several other computers straight in with a cross over cable either. The notebook had talked to both the 10/100 switch and the 10 hub before running the Windows "security update". So I doubt in your case that you would find you connected any better on a different network, but if you poke around at the register level I'm pretty sure you'll find that autonegotiation isn't working right.

As to it working with both XP and Solaris, I'm not surprised. I think you'll even find that it works with some versions of Linux. What I believe is happening is this: The eeprom settings are now in a bogus default state. If the driver doesn't use the eeprom defaults but rather resets the registers to what it wants, the NIC will work. If the driver trusts the eeprom settings, then it will fail. Normally one would think you should trust the eeprom settings, after all, why have a way to configure the NIC in eeprom and then defeat it? That seems to be what Knoppix does at start-up, and when it does it the NIC fails. However, Windows XP overrides the eeprom settings (kinda like they knew they had been screwed up) and so it works fine. And things like the command sudo mii-tool -r also are designed to reset the NIC settings, so after a mii-tool reset most people seem to be able to get past this problem too. Solaris (and versions of Linux that work fine) might also bring up the NIC with it's own settings rather than the eeprom power up settings, or it might even be making a call to something like mii-tool to be sure the device is reset during boot, which would defeat the ability to use eeprom settings to configure the NIC, but would also also prevent update software from having a bad effect by screwing up the NIC (the eeprom would still get screwed over, but if the booting software resets the bad values the NIC still works). You give up the configuration ability that almost no one ever really uses for security from the attack against the eeprom.

It's also interesting to note that while the eeproms are getting changed to things that make no sense for the chipset, the MAC address (also stored in that eeprom) never seems to ever get changed. Mine is certainly the same as it was when I first got the notebook (confirmed this from logs when I had the problem). Wonder why this would happen? My expectation is that the software screwing up the eeprom dare not mess with the MAC address, which it need too. And it better not store the MAC adress elsewhere and then muck up the eeprom AMC address, since a reinstall of the software would leave it without it's backup copy of the MAC address. So the eeprom MAC address is likely safe, but any other eeprom settings are targeted.

Not sure what's different between Knoppix and Morphix, but Morphix was able to configure the NS83815 (I'm using it right now). Maybe we can figure out what they're doing to make this work better.

Quote:

---

Originally Posted by Harry Kuhman

Quote:

---

Originally Posted by H1ghlander

I've got an HP ZE5185 (2.4G P4, 512M, 20G drive, with the Nat Semi network port),
and I've got the same problem with the network, it just doesn't configure. Possibly, because
I'm on a shared 10mb network, maybe the autonegotiation isn't working, but the card
works on the same network in both XP and Solaris 9/X86 (with a non-sun driver)

---

You're right about it being an autonegoitation issue; when I picked through what had been done to the eeprom I found that the eeprom settings were in a configuration that would screw up autonegotiation. But it really didn't matter what network I tried it on; I ran it to a 10/100 switch that would have negoiated anything the NIC wanted to talk and it just couldn't work anything out. I also ran it into a 10 mbit hub that only runs at 10 mbit, and the NIC couldn't work that out either. Wouldn't talk to several other computers straight in with a cross over cable either. The notebook had talked to both the 10/100 switch and the 10 hub before running the Windows "security update". So I doubt in your case that you would find you connected any better on a different network, but if you poke around at the register level I'm pretty sure you'll find that autonegotiation isn't working right.

---

Weirder yet, I booted 07/23 version on my HP ZE4100 (same kind of config, but builtin wlan and IGP-340 Radeon card). I thought it was hooked up to the switch, but it wasn't. I then connected it to the switch, and I now have connectivity
in Knoppix, once I told Knoppix what the appropriate network info is.

Quote:

---

Originally Posted by H1ghlander

Weirder yet, I booted 07/23 version on my HP ZE4100 .... I then connected it to the switch, and I now have connectivity in Knoppix, once I told Knoppix what the appropriate network info is.

---

That doesn't strike me as weird at all. It just sounds to me like a certain brand of evil software hasn't screwed your ZE4100 yet liike it did to your ZE5185. That's not to say that it will not; I ran my HP notebook for a while swapping between both systems and each worked fine. Then the Knoppix CD that always worked stopped working, as did other Knoppix CD copies I also had.

I would urge you to go to the website http://www.scyld.com/diag/ and get the nat semi diagnostics program and also the mii-diag program. Before you boot windows again on this system I would ask that you compile and run both of these programs with as many options as you can find (read the source to find all kinds of good options), and redirect all output to files that you can keep as a record. You'll be very very glad you have this information if the ZE4100 stops working later; you should be able to dump the eeprom settings now and reload them later. And this would certainly allow us to prove what is happening if you make note of when the problem first occurs (assuming, of course, if it does).

I would also say check closely if the two notebooks use the same chip. If it indeed does, you may be able to load the saved eeprom file into the ZE5185. And if you get this information, I would really appreciate it if you could send me a copy of everything; it might give me the information about the eeprom contents that I can't get from HP that would let me use the programs from www.scyld.com to reload my eeprom. And if I can get that working again I'll grab the new XP updates, and even reinstall all of the original software from the CD's that HP provided so that I can re-accept all of the "security updates" again and prove once and for all what is actually happening.

Of course, there could also be some BIOS issues that deal with the NIC differently in the ZE4100 than the ZE5185. I know my BIOS in my 4240 is extremely limited and more so than in many other HP Pavilion notebooks. I don't even have the "secret" diagnostics built into my system that many HP Pavilion notebooks do. Anything you can learn about the BIOS in each notebook might help too.

This output is from my ze4100 with the NatSemi DP83815 10/100 network running Knoppix 3.3 connected to a linksys 54G wireless router (though it's connected on a wired port). It came up the first time. I'll also post the results from my ZE5185 which had the problem next.


ethtool -e eth1

Address Data
------- ------
0x00 0x103c
0x01 0x002a
0x02 0x2cd0
0x03 0xcf82
0x04 0x0000
0x05 0x0000
0x06 0x0000
0x07 0x0007
0x08 0xf3b1
0x09 0xee74
0x0a 0xa098
0x0b 0xa355


hope this helps.

Here is the startup from my HP ZE5185, and connected to the same Linksys wireless router from the test with my ZE4100 (on the wired port, of course), the port did not start. This was booted cold, so no eeprom settings from XP may have been left over.


Initial "ethtool -e eth0"

Address Data
------- ------
0x00 0x103c
0x01 0x0029
0x02 0x2cd0
0x03 0xcf82
0x04 0x0000
0x05 0x0000
0x06 0x0000
0x07 0x0007
0x08 0xf2b0
0x09 0x8890
0x0a 0xa098
0x0b 0xf055


Initial "ifconfig eth0"


eth0 Link encap:Ethernet HWaddr 00:C0:9F:1A:22:12
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0x7000


did a "mii-tool -r; ethtool -e eth0"

restarting autonegotiation...

Address Data
------- ------
0x00 0x103c
0x01 0x0029
0x02 0x2cd0
0x03 0xcf82
0x04 0x0000
0x05 0x0000
0x06 0x0000
0x07 0x0007
0x08 0xf2b0
0x09 0x8890
0x0a 0xa098
0x0b 0xf055


did a "netcardconfig" (selecting dhcp broadcast)


Sending DHCP broadcast from device eth0 OK.


these are the settings from "ethtool -e eth0" after the "mii-tool -r" and "netcardconfig"


Address Data
------- ------
0x00 0x103c
0x01 0x0029
0x02 0x2cd0
0x03 0xcf82
0x04 0x0000
0x05 0x0000
0x06 0x0000
0x07 0x0007
0x08 0xf2b0
0x09 0x8890
0x0a 0xa098
0x0b 0xf055


and I have a working interface after this procedure from "ifconfig eth0"


eth0 Link encap:Ethernet HWaddr 00:C0:9F:1A:22:12
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:6 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2131 (2.0 KiB) TX bytes:1648 (1.6 KiB)
Interrupt:11 Base address:0x7000


What's weird is I don't see any changes in the register settings, despite that once renegotiation is reset, it just works. Maybe the thing to do is check the settings vs the ZE4100 which does work from a cold boot, and has not had it's driver updated in XP. Again, this interface works in MorphixCombined-Gnome-0.4.x so perhaps there's something they're doing differently.

Quote:

---

Originally Posted by H1ghlander

... Maybe the thing to do is check the settings vs the ZE4100 which does work from a cold boot, and has not had it's driver updated in XP. ....

---

Yup, I would certainly get the information from the notebook that does still work, both to compair with this notebook (if you're sure they both use the same chip in the NIC) and also so you have it in case Windows does something to the working notebook someday. I would also suggest using mii-diag and natsemi-diag from http://www.scyld.com/diag/index.html and getting the rom values from both of these programs.

Check out the last post on page 3. That has the ethtool -e output from the ZE4100 which works correctly. There are definitely some registers that are different. However, I don't have a clue what those difference mean.

Quote:

---

Originally Posted by H1ghlander

Check out the last post on page 3. That has the ethtool -e output from the ZE4100 which works correctly. There are definitely some registers that are different. However, I don't have a clue what those difference mean.

---

I have the documentation for the DP83815 chip (available as a PDF from the Nat.Semi. site). I'll try to make some sense out of what your ZE4100 settings are telling us and contrast then to the other NIC. It may take me a few days to get to it and the documentation is 108 pages and most of that is setting up the nic registers (and somewhat cryptic to me), so please be patient and don't expect any answers tonight or tomorrow. I would still suggest that you also check what the other programs I mentioned above give you. I don't know why, but I got different results on my NIC from the differet tools. I'm more inclined to trust the other two tools, particularly the natsemi-diag that is made for a natsemi chip (but also the mii-diag) over ethtool when the programs do not agree.

What I really would like you to do if you are willing is to run the natsemi-diag on both notebooks with both the -e and -ee options (-ee seems to be needed to get the raw data, which is what we'll want to put back into the corrupted eeproms). The -e option will also give us an interpeted discription of what it thinks the eeproms are set for, which should be a big help. natsemi-diag does need to be run as root or with the sudo command prefix. And if you are brave you might want to try the -E option (which from reading the source code I find should do an "emergency rewrite" of the eeprom, which might resolve this for us.) Having the mii-tool -r work around, I haven't been brave enough to try this yet.

If we can get the eeprom values right again, then at power up the registers should be put in a valid mode. The National Semi NIC does work under Knoppix (as your ZE4100 shows and my 4240 did show before I ran the "security updates").

Quote:

---

Originally Posted by H1ghlander

......
these are the settings from "ethtool -e eth0" after the "mii-tool -r" and "netcardconfig"
.......

---

That ethtool -e is giving you different values after these commands makes think that it's not really giving us eeprom settings at all (which should not change) but rather register settings. Yes, the documentation says it should dump the eeprom, but then you would get the same values each time. This is a further reason why I trust natsemi-diag over ethtool.

Quote:

---

Originally Posted by H1ghlander

...What's weird is I don't see any changes in the register settings, despite that once renegotiation is reset, it just works. ......

---

OK, I misunderstood what you were saying in the last post, once I actually started picking through the sets of data you posted I see thay are all the same. That is not weird if indeed they are eeprom values (as claimed) and not registers. I don't know if you're looking at registers with another tool or if you are thinking these values should be the chip registers, but what we care about to fix the problem is the eeprom values. While I had to use the DP83815 documentation and the register contents to see that the NIC was not being set correctly to auto-negotiate (as best as I can tell from the documentation), what we really need to figure out is not a good set of register settings (which we could get by looking at the registers once we kick one of these nics into working again), but rather the eeprom settings that let the registers get set up right.

I'll try to make sense of these values, maybe they will make more sense for your notebook than they did for mine, but I'm still hoping you can get the settings as reported by the national semi diag program -ee command.

Quote:

---

Originally Posted by H1ghlander

This output is from my ze4100 with the NatSemi DP83815 .... I'll also post the results from my ZE5185 which had the problem next.


ethtool -e eth1

Address Data
------- ------
0x00 0x103c
0x01 0x002a
...

---

Actually, the mystery deepens after looking at your settings. The doc calls these first two words of data the Configuration subsystem. While you have a 103c here in both devices, (which the natsemidiag indicates is a vendor code) I have a 3c08 - but the Natsemidiag reports a 103c for me in the same location!!!

We don't seem to have any conflict in locations 02-06.

07-09 are for the MAC address, so this will be different for each device.

0a always seems to match for both of us.

0b contains the checksum, which includes the mac address so will be different for each of us.

That seems to indicate the only "strange" settings are the CFGSID or Configuration Subsystem Identification Register. How this is causing problems, or even if it is, is not clear yet. I'm still hoping that you will post the results from the -ee option on the natsemidiag program, which seems to get very different results looking at these same locations than the generic ethtool does.

Also, I quoted your above post because I wanted to ask about the eth1 reference. In your other posts you list eth0, as I would have expected and as I have been using. In this case you listed eth1. Is there a reason for this? Was it just a typo? Are you by any chance looking at a different NIC added to the notebook and not the original factory installed NIC?

Quote:

---

Originally Posted by Harry Kuhman

That seems to indicate the only "strange" settings are the CFGSID or Configuration Subsystem Identification Register. How this is causing problems, or even if it is, is not clear yet. I'm still hoping that you will post the results from the -ee option on the natsemidiag program, which seems to get very different results looking at these same locations than the generic ethtool does.

Also, I quoted your above post because I wanted to ask about the eth1 reference. In your other posts you list eth0, as I would have expected and as I have been using. In this case you listed eth1. Is there a reason for this? Was it just a typo? Are you by any chance looking at a different NIC added to the notebook and not the original factory installed NIC?

---

The ZE4100 has a miniPCI wireless and it seems to come up as eth0. I also found out last night as I was updating XP, that there was an update for the LanExpress (DP83815) controller, so I did not install it.

I installed MorphixCombined-Gnome-0.4.1, and did a bunch of configurations and apt-gets. I was able to find mii-diag as a dpkg, but can't find a natsemi-diag dpkg (though I admit to not looking too hard as I 'm not very familiar with Debian). If I can't find one, I'll have to apt-get the compiler and build it by hand. If you have a pointer, I can get the diags for the ZE4100 in the next day or so. I will have to play with the ZE5185 to get the register settings for that.

Quote:

---

Originally Posted by H1ghlander

If you have a pointer, I can get the diags for the ZE4100 in the next day or so.

---

The diags are at
http://www.scyld.com/diag/index.html

The diag I seem to have best results with is
ftp://ftp.scyld.com/pub/diag/natsemi-diag.c

Instructions for compiling are at the end of the C code.

No need to ap-get a compiler, it compiles fine from knoppix if you just type in the given line (of course, you have to mount the disk where you store the file as read/write first).

YESSS thanks for sudo mii-tool -r :)

it's working on my hp nx9005

Quote:

---

Originally Posted by nighty

YESSS thanks for sudo mii-tool -r :)

it's working on my hp nx9005

---

Thanks for that report. Did Knoppix networking ever work on that system? If so, do you know when it stopped working?

Just looked up the nx9005, looks like it has a couple of nice features that my hp notebook lacks (firewire and 2 PC card slots rather than the one I have). What did it set you back(and what currency if not US dollars)?

Here ya go.
.

/natsemi-diag -aa -f

natsemi-diag.c:v2.07 12/17/2002 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a NatSemi DP83815 adapter at 0x2400.
Natsemi 83815 series with station address 00:c0:9f:1b:ef:5c
Transceiver setting Autonegotation advertise 10/100 Mbps half and full duplex.
NatSemi DP83815 chip registers at 0x2400
0x000: 00000004 e805e000 00000002 00000000 00000000 00f1cd65 00000001 00000000
0x020: 210a72a0 d0f01002 00000000 00000000 210a71b0 10700020 00000000 00008000
0x040: 0080000a 00200000 40000004 00005cef ffff0004 3f3f3f3f 00000505 00000000
0x060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x080: 00003100 0000786d 00002000 00005c21 000005e1 000045e1 00000005 00002801
0x0A0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x0C0: 00000615 00000002 00000000 00000000 00000000 00000000 00000100 00000030
0x0E0: 00000000 000000bf 00000804 00008200 00000000 00000000 00000000 00000000
No interrupt sources are pending (00000000).
Receive mode is 0xc8200000: Normal unicast and hashed multicast.
Rx filter contents: c000 1b9f 5cef 0000 0000 0000 0000 0000

Hi Harry,
Long time since this thread was last used, but thought I would post to update. Knoppix 3.3 now seems to connect to the internet first time every time but only if I exit xp by clicking restart, and have the cd in the tray ready to boot.

Steve.

Quote:

---

Originally Posted by stevethayne

.....Knoppix 3.3 now seems to connect to the internet first time every time but only if I exit xp by clicking restart, and have the cd in the tray ready to boot.

Steve.

---

Hi Steve,

Glad to hear it's working better for you. In my case, on the notebook that once booted fine but stopped connecting to the 'net after a "security update", my situation changed in the other direction. Knoppix would hang completely for me on boot, blank screen, never finish. I couldn't use the newer versions for quite some time. Finally I found that if I used a combination of two cheat codes, noscsi and acpi=off, Knoppix would boot OK. Since the acpi=off also was one of the ways that I could get around the NIC setup issue in the past, this "fix" aslo lets me use the NIC, but it's certainly a pain to have to do each time I boot from CD. It's not clear to me why I now need the cheat codes, but it's certainly something in the newer Knoppix release (the old CD's boot fine, but, of course, the same old CD's that used to let me on the 'net without any extra steps still need the cheat codes or the reset trick to get the NIC set up right now).

Harry

This thread should be named natsemi & DP83815 network start failures. Previously, it was posted in this thread, "dmesg errors: NETDEV watchdog: eth0 transmit timed out." I think there is a large clue in this message.
I have experienced this problem on Compaq Presario 2190US with knoppix and gentoo live-cd's.
I have observed that even if the nodhcp option is entered on the command line, gentoo searches for a network assignment, as does knoppix.
I don't have time to prove it, but it appears to me the natsemi driver deserves first place for examination for the source of the transmit time out. And ifconfig, which does not actually bring up a timed out DP83815 eth0 fully, deserves a close second place. This problem is wasting a lot of people's time and deserves highlighting in installation documentation, in any case.

Quote:

---

Originally Posted by ol fart

I have experienced this problem on Compaq Presario 2190US with knoppix and gentoo live-cd's....

---

Wow, you found a pretty old thread. It could have been named a lot of things; if I were to go back and change it I think I would use something like "Knoppix can no longer use my NIC, but only after running a Windows security update". If you are interested in this topic you might want to also look at this thread where more of the problem has been discussed. I do not have a final fix for the problem and my HP notebook still has this problem with old versions of Knoppix. But newer versions seem to be doing their startup logic differently (I don't think they use the configuration logic stored in the eeprom any more) and I personally have no had this problem since about 3.8 and others don't seem to be posting about it.

Posts going away does not necessarily mean problems have gone away. It just means people have gone away.

Version 4 knoppix does not properly network on a presario 2190 using a westell 2200 set for connection always on and dhcp enabled or disabled, without IF passthrough. With or without static NAT. MS ME on the desktop connects regardless of these settings on the westell. It properly obtains an IP in the 192.168.1.1-253 range when DHCP is enabled. It does not have to be powered down between changes. If the westell is set for static NAT to 192.168.1.1 and DHCP is disabled, and the IP on the destop is changed to 192.168.1.2, the westell connects to the new IP but does not update the static NAT IP unless it is disabled and then enabled, when it shows the static NAT connection by hostname. In any case, the network card is not turned off. This cannot be said of the knoppix v4 implementation. DHCP does not properly obtain an IP or a lease from a westell 2200 and, on failure is interacting with the network card drivers and registers to cause yawns and deep sleeps. Maybe, after netcardconfig,

cat /proc/interrupts
/etc/init.d/net.eth0 zap
/etc/init.d/net.eth0 start

There are more than apic problems in the kernel cured by apic=off involved here. My beef is that ifconfig is not written to do a proper inventory of the state of the interface when invoked with the up command.

If I were not bound and determined to get away from MS, I would not tolerate a hundredth of this aggravation. I am going to the gentoo forums with this. Perhaps these specifics will assist someone. Best wishes to all here.

Glad someone raised this from the dead before I did :)

I have this exact NS DP 83815 network chipset and problem :( . It is on a HP xt4300 Laptop. I was hoping someone could help me out. I know this is a Linux forum, and I'm running NT5. I used all the versions of drivers I could find and a clean install on each. No dice. It gets assigned an IP address, and will not connect to anything (I am trying to connect directly to a cable modem via network cable). If I try to release or renew the IP in ipconfig, it returns an error saying it cannot connect to DHCP server. I have also tried E:\>work or I will punt you out the freaking window; but, that had nary an effect also. Won't even speak of the worthless phone techs who couldn't figure this out either. Any ideas? I'm on my last leg here