Bug 408531 - System crash while calling via sip
System crash while calling via sip
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-03 05:31 EST by Thomas Funk
Modified: 2009-01-09 00:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 00:24:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output before crash (71.02 KB, text/plain)
2008-02-25 04:31 EST, Thomas Funk
no flags Details
lsmod output (3.55 KB, text/plain)
2008-02-25 04:32 EST, Thomas Funk
no flags Details
lspci -vvxxx (28.81 KB, text/plain)
2008-02-25 04:33 EST, Thomas Funk
no flags Details

  None (edit)
Description Thomas Funk 2007-12-03 05:31:27 EST
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
Comment 1 Chuck Ebbert 2007-12-04 19:14:32 EST
Installing a debug kernel is a good first step...
Comment 2 Christopher Brown 2008-01-15 23:40:01 EST
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.
Comment 3 Thomas Funk 2008-01-18 05:17:02 EST
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
Comment 4 Christopher Brown 2008-01-18 06:41:39 EST
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
Comment 5 Thomas Funk 2008-02-15 07:23:49 EST
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
Comment 6 Christopher Brown 2008-02-15 10:54:12 EST
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.
Comment 7 Thomas Funk 2008-02-19 07:42:49 EST
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
Comment 8 Christopher Brown 2008-02-24 10:43:37 EST
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
Comment 9 Kevin Fenzi 2008-02-24 11:31:46 EST
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. :( 
Comment 10 Thomas Funk 2008-02-25 04:31:22 EST
Created attachment 295781 [details]
dmesg output before crash
Comment 11 Thomas Funk 2008-02-25 04:32:17 EST
Created attachment 295782 [details]
lsmod output
Comment 12 Thomas Funk 2008-02-25 04:33:22 EST
Created attachment 295783 [details]
lspci -vvxxx
Comment 13 Thomas Funk 2008-02-25 04:39:18 EST
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
Comment 14 Chuck Ebbert 2008-02-25 16:34:55 EST
(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
Comment 15 Thomas Funk 2008-03-26 10:46:20 EDT
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
Comment 16 Chuck Ebbert 2008-04-18 17:15:22 EDT
Are you using a USB audio device to make the phone call?
Comment 17 Thomas Funk 2008-04-21 04:30:27 EDT
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
Comment 18 Thomas Funk 2008-04-29 08:43:45 EDT
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
Comment 19 Bug Zapper 2008-05-14 11:08:05 EDT
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
Comment 20 Pete Zaitcev 2008-05-27 15:50:54 EDT
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.
Comment 21 Thomas Funk 2008-05-29 11:04:07 EDT
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
Comment 22 Bug Zapper 2008-11-26 03:48:02 EST
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
Comment 23 Bug Zapper 2009-01-09 00:24:27 EST
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.

Note You need to log in before you can comment on or make changes to this bug.