On Mon, 2005-05-09 at 07:31 -0700, David Brownell wrote:
> On Monday 09 May 2005 2:25 am, John Steele Scott wrote:
> > On Sun, 2005-05-08 at 13:13 -0700, David Brownell wrote:
> 
> > Just to follow up on this, I just recently had the following oops:
> > 
> > Oops: kernel access of bad area, sig: 11 [#1]
> > NIP: DA50DEE8 LR: DA4A2498 SP: D3173D90 REGS: d3173ce0 TRAP: 0300    Not 
> > tainted
> > MSR: 0200b032 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 11
> > DAR: 000018A8, DSISR: 40000000
> > TASK = d7ae4110[4325] 'pbbuttonsd' THREAD: d3172000
> > Last syscall: 54
> > GPR00: 00000000 D3173D90 D7AE4110 00000000 00000010 00000001 C0330F4C 
> > C0330DDC
> > GPR08: 00000000 00000000 DA518850 D54216D8 28000482 10026C18 100C0000 
> > 100A0000
> > GPR16: 00000000 100D7408 28222482 100C0000 100D6F28 100D6AE8 10001180 
> > 1000BF7C
> > GPR24: C02B0000 C02DAF5C C02E0000 C02E0000 C02DAF54 D5421768 C02B5648 
> > D54216D8
> > NIP [da50dee8] hid_resume+0x20/0x48 [usbhid]
> 
> And what's at that location?  Presumably it doesn't happen if you
> disconnect the HID device before suspend?  Is this with or without
> CONFIG_USB_SUSPEND?

00002ec8 <hid_resume>:
    2ec8:       94 21 ff f0     stwu    r1,-16(r1)
    2ecc:       7c 08 02 a6     mflr    r0
    2ed0:       38 80 00 10     li      r4,16
    2ed4:       90 01 00 14     stw     r0,20(r1)
    2ed8:       38 00 00 00     li      r0,0
    2edc:       90 03 00 94     stw     r0,148(r3)
    2ee0:       81 23 00 8c     lwz     r9,140(r3)
    2ee4:       38 60 00 00     li      r3,0
    2ee8:       80 09 18 a8     lwz     r0,6312(r9)    <---- bogus load?
    2eec:       2c 00 00 00     cmpwi   r0,0
    2ef0:       40 82 00 14     bne-    2f04 <hid_resume+0x3c>
    2ef4:       80 01 00 14     lwz     r0,20(r1)
    2ef8:       38 21 00 10     addi    r1,r1,16
    2efc:       7c 08 03 a6     mtlr    r0
    2f00:       4e 80 00 20     blr
    2f04:       80 69 0c 54     lwz     r3,3156(r9)
    2f08:       48 00 00 01     bl      2f08 <hid_resume+0x40>
    2f0c:       4b ff ff e8     b       2ef4 <hid_resume+0x2c>

This is consistent with Ben's comments.

I can try sleeping it with the mouse disconnected over the next couple
of days. It seems to me that the oops is more likely to occur when
sleeping for a long period, such as overnight, or during the day when I
am at work. So far, long sleeps have always resulted in the oops,
whereas short sleeps have given an oops only once out of maybe seven or
eight tries.

CONFIG_USB_SUSPEND was NOT set.

By the way, I tried to use ksymoops to get some better information
yesterday, but I don't have a /proc/ksyms. Is that normal, or is there a
configuration switch somewhere I should turn on?

cheers,

John

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to