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 -- SteveReceived on Mon Nov 17 2014 - 00:45:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC