Date: Sun, 26 Jul 2009 16:36:44 +0200 From: Attilio Rao <attilio@freebsd.org> To: barbara <barbara.xxx1975@libero.it> Cc: FreeBSD-stable <FreeBSD-stable@freebsd.org>, bug-followup <bug-followup@freebsd.org> Subject: Re: kern/134584: [panic] spin lock held too long Message-ID: <3bbf2fe10907260736j3182af26v5346a4d9d2df2a84@mail.gmail.com> In-Reply-To: <KNDMU8$8EFE8DA350FF14C54F1F3D61C7265B47@libero.it> References: <KNDMU8$8EFE8DA350FF14C54F1F3D61C7265B47@libero.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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?3bbf2fe10907260736j3182af26v5346a4d9d2df2a84>