Reopening, there’s more to this than I thought.

I thought 3.2.0-14 brought with it a regression, but it turns out it’s now the -pae kernels that freeze during boot as I initially described. The thing is, I could’ve sworn I already ruled this out and also that I did most of yesterday’s successful boots with 3.2.0-13-pae, since that was the topmost and default in the Grub menu. So I’m not yet ruling out some funky hardware fault, but for now I’ll update the title to reflect how it presently seems: the wistron_btns problem lies with -pae. Non-pae kernels all the way back to 3.2.0-12 now boot fine.

I’m currently running memtest on the laptop just to be sure, although I’ve done it multiple times before with no issues.

3.2.0-13.22 fixed this! Just did three consequtive reboots and a cold boot with wistron_btns. Each booted just fine and the wireless was there, working. To be sure, I also tried 3.2.0-12 again and it still hung during boot. Back to 3.2.0-13 and again no problems. Excellent!

Okay, I’ve tested 3.2.0-13.22 and the results are… annoyingly varied. Mostly the boots ended in a black, nonresponsive screen. On a couple of such boots, I was able to ssh in and get some logs. I’ll attach them.

On one boot, there was a Trace different from the panic I reported. I’ll attach a picture.

On yet another boot, the same panic was there just as in my shots above, just after ”Starting CUPS” this time. I’ll attach a picture of that too just for completeness’ sake.

So the issue is definitely still there, either it just now manifests itself in slightly more random ways or is clouded by others. I tried -12 again too and that immediately produced the panic, so it’s more consistent in that respect.

On a positive note, fbdev still Just Works.

@Bryce, this really is a messy one: I’ve so far dissected three overlapping issues ((Bug #926007, Bug #926012 and Bug #926028) which have hindered my attempts to assist in debugging the one I originally laid down in this report. :)

Due to Bug #926007, I’m forced to use fbdev on this laptop in order to use X. In normal use it works okay, but when I boot in recovery mode, the resume normal boot option fails to launch X. Instead it launches the low graphics mode dialog, and if I switch to VT-1, the screen becomes garbled.

Xorg log says the problem is it can’t open /dev/fb0: No such file or directory. I’ll attach the log below.

It doesn’t matter whether or not I use the other options the recovery ncurses menu offers; X won’t start properly unless I reset and boot normally (i.e. not in recovery mode).

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).

Bug #904853 is related: for a i386 package installed with –force-architecture on an amd64 system, the Synaptic symptom is the same (”The list of installed files is only available for installed packages” ). The info files in /var/lib/dpkg/info don’t have a :i386 in the filename, as (I’m guessing) Synaptic figures for an :i386 package they should.

jani@saegusa:tmp$ ls /var/lib/dpkg/info/lightscribe*
/var/lib/dpkg/info/lightscribe.conffiles /var/lib/dpkg/info/lightscribe.list /var/lib/dpkg/info/lightscribe.postinst

This has been fixed in Precise (if not earlier): libsane depends on libsane-common, which now provides html/sane-mfgs.html.

jani@saegusa:~$ dlocate sane-mfgs.html
libsane-common: /usr/share/doc/libsane/html/sane-mfgs.html
jani@saegusa:~$ LC_ALL=C apt-cache depends libsane | grep libsane
libsane
Depends: libsane-common
libsane-common:i386
Suggests: libsane-extras
Replaces: libsane-extras
Replaces: libsane-extras:i386
Replaces: libsane:i386
Breaks: libsane:i386

This also concerns libsane 1.0.22-7ubuntu1 here. I don’t think this is Bug #904853, as I’ve not installed these packages manually, although I can’t vouch if –force-acrchitecture is used automatically by some upgrades.