After a bit of googling I discovered the reason for this is that my ISP, Virgin Media, have deliberately disabled SNMP access. Reports vary on the reasons for this, some claim “performance” others “security”, but both are utterly bogus reasons. All this does is deny customers basic information about their connection like bandwidth usage, and I can only conclude that Virgin Media want to make it more difficult for people to dispute their figures.

This isn’t enough to make me ditch VM, but it has pissed me off, and the next time I move house VM are going to be waaay down the list of providers I’ll look at.

PS. My router doesn’t support SNMP either so I can’t use that.

I’m using the uswsusp package for the job, s2disk works out of the box (with the above caveats) but s2ram needs the options “-f -a3 -m” in order to work. I would send the details to the devs to add it to the whitelist but there is a slight problem there:

This machine can be identified by:
    sys_vendor   = ""
    sys_product  = ""
    sys_version  = ""
    bios_version = ""
See http://en.opensuse.org/S2ram for details.

Not very helpful. So for now I’ve just compiled my own so I can run s2both, as that only works with machines that are on the whitelist.

I’m not sure I can live without neofb however, vesafb is incredibly slow when scrolling text. I may forget about using suspend and just live with hibernate.

They did take different paths to reach this point, and I assume that is the cause, udev (I think thats the responsible party) picking up configs from whatever was installed before. I recognise the stupidly long path as being a devfs type of thing, and vaguely recall playing with that on the laptop so that’s probably it.

The big question is, how do I get the laptop to use the nice short path like the desktop does? Without spending several hours researching into how udev works that is .

(Update: 03/04/2006)
It was udev, and I fixed it by the, obvious in retrospective, simple measure of comparing the /etc/udev dirs on the two machines and changing the laptop’s one to match. It had an extra couple of files in it, a devfs one and a compat one.

Switching off AGP support in the X server config by setting “NvAGP” to “0″ seemed to fix the problem when I was running a 2.4 kernel. Not useful if you are using the driver for the 3d acceleration, but all I want is tvout so it doesn’t affect me.

Section “Device”
Identifier “Geforce4MX-4000″
Driver “nvidia”
Option “IgnoreEDID” “1″
Option “UseEdidFreqs” “0″
Option “HWCursor” “0″
Option “ConnectedMonitor” “TV”
Option “NvAGP” “0″
EndSection

I recently switched to using a 2.6 kernel though and a few days after the switch the random lockups returned. A quick check, and sure enough, the via_agp and agpgart modules were loaded indicating the system was using AGP. No matter what I did I couldn’t seem to get rid of them.

So I decided drastic measures were needed and dived into the nvidia module source. I use the debian packages and build using module-assistant rather than the binary direct from NVidia, so these instructions are specific to that although I imagine you could adapt them.

I found the variable that controls the default setting for NvAGP (NVreg_NvAGP in os-registry.c), which is initially 3 (use whatever you can find) and reset it to 0 (don’t use AGP). Went to recompile the module and the compile fails, which struck me as very strange, I’ve only changed one number for fscks sake. Turns out that even with the value reset back to what it was the code won’t compile. Compiling it via module-assistant works fine though, don’t know what weird shit that is setting in the environment but it must be doing something.

Make the change again and compile a new module using module-assistant, install and reboot. Normally rebooting isn’t needed for new modules, but in this case I need to get rid of the agp modules and they won’t let me remove them once they have loaded. Everything comes back up fine, but the agp modules are still loaded. Damn I go back to the source to see what else I can change and find the NvAGP setting is back to 3!

Turns out module-assistant automatically replaces the source with a new copy from the tarball whenever you compile, so I created a new tarball of the source with the NvAGP set at 0, put it in place of the downloaded one and let module-assistant do it’s magic.

Result! An nvidia module that doesn’t load any AGP stuff, and thus a rock solid stable system once more .

/etc/modprobe.d/sound: (I’ve split some lines into two so they don’t mess up my website layout)

Then run update-modules to get debian to notice the change, load the module, check that the relevant channels are unmuted in alsamixer and we should be ready to boogy.