Date: Sun, 26 Jul 2009 15:10:10 GMT From: Attilio Rao <attilio@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/134584: [panic] spin lock held too long Message-ID: <200907261510.n6QFAA2o058016@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/134584; it has been noted by GNATS. From: Attilio Rao <attilio@freebsd.org> To: barbara <barbara.xxx1975@libero.it> Cc: bug-followup <bug-followup@freebsd.org>, FreeBSD-stable <FreeBSD-stable@freebsd.org> Subject: Re: kern/134584: [panic] spin lock held too long Date: Sun, 26 Jul 2009 16:36:44 +0200 2009/7/26 barbara <barbara.xxx1975@libero.it>: > It happened again, on shutdown. > As the previous time, it happened after a high (for a desktop) uptime and, if it could matter, after running net-p2p/transmission-gtk2 for several hours. > I don't know if it's related, but often quitting transmission, doesn't terminate the process. Sometimes it end after several minutes the gui exited, sometimes it's still running after hours. > I've noticed it as the destination folder is on a manually mounted device and I can't umount it as fstat reports the device used by a transmission process. > So I often have to kill it. > This happened both the time I had this kind of panic. Can you try to reproduce it with WITNESS and *without* WITNESS_SKIPSPIN? I would need to look at "show alllocks" and possibily "ps" because it seems that the lock owner is preempted but it should not happen while holding a spinlock (unless the acquired spinlock is the one in the preempting path, in this case thought it should drop inside sched_switch() and we can try to understand why that doesn't happen). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907261510.n6QFAA2o058016>