[SOLVED] Network access

Squiddles · 2011-10-02 19:12:37

So network access [internet access] was working great up until my onboard NIC died. I bought a PCI Intel NIC and it worked on first boot. Now I'm finding that it decides not to work at all more than it wants to work.

I did a "dmesg | grep NET" and got this:

[    0.443543] NET: Registered protocol family 16
[    0.536556] NET: Registered protocol family 2
[    0.541451] NET: Registered protocol family 1
[    0.982738] NET: Registered protocol family 17
[   12.342699] NET: Registered protocol family 10
[   12.405650] NET: Registered protocol family 4
[   12.421942] NET: Registered protocol family 5
[   12.424226] ADDRCONF(NETDEV_UP): eth1: link is not ready

In "rc.conf" I've tried using "network", "net-profiles", and "net-auto-wired". All 3 seem to work at times, but after ~20 reboots of trying. On some boots [not the boot the dmesg came from] eth1 [the NIC] is not listed when I do the command "ifconfig". The Intel NIC does work every time, without any fail or trouble, in Windows 7 and the Windows 8 Developer Preview. Yes I have made sure the onboard NIC is dead. It drops packets constantly on the local network and sometimes gets no connection from pings and accessing the internet.

Any ideas?

EDIT:
SOLUTION:
The NIC built into my board was causing conflict with the PCI NIC [I had bought it since the on-board was starting to die]. On my nvidia board, the driver name is "forcedeth". I just blacklisted the on-board NIC and the PCI NIC started working flawlessly.

Last edited by Squiddles (2011-10-30 18:06:54)

fukawi2 · 2011-10-02 22:38:04

Initially I suspected faulty cabling, but then you said it works fine in Windows.... But that's still the only idea I have since it thinks the link is not ready

Squiddles · 2011-10-03 00:56:21

fukawi2 wrote:

Initially I suspected faulty cabling, but then you said it works fine in Windows.... But that's still the only idea I have since it thinks the link is not ready

Right, the cable is a smidge busted up. By that I mean the clip on one end has broken off...it still works when I reboot without touching it though. Is there something extra that I need to do since it's a PCI NIC? Or is there a particular driver I should using/adding to the modprobe in rc.conf?

Squiddles · 2011-10-05 16:58:35

So, I found that it works not on consecutive boots, but it works after Windows has booted...

fukawi2 · 2011-10-05 23:06:52

Squiddles wrote:

So, I found that it works not on consecutive boots, but it works after Windows has booted...

I recall reading something once about a network that doesn't get initialized properly by the Linux driver... So if you boot Windows, the Windows driver initializes it correctly, then reboot (without powering off) into Linux and it's fine, since the card has been initialized. I don't remember the details since it wasn't *my* problem but maybe that's what is happening here?

Squiddles · 2011-10-06 23:18:10

fukawi2 wrote:

Squiddles wrote:
So, I found that it works not on consecutive boots, but it works after Windows has booted...
I recall reading something once about a network that doesn't get initialized properly by the Linux driver... So if you boot Windows, the Windows driver initializes it correctly, then reboot (without powering off) into Linux and it's fine, since the card has been initialized. I don't remember the details since it wasn't *my* problem but maybe that's what is happening here?

Seems like that's it, but I can't even think of where to start with this.

fukawi2 · 2011-10-07 07:09:44

Renaming this (or starting a new) thread with a more specific title might get the attention of someone who remembers more than I do.

tomk · 2011-10-07 08:20:08

A broader grep of dmesg wouldn't hurt - use the -i flag to ignore case, and try 'eth' as well as 'net'.

I would also suggest blacklisting the driver for the broken card, just for tidiness.

Squiddles · 2011-10-08 08:03:56

It may be coincidence, but I may have stumbled upon something. I do have VirtualBox installed. It needs a module loaded to function properly and I know VirtualBox uses a network adapter to get the virtual machine network access. I removed the "vboxdrv" from the modules line and rebooted. It found the network adapter and came to a very quick "DONE" while booting. I can't test further because it's 4am here and I've gotten no sleep [just thought about this while in bed, haha!].

tomk wrote:

A broader grep of dmesg wouldn't hurt - use the -i flag to ignore case, and try 'eth' as well as 'net'.
I would also suggest blacklisting the driver for the broken card, just for tidiness.

I don't know what you want to use -i with. What do you want me to ignore from dmesg? I will use grep for 'net' and 'eth' tomor-errr, later today.

Also, how would I go about blacklisting the driver? Would that just be in the rc.conf where blacklisting is? Or am I misinterpreting that lines use?

tomk · 2011-10-08 14:45:55

I was talking about grep, so I thought it was clear that I meant grep's -i/--ignore-case option. You would use it to capture occurrences of your chosen pattern in both upper and lower case e.g. net and NET, eth and ETH, etc.

See the grep man page for details.

Squiddles · 2011-10-11 07:30:59

tomk wrote:

I was talking about grep, so I thought it was clear that I meant grep's -i/--ignore-case option. You would use it to capture occurrences of your chosen pattern in both upper and lower case e.g. net and NET, eth and ETH, etc.
See the grep man page for details.

Alright, got grep done of dmesg on a non-working network boot [network daemon failed to start]. Removing "vboxdrv" from rc.conf's modules section was a fluke for that last boot. There is something I'm noticing on boot where it says a memory address doesn't match. I have to take a picture with a camera though, as I'm not sure this message would show up in dmesg. I'll check next time I boot into Linux [next few minutes or before my obligations tomorrow]. I'm still unsure of how I'd go about blacklisting the onboard driver. That's very new to me.

dmesg | grep -Ei 'net|eth'

[    0.013176] Initializing cgroup subsys net_cls
[    0.440211] NET: Registered protocol family 16
[    0.516700] NetLabel: Initializing
[    0.516702] NetLabel:  domain hash size = 128
[    0.516703] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.516715] NetLabel:  unlabeled traffic allowed by default
[    0.529628] NET: Registered protocol family 2
[    0.534813] NET: Registered protocol family 1
[    0.634942] audit: initializing netlink socket (disabled)
[    0.976067] NET: Registered protocol family 17
[    0.991064] Initializing network drop monitor service
[    5.294248] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    5.380519] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
[    5.380652] forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
[    5.380657] forcedeth 0000:00:14.0: setting latency timer to 64
[    5.728835] e1000 0000:08:06.0: eth0: (PCI:33MHz:32-bit) 00:1b:21:9e:9a:51
[    5.728843] e1000 0000:08:06.0: eth0: Intel(R) PRO/1000 Network Connection
[    5.904068] forcedeth 0000:00:14.0: ifname eth1, PHY OUI 0x732 @ 1, addr 40:61:86:4f:37:d7
[    5.904071] forcedeth 0000:00:14.0: highdma pwrctl gbit lnktim desc-v3
[   12.086476] NET: Registered protocol family 10
[   12.145910] NET: Registered protocol family 4
[   12.158224] NET: Registered protocol family 5
[   12.160425] forcedeth 0000:00:14.0: eth1: no link during initialization
[   12.161585] ADDRCONF(NETDEV_UP): eth1: link is not ready

Squiddles · 2011-10-11 18:21:13

Alright, the thing I noticed did show up in dmesg, I found by remembering the memory address it showed during boot:

dmesg | grep 0x000dffff

[    0.485241] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
[    0.485250] pci_root PNP0A03:00: address space collision: host bridge window [mem 0x000d0000-0x000dffff] conflicts with Adapter ROM [mem 0x000cf800-0x000d07ff]
[    0.522052] pnp 00:00: [mem 0x000d0000-0x000dffff window]
[    0.522834] pnp 00:05: [mem 0x000de000-0x000dffff window]
[    0.522974] system 00:05: [mem 0x000de000-0x000dffff window] has been reserved

It's the second line that I see during boot, just before the udev events.

Squiddles · 2011-10-14 20:18:57

Bump?

Squiddles · 2011-10-23 06:04:41

No more ideas/suggestions/information needed?

stryder · 2011-10-23 16:41:01

Let me try to help. From your dmesg | grep -Ei 'net|eth' results it looks like 2 network cards are detected, eth0 and eth1. Very often when there are 2 cards, assigning eth0 and eth1 to the respective cards can be inconsistent, which is probably why sometimes the card works (eth1 is intel) and doesn't (eth1 is onboard card). For example the output shows the onboard card to be eth1, thus "eth1: link is not ready." I think there are ways to make them consistent but in your case blacklisting forcedeth (most likely the driver for the onboard card) will make the new card the only one available, and should be eth0 (although you should always check - try "ifconfig -a". You blacklist the driver by creating a file (say, onboardnic_blacklist.conf) with a line "blacklist forcedeth" (no quotes) and save it in /etc/modprobe.d. Reboot, check whether the blacklist worked, meaning only 1 NIC available. You can then configure eth0 in rc.conf either with dhcp or using a static ip. Network should be in your daemon list.

Good luck.

Squiddles · 2011-10-23 17:44:00

stryder wrote:

Let me try to help. From your dmesg | grep -Ei 'net|eth' results it looks like 2 network cards are detected, eth0 and eth1. Very often when there are 2 cards, assigning eth0 and eth1 to the respective cards can be inconsistent, which is probably why sometimes the card works (eth1 is intel) and doesn't (eth1 is onboard card). For example the output shows the onboard card to be eth1, thus "eth1: link is not ready." I think there are ways to make them consistent but in your case blacklisting forcedeth (most likely the driver for the onboard card) will make the new card the only one available, and should be eth0 (although you should always check - try "ifconfig -a". You blacklist the driver by creating a file (say, onboardnic_blacklist.conf) with a line "blacklist forcedeth" (no quotes) and save it in /etc/modprobe.d. Reboot, check whether the blacklist worked, meaning only 1 NIC available. You can then configure eth0 in rc.conf either with dhcp or using a static ip. Network should be in your daemon list.
Good luck.

That appears to have worked! On one boot at least. I had no idea the driver for the chipset was "forcedeth", I was reading it as "forcedeath" as if it couldn't use it and was forcing it stop trying. Jeez, if I knew that weeks ago.

Thank you for this info! If it works the next few boots, I'll change the thread to "[SOLVED]".

Arch Linux

#1 2011-10-02 19:12:37

[SOLVED] Network access

#2 2011-10-02 22:38:04

Re: [SOLVED] Network access

#3 2011-10-03 00:56:21

Re: [SOLVED] Network access

#4 2011-10-05 16:58:35

Re: [SOLVED] Network access

#5 2011-10-05 23:06:52

Re: [SOLVED] Network access

#6 2011-10-06 23:18:10

Re: [SOLVED] Network access

#7 2011-10-07 07:09:44

Re: [SOLVED] Network access

#8 2011-10-07 08:20:08

Re: [SOLVED] Network access

#9 2011-10-08 08:03:56

Re: [SOLVED] Network access

#10 2011-10-08 14:45:55

Re: [SOLVED] Network access

#11 2011-10-11 07:30:59

Re: [SOLVED] Network access

#12 2011-10-11 18:21:13

Re: [SOLVED] Network access

#13 2011-10-14 20:18:57

Re: [SOLVED] Network access

#14 2011-10-23 06:04:41

Re: [SOLVED] Network access

#15 2011-10-23 16:41:01

Re: [SOLVED] Network access

#16 2011-10-23 17:44:00

Re: [SOLVED] Network access

Board footer