ktrace-ing a command that locks up the machine

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

So after fixing kern/53311 and kern/55745 on -8, I'm back to one nesting 
level down my original task.

I have a command that (when run the second time and with certain USB devices 
connected) will irrevertibly (to me) partly (no console switching) lock up 
the machine. I need to enter DDB and reboot.

I would like to ktrace/ktruss the command to see which USB transfer exactly 
is the one that hangs. However, even with ktrace -s, there is no trace file 
after the re-boot (on FFS/WAPBL); I can't tell whether it exists before the 
reboot. Using ktruss, the last trace output to the console is way behind the 
execution.

I would like to avoid GDB single stepping through libusb.

Any ideas?

The process is somewhat tedious because these wonderful 
grandgrandson-of-IBM-PCs take some 85 seconds from the reboot command to 
the primary boot.