On Thursday 25 August 2005 20.43, Alan Stern wrote:
> On Wed, 24 Aug 2005, Pete Zaitcev wrote:
>
> >
> > Bouncing this to linux-usb-devellist. Seems like something non-specific
> > to usb-storage.
> >
> > -- Pete
> >
> > Date: Tue, 23 Aug 2005 13:25:10 +0200
> > From: Jens Axboe <[EMAIL PROTECTED]>
> >
> > usbcore: deregistering driver usb-storage
> > usb 1-1: USB disconnect, address 3
> > Unable to handle kernel NULL pointer dereference at 0000000000000000
> > RIP:
> > <ffffffff803cf140>{_spin_lock+0}
> > PGD 1c303067 PUD 1c304067 PMD 0
> > Oops: 0002 [1] SMP
> > CPU 0
> > Modules linked in: nls_iso8859_1 nls_cp437 vfat fat nls_base ide_cd
> > cdrom
> > Pid: 80, comm: khubd Not tainted 2.6.13-rc6-mm2
> > RIP: 0010:[<ffffffff803cf140>] <ffffffff803cf140>{_spin_lock+0}
> > RSP: 0018:ffff81001fc75d80 EFLAGS: 00010296
> > RAX: ffff81001c08cdb0 RBX: ffff810019f5f8f8 RCX: ffff81001c4b14e8
> > RDX: 0000000000000070 RSI: ffffffff8040cfcc RDI: 0000000000000000
> > RBP: ffff810019f5f8a0 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000001 R11: ffffffff8018ad27 R12: 0000000000000000
> > R13: ffff810001a23c20 R14: ffff810001a23c00 R15: 0000000000000100
> > FS: 00002aaaaade8b00(0000) GS:ffffffff80612880(0000)
> > knlGS:0000000061ad4bb0
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000000000 CR3: 000000001c302000 CR4: 00000000000006e0
> > Process khubd (pid: 80, threadinfo ffff81001fc74000, task
> > ffff8100019f4e80)
> > Stack: ffffffff803cd130 ffffffff80500aa0 ffff810019f5f980
> > ffffffff80500aa0
> > ffffffff802a3263 ffff810019f5f9e8 ffff810019f5f8a0
> > ffff810019f5f8a0
> > ffffffff802a34f2 ffffffff80500880
> > Call Trace:<ffffffff803cd130>{klist_remove+21}
> > <ffffffff802a3263>{__device_release_driver+75}
> > <ffffffff802a34f2>{device_release_driver+39}
> > <ffffffff802a2db7>{bus_remove_device+146}
> > <ffffffff802a1f75>{device_del+55}
> > <ffffffff802a1fbc>{device_unregister+9}
> > <ffffffff802ff51c>{hub_thread+900}
> > <ffffffff80145e70>{autoremove_wake_function+0}
> > <ffffffff802ff198>{hub_thread+0}
> > <ffffffff80145a70>{keventd_create_kthread+0}
> > <ffffffff80145c9e>{kthread+203}
> > <ffffffff8012e3ae>{schedule_tail+57}
> > <ffffffff8010e6ce>{child_rip+8}
> > <ffffffff80145a70>{keventd_create_kthread+0}
> > <ffffffff80145bd3>{kthread+0} <ffffffff8010e6c6>{child_rip+0}
> >
> >
> > Code: f0 fe 0f 79 09 f3 90 80 3f 00 7e f9 eb f2 c3 f0 ff 0f 8b 07
> > RIP <ffffffff803cf140>{_spin_lock+0} RSP <ffff81001fc75d80>
> > CR2: 0000000000000000
> >
> > Just got this oops removing a usb-storage managed usb device.
> > usb-storage had been manually removed (as you can see from the kernel
> > message), a few seconds later I removed power from the device and the
> > oopsed happened right then.
>
> The oops was caused by this patch:
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm2/broken-out/driver-core-fix-bus_rescan_devices-race.patch
>
> Reverting it should fix the problem.
>
> In the changelog entry for that patch, Daniel Ritz wrote:
>
> device_attach() holds the sem, but calls again
> device_bind_driver() even when dev->driver is set (which means
> device is already bound to a driver).
>
> The remark in parenthesis is wrong. dev->driver can be set when calling
> device_add, at which time the device obviously is not already bound to a
> driver. When this is done, device_attach will automatically bind the
> device to dev->driver.
yeah, i noticed that too. see my answer in:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112481438512222&w=2
it's the easiest way to 'fix' the race by allowing a call to
device_bind_driver()
even if the device is already bound. fixes my rmmod hang and shoudln't mess
with USB. comment is updated too :)
what do you think about that as a short term fix?
>
> The comments in the changelog about races are correct, however. Daniel,
> take a look at this email:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112414102531138&w=2
>
yes, i already found that but didn't look closer. i needed a quick fix
because i was debugging a pcmcia problem.
> It makes a start at cleaning up that whole situation. I've begun a
> second patch to remove the races you described but it's not finished, for
> reasons described in the follow-up messages to the one above. If you're
> interested in working more on this, please get back to me.
>
may be.
> Alan Stern
>
>
rgds
-daniel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
