Note to others here suffering from this with Radeon HDMI only as I am: as per @David’s comments, I’ve just filed Bug #927323 about this.

Bug #751265 describes the symptom: when VLC uses Pulseaudio for audio output, the sound from it becomes garbled after playing for a while, with heavy digital artefacts and echoing. Comment #23 in that report suggests modifying /etc/pulse/default.pa so that load-module module-udev-detect is followed by tsched=0. I’ve done that, and with it VLC seems to work fine with Pulseaudio. Furthermore, in comment #30 @David Henningsson prompted us suffering from this and with the tsched=0 workaround working to file our own reports for each specific hardware. This is my report.

I believe apport adds data about the hardware automatically. I’ll add to that that for me this only occurs with the Radeon HDMI output; through the analog output (via headphones) the audio works fine. As Bug #864735 describes, Radeon audio is off by default in recent kernels, but I’ve re-enabled it by passing the radeon.audio=1 kernel commandline parameter.

If I switch to ALSA output for VLC (without tsched=0), VLC audio goes mute after a while. After some time of silence it sort of fast forwards itself to get up to sync with the video again. This keeps repeating, so it’s not really a workaround.

After selecting netroot from the friendly menu, I do get root but no network: only the loop interface is up. This happens even though the laptop has in fact both wired and wireless net, both of which do work on the system after a normal boot.

If I run ifconfig eth0 up and dhclient eth0 on the prompt, the wired interface comes up fine, so that’s a workaround.

Bug #572426 seems to have been repurposed for something that could make this a duplicate of that. Bug #868748 also describes something similar, but this isn’t just about not getting an IP address; the interfaces (apart from lo) aren’t brough up automatically at all.

(My previous comment was after trying 3.2.0-14.)

Alright, I will. Thanks Bryce.

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