With the recent Precise kernels (at least 3.2.0-[10-12] I think), the system freezes during boot with the Ubuntu logo and colored dots on screen (the dots stop progressing), when I have wistron_btns enabled in /etc/modules. I need wistron_btns on this laptop for the wireless to work, which is why I’d like to have it enabled.

This is unrelated to Bug #926007 which I also just filed: the wistron_btns freeze happens even when I’m using fbdev. (With -intel, the #926007 panic and this freeze take turns in who gets to mess with me.)

From what I’ve gathered so far, it seems that wistron_btns works fine if I manually modprobe it from my desktop, after booting without it. So that’s a workaround at least.

I can kill the freeze with Alt+PrtSc+REISUB. I’ll provide any additional info needed, though I don’t know how to produce logs when the system is frozen.

(Filing this a a separate issue as suggested by Bryce Harrington in comments of Bug #903831.)

With the -intel driver specified in xorg.conf (or without an xorg.conf so that -intel is used), booting Precise with the current 3.2.0-12 always results in a kernel panic. I’ll attach a couple of shots I took of two instances (although to me the panic looks the same in both cases).

This began within the Precise cycle: with the early kernels I was able to boot fine, although Bug #903831 did come up then.

I have yet to try 3.2.0-13 which has just been released. Once package listings pick it up I’ll give it a go and report back.

I’m able to boot by switching to fbdev in xorg.conf (the way I’m reporting this now).

3.2.0-10 #17 kernel panic pid: 1, comm: init printk+0x2d/0x2f (1019.6 KiB, image/jpeg)

Robert, I tested your kernel. Unfortunately there’s little to report: here it still panics when bringing up X with -intel. Should I perhaps file a different bug about these?

I’ll attach a picture of the output. Looks like the freezing with just the mouse cursor occurs about 1/3 of boots, in 2/3 it manages to switch back to the logging terminal with the panic.

I can confirm the bug and the workaround both hold on an up-to-date Precise system with a Radeon HD 3200.

According to my understanding and based on what Jonas wrote above and also [1], doing the freeze post-BIOS would be useless securitywise; it’s not even a workaround, as any malicious software then just inserts itself into the MBR. This really needs to be fixed at the BIOS level to be effective at all.

[1] http://www.coreboot.org/pipermail/coreboot/2005-May/011688.html

I couldn’t, and neither could I with a 10.10 live, so it’s possibly something that’s changed going from 10.04 to 10.10. I also tried Chromium and Firefox 6 under 10.04; with Firefox 6 the issue persists, whereas with Chromium I can’t reproduce it. There’s of course a more serious bug underlying the browser, as no application issue should bring the entire system to its knees.

(I just realized I used amd64 live discs in the tests whereas the installed 10.04 is an x86 system. Perhaps it makes no difference but I’ll leave judging that to experts.)

I’ll gladly execute more tests if anyone has ideas how to narrow this down even more.

Thanks for your input Timothy, I’ll have to see if I can reproduce this using a 11.04 live disc.

Timothy, does your harware setup match? You’re using the internal Nvidia graphics and not an add-on card?

I just tested kernel 3.0.0, and although the issue went away, this didn’t reveal as much as it could have, because I had to run GDM in safe mode.

I just reported Bug #840266 and thought I’d mention it here as it bears some resemblance to this one.