On 12/21/14 14:54, Fabian Keil wrote:
#0 sched_switch (td=0xf80015ea0940, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1940
#1 0x805bbf91 in mi_switch (flags=260, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:492
#2 0x8060126a in sleepq_wait (wchan=0x0, pri=0) at
/usr/
Fabian Keil wrote:
> Hans Petter Selasky wrote:
>
> > On 10/23/14 16:28, Fabian Keil wrote:
>
> > > kldunload umass.ko lead to a panic, dumping didn't work.
> > >
> > > Screenshots are available at:
> > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/
> > >
> > > I've seen l
Hans Petter Selasky wrote:
> On 10/23/14 16:28, Fabian Keil wrote:
> > kldunload umass.ko lead to a panic, dumping didn't work.
> >
> > Screenshots are available at:
> > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/
> >
> > I've seen locked-up usbconfig processes in the past,
On 10/23/14 16:28, Fabian Keil wrote:
A few days ago a couple of usbconfig processed did not exit:
fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig)
PIDTID COMM TDNAME KSTACK
1624 100781 usbconfig-mi_switch+0xe1 sleepq_wait+0x3a
_sx_xlock_har
A few days ago a couple of usbconfig processed did not exit:
fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig)
PIDTID COMM TDNAME KSTACK
1624 100781 usbconfig-mi_switch+0xe1 sleepq_wait+0x3a
_sx_xlock_hard+0x522 _sx_xlock+0