Hello,

New here, and new to Linux.

Using Slax KillBill Edition v 5.1.8.1 . Just downloaded and burned the live cd a couple days ago.

Nic is not being detected during boot.
Having to reboot back to Windows to be able to search for info on it, and to post here is a pain.

I have been searching around, looking for info on it, so I can learn how to fix it. I'm finding bits and pieces of info, but I still don't have a clear plan or outline of what to do.

First question: Is this a waste of time? For all I know it is impossible to fix, since the os is on a CD.
Or will the fix be something that I can run after booting, to find/config the nic?


Assuming it is do-able:
I could really use an outline of steps to take. I'm new, and am not getting any traction on working through this. I could use a rudder.

If it were you, what steps would you be taking?
Thanks


Some info that may be pertinent:
I believe the version returned by uname -r was
2.6.16.

Network interface card is
Encore 10/100m . Model number is ENL832-TX-ICNT.
w-w-w.encore-usa.com/product.php?id=5&lang
Fwiw, it works fine under Win98SE and Puppy Linux.

ifconfig returns info about lo only. Nothing about eth0.

ifconfig eth0 returns device not found.

dmesg |less and searched for eth .
Found nothing with eth0 .

lspci does find the card.

Puppy Linux found the card.
I remember sundance , fwiw.

At the above website for the nic, drivers are available for d/l. The linux driver is text files.

compat.h
crc32.h
ethtool.h
Makefile
mii.c
mii.h
readme.txt
sundance_main.c

I have never compiled anything, but I'm doing this to learn, so I'm game.... if that is the only solution right now.
However, I don't think anything is included with Slax to be able to do the compiling.


find / -name *sundance returns a few files. By the names of the directories and files, they might be drivers. or modules... I don't know the difference or what I'm talking about yet.


Looking forward to some replies, so I can get started with some direction. So far, I feel like I've just fumbled around. I'm hoping it is not impossible to fix with a live cd - it just can't be all that hard...

If you need more info, ask and I'll go get it. You might have to name the commands you want me to use.

Thanks

try:

as root

modprobe sundance

or

insmod sundance

Othewrwise, just use the knoppix live CD. Slack is ancient.

Ran modprobe -v sundance .

Appeared to run insmod and install two modules.
sundance
mii

I didn't see anything that, to me, would indicated errors.

Ran lsmod | less and saw both sundance and mii at the top of the list.

However ifconfig eth0 still reports device not found.

lspci still has a line in the report:
Ethernet Controller: Sundance Technology Inc: Unknown
Device 0200 (rev31)


Is it reasonable to think that the module I installed is the correct one for that nic?

If it is the right module, is there another step that I must perform, after using modprobe to install the module, and before I try ifconfig eth0 ?

What is the next step for me to do, to get this nic to be seen?

Thanks


Maybe it is. I don't know.

But I'm more interested in learning how to diagnose and work through things like this - so this is an opportunity.

Once you modprobe sundance, you'll want to type:
To see if the modules correctly worked with your NIC. 2.6.16 isn't that old, although you may have more luck with a newer kernel (or another Live Distro) simply because of what the newer kernel is made to support and what the distro creators choose to do with your hardware.

The steps I take when working with new hardware, specifically with new ethernet cards:

As root:
And look for anything ethernet. Usually something comes up, and as you noted, sometimes the device manufacterer will give you some really good info. In this case, the sundance driver sounds right. Then:

And then:
And finally:
sometimes it might rather be:
And then to get an IP from my DHCP server:
If dmesg doesn't report anything after modprobe, you probably won't get anything from ifconfig. You'll probably have to dig through google a bit, or read the kernel documentation.

Good luck!

And yes, I'll move your thread to the networking forum at your request to give it the exposure it deserves.

Cool

dmesg?
Ok, I'll try that shortly and see what it says.

But, I thought dmesg was for getting a report of bootup messages. Since you've mentioned it here, I must have gotten the wrong idea. Can you explain it a bit more?

I thought I was looking to see if the modules were installed when I ran lsmod again, after modprobe. I never considered looking at the output from dmesg.

Thank you for outlining. Apparently, I wasn't too far off track.

Good. I was loosing confidence in that. Thanks for commenting on it.

...

hmm.. ok.
I think I tried dhcpcd .
Although since ifconfig eth0 returned device not found, I'm thinking it is a moot point.
I'll try to remember that command for the future though. Thanks.

I haven't tried dmesg yet, but will soon.
But what about lsmod ? It DID show both
sundance and mii in it's output list,
after modprobe -v sundance.

Ahh... can you elborate? What am I searching for and/or looking for when reading?

Oh.

I was operating under the concept that everything was fixable - it was just a matter of knowing how to do it. This looked like it would be a good thing to learn how to do.

Thank you.
And thanks for taking time to reply too.

dmesg is updated anytime something changes on the system, similar to /var/log/messages. It's a great tool when working with new hardware or even just when plugging something into the USB port.

lsmod is used to identify the loaded modules, it's helpful to a point, but doesn't really indicate what hardware is actually being recognized and configured by the kernel when the module is loaded.

dhclient and dhcpcd are roughly the same thing, IIRC dhclient is just the newer name for the app. Either way, yeah, if dmesg doesn't throw up some friendly messages when sundance is loaded, there is no point in moving on. The sundance module might be the wrong one, check google and the kernel docs.

In your kernel source (or if you don't have it, download and untar it, and then in that kernel's source) you'll find a directory titled "Documentation". This little place is home to the documentation that applies to the kernel options. You would probably be looking somewhere in: (source)/Documentation/networking
However, if you don't find your modules listed, you may have better luck with a google.

It may or may not be worth your time to figure this out. It's not really a problem that you will have a lot while using Linux, but if you are planning on starting up a repair shop, or going to school, I guess this might be a decent way to prep yourself. As for using a different distro that "works" that's one way to help diagnose your problem. If it works with Knoppix, then you can begin comparing the differences in loaded modules, dmesg outputs, kernel versions, etc between the 2 distros to see where the difference lies. There is no wrong way to troubleshoot, assuming everything is legal

And I don't quite agree that everything is fixable, but I guess it depends on how deep you want to tread. If you are capable, I suppose anything is fixable; even if it means writing your own device drivers, applications, and possibly designing some modifications to the OS.

Cool

Well, even I never whip this module/driver/nic problem, I've learned something. :) Thanks.

ok. Thanks again... because that is exactly what I thought that lsmod did. Of course, I can't quote a source... I'm picking up little bits and pieces here and there, as I read what I can find. Linux seems to be like that. A little bit of info here, and a little bit there. :)

fwiw, dhclient returned command not found .

Did it.
(It is a real pain, exiting Windoze, rebooting with the Slax Live CD, trying, having to reboot to Windoze to be able to get here to read/post. THAT is why I really want to get the nic working, so I can proceed to experiment with whatever I'm reading at the moment regarding linux. )
Tried dmesg after modprobe -v sundance .

Found it. Well, I think I found where it logged the install of sundance. I didn't see anything that looked, to me, like an error.

Next, navigated with cd to a directory on my hard drive, and then did dmesg >> output.txt , so that I'd have it when I exited the live cd.

Here is the line from dmesg:
sundance.c:v1.01+LK1.10 28-Oct-2005 Written by Donald Becker
http://www.scyld.com/network/sundance.html

Next, tried ifconfig eth0 up .
Device not found.

ifconfig -a does not show anything like eth . :(

They would include a module with their distro that is incorrect?

... wait... on second thought... do you mean that it probably DOES work with their distro, but maybe with a different version of my nic?


Based on what I've reported so far....especially the lines in dmesg output... is that what you are thinking now? that the sundance module probably does work with my version of the kernel, but just doesn't work with my nic?


umm... what exactly am I googling for?
"linux driver kernel 2.6.16 enl832" possibly?
or.... ?

thanks... if you hadn't spelled it out, I would have had no idea what you meant, or where to look. I really don't know where to d/l the source, but I'll have a look around.

I'm a little confused here.
Wouldn't we expect to find sundance listed, since it is included with the distro?
I'm guess I'm not sure what I'm looking for as I'm reading in these docs.

:) only my own junk. I can't afford to pay somebody else to fix it.

nic seems to work fine with Puppy Linux Live cd. I can use the included browser and get around the web.

Where can I go to read up on what I would be looking for?
I mean... sure, I could spot a difference, but then what?... it wouldn't mean much to me yet.

Well... I do know that the versions are different between Puppy and Slax.
Puppy is 2.6.18.1 and Slax is 2.6.16
And I saw it again in dmesg. :)

I experimented.

Saved the sundance.ko and mii.ko files from my Puppy Live cd to the hard drive.
Rebooted with Slax.
Went to the /lib/modules/I can't recall the whole path/ directory where Slax holds both sundance.ko and mii.ko. They were different size.
Deleted both, and copied from hard drive the two files from the Puppy cd.
ran modprobe -v sundance again.
Fatal: ... invalid module format.

and, from dmesg:
mii: version magic '2.6.18.1 mod_unload 486 gcc-3.4' should be '2.6.16 486 gcc-3.4'

(Notice it didn't mention sundance? just the other one that always installs too, mii.
Btw, how would I find out what mii is ? )

Apparently modules from one version are rejected by another version? ... but, how did it know? ... something must be in those modules that is version specific... I wonder why....

That's just it. I need to know/learn what is involved, so I can decide if it is beyond my capabilities. That's what I'm hopign to get out of this conversation here in this forum. I thank you for your time... it is helping.

Writing code, if that is what you meant by writing device drivers, is beyond me. I'm not a programer.
Maybe someday I'll pick at it... but right now, it is beyond me.
If it comes down to that being the only option, then I've exhausted everything available to me.
That's what I'm looking for... to learn what all the options are, and to be sure I've handled all the ones that I can, properly.

However, I do have the code. At least I think I do.
It was on the disk with the other drivers, that came with the nic. I also found it online at their site... same drivers as I already had. I checked.

The linux drivers are about a half dozen or so text files. Looks like code to be compiled.
Does having this open up another option? I'm thinking that linux users, upon purchasing a card like this, know what to do with that included "driver". They must have a way of compliing it into that *.ko file, like I found.

Again, thanks for taking time to explain all this to me.

Starting from the bottom up:

Well, it doesn't necessarily mean you actually *need* them. The hardware manufacterer (that doesn't look like it's spelled right...) is likely doing it as a service to those who cannot (for whatever reason) upgrade/update their kernels to ones with the "drivers" (or modules in the linux world) already built in. So, you do have the source there, but it's not necessary because you have a kernel with those modules already there. This is all assuming sundance is the correct module at this point in the game (the sundance module might be correct for an older kernel, but a lot of times, especially with NIC hardware, a single driver supports hundreds of "versions" of the same or similar chip. The Realtek driver for instance is probably supporting a couple thousand varieties of NICs, you may want to give it a blind shot by typing "modprobe 8139too" to just see if your device happens to be one of them).

Simlarly to how you got that dmesg bit from redirecting dmesg output, try that with lspci:
And post that up here in the forums. Not knowing what you are looking for, as you've noted a couple times, really makes it difficult to do a "google" for it

Once you do that, I'll talk you through what I am doing with the info you post up so you can see how to "google it" in the future.

The writing code comment was more of a "sure, anything is possible" response. I tend to lean towards the "within my realm of current abilities, writing device drivers is impossible" even though technically I could probably take a year off and dedicate my life to learning how to code them and then get my NIC working...

I'm not sure what's involved yet, in the above information I was providing more abstract info to help you in your overall understanding. It may be that you might have an easier life to just head over to a junk computer parts store (that sells old hardware) and pickup a $10 NIC that says "3Com" on it and load up the 3c59x driver and be done. Really not sure yet though. And another option that you've pointed out and the other poster noted, other distros work. So your question at this point, "Is it worth my time to figure this out?" It may or may not be, that's up to you. Knowing what I know now about Linux, sure it would be worth my time because I could probably figure it out in less time than it takes me to make $10 (the cost of replacing the card with an el cheapo alternative) and if not, I'd just throw another distro on it and customize the distro to my flavor. Knowing what I knew when I started out learning Linux, I probably would spend entirely too much time on it, not learn a whole lot in the end because of it's obscurity, and be far beyond that $10 time spent. But I still probably would have done it back then Feel free to give up on this and not feel like you've given up on learning how linux works. This is 0.5% the other 99.5% won't include the knowledge gained from getting this working. However, it is truly gratifying when you pull something obscure off especially when in a room around a problem surrounded by other geeks who can't put their finger on it. There's where the 0.5% comes in and makes it worth it. Feel free to be that geek.

Modules, what is what and how do I know?

Using your example, the mii module. Funny thing is that relatively recently I asked the same question about the same module. What is it! Here's what I found just now from a few searches:
http://www.informit.com/guides/conte...seqNum=73&rl=1

Not a lot of detail, but something. How else can you find info, modinfo. I don't have mii loaded, but I'll post up what I get from my NIC module (via_rhine):

So now we hit too much info. But, at the beginning there, we see that it's "description: VIA Rhine PCI Fast Ethernet driver" tells us enough info about that module to understand what it does without having to dig into the actual code.

How would I dig the code? For my example, I would download the kernel source code (I called it the source above, and it's available at www.kernel.org), untar it (read a few pages about tar if you don't know what that means. They are available on this very website) and then:
In here I see a slew of actual C code, header files (the .h files) and if you have compiled your kernel, some .o files (these are the results of compiling the c code). The one of interest to me is the via_rhine.c This is the actual code that makes the module I use for my NIC. I can open up in any text editor, but to just browse, I use a pager, in this case, less:
Generally, you should not have to do that. But there you go, that's (for me) the lowest level of a forensic search I do if I'm having a hard time finding out what something does.

Module versioning is a feature, not a bug or something like that. It is designed to not "dork" your system. The kernel is what makes linux stable. If you introduce a module compiled with a different compiler for a different kernel, it can cause instability. So, without a little bit of extra work, you are usually unable to load modules compiled for another kernel, or using a different version of a compiler (gcc in most cases). So, yes, the information is coded into the module to help keep that from accidently happening.

What you are looking for when comparing 2 distros. First thing I'd check is the difference in loaded modules. They very likely won't be in order, but doing an "/sbin/lsmod > lsmod.output" comparison from the 2 distros might help you track down what one distro has that the other doesn't. You could then test your theory pretty easily doing a:
to see what happens. If you lose your network on your working system, it might lead you down the road that answers your question of "what module do I need to get my hardware working".

Hopefully that makes it a little clearer than mud. So post up that output from lspci and we'll go from there.

Good luck!

Cool

I am assuming that, since with Puppy Linux Live CD, that is the module that works.
It seems to install itself, if I remember correctly... haven't booted it in a while. I do seem to recall experimenting... modprobe -vr sundance in Puppy, and that sure enough killed the ability of the ethernet card to get to the internet.




I'll have to remember to give it a try, next time I boot Slax. Tnx for the tip.

Will do.

Fantastic! Much appreciated.

Right. I just wanted to exhaust everything that realistically is within my own realm of ability.
To make that decision, I need(ed) more info.

Taking your time to help is very kind of you.

Gaaack!! That's almost what I paid for the new one recently!
>g<

Seriously, I get your point.
You're talking about efficiency. If that was my main concern, simply to get 'something' to work, then yes - the time involved with getting the present card to work is certainly not worth the cost of a different, new card.

For now, I'm more interested in learning what is involved. Maybe it'll be useful to know someday, huh?

So that's why you are talking to me! You can relate.

Maybe someday. Way down the road. Not very soon though.

I believe I asked you here, without ever searching around. Sorry about that.

Just had a very brief look at that page. Realized it is not short, so I bookmarked it - and will get back to it later, after I finish replies.
Tnx.

modinfo.
Ok. Now to remember that.

Archiving util. No compression if I recall... have to use another util to do compressing.

Read a little about it, and that's it. Haven't had need to use it - yet.

And I have a file named sundance_main.c that came with the card. I meant to mention that in an earlier post.
First line of it is:
/* sundance.c: A Linux device driver for the Sundance ST201 "Alta". */

I assume /* is beginning of a comment line. ( Looks like REXX to me, but that is from long ago. )


So - if one has the kernel source code, one has the code for all the "drivers", i.e. modules?
hmm.. the catch would be - being sure one has the source code that matches whatever kernel one is running on the Live CD then, wouldn't it?

Why would a module included with the Live CD not work then? What are some reasons?
Is it possible that something about the way the NIC is actually made changed, after the kernel w/module came out?

I'm getting the feeling that I've missed something here.... sorry.


There were a couple "force" options. I found them with man modprobe. Is that what you implying?
Tried 'em.
Can't remember the exact result now... would have to do it again... but for sure it didn't solve the problem.

Thanks for explaining.

So.. for folks not using a Live CD... a 'real' install of linux .... they usually have a compiler that comes with their install? it matches their kernel? Thus, when they get ahold of something that needs a module, or for some reason the included module does not work, and if they can get the source code for the module - then they can complile it.... and this way the new module will "match" because it was compiled with the same compiler as the kernel. Have I got it right?
kernel, compiler, module all must "match" each other.