5.2-RELEASE intermittent ulpt bug

Howdy list,

I've been meaning to send this info in since mid January,
but the bug is very intermittent by nature and I couldn't
find time to poke and prod the system until now.

Here's the situation:

I have an HP-Deskjet-5550 (which, I might add, is an EXCELLENT
printer if you want great quality color prints and only need
a very light duty cycle) attached via USB cable to a 5.2-RELEASE
machine.

The 5.2-RELEASE machine is my wife's workstation and occasionally
it will fail to print. When this happens, the CPU climbs to 0% idle
and the hard disk light flashes incessantly.

The 'usb' process is hogging all the CPU, and any attempts to kill
the process fail:

[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# kill -9 11796
[18:48]jesse_at_isaac:[~/documents]# ps auxwww | grep usb
root  11796  6.2  0.1  2712  184  ??  D     4:12PM  12:26.99 usb:/dev/ulpt0 58 jesse (stdin) 1 (usb)

A reboot will solve the problem and any queued documents (via CUPS)
will print out successfully. If I swap the printer to a parrallel
cable instead of USB then it runs forever without problems.

Below is my DDB session during one of these ulpt fits. I'm not
very good with DDB, so I'm not sure how useful the below info
is, but hopefully someone can make heads or tails out of it:

Debugger("manual escape to debugger")
Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> ps

...
11796 c35f71c4 d3174000    0   542   542 0004100 [SLP]swwrt 0xc7d15510] usb
...

db> trace 11796
sched_switch(c32b3500,2,c08a51ce,1d4,bafe171f) at sched_switch+0xa5
mi_switch(c32b3500,44,c08a51ce,c6,2) at mi_switch+0x238
msleep(c7d15510,0,44,c08c21f2,0) at msleep+0x4ef
swap_pager_putpages(c37d6294,d30f8980,1,1,d30f8930) at swap_pager_putpages+0x4c9

vm_pageout_flush(d30f8980,1,0,64,d30f8a04) at vm_pageout_flush+0x17a
vm_contig_launder(22,0,c08c3c45,aa,246) at vm_contig_launder+0x237
contigmalloc1(4000,c0903980,1,0,ffffffff) at contigmalloc1+0x14c
contigmalloc(4000,c0903980,1,0,ffffffff) at contigmalloc+0x6b
bus_dmamem_alloc(c375df40,c375dd08,5,c375dd04,ffffffff) at bus_dmamem_alloc+0xcd

usb_block_allocmem(0,4000,1,c445b23c,0) at usb_block_allocmem+0x180
usb_allocmem(c2d81000,4000,0,c445b23c,d30f8b04) at usb_allocmem+0x73
uhci_allocm(c2d81000,c445b23c,4000,c2d92780,d30f8b3c) at uhci_allocm+0x27
usbd_alloc_buffer(c445b200,4000,c32b3500,0,c32d02ec) at usbd_alloc_buffer+0x28
ulpt_do_write(c2d92780,d30f8c80,20001,c32d02ec,c3ea8000) at ulpt_do_write+0x5a
ulptwrite(c09691b0,d30f8c80,20001,d30f8b78,108) at ulptwrite+0x59
spec_write(d30f8be4,d30f8c30,c06b25e3,d30f8be4,20002) at spec_write+0x1c3
spec_vnoperate(d30f8be4,20002,c32b3500,231,d30f8c80) at spec_vnoperate+0x18
vn_write(c32d02ec,d30f8c80,c37b4d00,0,c32b3500) at vn_write+0x233
dofilewrite(c32b3500,c32d02ec,3,bfbfcca4,108) at dofilewrite+0xfb
write(c32b3500,d30f8d14,c08c95a6,3ee,3) at write+0x6e
syscall(2f,2f,2f,bfbfcca4,108) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x280fe0af, esp = 0xbfbfcc1c, ebp =
 0xbfbfecbc ---


I tried panicing the system and running GDB on the crash dump
in hopes of getting line numbers for the above, but I couldn't
figure out how to make GDB do a trace on a process like I did
above with DDB. I'd be happy to do so if someone can tell me
how.

>From what little I know about POSIX threads (I've read about half
of Programming with POSIX Threads by Dave B.) I suspect a thread
dead lock condition, but take that as a grain of salt because I
don't know what I'm talking about. :)

I'll be upgrading this machine to 5.2.1-RC2 today, so I should
know in a week or two if this issue still exists in 5.2.1-RC2.
Again, the problem is very hard to reproduce, so it's a matter
of time.

Thanks!

-- 
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v)  423-559-5145 (f)
http://www.wingnet.net