Description of problem: System freezing after two or three minutes while talking via sip with twinkle. This occurs only with 2.6.23.x kernel. With 2.6.22.x it doesn't. Version-Release number of selected component (if applicable): Kernel: 2.6.23.8-34.fc7 (or older) Twinkle: 1.1 How reproducible: Random. It happens sometimes. Steps to Reproduce: 1. Open Twinkle and dial a number 2. talk 2-5 minutes 3. If system crashes all is frozen (no mouse, keyboard, but display) 4. Hard reset of the machine is needed Actual results: Nothing in /var/log/messages Expected results: Additional info: I took this report into kernel list cause it happens only on kernel 2.6.23 ... Could you tell me how I can create informations for you to help fixing? Is there a tool or should I install a debug kernel? Thanks, Thomas
Installing a debug kernel is a good first step...
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Were you able to install the debug kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
Hello, the problem why there is not much activity since creating this bug, the crash was occured only two times and then not with the newest kernel. I've switched to the newest one (2.6.23.12-52.fc7) some days ago and wait ... Btw about the debug kernel: I've installed it (2.6.23.12-52) also. Have I do anything else then booting with em? Regards, Thomas
Wait and see if you still encounter issues with the latest kernel. If you do then it would be time to troubleshoot this bug. If you do have the problem come back, you could also take a look at: http://fedoraproject.org/wiki/KernelCommonProblems
Hi, now I've this issue very often with kernel 2.6.23.15-80. I've installed the debug kernel and set him as the standard kernel but after crash and reboot I have seen nothing in /var/log/messages. Is there another place where I can find information? Or should I activate some more to get a crash dump or something else? These are my kernel parameters: kernel /boot/vmlinuz-2.6.23.15-80.fc7debug ro root=LABEL=/ initcall_debug Regards, Thomas
Do you have another computer than you can use to try and shell into the locking box from? You could also try sysrq to get some info. Enable it with sysctl kernel.sysrq=1 (or put kernel.sysrq = 1 in your /etc/sysctl.conf). This will allow you to hit ctrl-alt-sysrq plus one of the following keys to get debugging info: m will dump information about the current state of memory t will dump the state of every task the kernel knows about p will dump the current processor state (useful when a process is looping inside the kernel s will sync all data pending writeback to disk. (This is useful so that this debug info actually stands a chance of hitting the log files.) Could you also attach output of: lsmod > lsmod.out dmesg > dmesg.out as separate text/plain attachments. You could also see if the problem is twinkle or kernel by testing with ekiga perhaps. Lastly you could test with a rawhide kernel.
Hi, unfortunately ctrl-alt-sysrq (the print key?) plus s doesn't work. I think there's a kernel panic cause all LED's on my laptop blinking. All what I can do then is power off the laptop ... About taking ekiga: It doesn't work inside the company because I need a special feature from twinkle which is not present in ekiga. About your tip with a shell from another computer: do you mean log in via ssh? If a kernel panic occurs I have no possibility to get information via another computer then. Or do you mean another possibility? If so, please give me a description how to do this. thanks. Btw. I can reproduce it always now - after 12 minutes the crash occurs Regards, Thomas
Please attach the following as separate text/plain attachments: lsmod > lsmod.out # lspci -vvxxx > lspci.out dmesg > dmesg.out I will then assign this bug for kernel developers to review. I'm copying in the Fedora Twinkle maintainer as he might have some input here also. Regards Chris
Odd. I can't think of why twinkle would cause a system lockup... This is F7, so no pulseaudio in the mix, should just be opening and use alsa like any other application. :(
Created attachment 295781 [details] dmesg output before crash
Created attachment 295782 [details] lsmod output
Created attachment 295783 [details] lspci -vvxxx
Hi, I've created a crash dump with kdump (http://fedoraproject.org/wiki/FC6KdumpKexecHowTo) but it's very big (2 GB). Is there a possibility to upload it ? Unfortunately no kernel-debuginfos are available for kernel 2.6.23.15-80. Only for PAE kernel. So, I couldn't do the last step with crash command. Therefore, I don't know if the dump is then helpful... Regards, Thomas
(In reply to comment #13) > Hi, > > I've created a crash dump with kdump > (http://fedoraproject.org/wiki/FC6KdumpKexecHowTo) but it's very big (2 GB). Is > there a possibility to upload it ? Unfortunately no kernel-debuginfos are > available for kernel 2.6.23.15-80. Only for PAE kernel. So, I couldn't do the > last step with crash command. Therefore, I don't know if the dump is then helpful... The debuginfo is available for i686 and i586 base kernels. kernel-debuginfo-2.6.23.15-80.fc7.i686.rpm
Hi, now I've got a valid crashdump with the actual installed kernel. Here's the complete output of the crash util: [root@tfunk-nb 2008-03-26-14:19]# crash /usr/lib/debug/lib/modules/2.6.23.17-82.fc7/vmlinux vmcore crash 4.0-6.0.5 Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc. : : This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. : : This GDB was configured as "i686-pc-linux-gnu"... KERNEL: /usr/lib/debug/lib/modules/2.6.23.17-82.fc7/vmlinux DUMPFILE: vmcore CPUS: 1 DATE: Wed Mar 26 14:18:47 2008 UPTIME: 00:16:20 LOAD AVERAGE: 0.20, 0.15, 0.22 TASKS: 217 NODENAME: tfunk-nb RELEASE: 2.6.23.17-82.fc7 VERSION: #1 SMP Thu Feb 28 16:22:02 EST 2008 MACHINE: i686 (798 Mhz) MEMORY: 2 GB PANIC: "kernel BUG at lib/list_debug.c:33!" PID: 0 COMMAND: "swapper" TASK: c06f5340 [THREAD_INFO: c0738000] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt PID: 0 TASK: c06f5340 CPU: 0 COMMAND: "swapper" #0 [c07a6ce8] crash_kexec at c0451c6c #1 [c07a6d30] die at c040680e #2 [c07a6d54] do_invalid_op at c0406b21 #3 [c07a6df0] error_code (via invalid_op) at c061d7a0 EAX: 00000061 EBX: f6e8d414 ECX: 00000086 EDX: 00000000 EBP: f7ee4e34 DS: 007b ESI: f6e8d894 ES: 007b EDI: 00000246 CS: 0060 EIP: c04f71c9 ERR: ffffffff EFLAGS: 00010086 #4 [c07a6e24] __list_add at c04f71c9 #5 [c07a6e44] usb_hcd_submit_urb at c057a421 #6 [c07a6f08] snd_complete_urb at f8a3ae7f #7 [c07a6f1c] usb_hcd_giveback_urb at c05797ce #8 [c07a6f2c] ehci_urb_done at f8828614 #9 [c07a6f3c] ehci_work at f8829bbc #10 [c07a6fa0] ehci_irq at f882c87a #11 [c07a6fcc] usb_hcd_irq at c0579a3e #12 [c07a6fd4] handle_IRQ_event at c045a4e5 #13 [c07a6fe8] handle_fasteoi_irq at c045b7f9 crash> As I am not proficient in using crash I don't know if the information is enough for you. For more detailed crash outputs you should help me. Thanks. Thomas
Are you using a USB audio device to make the phone call?
Yes. A GN Netcom GN8110 USB headset with DSPs. /var/log/messages: Apr 21 10:29:20 localhost kernel: usb 5-2.4: new full speed USB device using ehci_hcd and address 6 Apr 21 10:29:20 localhost kernel: usb 5-2.4: configuration #1 chosen from 1 choice Apr 21 10:29:20 localhost kernel: input: GN Netcom GN 8110 USB as /class/input/input11 Apr 21 10:29:20 localhost kernel: input: USB HID v1.00 Device [GN Netcom GN 8110 USB] on usb-0000:00:1d.7-2.4
Hi, I've reproduced the issue with kernel 2.6.24 (from F8). Here's the output of crash util: KERNEL: /usr/lib/debug/lib/modules/2.6.24.2-4.fc8/vmlinux DUMPFILE: vmcore CPUS: 1 DATE: Tue Apr 29 12:25:36 2008 UPTIME: 02:54:45 LOAD AVERAGE: 0.00, 0.06, 0.05 TASKS: 226 NODENAME: tfunk-nb RELEASE: 2.6.24.2-4.fc8 VERSION: #1 SMP Sat Feb 16 11:48:33 EST 2008 MACHINE: i686 (798 Mhz) MEMORY: 2 GB PANIC: "kernel BUG at lib/list_debug.c:33!" PID: 0 COMMAND: "swapper" TASK: c07103c0 [THREAD_INFO: c074b000] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt PID: 0 TASK: c07103c0 CPU: 0 COMMAND: "swapper" #0 [c07babf8] crash_kexec at c0454785 #1 [c07bac40] die at c0406743 #2 [c07bac64] do_invalid_op at c0406a27 #3 [c07bad00] error_code (via invalid_op) at c062cda8 EAX: 00000061 EBX: f61cb014 ECX: 00000096 EDX: 00000000 EBP: 00000001 DS: 007b ESI: f61cb394 ES: 007b EDI: f638e180 CS: 0060 EIP: c0502371 ERR: ffffffff EFLAGS: 00010092 #4 [c07bad34] __list_add at c0502371 #5 [c07bad54] usb_hcd_link_urb_to_ep at c058513a #6 [c07bad60] ehci_urb_enqueue at f8834ac0 #7 [c07bae34] usb_hcd_submit_urb at c0586041 #8 [c07baeec] snd_complete_urb at f89ec378 #9 [c07baf10] usb_hcd_giveback_urb at c0584ecb #10 [c07baf24] ehci_urb_done at f8831615 #11 [c07baf3c] ehci_work at f8832c01 #12 [c07bafa0] ehci_irq at f88359b7 #13 [c07bafcc] usb_hcd_irq at c0585195 #14 [c07bafd4] handle_IRQ_event at c0460a29 #15 [c07bafe8] handle_fasteoi_irq at c0461d50 Thomas
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
OK, this is not only F7, so moving to F8 (at least). I wish this could be tested with F9 though... I'm sorry for ignoring this and making Chuck do the work. Just really being swamped with usb-serial, OHCI and things like that.
I could try it on my test installation of F9. But sadly F9 is not usable for daily working ... Here some things I've done in the past to check when the crash occurs (or not): It appears faster if I use seamless rdp to open Window apps under linux (I use it to work daily with Outlook and Word). But unfortunately it appears also without seamles rdp - it tooks only longer to crash. At the moment I use OWA via browser - so the crashes are reduced to 70% - but happens sporadically anyway. Then I have set "noacpi" but no changes. I've tried without a swap partition. After a while of phoning the heard sound began to chop and then (after 2 or 3 sec) crash. I've began to check the mem usage with conky on the second screen but it happens not after the available mem was full! I think there was 500 or 700 MB of 2G free. Unfortunately it often crashes when a app was over conky ... Therefore I've checked with memtest the ram. But no errors occur after 4 hours, so I stopped the test. I can check more if someone has ideas cause it's very important for me that this error will be fixed - daily working is very hard with constantly crashs and needed reboots. Thanks, Thomas
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.