3.3.0 panic on Lenovo T60
Hi
Since 3.3.0-2.dmz.1-liquorix-amd64 i'm experiencing panics shortly after booting. It might be that the panic happens when wifi connects. I'm using Ubuntu 12.04, stock kernel works. So far I was unable (no experience) to get a dump, just photographed the panic screen: link Let me know if you need anything else. Regards < Edited by enteon :: May 7, 12, 1:24 > Back to top |
|||||
Can you try 3.3.0-3.dmz.1?
Back to top |
|||||
Thank you!
Seems to work for now, but I will have to "test" some more because the panic did not always happen, even with wifi. Back to top |
|||||
:: enteon wrote :: Thank you!
Seems to work for now, but I will have to "test" some more because the panic did not always happen, even with wifi. Do you have Bluetooth enabled? I have panics with 3.3 seemingly related to Bluetooth. Back to top |
|||||
No, no bluetooth in this notebook.
Crashed again last boot, a simple reboot has been stable thus far and based on experience will remain stable. So there is only a small window after KDE started for it to panic, weird. Forgot to take a photo though... Any suggestions? Try to get kdump to work? Edit: 3.3.0-4.dmz.1-liquorix-amd64 link btw: my boot options are: "quiet i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1" sorry for the bad quality, I can't set display brightness after a panic :( Back to top |
|||||
This is probably a bug in the 3.3 kernel series. I'm merging the updates from the stable kernel tree as they come out, so I suppose all you can try doing is installing the newest and re-testing.
However, you can try running inxi per the topic here -> techpatterns.com/forums/about1891.html note: I did some quick googling and it looks like it's caused by one module, ite-cir as a few reporters in Ubuntu's launchpad reported in bugs.launchpad.net/ubuntu/+source/linux/+bug/972723 Back to top |
|||||
Thank you.
I blacklisted the module and will give it a lot of tries over the next week. I just didn't have much time to google for the panic. And I still don't know how to reliably reproduce the panic. Someone from the Canonical Kernel Distro Team wrote: "We indeed plan to send this upstream. We just wanted to get a few additional test confirmations first." So it might 'fix itself' soon. btw: here's the inxi output: :: Code :: System: Host: lappi Kernel: 3.3.0-4.dmz.1-liquorix-amd64 x86_64 (64 bit, gcc: 4.6.3)
Desktop: KDE 4.8.2 (Qt 4.8.1) Distro: Ubuntu 12.04 precise Machine: System: LENOVO (portable) product: 1951CA2 version: ThinkPad T60 Chassis: type: 10 Mobo: LENOVO model: 1951CA2 Bios: LENOVO version: 79ETE7WW (2.27 ) date: 03/21/2011 CPU: Dual core Intel Core2 CPU T7200 (-MCP-) clocked at 1000.00 MHz Graphics: Card: Intel Mobile 945GM/GMS 943/940GML Express Integrated Graphics Controller bus-ID: 00:02.0 X.Org: 1.11.3 drivers: intel (unloaded: vesa,fbdev) Resolution: 1024x768@60.0hz GLX Renderer: Mesa DRI Intel 945GM GLX Version: 1.4 Mesa 8.0.2 Direct Rendering: Yes Network: Card-1: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945 ver: in-tree:s bus-ID: 03:00.0 Card-2: Intel 82573L Gigabit Ethernet Controller driver: e1000e ver: 1.5.1-k port: 2000 bus-ID: 02:00.0 Drives: HDD Total Size: 80.0GB (38.7% used) Info: Processes: 129 Uptime: 49 min Memory: 973.9/3006.7MB Runlevel: 2 Gcc sys: 4.6.3 alt: 4.5 Client: Shell inxi: 1.7.36 PS: It might be a dumb question, but why is ite-cir loaded at all? I disabled IR in BIOS setup. Back to top |
|||||
Interesting, then it could be that ite-cir is a red herring. The next time you get an oops, can you boot with 'elevator=cfq' in the kernel command line? If you can't do that, you can change the IO scheduler on the fly to CFQ in /sys/block/*.
I made a quick script to make this quick to test since this is honestly a pain in the butt to change frequently if you're used to sudo access: :: Code :: #!/bin/sh
# change-ioscheduler.sh [elevator] function print_ioschedulers { for i in `find /sys/block/*/queue/scheduler`; do block_device="$(echo -n $i | sed -r 's|/sys/block/([a-z0-9]+)/queue/scheduler|\1|')" ioschedulers="$(cat $i)" echo "$block_device: $ioschedulers" done } function change_current_ioscheduler { new_ioscheduler="$1" for i in `find /sys/block/*/queue/scheduler`; do echo $new_ioscheduler > $i done } if [ -z "$1" ] ; then echo -e "current block devices and elevators\n" print_ioschedulers else change_current_ioscheduler $1 echo -e "new elevator configuration\n" print_ioschedulers fi exit 0 Run this script with root privileges like: sudo ./change-ioscheduler.sh cfq Back to top |
|||||
D'oh! I didn't even check if ite-cir was loaded and actually it isn't. At least if lsmod doesn't lie to me. So I unblacklisted the module.
I've been using deadline since around 2.6.39 on this machine and SSD but I think TLP (github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management) only overwrites the default after some time into the boot. So I'll be using cfq from grub-time on for now. PS: nice script, but I'm more of a su and ctrl+r guy ;) EDIT: Right now I have the seldom situation that the bug strickes every time. Therefore I have just discovered that no matter the I/O scheduler, my machine first becomes very sluggish (konsole) and then panics after about half a minute with the same stack trace. Still crashed without Intel i915 power saving mechanism parameters. Ubuntu kernel still doesn't panic, but is 3.2 anyway. What now? Kdump->LKML? EDIT2: Strangely, when I let it boot with a crash dump kernel (kexec) there is _no_ panic, not matter if I give the crash dump kernel RAM via "crashkernel" or not. :: Quote :: KVER="`uname -r`"
KERNEL_IMAGE="/boot/vmlinuz-$KVER" INITRD="/boot/initrd.img-$KVER" EDIT3: Now I'm relieved, 3.3.0-5 crashes with crash dump kernel. Back to top |
|||||
To be honest, I wouldn't request help from the LKML until you can reproduce this bug on 3.3 vanilla. Unfortunately, there's not much I can help you with, since I didn't add any special patches to linux's VM, and the panic you're getting is in slab / slub.
Let me know if you get any test results on 3.3 without my patch set. Back to top |
|||||
All times are GMT - 8 Hours
|