I am re-posting this from the Slackware forum, with revisions - really need some assistance figuring this out. I can't believe that this problem has stumped for so long.

The problem is that anytime I load the nic drivers (should be just a simple Intel E100 driver) the machine locks. This when loading either through the standard Linux boot up or manually via insmod and/or modprobe (I'm doing this from runlevel 1, otherwise I can't boot the box).

I have confirmation from the manufacturer (iBase) that the driver I'm using (e100-2.3.38.tar.gz, link on intel's website is below) was what they used to successfully test with RedHat 7.1 (that's pretty old huh?).

My specs: Slackware 9.1 (Kernel 2.4.22) installed on 1RU server w/ ibase IB800 P4 "computer on a card" w/ Intel 845 chipset w/ integrated ICH2 Intel Ethernet controller.

My lspci info (just the NIC line, none of the other lines have the same address):

02:08:0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)

which I realize doesn't say 82562,which is the nic chipset number that the MB manufacturer referenced - the 82801BA info appears on lots of the lspci lines, it's the chipset component that controls pci & isa bridge, SMBus, USB, and the NIC...I'm guessing it doesn't matter, though...

First problem was that immediately after linux install (first reboot off hard disk) the computer ID'd the NIC as an

eth0: Intel Corp. 82801BA/BAM/CA/CAM Ethernet controller **that jives with the lspci info above**

and then totally locked up, couldn't get to a login. Have gotten around that by typing at Lilo:

Linux init 1

in search of better drivers, I go here:

http://downloadfinder.intel.com/scr...mp;DwnldID=2896

and get the e100-2.3.38.tar.gz file, then follow directions in its readme file, up to:

4. Compile the driver module:

make install

*to which it returns:

find /lib/modules/2.4.22 -name e100.o - exec rm -f {} \; \
||true
find lib/modules/2.4.22 -name e100.o.gz -exec rm -f {} \; \
||true
mkdir -p /lib/modules/2.4.2/kernel/drivers/net
install -m 644 -o 'id -u' e100.o /lib/modules/2.4.2/kernel/drivers/net
mkdir -p /usr/share/man/man7
install -m 644 -o 'id -u' e100.7.gz /usr/share/man/man7
/sbin/depmod -a || true

and then it returns to a command prompt, and I proceed:

5. Install the module:

insmod e100 <parameter>=<value>

**OR I TYPE**

modprobe e100

and it displays

Using /lib/modules/2.4.22/nernel/drivers/net/e100.o
Intel (R) PRO/100 Network Driver - version 2.3.38
Copyright (c) 2004 Intel Corporation

PCI: Found IRQ 10 for device 02:08.0
e100: eth0: Intel (R) PRO/100 Netowrk Connection
Hardware receive checksums enabled

and then it returns to the prompt:

root@(none):/tmp/e100-2.3.38/src#

EXCEPT that the cursor is a solid white rectangle, and the machine is locked.

Current BIOS Settings, with notes:

PNP OS Installed [No]
ACPI = Disabled (was Enabled, no change)
APIC = Disabled (was Enabled, no change)
AC97 Audio = Disabled (was Enabled, no change)

These items are from /usr/src/linux/.config:

#
#PCI Hotplug Support
#
Config_PM=y
Config_APM=m **what is "m"?**

and also this:

#
#ACPI Support
#
#CONFIG_ACPI is not set

Out of ideas, I tried this:

in /tmp/e100-2.3.38/src# and typing

insmod e100_test.o

and that returns lots of lines like this one:

e100_test.0: unresolved symbol e00_eeprom_read

and then this:

Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. The module may be trying to access GPLONLY symbols but the problem is more likely to be a coding or user error. Contact the module supplier for assistance, only they can help you.

If you're still reading this...thanks.

RWS

after a quick search in my kernel sources, this is what I found:
-When I do a search on the 82801BA chip, I have that result:
-When I do the search for the 82562 one, I have this result:
So as lspci returns a 82801 chip, I think that you should try eepro100 driver

Well...that sounded good, too bad it didn't work.

I too get the same output with grep.

I typed modprobe eepro100 and it locked up.

Reboot in init 1, un-remed the eepro100 line in /etc/rc.d/rc.modules and rebooted normally, and very interesting, the boot process goes a full four lines more before it locks.

Whereas before (loading the epro100 driver), it locked right after the line that says "ROM checksum self-test: passed", now (loading the eepro100it goes past that line to say:

scsi: SCSI host adapter emulation for IDE ATAPI devices
Using /etc/random-seed to initialize /dev/urandom
INIT: Entering runlevel: 3
Going multiuser...

And *THEN* it locks up.

Try to go back and compare the eepro100 results with e100 results - uh oh, now when I type

linux init 1

at the LILO I don't get any farther than I did above, it says

INIT: Entering runlever: 1

and then locks up.

Same thing (runlevel: 3) by typing:

Linux /bin/sh

Uh...now I can't boot the box?

I do believe that I am about to say "f*ck it", punt and start over.

I think, You can still boot if you have a rescue floppy...
So the last method is to understand what goes wrong either with a tool like kgdb (but each time your system freezes, you have to reboot ) or with UML (User Mode Linux) which may be a bit difficult to set up correctly but you can crash your kernel as many times as you want without rebooting your computer

So...I blew the install away and started again, choosing every conservative option, including standard text output on boot up (no penguin). I did however have it autodetect my NIC for me.

What those two things did for me is show me that the NIC drivers (eepro100) were loading correctly (I think, see below), and that the box abends only once "entering multiuser".

So...I stumbled across /etc/rc.d/rc.M as the file that controls alot (all?) of what happens when you boot up normally (in this case, into runlevel 3).

Question 1 - I'm really new, why is it rc.d? Why not "system" or "boot" or...whatever? This is kind of like "why bash? = Bourne Again SHell, dummy"...

Question 2 - Why rc.M? What's the significance of that "M" (as opposed to rc.4 for runlevel 4, rc.S for startup, rc.k for kill)?

OK moving on, I vi'd into rc.M and through process of elimination (moving # around, in DOS we called this "remming" out lines) have determined that placing a # in front of these lines:

if [ -x /etc/rc.d/rc.inet1 ]; then
. /etc/rc.d/rc.inet1
fi

OK, those are the "initialize network hardware" lines (this is why I'm still not sure about the NIC drivers...)

rc.inet1 does exist, and it says...lots of stuff that I don't want to type, it's unmodified by me though.

Question 3 - How can I make this file a "step-through"? In DOS I would just put a "pause" at the points I wanted it to wait for a keystroke and that was enough...

First thing it seems to do is get config info like this:

. /etc/rc.d/rc/inet1.conf

and THAT file just seems to define whether I want to use DHCP or not...which I do, on eth0 only, which appears to be the way the file is setup.

OK, so coming back to rc.inet1...I am not familiar enough with it yet, but it definitely seems like the next part of the file is going to end up being my problem, anybody got any advice so far?

Running in runlevel 3, with the network config lines remmed out as noted above, I type

modprobe eepro100

and it appears to do nothing, just goes back the prompt. I type

insmod eepro100

and it replies

insmod: a module named eepro100 already exists

So...what's that mean? If it already exists, why don't you FREAKIN use it, you POS...

type "ifconfig" at the prompt, and it doens't do anything.

type "ifconfig -a" at the prompt, and it replies

eth 0 Link encap: Ethernet HWaddr 00:03:2D:02:05:AD
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes: 0 (0.0b)
Interrupt: 10 Base addresss: 0x8000

lo Link encap: Local Loopback
LOOPBACK MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes: 0 (0.0b)

That tells me that it sees the card, but it's not enabled. Which I think I knew already.

Any advice greatly appreciated re: how to get this thing to not freeze whenever it initializes the NIC.

Thanks,

RWS

So I won't do a huge reply
First, if you don't want your network card to be automatically initialized at boot, you just have to remove the /etc/rc.d/rc3.d/Network_Init_Symlinks (if you boot in runlevel 3 for example). If you prefer debugging init script by adding a sort of pause in your script, try "read" command: It will give you a prompt and waiting for "Enter" to continue.
If you want to know more about what happens when you try insmod, enable debug:
insmod eepro100.o debug=6 (6 is the maximum verbosity)
and if you want to know more about options: modinfo eepro100.o

ack a little explanation of the Slackware startup stuff as I see it (I may use some dos/windows analogies):

rc.d is the directory with all the startup files, most of them are heavily commented so you can figure out what they do by looking at them. If you are lost now they will make more sense as you learn more about linux in general and what actually happens when the system starts. Slackware's BSD style startup is actually quite elegant in it's simpliciity.

for runlevels check out /etc/inittab it gives you an idea of what the runlevels do like runlevel 1 or single user mode with no networking.

rc.S is Start so its the beginning startup script

rc.M is Multiuser so basically any runlevel besides 0 (stop) 1(single user) or 6 (reboot). it runs for all multiuser runlevels including runlevel 3 which doesn't do anything else so there is no need for an rc.3

rc.4 is for runlevel 4, the GUI run level, which gives you a text console and xwindows but is otherwise like runlevel 3. For runlevel 4 Slackware runs rc.M and then runs rc.4

rc.K is a Kill script used to back down into runlevel 1 from a higher one

rc.6 is reboot and rc.0 is the shutdown script.

Those are all the main startup scripts, notice they are rc - dot - one character and they actually start all the other scripts in the /etc/rc.d directory using code like this:
What that code meas is "if this script is executable (which implies it exists since if the script was gone it wouldn't be executable) then run it" so drawing off that conclusion the easiest way to disable a script is not to comment out the line in rc.? but to make the script not executeable:
root@scoob:/etc/rc.d#chmod -x rc.inet1

In the windows world they are called drivers but in linux a "driver" is actually a module or kernel module but can also be an added in 3rd party module.

OK, now onto your issue:

Thats not a Slackware thing, ignore that since Slack does all it's networking in rc.inet1 and rc.inet2.

For your network card you have a module that will/should load for it, the Intel unfortunatly has two possible ones, the first one is the one that was written by Linux people (Donald Becker) called eepro100 and the other one was written by Intel people and is called e100. The e100 module comes in two forms, the (open source?) one that is included in the kernel and ones you download like your e100-2.3.38.tar.gz.

You may want to check /etc/modules.conf and remark out (#) anything that refers to eepro100 then check /etc/rc.d/rc.modules and make sure anything that refers to eepro100 is also commented out there.

A command that should help is lsmod, specifically look for eepro100 and e100 to find out which ones are loaded. I haven't had lockup problems with trying to load e100 while eepro100 was loaded but they will usually not both load and I'm not a total guru so I ended up compiling a kernel without eepro100 in it to get my Intel NIC to use e100.

Oh yea some more troubleshooting stuff to try, edit or view the log files /var/log/messages or /var log/syslog pico /var/log/messages or tail /var/log/syslog or dmesg I already mentioned lsmod also modprobe or
rmmod.

Sorry, this is pretty long winded but hopefully it helps you not feel so lost looking in those config files even if it doesn't help with your problem much.

Darin - thank you for the concise info, it was much appreciated.

Came back to this - new MB, new install. Also had time away from it, so I'm able to communicate about it better.

When you install slack, you can include eepro100 in the kernel or not. I am running with it NOT in the kernel. So it doesn't see the nic on bootup. Going forward, I don't think eepro100 is the right module anyway.

Because it doesn't see the nic, it's not locking up on boot into runlevel 3. It used to see the nic before it launched "going multiuser", but now it goes from the video card to the scsi card and skips the nic entirely.

However, it is not seeing the nic once I type insmod or modprobe e100 from within runlevel 3 - it loads the module (confirmed with lsmod) but doesn't display the "now the module's running, now it sees this hardware" text, instead it just returns to a (functioning) prompt.

Typing insmod e100 or modprobe e100 from within runlevel 1, however, does result in the system id'ing the nic's IRQ, chipset etc. try typing "init 3" after that, though, and it locks up on "going multiuser".

In either runlevel, I type ifconfig and the eth0 interface is not listed as it is not active. Typing ifconfig -a forces it to show up, however it doesn't have an ip.

In either runlevel, typing . /etc/rc.d/rc.inet2 (or rc.inet1) causes a lockup.

I have the mb manufacturer looking into this, but I have little confidence.

Quite a fist-time (actually second time) linux install huh?