I've seen several threads with the same problem I have (Device or resource busy) when attempting to connect to my network. The solution posed (disable PnP in BIOS) isn't available to me. What I haven't seen mentioned is that the problem seems to be distro specific.

I have a Linksys card using the tulip module, and an onboard lan using the via-rhine module. All the distros I've used detect the cards and load the modules, but when attempting dhcp (whether at bootup or manually) some work perfectly while some give me "busy signal". More to the point, Slackware based distros won't, Debian distros will. Can someone with enough knowledge of these systems tell why that is?

Working:

Debian, Ubuntu, Kubuntu, Knoppix, Gentoo, Damn Small, h3knix

Non-working:

Slackware, Vector, Phlak, Arch, Suse, Minislack

As you can see, with a few exceptions they are either slackware or debian based.

Is it a difference in startup scripts?

I only need one card to work. The other is just a backup.

Thanks in advance.

If you have two onboard lan cards, this is a dual homes host - and requires extra configuration. You may find that some distros do this by default.

It may help to boot the problematical distro with the on-board card disabled in bios. Configure the remaining card as your main one (eth0) then manually configure the second one when you need it.

(Though it may just be an IRQ conflict?)

I only put the pci card in when the onboard fails to work, and I do disable the onboard in the bios. I only listed both to show that the problem is not related to a specific card. I never run both as I only need one.

I'm just curious as to what would be the difference in the way that a slackware distro initiates network starting as opposed the debian distros, and what I could do (other than disable pnp in the bios) to get the slackware distros to properly connect.

Thanks for the reply.

Hang on - the way I read your question was that you had trouble only when both cards were active. Now you say you only use one card at a time? Maybe I'm just extra thick today: I don't understand the situation. Can you direct me to the other threads you mentioned?

In General:
The main difference between debian and slackware is the amount of pre-configuring that goes on. You'll have noticed that Debian is generally easier to install and set up than Slackware - but sometimes Slack seems to run better.

In the slack based distributions you will be expected to do all the configuration needed to get the two lan cards to work, yourself. It's often a routing issue. Sometimes it is a matter of having some kernel parameters turned on to allow the cards to know about each other.

The situation may even be different for different slack based distros ... but a starting point to figuring it out would be to look at the dual homes situation.

Beyond that it would be difficult to tell without actually being in front of your machine - it dosn't seem to be a common problem in slack based distros though. I've not seen any trouble with two nics under slack... other than routing and firewall setup. But then, I probably don't understand what you are trying to describe.

Sorry about that. Let me clarify.

I normally use an onboard lan with the tulip module. On certain distros the card works perfectly with dhcp, whether configured manually or by some script or gui. Other distros, however, give me an error message about the device "SIOCSIFFLAGS: Device or resource busy", when attempting to connect. The ethernet is detected properly. The module is loaded properly. The general solution in the other threads was to disable PnP in the bios.

For Example:

Here
or Here

I can't find an option to disable PnP in the bios.

My point is that for me the problem is distro specific. Most slackware based distros give me the error, while most Debian distros work great. If I'm not mistaken a lot of these distros use the same startup scripts and network configuration as the distro it's based off of, and I was wondering what the difference would be that causes the problem in some and not others. In other words: What is the difference in the network startup scripts between Slackware and Debian (yes, I've used those distros specifically before), and would the problem lie in there?

Make any sense?

Thanks again.

Only in the second example is pnp=off suggested as a solution. And it didn't work.

I suppose pnp may leave a device busy ... but this is usually an issue with using the device under windows, then changing over to linux later - windows leaves some devices "busy" and the solution is normally to switch everything off then reboot. (The std win thing right...)

I don't see how this would relate to the issue.

OK - so - when you have found the onboard lan nic not going in slack (and distros of that ilk) do you then disable the onboard nic and plug in the other one? Does it work then or is it the same? ... I suspect it is the same.

Please bear with me while I review some of the existing threads on this topic myself... <read read read gasp read>

Rex_chaos : had this issue only when two cards were used on an old server under RH9. Suggested: pass commands to lilo - unhelpful - no further replies.

3-1415 is running Slack 10.1 with the identical issue - was advised to disable pnp in bios with success reported. Referred to

this article which baldly advises the same with reported success in RH9.

redness: has slack 10 with this issue, was asked about drivers and daemons etc. No result reported.

So we have this in RH9 (i.e. old) and Slack so far. It is starting to sound like driver compatability (if it is only some cards) which makes me think of kernel config ... if the slack at al are running distro kernels, then perhaps their configuration is slightly different? If they are identical vanilla kernels, then it's back to the drawing board

You have, of course, googled the error message:
Donald Becker: suggests checking what else is using the same IRQ. He says some drivers may not have been updated to properly share interrupts ... maybe the different distros come with different versions of the same driver?

Stefan Soeffing: running debian, admits to trying to use an old driver when he gets this problem. Maybe we're on to something here?

This thread has some inetersting ideas. 1. check the correct driver is being used: tell us the cards too (SiS 900 onboard?). 2. since you ahve been using two cards - albeit not at the same time - do you use the same mac address for them both? However - I'm not sure this is the lead it appears to be.

jeays.net: has this to say. They say to disable pnp in bios - but offer an explaination as to why it should work! Basically, this is to force the system to reconfigure. (Info for RH9.) However: it dosn't work for him - still gets the errors and dosn't know what to do. Provides a link lto the official scyld software page about the tulip driver under linux. Without knowing about your cards I cannot tell if it is useful.

First of all,

Thank you very much for the time and effort you invested. I had googled and seen most of those threads ( I think there was one that I hadn't looked into).

As for the problem, I'm almost positive it is an irq issue. I don't believe it's an issue of conflicting irq's, but the device irqs not being read properly. It may be as simple as enabling acpi at boot.

When booting phlak linux live cd yesterday, I noticed that "acpi=off" was passed to grub at boot. I removed the command and Bingo!, we had a connection.

I haven't had time to test this with other problem distros yet. I will update as I find out.

Thanks again.

Ah well... that's what happens when a hacker gets interested in a problem

Do let us know the result of this test - the problem seems common with little by way of reasonable answers. You could pick up a lot of mana by going back to all those pages and telling them your solution (should it work.)

Ok, back to square one.

The phlak live cd uses the knoppix booting system (which has always correctly connected my network), so enabling acpi was all I needed to connect. BUT!, when installed to the harddrive, phlak no longer uses the knoppix startup. It uses a different set of boot scripts and goes right back to having the "Device or Resource busy" problem.

So, digging through dmesg of a couple of distros, I came up with this:

Arch linux 0.7 (dmesg output)

PCI: Enabling device 0000:00:10.4 (0000 > 0002)
PCI: IRQ 0 for device 0000:00:10.4 doesn't match PIRQ mask-- try pci=usepirqmask
PCI: No IRQ known for interrupt pin C of device 0000:00:10.4. Please try using pci=biosirq.

lspci shows device 0000:00:10.4 to be my ethernet.

Slackware 10.1 (dmesg output)

PCI: Enabling Device 00:0a.0 (0000 > 0003)
PCI: No IRQ known for interrupt pin A of device 00:0a.0. Please try using pci=biosirq.

(a little farther down)

eth0: ADmtek Comet rev 17 at 0x100, 00:0c:41:EA:1D:55, IRQ 0


Neither of the commands pci=biosirq or pci=usepirqmask were useful. I just got the same output, but without the suggestions for the commands.

Why is my ethernet being assigned an IRQ of 0?

Why do some distros do this properly, while others don't? Is it a difference in programs?

Does anybody understand this?

This is on-board? Check out the bios entry.

Unfortunately, my bios is very limited in this way. The only option or entry for the onboard lan is whether or not it is enabled.

Hmmm - I've seen some very limited bios' too.
SO is there not a menue someplace to let you see the IRQ settings? It won't be part of the onboard periferals menue. It may be in advanced configuration or something.

No, the only irq settings are for the parallel port. Go figure. I flashed my bios to the most recent version just to be sure.

Very frustrating.

yeah - mine has a big list.

Chances are, then, that the bios assumes there is only one lan card available. All installed cards will share the same interrupt - and not all drivers work well with shared interrupts.

But this is a guess.

I seem to remember that dmesg tells you about assigned IRQs as well.