This has been, and continues to be, perhaps the worst and least reliable part of installing a linux system onto older OEM hardware: if you so much as LOOK at the cards wrong, there's no guarantee that the network card that worked PERFECTLY in the SAME KERNEL with the SAME CONFIGURATION will even be seen by the kernel the next time it boots.

What the hell? This just happened to me for the n-th time. I boot the system with a Debian CD, get the network card talking and update the system. I shut the damn thing down and plug the sound card back in, since I usually take it out just to get the thing updated because of this very problem. Now, even after playing with the BIOS for 20 minutes, the network card won't even come up in lspci!?

I'm a systems programmer. Granted, I know hardware internals are amazingly complex, but can SOMEONE just answer why my systems almost NEVER work the first time I try and plug two cards into the board? And why this has been a Linux problem forever and still shows no signs of being fixed? Am I forgetting a magic button somewhere?

-dave

I have been using Linux for about 4 years now, used about every major distribution there is, and have done probably in excess of 50 installs for personal use, friends, etc.

That said, I have absolutely no idea what you are talking about with this problem. I have never seen behavior like that on any hardware, on any kernel. Even the ISA boards/NICs I have used with Linux behaved relatively well.

I have seen my share of Linux instability in various tasks and situations, but never any problems with PCI cards just disappearing.

Moved: This thread is more suitable in Linux Hardware and has been moved accordingly to help your thread/question get the exposure it deserves.

Personally I have never had such issues nor seen such behaviour. I have a few really old computers that had Windows 98 and Linux just works with them.

I shut the damn thing down and plug the sound card back in, since I usually take it out just to get the thing updated because of this very problem.

Sounds more like this is your trouble, seems you have a soundcard from hell if its making the network card disappear and I would be surprised if they work together at all. You could try adding pci=usepirqmask to the relevant kernel in /boot/grub/menu.lst but that should show up in dmesg
Cheers,
Stan

I'm not sure if you are having problems with your NIC or your soundcard, but in any case, if your mobo has an onboard LAN port and/or onboard sound and you are also installing a standalone NIC or soundcard, you should get into BIOS and disable the onboard one. Having both onboard audio and a standalone sound card can lead to conflicts, same deal with onboard LAN and a NIC

That's the response I usually get

Summarized like: 1) don't throw stones and 2) it's your hardware problem

Well, I'm not a liar. And this happens almost every time. I've installed linux many dozens of times at least, been using it since '96. But now, as I used to do back 10 years ago, when I sit down to try and salvage some old OEM machine made worthless by commercial software's planned obsolescence, I:

1) remove the sound card, because it never works and in fact causes problems like we're talking about here
2) boot and install Debian off the CD
3) get the network card working (which never works automatically, but I'll admit I'm using the old school distro)
4) plug the sound card back in, and head down the road of getting X to work, the mouse, etc.

After step 4, almost every time, I have to either play with the card locations, or am faced with the wall of either having the sound card work, or the ethernet card work. In this case, I was fortunately able to simply switch the card locations, and it magically worked. This is not the first time I've done this.

In fact, its one of the first linux "Huh?" questions I had. Back in the day, the first thing that was suggested to me on how to fix a not-working ethernet card was to try another PCI slot. I questioned why it would make any difference to the kernel what slot the thing is in? He shrugged. Short of a busted motherboard, why would this make any difference at all? Especially in a modern kernel? And if it has always been busted motherboards, then I'd better go start betting double-zero.

Huh? This problem is always with the same type of machine? If it is on a variety of different hardware then your having some bad luck, I have never heard of anything like this before. Can you post the output of dmesg?
As for getting it working by changing slots, it has very little to do with the kernel and is almost completely due to the bus controller and bios setting up irq's
Cheers,
Stan

No one has accused you of that -- instead, people are trying to offer some assistance. Have you tried disabling the onboard audio/LAN in BIOS as suggested earlier? As I mentioned, if you've got onboard plus a PCI card, they can create conflicts with one another.

The closest I come to your problem is with Knoppix (which, surprise, I am more likely to use on various computers and, surprise again, it's Debian based).
Shortly after my first run in with Knoppix boot problems (a previous version had worked fine) I happened across a post about using the Knoppix cheat-codes.
Sometimes my network card will not be detected and the sound will go into a weird loop. The "noapic" cheat-code works in this case. I have also had to use the "nodma" code on one PC.
Maybe try passing the "noapic" message to the kernel rather than monkeying with the sound cards. Perhaps check out other messages that can be passed to the kernel. Does anyone have a good reference?

The board doesn't have onboard audio. The machine is an old HP Pavilion 4540, Intel Celeron, not sure of the board. But it really isn't relevant to the issue. I wouldn't be complaining if this happened to me once on one machine. It happens almost every time I setup an economy-priced old machine, and I have to play physical with card locations, each time praying I don't fry the the whole board.

Here's the output of dmesg, but again I still don't think this is machine specific:
http://wiki.linuxquestions.org/wiki/...ort_so_fragile

Here's where my knowledge runs out. Sometimes I hear that IRQ's are all software, others say hardware. In the BIOS, I see no place to set IRQ's for any specific PCI slot. I can set the IRQ for the serial ports, or the floppy disk controller, but that's it. I always thought that it was the OS that sets the IRQ's for things like sound and ethernet cards.

I admit that I might be missing something basic about setting up the BIOS that always leads me to this problem. But I usually try every combination of PnP, IRQ settings, enabling/disabling devices, and nothing fixes the problem. The only thing I can do is move the physical card.

PnP OS setting in BIOS. When turned on - OS is expected to finalize h/w initialization, assign IRQ's and I/O. When turned off - BIOS tries to take care of it. Which does not mean everything is OK. Some BIOS'es are broken, non-standard. Then usually a "Windows Motherboard Driver Disk" is included to make it work under Windows. Often there are h/w restrictions, like two side by side PCI slots cannot have different IRQ's. And so on! In particular older hardware may be tricky to get working.

for a kernel command reference:
http://www.kernel.org/pub/linux/kern...n_pdf/ch09.pdf
or "how to let the magic smoke out of your hardware if abused guide"
as suggested, try passing different commands to the kernel. a lot of laptop's have similar problems, though rarely to this extent. you can pass commands to the kernel in the grub menu at boot, I would suggest trying pci=usepirqmask first or the equivalent with knoppix's boot functions
cheers,
stan

Not all expansion boards will work the same in each system. The reason is because how the motherboard manufactures uses certain addresses. The second reason is the IRQ. If a expansion card is not capable of sharing its IRQ, it will either will not work or it will not work well. Third reason is the design of the power supply being used may make an expansion card malfunction. As you can see there are many reasons why one expansion card may work in one system and the other will not work at all. Engineers have to count for almost everything. Really there is no such thing of a perfect expansion board. Expansion boards can only be improved to provide better compatibility with hardware.

The are some expansion boards that needs some help from the OS in order for it to work. Usually it is an IRQ and memory address problem. If the BIOS has an option to set IRQ for the expansion boards, I suggest changing this option, so the BIOS sets the IRQ instead the OS.

If the network card is wireless, I strongly recommend using an external wireless NIC or use a wired to wireless bridge (aka access point).

I am sorry to say try other ethernet and sound cards. One or a few combinations should eventually work.

It is not just a Linux problem. Other OS also has the same problems. IMHO, using Linux provides a more realistic test of how compatible the hardware really is.

I heard of this problem and I know exactly what you are going through. I always question myself of certain expansion board that I am buying. When I bought a PCI combo card that contains 1 Gb NIC, USB 2.0, and IEEE-1394 (aka Firewire or i.Link), I was worry about the PCI to PCI bridge chip that it contains. PCI to PCI bridge chips are known to create problems. Luckly it worked or it have not yet make my computer malfunction. Also there are other expansion cards that uses PCI to PCI bridge chips like Hauppauge PVR-500. This card is not compatible with a lot motherboards, so people buying this expansion board are taking chances. This card is supported in Linux by the ivtv project. If the motherobard is not compatible with the PCI to PCI bridge that Hauppauge PVR-500 uses, it will not work.

Judging from the very informative responses, I'm guessing that the following are true:

1) PnP should always be disabled (or set to "Other OS" in the dumb wintel boards). I've always done this, but was wondering if it was still true.

2) Attempt to assign IRQ's in the BIOS. Make sure that no IRQs are shared (unless you know specifically that the driver and card can share an IRQ).

3) Pray

I'm still curious why swapping physical locations of the card would make it magically work. Perhaps the machine will only work if the sound card (which is as old as the machine) only works in the originally installed slot?

I'm also wondering if this is just a anomaly of >5 year old wintel boards, or a shortcoming of Linux hardware support? I say nothing bad about kernel developers, but will this forever be a problem so long as board and card manufacturers continue to try and keep their products secret? And if so, is there any way to detect the error in the kernel?