radio_maestro module generates kernel oops and crash
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Colin Ian King |
Bug Description
I'm currently testing the Jaunty beta on a Compaq Armada M300 laptop. As it does not have a floppy or optical device I'm booting over PXE and using the netboot installer. Due to its lack of horsepower I have only verified this bug on the Xubuntu and Ubuntu Netbook Remix flavours of 9.04 so far.
Unless I add "blacklist radio_maestro" to /etc/modprobe.
What I have seen in dmesg is that after the radio_maestro module is loaded the kernel has around 15-20 oops messages related to SMP. Odd as this machine only has a single (very slow) processor core. The filesystem mounts read-only with the module loaded, which means I cannot save anything anywhere. Eventually after a while I get lots of segmentation faults and the system hangs. I can reboot it with the magic SysRq keystrokes (raising elephants, etc...) but then the information about the error is lost.
With my blacklist workaround in place the system functions perfectly including the ESS Technology ES1978 Maestro 2E built-in audio. I was previously running Xubuntu 8.10 on this system without similar issues.
Please let me know if I can collect any other information to assist in fixing this issue?
Ian.
ProblemType: Bug
Architecture: i386
CurrentDmesg:
[ 40.384314] ADDRCONF(
[ 40.388302] e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
[ 40.397082] ADDRCONF(
[ 50.852045] eth0: no IPv6 routers present
[ 99.301569] ondemand governor failed, too long transition latency of HW, fallback to performance governor
DistroRelease: Ubuntu 9.04
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Compaq Armada M300
Package: linux-image-
ProcCmdLine: root=UUID=
ProcEnviron:
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: linux
Changed in linux (Ubuntu): | |
importance: | Undecided → High |
status: | Incomplete → Triaged |
tags: | added: kernel-oops |
Changed in linux (Ubuntu): | |
status: | Incomplete → In Progress |
tags: |
added: verification-done removed: verification-needed |
Hi Ian,
I don't suppose you'd be able to take a digital photo of the very first oops that occurs (and particularly be able to capture the beginning of the oops)? Could you attach that photo to this bug report? You also mentioned you are able to blacklist the module which allows the boot to succeed. Just curious what happens if you then load the module afterwards? Do you get an oops as well? Thanks.