On Thu, 14 Sep 2006, Jason Thorpe wrote:

> On Sep 14, 2006, at 2:41 PM, Juan RP wrote:
>
> > On Thu, 14 Sep 2006 19:35:19 +0100 (BST)
> > Iain Hibbert <plunky@rya-online.net> wrote:
> > > uvm_fault(0xcb169704, 0x4035a000, 1) -> 0xe
> > > kernel: supervisor trap page fault, code=0
> > > Stopped in pid 826.1 (rfcomm_sppd) at	0xcad09545:
> > > testl	%eax,netbsd:cpu_info_primary+0x188(,%ebx,4)
> > > db> bt
> > > _prop_dictionary_keysym32_pool
> > > (c0a4f000,c0b29b00,cb666960,2000,b1b2edf6) at 0xcad09545 pppintr
> > > (c0acac00,0,3f661a9c,246,0) at netbsd:pppintr+0x456 softintr_dispatch
> > > (1,4b,c0acac00,f0b8001b,cb6669cc) at netbsd:softintr_dispatch+0x2b
> > > DDB lost frame for netbsd:Xsoftnet+0x48, trying 0xcb66699c Xsoftnet()
> > > at netbsd:Xsoftnet+0x48 --- interrupt ---
> > > 0xca3a2420:
>
> That backtrace looks weird -- but you know you can't fiddle with prop objects
> in interrupt context, right?

Yeah, but proplib is not being touched at all in that code path. The only
place I have used it in bluetooth is for device (hid and audio)
configuration, and anything using ppp over rfcomm would not be near that.

Also, _prop_dictionary_keysym32_pool is not actually a function, so I'm
not sure why its on the backtrace?  I'm no DDB expert, but its presence at
the top of the tree (3 times) must be significant somehow.

I'm thinking that the only 'new' thing I have done recently with regards
to proplib is that bthub_attach() creates a prop_data object and stores it
in its device properties dictionary. So, in my current system there will
be two of these persistent objects.

Previously all I have done in the kernel is prop_dictionary_copyin_ioctl()
then prop_object_release() which would have left nothing in the pool.

Could this be significant?

iain