AnsweredAssumed Answered

i.MX53 system not responding - using Magic KeyReq

Question asked by Chris Ruehl on Feb 28, 2013
Branched to a new discussion

Hi All !

 

may you had stuck in a similar problem before and give me a hint on this.

We running a 2.6.35.14 kernel with freescale patches and system become randomly not responding

serial console, fb all frozen.

Magic KeyReq  ALT+CTRL+SysReq+<...> give me some idea what happened (see attachment):

 

We have 2 Gstreamer pipes running  a) Audio (audio-pipe)  b) Video (video-pipe) both pipes run in its own thread and are fully

independent. If a video is running on the video-pipe, we mute it by set volume to 0  and use  the audio-pipe to play an announcement.

 

Randomly its happen that the system hangs. We get out some infos from the Kernel using the SysReq  (see below)

may you can bring light into darkness.

 

Complete prints attached.

 

cheers

Chris

 

 

Pid: 2325, comm:            alsa-sink

CPU: 0    Not tainted  (2.6.35.14-ge79684d-dirty #721)

PC is at 0x2ab02018

LR is at 0x2ab02d00

pc : [<2ab02018>]    lr : [<2ab02d00>]    psr: 20000010

sp : 2f759c88  ip : 00000000  fp : 0006ec84

r10: 00000000  r9 : 00000000  r8 : 00000001

r7 : 00000000  r6 : 000b5e70  r5 : 00000001  r4 : 0006ddc8

r3 : 2ab02018  r2 : 00000000  r1 : 00000000  r0 : 000b5e70

Flags: nzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user

Control: 10c5387d  Table: cfb84019  DAC: 00000015

SysRq : Show clockevent devices & pending hrtimers (no others)

Timer List Version: v0.6

HRTIMER_MAX_CLOCK_BASES: 2

now at 69744121976361 nsecs

 

and

 

alsa-sink     R running      0  2325      1 0x00000000

[<8002e578>] (unwind_backtrace+0x0/0xf0) from [<8002d88c>] (show_stack+0x10/0x14)

[<8002d88c>] (show_stack+0x10/0x14) from [<8004cb9c>] (show_state_filter+0x58/0xb0)

[<8004cb9c>] (show_state_filter+0x58/0xb0) from [<80247470>] (__handle_sysrq+0xdc/0x1a4)

[<80247470>] (__handle_sysrq+0xdc/0x1a4) from [<80247620>] (sysrq_filter+0xb4/0xc8)

[<80247620>] (sysrq_filter+0xb4/0xc8) from [<802d0254>] (input_pass_event+0x9c/0xec)

[<802d0254>] (input_pass_event+0x9c/0xec) from [<802d23ec>] (input_event+0x74/0xa4)

[<802d23ec>] (input_event+0x74/0xa4) from [<8032d26c>] (hidinput_hid_event+0x2dc/0x330)

[<8032d26c>] (hidinput_hid_event+0x2dc/0x330) from [<80329354>] (hid_process_event+0xfc/0x148)

[<80329354>] (hid_process_event+0xfc/0x148) from [<80329908>] (hid_report_raw_event+0x568/0x58c)

[<80329908>] (hid_report_raw_event+0x568/0x58c) from [<80329abc>] (hid_input_report+0x190/0x1cc)

[<80329abc>] (hid_input_report+0x190/0x1cc) from [<8032eef8>] (hid_irq_in+0x94/0x24c)

[<8032eef8>] (hid_irq_in+0x94/0x24c) from [<802b09d8>] (usb_hcd_giveback_urb+0x70/0xb8)

[<802b09d8>] (usb_hcd_giveback_urb+0x70/0xb8) from [<802bf570>] (ehci_urb_done+0xac/0xc8)

[<802bf570>] (ehci_urb_done+0xac/0xc8) from [<802bf974>] (qh_completions+0x3e8/0x474)

[<802bf974>] (qh_completions+0x3e8/0x474) from [<802c0d7c>] (ehci_work+0x2e8/0x9d4)

[<802c0d7c>] (ehci_work+0x2e8/0x9d4) from [<802c3aac>] (ehci_irq+0x1e4/0x22c)

[<802c3aac>] (ehci_irq+0x1e4/0x22c) from [<802b03b0>] (usb_hcd_irq+0x38/0x90)

[<802b03b0>] (usb_hcd_irq+0x38/0x90) from [<80087708>] (handle_IRQ_event+0x24/0xe4)

[<80087708>] (handle_IRQ_event+0x24/0xe4) from [<80089808>] (handle_level_irq+0xd4/0x180)

[<80089808>] (handle_level_irq+0xd4/0x180) from [<8002906c>] (asm_do_IRQ+0x6c/0x8c)

[<8002906c>] (asm_do_IRQ+0x6c/0x8c) from [<80029a8c>] (__irq_svc+0x4c/0xcc)

Exception stack(0xdfd13b70 to 0xdfd13bb8)

3b60:                                     dfd13bd4 00000000 dfd13e50 00000004

3b80: 00000000 00000001 00000000 dfd13e50 00000001 00000000 00000000 0006e368

3ba0: 159720e0 dfd13bb8 800d12a4 800d0f20 20000013 ffffffff

[<80029a8c>] (__irq_svc+0x4c/0xcc) from [<800d0f20>] (poll_freewait+0x0/0x6c)

[<800d0f20>] (poll_freewait+0x0/0x6c) from [<00000001>] (0x1)

Original Attachment has been moved to: alsa_sink-crash.log.zip

Outcomes