Debian - Networking doesn't work after upgrading RAM to more than 2GB?
 

I'm running 64-bit Debian Squeeze (6.0.8). It had 2x 1GB sticks in it previously, and I tried to upgrade to 2 different sets of 2x 2GB sticks, totally 8GB RAM. The only difference between the two sets is one has slightly different latency (5x5x5x15 vs 6x6x6x16).

Anyways, if I put all 8GB in, the BIOS detects it, the OS detects it, but networking doesn't work. Through much troubleshooting, I found that regardless of setup, the only time networking actually responds is with no more than 2GB RAM. I can choose any individual 2GB RAM DIMM and it works fine. With all 8GB RAM, things seem to run fine, but I have no networking. Sometimes I can DHCP an address with more than 2GB, the link auto-negotiates speed/duplex perfectly, but I can't ping anything on my local network. Same thing if I set it statically.

All 8GB of RAM were in a previously known good machine, none bad.

This is driving me crazy. Can anyone tell me why this is?

Put the 8 gig in and run memtest for a day or so.

I get the feeling that maybe the ram is bad or worse, could be phoney.
Could be your board doesn't support it.
Not sure but could be a pae issue.

Not sure why memory would affect network adapter. Does it still show up in lspci/lsusb or such?

Networking functionality shouldn't have anything to do with how ram is installed. Like the previous user posted try running memtest86 overnight with all installed RAM this will tell you if any errors are detected (you'll know by a RED status bar on your screen the next morning). Have you installed the right networking drivers based on your network hardware? lspci/lsusb will tell you what network hardware you are using, also, some hardware require firmware from your linux distribution for the hardware to work correctly. Do some google searches on this, but what puzzles me is that it works 2GB or less. Keep me posted.

Yeah, I know network software is independent of non-network hardware, I'm just totally baffled as to why it won't work with over 2GB. Like I said, all this RAM came out of a known good PC, I can throw it back in that PC and it works fine. I can use any individual 2GB stick and it all works, but if I add any more then it just fails. I wouldn't be surprised if more than networking is actually affected, but most of my services run over networking so trying to test them is irrelevant anyways.

I did consider flashing my BIOS, it's just a bit of a pain to do it because of my physical setup (hooking up monitors & keyboard, shuffling around my little space, etc). But that's probably the best option at this point. I'll give that a shot tonight.

The whole thing sounds very unlikely. But within the unlikely, it sounds like a bug in a network driver.

That would be almost plausible if this were some very new or obscure network driver not likely used by enough other people for someone else to have seen the bug already.

What info do you have on exactly what network driver you are using?

I think BIOS is very very unlikely. I would not bother trying something as unlikely as flashing the BIOS.

Some bus issue (such as capacitance) with multiple ram sticks is a possibility, very unlikely to somehow affect just the network, but still worth investigating with memtest as others suggested.

If it is a hardware problem (rather than a driver bug) it would probably go away if the ram were underclocked (given a slower clock and/or more wait states than they officially need). Some BIOS's have the flexibility to let you slow things down (lower clock for the CPU forcing a lower ram clock or other methods of slowing the ram without changing the CPU clock). See what choices you have. If that fixes things, you probably don't want to keep it that way. You would rather fix it right. But it is still diagnostic. If it is fixed by slowing down the ram, a driver bug is far less likely and hardware problem more likely. Given what we already know (any 2GB works but more does not) if slowing the ram does not fix it, that makes a hardware problem much less likely and driver bug almost certain.

Hmm. That's some food for thought anyways. Prior to the upgrade it was running 2GB RAM in the form of 2x 1GB sticks, so I don't think it's a multiple stick issue.

Forgot to include the lspci entry:
I had already tried setting the RAM to slower speeds in BIOS. It did detect all 8GB, but still no network.

Based on google searches I found the driver you need to be "sk98lin", can you confirm this is the driver you are using? either with lsmod command or looking in your kernel configuration .config file or make menuconfig.

I did an "lsmod | grep sk98lin" and didn't return anything. Forgive me, I'm not fluent by any stretch of the imagination with lsmod.

Here's my lsmod output altogether.

In your case your kernel module is loaded correctly, its called "skge" and I see it in your lsmod result set. I was mislead by the first driver I mentioned earlier. So right now you are running on 2GB ram and your Marvel based networking is working correctly?

When I googled skge to discover it was your Marvell ethernet driver (because I hadn't yet seen cizzi's reply) I saw discussions of driver (maybe firmware) bugs. But I didn't really understand those discussions and don't know if they are relevant.

Correct.

You're BIOS flash update idea doesn't sound like a bad idea/option at this point,

One item google found was:

https://bugzilla.kernel.org/show_bug.cgi?id=61291

I don't begin to understand the bugzilla bookkeeping details of that message, but I do understand the diff of the C code. It is entirely about dma addressing and exactly the kind of difference one would expect for a bug causing DMA to fail (in just the skge driver) on addresses larger than 2GB.

I'm far from certain, but I think this means there was a bug in skge that fits your described symptoms and it was fixed.

I don't know the Linux kernel versioning and terminology well enough to tell you how to determine if your kernel version is before, during, or after that bug was created, found, fixed.

But I think a different kernel version (implying a different skge version) is a better shot than flashing the BIOS.

Do you happen to have a liveCD (or DVD or USB) copy of any MUCH newer Linux? See if that can use the network with 8GB ram in that system. That should confirm the issue is a driver bug that is fixed in newer Linux.

Good searching, use the latest kernel you can find for your distro or go to kernel.org and get it there and compile it yourself i you know how,

See attachment.

I'm willing to learn.