From owner-freebsd-stable@FreeBSD.ORG Fri Jul 31 05:19:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB48E106564A; Fri, 31 Jul 2009 05:19:50 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by mx1.freebsd.org (Postfix) with ESMTP id 58A8B8FC1D; Fri, 31 Jul 2009 05:19:49 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from libero.it (192.168.17.5) by cp-out1.libero.it (8.5.107) id 4A7204C400013898; Fri, 31 Jul 2009 07:19:48 +0200 Date: Fri, 31 Jul 2009 07:19:48 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "attilio" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 79.9.234.196 Cc: freebsd-bugs , freebsd-stable Subject: Re: kern/134584: [panic] spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 05:19:51 -0000 > The following reply was made to PR kern/134584; it has been noted by GN= ATS. > > From: Attilio Rao > To: barbara > Cc: bug-followup , FreeBSD-stable > Subject: Re: kern/134584: [panic] spin lock held too long > Date: Sun, 26 Jul 2009 16:36:44 +0200 > > 2009/7/26 barbara : > > It happened again, on shutdown. > > As the previous time, it happened after a high (for a desktop) uptim= e and, if it could matter, after running net-p2p/transmission-gtk2 for se= veral 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 d= evice and I can't umount it as fstat reports the device used by a transmi= ssion 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). > Yesterday it happened again but the machines locked on panic command and = nothing was dumped. It also happened today, and as yesterday after some hours (~10) of uptime= , but this time I've got no ddb.txt, just vmcore. It stopped after the following message: cpu reset: Stopping other CPUs The output of "show alllocks command" is (http://pastebin.com/f2323ad60):= Process 1 (init) thread 0xc589bd80 (100002) exclusive sleep mutex Giant r =3D 0 (0xc0873b10) locked @ /usr/src/sys/ke= rn/kern_module.c:102 That is the "mtx_lock(&Giant);" line in "static void module_shutdown(void= *arg1, int arg2)". ps -axl from crashinfo (http://pastebin.com/f15e7ff90): UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMA= ND 0 0 0 0 -16 0 0 0 sched DLs ?? 10505772:02.00 = [swapper] 0 1 0 0 -8 0 1888 0 - RLs ?? 8198756:46.00 [= init] 0 2 0 0 -8 0 0 0 - DL ?? -31491914:-33.5= 5 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? -18031048:-1.55= [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 29902314:39.00 = [g_down] 0 5 0 0 8 0 0 0 - DL ?? 0:00.00 [kque= ue tas 0 6 0 0 -8 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_= thrd] 0 7 0 0 8 0 0 0 - DL ?? 0:00.00 [acpi= _task_ 0 8 0 0 8 0 0 0 - DL ?? 0:00.00 [acpi= _task_ 0 9 0 0 8 0 0 0 - DL ?? 0:00.00 [acpi= _task_ 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audi= t] 0 11 0 0 171 0 0 0 - RL ?? 30495164:05.00 = [idle: cpu1 0 12 0 0 171 0 0 0 - RL ?? -8752676:-56.55= [idle: cpu0 0 13 0 0 -44 0 0 0 - WL ?? 1297477:00.00 [= swi1: net] 0 14 0 0 -32 0 0 0 - RL ?? 25300285:42.00 = [swi4: cloc 0 15 0 0 -36 0 0 0 - WL ?? 0:00.00 [swi3= : vm] 0 16 0 0 -16 0 0 0 - DL ?? 33237141:47.00 = [yarrow] 0 17 0 0 -40 0 0 0 - WL ?? 33608583:19.00 = [swi2: camb 0 18 0 0 -28 0 0 0 - WL ?? 0:00.00 [swi5= : +] 0 19 0 0 8 0 0 0 - DL ?? 577:12.00 [thre= ad tas 0 20 0 0 -24 0 0 0 - WL ?? 15874802:41.00 = [swi6: Gian 0 21 0 0 -24 0 0 0 - WL ?? 34388543:22.00 = [swi6: task 0 22 0 0 -52 0 0 0 - WL ?? 0:00.00 [irq9= : acpi 0 23 0 0 -80 0 0 0 - WL ?? 33965005:45.00 = [irq24: vga 0 24 0 0 -64 0 0 0 - WL ?? 0:00.00 [irq2= 8: ata 0 25 0 0 -64 0 0 0 - WL ?? 15406643:53.00 = [irq21: ata 0 26 0 0 -64 0 0 0 - WL ?? 225221:21.00 [i= rq14: ata 0 27 0 0 -64 0 0 0 - WL ?? -19343052:-29.5= 5 [irq15: ata 0 28 0 0 -64 0 0 0 - WL ?? -5763326:-52.55= [irq20: uhc 0 29 0 0 8 0 0 0 usbevt DL ?? 143817:50.00 [u= sb0] 0 30 0 0 8 0 0 0 usbtsk DL ?? 0:00.00 [usbt= ask-hc 0 31 0 0 8 0 0 0 usbtsk DL ?? 0:00.00 [usbt= ask-dr 0 32 0 0 -64 0 0 0 - WL ?? 0:00.00 [irq2= 2: uhc 0 33 0 0 8 0 0 0 usbevt DL ?? 139260:44.00 [u= sb1] 0 34 0 0 8 0 0 0 usbevt DL ?? 154878:51.00 [u= sb2] 0 35 0 0 -64 0 0 0 - WL ?? 0:00.00 [irq2= 3: uhc 0 36 0 0 8 0 0 0 usbevt DL ?? 147693:41.00 [u= sb3] 0 37 0 0 8 0 0 0 usbevt DL ?? 153607:50.00 [u= sb4] 0 38 0 0 -80 0 0 0 - RL ?? -23091533:-19.5= 5 [irq256: hd 0 39 0 0 -68 0 0 0 - WL ?? -9517088:-16.55= [irq19: rl0 0 40 0 0 -8 0 0 0 - DL ?? 8660889:23.00 [= fdc0] 0 41 0 0 -48 0 0 0 - WL ?? 0:00.00 [swi0= : sio] 0 42 0 0 -60 0 0 0 - WL ?? 19344460:25.00 = [irq1: atkb 0 43 0 0 -60 0 0 0 - WL ?? 0:00.00 [irq7= : ppbu 0 44 0 0 -16 0 0 0 waitin DL ?? 1395:36.00 [sct= p_itera 0 45 0 0 -16 0 0 0 psleep DL ?? 23513565:41.00 = [pagedaemon 0 46 0 0 20 0 0 0 psleep DL ?? 239:30.00 [vmda= emon] 0 47 0 0 171 0 0 0 pgzero DL ?? 19812:23.00 [pa= gezero] 0 48 0 0 20 0 0 0 ktsusp DL ?? 31705008:58.00 = [bufdaemon] 0 49 0 0 20 0 0 0 ktsusp DL ?? 17747103:57.00 = [syncer] 0 50 0 0 20 0 0 0 ktsusp DL ?? 26534645:02.00 = [vnlru] 0 51 0 0 -16 0 0 0 sdflus DL ?? 4932805:02.00 [= softdepflu