Hello and sorry for the long delay! I was on vacation and I've started online courses, as well as my other busy day-to-day things, well, this was the first time I could get back and give a decent response
So, in reverse (it's easier to read from bottom up for a response):
modprobing a driver. When hardware is initialized, it doesn't necessarily mean it's "ready to go" in the sense that you should be online immediately afterwards. Best relation I can give is to cars. When you start a car, it can't immediately drive; you must do something else to make it go, put it into gear. So, putting your ethernet card into gear would be the equivilent of telling the dhcp server to give it a new IP. However, in your case, it didn't quite work right. Without exacts (and I realize you can't give exacts all the time since we are trying to get the NIC working, so just take that for what it's worth) it's hard to tell you what's wrong or what didn't happen.
modprobe sundance
this should load sundance and any required modules (mii) to get the card recognized by the kernel (dmesg will tell usually when something is recognized and intialized). However, this won't get you your connection to your router/ISP. That requires either a DHCP server response (typical setup) or a manual setup with the correct parameters (advanced or non-typical setup). Running:
dhcpcd eth0
Usually is enough to get the rest of the job done (putting the car in drive). Sometimes, something just doesn't work right, whether that be the DHCP server responding with "Hey, I already sent your MAC adress an IP and you ACK (acknowledged) it. Wait until it expires to get another" or some other problem in between the 2 devices. Taking the device down properly might make the problem pretty much go away, something like:
ifconfig eth0 down
modprobe -r sundance
modprobe sundance
ifconfig eth0 up
dhcpcd eth0
Might work.
Learning Linux, and learning networking, AND learning Linux networking all at once might be a bit daunting. Take my examples for what their worth, just pointers to help you figure this all out.
So, the cryptic info from Puppy is quite cryptic as you've noted, it's not the best info nor the info we'd hope to glean from lspci. Sometimes lspci can hate us, I'll usually just plop in a Knoppix CD at that point and see what I've actually got.
The modules look about the same. I'd guess that the problem may just be something really lame at this point, something as simple as eth1 being the devices instead of eth0. Try an:
To see if there are other ethX devices listed. It may even just be your device is querky enough to not have good support with all distros "custom" kernels. The really really funny (well, to me because I'm on this side of a working ethernet card
) thing is that I (or anyone else really) can't even ssh into your system to take a look around and get a feel for what's going on and remotely get it working. Then feed you the steps, and point out what happened...
A LiveCD is, for the sake of simplicity, not meant to be tweaked. It's meant to work on the
most amount of systems, with very little user interaction to get it working. In other words, with a LiveCD, if it doesn't work, it's going to be hell trying to get it to.
Now, how the kernel, modules, and compilers all come together:
The kernel source code contains thousands of .c programs. These programs are human readable, and need to be converted to machine readable. The compiler steps up the plate to do the conversion (binary) and the resulting file is a .o file (not 100% true, it's up to the developer, but is true in a lot of situations). Now, how this all fits into the different modules for different machines. Kernels (used here to also include kernel modules) are compiled for the
CPU the system is using. Different CPUs are capable of different executions, and some are backwards compatible, but most are not
foward compatible. So, loading a module for a CPU that is "lesser" or "different" than the CPU used to compile the module could cause the system to crash. You can build a module for a bunch of different systems, but then you add unnecessary bloat to that kernel, further slowing down a system (and for no reason at all). To add to all that, compilers are also finicky. Older compilers were created when older hardware existed. When new compilers come out, some of the previously compiled code may not work on newer hardware (and vise versa). In comes kernel module versioning. It keeps compiler versions (in the case of open source, typically GCC) used to compile modules, and hardware type used to compile modules, somewhat the same. It's in your kernel information:
And
You can see in your example above:
Code:
vermagic: 2.6.16 486 gcc-3.4
and
Code:
vermagic: 2.6.18.1 mod_unload 486 gcc-3.4
These were compiled for the kernel version 2.6.16 and 2.6.18.1 respectively, and both were for a 486-series CPU (or better), and both using the same version of gcc: gcc-3.4 So, in this example, the biggest difference is kernel version, and this is why you can't just copy a kernel from one distro to another. What I meant by "typically" is that depending on how the kernel source code is compiled, you actually can copy the module across distros, but it's really not a good idea to do it without an excellent reason; the system will very likely become unstable and it's very likely the module simply won't work anyway.
The kernel contains many (not all, but a good 90+%) modules (drivers) for various hardware. In some instances, you may need a newer kernel to support the newer hardware, but eventually, most driver code makes it's way into the kernel. It's a much easier way for you and I to find something we need to make our hardware work; one stop shopping. In rare instances (older kernels, rare hardware, new hardware, specialized hardware) we may need to go to the manufacturer, or some other location for a driver. In the case of non-open source drivers, we definitely have to go elsewhere as the kernel is released using the GPL. Nvidia is a prime example of this. It's an even better example because there are 2 types of drivers for NVidia graphic cards. There are open source drivers that are included as part of the xorg (xfree86) packages, and there are the closed source drivers from Nvidia.com that allow you to take advantage of special features of a card such as hardware video acceleration (XvMC), or using multiple monitors from the graphics card's multiple outputs.
Yes. Ha, to which point
Yes, it's possible something changed after the 2.6.16 kernel was released that made it work better on the NIC you have. This would make sense to a point, especially when puppy's 2.6.18.1 kernel works. However, the code you received with the card should work with your hardware. But there are a slew of possible reasons it doesn't, and none of them are going to be easy to identify. Your best 'chance' of finding out where the ball got dropped would be by installing multiple distros with different kernel versions (the same distro would of course be the best scenario). This would allow you to test each kernel release to see where the problem occurs, or if it just lies in Slax specifically. If that becomes the case, it may just be a simple oversight (aka bug) and an email to the author with your findings is usually welcomed.
Doing a google on your hardware, sundance appears the way to go. You may just have to try out another kernel version and go from there. If you are dying to use Slax, you should read up on how to remaster a LiveCD. Get the new kernel working to your needs and replace it on the LiveCD and remaster your own. It's a lot work, but a lot knowledge is gained from the experience; the most helpful of which will be kernel compiling and option selecting.
Good luck!
Cool
