LORs in RELENG_7

Ulrich Spoerlein uspoerlein at gmail.com
Fri Nov 21 09:47:44 PST 2008


On Thu, 20.11.2008 at 15:22:04 -0800, Sean Bruno wrote:
> > And there are these LORs when I shut down my external firewire attached
> > disk:
> >
> > fwohci0: BUS reset
> > fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode
> > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
> > firewire0: bus manager 1 (me)
> > uma_zalloc_arg: zone "16" with the following non-sleepable locks held:
> > exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26
> > kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29
> > witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7
> > uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34
> > malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2
> > notify(c4150a00,4,c08d7856,34f,c05be4ea,...) at notify+0x49
> > destroy_devl(f93a9410,c046a6ce,c4150a00,0,c3f18370,...) at destroy_devl+0x236
> > destroy_dev(c4150a00,0,c3f18370,c3f69000,f93a9690,...) at destroy_dev+0x10
> > passcleanup(c3f69000,c08b50c7,0,0,0,...) at passcleanup+0x2e
> > camperiphfree(c3f69000,0,f93a96b0,c04568dd,c3f69000,...) at camperiphfree+0xbb
> > cam_periph_invalidate(c3f69000,c0983774,f93a96e4,c046a5ea,c3f69000,...) at cam_periph_invalidate+0x3e
> > cam_periph_async(c3f69000,100,c418a260,0,f93a96e0,...) at cam_periph_async+0x2d
> > passasync(c3f69000,100,c418a260,0,c42f8c00,...) at passasync+0xca
> > xpt_async_bcast(0,4,c08b53c5,11a5,c404d280,...) at xpt_async_bcast+0x32
> > xpt_async(100,c418a260,0,89b,0,...) at xpt_async+0x194
> > sbp_cam_detach_sdev(c402f45c,0,c402f418,0,f93a982c,...) at sbp_cam_detach_sdev+0xa4
> > sbp_cam_detach_target(c14729a8,c14729a8,c08250c6,c7373b40,10,...) at sbp_cam_detach_target+0x5b
> > sbp_post_explore(c402f400,f93a9ce8,f93a9ce4,675,0,...) at sbp_post_explore+0xa2
> > fw_bus_probe_thread(c404f000,f93a9d38,c08d8d0f,31c,c402b570,...) at fw_bus_probe_thread+0x69b
> > fork_exit(c0513500,c404f000,f93a9d38) at fork_exit+0xb8
> > fork_trampoline() at fork_trampoline+0x8
> > --- trap 0, eip = 0, esp = 0xf93a9d70, ebp = 0 ---
> > (da0:sbp0:0:0:0): lost device
> > (da0:sbp0:0:0:0): removing device entry
> > cam_periph_alloc: attempt to re-allocate valid device pass1 rejected
> > passasync: Unable to attach new device due to status 0x6: CCB request was invalid
> > cam_periph_alloc: attempt to re-allocate valid device da1 rejected
> > daasync: Unable to attach to new device due to status 0x6
> > fwohci0: BUS reset
> > fwohci0: node_id=0xc800ffc0, gen=3, CYCLEMASTER mode
> > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
> > firewire0: bus manager 0 (me)
> > uma_zalloc_arg: zone "16" with the following non-sleepable locks held:
> > exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26
> > kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29
> > witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7
> > uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34
> > malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2
> > notify(c4150d00,4,c08d7856,34f,c05be4ea,...) at notify+0x49
> > destroy_devl(f93a9410,c046a6ce,c4150d00,0,c3f18370,...) at destroy_devl+0x236
> > destroy_dev(c4150d00,0,c3f18370,c42c6700,f93a9690,...) at destroy_dev+0x10
> > passcleanup(c42c6700,c08b50c7,c09eff00,4,c08db41b,...) at passcleanup+0x2e
> > camperiphfree(c42c6700,0,f93a96b0,c04568dd,c42c6700,...) at camperiphfree+0xbb
> > cam_periph_invalidate(c42c6700,c0983774,f93a96e4,c046a5ea,c42c6700,...) at cam_periph_invalidate+0x3e
> > cam_periph_async(c42c6700,100,c418a250,0,f93a96e0,...) at cam_periph_async+0x2d
> > passasync(c42c6700,100,c418a250,0,c42f8a00,...) at passasync+0xca
> > xpt_async_bcast(0,4,c08b53c5,11a5,c404d280,...) at xpt_async_bcast+0x32
> > xpt_async(100,c418a250,0,89b,0,...) at xpt_async+0x194
> > sbp_cam_detach_sdev(c402f4c8,0,c402f484,1,f93a982c,...) at sbp_cam_detach_sdev+0xa4
> > sbp_cam_detach_target(c14729a8,c14729a8,c08250c6,c44263f0,10,...) at sbp_cam_detach_target+0x5b
> > sbp_post_explore(c402f400,f93a9ce8,f93a9ce4,675,0,...) at sbp_post_explore+0xa2
> > fw_bus_probe_thread(c404f000,f93a9d38,c08d8d0f,31c,c402b570,...) at fw_bus_probe_thread+0x69b
> > fork_exit(c0513500,c404f000,f93a9d38) at fork_exit+0xb8
> > fork_trampoline() at fork_trampoline+0x8
> > --- trap 0, eip = 0, esp = 0xf93a9d70, ebp = 0 ---
> > (da1:sbp0:0:1:0): lost device
> > (da1:sbp0:0:1:0): removing device entry
> >
> > I reckon these problems should appear in -STABLE ...

"shouldn't"

> You are able to make this happen simply by powering off your Firewire 
> Hard Drive?  What about pulling the cable out?

Pulling the cable is exactly the same as removing power to the device,
so I dont see how this should make a difference.

It is also very clear, that this code is violating locking restraints
if xpt_async() is calling into uma (as it obviously does).

sys/dev/firewire/sbp.c:
2202         if (sdev->path) {
2203                 SBP_LOCK(sdev->target->sbp);
2204                 xpt_release_devq(sdev->path,
2205                                  sdev->freeze, TRUE);
2206                 sdev->freeze = 0;
2207                 xpt_async(AC_LOST_DEVICE, sdev->path, NULL);
2208                 xpt_free_path(sdev->path);
2209                 sdev->path = NULL;
2210                 SBP_UNLOCK(sdev->target->sbp);
2211         }


Cheers,
Ulrich Spoerlein
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.


More information about the freebsd-stable mailing list