> > EIP is at hcd_pci_release+0x19/0x20 [usbcore]
> I don't understand this stack dump. The EIP address is _after the end_ of
> hcd_pci_release, as you can see from the fact that the following code is
> nothing but a long string of NOPs.
Hi Alan, I'm not sure what you mean. 0x19/0x20 seems to be inside the code
to me :) On my machine, this is what it corresponds to:
static void hcd_pci_release(struct usb_bus *bus)
{
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 04 sub $0x4,%esp
struct usb_hcd *hcd = bus->hcpriv;
6: 8b 45 08 mov 0x8(%ebp),%eax
9: 8b 50 30 mov 0x30(%eax),%edx
if (hcd)
c: 85 d2 test %edx,%edx
e: 74 0c je 1c <hcd_pci_release+0x1c>
hcd->driver->hcd_free(hcd);
10: 8b 82 38 01 00 00 mov 0x138(%edx),%eax
16: 89 14 24 mov %edx,(%esp,1)
19: ff 50 28 call *0x28(%eax) <= HERE
}
1c: c9 leave
1d: c3 ret
1e: 89 f6 mov %esi,%esi
So if Vince's disassembly is the same, the problem is that
hcd->driver or hcd->driver->hcd_free is stuffed.
> Also, I don't understand the cause of
> the oops. What does the PREEMPT mean? There's no indication that a null
> pointer was dereferenced. None of the registers contains 0.
I guess PREEMPT means it's a kernel with preempt support. There is
indeed no indication that a NULL pointer was dereferenced. Maybe it
is use-after-free.
> But if you think that's the problem, try adding a printk to
> hcd_pci_release to display the values of bus, hcd->driver, and
> hcd->driver->hcd_free. Knowing which one is NULL ought to help your
> analysis.
I will send Vince a patch.
Ciao,
Duncan.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
