On Sun, Nov 16, 2014 at 08:33:15PM +0100, Hans Petter Selasky wrote:
>
> thread apply all bt
>
> That will give you the backtrace of all threads. Grep for usbconfig, and
> figure out which line is causing the problem in the kernel. Then look at
> the USB explore threads and see where they are stuck in the detach of umass!
>
I haven't tried the kgdb approach, yet. I can say that the
problem is coming from sg device. If I have 'device sg' in
my config file, the problems occur. Removing 'device sg'
gives a working kernel.
If I do not start hald in /etc/rc.conf, everything works as
expected. Now, if hald was started at boot and I then stop
hald with '/usr/local/etc/rc.d/hald stop' then the one hald
relate process is not stopped. I've wrapped lines to keep this
short.
% ps axl | grep hald
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 1058 1 195 20 0 13180 3512 - I - 0:00.05
hald-probe-storage: /dev/sg1 (hald-probe-storage)
Using the procstat as suggested by Adrian, I have
% procstat -ka
1058 100157 hald-probe-storage hald-probe-stora mi_switch sleepq_switch
sleepq_catch_signals sleepq_wait_sig _sleep sgread giant_read
devfs_read_f dofileread kern_readv sys_read syscall Xint0x80_syscall
--
Steve
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
