iMX31 USB Oops on kernel 2.6.19.2

[hong zhang <henryzhang62@xxxxxxxxx>]

Alan,

Running mkfs.ext3 -j /dev/sda1 for usb scsi hard disk
on freescale iMX31(ARM) will get kernel panic. As you
suggested, I did find out statement in offending
function start_unlink_async. But I could not find
which register has 0 value. I try to add printk but it
does not print out when kernel panic occurs in
2.6.19.2. It has no problem in 2.6.10 for myself. And
another people in arm kernel list says 2.6.16 is Ok
but 2.6.19 has similar problem.

I met two kernel panic see item A (line 1016) and
B(line 155).

A. This is offset 0x40
[00000000] *pgd=83b89031, *pte=00000000,
*ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in:
CPU: 0
PC is at start_unlink_async+0x40/0x14c
LR is at ehci_work+0x13c/0x6a4
pc : [<c0174d78>]    lr : [<c0175e28>]    Not tainted
sp : c3b33e48  ip : c3b33e68  fp : c3b33e64

1. run gdb vmlinux
(gdb) disassemble start_unlink_async
Dump of assembler code for function
start_unlink_async:
0xc0174d38 <start_unlink_async+0>:      mov     r12,
sp
0xc0174d3c <start_unlink_async+4>:      stmdb   sp!,
{r4, r5, r6, r11, r12, lr, pc}
0xc0174d40 <start_unlink_async+8>:      sub     r11,
r12, #4    ; 0x4
0xc0174d44 <start_unlink_async+12>:     sub     sp,
sp, #4      ; 0x4
0xc0174d48 <start_unlink_async+16>:     ldr     r2,
[r0, #4]
0xc0174d4c <start_unlink_async+20>:     ldr     r3,
[r0, #20]
0xc0174d50 <start_unlink_async+24>:     mov     r4, r0
0xc0174d54 <start_unlink_async+28>:     cmp     r3, #0
 ; 0x0
0xc0174d58 <start_unlink_async+32>:     mov     r5, r1
0xc0174d5c <start_unlink_async+36>:     ldr     r6,
[r2]
0xc0174d60 <start_unlink_async+40>:     bne    
0xc0174d74 <start_unlink_async+60>
0xc0174d64 <start_unlink_async+44>:     ldrb    r3,
[r1, #104]
0xc0174d68 <start_unlink_async+48>:     cmp     r3, #1
 ; 0x1
0xc0174d6c <start_unlink_async+52>:     cmpne   r3, #4
 ; 0x4
0xc0174d70 <start_unlink_async+56>:     beq    
0xc0174d88 <start_unlink_async+80>
0xc0174d74 <start_unlink_async+60>:     ldr     r0,
[pc, #272]  ; 0xc0174e8c <$d>

2. Find address of 0x40 is 0xc0174d60
(gdb) l *0xc0174d60
0xc0174d60 is in start_unlink_async (ehci-q.c:1016).
1011            struct ehci_qh  *prev;
1012
1013    #ifdef DEBUG
1014            assert_spin_locked(&ehci->lock);
1015
1016            if (ehci->reclaim
1017                            || (qh->qh_state !=
QH_STATE_LINKED
1018                                    &&
qh->qh_state != QH_STATE_UNLINK_WAIT)1019             
              )
1020            {
(gdb)

As indicated above line 1016 is place causing kernel
panic.

B.
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0
PC is at __mod_timer+0x60/0xec
LR is at lock_timer_base+0x3c/0x74
pc : [<c0049f20>]    lr : [<c0049df8>]    Not tainted
sp : c387f828  ip : c387f808  fp : c387f84c
r10: c020e5ac  r9 : c387e000  r8 : 00000000

(gdb) disassemble __mod_timer
Dump of assembler code for function __mod_timer:
0xc004a004 <__mod_timer+0>:     mov     r12, sp
0xc004a008 <__mod_timer+4>:     stmdb   sp!, {r4, r5,
r6, r7, r11, r12, lr, pc}
0xc004a00c <__mod_timer+8>:     sub     r11, r12, #4  
 ; 0x4
0xc004a010 <__mod_timer+12>:    sub     sp, sp, #8    
 ; 0x8
0xc004a014 <__mod_timer+16>:    ldr     r3, [r0, #12]
0xc004a018 <__mod_timer+20>:    mov     r6, r1
0xc004a01c <__mod_timer+24>:    cmp     r3, #0  ; 0x0
0xc004a020 <__mod_timer+28>:    streq   r3, [r3]
0xc004a024 <__mod_timer+32>:    sub     r1, r11, #32  
 ; 0x20
0xc004a028 <__mod_timer+36>:    mov     r4, r0
0xc004a02c <__mod_timer+40>:    bl      0xc0049b70
<lock_timer_base>
0xc004a030 <__mod_timer+44>:    ldr     r2, [r4]
0xc004a034 <__mod_timer+48>:    cmp     r2, #0  ; 0x0
0xc004a038 <__mod_timer+52>:    moveq   r7, r2
0xc004a03c <__mod_timer+56>:    ldrne   r3, [r4, #4]
0xc004a040 <__mod_timer+60>:    movne   r7, #1  ; 0x1
0xc004a044 <__mod_timer+64>:    strne   r3, [r2, #4]
0xc004a048 <__mod_timer+68>:    strne   r2, [r3]
0xc004a04c <__mod_timer+72>:    ldrne   r3, [pc, #148]
 ; 0xc004a0e8 <$d>
0xc004a050 <__mod_timer+76>:    strne   r3, [r4, #4]
0xc004a054 <__mod_timer+80>:    ldr     r3, [pc, #144]
 ; 0xc004a0ec <$d+4>
0xc004a058 <__mod_timer+84>:    ldr     r5, [r3]

(gdb) l *0xc004a040
0xc004a040 is in __mod_timer (kernel/timer.c:155).
150             struct list_head *entry =
&timer->entry;
151
152             __list_del(entry->prev, entry->next);
153             if (clear_pending)
154                     entry->next = NULL;
155             entry->prev = LIST_POISON2;
156     }
157
158     /*
159      * We are using hashed locking: holding
per_cpu(tvec_bases).lock
(gdb)

Line 155 is problem.

---henry


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel