Procrastiblog

It just wouldn’t be a system update if it didn’t break Suspend.

If, for whatever reason, you have been moved to install the latest version of the Nvidia drivers—eschewing the always classy, always out of date nvidia-glx package—you must must must re-install after a kernel upgrade. The reason being that the driver compiles a custom kernel interface that is, in all likelihood, now broken.

Bonus tip: How do you shut down the server so that you can install the driver?

sudo /etc/init.d/gdm stop

(Or,

sudo /etc/init.d/kdm stop

for you Kubuntu people. (What’s wrong with you?)) (Hat tip: TheOS)

Ubuntu quietly made -fstack-protector (i.e., ProPolice support) the default in their GCC 4.1 binary. (I think it’s also the default in OpenBSD.) Unfortunately, this breaks some builds, especially (I think) if you’re trying to build a kernel module. If you get an error that mentions the symbol __stack_chk_fail_local, like the one below, you got bit by this bug.

/usr/bin/ld: .libs/cr_checkpoint: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

Either re-build your libraries with -fstack-protector or add -fno-stack-protector to CFLAGS. If this doesn’t work, you can try gcc-4.0, which predates the introduction of ProPolice, but this probably won’t work if you’re compiling a kernel module, because they have to be compiled with the same compiler as the kernel.

I finally gave up on ever getting my old Broadcom BCM4401 wireless card to work under Linux, so I went out and bought an Intel 3945ABG card (which is actually one of the cards Dell ships with my laptop model, just not the one I happened to get (through no fault of my own)). Out-of-the-box support from the stock ipw3945 driver. Plays nice with the Network Manager and the proprietary nVidia driver. Suspend works. Sweet.

Having taken a moment to appreciate this vast improvement in my computing situation, I will now proceed to bitch. Every now and then—say every 3rd or 4th time I suspend—the wireless card doesn’t come on after I resume. All I have to do is “rmmod ipw3945; modprobe ipw3945” and it comes back fine (which is better than manually fussing with the ESSID, which I have often had to do in the past).

I filed a bug on this and one of the maintainers suggested I add the module to the “suspend blacklist”. I politely asked both the maintainer and Google what and where the “suspend blacklist” is, but I’ve gotten no answers. There’s a bunch of scripts in /etc/acpi that seem relevant, but from what I can tell, they should already being doing what I want to hack them to do. Which might mean they’re not even being used anywhere anyway…

At less frequent intervals—say every 9th or 10th time I suspend—the module is “busy” when I try the unload/reload step and I have to reboot to get things back in order. I can’t figure out how to find out which process has a lock on the module either…

Bah!