From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 06:17:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 566641065670; Sun, 18 Jan 2009 06:17:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DE1A38FC17; Sun, 18 Jan 2009 06:17:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n0I6HpOk012517; Sun, 18 Jan 2009 01:17:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n0I6HpOf078849; Sun, 18 Jan 2009 01:17:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 06A587302F; Sun, 18 Jan 2009 01:17:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090118061751.06A587302F@freebsd-current.sentex.ca> Date: Sun, 18 Jan 2009 01:17:50 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 06:17:55 -0000 TB --- 2009-01-18 04:44:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-18 04:44:46 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-01-18 04:44:46 - cleaning the object tree TB --- 2009-01-18 04:45:12 - cvsupping the source tree TB --- 2009-01-18 04:45:12 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-01-18 04:45:20 - building world TB --- 2009-01-18 04:45:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-18 04:45:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-18 04:45:20 - TARGET=sun4v TB --- 2009-01-18 04:45:20 - TARGET_ARCH=sparc64 TB --- 2009-01-18 04:45:20 - TZ=UTC TB --- 2009-01-18 04:45:20 - __MAKE_CONF=/dev/null TB --- 2009-01-18 04:45:20 - cd /src TB --- 2009-01-18 04:45:20 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 18 04:45:21 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jan 18 06:03:14 UTC 2009 TB --- 2009-01-18 06:03:14 - generating LINT kernel config TB --- 2009-01-18 06:03:14 - cd /src/sys/sun4v/conf TB --- 2009-01-18 06:03:14 - /usr/bin/make -B LINT TB --- 2009-01-18 06:03:15 - building LINT kernel TB --- 2009-01-18 06:03:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-18 06:03:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-18 06:03:15 - TARGET=sun4v TB --- 2009-01-18 06:03:15 - TARGET_ARCH=sparc64 TB --- 2009-01-18 06:03:15 - TZ=UTC TB --- 2009-01-18 06:03:15 - __MAKE_CONF=/dev/null TB --- 2009-01-18 06:03:15 - cd /src TB --- 2009-01-18 06:03:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 18 06:03:16 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-18 06:17:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-18 06:17:50 - ERROR: failed to build lint kernel TB --- 2009-01-18 06:17:50 - 4575.47 user 406.34 system 5584.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 09:29:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C9E21065677; Sun, 18 Jan 2009 09:29:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id DC9948FC1B; Sun, 18 Jan 2009 09:29:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=3BqfucdjhS4QKjqFDqgA:9 a=0D1pluHFLBn_4DKW583XDKBQ1akA:4 a=LY0hPdMaydYA:10 Received: from [193.217.167.134] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1009545244; Sun, 18 Jan 2009 10:29:10 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 18 Jan 2009 10:31:34 +0100 User-Agent: KMail/1.9.7 References: <1503.1232226724@critter.freebsd.dk> In-Reply-To: <1503.1232226724@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901181031.35412.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 09:29:14 -0000 On Saturday 17 January 2009, Poul-Henning Kamp wrote: > I just updated to -current and tried USB2 again, FTDI serial ports > and Huawei 3G modem still not happy. Hi, I'm working on this issue. I have a machine with SSH which has the exact same problem. It seems like it is UHCI related! I have a patch you can try: Edit "..../usb2/controller/uhci2.c" And change: UHCI_TD_SET_ERRCNT(3) Into: UHCI_TD_SET_ERRCNT(0) Recompile and re-load "usb2_controller_uhci". --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 09:29:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C9E21065677; Sun, 18 Jan 2009 09:29:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id DC9948FC1B; Sun, 18 Jan 2009 09:29:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=3BqfucdjhS4QKjqFDqgA:9 a=0D1pluHFLBn_4DKW583XDKBQ1akA:4 a=LY0hPdMaydYA:10 Received: from [193.217.167.134] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1009545244; Sun, 18 Jan 2009 10:29:10 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 18 Jan 2009 10:31:34 +0100 User-Agent: KMail/1.9.7 References: <1503.1232226724@critter.freebsd.dk> In-Reply-To: <1503.1232226724@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901181031.35412.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 09:29:14 -0000 On Saturday 17 January 2009, Poul-Henning Kamp wrote: > I just updated to -current and tried USB2 again, FTDI serial ports > and Huawei 3G modem still not happy. Hi, I'm working on this issue. I have a machine with SSH which has the exact same problem. It seems like it is UHCI related! I have a patch you can try: Edit "..../usb2/controller/uhci2.c" And change: UHCI_TD_SET_ERRCNT(3) Into: UHCI_TD_SET_ERRCNT(0) Recompile and re-load "usb2_controller_uhci". --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 10:10:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6A0106564A for ; Sun, 18 Jan 2009 10:10:03 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE538FC12 for ; Sun, 18 Jan 2009 10:10:02 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2513405wfg.7 for ; Sun, 18 Jan 2009 02:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kwg137fRV/d2DVW0dhbdUpOe1AkKwV48BlTdReWW3mg=; b=NsTBzx+ABXv0J/rw6CUFJ3pbv5KIvmxyEJYexuTk4b79GtXiJGJtPoY2EGf1aAdKzn npwhhNPF4rskGbo+lYWTAhc6Nq6eif1Ckegy+T/xiCpA1DxZ2FQYvAvwIW5f88gRekC2 oEf52j5LcjL29dR5+sMIkUcAIOl8qhGM684ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Xr5dZ5OeLRjoDnrOK6BJIXnszPzdvjhXjmcCybS0m1jWLar33o+Y1nCbt4yNoA8L0Y cm0EJ2IInINvtrW30X/hLx/4LYMHpPw3PnAU7Blkt0wPqPvUJn9ghiBfY8PQsfmNtijx xLMmxgePSuwCtfGr6qDjIDfMkaX7jvYKVLRO0= MIME-Version: 1.0 Received: by 10.142.69.20 with SMTP id r20mr1853439wfa.188.1232273402706; Sun, 18 Jan 2009 02:10:02 -0800 (PST) In-Reply-To: <20090111063124.GE42714@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> <20090110031839.GK30747@cdnetworks.co.kr> <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> <20090111063124.GE42714@cdnetworks.co.kr> Date: Sun, 18 Jan 2009 05:10:02 -0500 Message-ID: <89dbfdc30901180210s45cabfaao1f0f15afa780b82f@mail.gmail.com> From: Kim Culhan To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 10:10:03 -0000 On Sun, Jan 11, 2009 at 1:31 AM, Pyun YongHyeon wrote: > On Sat, Jan 10, 2009 at 08:19:50AM -0500, Kim Culhan wrote: > > On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon wrote: > > > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > > > > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > > > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > > > > > Ok, then how about disabling TSO/Tx checksum offload? > > > > > (eg. ifconfig msk0 -tso -txcsum) > > > > > > > > This stops the messages: in_cksum_skip: out of data by 56952 > > > > > > Ok, would you try attached patch? > > > > With the patch there are no in_cksum_skip messages > > > > Thanks for testing! > > > a cvsup session still has: > > Network write failure: Connection timed out > > > > That's odd, I can't reproduce this on my box. If you disable Tx > checksum offload of msk(4), cvsup session completes without > problems? > When cvsup plains network errors, can you still send/receive > packets with msk(4)? Sorry for the noise re: Network write failure This was caused by an unrelated network problem. Thanks for the patch, this fixes the complaints: in_cksum_skip: out of data The present dmesg is: Jan 17 18:11:01 lapster kernel: mskc0: port 0x2000-0x20ff mem 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 Jan 17 18:11:01 lapster kernel: msk0: on mskc0 Jan 17 18:11:01 lapster kernel: can't re-use a leaf (jabbers)! Jan 17 18:11:01 lapster kernel: msk0: disabling jumbo frame support Jan 17 18:11:01 lapster kernel: msk0: Ethernet address: 00:1b:24:59:5b:7a Jan 17 18:11:01 lapster kernel: miibus0: on msk0 Jan 17 18:11:01 lapster kernel: e1000phy0: PHY 0 on miibus0 Jan 17 18:11:01 lapster kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jan 17 18:11:01 lapster kernel: mskc0: [FILTER] The problem with msk not working with ACPI enabled is well known, is there anything I can do to get this working? thanks -kim -- From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 11:00:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 064A11065674; Sun, 18 Jan 2009 11:00:51 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao107.cox.net (eastrmmtao107.cox.net [68.230.240.59]) by mx1.freebsd.org (Postfix) with ESMTP id A1F9D8FC0A; Sun, 18 Jan 2009 11:00:50 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090118110051.UAPF23750.eastrmmtao107.cox.net@eastrmimpo01.cox.net>; Sun, 18 Jan 2009 06:00:51 -0500 Received: from serene.no-ip.org ([72.200.37.152]) by eastrmimpo01.cox.net with bizsmtp id 4z0m1b0083Gxf8w02z0pva; Sun, 18 Jan 2009 06:00:50 -0500 X-Authority-Analysis: v=1.0 c=1 a=XUCd45H-lvu0iG0MZtYA:9 a=CBnoIuOwWh0yHNOyQM4A:7 a=qVWdJnJC_s2fsIb8eSE2MStFt0oA:4 a=4vB-4DCPJfMA:10 a=LY0hPdMaydYA:10 X-CM-Score: 0.00 Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.3/8.14.3) with ESMTP id n0IB0kJG010206; Sun, 18 Jan 2009 05:00:46 -0600 (CST) (envelope-from conrads@cox.net) Date: Sun, 18 Jan 2009 05:00:45 -0600 From: "Conrad J. Sabatier" To: "Conrad J. Sabatier" Message-ID: <20090118050045.39b8ab47@serene.no-ip.org> In-Reply-To: <20090114163846.0dfa6080@serene.no-ip.org> References: <20090114163846.0dfa6080@serene.no-ip.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, sos@freebsd.org Subject: Re: nv-pv2 (Was: I give up) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 11:00:51 -0000 On Wed, 14 Jan 2009 16:38:46 -0600 "Conrad J. Sabatier" wrote: > OK, I took Soren's advice and modified the device ID in one of the > patches he had originally sent me. The SATA controller is now being > recognized, as well as the hard drive, but still no CD/DVD. > > What else do I need to do to complete this remedy? I've included my > modifications to Soren's original patches below. > > Thank you, and sorry for the long lag in following up on this issue. > > Conrad I should hqve included the output of "ataconf list": # atacontrol list ATA channel 2: (this is the internal hard drive) Master: ad4 Serial ATA II Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present ATA channel 6: Master: no device present Slave: no device present ATA channel 7: Master: no device present Slave: no device present So where the heck is my CD/DVD connected to? This is one of the most bizarre problems I've ever encountered. Pciconf, camcontrol both turn up equally blank info. I'm quite at a loss here. And what could be the reason for no ATA channels 0 or 1 showing up? HELP! Conrad, quite at his wits' end with this mystery, Thanks for any further advice, > Begin forwarded message: > > Date: Wed, 31 Dec 2008 22:32:51 -0600 (CST) > From: conrads@serene.no-ip.org (Conrad J. Sabatier) > To: conrads@cox.net > Subject: nv-pv2 > > > Index: chipsets/ata-nvidia.c > =================================================================== > --- chipsets/ata-nvidia.c (revision 184585) > +++ chipsets/ata-nvidia.c (working copy) > @@ -61,6 +61,7 @@ > /* misc defines */ > #define NV4 0x01 > #define NVQ 0x02 > +#define NVAHCI 0x04 > > > /* > @@ -99,6 +100,7 @@ > { ATA_NFORCE_MCP67, 0, 0, 0, ATA_UDMA6, "nForce > MCP67" }, { ATA_NFORCE_MCP73, 0, 0, 0, ATA_UDMA6, "nForce > MCP73" }, { ATA_NFORCE_MCP77, 0, 0, 0, ATA_UDMA6, "nForce > MCP77" }, > + { ATA_NFORCE_MCP77_A8, 0, NVAHCI, 0, ATA_SA300, "nForce > MCP77" }, { 0, 0, 0, 0, 0, 0}} ; > > if (pci_get_vendor(dev) != ATA_NVIDIA_ID) > @@ -108,7 +110,10 @@ > return ENXIO; > > ata_set_desc(dev); > - ctlr->chipinit = ata_nvidia_chipinit; > + if (ctlr->chip->cfg1 & NVAHCI) > + ctlr->chipinit = ata_ahci_chipinit; > + else > + ctlr->chipinit = ata_nvidia_chipinit; > return 0; > } > > Index: ata-pci.h > =================================================================== > --- ata-pci.h (revision 184585) > +++ ata-pci.h (working copy) > @@ -255,8 +255,44 @@ > #define ATA_NFORCE_MCP61_S3 0x03f710de > #define ATA_NFORCE_MCP65 0x044810de > #define ATA_NFORCE_MCP67 0x056010de > +#define ATA_NFORCE_MCP67_A0 0x055010de > +#define ATA_NFORCE_MCP67_A1 0x055110de > +#define ATA_NFORCE_MCP67_A2 0x055210de > +#define ATA_NFORCE_MCP67_A3 0x055310de > +#define ATA_NFORCE_MCP67_A4 0x055410de > +#define ATA_NFORCE_MCP67_A5 0x055510de > +#define ATA_NFORCE_MCP67_A6 0x055610de > +#define ATA_NFORCE_MCP67_A7 0x055710de > +#define ATA_NFORCE_MCP67_A8 0x055810de > +#define ATA_NFORCE_MCP67_A9 0x055910de > +#define ATA_NFORCE_MCP67_Aa 0x055a10de > +#define ATA_NFORCE_MCP67_Ab 0x055b10de > #define ATA_NFORCE_MCP73 0x056c10de > +#define ATA_NFORCE_MCP73_A0 0x07f010de > +#define ATA_NFORCE_MCP73_A1 0x07f110de > +#define ATA_NFORCE_MCP73_A2 0x07f210de > +#define ATA_NFORCE_MCP73_A3 0x07f310de > +#define ATA_NFORCE_MCP73_A4 0x07f410de > +#define ATA_NFORCE_MCP73_A5 0x07f510de > +#define ATA_NFORCE_MCP73_A6 0x07f610de > +#define ATA_NFORCE_MCP73_A7 0x07f710de > +#define ATA_NFORCE_MCP73_A8 0x07f810de > +#define ATA_NFORCE_MCP73_A9 0x07f910de > +#define ATA_NFORCE_MCP73_Aa 0x07fa10de > +#define ATA_NFORCE_MCP73_Ab 0x07fb10de > #define ATA_NFORCE_MCP77 0x075910de > +#define ATA_NFORCE_MCP77_A0 0x0ad010de > +#define ATA_NFORCE_MCP77_A1 0x0ad110de > +#define ATA_NFORCE_MCP77_A2 0x0ad210de > +#define ATA_NFORCE_MCP77_A3 0x0ad310de > +#define ATA_NFORCE_MCP77_A4 0x0ad410de > +#define ATA_NFORCE_MCP77_A5 0x0ad510de > +#define ATA_NFORCE_MCP77_A6 0x0ad610de > +#define ATA_NFORCE_MCP77_A7 0x0ad710de > +#define ATA_NFORCE_MCP77_A8 0x0ad810de > +#define ATA_NFORCE_MCP77_A9 0x0ad910de > +#define ATA_NFORCE_MCP77_Aa 0x0ada10de > +#define ATA_NFORCE_MCP77_Ab 0x0adb10de > > #define ATA_PROMISE_ID 0x105a > #define ATA_PDC20246 0x4d33105a > > -- Conrad J. Sabatier From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 12:23:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A33E1065672 for ; Sun, 18 Jan 2009 12:23:18 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id D35F68FC08 for ; Sun, 18 Jan 2009 12:23:17 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so248572eyd.7 for ; Sun, 18 Jan 2009 04:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZkREVcEIzsz6W79HXxhJ38hTpftIcrXk7z1K3bUS474=; b=TFPDP8GkwuMH+ybDDDoPy1jLvSx/XeANTrjPF7cP9URDZjCG8cgztM98q1ZbMuui3n PpVC1C6goOUUiGrm6mY9BGocVBVAQjPAYh7wRJQNZPrvQgVz/C5C/VuDtCtERrMaC038 W1tOzYqfD/VCJRPUXHHxdOvwQyXOTvqQN9pd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mu/mG29dLtPfSXaHwxJ+6ZCYnSceBRrTKP28rYX1oNHg+IfrAm7wry04E1I/AEIMJA z+VJb50iwAVxi9ODJglzU4PYhZBSUWI50r4Kpe4jmDvMlDh2jSxZCWVYcufN0lUY2W3Y 5PwNSgkhdi189oEmE74Nz05INbPm0DqQJHzok= MIME-Version: 1.0 Received: by 10.210.59.14 with SMTP id h14mr108009eba.102.1232281396948; Sun, 18 Jan 2009 04:23:16 -0800 (PST) In-Reply-To: <49726AFF.9060807@gmail.com> References: <4971CC75.4050501@gmail.com> <3a142e750901171443w43ddb06p2022cca1e787773a@mail.gmail.com> <49726AFF.9060807@gmail.com> Date: Sun, 18 Jan 2009 13:23:16 +0100 Message-ID: <3a142e750901180423q7bcb54aesc1df30f832772afb@mail.gmail.com> From: "Paul B. Mahol" To: Martin Baumann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: linux compatibility module build problems.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 12:23:18 -0000 On 1/18/09, Martin Baumann wrote: > Hi. > > The strangest thing is that when I compile kernel with options > COMPAT_LINUX it doesnt give me any error.. So I really dont understand. Because in that case HWPMC_HOOKS definition is passed directly from your kernel conf eg. only one opt_hwpmc_hooks.h is used to build whole kernel and modules, so it will work also with COMPAT_LINUX not defined in kernel. That is not case when building inside module Makefile directory. And if that way doesnt work your are on your own to find what is missing. Building modules as you are doing is not generally to be supported all the time. > > Best regards, > Martin Baumann > > Paul B. Mahol wrote: >> On 1/17/09, Martin Baumann wrote: >> >>> Hi. >>> >>> My sources are updated to HEAD. >>> When I try to do: *cd /usr/src/sys/modules/linux && make* >>> >> >> This will make it just build but may not work .... >> >> diff Makefile.org Makefile >> 17c17 >> < device_if.h bus_if.h assym.s >> --- >> >>> device_if.h bus_if.h assym.s opt_hwpmc_hooks.h >>> >> >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 12:52:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242EA1065678 for ; Sun, 18 Jan 2009 12:52:06 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id A320C8FC08 for ; Sun, 18 Jan 2009 12:52:05 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id n0ICKhXd025226; Sun, 18 Jan 2009 13:20:43 +0100 (CET) (envelope-from sos@FreeBSD.ORG) Message-Id: <9AB4BB55-6F88-434D-B2BD-1E00DDCF7A8F@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Conrad J. Sabatier" In-Reply-To: <20090118050045.39b8ab47@serene.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 18 Jan 2009 13:20:43 +0100 References: <20090114163846.0dfa6080@serene.no-ip.org> <20090118050045.39b8ab47@serene.no-ip.org> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [217.20.59.72]); Sun, 18 Jan 2009 13:20:43 +0100 (CET) Cc: freebsd-current@FreeBSD.ORG Subject: Re: nv-pv2 (Was: I give up) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 12:52:06 -0000 On 18Jan, 2009, at 12:00 , Conrad J. Sabatier wrote: > On Wed, 14 Jan 2009 16:38:46 -0600 > "Conrad J. Sabatier" wrote: > >> OK, I took Soren's advice and modified the device ID in one of the >> patches he had originally sent me. The SATA controller is now being >> recognized, as well as the hard drive, but still no CD/DVD. >> >> What else do I need to do to complete this remedy? I've included my >> modifications to Soren's original patches below. >> >> Thank you, and sorry for the long lag in following up on this issue. >> >> Conrad > I should hqve included the output of "ataconf list": > > # atacontrol list > ATA channel 2: (this is the internal hard drive) > Master: ad4 Serial ATA II > Slave: no device present > ATA channel 3: > Master: no device present > Slave: no device present > ATA channel 4: > Master: no device present > Slave: no device present > ATA channel 5: > Master: no device present > Slave: no device present > ATA channel 6: > Master: no device present > Slave: no device present > ATA channel 7: > Master: no device present > Slave: no device present > > So where the heck is my CD/DVD connected to? This is one of the most > bizarre problems I've ever encountered. Pciconf, camcontrol both turn > up equally blank info. I'm quite at a loss here. If the optical device is SATA it might not be detected, the code for =20 SATA ATAPI is still fragile. If its PATA it should be detected.. > > > And what could be the reason for no ATA channels 0 or 1 showing up? Those two devices are reserved for the legacy ports. -S=F8ren= From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 14:07:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A441065675 for ; Sun, 18 Jan 2009 14:07:27 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id CE3278FC13 for ; Sun, 18 Jan 2009 14:07:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,283,1231110000"; d="scan'208";a="267330763" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 18 Jan 2009 15:07:25 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4CC691B0752; Sun, 18 Jan 2009 15:07:25 +0100 (CET) Date: Sun, 18 Jan 2009 15:07:24 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: fdisk: Class not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 14:07:27 -0000 hi there. when i'm trying to do the following: fdisk -B adX i get the following error message: fdisk: Class not found fdisk: Failed to write sector zero i'm running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r187392M: Sun Jan 18 14:42:30 UTC 2009 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 and rebuild and reinstalled fdisk. cheers. alex From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 14:33:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F22D1065675 for ; Sun, 18 Jan 2009 14:33:37 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 18CC38FC0A for ; Sun, 18 Jan 2009 14:33:36 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,283,1231110000"; d="scan'208";a="267331522" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 18 Jan 2009 15:33:36 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 15BF81B0752; Sun, 18 Jan 2009 15:33:36 +0100 (CET) Date: Sun, 18 Jan 2009 15:33:30 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200901181433301e86ffa8000037a6-a_best01+ Subject: periodic(8) daily should backup bsdlabel(8) / fdisk(8) disk labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 14:33:39 -0000 This is a MIME encoded multipart message. --+permail-200901181433301e86ffa8000037a6-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi there, i was browsing the pr-db and found this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 i think it would be a very nice addition to daily. i attached 220.backup-bsdlabels. it can also be found here: http://digitalfreaks.org/~lavalamp/220.backup-bsdlabels backing up the disk labels on a daily basis sounds like a really good thing to do. also the pr states that netbsd and openbsd are doing this for over 10 years now. cheers. alex --+permail-200901181433301e86ffa8000037a6-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="220.backupbsdlabels" IyEvYmluL3NoCiMKIyAkRnJlZUJTRDogc3JjL2V0Yy9wZXJpb2RpYy9kYWlseS8yMjAuYmFja3Vw LWJzZGxhYmxlbHMqKioqKioKIwoKIyAkSWQ6IDIyMC5iYWNrdXAtYnNkbGFiZWxzIDM2IDIwMDYt MDYtMTIgMjE6NTA6MzVaIHNla2xlY2tpICQKIyBSaXBwZWQgcmlnaHQgb3V0IE5ldEJTRCAvZXRj L2RhaWx5LiAgIEJhY2t1cCBGRElTSyBNQlIgYW5kIEJTRCAKIyBEaXNrbGFiZWwgZGF0YSB0byBs b2NhbCBmaWxlc3lzdGVtIHRvIGJlIHBpY2tlZCB1cCBieSBwZXJpb2RpYwojIG9mZnNpdGUgZGF0 YSByZWNvdmVyeS9zdG9yYWdlIG1lY2hhbmlzbSAoQmFjdWxhLCBBbWFuZGEsIHBheCgxKSkKIyB0 byBzaW1wbGlmeSByZWNvdmVyeSB0byBpZGVudGljYWwgZ2VvbWV0cnkgaGFyZHdhcmUgYXQgc2Vj b25kYXJ5LwojIGJhY2t1cCBkYXRhY2VudGVyIH5CQVMKCgojIElmIHRoZXJlIGlzIGEgZ2xvYmFs IHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCiMKaWYgWyAtciAvZXRjL2Rl ZmF1bHRzL3BlcmlvZGljLmNvbmYgXQp0aGVuCiAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMu Y29uZgogICAgc291cmNlX3BlcmlvZGljX2NvbmZzCmZpCgpjYXNlICIkZGFpbHlfYmFja3VwX2Jz ZGxhYmVsc19lbmFibGUiIGluCiAgICBbWXldW0VlXVtTc10pCgoKICAgIGJhaz0vdmFyL2JhY2t1 cHMKCgkjIHRlc3QgZGVidWcKCSMgZGlza3M9ImFkMCIKICAgIGRpc2tzPSQoc3lzY3RsIC1uIGtl cm4uZGlza3MpOwoKCWlmIFsgLW4gIiRkYWlseV9iYWNrdXBfYnNkbGFiZWxzX2luY2x1ZGUiIF07 IHRoZW4KCQkjZGFpbHlfYmFja3VwX2JzZGxhYmVsc19pbmNsdWRlPSQoZWNobyAke2RhaWx5X2Jh Y2t1cF9ic2RsYWJlbHNfaW5jbHVkZX18c2VkIC1lICJzL1wvL1xfL2ciKQoJCWRpc2tzPSIke2Rp c2tzfSAke2RhaWx5X2JhY2t1cF9ic2RsYWJlbHNfaW5jbHVkZX0iCglmaQoKCWlmIFsgLW4gIiRk YWlseV9iYWNrdXBfYnNkbGFiZWxzX2V4Y2x1ZGUiIF07IHRoZW4KCQlkaXNrcz0kKGVjaG8gJHtk aXNrc30gfCBzZWQgLWUgInMvJHtkYWlseV9iYWNrdXBfYnNkbGFiZWxzX2V4Y2x1ZGV9Ly9nIikK CWZpCgoJaWYgWyAteiAiJGRpc2tzIiAgXTsgdGhlbgoJCWVjaG8gJyRkYWlseV9iYWNrdXBfZGlz a2xhYmVsc19lbmFibGUiIGlzIHNldCBidXQgbm8gZGlzayBwcm9iZWQgYnkga2VybmVsLicgXAoJ CSJwZXJoYXBzIE5GUyBkaXNrbGVzcyBjbGllbnQuIgoJCXJjID0gMgoJZWxzZQoKCQllY2hvICJC YWNraW5nIHVwIGRldmljZSBNQlIgYW5kIEJTRCBsYWJlbHMgZm9yOiAke2Rpc2tzfSI7CgkKCQlm b3IgaSBpbiAke2Rpc2tzfTsgZG8KCQoJCQkjIGZpcnN0IG9yZGVyIG9mIGJ1c2luZXNzIGlzIHRv IGNoZWNrIGZvciBhbiBleGlzdGluZyBiYWNrdXAtYmFja3VwCgkJCWlmIFsgLWYgJHtiYWt9L2Zk aXNrLiR7aX0uYmFrIF0gOyB0aGVuCgkJCQlyYz0xCgkJCQllY2hvICJyb3RhdGluZyAkYmFrL2Zk aXNrLiR7aX0uYmFrIgoJCQkJY3AgLXBmICR7YmFrfS9mZGlzay4ke2l9LmJhayAkYmFrL2ZkaXNr LiR7aX0uYmFrMiB8fCByYz0zCgkJCWZpCgkKCQkJZWNobyAiYmFja2luZyB1cCBmZGlzayBmb3Ig JHtpfSIKCQoJCQlmZGlzayAke2l9ID4gIiR7YmFrfS8kKGVjaG8gImZkaXNrLiR7aX0uYmFrInwg c2VkIC1lICJzL1wvL1xfL2ciKSIgMj4vZGV2L251bGwgfHwgcmM9MwoJCgkJCSMgYWdhaW4gZXhl cHQgbm93IHdlIGhhdmUgdG8gZ2V0IGEgbGlzdCBvZiBwYXRpdGlvbnMvc2xpY2VzCgkJCSMgc3Bh cmM2NCBjYW4gaGF2ZS4uLjkgaG9wZWZ1bGx5IHNsaWNlcyBvbiBhIHN1bmxhYmVsPwoJCQlwYXJ0 X3NsaWNlcz0kKGVjaG8gL2Rldi8ke2l9c1swLTldKQoJCgkJCWZvciBqIGluICQoZWNobyAiJHBh cnRfc2xpY2VzIiB8IHNlZCAncy9cL2RldlwvLy8nKTsgZG8KCQkJCWlmIFsgLWYgJHtiYWt9L2Rp c2tsYWJlbC4ke2p9LmJhayBdIDsgdGhlbgoJCQkJCXJjPTEKCQkJCQllY2hvICJyb3RhdGluZyAk e2Jha30vZGlza2xhYmVsLiR7an0uYmFrIgoJCQkJCWNwIC1mcCAke2Jha30vZGlza2xhYmVsLiR7 an0uYmFrICR7YmFrfS9kaXNrbGFiZWwuJHtqfS5iYWsyIHx8IHJjPTMKCQkJCWZpCgkKCQkJCWVj aG8gImJhY2tpbmcgdXAgZGlza2xhYmVsIGZvciAke2p9IgoJCQkJZGlza2xhYmVsIC9kZXYvJHtq fSA+ICIke2Jha30vJChlY2hvICJkaXNrbGFiZWwuJHtqfS5iYWsifHNlZCAtZSAicy9cLy9cXy9n IikiIDI+L2Rldi9udWxsIHx8IHJjPTMKCQkJZG9uZQoJCWRvbmUKICAgIGZpOzsKCiAgICAqKSAg cmM9MDs7CmVzYWMKCmV4aXQgJHJjCg== --+permail-200901181433301e86ffa8000037a6-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 16:00:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 437891065679 for ; Sun, 18 Jan 2009 16:00:51 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id F3DE68FC16 for ; Sun, 18 Jan 2009 16:00:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 481A419E05A; Sun, 18 Jan 2009 16:45:42 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 211CC19E054; Sun, 18 Jan 2009 16:45:40 +0100 (CET) Message-ID: <49734EDA.2030000@quip.cz> Date: Sun, 18 Jan 2009 16:46:34 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: periodic(8) daily should backup bsdlabel(8) / fdisk(8) disk labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 16:00:51 -0000 Alexander Best wrote: > hi there, > > i was browsing the pr-db and found this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 > > i think it would be a very nice addition to daily. i attached > 220.backup-bsdlabels. it can also be found here: > http://digitalfreaks.org/~lavalamp/220.backup-bsdlabels > > backing up the disk labels on a daily basis sounds like a really good thing to > do. also the pr states that netbsd and openbsd are doing this for over 10 > years now. I second that. I posted in to this PR back in 2007, but this PR has still no attention of commiters. :( It is sad that some "simple" PRs are opened for more than 3 years. It should be commited or refused and closed. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 16:19:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 496731065673 for ; Sun, 18 Jan 2009 16:19:46 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id C77FF8FC08 for ; Sun, 18 Jan 2009 16:19:45 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by bwz3 with SMTP id 3so43751bwz.19 for ; Sun, 18 Jan 2009 08:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=lWYCO9Zvuehy14v7ZhU5Bv0eIp+Wo2dmVH+HoetDqqs=; b=iVUksFStoFpdPGjZ9DGFBS8bu2CBxfnKBhutHnyiFQdYnqEjFEyBD0gTQZjxsNqK3f QQDNwHzJ0h/YELfcMn85siYYbeNE/KkmG95EdPt1WV4wdZY/ddCtOOR9gKlzUQIqOsrZ risuEm57y1ELji7CqmYhTRgQOLzcsGjLOjwcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=e7Xqqmq+0QdeC4Hh/VbVWo9giT3iNCyzmcadGEUDiMWQACzZIBdZISw2Dtb5bgt0Zl JjYPAle0GLm/AZyM9/J8N1ixrB6vMAMY0l4SY0S1orhiKJhcs8QFn4zeEfu01qiqfscu kfOPl6Bz/Mc/V99CR+I7LTpd7STPbv/DynQGY= Received: by 10.181.226.2 with SMTP id d2mr1719537bkr.15.1232295352078; Sun, 18 Jan 2009 08:15:52 -0800 (PST) Received: by 10.181.22.6 with HTTP; Sun, 18 Jan 2009 08:15:52 -0800 (PST) Message-ID: <6eb82e0901180815wbbcbbdfr3ee435b0e5dcf62c@mail.gmail.com> Date: Mon, 19 Jan 2009 00:15:52 +0800 From: "Rong-en Fan" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ad0: setting up DMA failed / FAILURE - load data ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 16:19:46 -0000 Today, I upgraded one of my 7.x amd64 box to CURRENT and got lots of these messages on console: ad0: FAILURE - load data ad0: setting up DMA failed ad2: FAILURE - load data ad2: setting up DMA failed Both disks are SATA ones on atapci0: . Any ideas why they are there and is this known? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 16:53:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286BC1065670 for ; Sun, 18 Jan 2009 16:53:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id AFCAC8FC0A for ; Sun, 18 Jan 2009 16:53:21 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0IGrEhX005070; Sun, 18 Jan 2009 16:53:14 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LOate-0000WY-9j; Sun, 18 Jan 2009 16:53:14 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id n0IGrDvZ014379; Sun, 18 Jan 2009 16:53:13 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id n0IGrDDt014369; Sun, 18 Jan 2009 16:53:13 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 18 Jan 2009 16:53:13 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Attila Nagy In-Reply-To: <49720DFE.3080808@fsn.hu> Message-ID: <20090118164930.R24894@ury.york.ac.uk> References: <496B115F.1000105@fsn.hu> <4970BB63.7030601@andric.com> <4970E8C0.1080005@FreeBSD.org> <49720DFE.3080808@fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Maxim Sobolev , Dimitry Andric , freebsd-current@FreeBSD.org Subject: Re: FreeBSD panics with 64GiB of RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 16:53:22 -0000 On Sat, 17 Jan 2009, Attila Nagy wrote: > Hello, > > I've already tried something similar. The effect of the patch is this: > http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png > > BTW, this: > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-bootonly.iso > boots up fine (to sysinstall). > I haven't installed FreeBSD for years (I'm using netboot), is this i386? > That could explain the situation. I'm confused. That link is a snapshot of amd64 -CURRENT from December. The first email in this thread said you were trying -CURRENT anmd64 and it wasn't working. So, which ones work and which don't? Are we looking at a regression since December or has this been fixed between whatever image you first tested and the December snapshot? Gavin From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 17:03:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA5661065679 for ; Sun, 18 Jan 2009 17:03:22 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id 497C98FC19 for ; Sun, 18 Jan 2009 17:03:21 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by bwz3 with SMTP id 3so75090bwz.19 for ; Sun, 18 Jan 2009 09:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=CXUZtdwjW6iC7hyUleH2A1GVy+Qwl7bqZGnqFPOEPbk=; b=ChrT9hTREFmzUoRw7Ek+yfdWOkMNxQMRxuku3N/hjmXcg82X1eMfy2i5nqnkbG3l1D zYY3zU3SK9puHEEkf8/UCySR6KCnor7HG6o4HiF85OugqK5jvf2oX3OeIM/LKcxzWCRa AuzRvj/ILI7RPQXkzWVy15AF4H89W3znWOjUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=FElxLdbHSekrbqldhDtiGKCWM+mT62HwZaQ5Uf74TawC2QxTM445exUaPOBYf2S35Z uJnLXFAI22XoxDTO53OnooF0OBJVvWmhjM2MHbQv7NCFx0v6NNsMn6dInlWg2fcEWabB EX02h5smSJM/c4z2CzPzw4BlOHToLlhkkBMts= Received: by 10.181.141.18 with SMTP id t18mr1219361bkn.203.1232297929058; Sun, 18 Jan 2009 08:58:49 -0800 (PST) Received: by 10.181.22.6 with HTTP; Sun, 18 Jan 2009 08:58:49 -0800 (PST) Message-ID: <6eb82e0901180858s5329645bx4cbf0846bfe49c7f@mail.gmail.com> Date: Mon, 19 Jan 2009 00:58:49 +0800 From: "Rong-en Fan" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: promise sata150 tx4 gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 17:03:23 -0000 With the same hardware, CURRENT can't detect this card while BIOS and 7.x can. I'm running amd64 and today's CURRENT. Verbosed dmesg can be found at http://www.rafan.org/FreeBSD/ata/dmesg.boot It seems to me that somehow this device does not show up. pciconf -lv does not show a device with unattached driver, neither. Anything I can look at? Thanks, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 19:53:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86E0106564A for ; Sun, 18 Jan 2009 19:53:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 82DBA8FC0A for ; Sun, 18 Jan 2009 19:53:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from exbe05.intra.dlr.de ([192.168.35.38]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Jan 2009 20:39:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Jan 2009 20:39:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: problem with nss_ldap Thread-Index: Acl5pH/ym+3P83IxQeK7hx0vFU2YbA== From: To: X-OriginalArrivalTime: 18 Jan 2009 19:39:59.0442 (UTC) FILETIME=[8C6E8320:01C979A4] Cc: Subject: problem with nss_ldap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: harti@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 19:53:18 -0000 Hi, for a year or so I had nss_ldap connected to an active directory (with = openldap23-sasl-client) on a year-old current. Yesterday I've rebuilt = everything and I started to get 'undefined symbols' (for example = gss_equal_oid) when running any program needing pw or group entries. = After some poking around I fixed these by adding -lgssapi to the = Makefiles for libgssapi_krb5.so and libgssap_spnego.so. Now getent, = local login and everything works fine, except cron and sshd. Both create entries in /var/log/messages like:=20 Jan 18 20:00:02 knopdnsimu13f cron[1495]: GSSAPI Error: Miscellaneous = failure (see = text)=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5=A5ZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ= ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ Jan 18 20:00:02 knopdnsimu13f kernel: ZZZZZZZZZZZZZZZZ I've tried to figure out in which of the dozens of layered libraries = (gss, sasl, ssl, ......) this error is generated but did not find = anything. This is on amd64, krb5 enabled in pam, gssapi disabled in sshd_config = (as I said, this worked before). Any ideas? harti From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 20:16:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D2B31065673 for ; Sun, 18 Jan 2009 20:16:50 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 216E48FC16 for ; Sun, 18 Jan 2009 20:16:48 +0000 (UTC) (envelope-from christof.schulze@gmx.net) Received: (qmail invoked by alias); 18 Jan 2009 20:16:46 -0000 Received: from dslb-088-074-162-020.pools.arcor-ip.net (EHLO eri.localnet) [88.74.162.20] by mail.gmx.net (mp058) with SMTP; 18 Jan 2009 21:16:46 +0100 X-Authenticated: #3549759 X-Provags-ID: V01U2FsdGVkX1+XlpMRZXaX3qeEJ26DcnF3nvFyq/R7qOZseZbbdX PC8qOffLRNIis9 From: Christof Schulze To: freebsd-current@freebsd.org Date: Sun, 18 Jan 2009 21:16:30 +0100 User-Agent: KMail/1.10.4 (FreeBSD/7.1-BETA2; KDE/4.1.4; i386; ; ) References: <20090104011107.143069c3@ccschu935> <20090104115508.0acc416c@ccschu935> <20090104144112.7c83ff56.stas@FreeBSD.org> In-Reply-To: <20090104144112.7c83ff56.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2595940.L1AVsEeABx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200901182116.35061.christof.schulze@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 20:16:50 -0000 --nextPart2595940.L1AVsEeABx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag 04 Januar 2009 12:41:12 schrieb Stanislav Sedov: > On Sun, 4 Jan 2009 11:55:08 +0100 > > Christof Schulze mentioned: > > > I think you took the code intended for CURRENT. E.g. kproc_create > > > does not exists on 7.x. I believe there were some patches agains 7.x > > > as well. You may try to ask mav for them too. > > > Just for the record. They are the drivers from current which compile fine on 7.X after a small=20 adaption (kproc_create, kproc_exit) in thecode which I have documented for= =20 myself and maybe others on klausdieter0815.wordpress.com Regards Christof --nextPart2595940.L1AVsEeABx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAklzjiMACgkQpZfyPAmdZJkblwCcDaLXgUtq5ywSEMc0bF2u0RnJ 2c0AoL+PwsMGwUBmh2WwW/0Ek+6jAnIa =IKzX -----END PGP SIGNATURE----- --nextPart2595940.L1AVsEeABx-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 20:57:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1391A106566B for ; Sun, 18 Jan 2009 20:57:19 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 955758FC0A for ; Sun, 18 Jan 2009 20:57:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 19728 invoked by uid 60001); 18 Jan 2009 20:30:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=LudZ7S+lYWGiXUtM7W4KWZHFaRz+L/t422Nwwc2u1NBSS1OQt8owEWNIrfD6KsDUbJLnLa/vIO3xMsvOsYlOa9dnlNQ0gMjcSCdBDAP0YLUR3c8SrEdibxGBVvUFO5t8a7s598ZYQHtK/9DOKe0yC9QQ8tFnRHwDLhl1K5kEobQ=; X-YMail-OSG: HT5gLZ8VM1mD_Tf819r.OWZRKbdtIB8WLnQNl_W61PBF9QPW6wUPnCBvWmXjAsi_WRZpeJXouzNl_cF0v3tR41Z7gPI2QKdKBF2PEFQLAPkhmMHn4MmouMEEYbNfIsBhRtAUcRMuJUzV_2QAdLHesiy4e5P42Z7ccDm5OBuIocaal8oISFKbydSxSnuHaEljuw-- Received: from [98.242.222.229] by web63906.mail.re1.yahoo.com via HTTP; Sun, 18 Jan 2009 12:30:37 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Sun, 18 Jan 2009 12:30:37 -0800 (PST) From: Barney Cordoba To: freebsd-current@freebsd.org, Christof Schulze In-Reply-To: <200901182116.35061.christof.schulze@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <417204.17745.qm@web63906.mail.re1.yahoo.com> Cc: Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 20:57:19 -0000 Is there any interest in fixing this stupid and wrong error message to be something like "unresolved externals" at some point? --- On Sun, 1/18/09, Christof Schulze wrote: > From: Christof Schulze > Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 > To: freebsd-current@freebsd.org > Date: Sunday, January 18, 2009, 3:16 PM > Am Sonntag 04 Januar 2009 12:41:12 schrieb Stanislav Sedov: > > On Sun, 4 Jan 2009 11:55:08 +0100 > > > > Christof Schulze > mentioned: > > > > I think you took the code intended for > CURRENT. E.g. kproc_create > > > > does not exists on 7.x. I believe there were > some patches agains 7.x > > > > as well. You may try to ask mav for them > too. > > > > > > Just for the record. > They are the drivers from current which compile fine on 7.X > after a small > adaption (kproc_create, kproc_exit) in thecode which I have > documented for > myself and maybe others on klausdieter0815.wordpress.com > > Regards > > Christof From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 21:27:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F156106564A; Sun, 18 Jan 2009 21:27:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D738A8FC12; Sun, 18 Jan 2009 21:27:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7BFB23F129; Sun, 18 Jan 2009 21:27:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n0ILRrnJ001422; Sun, 18 Jan 2009 21:27:54 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 18 Jan 2009 10:31:34 +0100." <200901181031.35412.hselasky@c2i.net> Date: Sun, 18 Jan 2009 21:27:53 +0000 Message-ID: <1421.1232314073@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 21:27:57 -0000 In message <200901181031.35412.hselasky@c2i.net>, Hans Petter Selasky writes: >On Saturday 17 January 2009, Poul-Henning Kamp wrote: >> I just updated to -current and tried USB2 again, FTDI serial ports >> and Huawei 3G modem still not happy. > >Hi, > >I'm working on this issue. I have a machine with SSH which has the exact same >problem. It seems like it is UHCI related! I have a patch you can try: > >Edit "..../usb2/controller/uhci2.c" No luck, still stalls on FTDI based serial ports: usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 ushub0: on usbus0 ugen1.1: at usbus1 ushub1: on usbus1 ugen2.1: at usbus2 ushub2: on usbus2 ugen3.1: at usbus3 ushub3: on usbus3 ugen4.1: at usbus4 ushub4: on usbus4 [...] ushub0: 2 ports with 2 removable, self powered ushub2: 2 ports with 2 removable, self powered ushub1: 2 ports with 2 removable, self powered ushub3: 2 ports with 2 removable, self powered [...] usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! [...] usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 21:27:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F156106564A; Sun, 18 Jan 2009 21:27:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D738A8FC12; Sun, 18 Jan 2009 21:27:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7BFB23F129; Sun, 18 Jan 2009 21:27:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n0ILRrnJ001422; Sun, 18 Jan 2009 21:27:54 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 18 Jan 2009 10:31:34 +0100." <200901181031.35412.hselasky@c2i.net> Date: Sun, 18 Jan 2009 21:27:53 +0000 Message-ID: <1421.1232314073@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 21:27:57 -0000 In message <200901181031.35412.hselasky@c2i.net>, Hans Petter Selasky writes: >On Saturday 17 January 2009, Poul-Henning Kamp wrote: >> I just updated to -current and tried USB2 again, FTDI serial ports >> and Huawei 3G modem still not happy. > >Hi, > >I'm working on this issue. I have a machine with SSH which has the exact same >problem. It seems like it is UHCI related! I have a patch you can try: > >Edit "..../usb2/controller/uhci2.c" No luck, still stalls on FTDI based serial ports: usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 ushub0: on usbus0 ugen1.1: at usbus1 ushub1: on usbus1 ugen2.1: at usbus2 ushub2: on usbus2 ugen3.1: at usbus3 ushub3: on usbus3 ugen4.1: at usbus4 ushub4: on usbus4 [...] ushub0: 2 ports with 2 removable, self powered ushub2: 2 ports with 2 removable, self powered ushub1: 2 ports with 2 removable, self powered ushub3: 2 ports with 2 removable, self powered [...] usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! [...] usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 01:45:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163601065686 for ; Mon, 19 Jan 2009 01:45:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id CE6018FC19 for ; Mon, 19 Jan 2009 01:45:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2524318rvf.43 for ; Sun, 18 Jan 2009 17:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=K/uzVSavL9vlghb+6PPf/By5PpkLkDs9ai0D6DmUghk=; b=St4STFWBzdpwul7Cqf12NGCDZ2NCkM6xNNQK3i6k8ZuSB67Psgue9pQbsLhKgdQzpx X8IfygPjH9GBElTykDDPAzJEHNc3bBGxSfA3B6Tw2AJ03C7yEDa33/jndQWm/5k+4/Dx WIeKFrWZYB83f/M8sMCaE1A5V/MK/sKncLVYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=p6+DAcHHys8+w2Hxa/nLwwLvrs9KpBKIvNx+ojl8zvi6Y/v3BUgsEGLwjplD2UVfcm QgPmbiRJ5Ib2wpBkRWVe3oIra+AYbkbW/bOvR9hn703j6w2sajl091vuHfZO1p6jHxS2 3d0q+neAvQ6OPWs5bI+fmi6DazJGtZGrL4Zs0= Received: by 10.140.174.11 with SMTP id w11mr2549105rve.83.1232329508589; Sun, 18 Jan 2009 17:45:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm8807811rvb.6.2009.01.18.17.45.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Jan 2009 17:45:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n0J1j0eE075861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 10:45:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n0J1j0Wi075857; Mon, 19 Jan 2009 10:45:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 19 Jan 2009 10:45:00 +0900 From: Pyun YongHyeon To: Kim Culhan Message-ID: <20090119014500.GB75541@cdnetworks.co.kr> References: <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> <20090110031839.GK30747@cdnetworks.co.kr> <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> <20090111063124.GE42714@cdnetworks.co.kr> <89dbfdc30901180210s45cabfaao1f0f15afa780b82f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89dbfdc30901180210s45cabfaao1f0f15afa780b82f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: msk Marvell Yukon 88E8038 hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 01:45:09 -0000 On Sun, Jan 18, 2009 at 05:10:02AM -0500, Kim Culhan wrote: > On Sun, Jan 11, 2009 at 1:31 AM, Pyun YongHyeon wrote: > > On Sat, Jan 10, 2009 at 08:19:50AM -0500, Kim Culhan wrote: > > > On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon wrote: > > > > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > > > > > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > > > > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > > > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > > > > > > > Ok, then how about disabling TSO/Tx checksum offload? > > > > > > (eg. ifconfig msk0 -tso -txcsum) > > > > > > > > > > This stops the messages: in_cksum_skip: out of data by 56952 > > > > > > > > Ok, would you try attached patch? > > > > > > With the patch there are no in_cksum_skip messages > > > > > > > Thanks for testing! > > > > > a cvsup session still has: > > > Network write failure: Connection timed out > > > > > > > That's odd, I can't reproduce this on my box. If you disable Tx > > checksum offload of msk(4), cvsup session completes without > > problems? > > When cvsup plains network errors, can you still send/receive > > packets with msk(4)? > > Sorry for the noise re: Network write failure > > This was caused by an unrelated network problem. > Thanks for feedback. > Thanks for the patch, this fixes the complaints: in_cksum_skip: out of data > > The present dmesg is: > > Jan 17 18:11:01 lapster kernel: mskc0: Ethernet> port 0x2000-0x20ff mem 0xd0100000-0xd0103fff irq 16 at > device 0.0 on pci2 > Jan 17 18:11:01 lapster kernel: msk0: Yukon FE Id 0xb7 Rev 0x01> on mskc0 > Jan 17 18:11:01 lapster kernel: can't re-use a leaf (jabbers)! > Jan 17 18:11:01 lapster kernel: msk0: disabling jumbo frame support > Jan 17 18:11:01 lapster kernel: msk0: Ethernet address: 00:1b:24:59:5b:7a > Jan 17 18:11:01 lapster kernel: miibus0: on msk0 > Jan 17 18:11:01 lapster kernel: e1000phy0: Fast Ethernet PHY> PHY 0 on miibus0 > Jan 17 18:11:01 lapster kernel: e1000phy0: 10baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, auto > Jan 17 18:11:01 lapster kernel: mskc0: [FILTER] > > The problem with msk not working with ACPI enabled is well known, is > there anything > I can do to get this working? > Sorry, I have no idea. freebsd-acpi@ would be more appropriate list. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 01:55:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C685106566B for ; Mon, 19 Jan 2009 01:55:03 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4338FC1A for ; Mon, 19 Jan 2009 01:55:02 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1029718ywe.13 for ; Sun, 18 Jan 2009 17:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=jP8c+fJlBAukbEf/qSOuRhi3fOHID292coi8mPcR9a4=; b=U846QI7kq46VfEmFjgY0ng+DvodCfJy58kkIh3zOAKi2FLvFD2bKA8koSB9Yzr4X80 ljOq9oNM1ZjZyebRQiGJoS9uvw4pAIZaNR2+cHJq1CZgXExMsvDfkIw1Jm5XK3YwSD5E HYMqK4GkfebX7q2ZW3FFFvAxsQKP+Fer2TTcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=fJjSCfMQwB4JqUpH5xAnSVmV2u+m6WLAmVw/Os0nb7lNljERc8McC8zJLRg6xL3kaB jvIoV/dhqnl1oIhGfTddbZ/ePct9pL7MU4m090Q4XkHI+JLIrwwmMd5Z9GIF3dskiTXX hPKW38zCLtYg7XUhaoysAHIO+xoQE4VoNgOGw= Received: by 10.150.138.1 with SMTP id l1mr1114315ybd.233.1232328553825; Sun, 18 Jan 2009 17:29:13 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.6.12]) by mx.google.com with ESMTPS id 9sm7863171ywf.43.2009.01.18.17.29.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Jan 2009 17:29:13 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id F29E0B8067; Sun, 18 Jan 2009 22:29:08 -0300 (BRT) Received: from 189.71.52.229 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Sun, 18 Jan 2009 23:29:08 -0200 (BRST) Message-ID: <1da1bb16c32753bce066b3ba33c02573.squirrel@cygnus.homeunix.com> In-Reply-To: <20090115233553.GA24679@datura.dylex.net> References: <20090115233553.GA24679@datura.dylex.net> Date: Sun, 18 Jan 2009 23:29:08 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: SATA DMA errors on second ICH10 bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 01:55:03 -0000 may be related to this, I found on vr-zone.com: http://www.theinquirer.net/inquirer/news/374/1050374/seagate-barracudas-7200-11-failing matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 02:25:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C531065672 for ; Mon, 19 Jan 2009 02:25:27 +0000 (UTC) (envelope-from o.roeschke@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DED9B8FC16 for ; Mon, 19 Jan 2009 02:25:26 +0000 (UTC) (envelope-from o.roeschke@gmx.net) Received: (qmail invoked by alias); 19 Jan 2009 01:58:45 -0000 Received: from wipux2.wifo.uni-mannheim.de (EHLO [127.0.0.1]) [134.155.48.202] by mail.gmx.net (mp052) with SMTP; 19 Jan 2009 02:58:45 +0100 X-Authenticated: #26761920 X-Provags-ID: V01U2FsdGVkX1+3rB9t+MW3vH5sAVBPZPMepef/L8hFa4qkjp0nN3 CZCHKpKwIbcbw5 From: Oliver Roeschke To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="=-BP9BotMELBkvfFu5qnZX" Date: Mon, 19 Jan 2009 02:58:34 +0100 Message-Id: <1232330314.13652.11.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 X-Mailman-Approved-At: Mon, 19 Jan 2009 03:44:24 +0000 Subject: Kernel traps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: o.roeschke@gmx.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 02:25:27 -0000 --=-BP9BotMELBkvfFu5qnZX Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi... I just started testing 8-CURRENT and I have to say it really rocks. Is so incredibly fast (even with WITNESS activated). Great work!!! Currently I'm using 8-CURRENT within VMware workstation (6.0.4) and XEN (3.3.0) as para-virtualized domain. I've seen some kernel traps which appear on XEN and VMware, and some only on XEN or VMware. I've tried to collect them all, and saved them in the attached text-file. I'm currently running on SVN revision 187392. I'm experimenting for over a week now, and always seen the traps. How can I help resolve this issues? Since I'm experimenting in virtual machines it's no problem to test whatever needed. greetz olli --=-BP9BotMELBkvfFu5qnZX Content-Disposition: attachment; filename=kernel-traces Content-Type: text/plain; name=kernel-traces; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit XEN: ======================================== template-8_CURRENT# umount /mnt/new lock order reversal: 1st 0xc2b788b8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1190 2nd 0xc2b78bdc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1339 KDB: stack backtrace: X_db_sym_numargs(c024df5a,da14ea38,c00f1115,4,c0249670,...) at X_db_sym_numargs+0x146 kdb_backtrace(4,c0249670,c2896008,c2895f38,da14ea94,...) at kdb_backtrace+0x29 witness_display_spinlock(c0250bd0,c2b78bdc,c02414d6,c2895f38,c0261f23,...) at witness_display_spinlock+0x75 witness_checkorder(c2b78bdc,9,c0261f23,53b,c2b78bf8,...) at witness_checkorder+0x839 __lockmgr_args(c2b78bdc,80400,c2b78bf8,0,0,...) at __lockmgr_args+0x797 vop_stdlock(da14eb9c,c0261f23,c03eae00,80400,c2b78b84,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c027cfa0,da14eb9c,da14ebbc,c02a4f60,c2b78b84,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2b78b84,80400,c0261f23,53b,c2b91aec,...) at _vn_lock+0x5e ffs_sbupdate(c2a96a00,1,c2b2d240,4eb,c0284820,...) at ffs_sbupdate+0x7ba dounmount(c2a96a00,8000000,c2b2d240,471,eb08ac66,...) at dounmount+0x45c unmount(c2b2d240,da14ed08,8,c,c027fc70,...) at unmount+0x2e0 syscall(da14ed48) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d224f, esp = 0xbf7fe56c, ebp = 0xbf7fe638 --- template-8_CURRENT# rm -rf .cshrc .profile COPYRIGHT bin/ boot/ dist/ etc/ lib libexec/ rescue/ root/ sbin/ tmp/* usr/ var rm: bin/rcp: Operation not permitted rm: bin/: Directory not empty lock order reversal: 1st 0xcf831160 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc2a90e00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: X_db_sym_numargs(c024df5a,da151a84,c00f1115,4,c0249670,...) at X_db_sym_numargs+0x146 kdb_backtrace(4,c0249670,c2893f88,c2896070,da151ae0,...) at kdb_backtrace+0x29 witness_display_spinlock(c0250bd0,c2a90e00,c0262a60,c2896070,c02626f9,...) at witness_display_spinlock+0x75 witness_checkorder(c2a90e00,9,c02626f9,107,0,...) at witness_checkorder+0x839 _sx_xlock(c2a90e00,0,c02626f9,107,d01e9018,...) at _sx_xlock+0x85 ufsdirhash_enduseful(0,e,c2b90000,cf831100,d01e9018,...) at ufsdirhash_enduseful+0x2f5 ufsdirhash_remove(c2b7a348,d01e9018,18,da151b70,da151b6c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c2b97d9c,c2b961e0,500800c,0,0,...) at ufs_dirremove+0xe5 ufs_readdir(da151c40,da151c40,0,da151c40,c2b95d9c,...) at ufs_readdir+0x39f VOP_REMOVE_APV(c0297c00,da151c40,2,0,282191b8,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c2b2d000,ffffff9c,282191b8,0,da151c90,...) at kern_unlinkat+0x187 kern_unlink(c2b2d000,282191b8,0,da151d3c,c02282b3,...) at kern_unlink+0x27 unlink(c2b2d000,da151d08,4,c0267928,c027fb50,...) at unlink+0x22 syscall(da151d48) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815aedf, esp = 0xbf7fec1c, ebp = 0xbf7fec48 --- Trying to mount root from ufs:/dev/ad0s1a warning: no time-of-day clock registered, system time will not be set accurately lock order reversal: 1st 0xc28d7044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xc294b7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: X_db_sym_numargs(c024df5a,c27b9920,c00f1115,4,c0249670,...) at X_db_sym_numargs+0x146 kdb_backtrace(4,c0249670,c2892728,c2896008,c27b997c,...) at kdb_backtrace+0x29 witness_display_spinlock(c0250bd0,c294b7ac,c0244b0f,c2896008,c02579f0,...) at witness_display_spinlock+0x75 witness_checkorder(c294b7ac,1,c02579f0,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c294b7ac,200501,c294b7c8,0,0,...) at __lockmgr_args+0x237 ffs_syncvnode(c27b9a8c,c00f0ebb,c0266952,200501,c294b754,...) at ffs_syncvnode+0x58a VOP_LOCK1_APV(c0297c00,c27b9a8c,c28d3e24,c02a4f60,c294b754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c294b754,200501,c02579f0,81f,4,...) at _vn_lock+0x5e vget(c294b754,200501,c28d3d80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c087bc98,0,c0263f23,127,c27b9c2c,...) at vnode_pager_lock+0x1e0 vm_fault(c28d7000,80db000,2,8,80db700,...) at vm_fault+0x1df dblfault_handler() at dblfault_handler+0x4e7 --- trap 0x17, eip = 0, esp = 0, ebp = 0 --- When entering username on login for the first time after reboot: lock order reversal: 1st 0xc041d264 XCONS LOCK (XCONS LOCK) @ /usr/src/sys/dev/xen/console/console.c:290 2nd 0xc2946004 ttymtx (ttymtx) @ /usr/src/sys/dev/xen/console/console.c:274 KDB: stack backtrace: X_db_sym_numargs(c024df5a,c27f1bb4,c00f1115,4,c0249670,...) at X_db_sym_numargs+0x146 kdb_backtrace(4,c0249670,c28921e0,c2894f60,c27f1c10,...) at kdb_backtrace+0x29 witness_display_spinlock(c0250bd0,c2946004,c0253348,c2894f60,c02675ea,...) at witness_display_spinlock+0x75 witness_checkorder(c2946004,9,c02675ea,112,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c2946004,0,c02675ea,112,0,...) at _mtx_lock_flags+0xc4 xencons_rx(c0522000,1,c0267654,56,c024c985,...) at xencons_rx+0x4a xencons_handle_input(0,c27f1cc8,c00a3a94,c02aef40,c28cfd38,...) at xencons_handle_input+0x5d intr_event_execute_handlers(c28d17ec,c28cfd00,c02470f5,4dd,c28cfd70,...) at intr_event_execute_handlers+0x125 intr_event_add_handler(c28d06e0,c27f1d38,c0246e64,32d,c28d17ec,...) at intr_event_add_handler+0x42f fork_exit(c0092ee0,c28d06e0,c27f1d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc27f1d70, ebp = 0 --- VMware Workstation 6.0.4 ============================================ Trying to mount root from ufs:/dev/ad0s1a lock order reversal: 1st 0xc2954044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xc2ae77ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0be7dc5,c267d90c,c0874305,4,c0be3343,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0be3343,c2907728,c290c180,c267d968,...) at kdb_backtrace+0x29 _witness_debugger(c0beaaaf,c2ae77ac,c0bde3b4,c290c180,c0bf178c,...) at _witness_debugger+0x25 witness_checkorder(c2ae77ac,1,c0bf178c,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c2ae77ac,200501,c2ae77c8,0,0,...) at __lockmgr_args+0x237 ffs_lock(c267da78,c08740ab,c0c0d859,200501,c2ae7754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cee520,c267da78,c294fe24,c0d02600,c2ae7754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2ae7754,200501,c0bf178c,81f,4,...) at _vn_lock+0x5e vget(c2ae7754,200501,c294fd80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c187d744,0,c0c0ae3a,127,c267dc18,...) at vnode_pager_lock+0x1e0 vm_fault(c2954000,80db000,2,8,80db700,...) at vm_fault+0x1df trap_pfault(5,0,c0c1afbb,2e7,c294dd34,...) at trap_pfault+0x118 trap(c267dd38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- Jan 18 02:15:38 template_8-CURRENT syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...done All buffers synced. lock order reversal: 1st 0xc2ae79c4 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1190 2nd 0xc2ae7df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0be7dc5,c267d9c4,c0874305,4,c0be3343,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0be3343,c290c180,c290c0b0,c267da20,...) at kdb_backtrace+0x29 _witness_debugger(c0beaaaf,c2ae7df4,c0bda8f2,c290c0b0,c0bf178c,...) at _witness_debugger+0x25 witness_checkorder(c2ae7df4,9,c0bf178c,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c2ae7df4,80100,c2ae7e10,0,0,...) at __lockmgr_args+0x797 vop_stdlock(c267db28,c08740ab,c0bdab23,80100,c2ae7d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0cc62c0,c267db28,c294fe24,c0d02600,c2ae7d9c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2ae7d9c,80100,c0bf178c,81f,8,...) at _vn_lock+0x5e vget(c2ae7d9c,80100,c294fd80,160,c0bdaa45,...) at vget+0xc9 devfs_allocv(c2b63180,c2b79000,c267dbc0,c294fd80,c2ae796c,...) at devfs_allocv+0x11a devfs_root(c2b79000,80000,c267dbfc,c294fd80,0,...) at devfs_root+0x51 dounmount(c2b79000,80000,c294fd80,c24b1230,0,...) at dounmount+0x3f6 vfs_unmountall(c0be48c6,0,c0be4970,12a,0,...) at vfs_unmountall+0x4e boot(c0d36c50,0,c0be4970,ad,c267dd2c,...) at boot+0x44f reboot(c294fd80,c267dcf8,4,c0bebc92,c0cc9cc8,...) at reboot+0x4b syscall(c267dd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050ff3, esp = 0xbfbfe8cc, ebp = 0xbfbfe9a8 --- Uptime: 36s lock order reversal: 1st 0xc24f5690 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc2d68c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0be7dc5,c27eca74,c0874305,4,c0be3343,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0be3343,c29096d8,c290c1e8,c27ecad0,...) at kdb_backtrace+0x29 _witness_debugger(c0beaaaf,c2d68c00,c0c0992e,c290c1e8,c0c095c7,...) at _witness_debugger+0x25 witness_checkorder(c2d68c00,9,c0c095c7,107,0,...) at witness_checkorder+0x839 _sx_xlock(c2d68c00,0,c0c095c7,107,c8349454,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c2a98000,c24f5630,c8349454,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c2da8c30,c8349454,1454,c27ecb60,c27ecb5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c2da4d9c,c2da8bb8,500800c,0,c2da4d9c,...) at ufs_dirremove+0xe5 ufs_remove(c27ecc30,c27ecc30,0,c27ecc30,c2da496c,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0cee520,c27ecc30,2,c2d9a2a4,bfbfde87,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c2d7a480,ffffff9c,bfbfde87,0,c27ecc80,...) at kern_unlinkat+0x187 kern_unlink(c2d7a480,bfbfde87,0,c27ecd2c,c0b36d23,...) at kern_unlink+0x27 unlink(c2d7a480,c27eccf8,4,c0beb2e4,c0cc9890,...) at unlink+0x22 syscall(c27ecd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2818026f, esp = 0xbfbfd98c, ebp = 0xbfbfda08 --- --=-BP9BotMELBkvfFu5qnZX-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 03:45:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E81291065672 for ; Mon, 19 Jan 2009 03:45:12 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id BABCC8FC21 for ; Mon, 19 Jan 2009 03:45:12 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-233-126.phil.east.verizon.net [70.20.233.126]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 7F7FA6D54A; Mon, 19 Jan 2009 12:24:28 +0900 (JST) Date: Sun, 18 Jan 2009 22:22:56 -0500 From: Yoshihiro Ota To: Alexander Best , Miroslav Lachman <000.fbsd@quip.cz> Message-Id: <20090118222256.6985d69c.ota@j.email.ne.jp> In-Reply-To: <49734EDA.2030000@quip.cz> References: <49734EDA.2030000@quip.cz> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: periodic(8) daily should backup bsdlabel(8) / fdisk(8) disk labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 03:45:13 -0000 Alexander: I suggest you to follow up the PR with your patch so that your patch is visible from the PR, at least. Taking too long to get someone's attention is a whole different problem, though. Thanks, Hiro On Sun, 18 Jan 2009 16:46:34 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Alexander Best wrote: > > hi there, > > > > i was browsing the pr-db and found this pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 > > > > i think it would be a very nice addition to daily. i attached > > 220.backup-bsdlabels. it can also be found here: > > http://digitalfreaks.org/~lavalamp/220.backup-bsdlabels > > > > backing up the disk labels on a daily basis sounds like a really good thing to > > do. also the pr states that netbsd and openbsd are doing this for over 10 > > years now. > > I second that. I posted in to this PR back in 2007, but this PR has > still no attention of commiters. :( > > It is sad that some "simple" PRs are opened for more than 3 years. It > should be commited or refused and closed. > > Miroslav Lachman > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 03:55:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E47410656F5 for ; Mon, 19 Jan 2009 03:55:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2060E8FC2B for ; Mon, 19 Jan 2009 03:55:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LOlEb-000H7x-II for freebsd-current@freebsd.org; Mon, 19 Jan 2009 03:55:33 +0000 Message-ID: <4973F9AE.8080209@psg.com> Date: Mon, 19 Jan 2009 12:55:26 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: arp_proxy: ignoring request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 03:55:37 -0000 soekris 5501 8-current Jan 15 13:08 GMT, post arp changes FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Thu Jan 15 14:15:24 UTC 2009 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 i386 Jan 18 00:00:04 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:02:10 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:02:23 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:08:06 soek0 kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 18 00:08:10 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:12:22 soek0 kernel: arp_proxy: ignoring request from 192.168.0.30 via wlan0, expecting bridge0 Jan 18 00:14:10 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:19:26 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:19:39 soek0 kernel: arp_proxy: ignoring request from 192.168.0.28 via vr3, expecting bridge0 Jan 18 00:20:10 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 Jan 18 00:23:13 soek0 kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 .----------------. | | | b --wlan0| | r | 192.168.0.0/24 ext iij | i --- vr1| LAN hosts, PPP/NAT ---|vr0--- d | DHCP Clients WAN | g --- vr2| pptp 200-209 | e | ,.. | 0 --- vr3| | | `----------------' wlans_ath0=wlan0 create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey yourekidding weptxkey 1 media autoselect mode 11g up" cloned_interfaces=bridge0 ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up" ifconfig_vr1=up ifconfig_vr2=up ifconfig_vr3=up gateway_enable=YES pptpd_enable=YES arpproxy_all=YES From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 07:25:24 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E485F106564A for ; Mon, 19 Jan 2009 07:25:24 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 983318FC0C for ; Mon, 19 Jan 2009 07:25:24 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0J7PMmT084098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Jan 2009 23:25:23 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49742ADA.5080509@FreeBSD.org> Date: Sun, 18 Jan 2009 23:25:14 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 07:25:25 -0000 Hi, I am reviewing differences between amd64 and i386 GENERIC kernels and noticed that for some unclear reason we ship amd64 GENERIC with NTFS module compiled in, while i386 without it. IMHO both should match. The question is whether NTFS should be i386 way (opt in) or amd64 way (opt out) in GENERIC? What do people think? -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:08:40 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7109E1065675 for ; Mon, 19 Jan 2009 08:08:40 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate3.pacific.net.sg (smtpgate3.pacific.net.sg [203.81.36.33]) by mx1.freebsd.org (Postfix) with SMTP id A15E98FC3C for ; Mon, 19 Jan 2009 08:08:39 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 11205 invoked from network); 19 Jan 2009 07:41:58 -0000 Received: from bb116-14-19-136.singnet.com.sg (HELO ?10.0.1.131?) (oceanare@116.14.19.136) by smtpgate3.pacific.net.sg with ESMTPA; 19 Jan 2009 07:41:57 -0000 From: Erich Dollansky To: Maxim Sobolev In-Reply-To: <49742ADA.5080509@FreeBSD.org> References: <49742ADA.5080509@FreeBSD.org> Content-Type: text/plain Date: Mon, 19 Jan 2009 15:41:59 +0800 Message-Id: <1232350919.2322.3.camel@P2120.somewherefaraway.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 08:08:40 -0000 Hi, On Sun, 2009-01-18 at 23:25 -0800, Maxim Sobolev wrote: > Hi, > > I am reviewing differences between amd64 and i386 GENERIC kernels and > noticed that for some unclear reason we ship amd64 GENERIC with NTFS > module compiled in, while i386 without it. IMHO both should match. The > question is whether NTFS should be i386 way (opt in) or amd64 way (opt the Windows file system? I would use opt-in as most people will not need it. Erich > out) in GENERIC? What do people think? > > -Maxim > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:13:26 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A708A1065670; Mon, 19 Jan 2009 08:13:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD208FC19; Mon, 19 Jan 2009 08:13:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0214773098; Mon, 19 Jan 2009 09:18:43 +0100 (CET) Date: Mon, 19 Jan 2009 09:18:43 +0100 From: Luigi Rizzo To: Maxim Sobolev Message-ID: <20090119081843.GA49607@onelab2.iet.unipi.it> References: <49742ADA.5080509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49742ADA.5080509@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 08:13:27 -0000 On Sun, Jan 18, 2009 at 11:25:14PM -0800, Maxim Sobolev wrote: > Hi, > > I am reviewing differences between amd64 and i386 GENERIC kernels and > noticed that for some unclear reason we ship amd64 GENERIC with NTFS > module compiled in, while i386 without it. IMHO both should match. The > question is whether NTFS should be i386 way (opt in) or amd64 way (opt > out) in GENERIC? What do people think? given that the sysutils/fusefs-ntfs seems to be much better, I'd rather remove the in-kernel ntfs from both and replace with a note on what to do to use fusefs-ntfs cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:35:40 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A57106564A for ; Mon, 19 Jan 2009 08:35:40 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5FC8FC17 for ; Mon, 19 Jan 2009 08:35:39 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0J8ZchL087659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 00:35:39 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49743B52.5040108@FreeBSD.org> Date: Mon, 19 Jan 2009 00:35:30 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Erich Dollansky References: <49742ADA.5080509@FreeBSD.org> <1232350919.2322.3.camel@P2120.somewherefaraway.com> In-Reply-To: <1232350919.2322.3.camel@P2120.somewherefaraway.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 08:35:40 -0000 Erich Dollansky wrote: > Hi, > > On Sun, 2009-01-18 at 23:25 -0800, Maxim Sobolev wrote: >> Hi, >> >> I am reviewing differences between amd64 and i386 GENERIC kernels and >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS >> module compiled in, while i386 without it. IMHO both should match. The >> question is whether NTFS should be i386 way (opt in) or amd64 way (opt > > the Windows file system? > > I would use opt-in as most people will not need it. Any particular reason why not? Memory is cheap, 100-200KB of extra kernel code doesn't really matter today, while NTFS is probably the most widespread filesystem after MSDOS. Therefore supporting it in the GENERIC out of the box even in the read-only mode (our NTFS driver is read-only AFAIK) could benefit many users. -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:55:07 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66041106566B; Mon, 19 Jan 2009 08:55:07 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 275E68FC0C; Mon, 19 Jan 2009 08:55:06 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 0DFF5B02E8; Mon, 19 Jan 2009 09:39:24 +0100 (CET) MIME-Version: 1.0 Date: Mon, 19 Jan 2009 09:39:23 +0100 From: Marian Hettwer To: Maxim Sobolev In-Reply-To: <49743B52.5040108@FreeBSD.org> References: <49743B52.5040108@FreeBSD.org> Message-ID: <87233becc6141aa652478f1b3cef36f1@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Erich Dollansky , current@FreeBSD.org Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 08:55:07 -0000 On Mon, 19 Jan 2009 00:35:30 -0800, Maxim Sobolev wrote: > Erich Dollansky wrote: >> Hi, >> >> On Sun, 2009-01-18 at 23:25 -0800, Maxim Sobolev wrote: >>> Hi, >>> >>> I am reviewing differences between amd64 and i386 GENERIC kernels and >>> noticed that for some unclear reason we ship amd64 GENERIC with NTFS >>> module compiled in, while i386 without it. IMHO both should match. The >>> question is whether NTFS should be i386 way (opt in) or amd64 way (opt >> >> the Windows file system? >> >> I would use opt-in as most people will not need it. > > Any particular reason why not? Memory is cheap, 100-200KB of extra > kernel code doesn't really matter today, while NTFS is probably the most > widespread filesystem after MSDOS. Therefore supporting it in the > GENERIC out of the box even in the read-only mode (our NTFS driver is > read-only AFAIK) could benefit many users. > I'd like to have it loaded as a modile on demand, as soon as I try to mount_ntfs. I would throw it out of GENERIC if its up to me. Although I don't have technical arguments for throwing it out of GENERIC ;) Cheers, ./Marian From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 09:35:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6650106564A for ; Mon, 19 Jan 2009 09:35:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3BD8FC18 for ; Mon, 19 Jan 2009 09:35:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1071378ywe.13 for ; Mon, 19 Jan 2009 01:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BskkgjcIVSAkgbrDHx7C2+0zLibhsu04z/JsjLwX7D0=; b=pNqUk+gy5DUGoN6A4TqfejgoghA8jqr+NumDYhrwNJB+Iky3RZ8hc9zDt6h9WIX2aU JStf+E4AUlDnnHWONaInZIQE72oforSRPdQ8qS/oYObX7SAx1j16L0v4DQGfPt6ffuqT fVrgy+0utX2Pw52lnEqiPZR6VubuvwpwVnvE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v1FYx0meGDjGVhdJom/UvhwK+zZzcVvPNf9wmuMdMT62YRx4ButNZ5kkxSN6MgQ9Tm nIOA1vbjhbEN+Qi4AahzWNrRs17qujqkqXO//kvV96sw7M0F17Vf9ffG8GZwMxdcLKqC do36gwGb3Lt04TjPi5aztb6qmpmlwakpFR1SY= MIME-Version: 1.0 Received: by 10.90.70.6 with SMTP id s6mr2311234aga.33.1232356086277; Mon, 19 Jan 2009 01:08:06 -0800 (PST) In-Reply-To: <49743B52.5040108@FreeBSD.org> References: <49742ADA.5080509@FreeBSD.org> <1232350919.2322.3.camel@P2120.somewherefaraway.com> <49743B52.5040108@FreeBSD.org> Date: Mon, 19 Jan 2009 03:08:06 -0600 Message-ID: <790a9fff0901190108r4eb3232bqfc6a0c8af8cd7c71@mail.gmail.com> From: Scot Hetzel To: Maxim Sobolev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Erich Dollansky , "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:35:53 -0000 On Mon, Jan 19, 2009 at 2:35 AM, Maxim Sobolev wrote: > Erich Dollansky wrote: >> >> Hi, >> >> On Sun, 2009-01-18 at 23:25 -0800, Maxim Sobolev wrote: >>> >>> Hi, >>> >>> I am reviewing differences between amd64 and i386 GENERIC kernels and >>> noticed that for some unclear reason we ship amd64 GENERIC with NTFS module >>> compiled in, while i386 without it. IMHO both should match. The question is >>> whether NTFS should be i386 way (opt in) or amd64 way (opt >> >> the Windows file system? >> >> I would use opt-in as most people will not need it. > > Any particular reason why not? Memory is cheap, 100-200KB of extra kernel > code doesn't really matter today, while NTFS is probably the most widespread > filesystem after MSDOS. Therefore supporting it in the GENERIC out of the > box even in the read-only mode (our NTFS driver is read-only AFAIK) could > benefit many users. > I have been using FreeBSD/amd64, and my kernel doesn't include the NTFS filesystem complied in. Instead, I let the mount command load the ntfs.ko kernel module when I need read access to my NTFS filesystems. Since a buildkernel will install the ntfs.ko kernel module by default, their is no need to have the NTFS filesystem complied into GENERIC. Scot From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 09:37:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61E9C1065702 for ; Mon, 19 Jan 2009 09:37:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD8F8FC0C for ; Mon, 19 Jan 2009 09:37:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1C1BC3F129; Mon, 19 Jan 2009 09:37:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n0J9bMUv015306; Mon, 19 Jan 2009 09:37:22 GMT (envelope-from phk@critter.freebsd.dk) To: Scot Hetzel From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Jan 2009 03:08:06 CST." <790a9fff0901190108r4eb3232bqfc6a0c8af8cd7c71@mail.gmail.com> Date: Mon, 19 Jan 2009 09:37:22 +0000 Message-ID: <15305.1232357842@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Erich Dollansky , "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:37:26 -0000 In message <790a9fff0901190108r4eb3232bqfc6a0c8af8cd7c71@mail.gmail.com>, Scot Hetzel writes: >On Mon, Jan 19, 2009 at 2:35 AM, Maxim Sobolev wrote: >> Erich Dollansky wrote: >> Any particular reason why not? Memory is cheap, 100-200KB of extra kernel >> code doesn't really matter today, while NTFS is probably the most widespread >> filesystem after MSDOS. Therefore supporting it in the GENERIC out of the >> box even in the read-only mode (our NTFS driver is read-only AFAIK) could >> benefit many users. >Since a buildkernel will install the ntfs.ko kernel module by default, >their is no need to have the NTFS filesystem complied into GENERIC. Seconded, we should move towards a mode modular kernel, not less. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 09:47:34 2009 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BEF2106566B for ; Mon, 19 Jan 2009 09:47:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D48E88FC0A for ; Mon, 19 Jan 2009 09:47:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8DB8373098; Mon, 19 Jan 2009 10:52:51 +0100 (CET) Date: Mon, 19 Jan 2009 10:52:51 +0100 From: Luigi Rizzo To: Maxim Sobolev Message-ID: <20090119095251.GB52277@onelab2.iet.unipi.it> References: <49742ADA.5080509@FreeBSD.org> <20090119081843.GA49607@onelab2.iet.unipi.it> <49743BC5.3040508@sippysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49743BC5.3040508@sippysoft.com> User-Agent: Mutt/1.4.2.3i Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:47:34 -0000 On Mon, Jan 19, 2009 at 12:37:25AM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: > >On Sun, Jan 18, 2009 at 11:25:14PM -0800, Maxim Sobolev wrote: > >>Hi, > >> > >>I am reviewing differences between amd64 and i386 GENERIC kernels and > >>noticed that for some unclear reason we ship amd64 GENERIC with NTFS > >>module compiled in, while i386 without it. IMHO both should match. The > >>question is whether NTFS should be i386 way (opt in) or amd64 way (opt > >>out) in GENERIC? What do people think? > > > >given that the sysutils/fusefs-ntfs seems to be much better, > >I'd rather remove the in-kernel ntfs from both and replace > >with a note on what to do to use fusefs-ntfs > > I guess that you can use sysutils/fusefs-ntfs with or without NTFS in > the kernel, so that this may not very strong reason to me. Apart from what others stated (it is trivial to have it loaded on demand), The major reason is that the kernel ntfs is quite limited in what it can do (e.g. readonly) and possibly not as well maintained as the fusefs counterpart. So replacing the lines in the kernel config with pointers to fusefs-ntfs helps advertising what I consider a better solution to the particular problem. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 09:51:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0763D10656C3 for ; Mon, 19 Jan 2009 09:51:39 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 818148FC0A for ; Mon, 19 Jan 2009 09:51:38 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.2/8.14.2) with ESMTP id n0J9pbRD047263; Mon, 19 Jan 2009 12:51:37 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 19 Jan 2009 12:51:37 +0300 (MSK) From: Maxim Konovalov To: Alexander Best In-Reply-To: Message-ID: <20090119125046.V7355@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: periodic(8) daily should backup bsdlabel(8) / fdisk(8) disk labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:51:40 -0000 On Sun, 18 Jan 2009, 15:33+0100, Alexander Best wrote: > hi there, > > i was browsing the pr-db and found this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 > > i think it would be a very nice addition to daily. i attached > 220.backup-bsdlabels. it can also be found here: > http://digitalfreaks.org/~lavalamp/220.backup-bsdlabels > > backing up the disk labels on a daily basis sounds like a really > good thing to do. also the pr states that netbsd and openbsd are > doing this for over 10 years now. > Last time I looked over this PR I failed to find the discussed functionality in NetBSD. Where is it? -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 09:56:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31D4106566B for ; Mon, 19 Jan 2009 09:56:25 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E39D8FC0C for ; Mon, 19 Jan 2009 09:56:25 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.2/8.14.2) with ESMTP id n0J9uOY4047532; Mon, 19 Jan 2009 12:56:24 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 19 Jan 2009 12:56:24 +0300 (MSK) From: Maxim Konovalov To: Alexander Best In-Reply-To: <20090119125046.V7355@mp2.macomnet.net> Message-ID: <20090119125502.I7355@mp2.macomnet.net> References: <20090119125046.V7355@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: periodic(8) daily should backup bsdlabel(8) / fdisk(8) disk labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 09:56:26 -0000 And it would be nice if Someone (tm) sums all bits including periodic.conf and periodic.conf.5 deltas and post an update patch as a PR followup. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 10:16:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6390B1065673 for ; Mon, 19 Jan 2009 10:16:51 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB9D8FC12 for ; Mon, 19 Jan 2009 10:16:51 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n0JAGmWL060486; Mon, 19 Jan 2009 10:16:49 GMT (envelope-from ken@mthelicon.com) Message-ID: <70F6CB3B39D847A2B684D2EE9F5BDF3F@PegaPegII> From: "Pegasus Mc Cleaft" To: "Scot Hetzel" References: <15305.1232357842@critter.freebsd.dk> In-Reply-To: <15305.1232357842@critter.freebsd.dk> Date: Mon, 19 Jan 2009 10:16:48 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Antivirus: avast! (VPS 090118-0, 18/01/2009), Outbound message X-Antivirus-Status: Clean Cc: Erich Dollansky , current@freebsd.org Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 10:16:51 -0000 From: "Poul-Henning Kamp" > In message <790a9fff0901190108r4eb3232bqfc6a0c8af8cd7c71@mail.gmail.com>, > Scot > Hetzel writes: >>On Mon, Jan 19, 2009 at 2:35 AM, Maxim Sobolev >>wrote: >>> Erich Dollansky wrote: > >>> Any particular reason why not? Memory is cheap, 100-200KB of extra >>> kernel >>> code doesn't really matter today, while NTFS is probably the most >>> widespread >>> filesystem after MSDOS. Therefore supporting it in the GENERIC out of >>> the >>> box even in the read-only mode (our NTFS driver is read-only AFAIK) >>> could >>> benefit many users. > >>Since a buildkernel will install the ntfs.ko kernel module by default, >>their is no need to have the NTFS filesystem complied into GENERIC. > > Seconded, we should move towards a mode modular kernel, not less. What about making MINIMAL, TYPICAL, and KITCHENSINK kernel config file? To be honest, I dont know of a single machine that I have setup that actually runs on the generic kernel for any length of time aside from installing. If I had my drothers, I would like the generic kernel to be as fully packed as possible because I tend to use the probe messages on boot as a guide-line for what things I will keep from the generic config. I tend to copy the generic config and then start hacking it up from there. That said, NTFS is something I would not use during the install but for those users that do run there machine off the GENERIC kernel gotten through whatever way they installed, it may prove to be a bit annoying to not have all the bells and whistles in by default. Peg From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 11:11:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98CE10658EA for ; Mon, 19 Jan 2009 11:11:08 +0000 (UTC) (envelope-from alp@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id E5BA28FCA4 for ; Mon, 19 Jan 2009 11:10:50 +0000 (UTC) (envelope-from alp@rsu.ru) Received: from [195.208.252.128] (pyhalov.cc.rsu.ru [195.208.252.128]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id n0JAamAf094457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jan 2009 13:36:49 +0300 (MSK) (envelope-from alp@rsu.ru) From: Alexander Pyhalov To: freebsd-current@freebsd.org Content-Type: text/plain Date: Mon, 19 Jan 2009 13:36:48 +0300 Message-Id: <1232361408.1758.7.camel@pyhalov.cc.rsu.ru> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Dump device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 11:11:25 -0000 Hello. I'm trying to build FreeBSD-7.1, but have a problem - it panics after "Trying to mount root from ufs:/dev/ar0s1a " and says "Fatal double fault". Before sending bug report I want to look at core dump, but I haven't found how to set dumpdev variable in kernel (setting it in loader doesn't work). Could you assist me? P.S. Setting dumpdev in rc.conf will not work, because system can't mount root fs and read it. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 11:24:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886F91065909; Mon, 19 Jan 2009 11:24:05 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 40FCC8FC1F; Mon, 19 Jan 2009 11:24:05 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2687815rvf.43 for ; Mon, 19 Jan 2009 03:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem; bh=/zVo/sWzLEIPkATW/ayCDrEgQHNFBV9b4KPuVcesB04=; b=IFJG0KYyC3R70ANrOFZge63i+47KLLptRPXLtuwuwGedK5Mc9LQKT+BilpsYbsfUc3 lNLYtlu3e9wLB2jVk9UcnLxyj29OzfouJ+tdd0u5g2Ioe711aEdx0ZyxyacdnSX1ol3B M5wDpZ9H8XT/q7t7BGOuVAZekVroe40FWUZQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=GayLjSKISAPVRVIyFCzQF33pl2cWGwRLml8NFaSP2cSGhiQ/yo2itGxEKh/KGMyX49 7kOFuHW9yJgUi7gjmSnoVpK/c+1X8r8L5p8n0DV46szl5trXigjdDqnUJrvlrLo1CfFd 7m2zOMtpNLDslWG62iR1DRmsBgEqfeL2Fs0tg= Received: by 10.142.139.5 with SMTP id m5mr2320887wfd.237.1232364244939; Mon, 19 Jan 2009 03:24:04 -0800 (PST) Received: from freebsd.weongyo.org ([211.53.35.67]) by mx.google.com with ESMTPS id 9sm8543299wfc.36.2009.01.19.03.24.01 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jan 2009 03:24:03 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Mon, 19 Jan 2009 20:23:33 +0900 From: Weongyo Jeong Date: Mon, 19 Jan 2009 20:23:33 +0900 To: current@freebsd.org Message-ID: <20090119112333.GA36305@freebsd.weongyo.org> Mail-Followup-To: current@freebsd.org, freebsd-usb@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-usb@freebsd.org Subject: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 11:24:20 -0000 Hello, I would like to commit urtw(4) driver for supporting Realtek's 8187L wireless chipset based on USB into HEAD by the end of the week if there are no objections. And the license of files would be as follows that AFAIK it's based on OpenBSD's template license file: /*- * Copyright (c) 2008 Weongyo Jeong * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ Because I'm not a lawyer it'd definitely fail to answer about your detailed questions. Just one thing I want to is that it's okay if it's enough to use in *BSD, OpenSolaris and etc. Not want to go into troubles. :-) I'm looking for a person to port from USB to NEWUSB and if you want to test you can find the sources at: http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:50:22 2009 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F691065672 for ; Mon, 19 Jan 2009 08:50:22 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D5C208FC1B for ; Mon, 19 Jan 2009 08:50:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0J8bX0X087754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 00:37:34 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <49743BC5.3040508@sippysoft.com> Date: Mon, 19 Jan 2009 00:37:25 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Rizzo References: <49742ADA.5080509@FreeBSD.org> <20090119081843.GA49607@onelab2.iet.unipi.it> In-Reply-To: <20090119081843.GA49607@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Jan 2009 12:25:52 +0000 Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 08:50:22 -0000 Luigi Rizzo wrote: > On Sun, Jan 18, 2009 at 11:25:14PM -0800, Maxim Sobolev wrote: >> Hi, >> >> I am reviewing differences between amd64 and i386 GENERIC kernels and >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS >> module compiled in, while i386 without it. IMHO both should match. The >> question is whether NTFS should be i386 way (opt in) or amd64 way (opt >> out) in GENERIC? What do people think? > > given that the sysutils/fusefs-ntfs seems to be much better, > I'd rather remove the in-kernel ntfs from both and replace > with a note on what to do to use fusefs-ntfs I guess that you can use sysutils/fusefs-ntfs with or without NTFS in the kernel, so that this may not very strong reason to me. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 15:40:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC089106566B; Mon, 19 Jan 2009 15:40:41 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7112C8FC1C; Mon, 19 Jan 2009 15:40:41 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so3018792wfg.7 for ; Mon, 19 Jan 2009 07:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a5NuwGlBr2h/38uxgY53/8mTJbV9gnOSu6fNywiHPDo=; b=eIYamuvqQt76p+OKbWFnkV2aH3g4u6riVy9swczq0qeiudLlh9zOJUu9pjndmHIhfW BNCvMnXcbFzSI+euZkpwyIU9PY4K0dc2jMamsDQ7mbKfIanSLilV/XA+ByLPufXRV+5f MGN5QfA79l4Ikj6qA/9DOmTjGbNvat07kBmGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LALqyST2zrHyCd7fDZxLDR2NzSm0UdFXmlrf+ygOTuVwCVUCQ01qpdR1G7nkU6rG8Z YzP3RNsBc/vSy03/p5m+46ZGb8OptnMDnxT21Oo4Ec3Z2uV6Z6viltTgywKTlF1yBjbc KRGtf6yGW6i7lw6m3XeJiWm/bP/8caVxcnMJg= MIME-Version: 1.0 Received: by 10.142.82.6 with SMTP id f6mr2413100wfb.182.1232379640801; Mon, 19 Jan 2009 07:40:40 -0800 (PST) In-Reply-To: <4970DB6C.4030200@elischer.org> References: <4970DB6C.4030200@elischer.org> Date: Mon, 19 Jan 2009 13:40:40 -0200 Message-ID: From: Eduardo Meyer To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 15:40:42 -0000 > obviously you did some other commands here.. > something generated 2 million packets.. Julian, its a production enviroment, firewall was up for a few minutes. Thats the reason. > I was thinking of adding a 'reroute' ipfw keyword.. kind of like > 'fwd {original dest} ip from any to any' > because 'fwd' does cause the routing decision to be redone. > > The fib of the process that opens the socket controls where packets from the > local machine are sent. divert does cause this too, not "not fib X" seems to work fine... I wish you could make the "setfib" action be kept in state with keep-state only for the static rules, but I guess it will be done for all dynamic rules too, since keep-state makes dynamic rules repeat the static one, right? would something like ipfw add prob 0.5 setfib 1 all from X to any out keep-state be used to balance (per session) between FIB tables? > > > > > -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 16:33:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED361065687; Mon, 19 Jan 2009 16:33:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 85E7A8FC0A; Mon, 19 Jan 2009 16:33:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 3F12C46B23; Mon, 19 Jan 2009 11:33:57 -0500 (EST) Date: Mon, 19 Jan 2009 16:33:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20090119081843.GA49607@onelab2.iet.unipi.it> Message-ID: References: <49742ADA.5080509@FreeBSD.org> <20090119081843.GA49607@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 16:33:58 -0000 On Mon, 19 Jan 2009, Luigi Rizzo wrote: > On Sun, Jan 18, 2009 at 11:25:14PM -0800, Maxim Sobolev wrote: >> >> I am reviewing differences between amd64 and i386 GENERIC kernels and >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS module >> compiled in, while i386 without it. IMHO both should match. The question is >> whether NTFS should be i386 way (opt in) or amd64 way (opt out) in GENERIC? >> What do people think? > > given that the sysutils/fusefs-ntfs seems to be much better, I'd rather > remove the in-kernel ntfs from both and replace with a note on what to do to > use fusefs-ntfs There was a long thread on this topic on arch@, maybe 6 months ago, in which it was concluded that: (1) fusefs is fairly (quite) unstable if used intensively (2) our kernel ntfs code is much faster for read-only operation I doubt either of these has changed significantly in that time, but I'm willing to be surprised. I watched my office-mate here at the CL suffer through the fuse/ntfs support on FreeBSD 7.x for several weeks before giving up and using UFS on his larger USB-attached storage. He saw a range of panics in that time, all in fuse. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 16:35:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C2D1065732; Mon, 19 Jan 2009 16:35:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 912A58FC1A; Mon, 19 Jan 2009 16:35:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4CC6246B2C; Mon, 19 Jan 2009 11:35:24 -0500 (EST) Date: Mon, 19 Jan 2009 16:35:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Weongyo Jeong In-Reply-To: <20090119112333.GA36305@freebsd.weongyo.org> Message-ID: References: <20090119112333.GA36305@freebsd.weongyo.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 16:35:27 -0000 On Mon, 19 Jan 2009, Weongyo Jeong wrote: > I would like to commit urtw(4) driver for supporting Realtek's 8187L > wireless chipset based on USB into HEAD by the end of the week if there are > no objections. And the license of files would be as follows that AFAIK it's > based on OpenBSD's template license file: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pref-license.html > > /*- > * Copyright (c) 2008 Weongyo Jeong > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > Because I'm not a lawyer it'd definitely fail to answer about your > detailed questions. Just one thing I want to is that it's okay if it's > enough to use in *BSD, OpenSolaris and etc. Not want to go into > troubles. :-) > > I'm looking for a person to port from USB to NEWUSB and if you want to > test you can find the sources at: > > http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz > > regards, > Weongyo Jeong > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 17:07:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FC27106566B; Mon, 19 Jan 2009 17:07:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id D8A4A8FC0C; Mon, 19 Jan 2009 17:07:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n0JGiK9n059935; Mon, 19 Jan 2009 10:44:20 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n0JGiKsL059934; Mon, 19 Jan 2009 10:44:20 -0600 (CST) (envelope-from brooks) Date: Mon, 19 Jan 2009 10:44:20 -0600 From: Brooks Davis To: Robert Watson Message-ID: <20090119164420.GD16785@lor.one-eyed-alien.net> References: <20090119112333.GA36305@freebsd.weongyo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 19 Jan 2009 10:44:20 -0600 (CST) Cc: Weongyo Jeong , current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 17:07:34 -0000 --GpGaEY17fSl8rd50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 19, 2009 at 04:35:24PM +0000, Robert Watson wrote: >=20 > On Mon, 19 Jan 2009, Weongyo Jeong wrote: >=20 >> I would like to commit urtw(4) driver for supporting Realtek's 8187L=20 >> wireless chipset based on USB into HEAD by the end of the week if there= =20 >> are no objections. And the license of files would be as follows that=20 >> AFAIK it's based on OpenBSD's template license file: >=20 > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pref= -license.html This file is outdated. While this remains our prefered license, the current OpenBSD prefered license is the ISC licesed which is allowed by the license policy we published to developers last year. We should probably replace th= is page with that policy. -- Brooks >> /*- >> * Copyright (c) 2008 Weongyo Jeong >> * >> * Permission to use, copy, modify, and distribute this software for any >> * purpose with or without fee is hereby granted, provided that the above >> * copyright notice and this permission notice appear in all copies. >> * >> * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTI= ES >> * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >> * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >> * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >> * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >> * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >> * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >> */ >>=20 >> Because I'm not a lawyer it'd definitely fail to answer about your >> detailed questions. Just one thing I want to is that it's okay if it's >> enough to use in *BSD, OpenSolaris and etc. Not want to go into >> troubles. :-) >>=20 >> I'm looking for a person to port from USB to NEWUSB and if you want to >> test you can find the sources at: >>=20 >> http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz >>=20 >> regards, >> Weongyo Jeong >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >>=20 > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" >=20 --GpGaEY17fSl8rd50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJdK3jXY6L6fI4GtQRAnPWAKC9Ey6/wy1PpjnuOQ9bWwcGootxYwCeMZgD yzJBeM/vhY2UqTSX8gt5BwE= =pEsC -----END PGP SIGNATURE----- --GpGaEY17fSl8rd50-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 17:30:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF891065670; Mon, 19 Jan 2009 17:30:02 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id 792BA8FC1B; Mon, 19 Jan 2009 17:30:02 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from pgw.vnode.se ([77.110.37.134] helo=hackbook.local) by websrv01.jr-hosting.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LOxGY-000KhJ-SO; Mon, 19 Jan 2009 17:46:23 +0100 Message-ID: <4974AE57.80005@FreeBSD.org> Date: Mon, 19 Jan 2009 17:46:15 +0100 From: Joel Dahl User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org, freebsd-usb@freebsd.org References: <20090119112333.GA36305@freebsd.weongyo.org> In-Reply-To: <20090119112333.GA36305@freebsd.weongyo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 17:30:03 -0000 Weongyo Jeong skrev: > Hello, > > I would like to commit urtw(4) driver for supporting Realtek's 8187L > wireless chipset based on USB into HEAD by the end of the week if there > are no objections. And the license of files would be as follows that > AFAIK it's based on OpenBSD's template license file: > > /*- > * Copyright (c) 2008 Weongyo Jeong > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > Because I'm not a lawyer it'd definitely fail to answer about your > detailed questions. Just one thing I want to is that it's okay if it's > enough to use in *BSD, OpenSolaris and etc. Not want to go into > troubles. :-) Well, the FreeBSD project uses the following license: /*- * Copyright (c) [year] [your name] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -- Joel From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 18:09:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F71106567C for ; Mon, 19 Jan 2009 18:09:24 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9B6ED8FC2C for ; Mon, 19 Jan 2009 18:09:21 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 19 Jan 2009 18:09:17 -0000 Received: from 85-127-16-58.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.16.58] by mail.gmx.net (mp006) with SMTP; 19 Jan 2009 19:09:17 +0100 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1/8ORw10Ln8dfZ0nsYtv8jI1kedJz9luKQWET5HDH F5cnVukHEZ8RXQ From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Mon, 19 Jan 2009 19:09:07 +0100 User-Agent: KMail/1.10.4 (FreeBSD/7.1-RELEASE-p1; KDE/4.1.4; i386; ; ) References: <49742ADA.5080509@FreeBSD.org> <20090119081843.GA49607@onelab2.iet.unipi.it> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901191909.09733.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: Luigi Rizzo , Robert Watson Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 18:09:25 -0000 On Monday 19 January 2009 17:33:57 Robert Watson wrote: > On Mon, 19 Jan 2009, Luigi Rizzo wrote: > > On Sun, Jan 18, 2009 at 11:25:14PM -0800, Maxim Sobolev wrote: > >> I am reviewing differences between amd64 and i386 GENERIC kernels and > >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS > >> module compiled in, while i386 without it. IMHO both should match. The > >> question is whether NTFS should be i386 way (opt in) or amd64 way (opt > >> out) in GENERIC? What do people think? > > > > given that the sysutils/fusefs-ntfs seems to be much better, I'd rather > > remove the in-kernel ntfs from both and replace with a note on what to do > > to use fusefs-ntfs > > There was a long thread on this topic on arch@, maybe 6 months ago, in > which it was concluded that: > > (1) fusefs is fairly (quite) unstable if used intensively > (2) our kernel ntfs code is much faster for read-only operation > > I doubt either of these has changed significantly in that time, but I'm > willing to be surprised. I watched my office-mate here at the CL suffer > through the fuse/ntfs support on FreeBSD 7.x for several weeks before > giving up and using UFS on his larger USB-attached storage. He saw a range > of panics in that time, all in fuse. In that thread it is claimed that "Kernel NTFS support is about 10x faster than ntfs-3g on FreeBSD". That's contrary to my experience: I tried reading a ~1GB directory containing large files from a USB disk. ntfs-3g: ~6.1MB/s kernel ntfs: ~3.7MB/s ntfs-3g is rather slow and kernel ntfs is even worse. For smaller files ntfs-3g also is faster for me. ntfs-3g seems to do lots of unnecessary read operations. gstat(8) shows read speed of ~13-14MB/s. So half of the data seems to be thrown away. From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 18:14:52 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C4401065678; Mon, 19 Jan 2009 18:14:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A6AB48FC0C; Mon, 19 Jan 2009 18:14:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0JIDYLS077387; Mon, 19 Jan 2009 11:13:34 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 19 Jan 2009 11:14:07 -0700 (MST) Message-Id: <20090119.111407.-1037166918.imp@bsdimp.com> To: joel@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4974AE57.80005@FreeBSD.org> References: <20090119112333.GA36305@freebsd.weongyo.org> <4974AE57.80005@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 18:14:52 -0000 In message: <4974AE57.80005@FreeBSD.org> Joel Dahl writes: : Well, the FreeBSD project uses the following license: While this is the preferred license for the project, core@ published a license policy for files in the three last year or the year before. The ISC license, which was posted but I've cropped for my reply, is one of the ones on that list. While it may be preferable to have the license that Joel quoted, there's nothing wrong with the ISC license. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 18:02:51 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F67106566B for ; Mon, 19 Jan 2009 18:02:51 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: from web39108.mail.mud.yahoo.com (web39108.mail.mud.yahoo.com [209.191.87.227]) by mx1.freebsd.org (Postfix) with SMTP id 6A7568FC12 for ; Mon, 19 Jan 2009 18:02:51 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: (qmail 63592 invoked by uid 60001); 19 Jan 2009 17:36:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=jDSrprgUB0cqopWW5pBR6z3MgeEq8I0TpslSDm3lr7SCbucsIY3u3nWr4BnO+K5tr5KH0sNv+ElRuyBQ/NQoakXLCLwTEZb5KjEww1spcufzlYSquTR3Bx0PVkrNrAoyl2Yb2HfoMwv0AugwJfaF7pXYJoG59Pz3nTJYP+ILVTQ=; X-YMail-OSG: RYlivnYVM1lARnQZ4DjF9IyZn0RBVW0jPVVfR.sEV_tswZMhAfR9j1U6ViEA4P.qSyW9lAZDNaLgE1dz6sDzalT4sBipQiXztFRgaYuyjARXZkthEpi61spPpuBPboqFLkuvqHhIJ6NiNAGdMR95TFkTn6h16cBwPbYtq_bOmIxwLVcdbhlX50NRtpqb93X9.pXYIg-- Received: from [66.35.0.170] by web39108.mail.mud.yahoo.com via HTTP; Mon, 19 Jan 2009 09:36:11 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 19 Jan 2009 09:36:11 -0800 (PST) From: bf To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <540351.62331.qm@web39108.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 19 Jan 2009 18:18:54 +0000 Cc: bms@FreeBSD.org Subject: Re: Why LLVM may be a step forward X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf2006a@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 18:02:52 -0000 Bruce Simpson wrote: > Hi, > I'll chime in with my analysis... Garrett Cooper wrote: > On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler wrote: > >> I never took care about GPLv2 and v3 >> >>> differences but know, this seems to come to relevance in some way. I ducked in here to find tinderbox results, and I find the fur flying over this compiler issue ... > [1] RAW described the phenomenon of "paradigm shift" in terms of waiting > for a current generation of scientific dogma-followers to die off before > a new, testable *and* experience-able theroem about reality could be > shared with all other humans. A bit cutting, but sometimes we have to be > to administer the medicine! Er, you mean like after he read Thomas Kuhn's "The Structure of Scientific Revolutions"? If you're going to take the trouble to mention someone in connection with these ideas, you may as well give credit where credit is due, rather than citing some derivative writer. ... > I wager this "strange loop" of improved compiler software, originates > from something which process engineers e.g. in agriculture and the food > sciences have understood for years -- and an isolated example of where > engineering in the physical world, can lead to better engineering in the > virtual world. I wager that the only reason this example is "isolated" is that you haven't looked very hard. My question (and it's sincere, I don't ask to just to rile anyone) is: regardless of the opinions we express here, how "free" is FreeBSD with respect to this choice? That is, are there organizations or individuals that now support FreeBSD, without whom development may slow or stall, that have strong positions with regard to adopting a particular compiler and toolchain, or not adopting another, and thus may dictate the choice? Is there a line drawn in the sand with respect to adopting later versions of gcc in the base system because of the license, for example, or is that still to be decided? Regards, b. From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:01:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F0CB1065670 for ; Mon, 19 Jan 2009 19:01:41 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4388FC19 for ; Mon, 19 Jan 2009 19:01:41 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n0JJ1ei3007345; Mon, 19 Jan 2009 11:01:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jan 2009 11:01:28 -0800 Message-ID: In-Reply-To: <4973F9AE.8080209@psg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: arp_proxy: ignoring request Thread-Index: Acl56fM03dAb4P5eQ5ei/NYh4aQGbwAflVtw References: <4973F9AE.8080209@psg.com> From: "Li, Qing" To: "Randy Bush" , "FreeBSD Current" Cc: Subject: RE: arp_proxy: ignoring request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 19:01:41 -0000 Hi, I will look into it. I may ask you for additional information offline. Thanks, --Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Randy Bush > Sent: Sunday, January 18, 2009 7:55 PM > To: FreeBSD Current > Subject: arp_proxy: ignoring request >=20 > soekris 5501 8-current Jan 15 13:08 GMT, post arp changes >=20 > FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Thu Jan 15 > 14:15:24 UTC 2009 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 > i386 >=20 > Jan 18 00:00:04 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:02:10 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:02:23 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:08:06 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.12 via wlan0, expecting bridge0 > Jan 18 00:08:10 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:12:22 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.30 via wlan0, expecting bridge0 > Jan 18 00:14:10 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:19:26 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:19:39 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.28 via vr3, expecting bridge0 > Jan 18 00:20:10 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 > Jan 18 00:23:13 soek0 kernel: arp_proxy: ignoring request from > 192.168.0.10 via vr2, expecting bridge0 >=20 > .----------------. > | | > | b --wlan0| > | r | 192.168.0.0/24 > ext iij | i --- vr1| LAN hosts, > PPP/NAT ---|vr0--- d | DHCP Clients > WAN | g --- vr2| pptp 200-209 > | e | ,.. > | 0 --- vr3| > | | > `----------------' >=20 > wlans_ath0=3Dwlan0 > create_args_wlan0=3D"wlanmode hostap channel 11 ssid rgnet-aden wep > wepkey > yourekidding weptxkey 1 media autoselect mode 11g up" > cloned_interfaces=3Dbridge0 > ifconfig_bridge0=3D"192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 > addm > wlan1 up" > ifconfig_vr1=3Dup > ifconfig_vr2=3Dup > ifconfig_vr3=3Dup > gateway_enable=3DYES > pptpd_enable=3DYES > arpproxy_all=3DYES > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:19:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EB6106564A for ; Mon, 19 Jan 2009 19:19:36 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [66.184.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 43D378FC1B for ; Mon, 19 Jan 2009 19:19:36 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.7.6.254] ([63.76.235.163]) (authenticated bits=0) by lexi.siliconlandmark.com (8.14.2/8.14.2) with ESMTP id n0JJJWaw008711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Jan 2009 19:19:33 GMT (envelope-from andy@siliconlandmark.com) Message-Id: <0CDC7501-0C01-4458-9FF9-DA523BE4DC70@siliconlandmark.com> From: Andre Guibert de Bruet To: "Gary R. Van Sickle" In-Reply-To: <550B7A950EEE45359972D2A54F44EA5C@DFW5RB41> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 14:19:26 -0500 References: Your message of "Fri, 16 Jan 2009 15:32:30 EST." <23243.1232140762@critter.freebsd.dk> <550B7A950EEE45359972D2A54F44EA5C@DFW5RB41> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8877/Mon Jan 19 10:18:35 2009 on lexi.siliconlandmark.com X-Virus-Status: Clean Cc: lcdproc@lists.omnipotent.net, current@freebsd.org Subject: Re: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 19:19:36 -0000 On Jan 16, 2009, at 8:17 PM, Gary R. Van Sickle wrote: >> From: Poul-Henning Kamp >> >> In message >> , >> Andre Guibert de Bruet writes: >>> On Jan 16, 2009, at 5:09 AM, Gary R. Van Sickle wrote: >>>>> Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves >>>>> as HID devices. >>>> >>>> ...but... they *are* HID devices. Why is this "unfortunate"? >> >> It's unfortunate, because they are HID devices only because >> that is what microchip.com supplies as a USB programming example. >> >> The actual protocol they talk has nothing to do with the HID >> specification. > > Ah. That's not "unfortunate", that's just sheer laziness on > iTuner's part. > Great, and I just bought one too. Welp, here's hoping whatever > nonstandard > protocol they do use works reasonably, and that the mfg gets their act > together on the next one. The iTuner parts are firmware upgradable, so there is hope. The Picolcd.com SDK has code that does the flashing on Windows so it would be a matter of porting it, if firmware that addresses the issue becomes available. I have purchased a couple of these and they've worked with LCDproc CVS HEAD with the quirk. I just upgraded my testbed to CURRENT and will be producing the appropriate patch for the USB2 stack, later tonight. Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:25:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD0A1065670 for ; Mon, 19 Jan 2009 19:25:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id CC9228FC13 for ; Mon, 19 Jan 2009 19:25:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LOzkC-000Ifz-Ju; Mon, 19 Jan 2009 19:25:08 +0000 Message-ID: <4974D393.8050907@psg.com> Date: Tue, 20 Jan 2009 04:25:07 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: "Li, Qing" References: <4973F9AE.8080209@psg.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: arp_proxy: ignoring request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 19:25:10 -0000 > I will look into it. I may ask you for additional information offline. > >> Jan 18 00:08:10 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 >> Jan 18 00:12:22 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.30 via wlan0, expecting bridge0 >> Jan 18 00:14:10 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 >> Jan 18 00:19:26 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 >> Jan 18 00:19:39 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.28 via vr3, expecting bridge0 >> Jan 18 00:20:10 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 >> Jan 18 00:23:13 soek0 kernel: arp_proxy: ignoring request from >> 192.168.0.10 via vr2, expecting bridge0 i got rid of >> arpproxy_all=YES and did manual arp proxying for pptp setup. thanks to Luiz Otavio O Souza for the clue bat. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:39:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80AC81065673 for ; Mon, 19 Jan 2009 19:39:58 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 378D78FC13 for ; Mon, 19 Jan 2009 19:39:57 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LOzyT-00079Y-AG for freebsd-current@freebsd.org; Mon, 19 Jan 2009 19:39:54 +0000 Received: from 193.33.173.33 ([193.33.173.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Jan 2009 19:39:53 +0000 Received: from c.kworr by 193.33.173.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Jan 2009 19:39:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Volodymyr Kostyrko Date: Mon, 19 Jan 2009 21:39:41 +0200 Lines: 15 Message-ID: References: <49742ADA.5080509@FreeBSD.org> <20090119081843.GA49607@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.33.173.33 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.1.19) Gecko/20090113 SeaMonkey/1.1.14 In-Reply-To: <20090119081843.GA49607@onelab2.iet.unipi.it> Sender: news Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 19:39:58 -0000 Luigi Rizzo wrote: >> I am reviewing differences between amd64 and i386 GENERIC kernels and >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS >> module compiled in, while i386 without it. IMHO both should match. The >> question is whether NTFS should be i386 way (opt in) or amd64 way (opt >> out) in GENERIC? What do people think? > > given that the sysutils/fusefs-ntfs seems to be much better, > I'd rather remove the in-kernel ntfs from both and replace > with a note on what to do to use fusefs-ntfs That's not. fuse-ntfs can't work with 4G files. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 21:24:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA43106566B for ; Mon, 19 Jan 2009 21:24:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7198F8FC13 for ; Mon, 19 Jan 2009 21:24:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz3 with SMTP id 3so144011bwz.19 for ; Mon, 19 Jan 2009 13:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gZYyZ4TQau6HoULOXIdQlzNkQ14r9v7SQkYNdO4ckYA=; b=RJEk3cH03v6ditd+6WB5qq5i3b8M9BOeJka6a2KZZDhaBCAKusEJ6r8qB+SC+u6yO3 R8C/XXvz5nXx2G5OJpFXpb2noRVCxNQuOo6eo54Cj9aICHhvbJBCOpHHTkiRP0NKTyut e4VSspwlA47jzHY2UA3GuBQZVnjY6aybWaTvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eHiSnJM1P76cpzBoOj/rhIufg/Yk0Mhs6tIIyC+Nma+LviD62nsGOjUMML8qqdnEHr flPvwgI8Eb+a+JP0zvLv1rxObF8OAJDNZ6x3fFQlmSkslHKqP/aNr0xw0D+VqVQc0DwT z/aL3sdJKj6pOfXxZDiyiddEId5NloGP0nsXc= MIME-Version: 1.0 Received: by 10.181.146.14 with SMTP id y14mr2218553bkn.16.1232400041142; Mon, 19 Jan 2009 13:20:41 -0800 (PST) In-Reply-To: <1232330314.13652.11.camel@phoenix.blechhirn.net> References: <1232330314.13652.11.camel@phoenix.blechhirn.net> Date: Mon, 19 Jan 2009 13:20:41 -0800 Message-ID: <7d6fde3d0901191320h73d9b372k185a7f8172cbe9e1@mail.gmail.com> From: Garrett Cooper To: o.roeschke@gmx.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel traps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 21:24:02 -0000 On Sun, Jan 18, 2009 at 5:58 PM, Oliver Roeschke wrote: > Hi... > > I just started testing 8-CURRENT and I have to say it really rocks. Is > so incredibly fast (even with WITNESS activated). Great work!!! > > Currently I'm using 8-CURRENT within VMware workstation (6.0.4) and XEN > (3.3.0) as para-virtualized domain. > > I've seen some kernel traps which appear on XEN and VMware, and some > only on XEN or VMware. I've tried to collect them all, and saved them in > the attached text-file. > > I'm currently running on SVN revision 187392. I'm experimenting for over > a week now, and always seen the traps. > > How can I help resolve this issues? Since I'm experimenting in virtual > machines it's no problem to test whatever needed. > > > greetz > olli Olli, Have you tried these resources yet? 1. http://www.lemis.com/grog/Papers/Debug-tutorial/ 2. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 21:27:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A04106564A; Mon, 19 Jan 2009 21:27:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9118B8FC08; Mon, 19 Jan 2009 21:27:39 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by mail-bw0-f10.google.com with SMTP id 3so144011bwz.19 for ; Mon, 19 Jan 2009 13:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=43pkIm7qrFjED6vN1hJF6uaVMkFBZLsldaAJ62ohqDU=; b=UxgwvlzT2CfEDjp8Vd8pwwcEK39VO16z6yvHUcoRw276Vqw875SCpZpxM0Rbr2OBpv bDc2jAYAWJDsJi4D4f8S0s1eIYH0fZeXbsEkw6euLjYDeSe6ju4/QdiPvcFjgMfDbbZB YNnTJzQKaFtRtk5gF2uWFS//yT3xCNXCPrkLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nes2yF48pyddIZ9RgvXma7PTTEKVFn3tgnKRFkN1VbA941IGia+STWJcqwH9jT5kAk G2qultwOwowIsOYzYeS/uuwBcwKqx7ilwkScOecg60X0MhwVAGf0qDshdJHyYQQM8zLN NkAP8xgTJ2kf//xpgpxaiV4DnJJZPxmO6OKfQ= MIME-Version: 1.0 Received: by 10.181.61.7 with SMTP id o7mr2211449bkk.85.1232400271696; Mon, 19 Jan 2009 13:24:31 -0800 (PST) In-Reply-To: <20090118164930.R24894@ury.york.ac.uk> References: <496B115F.1000105@fsn.hu> <4970BB63.7030601@andric.com> <4970E8C0.1080005@FreeBSD.org> <49720DFE.3080808@fsn.hu> <20090118164930.R24894@ury.york.ac.uk> Date: Mon, 19 Jan 2009 13:24:31 -0800 Message-ID: <7d6fde3d0901191324v2faf623dlbe9f43bf48e60b91@mail.gmail.com> From: Garrett Cooper To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Attila Nagy , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: FreeBSD panics with 64GiB of RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 21:27:40 -0000 On Sun, Jan 18, 2009 at 8:53 AM, Gavin Atkinson wrote: > On Sat, 17 Jan 2009, Attila Nagy wrote: > >> Hello, >> >> I've already tried something similar. The effect of the patch is this: >> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png >> >> BTW, this: >> >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-bootonly.iso >> boots up fine (to sysinstall). >> I haven't installed FreeBSD for years (I'm using netboot), is this i386? >> That could explain the situation. > > I'm confused. That link is a snapshot of amd64 -CURRENT from December. The > first email in this thread said you were trying -CURRENT anmd64 and it > wasn't working. > > So, which ones work and which don't? Are we looking at a regression since > December or has this been fixed between whatever image you first tested and > the December snapshot? > > Gavin Gavin, He's saying that the snapshot from December works, but the more current CURRENT, doesn't. Hence the screenshot from December. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 21:39:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB969106564A for ; Mon, 19 Jan 2009 21:39:43 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f15.google.com (mail-bw0-f15.google.com [209.85.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 616A38FC12 for ; Mon, 19 Jan 2009 21:39:43 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by bwz8 with SMTP id 8so7554918bwz.12 for ; Mon, 19 Jan 2009 13:39:42 -0800 (PST) Received: by 10.223.105.72 with SMTP id s8mr6433939fao.9.1232400887647; Mon, 19 Jan 2009 13:34:47 -0800 (PST) Received: by 10.223.112.75 with HTTP; Mon, 19 Jan 2009 13:34:47 -0800 (PST) Message-ID: <367b2c980901191334q7a81d8calad4e4b52cd38b5be@mail.gmail.com> Date: Mon, 19 Jan 2009 22:34:47 +0100 From: "Olivier SMEDTS" To: "freebsd-current@freebsd.org" In-Reply-To: <1232330314.13652.11.camel@phoenix.blechhirn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1232330314.13652.11.camel@phoenix.blechhirn.net> Subject: Re: Kernel traps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 21:39:44 -0000 2009/1/19 Oliver Roeschke : > Hi... > > I just started testing 8-CURRENT and I have to say it really rocks. Is > so incredibly fast (even with WITNESS activated). Great work!!! Just a "me too". I couldn't downgrade my desktop computer to -STABLE now with all the -CURRENT nice features... http://ivoras.sharanet.org/freebsd/freebsd8.html (and more) And -CURRENT is really *really* stable and rarely broken compared to -CURRENT some time ago (5.0-CURRENT time). That's great ! Big thanks to all the team/community... Olivier > Currently I'm using 8-CURRENT within VMware workstation (6.0.4) and XEN > (3.3.0) as para-virtualized domain. > > I've seen some kernel traps which appear on XEN and VMware, and some > only on XEN or VMware. I've tried to collect them all, and saved them in > the attached text-file. > > I'm currently running on SVN revision 187392. I'm experimenting for over > a week now, and always seen the traps. > > How can I help resolve this issues? Since I'm experimenting in virtual > machines it's no problem to test whatever needed. > > > greetz > olli > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 03:59:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DD9106566B for ; Tue, 20 Jan 2009 03:59:43 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [66.184.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 612E78FC0A for ; Tue, 20 Jan 2009 03:59:43 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.102] (c-76-112-231-135.hsd1.mi.comcast.net [76.112.231.135]) (authenticated bits=0) by lexi.siliconlandmark.com (8.14.2/8.14.2) with ESMTP id n0K3xdAg026086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jan 2009 03:59:39 GMT (envelope-from andy@siliconlandmark.com) Message-Id: <129DC2F8-C5ED-4382-957A-29B5DBE2FCC9@siliconlandmark.com> From: Andre Guibert de Bruet To: Hans Petter Selasky In-Reply-To: <24019.1232155811@critter.freebsd.dk> Content-Type: multipart/mixed; boundary=Apple-Mail-10-713703121 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 22:59:33 -0500 References: <24019.1232155811@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8878/Mon Jan 19 22:01:48 2009 on lexi.siliconlandmark.com X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 03:59:43 -0000 --Apple-Mail-10-713703121 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jan 16, 2009, at 8:30 PM, Poul-Henning Kamp wrote: > In message A42CF4263B9E@siliconlandmark.com>, Andre Guibert de Bruet writes: > >>>>> ...but... they *are* HID devices. Why is this "unfortunate"? >>> >>> It's unfortunate, because they are HID devices only because that >>> is what microchip.com supplies as a USB programming example. >>> >>> The actual protocol they talk has nothing to do with the HID >>> specification. >> >> PHK - I see that you committed the quirk for the 2X20. Would you mind >> committing the patch attached to PR usb/128803? Do you want me to >> produce the bits required for usb2 as well? > > USB2 patches should go to HPS@ still I think ? I have attached the 4x20 quirk patch for hpsusb. Thanks for all of your hard work! Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ --Apple-Mail-10-713703121 Content-Disposition: attachment; filename=picolcd.usb2.quirk.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="picolcd.usb2.quirk.diff" Content-Transfer-Encoding: 7bit Index: sys/dev/usb2/include/usb2_devtable.h =================================================================== --- sys/dev/usb2/include/usb2_devtable.h (revision 187457) +++ sys/dev/usb2/include/usb2_devtable.h (working copy) @@ -3401,6 +3401,12 @@ "USB-LCD 2x20", }, { + USB_VENDOR_ITUNERNET, USB_PRODUCT_ITUNERNET_USBLCD4X20, + 0, + "I-Tuner Networks", + "USB-LCD 4x20", + }, + { USB_VENDOR_JABLOTRON, USB_PRODUCT_JABLOTRON_PC60B, 0, "Jablotron", Index: sys/dev/usb2/include/usb2_devid.h =================================================================== --- sys/dev/usb2/include/usb2_devid.h (revision 187457) +++ sys/dev/usb2/include/usb2_devid.h (working copy) @@ -1511,6 +1511,7 @@ /* Ituner networks products */ #define USB_PRODUCT_ITUNERNET_USBLCD2X20 0x0002 /* USB-LCD 2x20 */ +#define USB_PRODUCT_ITUNERNET_USBLCD4X20 0xc001 /* USB-LCD 4x20 */ /* Jablotron products */ #define USB_PRODUCT_JABLOTRON_PC60B 0x0001 /* PC-60B */ Index: sys/dev/usb2/quirk/usb2_quirk.c =================================================================== --- sys/dev/usb2/quirk/usb2_quirk.c (revision 187457) +++ sys/dev/usb2/quirk/usb2_quirk.c (working copy) @@ -95,6 +95,7 @@ {USB_QUIRK_ENTRY(USB_VENDOR_CYBERPOWER, USB_PRODUCT_CYBERPOWER_1500CAVRLCD, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_DELORME, USB_PRODUCT_DELORME_EARTHMATE, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_ITUNERNET, USB_PRODUCT_ITUNERNET_USBLCD2X20, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, + {USB_QUIRK_ENTRY(USB_VENDOR_ITUNERNET, USB_PRODUCT_ITUNERNET_USBLCD4X20, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_MGE, USB_PRODUCT_MGE_UPS1, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_MGE, USB_PRODUCT_MGE_UPS2, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPHONE, 0x0000, 0xFFFF, UQ_HID_IGNORE, UQ_NONE)}, --Apple-Mail-10-713703121 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-10-713703121-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 07:05:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E3571065673 for ; Tue, 20 Jan 2009 07:05:43 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 536578FC19 for ; Tue, 20 Jan 2009 07:05:41 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 07:05:40 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp013) with SMTP; 20 Jan 2009 08:05:40 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+5eZRxc8W5VYuboHUeo4rI7SLdHu5FVareD7nj8v mWJYFZQ7UiDjoV Message-ID: <497577C3.4030602@gmx.de> Date: Tue, 20 Jan 2009 08:05:39 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: freebsd-current@freebsd.org Subject: Re: fdisk: Class not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 07:05:43 -0000 Alexander Best schrieb: > when i'm trying to do the following: > > fdisk -B adX > > i get the following error message: > > fdisk: Class not found > fdisk: Failed to write sector zero > > i'm running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r187392M: Sun > Jan 18 14:42:30 UTC 2009 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 > and rebuild and reinstalled fdisk. Does this also happen with fdisk of revision r187202? The changes after that should be harmless, but I want to play it safe. Just updating sbin/fdisk to this revision and rebuilding it is sufficient to test this. Christoph From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 08:54:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D213106568B for ; Tue, 20 Jan 2009 08:54:44 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id CAB978FC26 for ; Tue, 20 Jan 2009 08:54:43 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so1363771rvb.6 for ; Tue, 20 Jan 2009 00:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=YRp9pHlkgMIpgvi8SyRSy7Gl4xiuqQ4a/GpGegXLsdA=; b=nJKFT5n/pbHfVBT4c9aXGisGvF/mLQX8ZfAwnZts/1L+no8QYbYwfSFLnwN2kceW/V qvYSRrqXcvpoW3Zl2o2klrBMO6v6/5QkEh4YCmlLzjlMElT/8TnandfWmjfgiRvA3Ham MlqgeySjHYieFYl9X9XczyaALNAlMgNgl77KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bahTs/uvGMENUVMBFrR8cLOhYIYly2OG+HLpRc3CpFONGtOuQgGCojW9vwo66Q868a wungRPbXbMirwFmN7hdecb0EXtKvGuJA7epYVkD3kfDH9lWA2RRzwUK58mHvWlvywuGI xJPwjJNJ5hnMf9bYRL6o2x0J2zye/NKkWid/8= Received: by 10.141.44.13 with SMTP id w13mr3309014rvj.18.1232440139291; Tue, 20 Jan 2009 00:28:59 -0800 (PST) Received: by 10.141.32.3 with HTTP; Tue, 20 Jan 2009 00:28:59 -0800 (PST) Message-ID: <515c64960901200028v4cf36559ladb318383bff68e0@mail.gmail.com> Date: Tue, 20 Jan 2009 13:58:59 +0530 From: Channa To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: jemalloc on uniprocessor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 08:54:46 -0000 Hi All, I am testing the performance of jemalloc on uniprocessor( MIPS arch). I could see if the number of threads are more the time taken for execution for some threads takes extreme values. I have the results as below: ./malloc-test 16 1000 30 Thread 2136997200 adjusted timing for malloc is: 1245 micro seconds for 1000 requests of 16 bytes. Thread 2134900048 adjusted timing for malloc is: 1119 micro seconds for 1000 requests of 16 bytes. Thread 2132802896 adjusted timing for malloc is: 1134 micro seconds for 1000 requests of 16 bytes. Thread 2130705744 adjusted timing for malloc is: 1119 micro seconds for 1000 requests of 16 bytes. Thread 2128608592 adjusted timing for malloc is: 3704 micro seconds for 1000 requests of 16 bytes. Thread 2126511440 adjusted timing for malloc is: 6742 micro seconds for 1000 requests of 16 bytes. Thread 2122317136 adjusted timing for malloc is: 10601 micro seconds for 1000 requests of 16 bytes. Thread 2124414288 adjusted timing for malloc is: 18722 micro seconds for 1000 requests of 16 bytes. < == HERE Thread 2118122832 adjusted timing for malloc is: 22490 micro seconds for 1000 requests of 16 bytes. < == HERE Thread 2120219984 adjusted timing for malloc is: 26584 micro seconds for 1000 requests of 16 bytes. < == HERE Thread 2116025680 adjusted timing for malloc is: 30462 micro seconds for 1000 requests of 16 bytes. Thread 2109734224 adjusted timing for malloc is: 34568 micro seconds for 1000 requests of 16 bytes. Thread 2111831376 adjusted timing for malloc is: 38361 micro seconds for 1000 requests of 16 bytes. Thread 2113928528 adjusted timing for malloc is: 42392 micro seconds for 1000 requests of 16 bytes. Thread 2105539920 adjusted timing for malloc is: 46194 micro seconds for 1000 requests of 16 bytes. Thread 2107637072 adjusted timing for malloc is: 50230 micro seconds for 1000 requests of 16 bytes. Thread 2103442768 adjusted timing for malloc is: 54132 micro seconds for 1000 requests of 16 bytes. Thread 2101345616 adjusted timing for malloc is: 58065 micro seconds for 1000 requests of 16 bytes. Thread 2099248464 adjusted timing for malloc is: 1133 micro seconds for 1000 requests of 16 bytes. Thread 2097151312 adjusted timing for malloc is: 1168 micro seconds for 1000 requests of 16 bytes. Thread 2095054160 adjusted timing for malloc is: 1100 micro seconds for 1000 requests of 16 bytes. Thread 2092957008 adjusted timing for malloc is: 1176 micro seconds for 1000 requests of 16 bytes. Thread 2090859856 adjusted timing for malloc is: 1134 micro seconds for 1000 requests of 16 bytes. Thread 2088762704 adjusted timing for malloc is: 3194 micro seconds for 1000 requests of 16 bytes. Thread 2086665552 adjusted timing for malloc is: 6710 micro seconds for 1000 requests of 16 bytes. Thread 2084568400 adjusted timing for malloc is: 10770 micro seconds for 1000 requests of 16 bytes. Thread 2080374096 adjusted timing for malloc is: 14513 micro seconds for 1000 requests of 16 bytes. Thread 2082471248 adjusted timing for malloc is: 18580 micro seconds for 1000 requests of 16 bytes. Thread 2078276944 adjusted timing for malloc is: 22601 micro seconds for 1000 requests of 16 bytes. Thread 2076179792 adjusted timing for malloc is: 26405 micro seconds for 1000 requests of 16 bytes. As shown in the above results mentioned "HERE" the threads take more time. I have allocated 16 bytes for 1000 iteration for 30 threads. Could anyone helpme , why the above results are seen? Is is because of lock contention on uniprocessor since only one arena is used? Awaiting for your reply. Thanks & Regards, Channa From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 09:35:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB60106564A for ; Tue, 20 Jan 2009 09:35:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF6D8FC2E for ; Tue, 20 Jan 2009 09:35:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=1Vylc-1sXicA:10 a=c1mOR_-mYvwA:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=6I5d2MoRAAAA:8 a=JXCY6yMNjKbup46Pfq8A:9 a=jLxND2J32jdERcnkm64A:7 a=VkledWJT8NGMrJ_d9TWteUIlTSsA:4 a=mABBJHOAw2oA:10 a=u-1G2w-SAyoA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1185935962; Tue, 20 Jan 2009 10:35:25 +0100 From: Hans Petter Selasky To: Andre Guibert de Bruet Date: Tue, 20 Jan 2009 10:37:49 +0100 User-Agent: KMail/1.9.7 References: <24019.1232155811@critter.freebsd.dk> <129DC2F8-C5ED-4382-957A-29B5DBE2FCC9@siliconlandmark.com> In-Reply-To: <129DC2F8-C5ED-4382-957A-29B5DBE2FCC9@siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901201037.49841.hselasky@c2i.net> Cc: current@freebsd.org Subject: Re: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 09:35:28 -0000 On Tuesday 20 January 2009, Andre Guibert de Bruet wrote: > On Jan 16, 2009, at 8:30 PM, Poul-Henning Kamp wrote: > > In message > > > A42CF4263B9E@siliconlandmark.com>, Andre Guibert de Bruet writes: > >>>>> ...but... they *are* HID devices. Why is this "unfortunate"? > >>> > >>> It's unfortunate, because they are HID devices only because that > >>> is what microchip.com supplies as a USB programming example. > >>> > >>> The actual protocol they talk has nothing to do with the HID > >>> specification. > >> > >> PHK - I see that you committed the quirk for the 2X20. Would you mind > >> committing the patch attached to PR usb/128803? Do you want me to > >> produce the bits required for usb2 as well? > > > > USB2 patches should go to HPS@ still I think ? > > I have attached the 4x20 quirk patch for hpsusb. > Hi, Committed to P4. And my private SVN. Will go into -current early next week. http://perforce.freebsd.org/chv.cgi?CH=156420 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 09:42:54 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F052106566C for ; Tue, 20 Jan 2009 09:42:54 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate1.pacific.net.sg (smtpgate1.pacific.net.sg [192.169.41.31]) by mx1.freebsd.org (Postfix) with SMTP id 343808FC0A for ; Tue, 20 Jan 2009 09:42:52 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 24408 invoked from network); 20 Jan 2009 09:42:50 -0000 Received: from bb116-14-19-136.singnet.com.sg (HELO ?10.0.1.131?) (oceanare@116.14.19.136) by smtpgate1.pacific.net.sg with ESMTPA; 20 Jan 2009 09:42:50 -0000 From: Erich Dollansky To: Maxim Sobolev In-Reply-To: <49743B52.5040108@FreeBSD.org> References: <49742ADA.5080509@FreeBSD.org> <1232350919.2322.3.camel@P2120.somewherefaraway.com> <49743B52.5040108@FreeBSD.org> Content-Type: text/plain Date: Tue, 20 Jan 2009 17:42:53 +0800 Message-Id: <1232444573.2191.20.camel@P2120.somewherefaraway.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" Subject: Re: NTFS in GENERIC: opt-in or opt-out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 09:42:54 -0000 Hi, On Mon, 2009-01-19 at 00:35 -0800, Maxim Sobolev wrote: > Erich Dollansky wrote: > > Hi, > > > > On Sun, 2009-01-18 at 23:25 -0800, Maxim Sobolev wrote: > >> Hi, > >> > >> I am reviewing differences between amd64 and i386 GENERIC kernels and > >> noticed that for some unclear reason we ship amd64 GENERIC with NTFS > >> module compiled in, while i386 without it. IMHO both should match. The > >> question is whether NTFS should be i386 way (opt in) or amd64 way (opt > > > > the Windows file system? > > > > I would use opt-in as most people will not need it. > > Any particular reason why not? Memory is cheap, 100-200KB of extra > kernel code doesn't really matter today, while NTFS is probably the most it still matters. Not one driver this size alone, but if all drivers together are always in the system, it is at the end nothing else than a direct replacement for Windows: slow and full of stuff the user does not need. > widespread filesystem after MSDOS. Therefore supporting it in the > GENERIC out of the box even in the read-only mode (our NTFS driver is > read-only AFAIK) could benefit many users. Thumb Drives are mostly formatted with FAT-32. So NTFS in the kernel will not make a difference. Erich From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 10:43:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4971065674 for ; Tue, 20 Jan 2009 10:43:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DC3458FC26 for ; Tue, 20 Jan 2009 10:43:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 10:43:23 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp045) with SMTP; 20 Jan 2009 11:43:23 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/BTVFSZv3B5RolQBgSEM0aL+4AZtssPsvOFcqFtO 3ybwq0bQYtLKdT Message-ID: <4975AACA.3050906@gmx.de> Date: Tue, 20 Jan 2009 11:43:22 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: FreeBSD Current References: <496D94FD.9030300@gmx.de> In-Reply-To: <496D94FD.9030300@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.44 Cc: uwe@grohnwaldt.eu, FreeBSD Hackers , miwi@freebsd.org Subject: Re: Question about panic in brelse() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 10:43:27 -0000 Sadly I got no response about the panic problem so far. I investigated further and I came to the conclusion, that there are at least two problems/bugs in brelse(). Here are my findings. All lines refer to sys/kern/vfs_bio.c at r183754, which is the most recent version of this file. Below is the KASSERT(), which triggers in bundirty() (which is called by brelse()): KASSERT(bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE, ("bundirty: buffer %p still on queue %d", bp, bp->b_qindex)); So this assertion triggers, if neither B_REMFREE is set nor the buffer is in QUEUE_NONE. Now lets have a look at brelse() before the call to bundirty() happens. In line 1325 we find: if (bp->b_flags & B_REMFREE) bremfreel(bp); In bremfreel() B_REMFREE is cleared (line 684). So after this B_REMFREE is guaranteed to be clear and so the first part of the triggered KASSERT() will be false. Now for the second part, i.e. QUEUE_NONE: At line 1331 starts an if-cascade. No matter which case of this cascade is entered, b_qindex is set and it especially in no case it is set to QUEUE_NONE. so after this if-cascade it is guaranteed that b_qindex is *not* QUEUE_NONE. So when we arrive at line 1373ff at the problematic call to bundirty(), which contains the KASSERT(), it is guaranteed that neither B_REMFREE is set nor the buffer is in QUEUE_NONE and therefore the KASSERT() will be triggered. So we have a serious problem here: When the call is done, it *will* fail. This is one part of the problem. I have no solution, I don't know what would be correct here. Further, I looked at r93707 when this call to bundirty() was added. The situation was basically the same back then, i.e. the buffer could not be in QUEUE_NONE (the check for B_REMFREE did not exist back then, so the KASSERT() was more strict). So this change seems to wrong all along or at least dubious. The commit log of r93707 on the other hand claims that it solved a serious problem. If this was tested back then, it must have been done without INVARIANTS. It seems to be, that it was a hot fix - mind the MFC time of 1 day. Now for the second problem. As stated in the original mail, there is a buffer for which a write attempt failed: > b_iocmd = BIO_WRITE > b_ioflags = BIO_ERROR > b_error = EIO > b_flags = B_NOCACHE Because the error ist "just" an EIO, the buffer is re-dirtied and BIO_ERROR is cleared (line 1144ff). So writing the buffer should be tried again. But later in line 1342ff it is determined that the buffer contains junk, because B_NOCACHE is set so B_INVAL is also set. This leads to entering the path in line 1373, which then triggers the KASSERT(). On the other hand, the buffer does not contain junk, because it should be retried to be written! It only should be not kept around after the write was successful (or is considered to be failed permamently). So I think testing B_NOCACHE here alone is to weak and the condition has to be modified. I propose this change: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); This only enters the path to invalidate the buffer in case of B_NOCACHE being set, if B_DELWRI is *not* set. Can somebody reconstruct my analysis and confirm/reject it? Does my proposed solution for the second problem look sensible? Are the two problems related, i.e. can the first problem only occur because the second problem exists? What about the change in r93707 in general? Is it wrong? Does my proposal remove the cause for the change done in r93707 or are there other circumstances by which the situation can be triggered? Hopefully somebody can shed some more light on this. Christoph From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 11:01:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51BA7106564A for ; Tue, 20 Jan 2009 11:01:41 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 14D1B8FC12 for ; Tue, 20 Jan 2009 11:01:41 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n0KB00gd051317; Tue, 20 Jan 2009 11:00:02 GMT (envelope-from ken@mthelicon.com) Message-ID: <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> From: "Pegasus Mc Cleaft" To: "O. Hartmann" , "Anton Shterenlikht" References: <20090115084515.GA91157@freebsd.org><496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com><20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> In-Reply-To: <497064C6.5070807@zedat.fu-berlin.de> Date: Tue, 20 Jan 2009 11:00:01 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Antivirus: avast! (VPS 090119-0, 19/01/2009), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 11:01:41 -0000 Hello Current, If anyone is interested, I have put togeather a port for binutils-2.19 and have also created a PR ports/130715 to get it added to the ports tree. I would be greatfull for any peer review of the port as this is my first attempt at making one. The latest tarball can be found: http://www.mthelicon.com/~ken/binutils/ ~Peg From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 11:17:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D33B106564A for ; Tue, 20 Jan 2009 11:17:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 903AF8FC1E for ; Tue, 20 Jan 2009 11:17:17 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 17095 invoked by uid 60001); 20 Jan 2009 11:17:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=L6UfoFhlkQxtjW6M6Yt90ckaZngDkUOemWFKeQrGKfIMnXktZPX3V34NuCjCyca6O7eFjf3gve+D11BLu/5yHA3mulxu48gRfwBHb8jfS2Y9wEsKxJtnm90jw2XMXAd0FfcTMZu0QHdTgsmcl+r17XeuJm2h3k+E/fGY9V+Xirg=; X-YMail-OSG: oh.pMicVM1kp4Ekyqai6DLhXCcPG5gY8LV5o2l4z0msL8CCyHYrhftu7ltJzu1vLFmzHRo1ZmdGgNPSKdZsR9IkRgkBtZAmcT712cfiS38pYorMLEwykplxUSwfTVruq9ohCVtzIMlBrLqp9O8Ner0K9cCI- Received: from [98.242.222.229] by web63902.mail.re1.yahoo.com via HTTP; Tue, 20 Jan 2009 03:17:16 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 20 Jan 2009 03:17:16 -0800 (PST) From: Barney Cordoba To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <844890.15272.qm@web63902.mail.re1.yahoo.com> Subject: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 11:17:18 -0000 Can FreeBSD be configured to only run on N cores? So for example, if I have an 8 core system, can it be configured in loader.conf or through a simple hack to only run on 2 cores? We're testing various configs, and its not terribly convenient to keep swapping out CPUs. Thanks, Barney From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 11:25:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD82A1065670 for ; Tue, 20 Jan 2009 11:25:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1E6B18FC16 for ; Tue, 20 Jan 2009 11:25:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 11:25:14 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp005) with SMTP; 20 Jan 2009 12:25:14 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18P7xRUwfAPN6S11JEOPsQbahm3gMLKcq+xFLEy2Z K2JpqSOVhveD7j Message-ID: <4975B49A.5060205@gmx.de> Date: Tue, 20 Jan 2009 12:25:14 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: barney_cordoba@yahoo.com References: <844890.15272.qm@web63902.mail.re1.yahoo.com> In-Reply-To: <844890.15272.qm@web63902.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Cc: freebsd-current@freebsd.org Subject: Re: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 11:25:17 -0000 Barney Cordoba schrieb: > Can FreeBSD be configured to only run on N cores? So for example, if I have an 8 core system, can it be configured in loader.conf or through a simple hack to only run on 2 cores? > > We're testing various configs, and its not terribly convenient to keep swapping out CPUs. man 4 smp look for machdep.hlt_cpus From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 11:54:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72FE91065675 for ; Tue, 20 Jan 2009 11:54:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B5BFE8FC14 for ; Tue, 20 Jan 2009 11:54:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 11:54:14 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp044) with SMTP; 20 Jan 2009 12:54:14 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+utelR/Y6ujdgyu/bVfT2n6VYnVrr0K6MTdwFu20 0qyFq5MfdjBtUp Message-ID: <4975BB65.2020502@gmx.de> Date: Tue, 20 Jan 2009 12:54:13 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: FreeBSD Current References: <496D94FD.9030300@gmx.de> <4975AACA.3050906@gmx.de> In-Reply-To: <4975AACA.3050906@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: uwe@grohnwaldt.eu, FreeBSD Hackers , miwi@freebsd.org Subject: Re: Question about panic in brelse() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 11:54:16 -0000 Christoph Mallon schrieb: > @@ -1340,7 +1340,8 @@ > } > TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); > /* buffers with junk contents */ > - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || > + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || > + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) > (bp->b_ioflags & BIO_ERROR)) { > bp->b_flags |= B_INVAL; > bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); I just realised that somehow a || got lost. The diff should read: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) || (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 12:08:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9FC1065779 for ; Tue, 20 Jan 2009 12:08:33 +0000 (UTC) (envelope-from alexander@yamshanov.ru) Received: from jerry.cis.ru (jerry.cis.ru [212.109.192.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8AEA68FC17 for ; Tue, 20 Jan 2009 12:08:32 +0000 (UTC) (envelope-from alexander@yamshanov.ru) Received: from quadhost.cis.ru (quadhost.cis.ru [212.109.192.32]) by jerry.cis.ru (8.14.2/8.14.2) with ESMTP id n0KBUpQP057710 for ; Tue, 20 Jan 2009 17:30:51 +0600 (NOVT) (envelope-from alexander@yamshanov.ru) Received: (qmail 31735 invoked from network); 20 Jan 2009 17:30:51 +0600 Received: from pilot.cis.ru (HELO KuKaBooK) (212.109.193.53) by quadhost.54.ru with SMTP; 20 Jan 2009 17:30:51 +0600 Message-ID: <62A2D562603C4C2A9EB6FF1238BBED9E@KuKaBooK> From: "Alexander Yamshanov" To: Date: Tue, 20 Jan 2009 17:30:59 +0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problem with wifi on fujitsu U810. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 12:08:38 -0000 Hello, I have (sub)notebook - Fujitsu U810. It has problem with integrated = Atheros Super AG Wireless LAN (802.11a/b/g) - recognized as ath0. I already tried to use various variants: 7.2-RELEASE/7.1-STABLE/with = patch from Sam Leffler/with patch from madwifi-project. Without result. pciconf -l -v: [...] ath0@pci0:1:0:0: class=3D0x020000 card=3D0x139c10cf chip=3D0x001c168c = rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5006 family 802.11abg Wireless NIC' class =3D network subclass =3D ethernet [...] dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #3: Tue Jan 20 10:28:46 NOVT 2009 root@:/usr/obj/usr/src/sys/KUKABOOK Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) processor 800MHz (598.50-MHz = 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6d8 Stepping =3D 8 = Features=3D0xafe9fbff Features2=3D0x180 AMD Features=3D0x100000 real memory =3D 1063649280 (1014 MB) avail memory =3D 1031663616 (983 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: BIOS IRQ 11 for 0.2.INTA is invalid pci_link4: BIOS IRQ 11 for 0.29.INTB is invalid pci_link2: BIOS IRQ 11 for 0.29.INTC is invalid pci_link0: BIOS IRQ 11 for 0.29.INTD is invalid pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 ath0: irq 9 at device 0.0 on pci1 ath0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). ath0: cannot map register space device_attach: ath0 attach returned 6 [...] Is this device supported by ath driver? I would do any necessary tests = if somebody tells me how. Thank You, Alexander From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 12:14:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 281F91065670 for ; Tue, 20 Jan 2009 12:14:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id AD8D28FC12 for ; Tue, 20 Jan 2009 12:14:40 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 99327 invoked by uid 60001); 20 Jan 2009 12:14:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=QN6qQsoMbL5zg4+5ngErK/PmAQaMqxOZQGMsMMpMm/HDmieIwHwZwKhz3UJ77t1Qm6KNq23xpxhQKGJxTAyZ3ctsbsMTdDS50Rxx8rtm++PLAU1rtTq14El6Ylo/OG0kt1Zb/LMhWfEw0LkbSK2vYBGcSmnXu18vneYi2wZnr9c=; X-YMail-OSG: 6scyAEQVM1kd_V7EQShX5rw7pfekziTPuDumT9qYW_6OEIejegsLC.O4r9wGf51d0YKVXkgWdKtL23tLhf8GdeJxoQsF6gWlNOftZ9XkeHVylEpykJd04iX4B1nL_q7xCPbPLaHGtoV4zUnN54tEh31YXbpTgK5XhZ9d1ro9.KPntydXDNzv9Y6h Received: from [98.242.222.229] by web63904.mail.re1.yahoo.com via HTTP; Tue, 20 Jan 2009 04:14:39 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 20 Jan 2009 04:14:39 -0800 (PST) From: Barney Cordoba To: Christoph Mallon In-Reply-To: <4975B49A.5060205@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <693347.98930.qm@web63904.mail.re1.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 12:14:41 -0000 --- On Tue, 1/20/09, Christoph Mallon wrote: > From: Christoph Mallon > Subject: Re: Running on only some cores > To: barney_cordoba@yahoo.com > Cc: freebsd-current@freebsd.org > Date: Tuesday, January 20, 2009, 6:25 AM > Barney Cordoba schrieb: > > Can FreeBSD be configured to only run on N cores? So > for example, if I have an 8 core system, can it be > configured in loader.conf or through a simple hack to only > run on 2 cores? > > > > We're testing various configs, and its not > terribly convenient to keep swapping out CPUs. > > man 4 smp > look for machdep.hlt_cpus I've tried various settings for this but the system still launches all 4 cpus machdep.hlt_cpus="0x7" machdep.hlt_cpus="1" machedp.hlt_cpus="0xC" all result in 4 cpus being lauched. What is the trick? Barney From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 12:27:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163A6106564A for ; Tue, 20 Jan 2009 12:27:07 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id 96E5C8FC19 for ; Tue, 20 Jan 2009 12:27:06 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 11841 invoked by uid 60001); 20 Jan 2009 12:27:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=fEaCsSqtSZBdP/G1vokF6d7bRsDLwsXdjbzHFonMzld+PtZUVM4Q70ZrIIRmo8AyuAaXqi/XL/PFzAR4vAOibuwNwg07cFDFzvEFDXI4ChOPUEaPUe5L3ktNlmUgVnuSyhRjOPI4ubtxu8sAYkvTjw4DJyKgzyrxe6eiZwGLk4c=; X-YMail-OSG: AcpDndoVM1kcnQecgf.XdiayyDQ3TkSsl_irdmp6r.YxzCUuALQHmitVJ3AjBiLdqCWfmYZweVR1ztLaMNsg0w6GqXEe3JNJa9XaROTRPgQec3lLuTwHK3T8GV_noHI3iJFit.aJZEzFmansswLefjMq2.mDroMXYbLwu3dZ5_CuWYj8GjtWT29SkX51b00AtvEoZZiuojxp79faQAf5qe_dpQ-- Received: from [98.242.222.229] by web63907.mail.re1.yahoo.com via HTTP; Tue, 20 Jan 2009 04:27:05 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 20 Jan 2009 04:27:05 -0800 (PST) From: Barney Cordoba To: Christoph Mallon In-Reply-To: <4975B49A.5060205@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <10041.11443.qm@web63907.mail.re1.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 12:27:07 -0000 --- On Tue, 1/20/09, Christoph Mallon wrote: > From: Christoph Mallon > Subject: Re: Running on only some cores > To: barney_cordoba@yahoo.com > Cc: freebsd-current@freebsd.org > Date: Tuesday, January 20, 2009, 6:25 AM > Barney Cordoba schrieb: > > Can FreeBSD be configured to only run on N cores? So > for example, if I have an 8 core system, can it be > configured in loader.conf or through a simple hack to only > run on 2 cores? > > > > We're testing various configs, and its not > terribly convenient to keep swapping out CPUs. > > man 4 smp > look for machdep.hlt_cpus Ok, I see this does something when run after boot. So there is no way to get the OS to simply not launch the CPU? We have something that reads the number of cpus, which doesn't seem to change. Barney From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 12:55:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFF331065670 for ; Tue, 20 Jan 2009 12:55:13 +0000 (UTC) (envelope-from ganael.laplanche@martymac.com) Received: from data.galacsys.net (data.galacsys.net [217.24.81.1]) by mx1.freebsd.org (Postfix) with ESMTP id 847B08FC08 for ; Tue, 20 Jan 2009 12:55:13 +0000 (UTC) (envelope-from ganael.laplanche@martymac.com) Received: from martymac.com (webmail.galacsys.net [217.24.81.215]) by data.galacsys.net (Postfix) with ESMTP id C5A4216A4B7; Tue, 20 Jan 2009 13:36:29 +0100 (CET) From: "Ganael LAPLANCHE" To: "Alexander Yamshanov" , X-Openwebmail-Date: Tue, 20 Jan 2009 13:36:29 +0100 Message-Id: <20090120122850.M45828@martymac.com> In-Reply-To: <62A2D562603C4C2A9EB6FF1238BBED9E@KuKaBooK> References: <62A2D562603C4C2A9EB6FF1238BBED9E@KuKaBooK> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.com) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Tue, 20 Jan 2009 13:36:29 +0100 (CET) Cc: Subject: Re: problem with wifi on fujitsu U810. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 12:55:14 -0000 On Tue, 20 Jan 2009 17:30:59 +0600, Alexander Yamshanov wrote Hi, > I have (sub)notebook - Fujitsu U810. It has problem with integrated > Atheros Super AG Wireless LAN (802.11a/b/g) - recognized as ath0. I have exactly the same problem on my U1010. See : http://lists.freebsd.org/pipermail/freebsd-acpi/2007-December/004355.html > I already tried to use various variants: 7.2-RELEASE/7.1-STABLE/with > patch from Sam Leffler/with patch from madwifi-project. Without result. > [...] > Is this device supported by ath driver? I would do any necessary tests > if somebody tells me how. It seems that the device would be supported by the driver, but that there is a problem on the PCI-PCI bridge configuration which prevents the Atheros card to work properly. Unfortunately, I haven't found a way to fix that problem. Any suggestion is welcome :) Best regards, Ganaël LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 13:56:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16655106567B for ; Tue, 20 Jan 2009 13:56:13 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id DF43F8FC14 for ; Tue, 20 Jan 2009 13:56:12 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so3528180wfg.7 for ; Tue, 20 Jan 2009 05:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+nh+z+1gveW8nirSdnu1v3fXwaWW35pbc1ksDnulfWM=; b=m5LKRQ9IoYGPEncJblW69hkNXbdE2nuQkKRIP/QufEHj1AvY2a5dx/EdipabhkH6OY eaUiGtpcC6hOf0LIyOQX8ETerjSjJ6DFUy5riwi35svZCWdM5hjx/PwN//d2u61lmzNi AuUwLGGlC6aoVV4s4O4WNOFiReG/rBXj2ZTjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mPlZ5+fxLQeQuWN3N/vCybDsNrwvzF8aN0V2XimJ5AelPqR99qYf+JpguSgr95FTsg nO8+XNvUd668Dq+aPa/CSReVifGsa8bgm+fhSiL/tmaZYL7hwyU6xJx7rZNGm2Pa8nIy r4JytitDbI414kNsjITFf5vSbW5ezLBXO/Fwk= MIME-Version: 1.0 Received: by 10.142.57.19 with SMTP id f19mr2873579wfa.80.1232457807699; Tue, 20 Jan 2009 05:23:27 -0800 (PST) In-Reply-To: <10041.11443.qm@web63907.mail.re1.yahoo.com> References: <4975B49A.5060205@gmx.de> <10041.11443.qm@web63907.mail.re1.yahoo.com> Date: Tue, 20 Jan 2009 07:23:27 -0600 Message-ID: <2fd864e0901200523q5559f301qa0475983d6e6deb1@mail.gmail.com> From: Astrodog To: barney_cordoba@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , freebsd-current@freebsd.org Subject: Re: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 13:56:13 -0000 You can set MAXCPU in the kernel config, if nothing else... On Tue, Jan 20, 2009 at 6:27 AM, Barney Cordoba wrote: > > > > --- On Tue, 1/20/09, Christoph Mallon wrote: > >> From: Christoph Mallon >> Subject: Re: Running on only some cores >> To: barney_cordoba@yahoo.com >> Cc: freebsd-current@freebsd.org >> Date: Tuesday, January 20, 2009, 6:25 AM >> Barney Cordoba schrieb: >> > Can FreeBSD be configured to only run on N cores? So >> for example, if I have an 8 core system, can it be >> configured in loader.conf or through a simple hack to only >> run on 2 cores? >> > >> > We're testing various configs, and its not >> terribly convenient to keep swapping out CPUs. >> >> man 4 smp >> look for machdep.hlt_cpus > > Ok, I see this does something when run after boot. So there is no way to get the OS to simply not launch the CPU? We have something that reads the number of cpus, which doesn't seem to change. > > Barney > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." --- Robert A. Heinlein From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 15:05:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC910106566C for ; Tue, 20 Jan 2009 15:05:22 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id EB2598FC13 for ; Tue, 20 Jan 2009 15:05:21 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by bwz3 with SMTP id 3so397067bwz.19 for ; Tue, 20 Jan 2009 07:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bJuyrVG9hClSD2i8UGdOrckmIrAMVSCHw6c/p8WjhsA=; b=Q5UBLl7Ta+tsd96hWCrSXa7rQg/g1oZb5PFSRQSM3jvqIGXulc6ENB/Fb7NnPK5/Bj ZG+O2yra53NaVgBFtMiU2aoHZSKL/+HtEEx4Dgz3CJmIxTlZvlt8HIp/qwGQHUvM0nuJ AxD8MpFTnLwb87Vw+LkydES0KMQbo7ZLP56aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=cvYRw5rxPCFBdPVnvDCSHjZd895SEaZ5Bxghtw8MQ5RGh6XZumKSIpErZmvxD02HzJ y3raGBJ7dhbXQB6NbAG0NlYB4139cDasqWrMZjeyKzyb83A4NkMrtxDqSqI7pUKaXnKi PRlol6IBoHUe5ZJaR1FLIBaudMrfFHYwu8S68= MIME-Version: 1.0 Received: by 10.103.198.15 with SMTP id a15mr3074422muq.60.1232462466886; Tue, 20 Jan 2009 06:41:06 -0800 (PST) In-Reply-To: <1da1bb16c32753bce066b3ba33c02573.squirrel@cygnus.homeunix.com> References: <20090115233553.GA24679@datura.dylex.net> <1da1bb16c32753bce066b3ba33c02573.squirrel@cygnus.homeunix.com> Date: Tue, 20 Jan 2009 09:41:06 -0500 Message-ID: <8cb6106e0901200641x4b0bda9ag31e6f059f13035a7@mail.gmail.com> From: Josh Carroll To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: SATA DMA errors on second ICH10 bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 15:05:22 -0000 On Sun, Jan 18, 2009 at 8:29 PM, Nenhum_de_Nos wrote: > may be related to this, I found on vr-zone.com: > http://www.theinquirer.net/inquirer/news/374/1050374/seagate-barracudas-7200-11-failing Quite possible. I have two ST31000340AS drives with the bad SD15 firmware and it threw a bunch of DMA errors last night, and smart shows: Error 2 occurred at disk power-on lifetime: 366 hours (15 days + 6 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 42 53 d7 0d Error: UNC at LBA = 0x0dd75342 = 232215362 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 ff 52 d7 4d 00 5d+06:34:09.759 READ DMA 35 00 00 ff ff ff 4f 00 5d+06:34:09.741 WRITE DMA EXT c8 00 00 ff 51 d7 4d 00 5d+06:34:09.687 READ DMA 35 00 00 ff ff ff 4f 00 5d+06:34:09.633 WRITE DMA EXT c8 00 00 ff 50 d7 4d 00 5d+06:34:09.605 READ DMA Error 1 occurred at disk power-on lifetime: 231 hours (9 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 00 ff ff ff 4f 00 8d+19:11:08.269 READ DMA EXT 25 00 00 ff ff ff 4f 00 8d+19:11:08.267 READ DMA EXT 25 00 00 ff ff ff 4f 00 8d+19:11:08.261 READ DMA EXT 25 00 00 ff ff ff 4f 00 8d+19:11:08.260 READ DMA EXT 25 00 00 ff ff ff 4f 00 8d+19:11:08.257 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 368 232215362 # 2 Short offline Completed: read failure 90% 368 232215362 # 3 Short offline Completed: read failure 90% 367 232215362 # 4 Short offline Completed without error 00% 224 - I've got 2 WD black drives on order to replace these two ST31000340AS, and originally my intention was to use them for separate filesystems, but I think I'll gmirror them now, to be safe(er). Josh From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 15:56:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0622A1065680 for ; Tue, 20 Jan 2009 15:56:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D38398FC1A for ; Tue, 20 Jan 2009 15:56:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7612B46B2E; Tue, 20 Jan 2009 10:56:38 -0500 (EST) Date: Tue, 20 Jan 2009 15:56:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <844890.15272.qm@web63902.mail.re1.yahoo.com> Message-ID: References: <844890.15272.qm@web63902.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Running on only some cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 15:56:39 -0000 On Tue, 20 Jan 2009, Barney Cordoba wrote: > Can FreeBSD be configured to only run on N cores? So for example, if I have > an 8 core system, can it be configured in loader.conf or through a simple > hack to only run on 2 cores? > > We're testing various configs, and its not terribly convenient to keep > swapping out CPUs. You can use device.hints to disable specific CPUs using: hint.lapic.X.disabled=1 This prevents FreeBSD from probing the CPU. If I had to guess, disabling the BSP would be a bad idea, but for the APs it should work fine. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 16:45:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A614F1065698 for ; Tue, 20 Jan 2009 16:45:08 +0000 (UTC) (envelope-from dylan@dylex.net) Received: from datura.dylex.net (datura.dylex.net [216.27.141.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5B08FC12 for ; Tue, 20 Jan 2009 16:45:08 +0000 (UTC) (envelope-from dylan@dylex.net) Received: from dylan by datura.dylex.net with local (Exim 4.69) (envelope-from ) id 1LPJio-0007OX-W5; Tue, 20 Jan 2009 11:45:02 -0500 Date: Tue, 20 Jan 2009 11:45:02 -0500 From: Dylan Alex Simon To: Josh Carroll Message-ID: <20090120164502.GA28393@datura.dylex.net> References: <20090115233553.GA24679@datura.dylex.net> <1da1bb16c32753bce066b3ba33c02573.squirrel@cygnus.homeunix.com> <8cb6106e0901200641x4b0bda9ag31e6f059f13035a7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0901200641x4b0bda9ag31e6f059f13035a7@mail.gmail.com> Jabber-ID: dylan@dylex.net Cc: freebsd-current@freebsd.org, Nenhum_de_Nos Subject: Re: SATA DMA errors on second ICH10 bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 16:45:09 -0000 >From Josh Carroll , Tue, Jan 20, 2009 at 09:41:06AM -0500: > On Sun, Jan 18, 2009 at 8:29 PM, Nenhum_de_Nos wrote: > > may be related to this, I found on vr-zone.com: > > http://www.theinquirer.net/inquirer/news/374/1050374/seagate-barracudas-7200-11-failing > > Quite possible. I have two ST31000340AS drives with the bad SD15 > firmware and it threw a bunch of DMA errors last night, and smart > shows: In this case I don't think that's the cause. They do have the bad firmware (which I'll update and test again as soon as Seagate provides a working fix), but SMART reports no errors on any disk, and all self-tests past. Linux has been running on this machine for a while now under similar conditions with no errors at all. Also, there's a similar report with WD disks in ICH7. (I've opened kern/130726 for this.) :-Dylan From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 16:04:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8968E106564A; Tue, 20 Jan 2009 16:04:37 +0000 (UTC) (envelope-from lesly.bien-aime@ver-mac.com) Received: from tomts46-srv.bellnexxia.net (ftp1.sympatico.ca [209.226.175.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2668F8FC08; Tue, 20 Jan 2009 16:04:36 +0000 (UTC) (envelope-from lesly.bien-aime@ver-mac.com) Received: from toip53-bus.srvr.bell.ca ([67.69.240.54]) by tomts27-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090120151016.OHXI1689.tomts27-srv.bellnexxia.net@toip53-bus.srvr.bell.ca>; Tue, 20 Jan 2009 10:10:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMOAEFydUlKD9SG/2dsb2JhbACBZogxgz69B4Vz Received: from bas2-quebec09-1242551430.dsl.bell.ca (HELO Baya) ([74.15.212.134]) by toip53-bus.srvr.bell.ca with ESMTP; 20 Jan 2009 10:09:59 -0500 Message-ID: <680234114D7A4F94A81D44EDBB1C969B@Baya> From: =?iso-8859-1?Q?Lesly_Bien-Aim=E9?= To: "Roman Divacky" , "Michel Talon" References: <20090113044111.134EC1CC0B@ptavv.es.net><20090113222023.GA51810@lor.one-eyed-alien.net><496D1ED6.4090202@FreeBSD.org><200901132356.40820.ken@mthelicon.com><496D64A0.1090309@FreeBSD.org><20090114091342.GA19986@lpthe.jussieu.fr><5d6848b00901140821s61599c9vb3f91f75142d0481@mail.gmail.com><20090114172033.GA29254@lpthe.jussieu.fr> <20090114175228.GA54368@freebsd.org> Date: Tue, 20 Jan 2009 10:10:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Tue, 20 Jan 2009 17:17:21 +0000 Cc: Kevin Wilcox , freebsd-current@FreeBSD.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it becomestandard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 16:04:37 -0000 www.OpenWatcom.com "Work in progress includes Linux and FreeBSD ports" Just pointing out one more compiler. // Yocto From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 17:51:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464781065677 for ; Tue, 20 Jan 2009 17:51:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id CDEA48FC1E for ; Tue, 20 Jan 2009 17:51:25 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.37,295,1231110000"; d="scan'208";a="267481524" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 20 Jan 2009 18:51:24 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id C5DA01B0761; Tue, 20 Jan 2009 18:51:23 +0100 (CET) Date: Tue, 20 Jan 2009 18:51:23 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Christoph Mallon Message-ID: In-Reply-To: <497577C3.4030602@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: fdisk: Class not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 17:51:26 -0000 nope. i'm getting the same error message using r187202. alex Christoph Mallon schrieb am 2009-01-20: > Alexander Best schrieb: > >when i'm trying to do the following: > >fdisk -B adX > >i get the following error message: > >fdisk: Class not found > >fdisk: Failed to write sector zero > >i'm running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #0 > >r187392M: Sun > >Jan 18 14:42:30 UTC 2009 > >root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 > >and rebuild and reinstalled fdisk. > Does this also happen with fdisk of revision r187202? The changes > after that should be harmless, but I want to play it safe. Just > updating sbin/fdisk to this revision and rebuilding it is sufficient > to test this. > Christoph From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 17:56:29 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BE61065673 for ; Tue, 20 Jan 2009 17:56:29 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1E58FC1C for ; Tue, 20 Jan 2009 17:56:29 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 73D2F9CB072; Tue, 20 Jan 2009 18:56:02 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p08Sn9l+z2pM; Tue, 20 Jan 2009 18:56:00 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1909B9CB094; Tue, 20 Jan 2009 18:56:00 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.3/Submit) id n0KHtxVV043609; Tue, 20 Jan 2009 18:55:59 +0100 (CET) (envelope-from rdivacky) Date: Tue, 20 Jan 2009 18:55:59 +0100 From: Roman Divacky To: Lesly Bien-Aim? Message-ID: <20090120175558.GA43333@freebsd.org> References: <20090114175228.GA54368@freebsd.org> <680234114D7A4F94A81D44EDBB1C969B@Baya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <680234114D7A4F94A81D44EDBB1C969B@Baya> User-Agent: Mutt/1.4.2.3i Cc: Kevin Wilcox , freebsd-current@FreeBSD.org, Michel Talon Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it becomestandard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 17:56:30 -0000 On Tue, Jan 20, 2009 at 10:10:04AM -0500, Lesly Bien-Aim? wrote: > www.OpenWatcom.com > > "Work in progress includes Linux and FreeBSD ports" > > Just pointing out one more compiler. this has been the case for quite some years now... it looks like a dead project... :( From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 18:29:16 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFEB3106564A for ; Tue, 20 Jan 2009 18:29:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 507758FC13 for ; Tue, 20 Jan 2009 18:29:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0KITE4U072324; Tue, 20 Jan 2009 19:29:14 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0KITE8V072323; Tue, 20 Jan 2009 19:29:14 +0100 (CET) (envelope-from olli) Date: Tue, 20 Jan 2009 19:29:14 +0100 (CET) Message-Id: <200901201829.n0KITE8V072323@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, josh.carroll@gmail.com In-Reply-To: <8cb6106e0901200641x4b0bda9ag31e6f059f13035a7@mail.gmail.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 20 Jan 2009 19:29:14 +0100 (CET) Cc: Subject: Re: SATA DMA errors on second ICH10 bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 18:29:17 -0000 Josh Carroll wrote: > I've got 2 WD black drives on order to replace these two ST31000340AS, > and originally my intention was to use them for separate filesystems, > but I think I'll gmirror them now, to be safe(er). Some people recommend to use different vendors for the components of disk mirrors, in order to reduce the likelihood that both drives will fail at about the same time due to a firmware bug or similar. That advice seems to be particularly valuable given the current firmware problems that particular Seagate disks are exhibiting. For example, I've got these in a server: # atacontrol list | grep ad Master: ad0 Serial ATA II Master: ad1 Serial ATA v1.0 # diskinfo ad0 ad1 ad0 512 160041885696 312581808 310101 16 63 ad1 512 160041885696 312581808 310101 16 63 # gmirror status Name Status Components mirror/gm0 COMPLETE ad0 ad1 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 18:34:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54413106564A for ; Tue, 20 Jan 2009 18:34:39 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 11FDF8FC1D for ; Tue, 20 Jan 2009 18:34:39 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 268CC6D43F; Tue, 20 Jan 2009 18:34:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 052CA844C4; Tue, 20 Jan 2009 19:34:38 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: barney_cordoba@yahoo.com References: <417204.17745.qm@web63906.mail.re1.yahoo.com> Date: Tue, 20 Jan 2009 19:34:37 +0100 In-Reply-To: <417204.17745.qm@web63906.mail.re1.yahoo.com> (Barney Cordoba's message of "Sun, 18 Jan 2009 12:30:37 -0800 (PST)") Message-ID: <864oztrflu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Christof Schulze Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 18:34:40 -0000 Barney Cordoba writes: > Is there any interest in fixing this stupid and wrong error message to > be something like "unresolved externals" at some point? When the kernel fails to load a module, kldload(2) returns ENOEXEC, which strerror(3) translates to "exec format error". If you can think of a better errno value to use, feel free to send patches. The only alternatives I can think of are ENOSYS (ambiguous) and EFTYPE (just as vague as ENOEXEC). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 18:54:51 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D11E21065670; Tue, 20 Jan 2009 18:54:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0468FC1A; Tue, 20 Jan 2009 18:54:51 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7B06F6D43F; Tue, 20 Jan 2009 18:54:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 57A9F844C4; Tue, 20 Jan 2009 19:54:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Roman Divacky References: <20090114175228.GA54368@freebsd.org> <680234114D7A4F94A81D44EDBB1C969B@Baya> <20090120175558.GA43333@freebsd.org> Date: Tue, 20 Jan 2009 19:54:50 +0100 In-Reply-To: <20090120175558.GA43333@freebsd.org> (Roman Divacky's message of "Tue, 20 Jan 2009 18:55:59 +0100") Message-ID: <86zlhlq03p.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Lesly =?utf-8?Q?Bien-Aim=C3=A9?= , Talon , Wilcox , freebsd-current@FreeBSD.org, Kevin, Michel Subject: Re: Alternatives to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 18:54:52 -0000 Roman Divacky writes: > Lesly Bien-Aim=C3=A9 writes: > > www.OpenWatcom.com > >=20 > > "Work in progress includes Linux and FreeBSD ports" > this has been the case for quite some years now... it looks like a dead > project... :( They released 1.8 RC2 just two weeks ago - still no FreeBSD support, though. What about TenDRA and Ten15? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 21:08:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF4B61065670 for ; Tue, 20 Jan 2009 21:08:06 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0BC0B8FC1E for ; Tue, 20 Jan 2009 21:08:05 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl189-242.kln.forthnet.gr [79.103.2.242]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n0KL7shA012767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jan 2009 23:07:59 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0KL7swO099079; Tue, 20 Jan 2009 23:07:54 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0KL7stf099078; Tue, 20 Jan 2009 23:07:54 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Tim Kientzle References: <87skndg0cv.fsf@kobe.laptop> Date: Tue, 20 Jan 2009 23:07:54 +0200 In-Reply-To: <87skndg0cv.fsf@kobe.laptop> (Giorgos Keramidas's message of "Tue, 20 Jan 2009 22:59:28 +0200") Message-ID: <87ocy1fzyt.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n0KL7shA012767 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.954, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.45, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 21:08:08 -0000 On Tue, 20 Jan 2009 22:59:28 +0200, Giorgos Keramidas wrote: > The cosmetic changes can probably go in a separate commit, but we should > probably fix & backport the core dump when archive_write_header() fails. Ok, this part was quite easy. I split the cosmetic changes and the core dump fix at: - cosmetic warn message tweak: http://people.freebsd.org/~keramida/diff/bsdcpio-2009.01.10-7752.c9e6e3ea5e24.diff - core dump fix: http://people.freebsd.org/~keramida/diff/bsdcpio-2009.01.10-7753.cb8c324bbcd1.diff From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 21:16:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3397106564A; Tue, 20 Jan 2009 21:16:37 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 089D38FC13; Tue, 20 Jan 2009 21:16:36 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (adsl189-242.kln.forthnet.gr [79.103.2.242]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n0KKxUom011264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jan 2009 22:59:36 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0KKxTjR098892; Tue, 20 Jan 2009 22:59:29 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0KKxTkK098891; Tue, 20 Jan 2009 22:59:29 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Tim Kientzle Date: Tue, 20 Jan 2009 22:59:28 +0200 Message-ID: <87skndg0cv.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n0KKxUom011264 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.149, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.25, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 21:16:38 -0000 Hi Tim & -CURRENT, I think I stumbled upon a minor bsdcpio bug. When bsdcpio tries to write to a directory it doesn't have permissions it core dumps: # mkdir /tmp/koko # chmod 0700 /tmp/koko % cd /ws/keramida/src/usr.in/cpio % env DEBUG_FLAGS='-ggdb' CFLAGS='' make bsdcpio ... % echo bsdcpio | ./bsdcpio -p -dmvu bsdcpio: /tmp/koko/bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied: Permission denied INTERNAL ERROR: Function 'archive_write_data' invoked with archive structure in state 'header', should be in state 'data' Segmentation fault: 11 (core dumped) % gdb bsdcpio bsdcpio.core #0 0x280b9ad7 in diediedie () at archive_check_magic.c:55 55 *(char *)0 = 1; /* Deliberately segfault and force a coredump. */ (gdb) bt #0 0x280b9ad7 in diediedie () at archive_check_magic.c:55 #1 0x280b9caf in __archive_check_magic (a=0x28202140, magic=3221336261, state=4, function=0x280bc960 "archive_write_data") at archive_check_magic.c:116 #2 0x2809f95d in _archive_write_data (_a=0x28202140, buff=0x804f360, size=16384) at archive_write_disk.c:625 #3 0x280a2e35 in archive_write_data (a=0x28202140, buff=0x804f360, s=16384) at archive_virtual.c:74 #4 0x0804b534 in entry_to_archive (cpio=0xbfbfe6ec, entry=0x282231c0) at cpio.c:637 #5 0x0804b219 in file_to_archive (cpio=0xbfbfe6ec, srcpath=0x2821e000 "bsdcpio") at cpio.c:542 #6 0x0804c1d1 in mode_pass (cpio=0xbfbfe6ec, destdir=0xbfbfe94e "/tmp/koko") at cpio.c:939 #7 0x0804a899 in main (argc=4, argv=0xbfbfe7c8) at cpio.c:291 (gdb) It seems that cpio tries in entry_to_archive() to handle errors in calls of archive_write_header() but it should be a bit more strict about it. I picked up ARCHIVE_RETRY as the smallest error code we 'accept' when archive_write_header() fails, but the choice seems pretty arbitrary. The patch does solve the core dump I was seeing though. Does it look good enough for cpio? Should we handle archive_write_header() errors differently? %%% diff -r cb9a95f8dfb3 usr.bin/cpio/cpio.c --- a/usr.bin/cpio/cpio.c Tue Jan 20 21:45:52 2009 +0200 +++ b/usr.bin/cpio/cpio.c Tue Jan 20 22:56:48 2009 +0200 @@ -623,12 +623,12 @@ r = archive_write_header(cpio->archive, entry); if (r != ARCHIVE_OK) - cpio_warnc(archive_errno(cpio->archive), + cpio_warnc(0, "%s: %s", - destpath, + srcpath, archive_error_string(cpio->archive)); - if (r == ARCHIVE_FATAL) + if (r < ARCHIVE_RETRY) exit(1); if (r >= ARCHIVE_WARN && fd >= 0) { %%% While here, I also changed destpath to srcpath in the warning and changed the 'code' argument of cpio_warnc() to zero, to avoid a duplicate strerror() like output. The message returned by archive_error_string() contains the destination path and strerror() text already, so this changes the error from: bsdcpio: /tmp/koko/bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied: Permission denied to: bsdcpio: ./bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied The cosmetic changes can probably go in a separate commit, but we should probably fix & backport the core dump when archive_write_header() fails. From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 21:19:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 011221065695 for ; Tue, 20 Jan 2009 21:19:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CBECA8FC0A for ; Tue, 20 Jan 2009 21:19:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 723D146B37; Tue, 20 Jan 2009 16:19:03 -0500 (EST) Date: Tue, 20 Jan 2009 21:19:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <864oztrflu.fsf@ds4.des.no> Message-ID: References: <417204.17745.qm@web63906.mail.re1.yahoo.com> <864oztrflu.fsf@ds4.des.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-598408371-1232486343=:16213" Cc: barney_cordoba@yahoo.com, freebsd-current@freebsd.org, Christof Schulze Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 21:19:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-598408371-1232486343=:16213 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 20 Jan 2009, Dag-Erling Smørgrav wrote: > Barney Cordoba writes: >> Is there any interest in fixing this stupid and wrong error message to be >> something like "unresolved externals" at some point? > > When the kernel fails to load a module, kldload(2) returns ENOEXEC, which > strerror(3) translates to "exec format error". If you can think of a better > errno value to use, feel free to send patches. The only alternatives I can > think of are ENOSYS (ambiguous) and EFTYPE (just as vague as ENOEXEC). A number of other UNIXy OS's have extended the errno space to support user linker errors in a bit more detail, it could be that we could reuse/abuse a few of them: ELIBACC Solaris/Linux Can't access needed shared lib ELIBBAD Solaris/Linux Accessing a corrupted shared lib ELIBSCN Solaris/Linux .lib section in a.out corrupted ELIBMAX Solaris/Linux Attempting to link in too many libs ELIBEXEC Solaris/Linux Attempting to exec a shared library EBADEXEC Mac OS X Bad excutable EBADARCH Mac OS X Bad CPU type in executable ESHLIBVERS Mac OS X Shared library version mismatch Or, we could add a couple of new errno values. This has come up a number of times and people do find it confusing that the errors returned aren't very related to the error. Another alternative would be to add a new kldload() system call that explicitly returns a more detailed error number space independent of the errno space. Robert --621616949-598408371-1232486343=:16213-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 21:28:33 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337BC106566C for ; Tue, 20 Jan 2009 21:28:33 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 76A5A8FC08 for ; Tue, 20 Jan 2009 21:28:32 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 21:28:31 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp017) with SMTP; 20 Jan 2009 22:28:31 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+bufkaKhWbKe7VeqcBfJwrrRNZAOsWu/UDY6NRdm XScvpCXtqN9RBL Message-ID: <497641FC.30209@gmx.de> Date: Tue, 20 Jan 2009 22:28:28 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Giorgos Keramidas References: <87skndg0cv.fsf@kobe.laptop> In-Reply-To: <87skndg0cv.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: freebsd-current@FreeBSD.org, Tim Kientzle Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 21:28:33 -0000 Giorgos Keramidas schrieb: > diff -r cb9a95f8dfb3 usr.bin/cpio/cpio.c > --- a/usr.bin/cpio/cpio.c Tue Jan 20 21:45:52 2009 +0200 > +++ b/usr.bin/cpio/cpio.c Tue Jan 20 22:56:48 2009 +0200 > @@ -623,12 +623,12 @@ > r = archive_write_header(cpio->archive, entry); > > if (r != ARCHIVE_OK) > - cpio_warnc(archive_errno(cpio->archive), > + cpio_warnc(0, > "%s: %s", > - destpath, > + srcpath, > archive_error_string(cpio->archive)); > Wouldn't it be better to remove the manually appended error string, i.e. ": %s" ... archive_error_string(), instead of circumventing the generic error reporting magic provided by cpio_warnc()? From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 22:04:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B3710657B1; Tue, 20 Jan 2009 22:04:12 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A33338FC16; Tue, 20 Jan 2009 22:04:11 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl189-242.kln.forthnet.gr [79.103.2.242]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n0KM41S4016515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jan 2009 00:04:08 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0KM41Bg099588; Wed, 21 Jan 2009 00:04:01 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0KM4001099587; Wed, 21 Jan 2009 00:04:00 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Christoph Mallon References: <87skndg0cv.fsf@kobe.laptop> <497641FC.30209@gmx.de> Date: Wed, 21 Jan 2009 00:04:00 +0200 In-Reply-To: <497641FC.30209@gmx.de> (Christoph Mallon's message of "Tue, 20 Jan 2009 22:28:28 +0100") Message-ID: <87d4eh8wj3.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n0KM41S4016515 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.156, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.24, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Tim Kientzle , freebsd-current@freebsd.org Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 22:04:17 -0000 On Tue, 20 Jan 2009 22:28:28 +0100, Christoph Mallon wrote: > Giorgos Keramidas schrieb: >> diff -r cb9a95f8dfb3 usr.bin/cpio/cpio.c >> --- a/usr.bin/cpio/cpio.c Tue Jan 20 21:45:52 2009 +0200 >> +++ b/usr.bin/cpio/cpio.c Tue Jan 20 22:56:48 2009 +0200 >> @@ -623,12 +623,12 @@ >> r = archive_write_header(cpio->archive, entry); >> if (r != ARCHIVE_OK) >> - cpio_warnc(archive_errno(cpio->archive), >> + cpio_warnc(0, >> "%s: %s", >> - destpath, >> + srcpath, >> archive_error_string(cpio->archive)); > > Wouldn't it be better to remove the manually appended error string, > i.e. ": %s" ... archive_error_string(), instead of circumventing the > generic error reporting magic provided by cpio_warnc()? That's probably better. It's why I split the patch in two parts, so Tim can review them separately and pick whatever is nicer :) It might be better to use: cpio_warnc(archive_errno(cpio->archive), "%s", srcpath); From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 22:44:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9D62106564A for ; Tue, 20 Jan 2009 22:44:45 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 919FD8FC08 for ; Tue, 20 Jan 2009 22:44:45 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 43E3933C62; Tue, 20 Jan 2009 14:44:45 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id AD4C233C5B; Tue, 20 Jan 2009 14:44:44 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18806.21468.277333.243611@almost.alerce.com> Date: Tue, 20 Jan 2009 14:44:44 -0800 To: Jaakko Heinonen In-Reply-To: <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> <18791.65426.128568.526167@almost.alerce.com> <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> X-Mailer: VM 7.19 under Emacs 22.1.50.1 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 20 Jan 2009 23:01:42 +0000 Cc: Michael Proto , Alexander Best , freebsd-current@freebsd.org, George Hartzell Subject: Re: patch to fix burncd bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 22:44:45 -0000 Jaakko Heinonen writes: > > Hi, > > On 2009-01-09, George Hartzell wrote: > > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > > updated it) on which burncd seems to successfully burn the data but > > then fails while fixating. > > > > I applied the above patch by hand, with a little bit of fuzz, and now > > it fails to burn the data but fixating no longer bombs out. > > It can't see how it could be possible that the patch (correctly applied) > causes this. Are you sure that this is repeatable behavior and burning > always works with an unpatched kernel? Does dmesg show any error > messages after failed burn? Hmmmm. I upgraded the machine to 7.1-STABLE and now the patch applies cleanly (using 'patch'). I still get the behaviour that I described above. So I backed out the patch, rebuilt, and it turns out that I see the same behaviour on the stock kernel. "It didn't use to do that. (tm)" There's a line in dmesg that says: acd0: TIMEOUT - WRITE_BIG retrying (1 retry left) I have a feeling I've seen a thread about cd drives and BIG, but I can't find it online or in the PR's. I see some recent discussion or READ_BIG, but no conclusion. This is with the stock DVD drive in a Mac PRO, dmesg reports it to be acd0: DVDR at ata2-master UDMA66 g. From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 04:28:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50EC6106566B for ; Wed, 21 Jan 2009 04:28:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by mx1.freebsd.org (Postfix) with ESMTP id AEBD48FC08 for ; Wed, 21 Jan 2009 04:28:03 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz6 with SMTP id 6so125239bwz.19 for ; Tue, 20 Jan 2009 20:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1yLc1GHmtbcG7yvLmSB7oGFl29SQsaU6EohyBMQ1J7s=; b=IkkpjZMBj8FLam8kL05X0LNlWYTQqj4YXv5msYmygzeJQ6n24uNmInDf1Q9poHyGAS VSa2nccl6mC075uORAjeOmL/Sm9lkAClGqWTz2zmdiGVLukd+4zNFD3WB8b3fbtiBQTq 6dpUCfh+T89dhr3cU4pb92O7nAenPs78vydBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g2O32s3GFF1eh7/h0+LxhQ6Kkx79+RPhjSIG2Xae5M+p9LExFEqln4sHC084zGxjaK 04kHZsnOhCC9nHXZJdCI9yaKXzTp4SIhj2LxNmTdhdwrM172ZfJQZbVDi1Vu7gcQIEoZ kXW2LWO5o6B3IJFcN4fvclu3hixwcIydh0COc= MIME-Version: 1.0 Received: by 10.181.158.3 with SMTP id k3mr2736671bko.182.1232512081134; Tue, 20 Jan 2009 20:28:01 -0800 (PST) In-Reply-To: <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> References: <20090115084515.GA91157@freebsd.org> <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> Date: Tue, 20 Jan 2009 20:28:01 -0800 Message-ID: <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> From: Garrett Cooper To: Pegasus Mc Cleaft Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anton Shterenlikht , freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 04:28:04 -0000 On Tue, Jan 20, 2009 at 3:00 AM, Pegasus Mc Cleaft wrote: > Hello Current, > > If anyone is interested, I have put togeather a port for binutils-2.19 and > have also created a PR ports/130715 to get it added to the ports tree. > > I would be greatfull for any peer review of the port as this is my first > attempt at making one. > > The latest tarball can be found: http://www.mthelicon.com/~ken/binutils/ > > ~Peg I hate to rain on your parade but that's LGPLv3, so it'll probably be rejected... You'll need to try binutils 2.17 (that's the latest LGPLv2.1 copy laying around). Good try though, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 04:43:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BEE2106564A for ; Wed, 21 Jan 2009 04:43:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 3BC678FC16 for ; Wed, 21 Jan 2009 04:43:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n0L4hQPv098448; Tue, 20 Jan 2009 20:43:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n0L4hQRn098447; Tue, 20 Jan 2009 20:43:26 -0800 (PST) (envelope-from sgk) Date: Tue, 20 Jan 2009 20:43:26 -0800 From: Steve Kargl To: Garrett Cooper Message-ID: <20090121044326.GA98425@troutmask.apl.washington.edu> References: <20090115084515.GA91157@freebsd.org> <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: "O. Hartmann" , Pegasus Mc Cleaft , Anton Shterenlikht , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 04:43:35 -0000 On Tue, Jan 20, 2009 at 08:28:01PM -0800, Garrett Cooper wrote: > On Tue, Jan 20, 2009 at 3:00 AM, Pegasus Mc Cleaft wrote: > > > > If anyone is interested, I have put togeather a port for binutils-2.19 and > > have also created a PR ports/130715 to get it added to the ports tree. > > > > I would be greatfull for any peer review of the port as this is my first > > attempt at making one. > > > > The latest tarball can be found: http://www.mthelicon.com/~ken/binutils/ > > > > ~Peg > > I hate to rain on your parade but that's LGPLv3, so it'll probably > be rejected... > You'll need to try binutils 2.17 (that's the latest LGPLv2.1 copy > laying around). > Good try though, > -Garrett ROTFL. See lang/port/gcc43. It's gplv3. It Peg said the s/he created a port. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 06:28:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1582A106564A for ; Wed, 21 Jan 2009 06:28:12 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id C0B108FC14 for ; Wed, 21 Jan 2009 06:28:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0L6SBC1076288; Tue, 20 Jan 2009 22:28:11 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4976C078.2040001@freebsd.org> Date: Tue, 20 Jan 2009 22:28:08 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <87skndg0cv.fsf@kobe.laptop> In-Reply-To: <87skndg0cv.fsf@kobe.laptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 06:28:12 -0000 Thank you! I found this bug last week but didn't know there was such an easy way to trigger it, so I haven't been in much of a hurry to commit the fix. I'll try to get that taken care of tonight. This turned out to be a libarchive bug; write_header() is returning the wrong code. ARCHIVE_WARN is supposed to indicate that the operation "succeeded with caveats". In particular, ARCHIVE_WARN from write_header() indicates that it's safe to write the following data. Libarchive should be returning ARCHIVE_FAILED in this case, to indicate that this particular file has to be abandoned. In particular, exit(1) is the wrong response to this particular error. Subsequent files might be going into other directories, after all, so cpio should keep on going and try the next file. The error messaging here is rather muddy and this duplication of messages has been bugging me for a while. I think the best solution is to go inside of libarchive and strip out the code that appends the strerror() information there, on the logic that the errno value is available to clients that want to display it. Then archive_error_string() will just contain the libarchive-specific clarification, so it will be appropriate to emit both. Tim Giorgos Keramidas wrote: > Hi Tim & -CURRENT, > > I think I stumbled upon a minor bsdcpio bug. When bsdcpio tries to > write to a directory it doesn't have permissions it core dumps: > > # mkdir /tmp/koko > # chmod 0700 /tmp/koko > > % cd /ws/keramida/src/usr.in/cpio > % env DEBUG_FLAGS='-ggdb' CFLAGS='' make bsdcpio > ... > % echo bsdcpio | ./bsdcpio -p -dmvu > bsdcpio: /tmp/koko/bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied: Permission denied > INTERNAL ERROR: Function 'archive_write_data' invoked with archive structure in state 'header', should be in state 'data' > Segmentation fault: 11 (core dumped) > > % gdb bsdcpio bsdcpio.core > #0 0x280b9ad7 in diediedie () at archive_check_magic.c:55 > 55 *(char *)0 = 1; /* Deliberately segfault and force a coredump. */ > (gdb) bt > #0 0x280b9ad7 in diediedie () at archive_check_magic.c:55 > #1 0x280b9caf in __archive_check_magic (a=0x28202140, magic=3221336261, state=4, > function=0x280bc960 "archive_write_data") at archive_check_magic.c:116 > #2 0x2809f95d in _archive_write_data (_a=0x28202140, buff=0x804f360, size=16384) at archive_write_disk.c:625 > #3 0x280a2e35 in archive_write_data (a=0x28202140, buff=0x804f360, s=16384) at archive_virtual.c:74 > #4 0x0804b534 in entry_to_archive (cpio=0xbfbfe6ec, entry=0x282231c0) at cpio.c:637 > #5 0x0804b219 in file_to_archive (cpio=0xbfbfe6ec, srcpath=0x2821e000 "bsdcpio") at cpio.c:542 > #6 0x0804c1d1 in mode_pass (cpio=0xbfbfe6ec, destdir=0xbfbfe94e "/tmp/koko") at cpio.c:939 > #7 0x0804a899 in main (argc=4, argv=0xbfbfe7c8) at cpio.c:291 > (gdb) > > It seems that cpio tries in entry_to_archive() to handle errors in calls > of archive_write_header() but it should be a bit more strict about it. > I picked up ARCHIVE_RETRY as the smallest error code we 'accept' when > archive_write_header() fails, but the choice seems pretty arbitrary. > The patch does solve the core dump I was seeing though. Does it look > good enough for cpio? Should we handle archive_write_header() errors > differently? > > %%% > diff -r cb9a95f8dfb3 usr.bin/cpio/cpio.c > --- a/usr.bin/cpio/cpio.c Tue Jan 20 21:45:52 2009 +0200 > +++ b/usr.bin/cpio/cpio.c Tue Jan 20 22:56:48 2009 +0200 > @@ -623,12 +623,12 @@ > r = archive_write_header(cpio->archive, entry); > > if (r != ARCHIVE_OK) > - cpio_warnc(archive_errno(cpio->archive), > + cpio_warnc(0, > "%s: %s", > - destpath, > + srcpath, > archive_error_string(cpio->archive)); > > - if (r == ARCHIVE_FATAL) > + if (r < ARCHIVE_RETRY) > exit(1); > > if (r >= ARCHIVE_WARN && fd >= 0) { > %%% > > While here, I also changed destpath to srcpath in the warning and > changed the 'code' argument of cpio_warnc() to zero, to avoid a > duplicate strerror() like output. The message returned by > archive_error_string() contains the destination path and strerror() text > already, so this changes the error from: > > bsdcpio: /tmp/koko/bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied: Permission denied > > to: > > bsdcpio: ./bsdcpio: Can't create '/tmp/koko/bsdcpio': Permission denied > > The cosmetic changes can probably go in a separate commit, but we should > probably fix & backport the core dump when archive_write_header() fails. > > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 06:50:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBFCD106564A; Wed, 21 Jan 2009 06:50:54 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4888FC13; Wed, 21 Jan 2009 06:50:54 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id n0L6eO5h023971; Wed, 21 Jan 2009 14:40:40 +0800 (CST) From: Kevin Lo To: Weongyo Jeong In-Reply-To: <20090119112333.GA36305@freebsd.weongyo.org> References: <20090119112333.GA36305@freebsd.weongyo.org> Content-Type: text/plain Date: Wed, 21 Jan 2009 14:38:18 +0800 Message-Id: <1232519898.26154.11.camel@srg.kevlo.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 OpenBSD/Ports Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 06:50:55 -0000 Weongyo Jeong wrote: > Hello, Hi Weongyo, > I would like to commit urtw(4) driver for supporting Realtek's 8187L > wireless chipset based on USB into HEAD by the end of the week if there > are no objections. And the license of files would be as follows that > AFAIK it's based on OpenBSD's template license file: > > /*- > * Copyright (c) 2008 Weongyo Jeong > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > Because I'm not a lawyer it'd definitely fail to answer about your > detailed questions. Just one thing I want to is that it's okay if it's > enough to use in *BSD, OpenSolaris and etc. Not want to go into > troubles. :-) > > I'm looking for a person to port from USB to NEWUSB and if you want to > test you can find the sources at: > > http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz Works for me, thanks. Though it's quite a bit slower, that's a job for another day :-) $ dmesg | grep urtw0 urtw0: on uhub0 urtw0: WARNING: using obsoleted IFF_NEEDSGIANT flag $ ifconfig plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 urtw0: flags=108843 metric 0 mtu 2290 ether 00:40:0c:04:3b:2a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843 metric 0 mtu 1500 ether 00:40:0c:04:3b:2a inet 192.168.1.116 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid MSI channel 11 (2462 Mhz 11g) bssid 00:11:09:0c:2f:91 country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > regards, > Weongyo Jeong Kevin From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 06:56:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC87106566B; Wed, 21 Jan 2009 06:56:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 536058FC08; Wed, 21 Jan 2009 06:56:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0L6uiC1076450; Tue, 20 Jan 2009 22:56:44 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4976C72A.50505@freebsd.org> Date: Tue, 20 Jan 2009 22:56:42 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <87skndg0cv.fsf@kobe.laptop> <497641FC.30209@gmx.de> <87d4eh8wj3.fsf@kobe.laptop> In-Reply-To: <87d4eh8wj3.fsf@kobe.laptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , freebsd-current@freebsd.org Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 06:56:46 -0000 Please try r187521, which should fix the core dump. I'll look at the error message more closely tomorrow. Cheers, Tim Giorgos Keramidas wrote: > On Tue, 20 Jan 2009 22:28:28 +0100, Christoph Mallon wrote: > >>Giorgos Keramidas schrieb: >> >>>diff -r cb9a95f8dfb3 usr.bin/cpio/cpio.c >>>--- a/usr.bin/cpio/cpio.c Tue Jan 20 21:45:52 2009 +0200 >>>+++ b/usr.bin/cpio/cpio.c Tue Jan 20 22:56:48 2009 +0200 >>>@@ -623,12 +623,12 @@ >>> r = archive_write_header(cpio->archive, entry); >>> if (r != ARCHIVE_OK) >>>- cpio_warnc(archive_errno(cpio->archive), >>>+ cpio_warnc(0, >>> "%s: %s", >>>- destpath, >>>+ srcpath, >>> archive_error_string(cpio->archive)); >> >>Wouldn't it be better to remove the manually appended error string, >>i.e. ": %s" ... archive_error_string(), instead of circumventing the >>generic error reporting magic provided by cpio_warnc()? > > > That's probably better. It's why I split the patch in two parts, so > Tim can review them separately and pick whatever is nicer :) > > It might be better to use: > > cpio_warnc(archive_errno(cpio->archive), > "%s", srcpath); > > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 07:21:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03125106566C; Wed, 21 Jan 2009 07:21:50 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id B8FAE8FC1A; Wed, 21 Jan 2009 07:21:49 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3627351rvf.43 for ; Tue, 20 Jan 2009 23:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=kKf9Um5j4wYdB/AOabcyfionl6krzYJu6qRByTmzTTg=; b=dMTJY1/vRYyGZ5Xi34UXUoRrS+iqlsQTL2Shnt6JZOugW2FDmjU/4I2OdJsf/H3IK3 qp0R3KuFGugKxswL/Z/gnvQffTTREcuD9oPCs437xa62Dx6juYwipLlbCzEAekfo2fKb 7jaW5b/K4kgrkX0JwurBFoQtqObUQ5nalqa9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=FTff7l7i2EU3O9DdLYS8xRhclAZqZi5hjq77HZn/7y0KjeE/fjJZJlMrNy3yJWN6xf hB4/gKRyfwFdRliTZHJPQc74TUHuZ65y8V8i3fljDjUm3FgPz/OFGkuUcFUDFVF6O1Ex D3g8qLtoFhKpiwiVLDjV1Pia49CeBGnQV6YJY= Received: by 10.140.157.1 with SMTP id f1mr3515204rve.196.1232522509446; Tue, 20 Jan 2009 23:21:49 -0800 (PST) Received: from freebsd.weongyo.org ([211.53.35.67]) by mx.google.com with ESMTPS id g14sm5883232rvb.0.2009.01.20.23.21.45 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jan 2009 23:21:48 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Wed, 21 Jan 2009 16:21:17 +0900 From: Weongyo Jeong Date: Wed, 21 Jan 2009 16:21:17 +0900 To: Kevin Lo Message-ID: <20090121072117.GA46438@freebsd.weongyo.org> Mail-Followup-To: Kevin Lo , current@freebsd.org, freebsd-usb@freebsd.org References: <20090119112333.GA36305@freebsd.weongyo.org> <1232519898.26154.11.camel@srg.kevlo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1232519898.26154.11.camel@srg.kevlo.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: HEADSUP: urtw(4) to be committed soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 07:21:50 -0000 On Wed, Jan 21, 2009 at 02:38:18PM +0800, Kevin Lo wrote: > Weongyo Jeong wrote: > > Hello, > > Hi Weongyo, > > > I would like to commit urtw(4) driver for supporting Realtek's 8187L > > wireless chipset based on USB into HEAD by the end of the week if there > > are no objections. And the license of files would be as follows that > > AFAIK it's based on OpenBSD's template license file: > > > > /*- > > * Copyright (c) 2008 Weongyo Jeong > > * > > * Permission to use, copy, modify, and distribute this software for any > > * purpose with or without fee is hereby granted, provided that the above > > * copyright notice and this permission notice appear in all copies. > > * > > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > */ > > > > Because I'm not a lawyer it'd definitely fail to answer about your > > detailed questions. Just one thing I want to is that it's okay if it's > > enough to use in *BSD, OpenSolaris and etc. Not want to go into > > troubles. :-) > > > > I'm looking for a person to port from USB to NEWUSB and if you want to > > test you can find the sources at: > > > > http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz > > > Works for me, thanks. Though it's quite a bit slower, that's a job > for another day :-) > > $ dmesg | grep urtw0 > urtw0: 2> on uhub0 > urtw0: WARNING: using obsoleted IFF_NEEDSGIANT flag > > $ ifconfig > plip0: flags=108810 metric 0 > mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > urtw0: flags=108843 > metric 0 mtu 2290 > ether 00:40:0c:04:3b:2a > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > wlan0: flags=8843 metric 0 mtu > 1500 > ether 00:40:0c:04:3b:2a > inet 192.168.1.116 netmask 0xffffff00 broadcast 192.168.1.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid MSI channel 11 (2462 Mhz 11g) bssid 00:11:09:0c:2f:91 > country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid > 60 > bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 > protmode CTS Thank you for testing. :-) The performance issue is a known issue that I think we need to fix a rate control routine for urtw(4). I tried to use wlan_amrr(4) but concluded it's hard to apply it without documents because I couldn't find a flag whether the tx is failed or not. It looks it's not enough with just looking USB_STATUS value of usb callbacks. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 07:24:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B85106566C for ; Wed, 21 Jan 2009 07:24:53 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 514738FC0A for ; Wed, 21 Jan 2009 07:24:53 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id AFCDF6D42B; Wed, 21 Jan 2009 08:26:01 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Zr7omuVxZr; Wed, 21 Jan 2009 08:25:58 +0100 (CET) Received: by mx1.rink.nu (Postfix, from userid 1000) id 97C2B6D423; Wed, 21 Jan 2009 08:25:58 +0100 (CET) Date: Wed, 21 Jan 2009 08:25:58 +0100 From: Rink Springer To: Giorgos Keramidas Message-ID: <20090121072558.GG78177@rink.nu> References: <87skndg0cv.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87skndg0cv.fsf@kobe.laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@FreeBSD.org, Tim Kientzle Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 07:24:53 -0000 On Tue, Jan 20, 2009 at 10:59:28PM +0200, Giorgos Keramidas wrote: > 55 *(char *)0 = 1; /* Deliberately segfault and force a coredump. */ Just nitpicking, but wouldn't a call to abort(3) be nicer here? -- Rink P.W. Springer - http://rink.nu "Chance favours the prepared mind" - Penn From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 09:23:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8F22106566C for ; Wed, 21 Jan 2009 09:23:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by mx1.freebsd.org (Postfix) with ESMTP id 413A08FC16 for ; Wed, 21 Jan 2009 09:23:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz6 with SMTP id 6so338767bwz.19 for ; Wed, 21 Jan 2009 01:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p4i4aN+O4ck7hNrkBi58dvjsLsspezlYPjE/2NX6zCM=; b=GxONQna7HGhSdOLJGpfLtAW6EUcP7eqUVKOt/Ch2tz9l3n//4cplLEYGKbKCe8SoMc yiBrSyQn33w2Iju3IoYviXKe6jG5f+IDCNDobM1meh7jCMYzkI4AcnmXpQOUn3LRgt53 50IAargYLVaOs6PEsAjg5VXXYzbpJnZFVR/Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WV+JgYpQexMn2nB5k2QQwErHTvBV6ieybjU05g+SHwgQWrldV2PEMHeW/p5sFkF5nP AtnzoXzC2FGzxW25vyDeuB1fin0JCJy/QEH2g4OLaShXm9sqRgt8NuWmHmiIdBEo8Rfk wbJg5iD+c/CCvZQqyxWcJPljTApErt5d9CjHc= MIME-Version: 1.0 Received: by 10.181.134.12 with SMTP id l12mr59468bkn.26.1232529632449; Wed, 21 Jan 2009 01:20:32 -0800 (PST) In-Reply-To: <20090121044326.GA98425@troutmask.apl.washington.edu> References: <20090115084515.GA91157@freebsd.org> <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> <20090121044326.GA98425@troutmask.apl.washington.edu> Date: Wed, 21 Jan 2009 01:20:32 -0800 Message-ID: <7d6fde3d0901210120y184dc3f0k7c7a9c96aeb1bba4@mail.gmail.com> From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" , Pegasus Mc Cleaft , Anton Shterenlikht , freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 09:23:51 -0000 On Tue, Jan 20, 2009 at 8:43 PM, Steve Kargl wrote: > On Tue, Jan 20, 2009 at 08:28:01PM -0800, Garrett Cooper wrote: >> On Tue, Jan 20, 2009 at 3:00 AM, Pegasus Mc Cleaft wrote: >> > >> > If anyone is interested, I have put togeather a port for binutils-2.19 and >> > have also created a PR ports/130715 to get it added to the ports tree. >> > >> > I would be greatfull for any peer review of the port as this is my first >> > attempt at making one. >> > >> > The latest tarball can be found: http://www.mthelicon.com/~ken/binutils/ >> > >> > ~Peg >> >> I hate to rain on your parade but that's LGPLv3, so it'll probably >> be rejected... >> You'll need to try binutils 2.17 (that's the latest LGPLv2.1 copy >> laying around). >> Good try though, >> -Garrett > > ROTFL. > > See lang/port/gcc43. It's gplv3. It > > Peg said the s/he created a port. Yeah... I just read the port field -_-. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 09:29:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35840106564A for ; Wed, 21 Jan 2009 09:29:19 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id ABA998FC1A for ; Wed, 21 Jan 2009 09:29:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1LPZOd-0002hz-Ho for freebsd-current@freebsd.org; Wed, 21 Jan 2009 09:29:17 +0000 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1LPZOZ-0003iB-Ms for freebsd-current@freebsd.org; Wed, 21 Jan 2009 09:29:12 +0000 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n0L9TAL9003244 for ; Wed, 21 Jan 2009 09:29:10 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n0L9T1x8003216 for freebsd-current@freebsd.org; Wed, 21 Jan 2009 09:29:01 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 21 Jan 2009 09:29:01 +0000 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20090121092901.GA2405@mech-cluster238.men.bris.ac.uk> References: <20090115084515.GA91157@freebsd.org> <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> <20090121044326.GA98425@troutmask.apl.washington.edu> <7d6fde3d0901210120y184dc3f0k7c7a9c96aeb1bba4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0901210120y184dc3f0k7c7a9c96aeb1bba4@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 X-Spam-Level: - Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 09:29:19 -0000 On Wed, Jan 21, 2009 at 01:20:32AM -0800, Garrett Cooper wrote: > >> > >> I hate to rain on your parade but that's LGPLv3, so it'll probably > >> be rejected... > >> You'll need to try binutils 2.17 (that's the latest LGPLv2.1 copy > >> laying around). I'm just a FBSD user. What's all this about, v2.1 vs v3? Is v3 more restrictive than v2.1? Or is this more complex? forgive my ignorance thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 09:42:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6FCA1065673 for ; Wed, 21 Jan 2009 09:42:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by mx1.freebsd.org (Postfix) with ESMTP id E9CB58FC17 for ; Wed, 21 Jan 2009 09:42:03 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz6 with SMTP id 6so356257bwz.19 for ; Wed, 21 Jan 2009 01:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rhHsiqbXsNc42IJMr5vAU9IEFow1PsIDQkJCIgD4LeA=; b=vP9VMek4aDeAb+9ftFl48P1mnksOL349FsgPFia8GtGW2R8x14IyuUBE4mImXxBSum ED8LzmBhky00iuROClmXUOSqq7irtOLkZ2y4kzD42V1reEkrxf2gfoB7pNHdRVOHa98T 9bLkFU+D0aBX4nMkbd2finur6Qwpl5mDb5WBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PQpdKjuTbdFbe4ir0ZUlQpp6Ga23MtPv27APRVEEFGLy0h5h3MUMjGE+5tbu/mbW+p g2eWRDO4PegPD9QuHGJiJLvtQr1saOaPVMDutK5AK7JxPxmvYcH+FitmxA3mqfxbAPU+ U7MhFqGZFlFKprfNsGQWrnmZMRwj3u511XAhU= MIME-Version: 1.0 Received: by 10.180.223.8 with SMTP id v8mr723890bkg.181.1232530757811; Wed, 21 Jan 2009 01:39:17 -0800 (PST) In-Reply-To: <20090121092901.GA2405@mech-cluster238.men.bris.ac.uk> References: <496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com> <20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> <3AF071CA587B4B61A2E1778E7FA17615@PegaPegII> <7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com> <20090121044326.GA98425@troutmask.apl.washington.edu> <7d6fde3d0901210120y184dc3f0k7c7a9c96aeb1bba4@mail.gmail.com> <20090121092901.GA2405@mech-cluster238.men.bris.ac.uk> Date: Wed, 21 Jan 2009 01:39:17 -0800 Message-ID: <7d6fde3d0901210139o4944c7ffw846ca7a6ecfc90b7@mail.gmail.com> From: Garrett Cooper To: Anton Shterenlikht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 09:42:05 -0000 On Wed, Jan 21, 2009 at 1:29 AM, Anton Shterenlikht wrote: > On Wed, Jan 21, 2009 at 01:20:32AM -0800, Garrett Cooper wrote: >> >> >> >> I hate to rain on your parade but that's LGPLv3, so it'll probably >> >> be rejected... >> >> You'll need to try binutils 2.17 (that's the latest LGPLv2.1 copy >> >> laying around). > > I'm just a FBSD user. What's all this about, v2.1 vs v3? > Is v3 more restrictive than v2.1? > Or is this more complex? > > forgive my ignorance > > thanks > anton In short, yes v3 is more restrictive that v2.1: http://www.opensource.org/licenses/lgpl-2.1.php http://www.opensource.org/licenses/lgpl-3.0.html I misread Peg's original post though, and didn't realize Peg was creating a port -- not trying to import the change into the base system... -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 11:14:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 609FE1065730 for ; Wed, 21 Jan 2009 11:14:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id 02B008FC16 for ; Wed, 21 Jan 2009 11:14:17 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 68231 invoked by uid 60001); 21 Jan 2009 11:14:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=zEAWt/ghGz/h7L25MdZm2k7gv8B1jdIVA76rmCvQn3GhKE8koDXX4lVROkOx4QR9NqjVkaG0b6xXGVZEr61NHRs2YsznZXVwQ3VJJY7X5fMkx+aUbL9ar8s1nRre2AKLxdeXUbp8GG4QhsFWZq6ThIF0JHbC+NCG/UXn+igWiPw=; X-YMail-OSG: 9t.uUXUVM1mVWDcc37vsgtl8yk8t4cg_wZBrEgOe3bDLqdKt67JAsfTakmbjrpfzGWUXJu8Pjos6N6icWCNMQOkIMy.BMWLTlOzDgOr9h4pcLDUQ0gVDnTsnlnn9urXGRI3zVyK5YbPf7VBC_SZV5_gZvgVTqlFHnndbSs_15mrfZvOc0tfEw51cwQpXXdI.RbSOqgiUGU1MObLCVYUgHExuwg-- Received: from [98.242.222.229] by web63908.mail.re1.yahoo.com via HTTP; Wed, 21 Jan 2009 03:14:17 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 21 Jan 2009 03:14:17 -0800 (PST) From: Barney Cordoba To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <864oztrflu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <419090.67820.qm@web63908.mail.re1.yahoo.com> Cc: freebsd-current@freebsd.org, Christof Schulze Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 11:14:21 -0000 --- On Tue, 1/20/09, Dag-Erling Sm=F8rgrav wrote: > From: Dag-Erling Sm=F8rgrav > Subject: Re: kldload exec format error on amd64 freebsd-7.1-rc2 > To: barney_cordoba@yahoo.com > Cc: freebsd-current@freebsd.org, "Christof Schulze" > Date: Tuesday, January 20, 2009, 1:34 PM > Barney Cordoba writes: > > Is there any interest in fixing this stupid and wrong > error message to > > be something like "unresolved externals" at > some point? >=20 > When the kernel fails to load a module, kldload(2) returns > ENOEXEC, > which strerror(3) translates to "exec format > error". If you can think > of a better errno value to use, feel free to send patches.=20 > The only > alternatives I can think of are ENOSYS (ambiguous) and > EFTYPE (just as > vague as ENOEXEC). >=20 > DES Have errnos reached MAXINT already? #define ENOREF 93 Or maybe some intelligent code, instead of just blindly calling warn(), sin= ce its just as likely an unresolved as it is a format error. I've patched mine to include "may have unresolved externals" so my customer= s have some idea that they might have a mismatched kernel. The=20 best solution is a more specific error. I'm not quite sure why BSD develop= ers are so frugal with errnos, but there must be a secret reason for it. No= body really cares if yacc returns EINVAL for every error, but functionally = visible binaries like kldload, which non-programmer users will encounter re= gularly, should have less cryptic error messages if possible.=20 kldload is what, 11 years old now? Its time. Barney=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 11:33:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8B9106566B for ; Wed, 21 Jan 2009 11:33:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id F3C928FC17 for ; Wed, 21 Jan 2009 11:33:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 16530 invoked by uid 60001); 21 Jan 2009 11:33:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=2jC0rG1BRFR+532aGD1tXSaDha+Tf/u+6qPihCfMWCrieDg4vhfiIEqhJEtODW6ddb326Gc8LXhPj9kHlT786SePQqtxOxPf97PWpWONh5WwsqQHDwGFzzBvuEsyuAW3WuZee0CYRnZVtct4U8Wky+dXz7Q+csBO1FowuGTrjeA=; X-YMail-OSG: lVtiMR8VM1l7SxK2JL4gLIvB1taoZSyR_pX6okGZB858pDC6sY7nBI5d6_LSdMrjWVNjo0oMaMvKrGRXVj.2ZzsXmVJmasWr9FybehvJQ0KtQTsVlwhahu0_PqJohncNhy6OwvXi9.Ghdz8ggPNHuiKg4iU- Received: from [98.242.222.229] by web63903.mail.re1.yahoo.com via HTTP; Wed, 21 Jan 2009 03:33:51 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 21 Jan 2009 03:33:51 -0800 (PST) From: Barney Cordoba To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <433125.16474.qm@web63903.mail.re1.yahoo.com> Subject: Binding timer interrupt to a cpu core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 11:33:52 -0000 Is there a way in 7.1 to bind a timer software interrupt? I see cpuset for userland threads, but its not clear how to do it within the kernel. Barney From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 11:40:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F1F10656E1 for ; Wed, 21 Jan 2009 11:40:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 059C48FC08 for ; Wed, 21 Jan 2009 11:40:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LPbRT-0007Ar-Uw for freebsd-current@freebsd.org; Wed, 21 Jan 2009 11:40:19 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 11:40:19 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 11:40:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 21 Jan 2009 12:39:59 +0100 Lines: 72 Message-ID: References: <433125.16474.qm@web63903.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF4A30DF1EB7DA7E6B040A56" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.19 (X11/20090105) In-Reply-To: <433125.16474.qm@web63903.mail.re1.yahoo.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Binding timer interrupt to a cpu core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 11:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF4A30DF1EB7DA7E6B040A56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Barney Cordoba wrote: > Is there a way in 7.1 to bind a timer software interrupt? I see cpuset = for userland threads, but its not clear how to do it within the kernel. Each CPU already has its own timer ticking: 3 users Load 0.00 0.00 0.00 Jan 21 12:36 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2152484 21140 2945416 46804 169412 count All 2267140 25916 7497096 71436 pages Proc: Interrup= ts r p d s w Csw Trp Sys Int Sof Flt 19 cow 3204 tot= al 6 170 476 213 119 4 147 203 101 zfod atkbd0 1 ozfod ata0 irq14 0.1%Sys 0.1%Intr 0.0%User 0.0%Nice 99.8%Idle %ozfod 1 ciss0 uhci | | | | | | | | | | | daefr uhci4 22 118 prcfr 400 cpu0: time 51 dtbuf 173 totfr 3 bce0 256 Namei Name-cache Dir-cache 100000 desvn react 400 cpu5: time Calls hits % hits % 83412 numvn pdwak 400 cpu7: time 33 28 85 1 3 24999 frevn pdpgs 400 cpu6: time intrn 400 cpu3: time Disks da0 pass0 478268 wire 400 cpu4: time KB/t 18.00 0.00 2240976 act 400 cpu2: time tps 2 0 1131116 inact 400 cpu1: time MB/s 0.04 0.00 129228 cache %busy 0 0 40184 free Interrupts can be bound to CPUs but only by using APIs within the kernel (there's no userland utility for it). --------------enigBF4A30DF1EB7DA7E6B040A56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdwmPldnAQVacBcgRAiGVAJ4w8maa7lic1EIug/qoMjVl0/UrNgCgwgY0 NkT/a0SEkWVDjyTGfSjEPFM= =GixZ -----END PGP SIGNATURE----- --------------enigBF4A30DF1EB7DA7E6B040A56-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 12:33:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14283106568A for ; Wed, 21 Jan 2009 12:33:23 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id C7C0C8FC0A for ; Wed, 21 Jan 2009 12:33:22 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n0LCV7hA065532; Wed, 21 Jan 2009 12:31:09 GMT (envelope-from ken@mthelicon.com) Message-ID: <6D1A9FB943724237A8E6490FA1AA4D34@PegaPegII> From: "Pegasus Mc Cleaft" To: "Garrett Cooper" , "Anton Shterenlikht" References: <496FBFCD.6010302@FreeBSD.org><7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com><20090116100932.GB36588@mech-cluster238.men.bris.ac.uk><497064C6.5070807@zedat.fu-berlin.de><3AF071CA587B4B61A2E1778E7FA17615@PegaPegII><7d6fde3d0901202028q255e82e6g3cc55df7046bd0c0@mail.gmail.com><20090121044326.GA98425@troutmask.apl.washington.edu><7d6fde3d0901210120y184dc3f0k7c7a9c96aeb1bba4@mail.gmail.com><20090121092901.GA2405@mech-cluster238.men.bris.ac.uk> <7d6fde3d0901210139o4944c7ffw846ca7a6ecfc90b7@mail.gmail.com> In-Reply-To: <7d6fde3d0901210139o4944c7ffw846ca7a6ecfc90b7@mail.gmail.com> Date: Wed, 21 Jan 2009 12:31:09 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Antivirus: avast! (VPS 090121-0, 21/01/2009), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 12:33:23 -0000 ----- Original Message ----- From: "Garrett Cooper" > > I misread Peg's original post though, and didn't realize Peg was > creating a port -- not trying to import the change into the base > system... No worries.. I would have loved to try and import into the base, but.... It dosent look like that will happen until things really get sorted out about the GPLv3 stuf. (Can we use it? Will the end users (companies) get scared off from FreeBSD if we did use GPLv3 code, will the sky go dark and rivers turn to blood, etc..) :> ~Peg From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 12:46:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 933D410656BB for ; Wed, 21 Jan 2009 12:46:51 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 53B168FC23 for ; Wed, 21 Jan 2009 12:46:51 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate01.web.de (Postfix) with ESMTP id 2CFA6FC0C015 for ; Wed, 21 Jan 2009 13:23:32 +0100 (CET) Received: from [217.236.0.162] (helo=zelda.local) by smtp06.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1LPc7H-0002oU-00 for freebsd-current@freebsd.org; Wed, 21 Jan 2009 13:23:31 +0100 Date: Wed, 21 Jan 2009 13:23:27 +0100 From: Martin To: freebsd-current@freebsd.org Message-ID: <20090121132327.68c9a2c3@zelda.local> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+Js1PqCCQbkC2Jv+PAr3wNDI43g/pG6+pJVtoZ ylLhrCsOZbcOxDT6kGquIaYH6XgwsWLHbFSwQ0aHhcmvfXSb+q 4oCP0Pa+M= Subject: panic in softdep handling routines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 12:46:52 -0000 Hallo, I installed a fresh CURRENT distribution yesterday (directly from HEAD). It installed ports fine, all the night. Today I've used smartctl to check few things and enabled SMART, of course. Shortly (perhaps not even 1 hour) after having enabled SMART I got this panic. I wrote it down on a piece of paper, but I think it can still be useful. ad0: FAILURE - SMART status=51 error=4 dev = ad0s3d, block = 3389512, fs = /tmp cpuid = 1 [...] Tracing pid 29 tid 100054 td 0xffffff0001919ab0 kdb_enter+0x3d panic+0x176 ffs_blkfree+0x6c7 indir_trunc+0x1f4 handle_workitem_freeblocks+0x281 process_worklist_item+0x29d softdep_flush+0x127 fork_exit+0x118 fork_trampoline+0xe /tmp is mounted rw with softupdates. I checked the SMART log of this hard disk once again with -STABLE. There is nothing suspicious logged. Hope it helps, Thank you. -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 13:14:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C54D1065767 for ; Wed, 21 Jan 2009 13:14:03 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id E51C08FC1A for ; Wed, 21 Jan 2009 13:14:02 +0000 (UTC) (envelope-from root@dchagin.dialup.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 7B10E45DB9; Wed, 21 Jan 2009 16:14:00 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.dialup.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1581792426; Wed, 21 Jan 2009 16:14:00 +0300 Received: from dchagin.dialup.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.dialup.corbina.ru (8.14.3/8.14.3) with ESMTP id n0LDDxAw013591; Wed, 21 Jan 2009 16:13:59 +0300 (MSK) (envelope-from root@dchagin.dialup.corbina.ru) Received: (from root@localhost) by dchagin.dialup.corbina.ru (8.14.3/8.14.3/Submit) id n0LDDsGk013590; Wed, 21 Jan 2009 16:13:54 +0300 (MSK) (envelope-from root) Date: Wed, 21 Jan 2009 16:13:54 +0300 From: Chagin Dmitry To: Martin Message-ID: <20090121131354.GA13533@dchagin.dialup.corbina.ru> References: <20090121132327.68c9a2c3@zelda.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090121132327.68c9a2c3@zelda.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: panic in softdep handling routines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:14:04 -0000 On Wed, Jan 21, 2009 at 01:23:27PM +0100, Martin wrote: > > Hallo, > > I installed a fresh CURRENT distribution yesterday (directly from > HEAD). It installed ports fine, all the night. > > Today I've used smartctl to check few things and enabled SMART, of > course. > > Shortly (perhaps not even 1 hour) after having enabled SMART I got this > panic. I wrote it down on a piece of paper, but I think it can still be > useful. > > ad0: FAILURE - SMART status=51 error=4 > > dev = ad0s3d, block = 3389512, fs = /tmp > cpuid = 1 > [...] > Tracing pid 29 tid 100054 td 0xffffff0001919ab0 > kdb_enter+0x3d > panic+0x176 > ffs_blkfree+0x6c7 > indir_trunc+0x1f4 > handle_workitem_freeblocks+0x281 > process_worklist_item+0x29d > softdep_flush+0x127 > fork_exit+0x118 > fork_trampoline+0xe > > > /tmp is mounted rw with softupdates. I checked the SMART log of this > hard disk once again with -STABLE. There is nothing suspicious logged. > update to r187490. -- Have fun! chd From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 13:39:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BC610656F7 for ; Wed, 21 Jan 2009 13:39:20 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 75F178FC17 for ; Wed, 21 Jan 2009 13:39:20 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 14749 invoked by uid 60001); 21 Jan 2009 13:39:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=mJHa//ufdDdjzk6ElTTGTpTi3e0W7v9w8CfI5YROdn5zj2V8HteAL/C7Q6GpcMZdgBO0wvMhvk8wqPlYwHA/mZSxceJudxOtvRdyYk6Tcpic7o686pVUI00MtJoz3gu46kJjAGsMI/0oCYiOby4Q0ZEtKptLJ3TCuHoX3rYfSVA=; X-YMail-OSG: XY2HdV8VM1km6vUhnESmmooVztOeazU2QpepIsxEexVosRYPUHN8kZyi89ePBDjT94Eyk4iPrsNvZb9U5u7dZHfHJ_mB4WoIPJGiNBxtOzMq4z864SYDVNJoDblZE5CDnKFO_5NTIsBTWhqmyBhFLX6G39_eECQczfMC_m7Nxmolq21wRiU7JFYXa_cCjUk- Received: from [98.242.222.229] by web63902.mail.re1.yahoo.com via HTTP; Wed, 21 Jan 2009 05:39:19 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 21 Jan 2009 05:39:19 -0800 (PST) From: Barney Cordoba To: freebsd-current@freebsd.org, Ivan Voras In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <423770.14655.qm@web63902.mail.re1.yahoo.com> Cc: Subject: Re: Binding timer interrupt to a cpu core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:39:22 -0000 --- On Wed, 1/21/09, Ivan Voras wrote: > From: Ivan Voras > Subject: Re: Binding timer interrupt to a cpu core > To: freebsd-current@freebsd.org > Date: Wednesday, January 21, 2009, 6:39 AM > Barney Cordoba wrote: > > Is there a way in 7.1 to bind a timer software > interrupt? I see cpuset for userland threads, but its not > clear how to do it within the kernel. > > Each CPU already has its own timer ticking: > > 3 users Load 0.00 0.00 0.00 Jan > 21 12:36 > > Mem:KB REAL VIRTUAL VN > PAGER SWAP > PAGER > Tot Share Tot Share Free in > out in > out > Act 2152484 21140 2945416 46804 169412 count > All 2267140 25916 7497096 71436 pages > Proc: > Interrupts > r p d s w Csw Trp Sys Int Sof Flt 19 > cow 3204 total > 6 170 476 213 119 4 147 203 101 > zfod > atkbd0 1 > > ozfod > ata0 irq14 > 0.1%Sys 0.1%Intr 0.0%User 0.0%Nice 99.8%Idle > %ozfod 1 > ciss0 uhci > | | | | | | | | | | | > daefr > uhci4 22 > 118 > prcfr 400 > cpu0: time > 51 dtbuf 173 > totfr 3 > bce0 256 > Namei Name-cache Dir-cache 100000 desvn > react 400 > cpu5: time > Calls hits % hits % 83412 numvn > pdwak 400 > cpu7: time > 33 28 85 1 3 24999 frevn > pdpgs 400 > cpu6: time > > intrn 400 > cpu3: time > Disks da0 pass0 478268 > wire 400 > cpu4: time > KB/t 18.00 0.00 2240976 > act 400 > cpu2: time > tps 2 0 1131116 > inact 400 > cpu1: time > MB/s 0.04 0.00 129228 > cache > %busy 0 0 40184 > free > > > Interrupts can be bound to CPUs but only by using APIs > within the kernel > (there's no userland utility for it). I'm asking HOW, to do it within the kernel. When I said timer, I meant software interrupts created with timeout() Barney From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 14:25:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60B0D1065745; Wed, 21 Jan 2009 14:25:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3898F8FC27; Wed, 21 Jan 2009 14:25:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C344946B32; Wed, 21 Jan 2009 09:25:41 -0500 (EST) Date: Wed, 21 Jan 2009 14:25:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <423770.14655.qm@web63902.mail.re1.yahoo.com> Message-ID: References: <423770.14655.qm@web63902.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jeff@FreeBSD.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Binding timer interrupt to a cpu core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:25:43 -0000 On Wed, 21 Jan 2009, Barney Cordoba wrote: >> Interrupts can be bound to CPUs but only by using APIs within the kernel >> (there's no userland utility for it). > > I'm asking HOW, to do it within the kernel. > > When I said timer, I meant software interrupts created with timeout() This is supported in FreeBSD 8.x, but not yet 7.x and earlier. Whoever added this support failed to update the timeout(9) man page, however, so the source is the reference -- take a look at callout.h, but gist is that you can call callout_reset_on(), callout_reset_curcpu(), callout_schedule_on(), and callout_schedule_curcpu() to specify the next CPU that the callout should run on. (Jeff Roberson CC'd to remind him that he wants to update timeout.9, or find someone to help him do that, so that it includes the new interfaces). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 15:08:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77BC91065881; Wed, 21 Jan 2009 15:08:43 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 743B58FC08; Wed, 21 Jan 2009 15:08:42 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl189-242.kln.forthnet.gr [79.103.2.242]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n0LF8WlQ029758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jan 2009 17:08:38 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0LF8Vet008417; Wed, 21 Jan 2009 17:08:31 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0LF8VXr008416; Wed, 21 Jan 2009 17:08:31 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Tim Kientzle References: <87skndg0cv.fsf@kobe.laptop> <497641FC.30209@gmx.de> <87d4eh8wj3.fsf@kobe.laptop> <4976C72A.50505@freebsd.org> Date: Wed, 21 Jan 2009 17:08:31 +0200 In-Reply-To: <4976C72A.50505@freebsd.org> (Tim Kientzle's message of "Tue, 20 Jan 2009 22:56:42 -0800") Message-ID: <87mydkzogg.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n0LF8WlQ029758 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.168, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.23, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Christoph Mallon , freebsd-current@freebsd.org Subject: Re: [PATCH] bsdcpio core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 15:09:04 -0000 On Tue, 20 Jan 2009 22:56:42 -0800, Tim Kientzle wrote: > Please try r187521, which should fix the core dump. > > I'll look at the error message more closely tomorrow. Thanks Tim! I updated my libarchive, and backed out the local hack that checks the return value of archive_write_header(). Now things work fine: $ find bsdcpio | ./bsdcpio -p -dmu /tmp/koko bsdcpio: 'bsdcpio': Can't create '/tmp/koko/bsdcpio': Permission denied 0 blocks From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 16:19:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B40106566C for ; Wed, 21 Jan 2009 16:19:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 80F498FC18 for ; Wed, 21 Jan 2009 16:19:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LPfna-00037E-LY for freebsd-current@freebsd.org; Wed, 21 Jan 2009 16:19:26 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 16:19:26 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 16:19:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Wed, 21 Jan 2009 08:19:15 -0800 Lines: 49 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.9 Sender: news Subject: memory alignment problems with -current on amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 16:19:31 -0000 With recent kernels on HAMMER/amd64 I cannot complete a buildworld. The compilation keeps failing with problems like: cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\" -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\" -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c: In function 'subseg_set_rest': /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c:205: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Yet if I run the failed command it will complete successfully: [root@dl385g5 /usr/src]# cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/as/../libbfd -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\" -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\" -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/usr/src/gnu/usr.bin/binutils/as -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c [root@dl385g5 /usr/src]# echo $? 0 If I boot back to a kernel from sources Oct 15th 2008, I can complete a buildworld on this machine no problem. * This is a HP DL385G5 with 1 quad core AMD 2100 and 10G of memory. * This the amd64 GENERIC kernel * I've tried reducing hw.physmem to 2G, but that didn't make any difference. * I will recieve bus errors when running buildworld w/ -j1 * If I run buildworld with a larger number the machine will reset w/ no panic. Ideas? -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 16:27:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B7251065672 for ; Wed, 21 Jan 2009 16:27:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B4A018FC1E for ; Wed, 21 Jan 2009 16:27:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPfvj-000NGM-La; Wed, 21 Jan 2009 18:27:51 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LGRmZi022905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 18:27:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LGRmN8048160; Wed, 21 Jan 2009 18:27:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LGRmT5048159; Wed, 21 Jan 2009 18:27:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 18:27:48 +0200 From: Kostik Belousov To: Mark Atkinson Message-ID: <20090121162748.GQ58517@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="glwmnIOgU1tcuP7N" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPfvj-000NGM-La 68cbdd83ab7727c3140a47fa049d79b0 X-Terabit: YES Cc: freebsd-current@freebsd.org Subject: Re: memory alignment problems with -current on amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 16:27:54 -0000 --glwmnIOgU1tcuP7N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 08:19:15AM -0800, Mark Atkinson wrote: >=20 > With recent kernels on HAMMER/amd64 I cannot complete a buildworld. The What is the svn revision of your sources ? --glwmnIOgU1tcuP7N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3TQMACgkQC3+MBN1Mb4hfYQCgjqEeTjnz6k2VWk6XfnyMxMEG 9/EAmgP67MCJbEZQddB+wgVy65gcP6GL =yxzW -----END PGP SIGNATURE----- --glwmnIOgU1tcuP7N-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 16:43:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F221065670 for ; Wed, 21 Jan 2009 16:43:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC3F8FC12 for ; Wed, 21 Jan 2009 16:43:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n0LGho76002716; Wed, 21 Jan 2009 08:43:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n0LGho3f002715; Wed, 21 Jan 2009 08:43:50 -0800 (PST) (envelope-from sgk) Date: Wed, 21 Jan 2009 08:43:50 -0800 From: Steve Kargl To: Mark Atkinson Message-ID: <20090121164350.GA2673@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: memory alignment problems with -current on amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 16:43:51 -0000 On Wed, Jan 21, 2009 at 08:19:15AM -0800, Mark Atkinson wrote: > > internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. Run memtest86+ -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 19:38:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD4E106564A for ; Wed, 21 Jan 2009 19:38:26 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 31E578FC1D for ; Wed, 21 Jan 2009 19:38:25 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by nf-out-0910.google.com with SMTP id h3so560189nfh.33 for ; Wed, 21 Jan 2009 11:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=eHznVOFsto4aM0WVjv0CufckklLKdbVRJqjv+NGqvvw=; b=ZsN4c6gqm9K4VithLDD0w/tvSFEqMuCL5mA9o8u4MrKREdIJSH3iTJn47qlFj62que SgKBi1MOxNDoNYg5LGINWGYG0AclRxxjzvo7uDtPCC9Dk8TGQtJOXyicc7J74itSMvXL AkXIrLKizKSePTJB7Br0FHgPXE+qtMv5RcWNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=E+w18LQpPhLuEmVUbuMapz2UQ9Bt19hZ2RBXewONZMOPkwJ65h6ZowieX/DkburlIQ 8VtfES5GKuURXtwNhRdrSYZ/nvw8NIzmuB1ygcsHwJX51/19C/50OKWLgzSpoERE4upH c4eRXrBwHyvbPTMkx9XL9swgjWfeWZqyw0kQM= Received: by 10.103.49.12 with SMTP id b12mr538397muk.98.1232565274724; Wed, 21 Jan 2009 11:14:34 -0800 (PST) Received: from ?10.30.1.178? (vpn-or.studi-planet.com [78.47.172.52]) by mx.google.com with ESMTPS id u26sm12900193mug.41.2009.01.21.11.14.29 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 11:14:34 -0800 (PST) From: Mister Olli To: freebsd-current@freebsd.org Content-Type: text/plain Date: Wed, 21 Jan 2009 20:14:03 +0100 Message-Id: <1232565243.5225.31.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit Subject: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 19:38:27 -0000 Hi.. I'm currently trying to setup FreeBSD 8-CURRENT as a para-virtualized domU on XEN 3.3.0 (with gentoo dom0). When I configure 2 CPU's (using vcpus=2) in the domU config file, I get the following error during bootup: ========================================================================== virt-001 template_8-CURRENT # xm create -c 00_template_8-CURRENT.XENconfig Using config file "./00_template_8-CURRENT.XENconfig". Started domain template_8-CURRENT WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Wed Jan 14 21:47:10 CET 2009 root@template-8_CURRENT.localdomain:/usr/obj/usr/src/sys/freebsd8_XEN WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 1600.056 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Athlon(tm) Processor (1600.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 268435456 (256 MB) avail memory = 256045056 (244 MB) gdtpfn=3e2d8 pdptpfn=28a43 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu=0 irq=0 vector=0 cpu=0 irq=0 vector=1 cpu=1 irq=0 vector=0 cpu=1 irq=0 vector=1 kbd0 at kbdmux0 xenbus0: on motherboard xc0: on motherboard Timecounters tick every 100.000 msec xbd0: 5120MB at device/vbd/768 on xenbus0 xbd0: attaching as ad0 xn0: at device/vif/0 on xenbus0 xn0: Ethernet address: 00:16:3e:11:4d:c4 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). [XEN] netfront_backend_changed: newstate=2 [XEN] netfront_backend_changed: newstate=4 Spanic: blockable sleep lock (sleep mutex) XCONS LOCK @ /usr/src/sys/dev/xen/console/console.c:290 cpuid = 1 KDB: enter: panic [thread pid 11 tid 100003 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> ========================================================================= greetz Mr. Olli From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 21:19:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 899D5106564A for ; Wed, 21 Jan 2009 21:19:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 374E38FC19 for ; Wed, 21 Jan 2009 21:19:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LPkTU-0007x5-9y for freebsd-current@freebsd.org; Wed, 21 Jan 2009 21:19:00 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 21:19:00 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Jan 2009 21:19:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Wed, 21 Jan 2009 13:18:52 -0800 Lines: 17 Message-ID: References: <20090121162748.GQ58517@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.9 Sender: news Subject: Re: memory alignment problems with -current on amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 21:19:01 -0000 Kostik Belousov wrote: > On Wed, Jan 21, 2009 at 08:19:15AM -0800, Mark Atkinson wrote: >> >> With recent kernels on HAMMER/amd64 I cannot complete a buildworld. The > What is the svn revision of your sources ? The current kernel exhibiting the problem is from Monday Jan 19th. I have re-tried with todays sources w/ the same result. HP's BIOS based memory diag passes. This unit has advanced ecc dimms on board. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 23:11:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FD5106574B; Wed, 21 Jan 2009 23:11:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C51A68FC08; Wed, 21 Jan 2009 23:11:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 4219B46B06; Wed, 21 Jan 2009 18:11:11 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LNB5db037051; Wed, 21 Jan 2009 18:11:05 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Bruce M. Simpson" Date: Wed, 21 Jan 2009 15:36:08 -0500 User-Agent: KMail/1.9.7 References: <200811191503.02192.jhb@freebsd.org> <4937EC6D.7050703@FreeBSD.org> In-Reply-To: <4937EC6D.7050703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211536.08297.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 18:11:05 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 23:11:12 -0000 On Thursday 04 December 2008 9:42:53 am Bruce M. Simpson wrote: > John Baldwin wrote: > > Please test! This is the last non-MPSAFE network driver at this point. This > > patch adds locking for the ppbus(4)/ppc(4) devices and the various ppbus > > child devices (lpt, vpo, lpbb, ppi, pps). The basic model is that a single > > mutex in the ppc(4) driver protects the ppc0 hardware and is shared with the > > various child drivers. Two drivers now have detach methods that did not have > > them before (plip and ppi). I've done some simple testing on my laptop (able > > to load the drivers and do some simple things w/o panic'ing or tripping > > assertions), but I am not really able to test the peripheral drivers fully. > > > > http://www.FreeBSD.org/~jhb/patches/ppc_locking.patch > > > > > > Runway lpt Giant is an occasionally show stopping issue for me because > my printer is attached via the plt port. I may get time to look at this > later on... > > I tried applying these patches against 7-STABLE. > > ppc_cleanup.patch applied OK to 7. > > ppc_intr.patch applied OK to 7 with interrupt.h change manually merged, > and some fixups to ppc.c for earlier intr_event kpi. > > ppc_locking.patch does not apply cleanly, and it's too much for me to > deal with right now. > > I found I had to hack up an existing 7 tree in /usr/src to get things to > compile because of the wide scope of the changes (touching kern, sys > etc), I couldn't just use an svn checkout to work from. Try http://www.FreeBSD.org/~jhb/patches/ppc_mpsafe_7.patch It is a complete backport generated against a fresh stable/7 tree. It does not need the interrupt changes since my locking patches actually undo them. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 00:34:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44B58106564A; Thu, 22 Jan 2009 00:34:58 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id DF10D8FC16; Thu, 22 Jan 2009 00:34:57 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n0LNUBNO010003; Wed, 21 Jan 2009 18:30:12 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <86zlhlq03p.fsf@ds4.des.no> References: <20090114175228.GA54368@freebsd.org> <680234114D7A4F94A81D44EDBB1C969B@Baya> <20090120175558.GA43333@freebsd.org> <86zlhlq03p.fsf@ds4.des.no> Date: Wed, 21 Jan 2009 18:30:10 -0500 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Roman Divacky From: Garance A Drosihn Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.00 () [Hold at 20.00] 22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 00:34:58 -0000 At 7:54 PM +0100 1/20/09, Dag-Erling Sm=F8rgrav wrote: >Roman Divacky writes: >> Lesly Bien-Aim=E9 writes: >> > www.OpenWatcom.com >> > >> > "Work in progress includes Linux and FreeBSD ports" > > > > this has been the case for quite some years now... it looks like > > a dead project... :( > >They released 1.8 RC2 just two weeks ago - still no FreeBSD support, >though. > >What about TenDRA and Ten15? As near as I can tell, it looks like both of these projects have stalled. -- Garance Alistair Drosehn =3D gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 03:04:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4D1106564A for ; Thu, 22 Jan 2009 03:04:13 +0000 (UTC) (envelope-from benjamindadams@gmail.com) Received: from mail-qy0-f17.google.com (mail-qy0-f17.google.com [209.85.221.17]) by mx1.freebsd.org (Postfix) with ESMTP id 27A288FC0C for ; Thu, 22 Jan 2009 03:04:12 +0000 (UTC) (envelope-from benjamindadams@gmail.com) Received: by qyk10 with SMTP id 10so6070491qyk.19 for ; Wed, 21 Jan 2009 19:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=dmpbGXaTt37e7eeuM0j0eS+yOj5+ma7H/8TK5okMXhA=; b=GSMtBH4yfWJvJgCV0WGLQPsc638wzVUA4MxO1//OmxGWfaWjsD0zO7vt0CCMLnSEOB 9ypDz2p19qO+JsmGQM801/3nHEbKxzrukVc/J7ZdlZAiWq2zZZopFdVJmFxaKToYVebZ peyJVKuEzptc/ysmJQxaaa+9ISIheTbJ7ZmfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=TAmjUSmJnHCZlPfdTI4MfkU0jssV3D3hLRXmOwHodWeIaS3ylACROUuD0kZ1Jt76K3 43DrzExOTC1Xk0yPTcSl1HRntv1vSErfrxy/zfgJEwKXj0xcRec5/Y7j9/T4e83NpV5h 5K9x0qPFJJcribogFnlrdiQDYvwcwxmuJjh+o= Received: by 10.214.115.1 with SMTP id n1mr10146899qac.374.1232592073233; Wed, 21 Jan 2009 18:41:13 -0800 (PST) Received: from ?192.168.1.103? (cpe-74-79-67-45.twcny.res.rr.com [74.79.67.45]) by mx.google.com with ESMTPS id 5sm8322920yxt.21.2009.01.21.18.41.11 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 18:41:12 -0800 (PST) From: Ben Adams To: current@freebsd.org Content-Type: multipart/mixed; boundary="=-dq2fxg1WGxjiHlNkDX3r" Date: Wed, 21 Jan 2009 21:41:42 -0500 Message-Id: <1232592102.13146.2.camel@laptop.sprymed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Mailman-Approved-At: Thu, 22 Jan 2009 04:46:20 +0000 Cc: Subject: dmesg for IBM T60 on 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 03:04:13 -0000 --=-dq2fxg1WGxjiHlNkDX3r Content-Type: text/plain Content-Transfer-Encoding: 7bit System Call showing Error?? KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c45242b8,e6dc0468,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb62,c49c19c4,c0bd05f5,c45242b8,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c49c19c4,9,c0bf92b3,221,0,...) at witness_checkorder +0x839 __lockmgr_args(c49c19c4,80100,c49c19e0,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6dc0578,c0e66518,c4a54524,80100,c49c196c,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6dc0578,e6dc0598,c0cf2680,c49c196c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c49c196c,80100,c0bf92b3,221,c4551200,...) at _vn_lock+0x5e ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot +0x1527 ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount +0x146f vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at vfs_donmount+0x1312 nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- lock order reversal: 1st 0xd85df670 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc5a99cdc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:794 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c4524a70,e6dc0468,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5a99cdc,c0bf9315,c4524a70,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c5a99cdc,9,c0bf92b3,31a,c5a9b4a4,...) at witness_checkorder+0x839 __lockmgr_args(c5a99cdc,80400,c5a9b4a4,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6dc0578,0,0,80400,c5a9b430,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6dc0578,c1979284,c0cf2680,c5a9b430,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5a9b430,80400,c0bf92b3,31a,0,...) at _vn_lock+0x5e ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot +0x28c6 ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount +0x146f vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at vfs_donmount+0x1312 nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- lock order reversal: 1st 0xc5a99cdc snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:293 2nd 0xc5a9b488 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1588 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc08c4,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c4524a70,c45242b8,e6dc0920,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5a9b488,c0bd05f5,c45242b8,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c5a9b488,9,c0bf92b3,634,0,...) at witness_checkorder +0x839 __lockmgr_args(c5a9b488,80000,0,0,0,...) at __lockmgr_args+0x797 ffs_snapremove(c5a9b430,c49d7500,0,c0be4ac3,414,...) at ffs_snapremove +0x11f softdep_releasefile(c5a9d690,e6dc0aa8,2,c0e664e8,c0cc1b64,...) at softdep_releasefile+0x3b ufs_inactive(e6dc0ae8,c5a9b4a4,c5a9b430,c5a9b4a4,e6dc0b00,...) at ufs_inactive+0x1bc VOP_INACTIVE_APV(c0cde5a0,e6dc0ae8,c0be38fd,914,c0cf2640,...) at VOP_INACTIVE_APV+0xa5 vinactive(c0cde5a0,e6dc0b1c,c0be38fd,8a0,128,...) at vinactive+0x8e vput(c5a9b430,e6dc0b54,c0be4ac3,125,c0cf23c0,...) at vput+0x1db vn_close(c5a9b430,1,c456b400,c4a54480,e6dc0be0,...) at vn_close+0xee vn_closefile(c498e888,c4a54480,3,0,c498e888,...) at vn_closefile+0xe9 _fdrop(c498e888,c4a54480,e6dc0c1c,c0871a6c,0,c4a54524,c0e664e8,c0cc3370,c0bd2199,c576372c,44f,c0bd2199,e6dc0c44,c083a780,c576372c,8,c0bd2199,44f) at _fdrop+0x43 closef(c498e888,c4a54480,44f,434,c498e888,...) at closef+0x290 kern_close(c4a54480,4,e6dc0d2c,c0b29ec3,c4a54480,...) at kern_close +0x11d close(c4a54480,e6dc0cf8,4,c0bddf84,c0cbafd0,...) at close+0x1a syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28184073, esp = 0xbfbfdb5c, ebp = 0xbfbfdb88 --- lock order reversal: 1st 0xd8539350 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc5b6e400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6e78a74,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c4524320,e6e78ad0,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5b6e400,c0bfb766,c4524320,c0bfb3ff,...) at _witness_debugger+0x25 witness_checkorder(c5b6e400,9,c0bfb3ff,107,0,...) at witness_checkorder +0x839 _sx_xlock(c5b6e400,0,c0bfb3ff,107,d9719018,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c4961800,d85392f0,d9719018,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c5bf9690,d9719018,18,e6e78b60,e6e78b5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c5d85218,c5e4d2d0,500800c,0,c5d85218,...) at ufs_dirremove +0xe5 ufs_remove(e6e78c30,e6e78c30,0,e6e78c30,c5e48000,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0cde5a0,e6e78c30,2,0,28216238,...) at VOP_REMOVE_APV +0xa5 kern_unlinkat(c56eed80,ffffff9c,28216238,0,e6e78c80,...) at kern_unlinkat+0x187 kern_unlink(c56eed80,28216238,0,e6e78d2c,c0b29ec3,...) at kern_unlink +0x27 unlink(c56eed80,e6e78cf8,4,c0bf5f1c,c0cbb030,...) at unlink+0x22 syscall(e6e78d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815aa8f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6e8 --- lock order reversal: 1st 0xc579bb2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xc5ca5ce8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4065 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6d63a30,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c4521948,c45242b8,e6d63a8c,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5ca5ce8,c0bd05f5,c45242b8,c0be38fd,...) at _witness_debugger+0x25 witness_checkorder(c5ca5ce8,9,c0be38fd,fe1,c5ca5d04,...) at witness_checkorder+0x839 __lockmgr_args(c5ca5ce8,80400,c5ca5d04,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6d63b9c,c,0,80400,c5ca5c90,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6d63b9c,e6d63ba4,c0cf2680,c5ca5c90,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5ca5c90,80400,c0be38fd,fe1,e6d63bf8,...) at _vn_lock+0x5e vfs_knllock(c5ca5c90,0,c0bd26b1,68c,c4e2361c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e6d63c18,c08b6fe9,c5d1608c,c4e2361c,...) at knlist_remove_kq+0xad knlist_remove(c5d1608c,c4e2361c,0,e6d63c44,c0809d65,...) at knlist_remove+0x1b filt_vfsdetach(c4e2361c,0,c0bd26b1,75c,8,...) at filt_vfsdetach+0x39 knote_fdclose(c4998d80,8,c0bd2199,434,c57cfcb0,...) at knote_fdclose +0xf5 kern_close(c4998d80,8,e6d63d2c,c0b29ec3,c4998d80,...) at kern_close+0xd5 close(c4998d80,e6d63cf8,4,c0bdd36a,c0cbafd0,...) at close+0x1a syscall(e6d63d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x284c3073, esp = 0xbfbfe10c, ebp = 0xbfbfe128 --- --=-dq2fxg1WGxjiHlNkDX3r Content-Disposition: attachment; filename="dmesg.txt" Content-Type: text/plain; name="dmesg.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT-200812 #0: Thu Dec 4 07:45:53 UTC 2008 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2500 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfe9fbff Features2=0xc1a9 AMD Features=0x100000 TSC: P-state invariant Cores per package: 2 real memory = 1072496640 (1022 MB) avail memory = 1031938048 (984 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xd8000000-0xdfffffff,0xee100000-0xee10ffff irq 16 at device 0.0 on pci1 pci0: at device 27.0 (no driver attached) pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 em0: port 0x3000-0x301f mem 0xee000000-0xee01ffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:21:86:9f:b7:37 pcib3: irq 21 at device 28.1 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 22 at device 28.2 on pci0 pci4: on pcib4 pcib5: irq 23 at device 28.3 on pci0 pci12: on pcib5 uhci0: port 0x1800-0x181f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xee404000-0xee4043ff irq 19 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci21: on pcib6 cbb0: mem 0xe4300000-0xe4300fff irq 16 at device 0.0 on pci21 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x18c8-0x18cf,0x18ac-0x18af,0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf mem 0xee404400-0xee4047ff irq 16 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci1 ata2: executing CLO failed ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ucom0: on uhub1 ucom0: configured 3 serial ports (U0.%d) ugen0: on uhub3 ugen1: on uhub3 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 95396MB at ata2-master SATA150 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted lock order reversal: 1st 0xc456a044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc4831ad0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,c41bb90c,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c451f728,c45242b8,c41bb968,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c4831ad0,c0bd05f5,c45242b8,c0be38fd,...) at _witness_debugger+0x25 witness_checkorder(c4831ad0,1,c0be38fd,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c4831ad0,200501,c4831aec,0,0,...) at __lockmgr_args+0x237 ffs_lock(c41bba78,c08719cb,c0bff68d,200501,c4831a78,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,c41bba78,c4566e24,c0cf2680,c4831a78,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4831a78,200501,c0be38fd,81f,4,...) at _vn_lock+0x5e vget(c4831a78,200501,c4566d80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c187e2e8,0,c0bfcc6f,127,c41bbc18,...) at vnode_pager_lock+0x1e0 vm_fault(c456a000,80db000,2,8,80db2e0,...) at vm_fault+0x1df trap_pfault(5,0,c0c0c998,2e7,c4564d0c,...) at trap_pfault+0x118 trap(c41bbd38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 136 files 34 WARNING: /var was not properly dismounted fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 em0: link state changed to UP drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 2 usecs drm0: [ITHREAD] lock order reversal: 1st 0xc5a9b488 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:424 2nd 0xd85df670 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc49c19c4 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:545 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c45242b8,e6dc0468,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb62,c49c19c4,c0bd05f5,c45242b8,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c49c19c4,9,c0bf92b3,221,0,...) at witness_checkorder+0x839 __lockmgr_args(c49c19c4,80100,c49c19e0,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6dc0578,c0e66518,c4a54524,80100,c49c196c,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6dc0578,e6dc0598,c0cf2680,c49c196c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c49c196c,80100,c0bf92b3,221,c4551200,...) at _vn_lock+0x5e ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot+0x1527 ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount+0x146f vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at vfs_donmount+0x1312 nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- lock order reversal: 1st 0xd85df670 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc5a99cdc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:794 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c4524a70,e6dc0468,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5a99cdc,c0bf9315,c4524a70,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c5a99cdc,9,c0bf92b3,31a,c5a9b4a4,...) at witness_checkorder+0x839 __lockmgr_args(c5a99cdc,80400,c5a9b4a4,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6dc0578,0,0,80400,c5a9b430,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6dc0578,c1979284,c0cf2680,c5a9b430,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5a9b430,80400,c0bf92b3,31a,0,...) at _vn_lock+0x5e ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot+0x28c6 ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount+0x146f vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at vfs_donmount+0x1312 nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- lock order reversal: 1st 0xc5a99cdc snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:293 2nd 0xc5a9b488 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1588 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6dc08c4,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c4524a70,c45242b8,e6dc0920,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5a9b488,c0bd05f5,c45242b8,c0bf92b3,...) at _witness_debugger+0x25 witness_checkorder(c5a9b488,9,c0bf92b3,634,0,...) at witness_checkorder+0x839 __lockmgr_args(c5a9b488,80000,0,0,0,...) at __lockmgr_args+0x797 ffs_snapremove(c5a9b430,c49d7500,0,c0be4ac3,414,...) at ffs_snapremove+0x11f softdep_releasefile(c5a9d690,e6dc0aa8,2,c0e664e8,c0cc1b64,...) at softdep_releasefile+0x3b ufs_inactive(e6dc0ae8,c5a9b4a4,c5a9b430,c5a9b4a4,e6dc0b00,...) at ufs_inactive+0x1bc VOP_INACTIVE_APV(c0cde5a0,e6dc0ae8,c0be38fd,914,c0cf2640,...) at VOP_INACTIVE_APV+0xa5 vinactive(c0cde5a0,e6dc0b1c,c0be38fd,8a0,128,...) at vinactive+0x8e vput(c5a9b430,e6dc0b54,c0be4ac3,125,c0cf23c0,...) at vput+0x1db vn_close(c5a9b430,1,c456b400,c4a54480,e6dc0be0,...) at vn_close+0xee vn_closefile(c498e888,c4a54480,3,0,c498e888,...) at vn_closefile+0xe9 _fdrop(c498e888,c4a54480,e6dc0c1c,c0871a6c,0,c4a54524,c0e664e8,c0cc3370,c0bd2199,c576372c,44f,c0bd2199,e6dc0c44,c083a780,c576372c,8,c0bd2199,44f) at _fdrop+0x43 closef(c498e888,c4a54480,44f,434,c498e888,...) at closef+0x290 kern_close(c4a54480,4,e6dc0d2c,c0b29ec3,c4a54480,...) at kern_close+0x11d close(c4a54480,e6dc0cf8,4,c0bddf84,c0cbafd0,...) at close+0x1a syscall(e6dc0d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28184073, esp = 0xbfbfdb5c, ebp = 0xbfbfdb88 --- lock order reversal: 1st 0xd8539350 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc5b6e400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6e78a74,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c45216d8,c4524320,e6e78ad0,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5b6e400,c0bfb766,c4524320,c0bfb3ff,...) at _witness_debugger+0x25 witness_checkorder(c5b6e400,9,c0bfb3ff,107,0,...) at witness_checkorder+0x839 _sx_xlock(c5b6e400,0,c0bfb3ff,107,d9719018,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c4961800,d85392f0,d9719018,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c5bf9690,d9719018,18,e6e78b60,e6e78b5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c5d85218,c5e4d2d0,500800c,0,c5d85218,...) at ufs_dirremove+0xe5 ufs_remove(e6e78c30,e6e78c30,0,e6e78c30,c5e48000,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0cde5a0,e6e78c30,2,0,28216238,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c56eed80,ffffff9c,28216238,0,e6e78c80,...) at kern_unlinkat+0x187 kern_unlink(c56eed80,28216238,0,e6e78d2c,c0b29ec3,...) at kern_unlink+0x27 unlink(c56eed80,e6e78cf8,4,c0bf5f1c,c0cbb030,...) at unlink+0x22 syscall(e6e78d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815aa8f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6e8 --- lock order reversal: 1st 0xc579bb2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xc5ca5ce8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4065 KDB: stack backtrace: db_trace_self_wrapper(c0bd9ebe,e6d63a30,c0871c25,4,c0bd5436,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bd5436,c4521948,c45242b8,e6d63a8c,...) at kdb_backtrace+0x29 _witness_debugger(c0bdcb49,c5ca5ce8,c0bd05f5,c45242b8,c0be38fd,...) at _witness_debugger+0x25 witness_checkorder(c5ca5ce8,9,c0be38fd,fe1,c5ca5d04,...) at witness_checkorder+0x839 __lockmgr_args(c5ca5ce8,80400,c5ca5d04,0,0,...) at __lockmgr_args+0x797 ffs_lock(e6d63b9c,c,0,80400,c5ca5c90,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cde5a0,e6d63b9c,e6d63ba4,c0cf2680,c5ca5c90,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5ca5c90,80400,c0be38fd,fe1,e6d63bf8,...) at _vn_lock+0x5e vfs_knllock(c5ca5c90,0,c0bd26b1,68c,c4e2361c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e6d63c18,c08b6fe9,c5d1608c,c4e2361c,...) at knlist_remove_kq+0xad knlist_remove(c5d1608c,c4e2361c,0,e6d63c44,c0809d65,...) at knlist_remove+0x1b filt_vfsdetach(c4e2361c,0,c0bd26b1,75c,8,...) at filt_vfsdetach+0x39 knote_fdclose(c4998d80,8,c0bd2199,434,c57cfcb0,...) at knote_fdclose+0xf5 kern_close(c4998d80,8,e6d63d2c,c0b29ec3,c4998d80,...) at kern_close+0xd5 close(c4998d80,e6d63cf8,4,c0bdd36a,c0cbafd0,...) at close+0x1a syscall(e6d63d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x284c3073, esp = 0xbfbfe10c, ebp = 0xbfbfe128 --- info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 2 usecs drm0: [ITHREAD] hdac0: mem 0xee400000-0xee403fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20081123_0118 hdac0: [ITHREAD] hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec #1: Conexant (Unknown) pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 --=-dq2fxg1WGxjiHlNkDX3r-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 06:10:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DD9106566B for ; Thu, 22 Jan 2009 06:10:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id C62A08FC14 for ; Thu, 22 Jan 2009 06:10:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0M6AeC1083441; Wed, 21 Jan 2009 22:10:41 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <49780DDE.2090800@freebsd.org> Date: Wed, 21 Jan 2009 22:10:38 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: a134qaed@gmail.com References: <4965927D.1060507@freebsd.org> <4968EF7E.5040002@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Extattr portability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 06:10:42 -0000 a134qaed@gmail.com wrote: > On 1/10/09, Tim Kientzle wrote: >>Dylan Cochran wrote: >> >>Wonderful! Care to help test? > > Absolutely. First draft of this is available on Googlecode right now: http://libarchive.googlecode.com/ The FreeBSD support only archives/restores attributes in the user namespace right now. They get stored in the archive as PAX attributes with the name LIBARCHIVE.xattr.user. with the actual value base-64 encoded for portability. Non-ASCII characters in the name are encoded using URL-style %XX hex encoding. All attributes are always recorded when you create the archive; the extended attributes are only restored with the -p flag. I haven't tested this yet, but bsdtar should now be able to move user extended attributes between Linux and FreeBSD portably. I've started reading up on the MacOS extended attribute support but doubt I'll have time to try implementing the OS-specific parts of that. If anyone else wants to take a shot, it's a pretty well isolated piece of code that shouldn't take long at all to implement. The tedious part will be the testing. Ditto for Solaris. Tim From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 11:52:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127CA1065675 for ; Thu, 22 Jan 2009 11:52:12 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id D8EDE8FC19 for ; Thu, 22 Jan 2009 11:52:11 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id A87CA125422; Thu, 22 Jan 2009 20:33:34 +0900 (JST) Message-ID: <4978598E.80800@ongs.co.jp> Date: Thu, 22 Jan 2009 20:33:34 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: FreeBSD Current , Masanori OZAWA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: USB2: ugd round bug? including patch to solve. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 11:52:12 -0000 Hi USB2 folks ;-) First I should show you my big respect. Thank you very much for your great usb2 work. That works very well. Using usb2, I have found a issue around uhid. ugd will be zero-cleared when ioctl(fd, USB_GET_REPORT_DESC, &ugd) is called. For example, follow ioctl are used to get information of report descriptor. memset(&ugd, 0, sizeof(ugd)); ugd.ugd_data = malloc(len); ugd.ugd_maxlen = len; ioctl(fd, USB_GET_REPORT_DESC, &ugd) The information of report descriptor should be copied to ugd, but ugd is zero-cleared. From my research, perphaps follow patch is good solution to solve this problem. How do you usb2 guys make of this? Please check and solve this issue. Thanks :) --- sys/dev/usb2/include/usb2_ioctl.h.orig 2009-01-22 20:11:13.000000000 +0900 +++ sys/dev/usb2/include/usb2_ioctl.h 2009-01-22 20:09:35.000000000 +0900 @@ -223,7 +223,7 @@ #define USB_DEVICEENUMERATE _IOW ('U', 6, int) /* Generic HID device */ -#define USB_GET_REPORT_DESC _IOR ('U', 21, struct usb2_gen_descriptor) +#define USB_GET_REPORT_DESC _IOWR('U', 21, struct usb2_gen_descriptor) #define USB_SET_IMMED _IOW ('U', 22, int) #define USB_GET_REPORT _IOWR('U', 23, struct usb2_gen_descriptor) #define USB_SET_REPORT _IOW ('U', 24, struct usb2_gen_descriptor) -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 12:25:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2D6A106564A for ; Thu, 22 Jan 2009 12:25:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.tele2.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4314C8FC08 for ; Thu, 22 Jan 2009 12:25:24 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ZeQXTuWxVp8A:10 a=9SoDCewf83AA:10 a=6I5d2MoRAAAA:8 a=wFY8NPiWzHpwMhGTkKQA:9 a=_RFrpVCOhL5KX3PPFOAA:7 a=ElBhBl80HBhwSud5mx87V6s6y6cA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 438301621; Thu, 22 Jan 2009 13:25:23 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 22 Jan 2009 13:27:45 +0100 User-Agent: KMail/1.9.7 References: <4978598E.80800@ongs.co.jp> In-Reply-To: <4978598E.80800@ongs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901221327.47634.hselasky@c2i.net> Cc: Daichi GOTO , Masanori OZAWA Subject: Re: USB2: ugd round bug? including patch to solve. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 12:25:25 -0000 On Thursday 22 January 2009, Daichi GOTO wrote: > Hi USB2 folks ;-) > > First I should show you my big respect. Thank you very much for your > great usb2 work. That works very well. > > Using usb2, I have found a issue around uhid. ugd will be zero-cleared > when ioctl(fd, USB_GET_REPORT_DESC, &ugd) is called. > > For example, follow ioctl are used to get information of report descriptor. > > memset(&ugd, 0, sizeof(ugd)); > ugd.ugd_data = malloc(len); > ugd.ugd_maxlen = len; > > ioctl(fd, USB_GET_REPORT_DESC, &ugd) > > The information of report descriptor should be copied to ugd, but ugd is > zero-cleared. > > From my research, perphaps follow patch is good solution to solve this > problem. How do you usb2 guys make of this? Please check and solve > this issue. Thanks :) Hi Daichi! Your patch is absolutely correct! Committed to P4. Will reach -current early next week! http://perforce.freebsd.org/chv.cgi?CH=156515 Thanks for testing and finding bugs! --HPS > --- sys/dev/usb2/include/usb2_ioctl.h.orig 2009-01-22 > 20:11:13.000000000 +0900 +++ sys/dev/usb2/include/usb2_ioctl.h 2009-01-22 > 20:09:35.000000000 +0900 @@ -223,7 +223,7 @@ > #define USB_DEVICEENUMERATE _IOW ('U', 6, int) > > /* Generic HID device */ > -#define USB_GET_REPORT_DESC _IOR ('U', 21, struct > usb2_gen_descriptor) +#define USB_GET_REPORT_DESC _IOWR('U', 21, > struct usb2_gen_descriptor) #define USB_SET_IMMED _IOW > ('U', 22, int) > #define USB_GET_REPORT _IOWR('U', 23, struct > usb2_gen_descriptor) #define USB_SET_REPORT _IOW ('U', 24, > struct usb2_gen_descriptor) From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 12:46:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D2E1065695 for ; Thu, 22 Jan 2009 12:46:49 +0000 (UTC) (envelope-from gunnar@bsd-gf.sr.se) Received: from dart.sr.se (dart.SR.SE [134.25.0.132]) by mx1.freebsd.org (Postfix) with ESMTP id 84F128FC22 for ; Thu, 22 Jan 2009 12:46:47 +0000 (UTC) (envelope-from gunnar@bsd-gf.sr.se) Received: from honken.sr.se (honken.sr.se [134.25.128.27]) by dart.sr.se (8.14.2/8.14.2) with ESMTP id n0MCHpUD077714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Jan 2009 13:17:56 +0100 (CET) (envelope-from gunnar@bsd-gf.sr.se) Received: from bsd-gf.sr.se (bsd-gf.sr.se [134.25.191.27]) by honken.sr.se (8.14.2/8.14.2) with ESMTP id n0MCHpJJ029166 for ; Thu, 22 Jan 2009 13:17:51 +0100 (CET) (envelope-from gunnar@bsd-gf.sr.se) Received: from bsd-gf.sr.se (localhost [127.0.0.1]) by bsd-gf.sr.se (8.14.3/8.14.2) with ESMTP id n0MCHoud014676 for ; Thu, 22 Jan 2009 13:17:50 +0100 (CET) (envelope-from gunnar@bsd-gf.sr.se) Received: (from gunnar@localhost) by bsd-gf.sr.se (8.14.3/8.14.3/Submit) id n0MCHowg014675 for current@freebsd.org; Thu, 22 Jan 2009 13:17:50 +0100 (CET) (envelope-from gunnar) Date: Thu, 22 Jan 2009 13:17:50 +0100 From: Gunnar Flygt To: current@freebsd.org Message-ID: <20090122121750.GA14657@sr.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 22 Jan 2009 12:52:07 +0000 Cc: Subject: Backporting of Heimdal 1.1 to 7.* X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gunnar Flygt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 12:46:50 -0000 Is there any possibility that heimdal 1.1 that works beautifully in Current will be backported to FreeBSD-7.x? Please CC me since I'm only subscrbed to stable, not current. Gunnar Flygt Sveriges Radio Teknik/IT From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 13:02:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E3310656F8 for ; Thu, 22 Jan 2009 13:02:33 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 47D558FC17 for ; Thu, 22 Jan 2009 13:02:33 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 6BBED125422; Thu, 22 Jan 2009 22:02:32 +0900 (JST) Message-ID: <49786E68.3030306@ongs.co.jp> Date: Thu, 22 Jan 2009 22:02:32 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky References: <4978598E.80800@ongs.co.jp> <200901221327.47634.hselasky@c2i.net> In-Reply-To: <200901221327.47634.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Masanori OZAWA Subject: Re: USB2: ugd round bug? including patch to solve. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 13:02:35 -0000 Hi HPS, Cool! thanks for your fastest check! I'm looking forward to current merging time ;) Hans Petter Selasky wrote: > On Thursday 22 January 2009, Daichi GOTO wrote: >> Hi USB2 folks ;-) >> >> First I should show you my big respect. Thank you very much for your >> great usb2 work. That works very well. >> >> Using usb2, I have found a issue around uhid. ugd will be zero-cleared >> when ioctl(fd, USB_GET_REPORT_DESC, &ugd) is called. >> >> For example, follow ioctl are used to get information of report descriptor. >> >> memset(&ugd, 0, sizeof(ugd)); >> ugd.ugd_data = malloc(len); >> ugd.ugd_maxlen = len; >> >> ioctl(fd, USB_GET_REPORT_DESC, &ugd) >> >> The information of report descriptor should be copied to ugd, but ugd is >> zero-cleared. >> >> From my research, perphaps follow patch is good solution to solve this >> problem. How do you usb2 guys make of this? Please check and solve >> this issue. Thanks :) > > Hi Daichi! > > Your patch is absolutely correct! Committed to P4. Will reach -current early > next week! > > http://perforce.freebsd.org/chv.cgi?CH=156515 > > Thanks for testing and finding bugs! > > --HPS > >> --- sys/dev/usb2/include/usb2_ioctl.h.orig 2009-01-22 >> 20:11:13.000000000 +0900 +++ sys/dev/usb2/include/usb2_ioctl.h 2009-01-22 >> 20:09:35.000000000 +0900 @@ -223,7 +223,7 @@ >> #define USB_DEVICEENUMERATE _IOW ('U', 6, int) >> >> /* Generic HID device */ >> -#define USB_GET_REPORT_DESC _IOR ('U', 21, struct >> usb2_gen_descriptor) +#define USB_GET_REPORT_DESC _IOWR('U', 21, >> struct usb2_gen_descriptor) #define USB_SET_IMMED _IOW >> ('U', 22, int) >> #define USB_GET_REPORT _IOWR('U', 23, struct >> usb2_gen_descriptor) #define USB_SET_REPORT _IOW ('U', 24, >> struct usb2_gen_descriptor) > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 13:19:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C78D106566C for ; Thu, 22 Jan 2009 13:19:48 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 03F958FC19 for ; Thu, 22 Jan 2009 13:19:47 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from localhost (people [192.168.2.4]) by people.fsn.hu (Postfix) with SMTP id 6863412A326 for ; Thu, 22 Jan 2009 14:19:45 +0100 (CET) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 232AD12A321; Thu, 22 Jan 2009 14:19:43 +0100 (CET) Message-ID: <4978726E.9050001@fsn.hu> Date: Thu, 22 Jan 2009 14:19:42 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Gavin Atkinson References: <496B115F.1000105@fsn.hu> <4970BB63.7030601@andric.com> <4970E8C0.1080005@FreeBSD.org> <49720DFE.3080808@fsn.hu> <20090118164930.R24894@ury.york.ac.uk> In-Reply-To: <20090118164930.R24894@ury.york.ac.uk> X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 22 Jan 2009 14:19:43 +0100 (CET) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jan 22 14:19:45 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 49787271607581081318544 Cc: Maxim Sobolev , Dimitry Andric , freebsd-current@FreeBSD.org Subject: Re: FreeBSD panics with 64GiB of RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 13:19:48 -0000 Gavin Atkinson wrote: > On Sat, 17 Jan 2009, Attila Nagy wrote: > >> Hello, >> >> I've already tried something similar. The effect of the patch is this: >> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png >> >> >> BTW, this: >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-bootonly.iso >> >> boots up fine (to sysinstall). >> I haven't installed FreeBSD for years (I'm using netboot), is this i386? >> That could explain the situation. > > I'm confused. That link is a snapshot of amd64 -CURRENT from > December. The first email in this thread said you were trying -CURRENT > anmd64 and it wasn't working. > > So, which ones work and which don't? Are we looking at a regression > since December or has this been fixed between whatever image you first > tested and the December snapshot? > The saga continues. With: *default release=cvs tag=. *default date=2008.03.07.00.00.00 the machine gets over the pxeboot and loads kernel, then panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png With: *default date=2008.04.12.00.00.00 it freezes in this stage: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png 03.11 gave a stackdump loop (BTX halted, register states scrolling endlessly), earlier ones can boot but crash with "kernel trap 12 with interrupts disabled" (see above). Any chance for somebody to look into this issue? From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 13:31:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EEB9106564A; Thu, 22 Jan 2009 13:31:52 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3C58FC16; Thu, 22 Jan 2009 13:31:50 +0000 (UTC) (envelope-from bra@fsn.hu) Received: by people.fsn.hu (Postfix, from userid 125) id 5405112A53D; Thu, 22 Jan 2009 14:29:41 +0100 (CET) Received: from [172.27.51.1] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 4BA78120F12; Sun, 18 Jan 2009 22:17:49 +0100 (CET) Message-ID: <49739C7C.10700@fsn.hu> Date: Sun, 18 Jan 2009 22:17:48 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Gavin Atkinson References: <496B115F.1000105@fsn.hu> <4970BB63.7030601@andric.com> <4970E8C0.1080005@FreeBSD.org> <49720DFE.3080808@fsn.hu> <20090118164930.R24894@ury.york.ac.uk> In-Reply-To: <20090118164930.R24894@ury.york.ac.uk> X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Sun, 18 Jan 2009 22:17:49 +0100 (CET) Cc: Maxim Sobolev , Dimitry Andric , freebsd-current@FreeBSD.org Subject: Re: FreeBSD panics with 64GiB of RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 13:31:52 -0000 Gavin Atkinson wrote: > On Sat, 17 Jan 2009, Attila Nagy wrote: > >> Hello, >> >> I've already tried something similar. The effect of the patch is this: >> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png >> >> >> BTW, this: >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-bootonly.iso >> >> boots up fine (to sysinstall). >> I haven't installed FreeBSD for years (I'm using netboot), is this i386? >> That could explain the situation. > > I'm confused. That link is a snapshot of amd64 -CURRENT from > December. The first email in this thread said you were trying -CURRENT > anmd64 and it wasn't working. > > So, which ones work and which don't? Are we looking at a regression > since December or has this been fixed between whatever image you first > tested and the December snapshot? The screenshots were made with an up to date (at that point of course) 8-CURRENT. But I've tried to boot with the snapshot ISO, which boots fine. Summary: - the original problem: with a fresh pxeloader, the machine halts at this point: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png - 8-CURRENT, booting with an older pxeloader panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-55.png - the 640kB patch panics with this (8-CURRENT, older pxeloader): http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png - with safe mode, I get this (8-CURRENT, older pxeloader, apparently no NICs recognized): http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-78-safemode.png - the December snapshot ISO with CD-ROM redirection boots fine, and it seems the SMAP is OK too: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-78-fbsd8-amd64-livefs.png According to these, I think my problem is the pxeloader's inability to boot on this machine. An older one can't boot because of the memory-related difference, a newer one can not boot because of another changes, happening in-between. Somebody please help. :) I don't know if there is a version, which can get to the loader prompt AND initialize what need to be initialized correctly to overcome the SMAP-panic. From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 13:32:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD37D106566C; Thu, 22 Jan 2009 13:32:19 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 91CE38FC22; Thu, 22 Jan 2009 13:32:18 +0000 (UTC) (envelope-from bra@fsn.hu) Received: by people.fsn.hu (Postfix, from userid 125) id DB4F312A677; Thu, 22 Jan 2009 14:59:03 +0100 (CET) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 46B67119A06; Tue, 20 Jan 2009 17:24:02 +0100 (CET) Message-ID: <4975FAA2.7050203@fsn.hu> Date: Tue, 20 Jan 2009 17:24:02 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Gavin Atkinson References: <496B115F.1000105@fsn.hu> <4970BB63.7030601@andric.com> <4970E8C0.1080005@FreeBSD.org> <49720DFE.3080808@fsn.hu> <20090118164930.R24894@ury.york.ac.uk> In-Reply-To: <20090118164930.R24894@ury.york.ac.uk> X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Tue, 20 Jan 2009 17:24:03 +0100 (CET) Cc: Maxim Sobolev , Dimitry Andric , freebsd-current@FreeBSD.org Subject: Re: FreeBSD panics with 64GiB of RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 13:32:20 -0000 Gavin Atkinson wrote: > On Sat, 17 Jan 2009, Attila Nagy wrote: > >> Hello, >> >> I've already tried something similar. The effect of the patch is this: >> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png >> >> >> BTW, this: >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-bootonly.iso >> >> boots up fine (to sysinstall). >> I haven't installed FreeBSD for years (I'm using netboot), is this i386? >> That could explain the situation. > > I'm confused. That link is a snapshot of amd64 -CURRENT from > December. The first email in this thread said you were trying -CURRENT > anmd64 and it wasn't working. > > So, which ones work and which don't? Are we looking at a regression > since December or has this been fixed between whatever image you first > tested and the December snapshot? > The saga continues. With: *default release=cvs tag=. *default date=2008.03.07.00.00.00 the machine gets over the pxeboot and loads kernel, then panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-70.png With: *default date=2008.04.12.00.00.00 it freezes in this stage: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png 03.11 gave a stackdump loop (BTX halted, register states scrolling endlessly), earlier ones can boot but crash with "kernel trap 12 with interrupts disabled" (see above). Any chance for somebody to look into this issue? From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 14:40:00 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3383D106564A for ; Thu, 22 Jan 2009 14:40:00 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 93E918FC18 for ; Thu, 22 Jan 2009 14:39:58 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from localhost (people [192.168.2.4]) by people.fsn.hu (Postfix) with SMTP id ABACB12AB42 for ; Thu, 22 Jan 2009 15:39:56 +0100 (CET) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 585D812AB3F for ; Thu, 22 Jan 2009 15:39:55 +0100 (CET) Message-ID: <4978853A.2000107@fsn.hu> Date: Thu, 22 Jan 2009 15:39:54 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 22 Jan 2009 15:39:55 +0100 (CET) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jan 22 15:39:56 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4978853c607582036610207 Cc: Subject: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 14:40:00 -0000 Hello, In /etc/rc.initdiskless there is a function, which creates memory disks in diskless environments: # Create a generic memory disk # mount_md() { /sbin/mdmfs -S -i 4096 -s $1 -M md $2 } I have a lot of remote booted diskless and "with disks" machines, which rely on this kind of storage. The problem is that the above command specifies "-M", so it will create MD_MALLOC disks, which can't be swapped out, so it constantly takes away RAM, even if there is only a lightly used dataset on the storage, which could be in swap too in cases, when there is a memory pressure on the system. So the question is: what is the rationale behind creating malloc backed disks by default, instead of swap-backed ones? I can only think of two: - MD_SWAP disks cannot be created, if NO_SWAPPING is enabled in the kernel (I haven't checked, if the swap code is enabled (default) and there is no swap, I can create swap based disks, like malloc based ones) - under memory pressure, the swap based disks will be slow, so maybe it's not a goot idea to put /etc (in netbooted environment, this is by default on memory disks) onto it. BTW, I don't see the difference here between a netbooted machine, having /etc on a swap backed memory disk, which also holds swap and a locally booted machine, having /etc on a disk, which also holds swap. (of course there is a difference, if the swap is on another disk(s) So, are there any objections on changing /sbin/mdmfs -S -i 4096 -s $1 -M md $2 to /sbin/mdmfs -S -i 4096 -s $1 md $2 ? From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:21:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 661EE1065670 for ; Thu, 22 Jan 2009 15:21:55 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id EEAED8FC18 for ; Thu, 22 Jan 2009 15:21:54 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0MFLlnb028471; Thu, 22 Jan 2009 15:21:47 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LQ1NK-00014z-RC; Thu, 22 Jan 2009 15:21:46 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n0MFLktf045958; Thu, 22 Jan 2009 15:21:46 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n0MFLkTZ045954; Thu, 22 Jan 2009 15:21:46 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: mister.olli@googlemail.com In-Reply-To: <1232565243.5225.31.camel@phoenix.blechhirn.net> References: <1232565243.5225.31.camel@phoenix.blechhirn.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Jan 2009 15:21:45 +0000 Message-Id: <1232637705.16898.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:21:56 -0000 On Wed, 2009-01-21 at 20:14 +0100, Mister Olli wrote: > Hi.. > > I'm currently trying to setup FreeBSD 8-CURRENT as a para-virtualized > domU on XEN 3.3.0 (with gentoo dom0). > > When I configure 2 CPU's (using vcpus=2) in the domU config file, I get > the following error during bootup: > ========================================================================== > virt-001 template_8-CURRENT # xm create -c 00_template_8-CURRENT.XENconfig > Using config file "./00_template_8-CURRENT.XENconfig". > Started domain template_8-CURRENT > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0: Wed Jan 14 21:47:10 CET 2009 > root@template-8_CURRENT.localdomain:/usr/obj/usr/src/sys/freebsd8_XEN > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 1600.056 MHz processor. > Timecounter "ixen" frequency 1000000000 Hz quality 0 > CPU: AMD Athlon(tm) Processor (1600.06-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 > Features=0x383fbff > AMD Features=0xc0480800 > real memory = 268435456 (256 MB) > avail memory = 256045056 (244 MB) > gdtpfn=3e2d8 pdptpfn=28a43 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu=0 irq=0 vector=0 > cpu=0 irq=0 vector=1 > cpu=1 irq=0 vector=0 > cpu=1 irq=0 vector=1 > kbd0 at kbdmux0 > xenbus0: on motherboard > xc0: on motherboard > Timecounters tick every 100.000 msec > xbd0: 5120MB at device/vbd/768 on xenbus0 > xbd0: attaching as ad0 > xn0: at device/vif/0 on xenbus0 > xn0: Ethernet address: 00:16:3e:11:4d:c4 > GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). > [XEN] netfront_backend_changed: newstate=2 > [XEN] netfront_backend_changed: newstate=4 > Spanic: blockable sleep lock (sleep mutex) XCONS LOCK @ /usr/src/sys/dev/xen/console/console.c:290 > cpuid = 1 > KDB: enter: panic > [thread pid 11 tid 100003 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> At this point, can you enter the following commands and show the result? bt show alllocks Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:22:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D5C1065701 for ; Thu, 22 Jan 2009 15:22:07 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2337B8FC1C for ; Thu, 22 Jan 2009 15:22:06 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from localhost (people [192.168.2.4]) by people.fsn.hu (Postfix) with SMTP id F332712AC95 for ; Thu, 22 Jan 2009 16:22:03 +0100 (CET) Received: from [172.16.129.134] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 5BFB712AC8C; Thu, 22 Jan 2009 16:22:03 +0100 (CET) Message-ID: <49788F1B.7000600@fsn.hu> Date: Thu, 22 Jan 2009 16:22:03 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Igor Mozolevsky References: <4978853A.2000107@fsn.hu> In-Reply-To: X-Stationery: 0.4.8.12 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Thu, 22 Jan 2009 16:22:03 +0100 (CET) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 22 16:22:03 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 49788f1b607582032818152 Cc: freebsd-current@freebsd.org Subject: Re: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:22:08 -0000 Igor Mozolevsky wrote: > 2009/1/22 Attila Nagy : > > [snip] > > >> So the question is: what is the rationale behind creating malloc backed >> disks by default, instead of swap-backed ones? >> > > Yes --- booting from DoC/CDROM/PXE with no HDD on the node... > Did you read my e-mail? px# geom disk list px# swapinfo Device 1K-blocks Used Avail Capacity px# /sbin/mdmfs -S -i 4096 -s 32m md /tmp/a px# mdconfig -lv md0 malloc 9.8M md1 malloc 34M md2 swap 20M md3 swap 32M From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:29:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C533106564A for ; Thu, 22 Jan 2009 15:29:57 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by mx1.freebsd.org (Postfix) with ESMTP id 30B258FC18 for ; Thu, 22 Jan 2009 15:29:56 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ewy13 with SMTP id 13so3167362ewy.19 for ; Thu, 22 Jan 2009 07:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=UZUrVNANuCpaW2pVgftVVbgApDd2g1pkmzPFylKjI7M=; b=x308nP+k5vczahyizOEZcPAkssB1LFdUBq+SvZgAiy8lVt/+0yk0R1koMLET/AdGUG Y+fEmrbB1EWPNuUAgd7nr+/l+NN0oVZ1wplAa6nfO9S9hR0bpQfQuEz7Rp4cSVsc5Pa0 X68WZeNwx6vmtOFQG91J4zEn66pMlI9MqBFfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X0sGj5rReDscupBqui4YPIk8LgeA0oiVbVLThcLlEu7YE5R0A+P5KKHpEr1aeYEZgv pdiRkeI3M58Yl9EAf/2UbVl5EpwFYB5JII2r9GvzgwDMh8wDgL6tJ39E3fd32zr91Cfc 9bGfyayIKmqY79M3+XLvF7hyRxgFx/rpUKlwo= MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.223.109.148 with SMTP id j20mr1680735fap.43.1232636730190; Thu, 22 Jan 2009 07:05:30 -0800 (PST) In-Reply-To: <4978853A.2000107@fsn.hu> References: <4978853A.2000107@fsn.hu> Date: Thu, 22 Jan 2009 15:05:30 +0000 X-Google-Sender-Auth: ebd0c29533cbf88f Message-ID: From: Igor Mozolevsky To: Attila Nagy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:29:57 -0000 2009/1/22 Attila Nagy : [snip] > So the question is: what is the rationale behind creating malloc backed > disks by default, instead of swap-backed ones? Yes --- booting from DoC/CDROM/PXE with no HDD on the node... Cheers, Igor :-) From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:36:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F345E10656DD; Thu, 22 Jan 2009 15:36:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 60F948FC2B; Thu, 22 Jan 2009 15:36:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=6I5d2MoRAAAA:8 a=BDwaAj4jZNtyhgjvPwUA:9 a=hxg3tgWPZI9e5rilUGUA:7 a=1uQOfrYE2kg-FkgOc1ETOYUAWmoA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1011901703; Thu, 22 Jan 2009 16:21:49 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 22 Jan 2009 16:24:12 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> In-Reply-To: <1421.1232314073@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901221624.13536.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:36:51 -0000 Hi, Try these patches on a clean -current. Tested with a similar device of yours! http://perforce.freebsd.org/chv.cgi?CH=156521 http://perforce.freebsd.org/chv.cgi?CH=156522 --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:36:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F345E10656DD; Thu, 22 Jan 2009 15:36:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 60F948FC2B; Thu, 22 Jan 2009 15:36:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=6I5d2MoRAAAA:8 a=BDwaAj4jZNtyhgjvPwUA:9 a=hxg3tgWPZI9e5rilUGUA:7 a=1uQOfrYE2kg-FkgOc1ETOYUAWmoA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1011901703; Thu, 22 Jan 2009 16:21:49 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 22 Jan 2009 16:24:12 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> In-Reply-To: <1421.1232314073@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901221624.13536.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:36:51 -0000 Hi, Try these patches on a clean -current. Tested with a similar device of yours! http://perforce.freebsd.org/chv.cgi?CH=156521 http://perforce.freebsd.org/chv.cgi?CH=156522 --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:42:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 381871065672 for ; Thu, 22 Jan 2009 15:42:35 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id BD37E8FC12 for ; Thu, 22 Jan 2009 15:42:34 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2667596fgb.35 for ; Thu, 22 Jan 2009 07:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=x1ZUTz/Rwwz4eq9/B5RpvfJZCT7gKNvuNNXXQ5PRf4A=; b=sDkut1h9tKh0fiK+30yVziqUrBH11AZIX1x7YlcgP+bEz/+y0G1b11Z/1uT89C+KZb 5COIXoBZeUxyg1r5NGDwsKBSxjt/D6OKf7fD5Hsn7TWEdFtAW7FarWOLiedOww976rGw IFSD6E3Nrx7cRfQbVFznlJiWFDvczVYjwks5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IvO9+b9UEA5FD++Q+8AA8XXSRqk4cgW2Cb5KqhH1xFeZ6AiYa22Fdgg2R6jUZ7RqkC 8Uag2KgAUHqa9HQserl45GPhID0NW6fOIe4Bcbly/whEwOa4GiayxDPobrdEhVbbAxLe DjMYf8yr6U/UbubzpdltQ/o84ZvDnjfgO5mdI= MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.223.112.83 with SMTP id v19mr770101fap.66.1232638953742; Thu, 22 Jan 2009 07:42:33 -0800 (PST) In-Reply-To: <49788F1B.7000600@fsn.hu> References: <4978853A.2000107@fsn.hu> <49788F1B.7000600@fsn.hu> Date: Thu, 22 Jan 2009 15:42:33 +0000 X-Google-Sender-Auth: 4c443c33d8a1a589 Message-ID: From: Igor Mozolevsky To: Attila Nagy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:42:35 -0000 2009/1/22 Attila Nagy : > Igor Mozolevsky wrote: >> >> 2009/1/22 Attila Nagy : >> >> [snip] >> >> >>> >>> So the question is: what is the rationale behind creating malloc backed >>> disks by default, instead of swap-backed ones? >>> >> >> Yes --- booting from DoC/CDROM/PXE with no HDD on the node... >> > > Did you read my e-mail? Yes, but why would you have swap enabled in the kernel on a system that cannot possibly swap? Cheers, Igor :-) From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:24:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BB79106564A for ; Thu, 22 Jan 2009 16:24:43 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id E3B638FC17 for ; Thu, 22 Jan 2009 16:24:42 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n0MGOdHj001051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jan 2009 17:24:41 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <49789DC7.1050300@boland.org> Date: Thu, 22 Jan 2009 17:24:39 +0100 From: Michiel Boland User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: panic on boot with today's kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:24:43 -0000 Hi. I'm getting panic on boot with latest kernel (GENERIC) HW is Dell OptiPlex 745 (i386) I can get more info if needed. panic: mutex ppc0 not owned at /usr/src/sys/dev/ppc/ppc.c:1983 cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 100000 td 0xc0d3d230 kdb_enter(c0bec4be,c0bec4be,c0beacc3,c142095c,0,...) at kdb_enter+0x3a panic(c0beacc3,c5759370,c0bd3582,7bf,c1420984,...) at panic+0x136 _mtx_assert(c5732a7c,4,c0bd3582,7bf,c56d4800,...) at _mtx_assert+0x87 ppc_write_ivar(c56d4800,c5743180,2,c06fd070,ffffffff,...) at ppc_write_ivar+0x42 ppbus_attach(c5743180,c55fd054,c0cd0dc8,c0beeeb3,80000000,...) at ppbus_attach+0x148 device_attach(c5743180,4,c0beee3c,969) at device_attach+0x36f device_probe_and_attach(c5743180,c0bd34f5,ffffffff,0,c06ff850,...) at device_probe_and_attach+0x4e ppc_attach(c56d4800,c0cd0dc8,c56d484c,c1420b84,c56ab480,...) at ppc_attach+0x143 ppc_isa_attach(c56d4800,c55fb854,c0cd0dc8,c0beeeb3,80000000,...) at ppc_isa_attach+0x7f device_attach(c56d4800,4,c0beee3c,969) at device_attach+0x36f device_probe_and_attach(c56d4800,affe,c1420c64,c04cf896,c56ab480,...) at device_probe_and_attach+0x4e bus_generic_attach(c56ab480,af00,affe,c56bda68,af00,...) at bus_generic_attach+0x19 acpi_attach(c56ab480,c5643854,c0cd0dc8,c0beeeb3,80000000,...) at acpi_attach+0xba6 device_attach(c56ab480,4,c0beee3c,969) at device_attach+0x36f device_probe_and_attach(c56ab480,c56aba00,c1420cf0,c0b16e7e,c56aba00,...) at device_probe_and_attach+0x4e bus_generic_attach(c56aba00,a,c0b9fcf6,0) at bus_generic_attach+0x19 nexus_acpi_attach(c56aba00,c5674054,c0cd0dc8,c0beeeb3,80000000,...) at nexus_acpi_attach+0x7e device_attach(c56aba00,4,c0beee3c,969) at device_attach+0x36f device_probe_and_attach(c56aba00,c552627c,c1420d6c,c0b1bdfc,c0d51bd0,...) at device_probe_and_attach+0x4e From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:28:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1331065688 for ; Thu, 22 Jan 2009 16:28:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 410D38FC1D for ; Thu, 22 Jan 2009 16:28:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:1910:dd32:a724:3707] (unknown [IPv6:2001:7b8:3a7:0:1910:dd32:a724:3707]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5ACD311F859; Thu, 22 Jan 2009 17:28:42 +0100 (CET) Message-ID: <49789EBC.1050401@andric.com> Date: Thu, 22 Jan 2009 17:28:44 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre MIME-Version: 1.0 To: Michiel Boland References: <49789DC7.1050300@boland.org> In-Reply-To: <49789DC7.1050300@boland.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic on boot with today's kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:28:44 -0000 On 2009-01-22 17:24, Michiel Boland wrote: > panic: mutex ppc0 not owned at /usr/src/sys/dev/ppc/ppc.c:1983 ... > _mtx_assert(c5732a7c,4,c0bd3582,7bf,c56d4800,...) at _mtx_assert+0x87 > ppc_write_ivar(c56d4800,c5743180,2,c06fd070,ffffffff,...) at ppc_write_ivar+0x42 > ppbus_attach(c5743180,c55fd054,c0cd0dc8,c0beeeb3,80000000,...) at ppbus_attach+0x148 Please try jhb's fix from here: http://docs.freebsd.org/cgi/mid.cgi?200901221016.58349.jhb From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:40:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A877106566C for ; Thu, 22 Jan 2009 16:40:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id B25F38FC19 for ; Thu, 22 Jan 2009 16:40:57 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n0MGdf4t012932; Thu, 22 Jan 2009 10:39:41 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n0MGdei3012931; Thu, 22 Jan 2009 10:39:40 -0600 (CST) (envelope-from brooks) Date: Thu, 22 Jan 2009 10:39:40 -0600 From: Brooks Davis To: Attila Nagy Message-ID: <20090122163940.GA12490@lor.one-eyed-alien.net> References: <4978853A.2000107@fsn.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <4978853A.2000107@fsn.hu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 22 Jan 2009 10:39:41 -0600 (CST) Cc: freebsd-current@freebsd.org Subject: Re: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:40:58 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 22, 2009 at 03:39:54PM +0100, Attila Nagy wrote: > Hello, >=20 > In /etc/rc.initdiskless there is a function, which creates memory disks i= n=20 > diskless environments: > # Create a generic memory disk > # > mount_md() { > /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > } >=20 > I have a lot of remote booted diskless and "with disks" machines, which= =20 > rely on this kind of storage. The problem is that the above command=20 > specifies "-M", so it will create MD_MALLOC disks, which can't be swapped= =20 > out, so it constantly takes away RAM, even if there is only a lightly use= d=20 > dataset on the storage, which could be in swap too in cases, when there i= s=20 > a memory pressure on the system. >=20 > So the question is: what is the rationale behind creating malloc backed= =20 > disks by default, instead of swap-backed ones? > I can only think of two: > - MD_SWAP disks cannot be created, if NO_SWAPPING is enabled in the kerne= l=20 > (I haven't checked, if the swap code is enabled (default) and there is no= =20 > swap, I can create swap based disks, like malloc based ones) > - under memory pressure, the swap based disks will be slow, so maybe it's= =20 > not a goot idea to put /etc (in netbooted environment, this is by default= =20 > on memory disks) onto it. BTW, I don't see the difference here between a= =20 > netbooted machine, having /etc on a swap backed memory disk, which also= =20 > holds swap and a locally booted machine, having /etc on a disk, which als= o=20 > holds swap. (of course there is a difference, if the swap is on another= =20 > disk(s) >=20 > So, are there any objections on changing > /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > to > /sbin/mdmfs -S -i 4096 -s $1 md $2 >=20 > ? It's a historical artifact rooted in the misleading name of the swap-backed type. I'm having a hard time imagining a case were it makes any differece and you'd actually use the script, but we should generally use swap backed mds. -- Brooks --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJeKFMXY6L6fI4GtQRApRFAJ9KVXQvANJrr7RrQ4UmNRikGc4PHACgsy8G 4qZyB8qFTDGRQIn+gAs3CmE= =vOVi -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:48:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 159631065670 for ; Thu, 22 Jan 2009 16:48:17 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id D889E8FC17 for ; Thu, 22 Jan 2009 16:48:16 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4354271rvf.43 for ; Thu, 22 Jan 2009 08:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tkoQJmHi5vCjzcOaLK7nz8Gd7hTV3QmVpvizSDfTDek=; b=AzfDvtag7ZVSa5J/QUK48QNU7r3McNC7BulFuneaBF83K4rxjR3UaL9NI5kQ46gqCm j1wtL9AmecfksHa6Jd5tPemPwNfccunAzPkxehH5ff5/Jv8CgbF38lnVg5eGhvTZnfFl MtnvV4cEy3VnLbI20J6O4xs+OalXAanHpdOkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B5YwcyHBPA79kWQ5Jr8M5iv876SNkLfvL+Ixf9ycJqJ7NYULoUpGaKskgdBcxBnhjO EWfWNZilixt+eicaxaqXgkyohXcOgGu+i2dn0O0UCOV1Mj8YaudW6nbf+cm1He0ydUW/ W4nIaxD/pSF6F9KmYMn1Da+D6/mXW3QXXiLbU= MIME-Version: 1.0 Received: by 10.140.136.5 with SMTP id j5mr818922rvd.167.1232642896566; Thu, 22 Jan 2009 08:48:16 -0800 (PST) In-Reply-To: <1232637705.16898.3.camel@buffy.york.ac.uk> References: <1232565243.5225.31.camel@phoenix.blechhirn.net> <1232637705.16898.3.camel@buffy.york.ac.uk> Date: Thu, 22 Jan 2009 19:48:16 +0300 Message-ID: <3cb459ed0901220848k6978c1d9j1f5b5720c2419ee1@mail.gmail.com> From: Alexander Churanov To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, mister.olli@googlemail.com Subject: Re: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:48:17 -0000 2009/1/22 Gavin Atkinson > > At this point, can you enter the following commands and show the result? > > bt > show alllocks > > Thanks, > > Gavin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Gavin, I've just built the latest kernel and have the same issue. The machine is a VmWare 2-CPU box, running on host with Intel Core2 CPU. Here are the logs: le1: port Bxl4ee-Bxl47f irq 18 at device 17.0 on pciB le1: 16 receive buffers, 4 transMit buffers le1: Ethernet address: 88:8c:29:dl:14:96 le1: [ITHRERD] acpi_acad8: on acpiB atrtc8: port 8x78-8x71 irq 8 on acpiB atkbdcB: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd8 at atkbdB atkbdB: [GIRNT-LBCKEDl atkbdB: [ITHRERD] psMB: irq 12 on atkbdcB psMB: [GIRNT-LBCKEDl psM0: [ITHRERD] psM0: Model IntelliMouse, device ID 3 ppcB: port 8x378-8x37f irq 7 on acpiB ppcB: Generic chipset (NIDDLE-only) in CBMPRTIDLE Mode ppcB: [ITHRERD] ppbusB: on ppcB panic: Mutex ppcB not ouned at /usr/src/sys/dev/ppc/ppc.c:1983 cpuid = 8 HDD: enter: panic [thread pid 8 tid 188888 ] Stopped at kdb_enter+8x3a: movI $8,kdb_why db> bt ppbus_attach(c2a7a38B,c29b8B54,cBcdl6c8,c8bef7bd,88888888,.. ) at ppbus_attach+8xl48 device_attach(c2a7a388,4,c8bef746,969) at device_attach+8x36f device_probe_and_attach(c2a7a388,c8bd3el5,ffffffff,8,c86ff858,...) at device_probe_and_attach+8x4e ppc_attach(c2a67188,c8cdl6c8,c2a671cc,cl42Bb84,c2a674BB,...) at ppc_attach+8xl43 Ppc_isa_attach(c2a67188,c29c4854,c8cdl6c8,c8bef7bd,88888888,...) at ppc_isa_attach*8x7f device_attach(c2a6718B,4,cBbef746,969) at device_attach+8x36f device_probe_and_attach(c2a67188,184f,cl428c64,cB4cf896,c2a67488,...) at device. probe_and_attach+8x4e bus_generic_attach(c2a67488,184B,lB4f,c2a78a28,1B4B,...) at bus_gener ic_attach+8xl9 acpi_attach(c2a67468,c2a84854,c8cdl6c8,c8bef7bd,88888888,...) at acpi_attach+0xba6 device_attach(c2a67488,4,c8bef746,969) at device_attach+8x36f device_probe_and_attach(c2a67488,c2a67988,cl428cf8,c8bl728e,c2a67988,...) at device_probe_and_attach+6x4e bus_generic_attach(c2a67988,a,c8baB616,B) at bus_generic_attach+8xl9 nexus_acpi_attach(c2a67988,c2a2c854,c8cdl6c8,c8bef?bd,88886888,...) at nexus_acpi_attach+8x7e device_attach(c2a67988,4,c8bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67988,c8c28494,cl428d6c,c8blcl8c,c8b9e722,...) at device_probe_and_attach+0x4e Ppc_attach(c2a67180,c0cdl6c8,c2a671cc,cl420b84,c2a67400,...) at ppc_attach+0xl43 Ppc_isa_attach(c2a67180,c29c4054,c0cdl6c8,c0bef7bd,80000000,...) at ppc_isa_attach*0x7f device_attach(c2a67180,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67180,104f,cl420c64,c04cf896,c2a67400,...) at device probe_and_attach+0x4e bus_generic_attach(c2a67400,1040,104f,c2a70a28,1040,...) at bus_gener ic_attach+0xl9 acpi_attach(c2a67400,c2a04054,c0cdl6c8,cObef7bd,80000000,...) at acpi_attach+8xba6 device_attach(c2a67400,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67400,c2a67980,cl420cf0,c0bl720e,c2a67980,...) at device_probe_and_attach+0x4e bus_generic_attach(c2a67980,a,c0ba0616,0) at bus_generic_attach+0xl9 nexus_acpi_attach(c2a6798O,c2a2c054,c0cdl6c8,c0bef7bd,80000000,...) at nexus_acpi_attach+0x7e device_attach(c2a67980,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67980,c0c28494,cl428d6c,c0blcl8c,c0b9e722,...) at device_probe_and_attach+0x4e root_b??s_configure(c0b9e722,cl420d88,c07fdfc6,0,141ec00,...) at root_bus_configure+0xlb configure(0,141ec00,141ec00,141e000,1425000,...) at configure+8xc Mi_startup() at Mi_startup+0x96 beginO at begin+0x2c db> show all locks Process 0 (kernel) thread 0xc0d3db30 (100000) exclusive sleep Mutex Giant (Giant) r = 0 (0xc0d3f590) locked @ /usr/src/sys/kern/kern_Module.c:117 db> Sorry for the quality, I've captured images from the screen and ran OCR on them. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:50:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3E3106564A for ; Thu, 22 Jan 2009 16:50:44 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5B31C8FC19 for ; Thu, 22 Jan 2009 16:50:44 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4355246rvf.43 for ; Thu, 22 Jan 2009 08:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=06OlrE/hZGIh18kDRfrQiaHxzByYEFJzMphi79DBbho=; b=hj3s4u2aM2gsVu1xCMhgxU4Y46ilRRRkOwee13EeuLPzvh0AfsrDznXELf1thQnBw9 z6dk9soLeJiTPdDOl8gjsYjMOZL20xeoHzn4nYopFWjGCumSWrzr2ywsMs7tmElRZK4d N/H1yQAa0umP/DTliiSzmZ7TLU7mthqJWr2I4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wRk+cEwm8Rr+yqG24VcKmqQ3xfEo/9RS2nT9UWmpD+23/sWjg/pNMAW62LwCXQMOxQ GHBdpM2FJB3Czz0AClUqweHxyerOOz0adp5n9j9NbAsTcg8Jg/mbWxvWVliobbpQBp8s +LRU5Kn/bAxWlBzwxHsLMVDTu9njGITpr8Jcs= MIME-Version: 1.0 Received: by 10.141.153.17 with SMTP id f17mr4676780rvo.99.1232643043890; Thu, 22 Jan 2009 08:50:43 -0800 (PST) In-Reply-To: <1232637705.16898.3.camel@buffy.york.ac.uk> References: <1232565243.5225.31.camel@phoenix.blechhirn.net> <1232637705.16898.3.camel@buffy.york.ac.uk> Date: Thu, 22 Jan 2009 19:50:43 +0300 Message-ID: <3cb459ed0901220850tf7bc3afo5404572c808783e4@mail.gmail.com> From: Alexander Churanov To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, mister.olli@googlemail.com Subject: Re: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:50:45 -0000 Im' sending this message again, because it seems the previous is corrupted by gmail. 2009/1/22 Gavin Atkinson > > At this point, can you enter the following commands and show the result? > > bt > show alllocks > > Thanks, > > Gavin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Gavin, I've just built the latest kernel and have the same issue. The machine is a VmWare 2-CPU box, running on host with Intel Core2 CPU. Here are the logs: le1: port Bxl4ee-Bxl47f irq 18 at device 17.0 on pciB le1: 16 receive buffers, 4 transMit buffers le1: Ethernet address: 88:8c:29:dl:14:96 le1: [ITHRERD] acpi_acad8: on acpiB atrtc8: port 8x78-8x71 irq 8 on acpiB atkbdcB: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd8 at atkbdB atkbdB: [GIRNT-LBCKEDl atkbdB: [ITHRERD] psMB: irq 12 on atkbdcB psMB: [GIRNT-LBCKEDl psM0: [ITHRERD] psM0: Model IntelliMouse, device ID 3 ppcB: port 8x378-8x37f irq 7 on acpiB ppcB: Generic chipset (NIDDLE-only) in CBMPRTIDLE Mode ppcB: [ITHRERD] ppbusB: on ppcB panic: Mutex ppcB not ouned at /usr/src/sys/dev/ppc/ppc.c:1983 cpuid = 8 HDD: enter: panic [thread pid 8 tid 188888 ] Stopped at kdb_enter+8x3a: movI $8,kdb_why db> bt ppbus_attach(c2a7a38B,c29b8B54,cBcdl6c8,c8bef7bd,88888888,.. ) at ppbus_attach+8xl48 device_attach(c2a7a388,4,c8bef746,969) at device_attach+8x36f device_probe_and_attach(c2a7a388,c8bd3el5,ffffffff,8,c86ff858,...) at device_probe_and_attach+8x4e ppc_attach(c2a67188,c8cdl6c8,c2a671cc,cl42Bb84,c2a674BB,...) at ppc_attach+8xl43 Ppc_isa_attach(c2a67188,c29c4854,c8cdl6c8,c8bef7bd,88888888,...) at ppc_isa_attach*8x7f device_attach(c2a6718B,4,cBbef746,969) at device_attach+8x36f device_probe_and_attach(c2a67188,184f,cl428c64,cB4cf896,c2a67488,...) at device. probe_and_attach+8x4e bus_generic_attach(c2a67488,184B,lB4f,c2a78a28,1B4B,...) at bus_gener ic_attach+8xl9 acpi_attach(c2a67468,c2a84854,c8cdl6c8,c8bef7bd,88888888,...) at acpi_attach+0xba6 device_attach(c2a67488,4,c8bef746,969) at device_attach+8x36f device_probe_and_attach(c2a67488,c2a67988,cl428cf8,c8bl728e,c2a67988,...) at device_probe_and_attach+6x4e bus_generic_attach(c2a67988,a,c8baB616,B) at bus_generic_attach+8xl9 nexus_acpi_attach(c2a67988,c2a2c854,c8cdl6c8,c8bef?bd,88886888,...) at nexus_acpi_attach+8x7e device_attach(c2a67988,4,c8bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67988,c8c28494,cl428d6c,c8blcl8c,c8b9e722,...) at device_probe_and_attach+0x4e Ppc_attach(c2a67180,c0cdl6c8,c2a671cc,cl420b84,c2a67400,...) at ppc_attach+0xl43 Ppc_isa_attach(c2a67180,c29c4054,c0cdl6c8,c0bef7bd,80000000,...) at ppc_isa_attach*0x7f device_attach(c2a67180,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67180,104f,cl420c64,c04cf896,c2a67400,...) at device probe_and_attach+0x4e bus_generic_attach(c2a67400,1040,104f,c2a70a28,1040,...) at bus_gener ic_attach+0xl9 acpi_attach(c2a67400,c2a04054,c0cdl6c8,cObef7bd,80000000,...) at acpi_attach+8xba6 device_attach(c2a67400,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67400,c2a67980,cl420cf0,c0bl720e,c2a67980,...) at device_probe_and_attach+0x4e bus_generic_attach(c2a67980,a,c0ba0616,0) at bus_generic_attach+0xl9 nexus_acpi_attach(c2a6798O,c2a2c054,c0cdl6c8,c0bef7bd,80000000,...) at nexus_acpi_attach+0x7e device_attach(c2a67980,4,c0bef746,969) at device_attach+0x36f device_probe_and_attach(c2a67980,c0c28494,cl428d6c,c0blcl8c,c0b9e722,...) at device_probe_and_attach+0x4e root_b??s_configure(c0b9e722,cl420d88,c07fdfc6,0,141ec00,...) at root_bus_configure+0xlb configure(0,141ec00,141ec00,141e000,1425000,...) at configure+8xc Mi_startup() at Mi_startup+0x96 beginO at begin+0x2c db> show all locks Process 0 (kernel) thread 0xc0d3db30 (100000) exclusive sleep Mutex Giant (Giant) r = 0 (0xc0d3f590) locked @ /usr/src/sys/kern/kern_Module.c:117 db> Sorry for the quality, I've captured images from the screen and ran OCR on them. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 17:32:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66401065679 for ; Thu, 22 Jan 2009 17:32:57 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 904818FC08 for ; Thu, 22 Jan 2009 17:32:56 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so2702921fgb.35 for ; Thu, 22 Jan 2009 09:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=o44k0MS3xGkZPEuSOvcf5thc7neWeo497UrRgTAd0+M=; b=v3hCQ08r2QAUkJ89CTn+sfHGlyelcQua9gYfN67RosImoff7EIs5lNUNtmJMValoUd jO+4qzPmgGmvHvMWv3+0YENYnTB+4HlfkYeMITMvUSLSVhDBr0xMen/s4H2nKoCKd1KP nK3DMZoI6TQzvwP7KY3eiVzkwgC/6uzcRGPRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=kH92WNkCMoAmxksi6/Mf+RoOi05XDGmy8YUVnOl1PFiEHRBOtP8w51aI3XPRB7Vdby VwDYiz9hSXgQ6aAGjYoNXg/Tl4Pv46+Bgc8IhFg/6GvsWrQ4aPt/92GdNj9N765Secsk JqPD/Sn/y25ETC7WAwJaWSLCwJ84sgHOux1mc= Received: by 10.223.113.195 with SMTP id b3mr3072015faq.79.1232645574882; Thu, 22 Jan 2009 09:32:54 -0800 (PST) Received: from ?10.30.1.220? (vpn-or.studi-planet.com [78.47.172.52]) by mx.google.com with ESMTPS id b17sm16987757fka.24.2009.01.22.09.32.52 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Jan 2009 09:32:53 -0800 (PST) From: Mister Olli To: freebsd-current@freebsd.org In-Reply-To: <1232592102.13146.2.camel@laptop.sprymed.com> References: <1232592102.13146.2.camel@laptop.sprymed.com> Content-Type: text/plain Date: Thu, 22 Jan 2009 13:30:33 +0100 Message-Id: <1232627433.5225.47.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit Subject: Re: dmesg for IBM T60 on 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 17:32:58 -0000 Hi... Some of the backtraces here looks quite the same as the ones I see when using 8-CURRENT as a PV xen domU. Espacially the unlink backtrace. Did anybody already had a look into it? greetz mr. olli Am Mittwoch, den 21.01.2009, 21:41 -0500 schrieb Ben Adams: > System Call showing Error?? > KDB: stack backtrace: > db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bd5436,c45216d8,c45242b8,e6dc0468,...) at > kdb_backtrace+0x29 > _witness_debugger(c0bdcb62,c49c19c4,c0bd05f5,c45242b8,c0bf92b3,...) at > _witness_debugger+0x25 > witness_checkorder(c49c19c4,9,c0bf92b3,221,0,...) at witness_checkorder > +0x839 > __lockmgr_args(c49c19c4,80100,c49c19e0,0,0,...) at __lockmgr_args+0x797 > ffs_lock(e6dc0578,c0e66518,c4a54524,80100,c49c196c,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0cde5a0,e6dc0578,e6dc0598,c0cf2680,c49c196c,...) at > VOP_LOCK1_APV+0xa5 > _vn_lock(c49c196c,80100,c0bf92b3,221,c4551200,...) at _vn_lock+0x5e > ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot > +0x1527 > ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount > +0x146f > vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at > vfs_donmount+0x1312 > nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe > syscall(e6dc0d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = > 0xbfbfeb1c, ebp = 0xbfbfee78 --- > lock order reversal: > 1st 0xd85df670 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 2nd 0xc5a99cdc snaplk (snaplk) > @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:794 > KDB: stack backtrace: > db_trace_self_wrapper(c0bd9ebe,e6dc040c,c0871c25,4,c0bd5436,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bd5436,c45216d8,c4524a70,e6dc0468,...) at > kdb_backtrace+0x29 > _witness_debugger(c0bdcb49,c5a99cdc,c0bf9315,c4524a70,c0bf92b3,...) at > _witness_debugger+0x25 > witness_checkorder(c5a99cdc,9,c0bf92b3,31a,c5a9b4a4,...) at > witness_checkorder+0x839 > __lockmgr_args(c5a99cdc,80400,c5a9b4a4,0,0,...) at __lockmgr_args+0x797 > ffs_lock(e6dc0578,0,0,80400,c5a9b430,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0cde5a0,e6dc0578,c1979284,c0cf2680,c5a9b430,...) at > VOP_LOCK1_APV+0xa5 > _vn_lock(c5a9b430,80400,c0bf92b3,31a,0,...) at _vn_lock+0x5e > ffs_snapshot(c49d7500,c49d5660,c0bfac18,15e,3,...) at ffs_snapshot > +0x28c6 > ffs_mount(c49d7500,c4a54480,c0be3253,3dc,c4a35660,...) at ffs_mount > +0x146f > vfs_donmount(c4a54480,211000,c57b5480,c57b5480,201000,...) at > vfs_donmount+0x1312 > nmount(c4a54480,e6dc0cf8,c,e6dc0d38,c0cbd2b0,...) at nmount+0xbe > syscall(e6dc0d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6beb, esp = > 0xbfbfeb1c, ebp = 0xbfbfee78 --- > lock order reversal: > 1st 0xc5a99cdc snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:293 > 2nd 0xc5a9b488 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1588 > KDB: stack backtrace: > db_trace_self_wrapper(c0bd9ebe,e6dc08c4,c0871c25,4,c0bd5436,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bd5436,c4524a70,c45242b8,e6dc0920,...) at > kdb_backtrace+0x29 > _witness_debugger(c0bdcb49,c5a9b488,c0bd05f5,c45242b8,c0bf92b3,...) at > _witness_debugger+0x25 > witness_checkorder(c5a9b488,9,c0bf92b3,634,0,...) at witness_checkorder > +0x839 > __lockmgr_args(c5a9b488,80000,0,0,0,...) at __lockmgr_args+0x797 > ffs_snapremove(c5a9b430,c49d7500,0,c0be4ac3,414,...) at ffs_snapremove > +0x11f > softdep_releasefile(c5a9d690,e6dc0aa8,2,c0e664e8,c0cc1b64,...) at > softdep_releasefile+0x3b > ufs_inactive(e6dc0ae8,c5a9b4a4,c5a9b430,c5a9b4a4,e6dc0b00,...) at > ufs_inactive+0x1bc > VOP_INACTIVE_APV(c0cde5a0,e6dc0ae8,c0be38fd,914,c0cf2640,...) at > VOP_INACTIVE_APV+0xa5 > vinactive(c0cde5a0,e6dc0b1c,c0be38fd,8a0,128,...) at vinactive+0x8e > vput(c5a9b430,e6dc0b54,c0be4ac3,125,c0cf23c0,...) at vput+0x1db > vn_close(c5a9b430,1,c456b400,c4a54480,e6dc0be0,...) at vn_close+0xee > vn_closefile(c498e888,c4a54480,3,0,c498e888,...) at vn_closefile+0xe9 > _fdrop(c498e888,c4a54480,e6dc0c1c,c0871a6c,0,c4a54524,c0e664e8,c0cc3370,c0bd2199,c576372c,44f,c0bd2199,e6dc0c44,c083a780,c576372c,8,c0bd2199,44f) at _fdrop+0x43 > closef(c498e888,c4a54480,44f,434,c498e888,...) at closef+0x290 > kern_close(c4a54480,4,e6dc0d2c,c0b29ec3,c4a54480,...) at kern_close > +0x11d > close(c4a54480,e6dc0cf8,4,c0bddf84,c0cbafd0,...) at close+0x1a > syscall(e6dc0d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x28184073, esp = > 0xbfbfdb5c, ebp = 0xbfbfdb88 --- > lock order reversal: > 1st 0xd8539350 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 2nd 0xc5b6e400 dirhash (dirhash) > @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 > KDB: stack backtrace: > db_trace_self_wrapper(c0bd9ebe,e6e78a74,c0871c25,4,c0bd5436,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bd5436,c45216d8,c4524320,e6e78ad0,...) at > kdb_backtrace+0x29 > _witness_debugger(c0bdcb49,c5b6e400,c0bfb766,c4524320,c0bfb3ff,...) at > _witness_debugger+0x25 > witness_checkorder(c5b6e400,9,c0bfb3ff,107,0,...) at witness_checkorder > +0x839 > _sx_xlock(c5b6e400,0,c0bfb3ff,107,d9719018,...) at _sx_xlock+0x85 > ufsdirhash_acquire(0,e,c4961800,d85392f0,d9719018,...) at > ufsdirhash_acquire+0x35 > ufsdirhash_remove(c5bf9690,d9719018,18,e6e78b60,e6e78b5c,...) at > ufsdirhash_remove+0x14 > ufs_dirremove(c5d85218,c5e4d2d0,500800c,0,c5d85218,...) at ufs_dirremove > +0xe5 > ufs_remove(e6e78c30,e6e78c30,0,e6e78c30,c5e48000,...) at ufs_remove+0x6e > VOP_REMOVE_APV(c0cde5a0,e6e78c30,2,0,28216238,...) at VOP_REMOVE_APV > +0xa5 > kern_unlinkat(c56eed80,ffffff9c,28216238,0,e6e78c80,...) at > kern_unlinkat+0x187 > kern_unlink(c56eed80,28216238,0,e6e78d2c,c0b29ec3,...) at kern_unlink > +0x27 > unlink(c56eed80,e6e78cf8,4,c0bf5f1c,c0cbb030,...) at unlink+0x22 > syscall(e6e78d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (10, FreeBSD ELF32, unlink), eip = 0x2815aa8f, esp = > 0xbfbfe6bc, ebp = 0xbfbfe6e8 --- > lock order reversal: > 1st 0xc579bb2c filedesc structure (filedesc structure) > @ /usr/src/sys/kern/kern_descrip.c:1076 > 2nd 0xc5ca5ce8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4065 > KDB: stack backtrace: > db_trace_self_wrapper(c0bd9ebe,e6d63a30,c0871c25,4,c0bd5436,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bd5436,c4521948,c45242b8,e6d63a8c,...) at > kdb_backtrace+0x29 > _witness_debugger(c0bdcb49,c5ca5ce8,c0bd05f5,c45242b8,c0be38fd,...) at > _witness_debugger+0x25 > witness_checkorder(c5ca5ce8,9,c0be38fd,fe1,c5ca5d04,...) at > witness_checkorder+0x839 > __lockmgr_args(c5ca5ce8,80400,c5ca5d04,0,0,...) at __lockmgr_args+0x797 > ffs_lock(e6d63b9c,c,0,80400,c5ca5c90,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0cde5a0,e6d63b9c,e6d63ba4,c0cf2680,c5ca5c90,...) at > VOP_LOCK1_APV+0xa5 > _vn_lock(c5ca5c90,80400,c0be38fd,fe1,e6d63bf8,...) at _vn_lock+0x5e > vfs_knllock(c5ca5c90,0,c0bd26b1,68c,c4e2361c,...) at vfs_knllock+0x29 > knlist_remove_kq(0,e6d63c18,c08b6fe9,c5d1608c,c4e2361c,...) at > knlist_remove_kq+0xad > knlist_remove(c5d1608c,c4e2361c,0,e6d63c44,c0809d65,...) at > knlist_remove+0x1b > filt_vfsdetach(c4e2361c,0,c0bd26b1,75c,8,...) at filt_vfsdetach+0x39 > knote_fdclose(c4998d80,8,c0bd2199,434,c57cfcb0,...) at knote_fdclose > +0xf5 > kern_close(c4998d80,8,e6d63d2c,c0b29ec3,c4998d80,...) at kern_close+0xd5 > close(c4998d80,e6d63cf8,4,c0bdd36a,c0cbafd0,...) at close+0x1a > syscall(e6d63d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x284c3073, esp = > 0xbfbfe10c, ebp = 0xbfbfe128 --- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 17:37:41 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B159106566C for ; Thu, 22 Jan 2009 17:37:41 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3382A8FC08 for ; Thu, 22 Jan 2009 17:37:40 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0MHbbDQ026486; Thu, 22 Jan 2009 17:37:37 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LQ3Um-0000WM-VI; Thu, 22 Jan 2009 17:37:36 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n0MHbaqY083926; Thu, 22 Jan 2009 17:37:36 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n0MHbahl083925; Thu, 22 Jan 2009 17:37:36 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Alexander Churanov In-Reply-To: <3cb459ed0901220848k6978c1d9j1f5b5720c2419ee1@mail.gmail.com> References: <1232565243.5225.31.camel@phoenix.blechhirn.net> <1232637705.16898.3.camel@buffy.york.ac.uk> <3cb459ed0901220848k6978c1d9j1f5b5720c2419ee1@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Jan 2009 17:37:36 +0000 Message-Id: <1232645856.16898.5.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 17:37:41 -0000 On Thu, 2009-01-22 at 19:48 +0300, Alexander Churanov wrote: > 2009/1/22 Gavin Atkinson > > > > > At this point, can you enter the following commands and show the result? > > > > bt > > show alllocks > > > > Thanks, > > > > Gavin > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > Gavin, > > I've just built the latest kernel and have the same issue. This is not the same issue, and should be fixed by the patch at http://docs.freebsd.org/cgi/mid.cgi?200901221016.58349.jhb Gavin > The machine is a VmWare 2-CPU box, running on host with Intel Core2 CPU. > Here are the logs: > le1: port Bxl4ee-Bxl47f irq 18 at device 17.0 on pciB > le1: 16 receive buffers, 4 transMit buffers > le1: Ethernet address: 88:8c:29:dl:14:96 > le1: [ITHRERD] > acpi_acad8: on acpiB > atrtc8: port 8x78-8x71 irq 8 on acpiB > atkbdcB: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd8 at atkbdB > atkbdB: [GIRNT-LBCKEDl > atkbdB: [ITHRERD] > psMB: irq 12 on atkbdcB > psMB: [GIRNT-LBCKEDl > psM0: [ITHRERD] > psM0: Model IntelliMouse, device ID 3 > ppcB: port 8x378-8x37f irq 7 on acpiB > ppcB: Generic chipset (NIDDLE-only) in CBMPRTIDLE Mode > ppcB: [ITHRERD] > ppbusB: on ppcB > panic: Mutex ppcB not ouned at /usr/src/sys/dev/ppc/ppc.c:1983 > cpuid = 8 > HDD: enter: panic > [thread pid 8 tid 188888 ] > Stopped at kdb_enter+8x3a: movI $8,kdb_why > db> bt > ppbus_attach(c2a7a38B,c29b8B54,cBcdl6c8,c8bef7bd,88888888,.. ) at > ppbus_attach+8xl48 > device_attach(c2a7a388,4,c8bef746,969) at device_attach+8x36f > device_probe_and_attach(c2a7a388,c8bd3el5,ffffffff,8,c86ff858,...) at > device_probe_and_attach+8x4e > ppc_attach(c2a67188,c8cdl6c8,c2a671cc,cl42Bb84,c2a674BB,...) at > ppc_attach+8xl43 > Ppc_isa_attach(c2a67188,c29c4854,c8cdl6c8,c8bef7bd,88888888,...) at > ppc_isa_attach*8x7f > device_attach(c2a6718B,4,cBbef746,969) at device_attach+8x36f > device_probe_and_attach(c2a67188,184f,cl428c64,cB4cf896,c2a67488,...) at > device. > probe_and_attach+8x4e > bus_generic_attach(c2a67488,184B,lB4f,c2a78a28,1B4B,...) at bus_gener > ic_attach+8xl9 > acpi_attach(c2a67468,c2a84854,c8cdl6c8,c8bef7bd,88888888,...) at > acpi_attach+0xba6 > device_attach(c2a67488,4,c8bef746,969) at device_attach+8x36f > device_probe_and_attach(c2a67488,c2a67988,cl428cf8,c8bl728e,c2a67988,...) at > device_probe_and_attach+6x4e > bus_generic_attach(c2a67988,a,c8baB616,B) at bus_generic_attach+8xl9 > nexus_acpi_attach(c2a67988,c2a2c854,c8cdl6c8,c8bef?bd,88886888,...) at > nexus_acpi_attach+8x7e > device_attach(c2a67988,4,c8bef746,969) at device_attach+0x36f > device_probe_and_attach(c2a67988,c8c28494,cl428d6c,c8blcl8c,c8b9e722,...) at > device_probe_and_attach+0x4e > Ppc_attach(c2a67180,c0cdl6c8,c2a671cc,cl420b84,c2a67400,...) at > ppc_attach+0xl43 > Ppc_isa_attach(c2a67180,c29c4054,c0cdl6c8,c0bef7bd,80000000,...) at > ppc_isa_attach*0x7f > device_attach(c2a67180,4,c0bef746,969) at device_attach+0x36f > device_probe_and_attach(c2a67180,104f,cl420c64,c04cf896,c2a67400,...) at > device probe_and_attach+0x4e > bus_generic_attach(c2a67400,1040,104f,c2a70a28,1040,...) at bus_gener > ic_attach+0xl9 > acpi_attach(c2a67400,c2a04054,c0cdl6c8,cObef7bd,80000000,...) at > acpi_attach+8xba6 > device_attach(c2a67400,4,c0bef746,969) at device_attach+0x36f > device_probe_and_attach(c2a67400,c2a67980,cl420cf0,c0bl720e,c2a67980,...) at > device_probe_and_attach+0x4e > bus_generic_attach(c2a67980,a,c0ba0616,0) at bus_generic_attach+0xl9 > nexus_acpi_attach(c2a6798O,c2a2c054,c0cdl6c8,c0bef7bd,80000000,...) at > nexus_acpi_attach+0x7e > device_attach(c2a67980,4,c0bef746,969) at device_attach+0x36f > device_probe_and_attach(c2a67980,c0c28494,cl428d6c,c0blcl8c,c0b9e722,...) at > device_probe_and_attach+0x4e > root_b??s_configure(c0b9e722,cl420d88,c07fdfc6,0,141ec00,...) at > root_bus_configure+0xlb > configure(0,141ec00,141ec00,141e000,1425000,...) at configure+8xc > Mi_startup() at Mi_startup+0x96 > beginO at begin+0x2c > db> show all locks > Process 0 (kernel) thread 0xc0d3db30 (100000) > exclusive sleep Mutex Giant (Giant) r = 0 (0xc0d3f590) locked @ > /usr/src/sys/kern/kern_Module.c:117 > db> > Sorry for the quality, I've captured images from the screen and ran OCR on > them. > Alexander Churanov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 17:42:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1AC1106566B for ; Thu, 22 Jan 2009 17:42:14 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 3789F8FC19 for ; Thu, 22 Jan 2009 17:42:13 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by fk-out-0910.google.com with SMTP id f40so885221fka.11 for ; Thu, 22 Jan 2009 09:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=SXLeeuyMTEZWu80X5D670/vyTNiVlFUZ4NKqd2eR7/0=; b=efpdDQA9qyWpkbNRsgcVO9KTNgey7qHjWyFjOmsclKNGq75Dg73iy+BPUVMhk51+YU e4vHZyGWX68KUqD6YHdTMbzEgwb5VmrNR9IaCxfS68bH50Ytv7f6rrWbVkuMZsM1+tIl lSDtu1JnN8PoW5/nT5mrnfwm7gDHJHn/gTDns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=we61C80qICkaCQXFcVOVrXt1C2twpxDFQT+XRuAklvcrbOPdCpAIsi0UxxSIL6d2BH JuPrDsq7PeVcOa5kVveNP1KOLM9oM5rpYNmoVA6Gu0EKWue1tR3aGd6XYk8PYc+v+fcB TqnuXxkWqxVxlry/THcazbEZBujTYei63C+Zg= Received: by 10.223.108.196 with SMTP id g4mr3213422fap.36.1232646132315; Thu, 22 Jan 2009 09:42:12 -0800 (PST) Received: from ?10.30.1.220? (vpn-or.studi-planet.com [78.47.172.52]) by mx.google.com with ESMTPS id 28sm10155873fkx.37.2009.01.22.09.42.11 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Jan 2009 09:42:11 -0800 (PST) From: Mister Olli To: Gavin Atkinson In-Reply-To: <1232637705.16898.3.camel@buffy.york.ac.uk> References: <1232565243.5225.31.camel@phoenix.blechhirn.net> <1232637705.16898.3.camel@buffy.york.ac.uk> Content-Type: text/plain Date: Thu, 22 Jan 2009 17:41:47 +0000 Message-Id: <1232646107.5225.67.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: KDB panic with 2 vcpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 17:42:14 -0000 Am Donnerstag, den 22.01.2009, 15:21 +0000 schrieb Gavin Atkinson: > On Wed, 2009-01-21 at 20:14 +0100, Mister Olli wrote: > > Hi.. > > > > I'm currently trying to setup FreeBSD 8-CURRENT as a para-virtualized > > domU on XEN 3.3.0 (with gentoo dom0). > > > > When I configure 2 CPU's (using vcpus=2) in the domU config file, I get > > the following error during bootup: > > ========================================================================== > > virt-001 template_8-CURRENT # xm create -c 00_template_8-CURRENT.XENconfig > > Using config file "./00_template_8-CURRENT.XENconfig". > > Started domain template_8-CURRENT > > WARNING: loader(8) metadata is missing! > > GDB: no debug ports present > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2009 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 8.0-CURRENT #0: Wed Jan 14 21:47:10 CET 2009 > > root@template-8_CURRENT.localdomain:/usr/obj/usr/src/sys/freebsd8_XEN > > WARNING: WITNESS option enabled, expect reduced performance. > > Xen reported: 1600.056 MHz processor. > > Timecounter "ixen" frequency 1000000000 Hz quality 0 > > CPU: AMD Athlon(tm) Processor (1600.06-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 > > Features=0x383fbff > > AMD Features=0xc0480800 > > real memory = 268435456 (256 MB) > > avail memory = 256045056 (244 MB) > > gdtpfn=3e2d8 pdptpfn=28a43 > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > cpu=0 irq=0 vector=0 > > cpu=0 irq=0 vector=1 > > cpu=1 irq=0 vector=0 > > cpu=1 irq=0 vector=1 > > kbd0 at kbdmux0 > > xenbus0: on motherboard > > xc0: on motherboard > > Timecounters tick every 100.000 msec > > xbd0: 5120MB at device/vbd/768 on xenbus0 > > xbd0: attaching as ad0 > > xn0: at device/vif/0 on xenbus0 > > xn0: Ethernet address: 00:16:3e:11:4d:c4 > > GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). > > [XEN] netfront_backend_changed: newstate=2 > > [XEN] netfront_backend_changed: newstate=4 > > Spanic: blockable sleep lock (sleep mutex) XCONS LOCK @ /usr/src/sys/dev/xen/console/console.c:290 > > cpuid = 1 > > KDB: enter: panic > > [thread pid 11 tid 100003 ] > > Stopped at kdb_enter+0x3a: movl $0,kdb_why > > db> > > At this point, can you enter the following commands and show the result? > > bt > show alllocks > > Thanks, > > Gavin Hi... the output is: ===========================0 ... [SNIPPING_AWAY_DMESG_MESSAGES] [XEN] netfront_backend_changed: newstate=2 [XEN] netfront_backend_changed: newstate=4 Spanic: blockable sleep lock (sleep mutex) XCONS LOCK @ /usr/src/sys/dev/xen/console/console.c:290 cpuid = 1 KDB: enter: panic [thread pid 11 tid 100003 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 11 tid 100003 td 0xc14d3b40 kdb_enter(c024beb7,c024beb7,c0251ae0,c12ffd70,1,...) at kdb_enter+0x3a panic(c0251ae0,c026584c,c02687f1,c02687b0,122,...) at panic+0x136 witness_checkorder(c041e584,9,c02687b0,122,0,...) at witness_checkorder+0xb0 _mtx_lock_flags(c041e584,0,c02687b0,122,c029b900,...) at _mtx_lock_flags+0xc4 xenbus_exists(c12ffe1c,c01f513b,c12ffe38,c007bb6f,c029b900,...) at xenbus_exists+0x2ba xencons_tx(c12ffe38,c007bb6f,c029b900,53,c12fffb8,...) at xencons_tx+0x66 xencons_tx(c029b900,53,c12fffb8,5,53,...) at xencons_tx+0xeb cnputc(53,c12fffb8,c12ffe68,c00e36b1,0,...) at cnputc+0x5f ttyprintf(0,0,1000000,c14d3b40,c00e3650,...) at ttyprintf+0x1b7 ttyprintf(53,c12fffb8,0,0,0,...) at ttyprintf+0x281 kvprintf(c026f0e7,c00e3650,c12fffb8,a,c12fffe4,...) at kvprintf+0x9e printf(c026f0e7,1,c026f06e,254,1,...) at printf+0x4e *** error reading from address c1300000 *** db> show allocks No such command db> show alllocks Process 0 (kernel) thread 0xc02aa2b0 (100000) exclusive sleep mutex Giant (Giant) r = 0 (0xc02abd10) locked @ /usr/src/sys/kern/kern_module.c:117 db> If there's any thing I can help on further investigating just let me know. Greetings, Olli From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 17:45:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA14E106568B for ; Thu, 22 Jan 2009 17:45:50 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6A37F8FC22 for ; Thu, 22 Jan 2009 17:45:50 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id n0MHjmi4047083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 18:45:48 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <4978B0CC.4070803@boland.org> Date: Thu, 22 Jan 2009 18:45:48 +0100 From: Michiel Boland User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Dimitry Andric References: <49789DC7.1050300@boland.org> <49789EBC.1050401@andric.com> In-Reply-To: <49789EBC.1050401@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: Re: panic on boot with today's kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 17:45:51 -0000 Dimitry Andric wrote: > On 2009-01-22 17:24, Michiel Boland wrote: >> panic: mutex ppc0 not owned at /usr/src/sys/dev/ppc/ppc.c:1983 > ... >> _mtx_assert(c5732a7c,4,c0bd3582,7bf,c56d4800,...) at _mtx_assert+0x87 >> ppc_write_ivar(c56d4800,c5743180,2,c06fd070,ffffffff,...) at ppc_write_ivar+0x42 >> ppbus_attach(c5743180,c55fd054,c0cd0dc8,c0beeeb3,80000000,...) at ppbus_attach+0x148 > > Please try jhb's fix from here: > > http://docs.freebsd.org/cgi/mid.cgi?200901221016.58349.jhb Now it crashes somewhere else... ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 panic: mutex ppc0 not owned at /usr/src/sys/dev/ppbus/lpt.c:222 cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 100000 td 0xc0d3d2b0 kdb_enter(c0bec51e,c0bec51e,c0bead23,c1420890,0,...) at kdb_enter+0x3a panic(c0bead23,c574b520,c0bd31a4,de,c14208b4,...) at panic+0x136 _mtx_assert(c573217c,4,c0bd31a4,de,c14208d4,...) at _mtx_assert+0x87 _ppb_assert_locked(c5746580,c0bd31a4,de,c5746500,c5746580,...) at _ppb_assert_locked+0x32 lpt_release_ppbus(c5746580,10,0,0,4,...) at lpt_release_ppbus+0x3d From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 17:46:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F0A1065670 for ; Thu, 22 Jan 2009 17:46:37 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 987D68FC16 for ; Thu, 22 Jan 2009 17:46:36 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180146187.adsl.alicedsl.de [85.180.146.187]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id n0MHkYN6097617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 18:46:34 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id n0MHkWZk004681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 18:46:32 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id n0MHkWr2004680; Thu, 22 Jan 2009 18:46:32 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Thu, 22 Jan 2009 18:46:31 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Igor Mozolevsky Message-ID: <20090122174631.GC1482@roadrunner.spoerlein.net> Mail-Followup-To: Igor Mozolevsky , Attila Nagy , freebsd-current@freebsd.org References: <4978853A.2000107@fsn.hu> <49788F1B.7000600@fsn.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Attila Nagy , freebsd-current@freebsd.org Subject: Re: Creating swap based ramdisks from rc.initdiskless by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 17:46:37 -0000 On Thu, 22.01.2009 at 15:42:33 +0000, Igor Mozolevsky wrote: > 2009/1/22 Attila Nagy : > > Igor Mozolevsky wrote: > >> 2009/1/22 Attila Nagy : > >>> So the question is: what is the rationale behind creating malloc backed > >>> disks by default, instead of swap-backed ones? > >> > >> Yes --- booting from DoC/CDROM/PXE with no HDD on the node... > > > > Did you read my e-mail? > > Yes, but why would you have swap enabled in the kernel on a system > that cannot possibly swap? That's not the point. AFAIK there's a kernel memory pool difference between malloc(9) and swap-backed memory. You usually want to use the latter, irregardless of an actual swap device, as the former is a scarce ressource and shouldn't be used for RAM disks. Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 18:50:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 115DF106567C for ; Thu, 22 Jan 2009 18:50:09 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id F19C88FC12 for ; Thu, 22 Jan 2009 18:50:08 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id BBF3A33C62 for ; Thu, 22 Jan 2009 10:50:08 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 575F733C5B for ; Thu, 22 Jan 2009 10:50:08 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18808.49120.167837.490082@almost.alerce.com> Date: Thu, 22 Jan 2009 10:50:08 -0800 To: freebsd-current@freebsd.org X-Mailer: VM 7.19 under Emacs 22.1.50.1 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 22 Jan 2009 19:12:38 +0000 Subject: Steps to debug memory/motherboard (Via VB8001) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 18:50:10 -0000 I have a Via VB8001 running 8.0-CURRENT using ZFS on a pair of SATA drives. It has two memory slots, and I have 2x2GB of Kingston PC2 5300 memory (KVR667D2N5K2/4G) that I think is correct. I can run with either of the DIMMs in the first slot and am able to build and install world and kernel. If I populate both slots then I can run for a bit (e.g. make buildkernel) before I end up in the debugger or with the build bombing out with a message about "bad address". This happens no matter which DIMM is in which slot. With both DIMMs installed the system only reports 3GB to the BIOS and to FreeBSD, others have reported this and it seems to be a limitation of the BIOS and the integrated video. The fact that the DIMMs work in isolation and I have problems independent of which one goes in which slot suggests that the problem is either: a) with the motherboard b) with how -CURRENT sets up or drives the hardware. c) bad memory that only shows up when both DIMMs are in use. I didn't get the RAM and the board from the same vendor, so I'm kind of expecting some finger pointing. Left to my own devices, I'd blame the motherboard and try to get it swapped. Is it more likely to be a memory problem? A -CURRENT problem? Thanks, g. From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 19:19:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883CA1065672 for ; Thu, 22 Jan 2009 19:19:02 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0E58FC1D for ; Thu, 22 Jan 2009 19:19:01 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from [192.168.4.16] (unknown [192.168.4.16]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id ED7F839; Thu, 22 Jan 2009 19:18:58 +0000 (UTC) Message-ID: <4978C6A2.9050708@stillbilde.net> Date: Thu, 22 Jan 2009 20:18:58 +0100 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hartzell@alerce.com References: <18808.49120.167837.490082@almost.alerce.com> In-Reply-To: <18808.49120.167837.490082@almost.alerce.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Steps to debug memory/motherboard (Via VB8001) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 19:19:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Hartzell wrote: *SNIP!* > > With both DIMMs installed the system only reports 3GB to the BIOS and > to FreeBSD, others have reported this and it seems to be a limitation > of the BIOS and the integrated video. Here we find the first clue! ;) > The fact that the DIMMs work in isolation and I have problems > independent of which one goes in which slot suggests that the problem > is either: > > a) with the motherboard > > b) with how -CURRENT sets up or drives the hardware. > > c) bad memory that only shows up when both DIMMs are in use. > > I didn't get the RAM and the board from the same vendor, so I'm kind > of expecting some finger pointing. > > Left to my own devices, I'd blame the motherboard and try to get it > swapped. > > Is it more likely to be a memory problem? A -CURRENT problem? Neighter. This sounds like a bios issue with the mainboard. If the bios doesn't find all the memory that is actually attached to the mainboard, this usually means that eighter the memory is the wrong speed for the mainboard (less likely these days, more of a problem before the DDR days, as you don't get an error message), or that the bios simply doesn't know how to address the memory found. This is more likely since a lot of mainboard manufacturers are hell-bent on "32 bit windows cannot use more than 3gb of ram and still have swap", and promptly refuses to acknowledge that someone might be tempted to run anything that isn't a 32bit windows version. Check if there is a new bios available, and if not mail the mainboard manufacturer about the problem. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl4xqIACgkQODUnwSLUlKTOxgCgtUdlYg273GA+1KhrH7S3Lysy lQ0An1k7+PMAwgx3kFIafTq28u/YTIX4 =J13R -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 19:37:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B0A1106566B for ; Thu, 22 Jan 2009 19:37:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 011158FC14 for ; Thu, 22 Jan 2009 19:37:56 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 25DB24DA0064; Thu, 22 Jan 2009 11:21:47 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id 0E4F045C0001; Thu, 22 Jan 2009 11:21:47 -0800 (PST) X-AuditID: 11807130-ab096bb000000fcd-87-4978c74a3ca3 Received: from cswiger1.apple.com (cswiger1.apple.com [17.227.140.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id E71202807E; Thu, 22 Jan 2009 11:21:46 -0800 (PST) Message-Id: From: Chuck Swiger To: hartzell@alerce.com In-Reply-To: <18808.49120.167837.490082@almost.alerce.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 11:21:46 -0800 References: <18808.49120.167837.490082@almost.alerce.com> X-Mailer: Apple Mail (2.930.3) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@freebsd.org Subject: Re: Steps to debug memory/motherboard (Via VB8001) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 19:37:57 -0000 On Jan 22, 2009, at 10:50 AM, George Hartzell wrote: > I can run with either of the DIMMs in the first slot and am able to > build and install world and kernel. > > If I populate both slots then I can run for a bit (e.g. make > buildkernel) before I end up in the debugger or with the build bombing > out with a message about "bad address". Sounds like the motherboard or the memory is marginal, and the combination of the 2 DIMMs puts it out of spec. Try running memtest86 overnight and see whether that finds errors. If so, you might be able to reduce the RAM timings in the BIOS and get it stable, or you might not. Are the two DIMMs identical (ie, same vendor, same specs)? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 19:51:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B32510656C1 for ; Thu, 22 Jan 2009 19:51:36 +0000 (UTC) (envelope-from prvs=julian=2668fe0af@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 35F358FC17 for ; Thu, 22 Jan 2009 19:51:36 +0000 (UTC) (envelope-from prvs=julian=2668fe0af@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.28]) by smtp-outbound.ironport.com with ESMTP; 22 Jan 2009 11:23:14 -0800 Message-ID: <4978C7A3.6080602@elischer.org> Date: Thu, 22 Jan 2009 11:23:15 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: hartzell@alerce.com References: <18808.49120.167837.490082@almost.alerce.com> In-Reply-To: <18808.49120.167837.490082@almost.alerce.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Steps to debug memory/motherboard (Via VB8001) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 19:51:37 -0000 George Hartzell wrote: > > a) with the motherboard > > b) with how -CURRENT sets up or drives the hardware. > > c) bad memory that only shows up when both DIMMs are in use. > > d) the settings the BIOS uses to set up the memory bus controllers I presume the DIMMs are identical.... From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 19:58:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C56E10656C0; Thu, 22 Jan 2009 19:58:14 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3918FC1C; Thu, 22 Jan 2009 19:58:14 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 7AB4BFEF1; Fri, 23 Jan 2009 08:58:13 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfGK9grUKxg3; Fri, 23 Jan 2009 08:58:10 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 23 Jan 2009 08:58:10 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A2E4E11431; Fri, 23 Jan 2009 08:58:09 +1300 (NZDT) Date: Thu, 22 Jan 2009 11:58:09 -0800 From: Andrew Thompson To: Hans Petter Selasky Message-ID: <20090122195809.GD84458@citylink.fud.org.nz> References: <1421.1232314073@critter.freebsd.dk> <200901221624.13536.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901221624.13536.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 19:58:15 -0000 On Thu, Jan 22, 2009 at 04:24:12PM +0100, Hans Petter Selasky wrote: > Hi, > > Try these patches on a clean -current. Tested with a similar device of yours! > > http://perforce.freebsd.org/chv.cgi?CH=156521 > http://perforce.freebsd.org/chv.cgi?CH=156522 I am still seeing the UHCI attach issue with these patches applied. usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 19:58:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C56E10656C0; Thu, 22 Jan 2009 19:58:14 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3918FC1C; Thu, 22 Jan 2009 19:58:14 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 7AB4BFEF1; Fri, 23 Jan 2009 08:58:13 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfGK9grUKxg3; Fri, 23 Jan 2009 08:58:10 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 23 Jan 2009 08:58:10 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A2E4E11431; Fri, 23 Jan 2009 08:58:09 +1300 (NZDT) Date: Thu, 22 Jan 2009 11:58:09 -0800 From: Andrew Thompson To: Hans Petter Selasky Message-ID: <20090122195809.GD84458@citylink.fud.org.nz> References: <1421.1232314073@critter.freebsd.dk> <200901221624.13536.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901221624.13536.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 19:58:15 -0000 On Thu, Jan 22, 2009 at 04:24:12PM +0100, Hans Petter Selasky wrote: > Hi, > > Try these patches on a clean -current. Tested with a similar device of yours! > > http://perforce.freebsd.org/chv.cgi?CH=156521 > http://perforce.freebsd.org/chv.cgi?CH=156522 I am still seeing the UHCI attach issue with these patches applied. usb2_alloc_device:1401: set address 2 failed (ignored) usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 20:20:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B081065672 for ; Thu, 22 Jan 2009 20:20:37 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 91BCD8FC0A for ; Thu, 22 Jan 2009 20:20:37 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 22 Jan 2009 15:20:36 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.4-GA) with ESMTP id PLD72237; Thu, 22 Jan 2009 15:20:34 -0500 (EST) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 22 Jan 2009 15:20:32 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18808.54543.771955.996924@jerusalem.litteratus.org> Date: Thu, 22 Jan 2009 15:20:31 -0500 To: Roman Divacky In-Reply-To: <20090120175558.GA43333@freebsd.org> References: <20090120175558.GA43333@freebsd.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Kevin Wilcox , freebsd-current@FreeBSD.org, Lesly Bien-Aim? , Michel Talon Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it becomestandard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 20:20:38 -0000 Roman Divacky writes: > > www.OpenWatcom.com > > > > "Work in progress includes Linux and FreeBSD ports" > > > > Just pointing out one more compiler. > > this has been the case for quite some years now... it looks like > a dead project... :( When was the last commit to the code base? :-) Robert Huff From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:05:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB441065673; Thu, 22 Jan 2009 21:05:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AA6418FC17; Thu, 22 Jan 2009 21:05:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n0ML5boN042586; Thu, 22 Jan 2009 16:05:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n0ML5bFL006678; Thu, 22 Jan 2009 16:05:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5EADB7302F; Thu, 22 Jan 2009 16:05:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090122210537.5EADB7302F@freebsd-current.sentex.ca> Date: Thu, 22 Jan 2009 16:05:37 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 21:05:41 -0000 TB --- 2009-01-22 19:25:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-22 19:25:48 - starting HEAD tinderbox run for i386/i386 TB --- 2009-01-22 19:25:48 - cleaning the object tree TB --- 2009-01-22 19:26:21 - cvsupping the source tree TB --- 2009-01-22 19:26:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-01-22 19:26:30 - building world TB --- 2009-01-22 19:26:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-22 19:26:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-22 19:26:30 - TARGET=i386 TB --- 2009-01-22 19:26:30 - TARGET_ARCH=i386 TB --- 2009-01-22 19:26:30 - TZ=UTC TB --- 2009-01-22 19:26:30 - __MAKE_CONF=/dev/null TB --- 2009-01-22 19:26:30 - cd /src TB --- 2009-01-22 19:26:30 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 22 19:26:31 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 22 20:46:49 UTC 2009 TB --- 2009-01-22 20:46:49 - generating LINT kernel config TB --- 2009-01-22 20:46:49 - cd /src/sys/i386/conf TB --- 2009-01-22 20:46:49 - /usr/bin/make -B LINT TB --- 2009-01-22 20:46:49 - building LINT kernel TB --- 2009-01-22 20:46:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-22 20:46:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-22 20:46:49 - TARGET=i386 TB --- 2009-01-22 20:46:49 - TARGET_ARCH=i386 TB --- 2009-01-22 20:46:49 - TZ=UTC TB --- 2009-01-22 20:46:49 - __MAKE_CONF=/dev/null TB --- 2009-01-22 20:46:49 - cd /src TB --- 2009-01-22 20:46:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 22 20:46:49 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/cpufreq/est.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/cpufreq/p4tcc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/cpufreq/powernow.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/cpufreq/smist.c /src/sys/i386/cpufreq/smist.c: In function 'smist_identify': /src/sys/i386/cpufreq/smist.c:288: error: 'CPU_VENDOR_INTEL' undeclared (first use in this function) /src/sys/i386/cpufreq/smist.c:288: error: (Each undeclared identifier is reported only once /src/sys/i386/cpufreq/smist.c:288: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-22 21:05:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-22 21:05:37 - ERROR: failed to build lint kernel TB --- 2009-01-22 21:05:37 - 4831.59 user 435.92 system 5988.54 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:07:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90C51065706; Thu, 22 Jan 2009 21:07:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 08D788FC1D; Thu, 22 Jan 2009 21:07:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=6I5d2MoRAAAA:8 a=o1t3ePbbDe6zwtdeGQUA:9 a=9WOTzE1hlvIT2Tm02K0A:7 a=FfbHXuv4IowFyaqV_3bXABohXp0A:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 133590659; Thu, 22 Jan 2009 22:07:27 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Thu, 22 Jan 2009 22:09:50 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> <200901221624.13536.hselasky@c2i.net> <20090122195809.GD84458@citylink.fud.org.nz> In-Reply-To: <20090122195809.GD84458@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901222209.51225.hselasky@c2i.net> Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 21:07:30 -0000 On Thursday 22 January 2009, Andrew Thompson wrote: > On Thu, Jan 22, 2009 at 04:24:12PM +0100, Hans Petter Selasky wrote: > > Hi, > > > > Try these patches on a clean -current. Tested with a similar device of > > yours! > > > > http://perforce.freebsd.org/chv.cgi?CH=156521 > > http://perforce.freebsd.org/chv.cgi?CH=156522 > > I am still seeing the UHCI attach issue with these patches applied. > > usb2_alloc_device:1401: set address 2 failed (ignored) > usb2_alloc_device:1436: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > ugen1.2: <> at usbus1 (disconnected) > uhub_reattach_port:413: could not allocate new device! > > > Andrew Hi, You can try editing "uhci2.c" and change the "if ()" in: static void uhci_set_hw_power(struct usb2_bus *bus) to "if (1)". That will prevent the USB schedule from ever stopping. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:07:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90C51065706; Thu, 22 Jan 2009 21:07:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 08D788FC1D; Thu, 22 Jan 2009 21:07:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=6I5d2MoRAAAA:8 a=o1t3ePbbDe6zwtdeGQUA:9 a=9WOTzE1hlvIT2Tm02K0A:7 a=FfbHXuv4IowFyaqV_3bXABohXp0A:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 133590659; Thu, 22 Jan 2009 22:07:27 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Thu, 22 Jan 2009 22:09:50 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> <200901221624.13536.hselasky@c2i.net> <20090122195809.GD84458@citylink.fud.org.nz> In-Reply-To: <20090122195809.GD84458@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901222209.51225.hselasky@c2i.net> Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 21:07:30 -0000 On Thursday 22 January 2009, Andrew Thompson wrote: > On Thu, Jan 22, 2009 at 04:24:12PM +0100, Hans Petter Selasky wrote: > > Hi, > > > > Try these patches on a clean -current. Tested with a similar device of > > yours! > > > > http://perforce.freebsd.org/chv.cgi?CH=156521 > > http://perforce.freebsd.org/chv.cgi?CH=156522 > > I am still seeing the UHCI attach issue with these patches applied. > > usb2_alloc_device:1401: set address 2 failed (ignored) > usb2_alloc_device:1436: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > ugen1.2: <> at usbus1 (disconnected) > uhub_reattach_port:413: could not allocate new device! > > > Andrew Hi, You can try editing "uhci2.c" and change the "if ()" in: static void uhci_set_hw_power(struct usb2_bus *bus) to "if (1)". That will prevent the USB schedule from ever stopping. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:29:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA5A41065705 for ; Thu, 22 Jan 2009 21:29:54 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id C3B688FC19 for ; Thu, 22 Jan 2009 21:29:53 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 309C1FEEF; Fri, 23 Jan 2009 10:29:53 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqcpvrjyCz2D; Fri, 23 Jan 2009 10:29:48 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 23 Jan 2009 10:29:48 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 32EFA11431; Fri, 23 Jan 2009 10:29:48 +1300 (NZDT) Date: Thu, 22 Jan 2009 13:29:48 -0800 From: Andrew Thompson To: Hans Petter Selasky Message-ID: <20090122212948.GA11441@citylink.fud.org.nz> References: <1421.1232314073@critter.freebsd.dk> <200901221624.13536.hselasky@c2i.net> <20090122195809.GD84458@citylink.fud.org.nz> <200901222209.51225.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <200901222209.51225.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 21:29:55 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 22, 2009 at 10:09:50PM +0100, Hans Petter Selasky wrote: > On Thursday 22 January 2009, Andrew Thompson wrote: > > On Thu, Jan 22, 2009 at 04:24:12PM +0100, Hans Petter Selasky wrote: > > > Hi, > > > > > > Try these patches on a clean -current. Tested with a similar device of > > > yours! > > > > > > http://perforce.freebsd.org/chv.cgi?CH=156521 > > > http://perforce.freebsd.org/chv.cgi?CH=156522 > > > > I am still seeing the UHCI attach issue with these patches applied. > > > > usb2_alloc_device:1401: set address 2 failed (ignored) > > usb2_alloc_device:1436: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) > > usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! > > ugen1.2: <> at usbus1 (disconnected) > > uhub_reattach_port:413: could not allocate new device! > > You can try editing "uhci2.c" and change the "if ()" in: > > static void > uhci_set_hw_power(struct usb2_bus *bus) > > to "if (1)". That will prevent the USB schedule from ever stopping. No change, log attached. --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uhci-log2.txt" uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_device_done:1825: xfer=0xc4361cb8, pipe=0xc44e73a8, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0002 uhci_root_ctrl_done:2673: UR_CLEAR_PORT_FEATURE port=2 feature=16 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2429: uhci port 2 reset, status0 = 0x0280 uhci_portreset:2442: uhci port 2 reset, status1 = 0x0093 uhci_portreset:2460: uhci port 2 iteration 0, status = 0x0097 uhci_portreset:2460: uhci port 2 iteration 1, status = 0x0095 uhci_portreset:2498: uhci port 2 reset, status2 = 0x0095 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2673: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_pipe_init:3184: pipe=0xc44c5380, addr=0, endpt=0, mode=0 (1) uhci_set_hw_power:3335: uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1804: nexttog=0; data before transfer: TD(0xe67a48d0) at 0x096578d4 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:919: 0xc432f280 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x096578d4 = link=0x00000001 status=0x01450007 token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-CRCTO-STALLED-IOC, errcnt=0, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_non_isoc_done_sub:1173: error, addr=0, endpt=0x00, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE][IOC] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc432f280 from 0xc432f280 ichsmb0: irq 0x02 during -1 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc432f280 from 0xc42dab80 usb2_alloc_device:1401: set address 2 failed (ignored) uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1804: nexttog=1; data before transfer: TD(0xe67a48d0) at 0x096768d4 = link=0x096768a4 status=0x188003ff token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-ACTIVE, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x096768a4 = link=0x09676874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x09676874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:919: 0xc432f880 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x096768d4 = link=0x096768a4 status=0x00450007 token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-CRCTO-STALLED, errcnt=0, actlen=8 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x096768a4 = link=0x09676874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x09676874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 uhci_non_isoc_done_sub:1173: error, addr=2, endpt=0x80, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc432f880 from 0xc432f880 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc432f880 from 0xc42dab80 usb2_alloc_device:1436: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2429: uhci port 2 reset, status0 = 0x0288 uhci_portreset:2442: uhci port 2 reset, status1 = 0x009b uhci_device_done:1825: xfer=0xc4361cb8, pipe=0xc44e73a8, error=0 uhci_portreset:2460: uhci port 2 iteration 0, status = 0x009f uhci_portreset:2460: uhci port 2 iteration 1, status = 0x0095 uhci_portreset:2498: uhci port 2 reset, status2 = 0x0095 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2673: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1804: nexttog=1; data before transfer: TD(0xe67a48d0) at 0x011488d4 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:919: 0xc432fe80 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x011488d4 = link=0x00000001 status=0x01450007 token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-CRCTO-STALLED-IOC, errcnt=0, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_non_isoc_done_sub:1173: error, addr=0, endpt=0x00, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE][IOC] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc432fe80 from 0xc432fe80 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc432fe80 from 0xc42dab80 usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1804: nexttog=1; data before transfer: TD(0xe67a48d0) at 0x0847a8d4 = link=0x0847a8a4 status=0x188003ff token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-ACTIVE, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x0847a8a4 = link=0x0847a874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x0847a874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:919: 0xc4318700 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x0847a8d4 = link=0x0847a8a4 status=0x00450007 token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-CRCTO-STALLED, errcnt=0, actlen=8 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x0847a8a4 = link=0x0847a874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x0847a874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 uhci_non_isoc_done_sub:1173: error, addr=2, endpt=0x80, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc4318700 from 0xc4318700 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc4318700 from 0xc42dab80 usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2429: uhci port 2 reset, status0 = 0x0288 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_portreset:2442: uhci port 2 reset, status1 = 0x009b uhci_portreset:2460: uhci port 2 iteration 0, status = 0x009f uhci_portreset:2460: uhci port 2 iteration 1, status = 0x0095 uhci_portreset:2498: uhci port 2 reset, status2 = 0x0095 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2673: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1804: nexttog=1; data before transfer: TD(0xe67a48d0) at 0x011488d4 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:919: 0xc432f580 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x011488d4 = link=0x00000001 status=0x01450007 token=0x00e0002d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-T td_status=-CRCTO-STALLED-IOC, errcnt=0, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_non_isoc_done_sub:1173: error, addr=0, endpt=0x00, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE][IOC] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc432f580 from 0xc432f580 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc432f580 from 0xc42dab80 usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1804: nexttog=1; data before transfer: TD(0xe67a48d0) at 0x0847a8d4 = link=0x0847a8a4 status=0x188003ff token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-ACTIVE, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x0847a8a4 = link=0x0847a874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x0847a874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 _uhci_append_qh:919: 0xc4330680 to 0xc42dab80 uhci_check_transfer:1384: xfer=0xc431a0b8 is still active uhci_non_isoc_done:1186: xfer=0xc431a0b8 pipe=0xc44c5380 transfer done TD(0xe67a48d0) at 0x0847a8d4 = link=0x0847a8a4 status=0x00450007 token=0x00e0022d buffer=0x01b1a168 TD(0xe67a48d0) td_next=-VF td_status=-CRCTO-STALLED, errcnt=0, actlen=8 pid=2d,addr=2,endpt=0,D=0,maxlen=8 TD(0xe67a48a0) at 0x0847a8a4 = link=0x0847a874 status=0x388003ff token=0x00e80269 buffer=0x01b1a170 TD(0xe67a48a0) td_next=-VF td_status=-ACTIVE-SPD, errcnt=3, actlen=0 pid=69,addr=2,endpt=0,D=1,maxlen=8 TD(0xe67a4870) at 0x0847a874 = link=0x00000001 status=0x198003ff token=0xffe802e1 buffer=0x00000000 TD(0xe67a4870) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=e1,addr=2,endpt=0,D=1,maxlen=0 uhci_non_isoc_done_sub:1173: error, addr=2, endpt=0x80, frame=0x00 status=[CRCTO][STALLED][NOT_ACTIVE] uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=22 _uhci_remove_qh:975: 0xc4330680 from 0xc4330680 uhci_device_done:1825: xfer=0xc431a0b8, pipe=0xc44c5380, error=5 _uhci_remove_qh:975: 0xc4330680 from 0xc42dab80 usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen1.2: <> at usbus1 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_root_ctrl_done:2673: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed8b8, pipe=0xc44e8380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ed0b8, pipe=0xc44e7380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ee0b8, pipe=0xc44e6380, error=0 uhci_set_hw_power:3335: uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 uhci_root_ctrl_start:2515: uhci_root_ctrl_done:2563: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1825: xfer=0xc44ef0b8, pipe=0xc44e5380, error=0 --fUYQa+Pmc3FrFX/N-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 23:05:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A186106564A; Thu, 22 Jan 2009 23:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2BAC88FC1E; Thu, 22 Jan 2009 23:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A0BDA41C74D; Fri, 23 Jan 2009 00:05:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id GjaNIKfF+WPO; Fri, 23 Jan 2009 00:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 3A0B841C650; Fri, 23 Jan 2009 00:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D4EB84448D5; Thu, 22 Jan 2009 23:03:02 +0000 (UTC) Date: Thu, 22 Jan 2009 23:03:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090122225404.U45399@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD net mailing list Subject: Need testers for a network cleanup patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 23:05:09 -0000 Hi, while cleaning up protosw things I found that rip6_output was most likely never called from pr_output and after a short talk with Robert the conclusion was that the same had been true for rip_output. Before I am going to remove the initializations I made the two rip{,6}_output functions calling panic(). I have a patch for HEAD here: http://people.freebsd.org/~bz/20090122-03-pr_output.diff and one for 7-STABLE here (compiled but not booted): http://people.freebsd.org/~bz/20090122-04-pr_output-7STABLE.diff I am confident it will not panic (at least for HEAD;) but not 100% sure so you can run this on your test or devel machine but I'd not run it on a production machine. If you are going to use the 7-STABLE patch make sure to have debugging support in your kernel as well so we could get backtraces in the unlikely event of panic. Please reply directly to me if you have (un)successfully run the patch and do NOT to the lists. In case you think you run it successfully mail me after a 2-3 days, and _not_ with an "it booted" message! ;-) Thanks for your help. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 04:03:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1039E106564A for ; Fri, 23 Jan 2009 04:03:07 +0000 (UTC) (envelope-from ptice@aldridge.com) Received: from starbase.aldridge.com (starbase.aldridge.com [205.196.186.12]) by mx1.freebsd.org (Postfix) with ESMTP id DDFCE8FC1B for ; Fri, 23 Jan 2009 04:03:06 +0000 (UTC) (envelope-from ptice@aldridge.com) Received: from corporate.aldridge.com (corporate.aldridge.com [216.139.69.10]) by starbase.aldridge.com (8.14.3/8.14.2) with ESMTP id n0N3c4Hr062583 for ; Thu, 22 Jan 2009 21:38:04 -0600 (CST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Jan 2009 21:33:48 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 Thread-Index: Acl9C2bqIzPM2CY1QEqux+U7ylKxuQ== From: "Paul Tice" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 04:03:07 -0000 I'm new, so please advise me (gently?) about list protocol and such if = needed. Using stock 8.0-CURRENT-200812-amd64, I am getting the messages below. I've run memtest 3.4 through 3 passes with no errors. I did go through an entire boot/install with no errors by setting all = caching to Write-Through in BIOS, but that leads to unacceptable = performance, and I'm not sure the slowness wasn't masking the problem. Motherboard is a Supermicro x7dvl3, 8G of RAM (4 x 2G matched within a = small range of serial numbers.) Chipset is an Intel 5000V with a ESB2 Southbridge. Cpu is 2 Quad core = Xeon 5400 Series @ 2GHz. This is a fairly new CPU with a larger cache = than previous Xeons (12Meg L2). The error occurs whether I use the LSI 1068E attached via PCI-E(x4) or = the ESB2 onboard SATA. I do not get the error when mounting another drive after booting, I do = see the same error when shutting down. I also notice (maybe related) text video corruption during shutdown. = (XGI Volari=99 Z7 PCI-E Graphics Processor) Am I too wordy, or did I forget something? Trying to mount root from ufs:/dev/ad20s1a lock order reversal: 1st 0xffffff0001701070 user map (user map) @ = /usr/src/sys/vm/vm_map.c:3115 2nd 0xffffff0001ea87f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip =3D 0x40014f, rsp =3D 0x7fffffffee70, rbp =3D = 0x7fffffffee90 --- Later in the boot sequence lock order reversal: 1st 0xfffffffec0491330 bufwait (bufwait) @ = /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xffffff0004163000 dirhash (dirhash) @ = /usr/src/sys/ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x889 ufs_makeinode() at ufs_makeinode+0x338 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x479 kern_openat() at kern_openat+0x169 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip =3D 0x800daceac, rsp =3D = 0x7fffffffe7c8, rbp =3D 0x8 --- Thanks Paul From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 07:13:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D015106564A for ; Fri, 23 Jan 2009 07:13:15 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 146EC8FC0A for ; Fri, 23 Jan 2009 07:13:15 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 39A44125422 for ; Fri, 23 Jan 2009 16:13:14 +0900 (JST) Message-ID: <49796E09.7000805@ongs.co.jp> Date: Fri, 23 Jan 2009 16:13:13 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: sparse file issue?, dd(1) works well but tar(1) not on different partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 07:13:15 -0000 Hi sparse guys (?) I have been wondering about sparse file transportation between different partitions on -current. For example, /localapps/qemu/ on local disk (UFS2) /nfshome/user/ on NFS (UFS2) /localapps/qemu/disk0image 20GB qemu diskimage sparsed file then, follow operation works well. # cd /localapps/qemu/ # tar cpf - disk0image | tar xpf - -C /nfshome/user/ # cd /nfshome/user/ # dd if=disk0image of=disk0image-sparse conv=sparse But # cd /localapps/qemu/ # tar cpf - disk0image | tar xpf - -S -C /nfshome/user/ gets follow error message. # tar cpf - disk0image | tar xpf - -S -C /nfshome/user/ disk0image: Write request too large tar: Error exit delayed from previous errors. # tar(1) cannot do sparse output between different partations? Have I missed something important point? If you have any ideas, teach me. Thanks :) -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 08:12:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2896106566C for ; Fri, 23 Jan 2009 08:12:50 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id AEB788FC16 for ; Fri, 23 Jan 2009 08:12:50 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0N8ClC1090338; Fri, 23 Jan 2009 00:12:48 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <49797BFD.3060805@freebsd.org> Date: Fri, 23 Jan 2009 00:12:45 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daichi GOTO References: <49796E09.7000805@ongs.co.jp> In-Reply-To: <49796E09.7000805@ongs.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: sparse file issue?, dd(1) works well but tar(1) not on different partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 08:12:51 -0000 Daichi GOTO wrote: > Hi sparse guys (?) > > I have been wondering about sparse file transportation between different > partitions on -current. For example, > > /localapps/qemu/ on local disk (UFS2) > /nfshome/user/ on NFS (UFS2) > > /localapps/qemu/disk0image 20GB qemu diskimage sparsed file > > then, follow operation works well. > > # cd /localapps/qemu/ > # tar cpf - disk0image | tar xpf - -C /nfshome/user/ > # cd /nfshome/user/ > # dd if=disk0image of=disk0image-sparse conv=sparse > > But > > # cd /localapps/qemu/ > # tar cpf - disk0image | tar xpf - -S -C /nfshome/user/ > > gets follow error message. > > # tar cpf - disk0image | tar xpf - -S -C /nfshome/user/ > disk0image: Write request too large > tar: Error exit delayed from previous errors. > # > > tar(1) cannot do sparse output between different partations? > Have I missed something important point? If you have any ideas, > teach me. Looks like I managed to break -S recently. I'll send you a patch soon. Tim From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 09:48:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89591065675; Fri, 23 Jan 2009 09:48:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 43A7D8FC14; Fri, 23 Jan 2009 09:48:58 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=hniE7hlO5cIxOTFzR2QA:9 a=vgCkZdFXIgtPvAFClxiBGK-xr_wA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 794964326; Fri, 23 Jan 2009 10:48:57 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Fri, 23 Jan 2009 10:51:14 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> <200901222209.51225.hselasky@c2i.net> <20090122212948.GA11441@citylink.fud.org.nz> In-Reply-To: <20090122212948.GA11441@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231051.18006.hselasky@c2i.net> Cc: current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 09:49:00 -0000 On Thursday 22 January 2009, Andrew Thompson wrote: > > > > You can try editing "uhci2.c" and change the "if ()" in: > > > > static void > > uhci_set_hw_power(struct usb2_bus *bus) > > > > to "if (1)". That will prevent the USB schedule from ever stopping. > > No change, log attached. Hi, Can you give me access to this box so that I can figure out what is going wrong? The patches I sent you have been tested on another machine and there all UHCI problems went away! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 09:49:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D0F1065672 for ; Fri, 23 Jan 2009 09:49:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2C18FC0A for ; Fri, 23 Jan 2009 09:49:41 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ysW5hgY2mRQA:10 a=LBZLMXZL60Qf9eqbQ9YA:9 a=ZBJ8hXtZZG6nIgTsluAaDX7M4JkA:4 a=zoKOyUDlhksA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1012219358; Fri, 23 Jan 2009 10:49:40 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Fri, 23 Jan 2009 10:52:05 +0100 User-Agent: KMail/1.9.7 References: <1421.1232314073@critter.freebsd.dk> <200901222209.51225.hselasky@c2i.net> <20090122212948.GA11441@citylink.fud.org.nz> In-Reply-To: <20090122212948.GA11441@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231052.05982.hselasky@c2i.net> Cc: current@freebsd.org Subject: Re: USB2 + ucom + UHCI: still not happy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 09:49:43 -0000 Beware that you might physically have to re-plug your devices before they work after loading UHCI! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 12:08:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1FC6106566C for ; Fri, 23 Jan 2009 12:08:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDD48FC14 for ; Fri, 23 Jan 2009 12:08:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0NC7wvp018181; Fri, 23 Jan 2009 12:07:59 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LQKpK-0005GC-ST; Fri, 23 Jan 2009 12:07:58 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n0NC7wiH029386; Fri, 23 Jan 2009 12:07:58 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n0NC7w8l029382; Fri, 23 Jan 2009 12:07:58 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Paul Tice In-Reply-To: References: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jan 2009 12:07:57 +0000 Message-Id: <1232712477.89022.7.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 12:08:09 -0000 On Thu, 2009-01-22 at 21:33 -0600, Paul Tice wrote: > I'm new, so please advise me (gently?) about list protocol and such if ne= eded. >=20 > Using stock 8.0-CURRENT-200812-amd64, I am getting the messages below. 8.0-CURRENT is essentially the bleeding-edge of FreeBSD, and is where development happens that has not necessarily proven itself as being stable. As it is the development branch, it also has a lot of extra debugging enabled, which is what you are seeing with the "lock order reversals". If you are not running 8-CURRENT for a specific reason (e.g. because you are doing FreeBSD OS development work, or you are prepared to help debug issues as you encounter them, or similar), you probably shouldn't be running CURRENT. Stick with 7.1. Gavin > I've run memtest 3.4 through 3 passes with no errors. > I did go through an entire boot/install with no errors by setting all cac= hing to Write-Through in BIOS, but that leads to unacceptable performance, = and I'm not sure the slowness wasn't masking the problem. > Motherboard is a Supermicro x7dvl3, 8G of RAM (4 x 2G matched within a sm= all range of serial numbers.) > Chipset is an Intel 5000V with a ESB2 Southbridge. Cpu is 2 Quad core Xeo= n 5400 Series @ 2GHz. This is a fairly new CPU with a larger cache than pre= vious Xeons (12Meg L2). > The error occurs whether I use the LSI 1068E attached via PCI-E(x4) or th= e ESB2 onboard SATA. > I do not get the error when mounting another drive after booting, I do se= e the same error when shutting down. > I also notice (maybe related) text video corruption during shutdown. (XGI= Volari=99 Z7 PCI-E Graphics Processor) >=20 > Am I too wordy, or did I forget something? >=20 >=20 > Trying to mount root from ufs:/dev/ad20s1a > lock order reversal: > 1st 0xffffff0001701070 user map (user map) @ /usr/src/sys/vm/vm_map.c:31= 15 > 2nd 0xffffff0001ea87f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xca8 > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x8b > vnode_pager_lock() at vnode_pager_lock+0x1d0 > vm_fault() at vm_fault+0x1e2 > trap_pfault() at trap_pfault+0x128 > trap() at trap+0x51c > calltrap() at calltrap+0x8 > --- trap 0xc, rip =3D 0x40014f, rsp =3D 0x7fffffffee70, rbp =3D 0x7ffffff= fee90 --- >=20 > Later in the boot sequence > lock order reversal: > 1st 0xfffffffec0491330 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2= 443 > 2nd 0xffffff0004163000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirh= ash.c:263 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_xlock() at _sx_xlock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_add() at ufsdirhash_add+0x19 > ufs_direnter() at ufs_direnter+0x889 > ufs_makeinode() at ufs_makeinode+0x338 > VOP_CREATE_APV() at VOP_CREATE_APV+0x8d > vn_open_cred() at vn_open_cred+0x479 > kern_openat() at kern_openat+0x169 > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (5, FreeBSD ELF64, open), rip =3D 0x800daceac, rsp =3D 0x7fff= ffffe7c8, rbp =3D 0x8 --- >=20 > Thanks > Paul > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 12:19:40 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C46F6106566B for ; Fri, 23 Jan 2009 12:19:40 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 58AD18FC0C for ; Fri, 23 Jan 2009 12:19:40 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0NCJYH0020575; Fri, 23 Jan 2009 12:19:34 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LQL0Y-0002RC-Md; Fri, 23 Jan 2009 12:19:34 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n0NCJYGx034332; Fri, 23 Jan 2009 12:19:34 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n0NCJYcn034331; Fri, 23 Jan 2009 12:19:34 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Paul Tice In-Reply-To: <1232712477.89022.7.camel@buffy.york.ac.uk> References: <1232712477.89022.7.camel@buffy.york.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 23 Jan 2009 12:19:34 +0000 Message-Id: <1232713174.89022.8.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 12:19:41 -0000 On Fri, 2009-01-23 at 12:07 +0000, Gavin Atkinson wrote: > On Thu, 2009-01-22 at 21:33 -0600, Paul Tice wrote: > > I'm new, so please advise me (gently?) about list protocol and such if needed. > > > > Using stock 8.0-CURRENT-200812-amd64, I am getting the messages below. > > 8.0-CURRENT is essentially the bleeding-edge of FreeBSD, and is where > development happens that has not necessarily proven itself as being > stable. As it is the development branch, it also has a lot of extra > debugging enabled, which is what you are seeing with the "lock order > reversals". > > If you are not running 8-CURRENT for a specific reason (e.g. because you > are doing FreeBSD OS development work, or you are prepared to help debug > issues as you encounter them, or similar), you probably shouldn't be > running CURRENT. Stick with 7.1. I should have also included (in answer to your actual question): Neither the lock order reversals or the corrupted messages on shutdown are anything you need worry about. Gavin From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 13:15:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2E71065672 for ; Fri, 23 Jan 2009 13:15:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD0B8FC14 for ; Fri, 23 Jan 2009 13:15:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.fastmail.fm (Postfix) with ESMTP id D76A02553F0; Fri, 23 Jan 2009 07:59:53 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 23 Jan 2009 07:59:53 -0500 X-Sasl-enc: 2xXT4Cf3a2VcUZFo/fK0+NY5sN7xyxUwerL1hcb6bZox 1232715593 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 618962DDA1; Fri, 23 Jan 2009 07:59:53 -0500 (EST) Message-ID: <4979BF48.7010704@FreeBSD.org> Date: Fri, 23 Jan 2009 12:59:52 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: John Baldwin References: <200811191503.02192.jhb@freebsd.org> <4937EC6D.7050703@FreeBSD.org> <200901211536.08297.jhb@freebsd.org> In-Reply-To: <200901211536.08297.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 13:15:59 -0000 John Baldwin wrote: > Try http://www.FreeBSD.org/~jhb/patches/ppc_mpsafe_7.patch It is a complete > backport generated against a fresh stable/7 tree. It does not need the > interrupt changes since my locking patches actually undo them. > > After applying this patch to 7.1-RELEASE: %%% ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port %%% ...I tried printing, didn't work, it seems /dev/lpt0 doesn't exist ? From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 13:41:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAC4106564A; Fri, 23 Jan 2009 13:41:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9048F8FC0A; Fri, 23 Jan 2009 13:41:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3C0C446B03; Fri, 23 Jan 2009 08:41:59 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0NDfpGp051549; Fri, 23 Jan 2009 08:41:51 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Bruce M. Simpson" Date: Fri, 23 Jan 2009 08:38:35 -0500 User-Agent: KMail/1.9.7 References: <200811191503.02192.jhb@freebsd.org> <200901211536.08297.jhb@freebsd.org> <4979BF48.7010704@FreeBSD.org> In-Reply-To: <4979BF48.7010704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901230838.35340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 23 Jan 2009 08:41:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8897/Fri Jan 23 07:59:36 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 13:42:00 -0000 On Friday 23 January 2009 7:59:52 am Bruce M. Simpson wrote: > John Baldwin wrote: > > Try http://www.FreeBSD.org/~jhb/patches/ppc_mpsafe_7.patch It is a complete > > backport generated against a fresh stable/7 tree. It does not need the > > interrupt changes since my locking patches actually undo them. > > > > > > After applying this patch to 7.1-RELEASE: > %%% > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppc0: [ITHREAD] > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > %%% > > ...I tried printing, didn't work, it seems /dev/lpt0 doesn't exist ? Hmm you don't see /dev/lpt0 and /dev/lpt0.ctl via ls(1)? The attach routine creates the devices via make_dev() right after the "interrupt-driven port" message. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 14:23:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BA01065678; Fri, 23 Jan 2009 14:23:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id B86938FC21; Fri, 23 Jan 2009 14:23:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.fastmail.fm (Postfix) with ESMTP id 5940525541B; Fri, 23 Jan 2009 09:23:01 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 23 Jan 2009 09:23:01 -0500 X-Sasl-enc: TYKSTzFd/qfz2nRPmcfUAtrDn5bltTR31eqV98AwB+gB 1232720580 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id BAC1524DBF; Fri, 23 Jan 2009 09:23:00 -0500 (EST) Message-ID: <4979D2C3.1050103@FreeBSD.org> Date: Fri, 23 Jan 2009 14:22:59 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: John Baldwin References: <200811191503.02192.jhb@freebsd.org> <200901211536.08297.jhb@freebsd.org> <4979BF48.7010704@FreeBSD.org> <200901230838.35340.jhb@freebsd.org> In-Reply-To: <200901230838.35340.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 14:23:02 -0000 John Baldwin wrote: > ... > Hmm you don't see /dev/lpt0 and /dev/lpt0.ctl via ls(1)? The attach routine > creates the devices via make_dev() right after the "interrupt-driven port" > message. > > I see /dev/lpt0.ctl, but not /dev/lpt0. data points: * The printer is a shonky old GCC Elite 600. * The BIOS is configured to expose LPT0 at "the usual ISA I/O address" w/interrupt mode 0x378 irq 7. * There are no error messages from lpt0 in dmesg, it does say lpt0: [MPSAFE]. * I load lpt.ko from loader.conf on boot. * If I try to kldunload lpt, it panics in destroy_devl() called from lpt_detach(). * I get the same results if the printer attached via lpt is switched on or off on boot. cups will just complain the printer isn't connected, as /dev/lpt0 doesn't exist. If I boot with bootverbose enabled, I see nothing which indicates that the make_dev() call has failed. From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 14:58:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E15D61065674; Fri, 23 Jan 2009 14:58:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id B660D8FC16; Fri, 23 Jan 2009 14:58:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.fastmail.fm (Postfix) with ESMTP id 3E0B0255B0C; Fri, 23 Jan 2009 09:58:12 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 23 Jan 2009 09:58:12 -0500 X-Sasl-enc: yxPY+HHK3kOmDDsy0g+ddfCe3XKoeUiskxGXPTFByEC5 1232722691 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 94B811B834; Fri, 23 Jan 2009 09:58:11 -0500 (EST) Message-ID: <4979DB00.10503@FreeBSD.org> Date: Fri, 23 Jan 2009 14:58:08 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: John Baldwin References: <200811191503.02192.jhb@freebsd.org> <200901211536.08297.jhb@freebsd.org> <4979BF48.7010704@FreeBSD.org> <200901230838.35340.jhb@freebsd.org> <4979D2C3.1050103@FreeBSD.org> In-Reply-To: <4979D2C3.1050103@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 14:58:13 -0000 Bruce M. Simpson wrote: > John Baldwin wrote: >> ... >> Hmm you don't see /dev/lpt0 and /dev/lpt0.ctl via ls(1)? The attach >> routine creates the devices via make_dev() right after the >> "interrupt-driven port" message. >> >> > > I see /dev/lpt0.ctl, but not /dev/lpt0. As per IRC convo: * I instrumented lpt_attach() to clean up if it can't create the cdevs. * If I then kldload lpt after boot in single-user, and ls /dev, the ls process hangs inside devfs_populate_loop(). Something really fishy is going on. I don't see this issue with devfs if I load lpt from the loader, however, lpt0 doesn't appear there either. I still see the destroy_devl() panic if I kldunload lpt. This probably shouldn't be MFCed until this can get sorted out... in the meantime, this is my home repo box / smb / print server, need it up, and need to fix the total RAID meltdown I experienced yesterday after first trying this patch (I don't think this patch is to blame here), so, back to work :/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 15:43:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 396841065719 for ; Fri, 23 Jan 2009 15:43:39 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 270AF8FC4D for ; Fri, 23 Jan 2009 15:43:37 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 8D1E43A6C6; Fri, 23 Jan 2009 16:43:36 +0100 (CET) Date: Fri, 23 Jan 2009 16:43:36 +0100 From: Lars Engels To: current@freebsd.org Message-ID: <20090123154336.GJ60948@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vA66WO2vHvL/CRSR" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: hselasky@c2i.net Subject: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 15:43:40 -0000 --vA66WO2vHvL/CRSR Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On yesterday's CURRENT I got the following panic while booting: lars@pts/3 # kgdb /usr/obj/usr/src/sys/USB2/kernel.debug /var/crash/vmcore.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1: Fri Jan 23 01:30:01 CET 2009 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/USB2 WARNING: WITNESS option enabled, expect reduced performance. module_register: module cpu/ichss already exists! Module cpu/ichss failed to register: 17 module_register: module cpu/est already exists! Module cpu/est failed to register: 17 module_register: module cpu/p4tcc already exists! Module cpu/p4tcc failed to register: 17 module_register: module cpu/powernow already exists! Module cpu/powernow failed to register: 17 module_register: module cpu/smist already exists! Module cpu/smist failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.52-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Stepping =3D 8 Features=3D0xbfe9fbff Features2=3D0xc189 AMD Features=3D0x100000 TSC: P-state invariant Cores per package: 2 real memory =3D 1063845888 (1014 MB) avail memory =3D 1022652416 (975 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817f= fff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 o= n pci0 hdac0: mem 0xd8240000-0xd82= 43fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090113_0125 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 wpi0: mem 0xd4000000-0xd4000fff irq 16 at d= evice 0.0 on pci2 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) adding chan 1 (2412MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 2 [...] pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 at device = 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 19 at device = 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 18 at device = 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2: on uhci2 uhci3: port 0x1880-0x189f irq 16 at device = 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x2f00 usbus3: on uhci3 ehci0: mem 0xd8444000-0xd84443f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 = at device 5.0 on pci5 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:00:f0:7f:da:00 bfe0: [ITHREAD] cbb0: at device 9.0 on pci5 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:20:0f:ab:79 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1484000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:0f:ab:79 fwe0: Ethernet address: 02:00:f0:0f:ab:79 fwip0: on firewire0 fwip0: Firewire address: 00:00:f0:41:20:0f:ab:79 @ 0xfffe00000000, S400, ma= xrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode sdhci0: mem 0xd8002800-0xd80028ff at device 9.2 on pci5 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) usbus4: 480Mbps High Speed USB v2.0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 ushub0: on usbus0 ugen1.1: at usbus1 ushub1: on usbus1 ugen2.1: at usbus2 ushub2: on usbus2 ugen3.1: at usbus3 ushub3: on usbus3 ugen4.1: at usbus4 ushub4: on usbus4 ad0: 114473MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) hdac0: hdac_widget_connection_parse: nid=3D18 WARNING: zero cnid entnum=3D4= j=3D2 index=3D0 entries=3D8 found=3D2 res=3D0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 GEOM_LABEL: Label for provider ad0s1 is ntfs/Windows. GEOM: ad0s2: geometry does not match label (255h,63s !=3D 16h,63s). ushub0: 2 ports with 2 removable, self powered ushub1: 2 ports with 2 removable, self powered ushub2: 2 ports with 2 removable, self powered ushub3: 2 ports with 2 removable, self powered ushub4: 8 ports with 8 removable, self powered acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 (probe0:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:1:0): CAM Status: SCSI Status Error (probe0:ata0:0:1:0): SCSI Status: Check Condition (probe0:ata0:0:1:0): NOT READY asc:3a,1 (probe0:ata0:0:1:0): Medium not present - tray closed (probe0:ata0:0:1:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 (probe0:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:1:0): CAM Status: SCSI Status Error (probe0:ata0:0:1:0): SCSI Status: Check Condition (probe0:ata0:0:1:0): NOT READY asc:3a,1 (probe0:ata0:0:1:0): Medium not present - tray closed (probe0:ata0:0:1:0): Unretryable error cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /: GJOURNAL flag on fs but no gjournal provider below lock order reversal: 1st 0xc459a044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xc49cdad0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0c2b1d3,c419890c,c0898635,4,c0c2675b,...) at db_trac= e_self_wrapper+0x26 kdb_backtrace(4,c0c2675b,c4521728,c4527708,c4198968,...) at kdb_backtrace+0= x29 _witness_debugger(c0c2def8,c49cdad0,c0c217cc,c4527708,c0c34bd5,...) at _wit= ness_debugger+0x25 witness_checkorder(c49cdad0,1,c0c34bd5,81f,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c49cdad0,200501,c49cdaec,0,0,...) at __lockmgr_args+0x237 ffs_lock(c4198a78,c08983db,c0c50c7f,200501,c49cda78,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d2fb80,c4198a78,c4596e24,c0d43ca0,c49cda78,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c49cda78,200501,c0c34bd5,81f,4,...) at _vn_lock+0x5e vget(c49cda78,200501,c4596d80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c4ae8e0c,0,c0c4e265,127,c4198c18,...) at vnode_pager_lock+= 0x1e0 vm_fault(c459a000,80bd000,2,8,80bd000,...) at vm_fault+0x1df trap_pfault(5,0,c0c5e3d4,2e7,c4594d34,...) at trap_pfault+0x118 trap(c4198d38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0x80480e5, esp =3D 0xbfbfeef0, ebp =3D 0xbfbfef10 --- ugen2.2: at usbus2 ubt0: on usbus2 <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>/dev/ad0s2a: DEFER FOR BACKGROUND CHECKING <118>/dev/ad0s2d: DEFER FOR BACKGROUND CHECKING <118>/dev/ad0s2e: DEFER FOR BACKGROUND CHECKING <118>/dev/ad0s2f: DEFER FOR BACKGROUND CHECKING WARNING: / was not properly dismounted WARNING: /var was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted ath0: mem 0x88000000-0x8800ffff irq 20 at device 0.0 on card= bus0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 5.9 phy 4.3 radio 3.6 wlan1: Ethernet address: 00:13:02:3f:0d:e4 wlan0: Ethernet address: 00:0f:b5:9a:47:47 <118>Starting wpa_supplicant. <118>Starting Network: lo0. <118>/etc/rc: INFO: pf kernel module loaded. <118>No ALTQ support in kernel <118>ALTQ related functions disabled <118>No ALTQ support in kernel <118>ALTQ related functions disabled <118>No ALTQ support in kernel <118>ALTQ related functions disabled <118>pf enabled <118>route: <118>writing to routing socket <118>: <118>Network is unreachable <118>add net default: gateway 192.168.2.1: Network is unreachable <118>ifconfig: <118>create: bad value <118> <118>ifconfig: <118>create: bad value <118> <118>/etc/rc.d/bluetooth: INFO: ng_l2cap kernel module loaded. WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() <118>/etc/rc.d/bluetooth: INFO: ng_btsocket kernel module loaded. WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ubt if1 (ubt if1) r =3D 0 (0xc4ab3e44) locked @ /usr/= src/sys/dev/usb2/core/usb2_transfer.c:1804 KDB: stack backtrace: db_trace_self_wrapper(c0c2b1d3,f12eab00,c0898635,c0c183f9,70c,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0c183f9,70c,ffffffff,c0eb781c,f12eab38,...) at kdb_backtrace= +0x29 _witness_debugger(c0c2d4a4,f12eab4c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c5e3d4,f12eab80,c4a717ec,...) at witness_warn+0x1fd trap(f12eabd8) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc11aa052, esp =3D 0xf12eac18, ebp =3D 0xf12eac54 --- ubt_isoc_read_callback(c4b8b0b8,ffffffff,c0c183f9,99e,c0eb7818,...) at ubt_= isoc_read_callback+0x22 usb2_callback_wrapper(c4b8b014,70d,0,c4b8b000,c4b8b000,...) at usb2_callbac= k_wrapper+0x61a usb2_command_wrapper(c4b8b014,0,c0c183f9,70d,c4b8b028,...) at usb2_command_= wrapper+0x116 usb2_callback_proc(c4b8b028,c47ace70,c0c17faf,51,c0d7b3c0,...) at usb2_call= back_proc+0x9b usb2_process(c47acda0,f12ead38,c0c23f3b,32d,c4a717ec,...) at usb2_process+0= xde fork_exit(c0793fb0,c47acda0,f12ead38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xf12ead70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xdeadc1ba fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc11aa052 stack pointer =3D 0x28:0xf12eac18 frame pointer =3D 0x28:0xf12eac54 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 26 (USBPROC) lock order reversal: (Giant after non-sleepable) 1st 0xc4ab3e44 ubt if1 (ubt if1) @ /usr/src/sys/dev/usb2/core/usb2_transfe= r.c:1804 2nd 0xc0d76e90 Giant (Giant) @ /usr/src/sys/dev/kbdmux/kbdmux.c:1044 KDB: stack backtrace: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 cpuid =3D 0 Uptime: 20s Physical memory: 998 MB Dumping 59 MB: 44 28 12 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko [...] Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot= /kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc085923e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 20 #2 0xc0859512 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0849fc7 in _mtx_assert (m=3D0xc0d76e90, what=3D4, file=3D0xc0c30b4c = "/usr/src/sys/kern/tty_ttydisc.c", line=3D1127) at /usr/src/sys/kern/kern_m= utex.c:639 #4 0xc08aebad in ttydisc_getc (tp=3D0xc4650c00, buf=3D0xf12ea920, len=3D12= 8) at /usr/src/sys/kern/tty_ttydisc.c:1127 #5 0xc0740604 in sctty_outwakeup (tp=3D0xc4650c00) at /usr/src/sys/dev/sys= cons/syscons.c:323 #6 0xc0740b6c in scgetc (sc=3D0xc0f11f20, flags=3D3) at /usr/src/sys/dev/s= yscons/syscons.c:3281 #7 0xc0741190 in sc_cngetc (cd=3D0xc0cc9be0) at /usr/src/sys/dev/syscons/s= yscons.c:1607 #8 0xc0821a28 in cncheckc () at /usr/src/sys/kern/kern_cons.c:379 #9 0xc0821a66 in cngetc () at /usr/src/sys/kern/kern_cons.c:357 #10 0xc04bfb15 in db_readline (lstart=3D0xc0d45cc0 "\n", lsize=3D120) at /u= sr/src/sys/ddb/db_input.c:326 #11 0xc04c04ea in db_read_line () at /usr/src/sys/ddb/db_lex.c:56 #12 0xc04be796 in db_command_loop () at /usr/src/sys/ddb/db_command.c:496 #13 0xc04c060d in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= =2Ec:229 #14 0xc0886be6 in kdb_trap (type=3D12, code=3D0, tf=3D0xf12eabd8) at /usr/s= rc/sys/kern/subr_kdb.c:534 #15 0xc0b5af2f in trap_fatal (frame=3D0xf12eabd8, eva=3D3735929274) at /usr= /src/sys/i386/i386/trap.c:920 #16 0xc0b5b860 in trap (frame=3D0xf12eabd8) at /usr/src/sys/i386/i386/trap.= c:318 #17 0xc0b3fb3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #18 0xc11aa052 in ubt_isoc_read_callback () from /boot/kernel/usb2_bluetoot= h_ng.ko #19 0xc079908a in usb2_callback_wrapper (pq=3D0xc4b8b014) at /usr/src/sys/d= ev/usb2/core/usb2_transfer.c:1934 #20 0xc07969d6 in usb2_command_wrapper (pq=3D0xc4b8b014, xfer=3D0x0) at /us= r/src/sys/dev/usb2/core/usb2_transfer.c:2514 #21 0xc0796abb in usb2_callback_proc (_pm=3D0xc4b8b028) at /usr/src/sys/dev= /usb2/core/usb2_transfer.c:1808 #22 0xc079408e in usb2_process (arg=3D0xc47acda0) at /usr/src/sys/dev/usb2/= core/usb2_process.c:139 #23 0xc0836228 in fork_exit (callout=3D0xc0793fb0 , arg=3D0xc= 47acda0, frame=3D0xf12ead38) at /usr/src/sys/kern/kern_fork.c:821 #24 0xc0b3fbb0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --vA66WO2vHvL/CRSR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl55agACgkQKc512sD3afjmqgCeNtyjkXGhkPtoAv8Dxb9uguaF 4eEAnitjmpoiPBx13rvajsIIqSD1fV9Q =IhJ8 -----END PGP SIGNATURE----- --vA66WO2vHvL/CRSR-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 15:50:26 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D79F10656E7; Fri, 23 Jan 2009 15:50:26 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id BC8CF8FC1A; Fri, 23 Jan 2009 15:50:25 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.fastmail.fm (Postfix) with ESMTP id 4EF86255F92; Fri, 23 Jan 2009 10:50:25 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 23 Jan 2009 10:50:25 -0500 X-Sasl-enc: sg+74CyR7CMQLFlDHufPLO4TF7AjKgC3ef+JGYaT+04L 1232725824 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A8DB31DE65; Fri, 23 Jan 2009 10:50:24 -0500 (EST) Message-ID: <4979E73F.6000306@FreeBSD.org> Date: Fri, 23 Jan 2009 15:50:23 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: John Baldwin References: <200811191503.02192.jhb@freebsd.org> <200901211536.08297.jhb@freebsd.org> <4979BF48.7010704@FreeBSD.org> <200901230838.35340.jhb@freebsd.org> <4979D2C3.1050103@FreeBSD.org> <4979DB00.10503@FreeBSD.org> In-Reply-To: <4979DB00.10503@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------040409010905030409070600" Cc: current@freebsd.org Subject: Re: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 15:50:26 -0000 This is a multi-part message in MIME format. --------------040409010905030409070600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here's a diff with my edits. With these changes, the printer keeps being reported as busy, although I seem to be able to write to the /dev/lpt0 device, and it is seen. As Ed Schouten pointed out on IRC probably this unit2minor stuff needs to go back in. Back to work for this machine... --------------040409010905030409070600 Content-Type: text/plain; name="lpt.c.mine.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lpt.c.mine.diff" --- lpt.c.jhb 2009-01-23 14:31:43.000000000 +0000 +++ lpt.c 2009-01-23 15:21:08.000000000 +0000 @@ -140,6 +140,7 @@ static timeout_t lptout; static int lpt_port_test(device_t dev, u_char data, u_char mask); +static int lpt_detach(device_t dev); static int lpt_detect(device_t dev); #define DEVTOSOFTC(dev) \ @@ -408,12 +409,22 @@ sc->sc_inbuf = malloc(BUFSIZE, M_DEVBUF, M_WAITOK); sc->sc_statbuf = malloc(BUFSTATSIZE, M_DEVBUF, M_WAITOK); sc->sc_dev = dev; - sc->sc_cdev = make_dev(&lpt_cdevsw, unit, + sc->sc_cdev = make_dev(&lpt_cdevsw, unit * 2, UID_ROOT, GID_WHEEL, 0600, LPT_NAME "%d", unit); + if (sc->sc_cdev == NULL) { + device_printf(dev, "Unable to create data device node\n"); + (void)lpt_detach(dev); + return (ENXIO); + } sc->sc_cdev->si_drv1 = sc; sc->sc_cdev->si_drv2 = 0; - sc->sc_cdev_bypass = make_dev(&lpt_cdevsw, unit, + sc->sc_cdev_bypass = make_dev(&lpt_cdevsw, (unit * 2) + 1, UID_ROOT, GID_WHEEL, 0600, LPT_NAME "%d.ctl", unit); + if (sc->sc_cdev_bypass == NULL) { + device_printf(dev, "Unable to create control device node\n"); + (void)lpt_detach(dev); + return (ENXIO); + } sc->sc_cdev_bypass->si_drv1 = sc; sc->sc_cdev_bypass->si_drv2 = (void *)LP_BYPASS; return (0); @@ -425,8 +436,10 @@ struct lpt_data *sc = DEVTOSOFTC(dev); device_t ppbus = device_get_parent(dev); - destroy_dev(sc->sc_cdev); - destroy_dev(sc->sc_cdev_bypass); + if (sc->sc_cdev) + destroy_dev(sc->sc_cdev); + if (sc->sc_cdev_bypass) + destroy_dev(sc->sc_cdev_bypass); ppb_lock(ppbus); lpt_release_ppbus(dev); ppb_unlock(ppbus); --------------040409010905030409070600-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 16:12:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B57F106567F for ; Fri, 23 Jan 2009 16:12:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 12EE28FC1A for ; Fri, 23 Jan 2009 16:12:17 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=R5hmtHOM2o5w57mSNgIA:9 a=swhdr4_KSqgHU6vSpSL3Xee3obUA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1184526535; Fri, 23 Jan 2009 17:12:15 +0100 From: Hans Petter Selasky To: Lars Engels Date: Fri, 23 Jan 2009 17:14:38 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> In-Reply-To: <20090123154336.GJ60948@e.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231714.39873.hselasky@c2i.net> Cc: current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 16:12:19 -0000 On Friday 23 January 2009, Lars Engels wrote: > 0xf12eabd8) at /usr/src/sys/i386/i386/trap.c:318 > #17 0xc0b3fb3b in Hi Lars, Maksim has made a lot of changes to the Bluetooth driver. Maybe he can look into it? This looks like a NULL-pointer access to me. Maksim: In the ubt_detach routine, make sure that: 0) No further commands are accepted from the Netgraph stack. 1) You drain the task queue! 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. 3) Set the "sc_node" to NULL. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 16:29:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4176B10656C9; Fri, 23 Jan 2009 16:29:22 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id D092D8FC08; Fri, 23 Jan 2009 16:29:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 832841D026; Fri, 23 Jan 2009 17:29:20 +0100 (CET) Date: Fri, 23 Jan 2009 17:29:20 +0100 From: Ed Schouten To: Lars Engels Message-ID: <20090123162920.GT41248@hoeg.nl> References: <20090123154336.GJ60948@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FiqEyLLt06qkB6ow" Content-Disposition: inline In-Reply-To: <20090123154336.GJ60948@e.0x20.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 16:29:24 -0000 --FiqEyLLt06qkB6ow Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Lars, As HPS said, the issue seems to be related to ubt, but there's still something else that is interesting to see here: * Lars Engels wrote: > #2 0xc0859512 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc0849fc7 in _mtx_assert (m=3D0xc0d76e90, what=3D4, file=3D0xc0c30b4= c "/usr/src/sys/kern/tty_ttydisc.c", line=3D1127) at /usr/src/sys/kern/kern= _mutex.c:639 > #4 0xc08aebad in ttydisc_getc (tp=3D0xc4650c00, buf=3D0xf12ea920, len=3D= 128) at /usr/src/sys/kern/tty_ttydisc.c:1127 > #5 0xc0740604 in sctty_outwakeup (tp=3D0xc4650c00) at /usr/src/sys/dev/s= yscons/syscons.c:323 > #6 0xc0740b6c in scgetc (sc=3D0xc0f11f20, flags=3D3) at /usr/src/sys/dev= /syscons/syscons.c:3281 > #7 0xc0741190 in sc_cngetc (cd=3D0xc0cc9be0) at /usr/src/sys/dev/syscons= /syscons.c:1607 > #8 0xc0821a28 in cncheckc () at /usr/src/sys/kern/kern_cons.c:379 > #9 0xc0821a66 in cngetc () at /usr/src/sys/kern/kern_cons.c:357 > #10 0xc04bfb15 in db_readline (lstart=3D0xc0d45cc0 "\n", lsize=3D120) at = /usr/src/sys/ddb/db_input.c:326 Sam Leffler also reported this issue to me privately. I'll see what I can do to fix this. --=20 Ed Schouten WWW: http://80386.nl/ --FiqEyLLt06qkB6ow Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl58GAACgkQ52SDGA2eCwVv7gCfX4h964hwopuUwWYjsQI+Dodf QmgAnRdYF1F3kVq5aMBFOfAB+hxsSXzg =JBi8 -----END PGP SIGNATURE----- --FiqEyLLt06qkB6ow-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 18:05:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD38C1065670 for ; Fri, 23 Jan 2009 18:05:57 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 60E3B8FC0A for ; Fri, 23 Jan 2009 18:05:57 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knopdnsimu13l.kn.op.dlr.de ([129.247.178.118]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 19:05:55 +0100 Date: Fri, 23 Jan 2009 19:02:07 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knopdnsimu13l.kn.op.dlr.de To: harti@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3030779680-1567109463-1232733730=:1173" X-OriginalArrivalTime: 23 Jan 2009 18:05:55.0283 (UTC) FILETIME=[3C50F230:01C97D85] Cc: current@freebsd.org Subject: Re: problem with nss_ldap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 18:05:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3030779680-1567109463-1232733730=:1173 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 18 Jan 2009, Hartmut.Brandt@dlr.de wrote: > Hi, > > for a year or so I had nss_ldap connected to an active directory (with openldap23-sasl-client) on a year-old current. Yesterday I've rebuilt everything and I started to get 'undefined symbols' (for example gss_equal_oid) when running any program needing pw or group entries. After some poking around I fixed these by adding -lgssapi to the Makefiles for libgssapi_krb5.so and libgssap_spnego.so. Now getent, local login and everything works fine, except cron and sshd. > > Both create entries in /var/log/messages like: > > Jan 18 20:00:02 knopdnsimu13f cron[1495]: GSSAPI Error: Miscellaneous failure (see text)???????????????ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ > Jan 18 20:00:02 knopdnsimu13f kernel: ZZZZZZZZZZZZZZZZ > > I've tried to figure out in which of the dozens of layered libraries (gss, sasl, ssl, ......) this error is generated but did not find anything. > > This is on amd64, krb5 enabled in pam, gssapi disabled in sshd_config (as I said, this worked before). So to answer my own mail: I made a link from the kerberos ticket file which contains the host ticket (and is specified in nss_ldap.conf) to /tmp/krb5cc_0. I've no idea why this is suddenly necessary, though. harti > > Any ideas? > harti > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > --3030779680-1567109463-1232733730=:1173-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 18:08:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B601065674 for ; Fri, 23 Jan 2009 18:08:52 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 063798FC19 for ; Fri, 23 Jan 2009 18:08:51 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4929792rvf.43 for ; Fri, 23 Jan 2009 10:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IZpilAdi1saqEdbCX906AGqIWCjPuwy+1/H8f8h2L7E=; b=S5GjFwmVl//634ZecQFrYoxyf4eOK9Ir9y4q1QdWjIIAPnyZML4M7YlLCyAevmswQk PyU8dYU+xakCq3TnViOnTdGwPeMtNbpAy1HZN7hvPP7HstnYqkxiqtN2ytClmIm/RHmu IKo5te/d9PLd00lBx63maAbzbA48uKqA0Da0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G+rN3UQ9rYpxLbV/atlJIUDnjNR/e5RfmR0cTk94Qbt2B3kMOALjouf/uTPgoUCNRI wXwo0cmltyYIHKBp2v/feyJjfSs8Jiw50PAaveVZqjsi/2lG3VFd4hqUuUMDVFM4VfiB hUqYce9KoQtDzUNkqexQ2DM4GKSATsmjCq4Fo= MIME-Version: 1.0 Received: by 10.141.171.3 with SMTP id y3mr5245101rvo.263.1232732834127; Fri, 23 Jan 2009 09:47:14 -0800 (PST) In-Reply-To: <200901231714.39873.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901231714.39873.hselasky@c2i.net> Date: Fri, 23 Jan 2009 09:47:14 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lars Engels , current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 18:08:52 -0000 hello, > Maksim has made a lot of changes to the Bluetooth driver. Maybe he can look > into it? yes, i will take a look at it. > > This looks like a NULL-pointer access to me. > > Maksim: > > In the ubt_detach routine, make sure that: > > 0) No further commands are accepted from the Netgraph stack. yes, we do that. > 1) You drain the task queue! that should not be needed (in theory) but i will add it. > 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. yes, usb2_transfer_unsetup() does that, does it not? > 3) Set the "sc_node" to NULL. yes, we do that too. i have lots of questions about stalled transfers. in any case, it appears that my code is wrong when it comes to stalled transfers. in particular, usb2_clear_stall_callback() returns 0 in both USB_ST_SETUP and default/error cases, so the code incorrectly clears node reference in USB_ST_SETUP case. that needs to be fixed. i'm also deeply confused about error handling in transfers. in particular, any error that is not USB_ERR_CANCELLED makes code to assume that it was a stall and queue clear stall transfer. that is clearly not the case when hardware is yanked while transfer is active. in this case transfer callback seems to be called with USB_ERR_IOERROR (or something like that). so, shouldn't we be safe and only queue stall transfer if callback was in fact called with USB_ERR_STALLED? the completely different question here is why stall happens in the first place. also as others pointed out, panic in ttydisc_getc is something else. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 18:33:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785481065673 for ; Fri, 23 Jan 2009 18:33:39 +0000 (UTC) (envelope-from ptice@aldridge.com) Received: from starbase.aldridge.com (starbase.aldridge.com [205.196.186.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2EE8FC14 for ; Fri, 23 Jan 2009 18:33:39 +0000 (UTC) (envelope-from ptice@aldridge.com) Received: from corporate.aldridge.com (corporate.aldridge.com [216.139.69.10]) by starbase.aldridge.com (8.14.3/8.14.2) with ESMTP id n0NIWnXL040785; Fri, 23 Jan 2009 12:32:49 -0600 (CST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Jan 2009 12:28:33 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 Thread-Index: Acl9VCdrlOkSkRUXT3Gt9YKpkKDnFQAMr0/h References: <1232712477.89022.7.camel@buffy.york.ac.uk> <1232713174.89022.8.camel@buffy.york.ac.uk> From: "Paul Tice" To: "Gavin Atkinson" , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 18:33:39 -0000 -----Original Message----- From: Gavin Atkinson [mailto:gavin@FreeBSD.org] Sent: Fri 1/23/2009 6:19 AM To: Paul Tice Cc: freebsd-current@FreeBSD.org Subject: Re: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 =20 On Fri, 2009-01-23 at 12:07 +0000, Gavin Atkinson wrote: > On Thu, 2009-01-22 at 21:33 -0600, Paul Tice wrote: > > I'm new, so please advise me (gently?) about list protocol and such = if needed. > >=20 > > Using stock 8.0-CURRENT-200812-amd64, I am getting the messages = below. >=20 > 8.0-CURRENT is essentially the bleeding-edge of FreeBSD, and is where > development happens that has not necessarily proven itself as being > stable. As it is the development branch, it also has a lot of extra > debugging enabled, which is what you are seeing with the "lock order > reversals". >=20 > If you are not running 8-CURRENT for a specific reason (e.g. because = you > are doing FreeBSD OS development work, or you are prepared to help = debug > issues as you encounter them, or similar), you probably shouldn't be > running CURRENT. Stick with 7.1. >I should have also included (in answer to your actual question): >Neither the lock order reversals or the corrupted messages on shutdown >are anything you need worry about. >Gavin I wouldn't have asked if I wasn't willing to help debug (as possible, = and with very little coding knowledge.) I pulled out the 'extra debugging', made world and kernel, and rebooted. Notice the 5th line of da7's drive ID being interleaved with 'SMP: AP = CPU #1 Launched!' I'm fairly sure this is not a good thing, if for no other reason that = 'apparent garbage' in dmesg is not useful. da6 at mpt0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device=20 da6: 300.000MB/s transfers da6: Command Queueing Enabled da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da7 at mpt0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device=20 da7: 300.000MB/s transfers da7: Command Queueing Enabled da7: 715404MB (1465149168 512 bytSeM Ps:e cAtPo rCsP:U 2#515 HL = a6u3nSc/hTe d9!12 01C) SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! Trying to mount root from ufs:/dev/ad20s1a Thank You Paul From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 19:08:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1831C106568C for ; Fri, 23 Jan 2009 19:08:15 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9818FC40 for ; Fri, 23 Jan 2009 19:08:14 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.147.234] (port=46373 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LQRO0-000DdP-8V for freebsd-current@FreeBSD.org; Fri, 23 Jan 2009 22:08:12 +0300 Message-ID: <497A159B.5050404@lissyara.su> Date: Fri, 23 Jan 2009 22:08:11 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.19) Gecko/20090110 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: acpi_throttle1: failed to attach P_CNT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 19:08:15 -0000 After last update I have in dmesg acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 When I build somesing - laptop shutdown, because CPU temp > 105 Celsius HP# uname -a FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Jan 22 19:49:57 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/HP amd64 HP# Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Thu Jan 22 19:49:57 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/HP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (1994.91-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 1995911168 (1903 MB) avail memory = 1927376896 (1838 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ 8800] [ 0 8100], using 64X [20070320] ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, 8000000 (3) failed acpi0: reservation of 100000, fff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x4000-0x40ff mem 0xc0000000-0xc7ffffff,0xd0200000-0xd020ffff,0xd0300000-0xd03fffff irq 19 at device 5.0 on pci1 acpi_video0: on vgapci0 pcib2: at device 4.0 on pci0 pci16: on pcib2 bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bge0: Ethernet address: 00:1f:29:89:38:f3 bge0: [ITHREAD] pcib3: at device 5.0 on pci0 pci32: on pcib3 pcib4: at device 6.0 on pci0 pci48: on pcib4 bwi0: mem 0xc8000000-0xc8003fff irq 18 at device 0.0 on pci48 bwi0: [ITHREAD] bwi0: regwin: type 0x800, rev 19, vendor 0x4243 bwi0: BBP: id 0x4311, rev 0x2, pkg 0 bwi0: nregwin 4, cap 0x0864000d bwi0: regwin: type 0x812, rev 13, vendor 0x4243 bwi0: MAC: rev 13 bwi0: regwin: type 0x817, rev 4, vendor 0x4243 bwi0: regwin: type 0x820, rev 5, vendor 0x4243 bwi0: clksrc CS_OSC bwi0: clkfreq min 990000, max 1010000 bwi0: power on delay 3 bwi0: bus rev 6 bwi0: PCIE is enabled bwi0: card flags 0x4a49 bwi0: 0th led, act 2, lowact 0 bwi0: 1th led, act 3, lowact 1 bwi0: 2th led, act 4, lowact 0 bwi0: 3th led, act 0, lowact 0 bwi0: MAC was already disabled bwi0: PHY is linked bwi0: PHY: type 2, rev 9, ver 4 bwi0: PHY: 11G attach bwi0: RF: manu 0x17f, type 0x2050, rev 2 bwi0: bus rev 6 bwi0: PHY is linked bwi0: 64bit bus space bwi0: max txpower from sprom: 74 dBm bwi0: ant gain 8 dBm bwi0: region/domain max txpower 76 dBm bwi0: max txpower 74 dBm bwi0: sprom idle tssi: 0x783e bwi0: TSSI-TX power map: 83 83 82 82 82 82 81 81 80 80 79 79 79 78 78 77 77 76 75 75 74 74 73 73 72 72 71 70 69 69 68 67 66 65 64 64 62 61 60 59 58 57 55 54 52 51 49 48 46 45 42 41 38 36 33 31 28 25 22 19 15 11 6 2 bwi0: idle tssi0: 62 bwi0: bus rev 6 bwi0: locale: 0 bwi0: WARNING: using obsoleted if_watchdog interface atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci0 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci0 ata5: port not implemented ata5: [ITHREAD] ohci0: mem 0xd0401000-0xd0401fff irq 23 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xd0402000-0xd0402fff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xd0403000-0xd0403fff irq 17 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xd0404000-0xd0404fff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xd0405000-0xd0405fff irq 17 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0406000-0xd04060ff irq 23 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090113_0125 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci2: on pcib5 cbb0: mem 0xd0100000-0xd0100fff irq 20 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x73 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 orm0: at iomem 0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ugen0: on uhub0 ums0: on uhub1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec cpufreq0: rejecting change, SMP not started yet acpi_tz0: failed to set new freq, disabling passive cooling acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master SATA300 hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: at cad 0 nid 1 on hdac0 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a lock order reversal: 1st 0xffffff0002322070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff00029107f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. lock order reversal: 1st 0xfffffffe66c80bf8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xffffff0002975400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x338 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x479 kern_openat() at kern_openat+0x169 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip = 0x80155bd1c, rsp = 0x7fffffffddf8, rbp = 0x11 --- WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. wlan0: Ethernet address: 00:00:00:21:00:0a ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled lock order reversal: 1st 0xffffff0005603d80 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1047 2nd 0xffffff0002e9d620 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b devfs_allocv() at devfs_allocv+0x10c devfs_root() at devfs_root+0x52 vfs_donmount() at vfs_donmount+0x1106 nmount() at nmount+0xa6 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007a5cdc, rsp = 0x7fffffffdda8, rbp = 0x800a04048 --- WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() lock order reversal: 1st 0xffffff0002df8650 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff00051c29d0 tmpfs (tmpfs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x401705, rsp = 0x7fffffffeb80, rbp = 0x80106c000 --- fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading RS690/RS740 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] lock order reversal: 1st 0xffffff000508d848 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xffffff00058ea098 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4065 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 knlist_remove_kq() at knlist_remove_kq+0x73 knote_fdclose() at knote_fdclose+0x177 kern_close() at kern_close+0xe6 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (6, FreeBSD ELF64, close), rip = 0x80108bc2c, rsp = 0x7fffffffe6c8, rbp = 0x802563840 --- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 19:12:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DFE106564A; Fri, 23 Jan 2009 19:12:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9449C8FC1E; Fri, 23 Jan 2009 19:12:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4955990rvf.43 for ; Fri, 23 Jan 2009 11:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7eHRUhigtyV5gmsb7iT4hMaH+k55+IMX8Roey37Fv9k=; b=SCCd1H+tABkfV8Vj1hlJH4wgDmqHAMFliEHSiyd8VtdW/iI+oGpWkltdUiBm04ouEj 3lPV340wZtHf3f7ZueIqDdDxxJ5Q7hQ0rCHN53W+CXTgcET0wFBKNsr+SxVz1TQUhpBy 6t/JJEeyolrgmItMMETPcTRPv0XOwe3TK0V8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SthOrd4ARPvvZu0Vvsh1moE2PBFaCvy3s/TReBj5tCBdKuQ3yrSe8YvGAbAocPE3My aATSu8Iv+ZyH7n4jKC9HU+2KxLfUgP9lkzju/eugJcltGWsbJYn2U+0qbxT3pFfrJvpp vqUU269pL3oLHpgJMjDKJLmJbAUkWzzEWUMI4= MIME-Version: 1.0 Received: by 10.140.164.1 with SMTP id m1mr1372032rve.223.1232737945322; Fri, 23 Jan 2009 11:12:25 -0800 (PST) Date: Fri, 23 Jan 2009 11:12:25 -0800 Message-ID: From: Maksim Yevmenkin To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 19:12:26 -0000 Lars, > Maksim has made a lot of changes to the Bluetooth driver. Maybe he can look > into it? > > This looks like a NULL-pointer access to me. > > Maksim: > > In the ubt_detach routine, make sure that: > > 0) No further commands are accepted from the Netgraph stack. > 1) You drain the task queue! > 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. > 3) Set the "sc_node" to NULL. please try attached patch for ng_ubt2 that hopefully addresses some of the issues with stalled transfers. stalled transfers do not happen on my machine, so i can not test it. i briefly kicked the tires and made sure other things seems to work fine for me. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 19:13:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB57010656C2; Fri, 23 Jan 2009 19:13:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 84E448FC0C; Fri, 23 Jan 2009 19:13:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4956632rvf.43 for ; Fri, 23 Jan 2009 11:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6xJk+otF5IuZN5bObbzCKlxD0ZWKY8PP8zcRJgMcFNQ=; b=O0xlmL+fGIGEl6s4RkFTWVfZB2JKX9kileqNGhOzdwaHQTX2qaGHcRPUFDEsSJgqLj rad0n8YITTcrttESXlz3hRT/s1qi4247w8ktwqjgs24nbhObse1nv6WbzMDKpX+Q1KVO x4QufinbnnxJHvy11JmekB9Hj52QHSwhUv3fU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A4IFSs1SBe0ZucKzxLfyB+08CORKe5FTr+0GicslPD6d09zoFaD9bNd46dQPgo9gzd U7nNl8URmhLcFwFk6WQuBAzw11DjlSXp49Y5N3tqlirCEjju4E82qnqzmOKOqi2xHMfb da4vbIEPim2vgfFtU/io4NG8iq5/4B0XFpAE4= MIME-Version: 1.0 Received: by 10.141.69.1 with SMTP id w1mr3607584rvk.119.1232738039261; Fri, 23 Jan 2009 11:13:59 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2009 11:13:59 -0800 Message-ID: From: Maksim Yevmenkin To: Lars Engels Content-Type: multipart/mixed; boundary=000e0cd14d34ee6a0204612b3091 Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 19:14:00 -0000 --000e0cd14d34ee6a0204612b3091 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jan 23, 2009 at 11:12 AM, Maksim Yevmenkin wrote: > Lars, > >> Maksim has made a lot of changes to the Bluetooth driver. Maybe he can look >> into it? >> >> This looks like a NULL-pointer access to me. >> >> Maksim: >> >> In the ubt_detach routine, make sure that: >> >> 0) No further commands are accepted from the Netgraph stack. >> 1) You drain the task queue! >> 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. >> 3) Set the "sc_node" to NULL. > > please try attached patch for ng_ubt2 that hopefully addresses some of > the issues with stalled transfers. stalled transfers do not happen on > my machine, so i can not test it. i briefly kicked the tires and made > sure other things seems to work fine for me. sorry, forgot to attach the patch :) thanks, max --000e0cd14d34ee6a0204612b3091 Content-Type: text/plain; charset=US-ASCII; name="ng_ubt2.stall.diff.txt" Content-Disposition: attachment; filename="ng_ubt2.stall.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fqb8e30z0 SW5kZXg6IG5nX3VidDIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBuZ191YnQyLmMJKHJldmlzaW9uIDE4NzUw NSkKKysrIG5nX3VidDIuYwkod29ya2luZyBjb3B5KQpAQCAtMjQzLDEzICsyNDMsMTEgQEAKIC8q IFVTQiBtZXRob2RzICovCiBzdGF0aWMgdXNiMl9jYWxsYmFja190CXVidF9jdHJsX3dyaXRlX2Nh bGxiYWNrOwogc3RhdGljIHVzYjJfY2FsbGJhY2tfdAl1YnRfaW50cl9yZWFkX2NhbGxiYWNrOwot c3RhdGljIHVzYjJfY2FsbGJhY2tfdAl1YnRfaW50cl9yZWFkX2NsZWFyX3N0YWxsX2NhbGxiYWNr Owogc3RhdGljIHVzYjJfY2FsbGJhY2tfdAl1YnRfYnVsa19yZWFkX2NhbGxiYWNrOwotc3RhdGlj IHVzYjJfY2FsbGJhY2tfdAl1YnRfYnVsa19yZWFkX2NsZWFyX3N0YWxsX2NhbGxiYWNrOwogc3Rh dGljIHVzYjJfY2FsbGJhY2tfdAl1YnRfYnVsa193cml0ZV9jYWxsYmFjazsKLXN0YXRpYyB1c2Iy X2NhbGxiYWNrX3QJdWJ0X2J1bGtfd3JpdGVfY2xlYXJfc3RhbGxfY2FsbGJhY2s7CiBzdGF0aWMg dXNiMl9jYWxsYmFja190CXVidF9pc29jX3JlYWRfY2FsbGJhY2s7CiBzdGF0aWMgdXNiMl9jYWxs YmFja190CXVidF9pc29jX3dyaXRlX2NhbGxiYWNrOworc3RhdGljIHVzYjJfY2FsbGJhY2tfdAl1 YnRfY2xlYXJfc3RhbGxfY2FsbGJhY2s7CiAKIHN0YXRpYyBpbnQJdWJ0X2lzb2NfcmVhZF9vbmVf ZnJhbWUoc3RydWN0IHVzYjJfeGZlciAqLCBpbnQpOwogCkBAIC0zMTYsNyArMzE0LDcgQEAKIAkJ LmVuZHBvaW50ID0JMHgwMCwJLyogY29udHJvbCBwaXBlICovCiAJCS5kaXJlY3Rpb24gPQlVRV9E SVJfQU5ZLAogCQkubWguYnVmc2l6ZSA9CXNpemVvZihzdHJ1Y3QgdXNiMl9kZXZpY2VfcmVxdWVz dCksCi0JCS5taC5jYWxsYmFjayA9CSZ1YnRfYnVsa193cml0ZV9jbGVhcl9zdGFsbF9jYWxsYmFj aywKKwkJLm1oLmNhbGxiYWNrID0JJnVidF9jbGVhcl9zdGFsbF9jYWxsYmFjaywKIAkJLm1oLnRp bWVvdXQgPQkxMDAwLAkvKiAxIHNlY29uZCAqLwogCQkubWguaW50ZXJ2YWwgPQk1MCwJLyogNTBt cyAqLwogCX0sCkBAIC0zMjYsNyArMzI0LDcgQEAKIAkJLmVuZHBvaW50ID0JMHgwMCwJLyogY29u dHJvbCBwaXBlICovCiAJCS5kaXJlY3Rpb24gPQlVRV9ESVJfQU5ZLAogCQkubWguYnVmc2l6ZSA9 CXNpemVvZihzdHJ1Y3QgdXNiMl9kZXZpY2VfcmVxdWVzdCksCi0JCS5taC5jYWxsYmFjayA9CSZ1 YnRfYnVsa19yZWFkX2NsZWFyX3N0YWxsX2NhbGxiYWNrLAorCQkubWguY2FsbGJhY2sgPQkmdWJ0 X2NsZWFyX3N0YWxsX2NhbGxiYWNrLAogCQkubWgudGltZW91dCA9CTEwMDAsCS8qIDEgc2Vjb25k ICovCiAJCS5taC5pbnRlcnZhbCA9CTUwLAkvKiA1MG1zICovCiAJfSwKQEAgLTMzOSw3ICszMzcs NyBAQAogCQkuZW5kcG9pbnQgPQkweDAwLAkvKiBjb250cm9sIHBpcGUgKi8KIAkJLmRpcmVjdGlv biA9CVVFX0RJUl9BTlksCiAJCS5taC5idWZzaXplID0Jc2l6ZW9mKHN0cnVjdCB1c2IyX2Rldmlj ZV9yZXF1ZXN0KSwKLQkJLm1oLmNhbGxiYWNrID0JJnVidF9pbnRyX3JlYWRfY2xlYXJfc3RhbGxf Y2FsbGJhY2ssCisJCS5taC5jYWxsYmFjayA9CSZ1YnRfY2xlYXJfc3RhbGxfY2FsbGJhY2ssCiAJ CS5taC50aW1lb3V0ID0JMTAwMCwJLyogMSBzZWNvbmQgKi8KIAkJLm1oLmludGVydmFsID0JNTAs CS8qIDUwbXMgKi8KIAl9LApAQCAtNjIzLDYgKzYyMSw5IEBACiAJCW5nX3Jtbm9kZV9zZWxmKG5v ZGUpOwogCX0KIAorCS8qIE1ha2Ugc3VyZSB1YnRfdGFzayBpbiBnb25lICovCisJdGFza3F1ZXVl X2RyYWluKHRhc2txdWV1ZV9zd2ksICZzYy0+c2NfdGFzayk7CisKIAkvKiBGcmVlIFVTQiB0cmFu c2ZlcnMsIGlmIGFueSAqLwogCXVzYjJfdHJhbnNmZXJfdW5zZXR1cChzYy0+c2NfeGZlciwgVUJU X05fVFJBTlNGRVIpOwogCkBAIC04NDMsMzUgKzg0NCw2IEBACiB9IC8qIHVidF9pbnRyX3JlYWRf Y2FsbGJhY2sgKi8KIAogLyoKLSAqIENhbGxlZCB3aGVuIG91dGdvaW5nIGNvbnRyb2wgdHJhbnNm ZXIgaW5pdGlhdGVkIHRvIGNsZWFyIHN0YWxsIG9uCi0gKiBpbnRlcnJ1cHQgcGlwZSBoYXMgY29t cGxldGVkLgotICogVVNCIGNvbnRleHQuCi0gKi8KLQotc3RhdGljIHZvaWQKLXVidF9pbnRyX3Jl YWRfY2xlYXJfc3RhbGxfY2FsbGJhY2soc3RydWN0IHVzYjJfeGZlciAqeGZlcikKLXsKLQlub2Rl X3AJCQlub2RlID0geGZlci0+cHJpdl9zYzsKLQlzdHJ1Y3QgdWJ0X3NvZnRjCSpzYzsKLQlzdHJ1 Y3QgdXNiMl94ZmVyCSp4ZmVyX290aGVyOwotCi0JaWYgKE5HX05PREVfTk9UX1ZBTElEKG5vZGUp KSB7Ci0JCU5HX05PREVfVU5SRUYobm9kZSk7Ci0JCXJldHVybjsgLyogbmV0Z3JhcGggbm9kZSBp cyBnb25lICovCi0JfQotCi0Jc2MgPSBOR19OT0RFX1BSSVZBVEUobm9kZSk7Ci0JeGZlcl9vdGhl ciA9IHNjLT5zY194ZmVyW1VCVF9JRl8wX0lOVFJfRFRfUkRdOwotCi0JaWYgKHVzYjJfY2xlYXJf c3RhbGxfY2FsbGJhY2soeGZlciwgeGZlcl9vdGhlcikpIHsKLQkJRFBSSU5URigic3RhbGwgY2xl YXJlZFxuIik7Ci0JCXNjLT5zY19mbGFncyAmPSB+VUJUX0ZMQUdfSU5UUl9TVEFMTDsKLQkJdXNi Ml90cmFuc2Zlcl9zdGFydCh4ZmVyX290aGVyKTsKLQl9IGVsc2UKLQkJTkdfTk9ERV9VTlJFRihu b2RlKTsgLyogY2FudCBjbGVhciBzdGFsbCAqLwotfSAvKiB1YnRfaW50cl9yZWFkX2NsZWFyX3N0 YWxsX2NhbGxiYWNrICovCi0KLS8qCiAgKiBDYWxsZWQgd2hlbiBpbmNvbWluZyBidWxrIHRyYW5z ZmVyIChBQ0wgcGFja2V0KSBoYXMgY29tcGxldGVkLCBpLmUuCiAgKiBBQ0wgcGFja2V0IHdhcyBy ZWNlaXZlZCBmcm9tIHRoZSBkZXZpY2UuCiAgKiBVU0IgY29udGV4dC4KQEAgLTk5MCwzNSArOTYy LDYgQEAKIH0gLyogdWJ0X2J1bGtfcmVhZF9jYWxsYmFjayAqLwogCiAvKgotICogQ2FsbGVkIHdo ZW4gb3V0Z29pbmcgY29udHJvbCB0cmFuc2ZlciBpbml0aWF0ZWQgdG8gY2xlYXIgc3RhbGwgb24K LSAqIGluY29taW5nIGJ1bGsgcGlwZSBoYXMgY29tcGxldGVkLgotICogVVNCIGNvbnRleHQuCi0g Ki8KLQotc3RhdGljIHZvaWQKLXVidF9idWxrX3JlYWRfY2xlYXJfc3RhbGxfY2FsbGJhY2soc3Ry dWN0IHVzYjJfeGZlciAqeGZlcikKLXsKLQlub2RlX3AJCQlub2RlID0geGZlci0+cHJpdl9zYzsK LQlzdHJ1Y3QgdWJ0X3NvZnRjCSpzYzsKLQlzdHJ1Y3QgdXNiMl94ZmVyCSp4ZmVyX290aGVyOwot Ci0JaWYgKE5HX05PREVfTk9UX1ZBTElEKG5vZGUpKSB7Ci0JCU5HX05PREVfVU5SRUYobm9kZSk7 Ci0JCXJldHVybjsgLyogbmV0Z3JhcGggbm9kZSBpcyBnb25lICovCi0JfQotCi0Jc2MgPSBOR19O T0RFX1BSSVZBVEUobm9kZSk7Ci0JeGZlcl9vdGhlciA9IHNjLT5zY194ZmVyW1VCVF9JRl8wX0JV TEtfRFRfUkRdOwotCi0JaWYgKHVzYjJfY2xlYXJfc3RhbGxfY2FsbGJhY2soeGZlciwgeGZlcl9v dGhlcikpIHsKLQkJRFBSSU5URigic3RhbGwgY2xlYXJlZFxuIik7Ci0JCXNjLT5zY19mbGFncyAm PSB+VUJUX0ZMQUdfUkVBRF9TVEFMTDsKLQkJdXNiMl90cmFuc2Zlcl9zdGFydCh4ZmVyX290aGVy KTsKLQl9IGVsc2UKLQkJTkdfTk9ERV9VTlJFRihub2RlKTsgLyogY2FudCBjbGVhciBzdGFsbCAq LwotfSAvKiB1YnRfYnVsa19yZWFkX2NsZWFyX3N0YWxsX2NhbGxiYWNrICovCi0KLS8qCiAgKiBD YWxsZWQgd2hlbiBvdXRnb2luZyBidWxrIHRyYW5zZmVyIChBQ0wgcGFja2V0KSBoYXMgY29tcGxl dGVkLCBpLmUuCiAgKiBBQ0wgcGFja2V0IHdhcyBzZW50IHRvIHRoZSBkZXZpY2UuCiAgKiBVU0Ig Y29udGV4dC4KQEAgLTEwOTYsMzUgKzEwMzksNiBAQAogfSAvKiB1YnRfYnVsa193cml0ZV9jYWxs YmFjayAqLwogCiAvKgotICogQ2FsbGVkIHdoZW4gb3V0Z29pbmcgY29udHJvbCB0cmFuc2ZlciBp bml0aWF0ZWQgdG8gY2xlYXIgc3RhbGwgb24KLSAqIG91dGdvaW5nIGJ1bGsgcGlwZSBoYXMgY29t cGxldGVkLgotICogVVNCIGNvbnRleHQuCi0gKi8KLQotc3RhdGljIHZvaWQKLXVidF9idWxrX3dy aXRlX2NsZWFyX3N0YWxsX2NhbGxiYWNrKHN0cnVjdCB1c2IyX3hmZXIgKnhmZXIpCi17Ci0Jbm9k ZV9wCQkJbm9kZSA9IHhmZXItPnByaXZfc2M7Ci0Jc3RydWN0IHVidF9zb2Z0Ywkqc2M7Ci0Jc3Ry dWN0IHVzYjJfeGZlcgkqeGZlcl9vdGhlcjsKLQotCWlmIChOR19OT0RFX05PVF9WQUxJRChub2Rl KSkgewotCQlOR19OT0RFX1VOUkVGKG5vZGUpOwotCQlyZXR1cm47IC8qIG5ldGdyYXBoIG5vZGUg aXMgZ29uZSAqLwotCX0KLQotCXNjID0gTkdfTk9ERV9QUklWQVRFKG5vZGUpOwotCXhmZXJfb3Ro ZXIgPSBzYy0+c2NfeGZlcltVQlRfSUZfMF9CVUxLX0RUX1dSXTsKLQotCWlmICh1c2IyX2NsZWFy X3N0YWxsX2NhbGxiYWNrKHhmZXIsIHhmZXJfb3RoZXIpKSB7Ci0JCURQUklOVEYoInN0YWxsIGNs ZWFyZWRcbiIpOwotCQlzYy0+c2NfZmxhZ3MgJj0gflVCVF9GTEFHX1dSSVRFX1NUQUxMOwotCQl1 c2IyX3RyYW5zZmVyX3N0YXJ0KHhmZXJfb3RoZXIpOwotCX0gZWxzZQotCQlOR19OT0RFX1VOUkVG KG5vZGUpOyAvKiBjYW50IGNsZWFyIHN0YWxsICovCi19IC8qIHVidF9idWxrX3dyaXRlX2NsZWFy X3N0YWxsX2NhbGxiYWNrICovCi0KLS8qCiAgKiBDYWxsZWQgd2hlbiBpbmNvbWluZyBpc29jIHRy YW5zZmVyIChTQ08gcGFja2V0KSBoYXMgY29tcGxldGVkLCBpLmUuCiAgKiBTQ08gcGFja2V0IHdh cyByZWNlaXZlZCBmcm9tIHRoZSBkZXZpY2UuCiAgKiBVU0IgY29udGV4dC4KQEAgLTEzNjEsNiAr MTI3NSw4MCBAQAogCX0KIH0KIAorLyoKKyAqIENhbGxlZCB3aGVuIGFuIG91dGdvaW5nIGNvbnRy b2wgdHJhbnNmZXIgdG8gY2xlYXIgc3RhbGwgb24gYW5vdGhlcgorICogcGlwZSBoYXMgYmVlbiBj b21wbGV0ZWQuIEdlbmVyaWMgZm9yIGFsbCBjbGVhciBzdGFsbCB0cmFuc2ZlcnMuCisgKiBVU0Ig Y29udGV4dC4KKyAqLworCitzdGF0aWMgdm9pZAordWJ0X2NsZWFyX3N0YWxsX2NhbGxiYWNrKHN0 cnVjdCB1c2IyX3hmZXIgKnhmZXIpCit7CisJbm9kZV9wCQkJbm9kZSA9IHhmZXItPnByaXZfc2M7 CisJc3RydWN0IHVidF9zb2Z0Ywkqc2M7CisJc3RydWN0IHVzYjJfeGZlcgkqeGZlcl9vdGhlcjsK KwlpbnQJCQlmbGFnOworCisJaWYgKE5HX05PREVfTk9UX1ZBTElEKG5vZGUpKSB7CisJCU5HX05P REVfVU5SRUYobm9kZSk7CisJCXJldHVybjsgLyogbmV0Z3JhcGggbm9kZSBpcyBnb25lICovCisJ fQorCisJc2MgPSBOR19OT0RFX1BSSVZBVEUobm9kZSk7CisKKwkvKgorCSAqIEZpZ3VyZSBvdXQg d2hpY2ggY2xlYXIgc3RhbGwgdHJhbnNmZXIgaGFzIGNvbXBsZXRlZAorCSAqIGFuZCBzZXQgeGZl cl9vdGhlciBhbmQgZmxhZyBhY2NvcmRpbmdseQorCSAqLworCisJaWYgKHhmZXIgPT0gc2MtPnNj X3hmZXJbVUJUX0lGXzBfQlVMS19DU19XUl0pIHsKKwkJeGZlcl9vdGhlciA9IHNjLT5zY194ZmVy W1VCVF9JRl8wX0JVTEtfRFRfV1JdOworCQlmbGFnID0gVUJUX0ZMQUdfV1JJVEVfU1RBTEw7CisJ fSBlbHNlIGlmICh4ZmVyID09IHNjLT5zY194ZmVyW1VCVF9JRl8wX0JVTEtfQ1NfUkRdKSB7CisJ CXhmZXJfb3RoZXIgPSBzYy0+c2NfeGZlcltVQlRfSUZfMF9CVUxLX0RUX1JEXTsKKwkJZmxhZyA9 IFVCVF9GTEFHX1JFQURfU1RBTEw7CisJfSBlbHNlIGlmICh4ZmVyID09IHNjLT5zY194ZmVyW1VC VF9JRl8wX0lOVFJfQ1NfUkRdKSB7CisJCXhmZXJfb3RoZXIgPSBzYy0+c2NfeGZlcltVQlRfSUZf MF9JTlRSX0RUX1JEXTsKKwkJZmxhZyA9IFVCVF9GTEFHX0lOVFJfU1RBTEw7CisJfSBlbHNlCisJ CXBhbmljKCJjb3VsZCBub3Qgc2V0IHhmZXJfb3RoZXIhIHhmZXI9JXBcbiIsIHhmZXIpOworCisJ aWYgKHhmZXJfb3RoZXIgPT0gTlVMTCkgeworCQlVQlRfV0FSTihzYywgIm90aGVyIHRyYW5zZmVy IGlzIGdvbmUuIGFyZSB3ZSBkeWluZz8hXG4iKTsKKwkJTkdfTk9ERV9VTlJFRihub2RlKTsKKwkJ cmV0dXJuOyAvKiBvdGhlciB0cmFuc2ZlciBpcyBnb25lLiBhcmUgd2UgZHlpbmc/ISAqLworCX0K KworCXN3aXRjaCAoVVNCX0dFVF9TVEFURSh4ZmVyKSkgeworCWNhc2UgVVNCX1NUX1NFVFVQOgor CQkvKgorCQkgKiBJZ25vcmUgcmV0dXJuIHZhbHVlIGZyb20gdXNiMl9jbGVhcl9zdGFsbF9jYWxs YmFjaygpCisJCSAqIGFzIGl0IGFwcGVhcnMgaXQgY2FuIG5vdCByZXR1cm4gYW55dGhpbmcgb3Ro ZXIgdGhhbgorCQkgKiB6ZXJvIGluIFVTQl9TVF9TRVRVUCBjYXNlCisJCSAqLworCQkodm9pZCkg dXNiMl9jbGVhcl9zdGFsbF9jYWxsYmFjayh4ZmVyLCB4ZmVyX290aGVyKTsKKwkJYnJlYWs7CisK KwljYXNlIFVTQl9TVF9UUkFOU0ZFUlJFRDoKKwkJVUJUX0lORk8oc2MsICJzdGFsbCBjbGVhcmVk LCBmbGFnPSUjeFxuIiwgZmxhZyk7CitzdWJtaXRfb3RoZXI6CisJCXNjLT5zY19mbGFncyAmPSB+ ZmxhZzsKKwkJdXNiMl90cmFuc2Zlcl9zdGFydCh4ZmVyX290aGVyKTsKKwkJYnJlYWs7CisKKwlk ZWZhdWx0OgorCQlpZiAoeGZlci0+ZXJyb3IgIT0gVVNCX0VSUl9DQU5DRUxMRUQpIHsKKwkJCVVC VF9XQVJOKHNjLCAiY2xlYXIgc3RhbGwgdHJhbnNmZXIgZmFpbGVkOiAlcywgIiBcCisJCQkJImZs YWc9JSN4XG4iLCB1c2IyX2VycnN0cih4ZmVyLT5lcnJvciksIGZsYWcpOworCQkJZ290byBzdWJt aXRfb3RoZXI7CisJCQkvKiBOT1QgUkVBQ0hFRCAqLworCQl9CisKKwkJTkdfTk9ERV9VTlJFRihu b2RlKTsgLyogY2FuY2VsbGVkICovCisJCWJyZWFrOworCX0KK30gLyogdWJ0X2NsZWFyX3N0YWxs X2NhbGxiYWNrICovCisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCiAgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KgogICoqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR2x1ZSAK --000e0cd14d34ee6a0204612b3091-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 19:26:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444AB106566C for ; Fri, 23 Jan 2009 19:26:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id A2A5D8FC22 for ; Fri, 23 Jan 2009 19:26:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=BgLTMzI9XPk8trZRc9gA:9 a=hZqmzLOkog5fejotXWAA:7 a=41F6Q73lrYk4a1dNx3WkeRwJGlgA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1012633704; Fri, 23 Jan 2009 20:26:45 +0100 From: Hans Petter Selasky To: Maksim Yevmenkin Date: Fri, 23 Jan 2009 20:29:09 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901231714.39873.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232029.10538.hselasky@c2i.net> Cc: Lars Engels , current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 19:26:48 -0000 Hi Maksim, First of all I've made some patches which try to tidy up the USB blutooth driver. Please see: http://perforce.freebsd.org/chv.cgi?CH=156577 http://perforce.freebsd.org/chv.cgi?CH=156579 Maybe you can review this and consider it for commit to -current. My problem is that I do not fully understand Netgraph. > > that should not be needed (in theory) but i will add it. Yes! We are multithreaded! > > 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. > > yes, usb2_transfer_unsetup() does that, does it not? That is correct, but sometimes you need to stop the transfers at an earlier point. It depends on your design. I see in your code that you try to do things Asynchronously. This complicates stuff quite a lot. In my patches I've tried to do some things synchronously. > > 3) Set the "sc_node" to NULL. > > yes, we do that too. > > i have lots of questions about stalled transfers. in any case, it > appears that my code is wrong when it comes to stalled transfers. in > particular, usb2_clear_stall_callback() returns 0 The return value of this function should not an error code. > in both USB_ST_SETUP > and default/error cases, so the code incorrectly clears node reference > in USB_ST_SETUP case. that needs to be fixed. Yes, I noticed that. > > i'm also deeply confused about error handling in transfers. in > particular, any error that is not USB_ERR_CANCELLED makes code to > assume that it was a stall and queue clear stall transfer. that is > clearly not the case when hardware is yanked while transfer is active. > in this case transfer callback seems to be called with USB_ERR_IOERROR > (or something like that). so, shouldn't we be safe and only queue > stall transfer if callback was in fact called with USB_ERR_STALLED? > 1) Any non-cancelled error goes through the standard clear-stall procedure. The clear stall transfers are niced for 50ms interval, see the "interval" field in the "usb2_config" structure! We do the clear stall, because it puts some delay between the error and the re-start of the transfers. We don't want to end up in a case where the transfer simply stops because of a silly CRC error. Or that we go into fast race with the hardware on errors. 2) "xfer->error" is never set at the same time you are in the transferred state. > the completely different question here is why stall happens in the first > place. 1) Cable signal error 2) Device sent a STALL PID. > > also as others pointed out, panic in ttydisc_getc is something else. Yepp. Maybe my P4 patches will help you? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 20:01:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA038106564A; Fri, 23 Jan 2009 20:01:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3248FC1A; Fri, 23 Jan 2009 20:01:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4974948rvf.43 for ; Fri, 23 Jan 2009 12:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z7UmvYrOWi9DsFTE+JONdipBCzMVKQI6Xd18XAsAAm8=; b=pztQSGpofcUDWH6ZNxWyNZjb4JvcKFREYEDuY3CmlMhO2IIzE1WhEOW29LGuliQxpm ScJn5NPlqtUpR3LbQv9edo+qvYaN0jckneXAfzYtXHL9OTeS4sbUIcWRyqPukeR1DtGn ubjc9eax0LUED/au3p2WAWLiK2u9rsb7LSHHI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tX48VjUoirie1vKYCcCt1mOpu+EfqS6gHIqFOskK6rOPqClmA98g9gyquJ8fNpPyow FkfeiKeQbJUhhjaLEGl2wZ7DO98l/P0x1fmHO6sJdd98V7LQ+zk7Jz8pK/rchb4Oi7jU dQ5PKt3WOfaLM6Ynbx6kKEbKd4yElY81lpPRo= MIME-Version: 1.0 Received: by 10.141.86.4 with SMTP id o4mr3821569rvl.172.1232740904283; Fri, 23 Jan 2009 12:01:44 -0800 (PST) In-Reply-To: <200901232029.10538.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901231714.39873.hselasky@c2i.net> <200901232029.10538.hselasky@c2i.net> Date: Fri, 23 Jan 2009 12:01:44 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lars Engels , Alfred Perlstein , current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 20:01:45 -0000 On Fri, Jan 23, 2009 at 11:29 AM, Hans Petter Selasky wrote: > Hi Maksim, > > First of all I've made some patches which try to tidy up the USB blutooth > driver. Please see: > > http://perforce.freebsd.org/chv.cgi?CH=156577 > http://perforce.freebsd.org/chv.cgi?CH=156579 thanks! unfortunately, i have few problems with those patches. please read below. >> that should not be needed (in theory) but i will add it. > > Yes! We are multithreaded! please tell me that you read the blob about locking strategy at the top of ng_ubt2.c file. when ubt_task() is pending, it holds a reference to the netgraph node. that means the pointer is still pointing to a valid structure, but the node is marked as "dead" and NG_NODE[_NOT]_VALID() macros can be use to check for that. so, even if task is still pending while the rest of ng_ubt2 stuff is gone, it does not matter because task holds netgraph node. so the next time task is executed it will see that the node is "dead", release the node and simply return doing nothing. >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocked. >> >> yes, usb2_transfer_unsetup() does that, does it not? > > That is correct, but sometimes you need to stop the transfers at an earlier > point. It depends on your design. when detach() is called its already out of driver's hands. all it can do now is to call unsetup(), or am i missing something here? > I see in your code that you try to do things Asynchronously. This complicates > stuff quite a lot. In my patches I've tried to do some things synchronously. no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. period. you _CAN_NOT_ grab usb interface mutexes unless you can absolutely guarantee that they will not sleep for any significant amount of time. netgraph is essentially single threaded and by sleeping you will stall entire netgraph subsystem and not just current thread. so, objection #1 (the biggest one) is: please leave sc_mbufq_mtx and ubt_task() glue in place. it is needed as far as i can tell. >> i'm also deeply confused about error handling in transfers. in >> particular, any error that is not USB_ERR_CANCELLED makes code to >> assume that it was a stall and queue clear stall transfer. that is >> clearly not the case when hardware is yanked while transfer is active. >> in this case transfer callback seems to be called with USB_ERR_IOERROR >> (or something like that). so, shouldn't we be safe and only queue >> stall transfer if callback was in fact called with USB_ERR_STALLED? > > 1) Any non-cancelled error goes through the standard clear-stall procedure. > The clear stall transfers are niced for 50ms interval, see the "interval" > field in the "usb2_config" structure! We do the clear stall, because it puts > some delay between the error and the re-start of the transfers. We don't want > to end up in a case where the transfer simply stops because of a silly CRC > error. Or that we go into fast race with the hardware on errors. ok, that makes sense. except the case when hardware is gone and transfer callback is called with IOERROR (or something like that). i guess the question is can callback be called with IOERROR for any reason other than hardware departure? so, back to your patches. objection #2 (somewhat major). please do NOT remove NG_NODE_REF() call in detach() before calling ng_rmnode_self() (unless you remove NG_NODE_UNREF() below as well). again the reason here is to tell netgraph node that we are dying, but make sure we keep node_p pointer pointing to a valid structure as long as possible. to summarize, NG_NODE_REF(node) <- grab our reference to ensure node pointer remains valid ng_rmnode_self(node) <- tell node we are dying, mark node as "dead" but NOT free node structure /* do other stuff */ NG_NODE_UNREF(node) <- drop our reference and possibly free node pointer more of a question than objection. why you insist on having single mutex for both interfaces? isoc transfers callbacks will be called much more often that control, bulk and interrupt callbacks, so wouldn't it make sense to use different lock for isoc transfers? changes in attach() and usb2_config structures are fine (i guess). but please keep asynchronous design in place. it is required. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 20:44:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515C31065673; Fri, 23 Jan 2009 20:44:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 25D3F8FC21; Fri, 23 Jan 2009 20:44:36 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=F4Xq1ygv2EPCaWVc8pUA:9 a=NPho0j7jtTSMCwuEI10A:7 a=7_GJtV10YOjpX6Wx9yM-mxKt1VYA:4 a=9aOQ2cSd83gA:10 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 795311138; Fri, 23 Jan 2009 21:44:35 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 23 Jan 2009 21:46:55 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232029.10538.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232146.58360.hselasky@c2i.net> Cc: Lars Engels , Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 20:44:39 -0000 Hi Maksim, On Friday 23 January 2009, Maksim Yevmenkin wrote: > On Fri, Jan 23, 2009 at 11:29 AM, Hans Petter Selasky wrote: > > Hi Maksim, > > > > First of all I've made some patches which try to tidy up the USB blutooth > > driver. Please see: > > > > http://perforce.freebsd.org/chv.cgi?CH=156577 > > http://perforce.freebsd.org/chv.cgi?CH=156579 > > thanks! unfortunately, i have few problems with those patches. please > read below. > > >> that should not be needed (in theory) but i will add it. > > > > Yes! We are multithreaded! > > please tell me that you read the blob about locking strategy at the > top of ng_ubt2.c file. when ubt_task() is pending, it holds a > reference to the netgraph node. that means the pointer is still > pointing to a valid structure, but the node is marked as "dead" and > NG_NODE[_NOT]_VALID() macros can be use to check for that. so, even if > task is still pending while the rest of ng_ubt2 stuff is gone, it does > not matter because task holds netgraph node. so the next time task is > executed it will see that the node is "dead", release the node and > simply return doing nothing. This kind of complexity is unneccesary. We should be able to drain a node, or sleep until a node is released. 0) stop all USB activity 1) free node 2) wait until the node is actually freed 3) free USB resources which might access node fields Conclusion: No checks are required inside any of the USB callbacks. > > >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called > >> > unlocked. > >> > >> yes, usb2_transfer_unsetup() does that, does it not? > > > > That is correct, but sometimes you need to stop the transfers at an > > earlier point. It depends on your design. > > when detach() is called its already out of driver's hands. all it can > do now is to call unsetup(), or am i missing something here? The correct thing is to do a usb2_transfer_drain() which will wait until the callback has been called back, if a transfer is pending. In USB2 a "usb2_start_hardware()" call is always paired with a USB transfer callback, no matter what you do! This way of design has been chosen so that you can do refcounts inside the callback! > > I see in your code that you try to do things Asynchronously. This > > complicates stuff quite a lot. In my patches I've tried to do some things > > synchronously. > > no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. > period. you _CAN_NOT_ grab usb interface mutexes unless you can > absolutely guarantee that they will not sleep for any significant > amount of time. usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will never sleep. The exception is "usb2_transfer_drain()" which can sleep for a few milliseconds and is only called when the hook is disconnected. I do not see that as a problem versus having "X" more checks in the code. > netgraph is essentially single threaded and by > sleeping you will stall entire netgraph subsystem and not just current > thread. If we sleep 10 milliseconds on a UBT hook disconnect, is that a big problem? How often will UBT hook disconnect be called? > > so, objection #1 (the biggest one) is: please leave sc_mbufq_mtx and > ubt_task() glue in place. it is needed as far as i can tell. What I see is that USB already has a separate process handling the callback so that when you call "usb2_transfer_start()" this other process is woken up. Are you sure that there is a measurable gain using "ubt_task()" versus the way I'm doing it? > > ok, that makes sense. except the case when hardware is gone and > transfer callback is called with IOERROR (or something like that). i > guess the question is can callback be called with IOERROR for any > reason other than hardware departure? Yes, if there is interference on the cable. It is quite valid to setup an USB transaction after that the hardware has dissappeared, in xxx_detach() for example. Remeber USB is a polling bus. If the device is not there (I.E. not responds) the USB transfer will simply terminate, either immediately or after a timeout. > > objection #2 (somewhat major). please do NOT remove NG_NODE_REF() call > in detach() before calling ng_rmnode_self() (unless you remove > NG_NODE_UNREF() below as well). again the reason here is to tell > netgraph node that we are dying, but make sure we keep node_p pointer > pointing to a valid structure as long as possible. to summarize, We are already holding a reference to the node from ubt_attach(), right? Why do we need another node reference? > > NG_NODE_REF(node) <- grab our reference to ensure node pointer remains > valid ng_rmnode_self(node) <- tell node we are dying, mark node as "dead" > but NOT free node structure > /* do other stuff */ > NG_NODE_UNREF(node) <- drop our reference and possibly free node pointer > > > more of a question than objection. why you insist on having single > mutex for both interfaces? isoc transfers callbacks will be called > much more often that control, bulk and interrupt callbacks, so > wouldn't it make sense to use different lock for isoc transfers? Because a single mutex is much easier to maintain and I see no gain fine graining more for a bluetooth device :-) > changes in attach() and usb2_config structures are fine (i guess). but > please keep asynchronous design in place. it is required. Is it possible we can make a compromise here? From my experience synchronous code is smaller and easier to understand than asynchronous code! The only disadvantage about synchronous code is that more threads might be required. And hence Netgraph is single threaded other signalling might be delayed, but is that a real problem if we are talking about delays around 1x10ms ever time you disconnect the hook of an UBT node? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 20:44:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515C31065673; Fri, 23 Jan 2009 20:44:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 25D3F8FC21; Fri, 23 Jan 2009 20:44:36 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=F4Xq1ygv2EPCaWVc8pUA:9 a=NPho0j7jtTSMCwuEI10A:7 a=7_GJtV10YOjpX6Wx9yM-mxKt1VYA:4 a=9aOQ2cSd83gA:10 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 795311138; Fri, 23 Jan 2009 21:44:35 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 23 Jan 2009 21:46:55 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232029.10538.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232146.58360.hselasky@c2i.net> Cc: Lars Engels , Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 20:44:39 -0000 Hi Maksim, On Friday 23 January 2009, Maksim Yevmenkin wrote: > On Fri, Jan 23, 2009 at 11:29 AM, Hans Petter Selasky wrote: > > Hi Maksim, > > > > First of all I've made some patches which try to tidy up the USB blutooth > > driver. Please see: > > > > http://perforce.freebsd.org/chv.cgi?CH=156577 > > http://perforce.freebsd.org/chv.cgi?CH=156579 > > thanks! unfortunately, i have few problems with those patches. please > read below. > > >> that should not be needed (in theory) but i will add it. > > > > Yes! We are multithreaded! > > please tell me that you read the blob about locking strategy at the > top of ng_ubt2.c file. when ubt_task() is pending, it holds a > reference to the netgraph node. that means the pointer is still > pointing to a valid structure, but the node is marked as "dead" and > NG_NODE[_NOT]_VALID() macros can be use to check for that. so, even if > task is still pending while the rest of ng_ubt2 stuff is gone, it does > not matter because task holds netgraph node. so the next time task is > executed it will see that the node is "dead", release the node and > simply return doing nothing. This kind of complexity is unneccesary. We should be able to drain a node, or sleep until a node is released. 0) stop all USB activity 1) free node 2) wait until the node is actually freed 3) free USB resources which might access node fields Conclusion: No checks are required inside any of the USB callbacks. > > >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called > >> > unlocked. > >> > >> yes, usb2_transfer_unsetup() does that, does it not? > > > > That is correct, but sometimes you need to stop the transfers at an > > earlier point. It depends on your design. > > when detach() is called its already out of driver's hands. all it can > do now is to call unsetup(), or am i missing something here? The correct thing is to do a usb2_transfer_drain() which will wait until the callback has been called back, if a transfer is pending. In USB2 a "usb2_start_hardware()" call is always paired with a USB transfer callback, no matter what you do! This way of design has been chosen so that you can do refcounts inside the callback! > > I see in your code that you try to do things Asynchronously. This > > complicates stuff quite a lot. In my patches I've tried to do some things > > synchronously. > > no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. > period. you _CAN_NOT_ grab usb interface mutexes unless you can > absolutely guarantee that they will not sleep for any significant > amount of time. usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will never sleep. The exception is "usb2_transfer_drain()" which can sleep for a few milliseconds and is only called when the hook is disconnected. I do not see that as a problem versus having "X" more checks in the code. > netgraph is essentially single threaded and by > sleeping you will stall entire netgraph subsystem and not just current > thread. If we sleep 10 milliseconds on a UBT hook disconnect, is that a big problem? How often will UBT hook disconnect be called? > > so, objection #1 (the biggest one) is: please leave sc_mbufq_mtx and > ubt_task() glue in place. it is needed as far as i can tell. What I see is that USB already has a separate process handling the callback so that when you call "usb2_transfer_start()" this other process is woken up. Are you sure that there is a measurable gain using "ubt_task()" versus the way I'm doing it? > > ok, that makes sense. except the case when hardware is gone and > transfer callback is called with IOERROR (or something like that). i > guess the question is can callback be called with IOERROR for any > reason other than hardware departure? Yes, if there is interference on the cable. It is quite valid to setup an USB transaction after that the hardware has dissappeared, in xxx_detach() for example. Remeber USB is a polling bus. If the device is not there (I.E. not responds) the USB transfer will simply terminate, either immediately or after a timeout. > > objection #2 (somewhat major). please do NOT remove NG_NODE_REF() call > in detach() before calling ng_rmnode_self() (unless you remove > NG_NODE_UNREF() below as well). again the reason here is to tell > netgraph node that we are dying, but make sure we keep node_p pointer > pointing to a valid structure as long as possible. to summarize, We are already holding a reference to the node from ubt_attach(), right? Why do we need another node reference? > > NG_NODE_REF(node) <- grab our reference to ensure node pointer remains > valid ng_rmnode_self(node) <- tell node we are dying, mark node as "dead" > but NOT free node structure > /* do other stuff */ > NG_NODE_UNREF(node) <- drop our reference and possibly free node pointer > > > more of a question than objection. why you insist on having single > mutex for both interfaces? isoc transfers callbacks will be called > much more often that control, bulk and interrupt callbacks, so > wouldn't it make sense to use different lock for isoc transfers? Because a single mutex is much easier to maintain and I see no gain fine graining more for a bluetooth device :-) > changes in attach() and usb2_config structures are fine (i guess). but > please keep asynchronous design in place. it is required. Is it possible we can make a compromise here? From my experience synchronous code is smaller and easier to understand than asynchronous code! The only disadvantage about synchronous code is that more threads might be required. And hence Netgraph is single threaded other signalling might be delayed, but is that a real problem if we are talking about delays around 1x10ms ever time you disconnect the hook of an UBT node? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:09:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D22F1065674 for ; Fri, 23 Jan 2009 21:09:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 27E168FC0C for ; Fri, 23 Jan 2009 21:09:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from p6161-ipbfp03kouchinwc.kochi.ocn.ne.jp ([118.13.106.161] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LQTH7-0004ro-2w; Fri, 23 Jan 2009 21:09:13 +0000 Message-ID: <497A31F7.1070005@psg.com> Date: Sat, 24 Jan 2009 06:09:11 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Marcel Moolenaar References: <496D0364.2060505@psg.com> <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> <085BEE07-BAE5-4A45-A14D-9587987FAA5C@mac.com> <496F44FA.1070004@andric.com> <48C1C477-B7BE-43B0-AC57-9DEB7BF9AA88@mac.com> <496F7347.4060007@andric.com> <496F8D8A.1060508@andric.com> <496F928F.6010807@andric.com> <496FE791.7000709@psg.com> In-Reply-To: <496FE791.7000709@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: GEOM and moving to CURRENT from 7.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:09:14 -0000 >> Thanks *very* much for testing! It's important that we >> get the details right, so that we can consider adding >> code to help in the migration and fix whatever is broken. > i may not understand things correctly, but it would seem three things > are needed: > o fix to source of problem > o hack to migration so those with the trigger get it nulled > while migrating > o repair hack for those of us who migrated and are suffering > the result what ever happened here. we still have a system with gmirror that we have suspended work on until we know what we should be doing. randy From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:25:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 426621065670 for ; Fri, 23 Jan 2009 21:25:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2711E8FC1B for ; Fri, 23 Jan 2009 21:25:33 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from bobbyg-pc.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KDY00E5E0U38410@asmtp022.mac.com> for current@freebsd.org; Fri, 23 Jan 2009 13:25:16 -0800 (PST) Message-id: <6D9C4D7C-88BD-4345-B281-26915601F4BF@mac.com> From: Marcel Moolenaar To: Randy Bush In-reply-to: <497A31F7.1070005@psg.com> Date: Fri, 23 Jan 2009 13:25:14 -0800 References: <496D0364.2060505@psg.com> <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> <085BEE07-BAE5-4A45-A14D-9587987FAA5C@mac.com> <496F44FA.1070004@andric.com> <48C1C477-B7BE-43B0-AC57-9DEB7BF9AA88@mac.com> <496F7347.4060007@andric.com> <496F8D8A.1060508@andric.com> <496F928F.6010807@andric.com> <496FE791.7000709@psg.com> <497A31F7.1070005@psg.com> X-Mailer: Apple Mail (2.930.3) Cc: current@freebsd.org Subject: Re: GEOM and moving to CURRENT from 7.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:25:33 -0000 On Jan 23, 2009, at 1:09 PM, Randy Bush wrote: >>> Thanks *very* much for testing! It's important that we >>> get the details right, so that we can consider adding >>> code to help in the migration and fix whatever is broken. >> i may not understand things correctly, but it would seem three things >> are needed: >> o fix to source of problem >> o hack to migration so those with the trigger get it nulled >> while migrating >> o repair hack for those of us who migrated and are suffering >> the result > > what ever happened here. we still have a system with gmirror that > we have suspended work on until we know what we should be doing. Wipe out the second sector on the disk. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:29:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2683106564A for ; Fri, 23 Jan 2009 21:29:53 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 67CD68FC1C for ; Fri, 23 Jan 2009 21:29:53 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 89BFA3A6A4; Fri, 23 Jan 2009 22:29:52 +0100 (CET) Date: Fri, 23 Jan 2009 22:29:52 +0100 From: Lars Engels To: Maksim Yevmenkin Message-ID: <20090123212952.GM60948@e.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cf0hFtnykp6aONGL" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:29:54 -0000 --cf0hFtnykp6aONGL Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 11:13:59AM -0800, Maksim Yevmenkin wrote: > On Fri, Jan 23, 2009 at 11:12 AM, Maksim Yevmenkin > wrote: > > Lars, > > > >> Maksim has made a lot of changes to the Bluetooth driver. Maybe he can= look > >> into it? > >> > >> This looks like a NULL-pointer access to me. > >> > >> Maksim: > >> > >> In the ubt_detach routine, make sure that: > >> > >> 0) No further commands are accepted from the Netgraph stack. > >> 1) You drain the task queue! > >> 2) You drain all USB transfers: "usb2_transfer_drain()" called unlocke= d. > >> 3) Set the "sc_node" to NULL. > > > > please try attached patch for ng_ubt2 that hopefully addresses some of > > the issues with stalled transfers. stalled transfers do not happen on > > my machine, so i can not test it. i briefly kicked the tires and made > > sure other things seems to work fine for me. >=20 > sorry, forgot to attach the patch :) >=20 > thanks, > max Thanks for the quick patch, but that did not help: ubt0: on usbus2 ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED I also have another usb bluetooth stick which shows this on insertion: Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1401: set address 2 failed= (ignored) Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1436: getting device descr= iptor at addr 2 failed! Jan 23 22:13:01 maggie kernel: ugen0.2: at usbus0 Jan 23 22:13:01 maggie kernel: ubt1: on usbus0 Lars --cf0hFtnykp6aONGL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6NtAACgkQKc512sD3afjmhwCfZParmfRHKKE4MHR8mIwoVESH Ry4AoJXjjWDAPWbfl85aOk93kYgVZKjL =Ysgn -----END PGP SIGNATURE----- --cf0hFtnykp6aONGL-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:31:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC9A106564A for ; Fri, 23 Jan 2009 21:31:43 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3599E8FC0A for ; Fri, 23 Jan 2009 21:31:43 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 668493A6A4; Fri, 23 Jan 2009 22:31:42 +0100 (CET) Date: Fri, 23 Jan 2009 22:31:42 +0100 From: Lars Engels To: Ed Schouten Message-ID: <20090123213142.GN60948@e.0x20.net> References: <20090123154336.GJ60948@e.0x20.net> <20090123162920.GT41248@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2VXyA7JGja7B50zs" Content-Disposition: inline In-Reply-To: <20090123162920.GT41248@hoeg.nl> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:31:43 -0000 --2VXyA7JGja7B50zs Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 05:29:20PM +0100, Ed Schouten wrote: > Hello Lars, >=20 > As HPS said, the issue seems to be related to ubt, but there's still > something else that is interesting to see here: >=20 > * Lars Engels wrote: > > #2 0xc0859512 in panic (fmt=3DVariable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:576 > > #3 0xc0849fc7 in _mtx_assert (m=3D0xc0d76e90, what=3D4, file=3D0xc0c30= b4c "/usr/src/sys/kern/tty_ttydisc.c", line=3D1127) at /usr/src/sys/kern/ke= rn_mutex.c:639 > > #4 0xc08aebad in ttydisc_getc (tp=3D0xc4650c00, buf=3D0xf12ea920, len= =3D128) at /usr/src/sys/kern/tty_ttydisc.c:1127 > > #5 0xc0740604 in sctty_outwakeup (tp=3D0xc4650c00) at /usr/src/sys/dev= /syscons/syscons.c:323 > > #6 0xc0740b6c in scgetc (sc=3D0xc0f11f20, flags=3D3) at /usr/src/sys/d= ev/syscons/syscons.c:3281 > > #7 0xc0741190 in sc_cngetc (cd=3D0xc0cc9be0) at /usr/src/sys/dev/sysco= ns/syscons.c:1607 > > #8 0xc0821a28 in cncheckc () at /usr/src/sys/kern/kern_cons.c:379 > > #9 0xc0821a66 in cngetc () at /usr/src/sys/kern/kern_cons.c:357 > > #10 0xc04bfb15 in db_readline (lstart=3D0xc0d45cc0 "\n", lsize=3D120) a= t /usr/src/sys/ddb/db_input.c:326 >=20 > Sam Leffler also reported this issue to me privately. I'll see what I > can do to fix this. Thanks a lot. BTW it doesn't panic on every boot but only from time to time. --2VXyA7JGja7B50zs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6Nz4ACgkQKc512sD3afh0KQCgzgM2pSBJZ14yzMT1X651ibjK 5zYAoLuuPDUzjFhqA52ADGjCNlFCoUX1 =YDBA -----END PGP SIGNATURE----- --2VXyA7JGja7B50zs-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:33:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4595E1065673 for ; Fri, 23 Jan 2009 21:33:24 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id F193E8FC0C for ; Fri, 23 Jan 2009 21:33:23 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 2A3FC3A6A4; Fri, 23 Jan 2009 22:33:23 +0100 (CET) Date: Fri, 23 Jan 2009 22:33:23 +0100 From: Lars Engels To: Maksim Yevmenkin Message-ID: <20090123213323.GO60948@e.0x20.net> References: <20090123212952.GM60948@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mPOSj6iWmtyhwOMz" Content-Disposition: inline In-Reply-To: <20090123212952.GM60948@e.0x20.net> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:33:24 -0000 --mPOSj6iWmtyhwOMz Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 10:29:52PM +0100, Lars Engels wrote: > On Fri, Jan 23, 2009 at 11:13:59AM -0800, Maksim Yevmenkin wrote: > > On Fri, Jan 23, 2009 at 11:12 AM, Maksim Yevmenkin > > wrote: > > > Lars, > > > > > >> Maksim has made a lot of changes to the Bluetooth driver. Maybe he c= an look > > >> into it? > > >> > > >> This looks like a NULL-pointer access to me. > > >> > > >> Maksim: > > >> > > >> In the ubt_detach routine, make sure that: > > >> > > >> 0) No further commands are accepted from the Netgraph stack. > > >> 1) You drain the task queue! > > >> 2) You drain all USB transfers: "usb2_transfer_drain()" called unloc= ked. > > >> 3) Set the "sc_node" to NULL. > > > > > > please try attached patch for ng_ubt2 that hopefully addresses some of > > > the issues with stalled transfers. stalled transfers do not happen on > > > my machine, so i can not test it. i briefly kicked the tires and made > > > sure other things seems to work fine for me. > >=20 > > sorry, forgot to attach the patch :) > >=20 > > thanks, > > max >=20 > Thanks for the quick patch, but that did not help: >=20 > ubt0: on usbus2 > ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED > ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALL= ED >=20 >=20 > I also have another usb bluetooth stick which shows this on insertion: >=20 > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1401: set address 2 fail= ed (ignored) > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1436: getting device des= criptor at addr 2 failed! > Jan 23 22:13:01 maggie kernel: ugen0.2: at usbu= s0 > Jan 23 22:13:01 maggie kernel: ubt1: on usbus0 > I forgot to mention that both bt devices worked without problems with the old stack, so there is no hardware issue. :) --mPOSj6iWmtyhwOMz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6N6MACgkQKc512sD3afg6uACdHPrrIKefFoYD8I5gg6tioj0R hUwAoMCIRxLDQEzpRgvRqXg+04p0TLl9 =vbBR -----END PGP SIGNATURE----- --mPOSj6iWmtyhwOMz-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:45:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4B9F106564A; Fri, 23 Jan 2009 21:45:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id A940E8FC1B; Fri, 23 Jan 2009 21:45:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5016028rvf.43 for ; Fri, 23 Jan 2009 13:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HuJgWXD0zp0jCQUls7SQCykM4HPpWKYtPf6KwbKbK0Y=; b=lxMY5qOtxToLKWOvSQJH819LEn23NKQEub2oCWKLuuQ462/GYPA3p3mHD3qrhsVWKT zfDf726mDOr54sI0aBDkmeJ7oHL2by+wefnABfR7DKKHfpf0KRXcgWYbc3PlmSttQfre 0g6X+0pqNIkizD4ObcY7jnzLdr6rp5urvtwPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HX8wUwdfmjlNEklE2fuMFOb8vQO9p4yfmfoyLI/wq0UF9c13KIT6fKnbXiGglyKbgO APNFEWtDGCn1hLRg1H3Xsuc+K88qNttUHpygCNbHd6fop9Di+q5Qlpgn1/cM1ELITUon M5UjsGYtFv1B/vO1HCPIdZORp/ItqoDe5SExE= MIME-Version: 1.0 Received: by 10.140.165.21 with SMTP id n21mr3240292rve.240.1232747134303; Fri, 23 Jan 2009 13:45:34 -0800 (PST) In-Reply-To: <200901232146.58360.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232029.10538.hselasky@c2i.net> <200901232146.58360.hselasky@c2i.net> Date: Fri, 23 Jan 2009 13:45:34 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:45:35 -0000 Hans Petter, [...] >> > First of all I've made some patches which try to tidy up the USB blutooth >> > driver. Please see: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=156577 >> > http://perforce.freebsd.org/chv.cgi?CH=156579 >> >> thanks! unfortunately, i have few problems with those patches. please >> read below. >> >> >> that should not be needed (in theory) but i will add it. >> > >> > Yes! We are multithreaded! >> >> please tell me that you read the blob about locking strategy at the >> top of ng_ubt2.c file. when ubt_task() is pending, it holds a >> reference to the netgraph node. that means the pointer is still >> pointing to a valid structure, but the node is marked as "dead" and >> NG_NODE[_NOT]_VALID() macros can be use to check for that. so, even if >> task is still pending while the rest of ng_ubt2 stuff is gone, it does >> not matter because task holds netgraph node. so the next time task is >> executed it will see that the node is "dead", release the node and >> simply return doing nothing. > > This kind of complexity is unneccesary. We should be able to drain a node, or > sleep until a node is released. > > 0) stop all USB activity > 1) free node > 2) wait until the node is actually freed > 3) free USB resources which might access node fields > > Conclusion: > > No checks are required inside any of the USB callbacks. i've added taskqueue_drain() to detach() in my "stall" diff that i posted few hours back. is that addresses some of your concerns? also keep in mind that while netgraph node is created and destroyed primarily by the driver in response to hardware arrival and departure, nothing protects it from the netgraph side. in other words there is another way to manipulate netgraph node using netgraph api. for example user can request shutdown of a netgraph node, etc. so all of this has to be taking into consideration. in fact, if i understand you correctly, with addition of taskqueue_drain() to detach(), the later becomes completely synchronous. that is 1) NG_NODE_REF() 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the hooks, etc. etc.) 3) taskqueue_drain() (i.e. sleep until task has finished) 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) 5) NG_NODE_UNREF() 6) free everything up in theory, items (1) and (5) above just an additional protection because i was not sure about inner workings of usb2. i think, when we sort everything out they can be removed. >> >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called >> >> > unlocked. >> >> >> >> yes, usb2_transfer_unsetup() does that, does it not? >> > >> > That is correct, but sometimes you need to stop the transfers at an >> > earlier point. It depends on your design. right >> when detach() is called its already out of driver's hands. all it can >> do now is to call unsetup(), or am i missing something here? > > The correct thing is to do a usb2_transfer_drain() which will wait until the > callback has been called back, if a transfer is pending. i do not understand. if usb2_transfer_unsetup() calls usb2_transfer_drain() and sleeps, then what difference does it make in detach()? i just followed original code that did it this way, i.e. drain and unsetup all transfers in one call. > In USB2 a "usb2_start_hardware()" call is always paired with a USB transfer > callback, no matter what you do! This way of design has been chosen so that > you can do refcounts inside the callback! ok, and that is exactly what code does. the only thing is that refcounts are on netgraph node and not on softc structure. again the reason for that is because netgraph node can be accessed from both usb2 driver and netgraph subsystem directly. > > I see in your code that you try to do things Asynchronously. This >> > complicates stuff quite a lot. In my patches I've tried to do some things >> > synchronously. >> >> no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. >> period. you _CAN_NOT_ grab usb interface mutexes unless you can >> absolutely guarantee that they will not sleep for any significant >> amount of time. > > usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will never > sleep. The exception is "usb2_transfer_drain()" which can sleep for a few > milliseconds and is only called when the hook is disconnected. I do not see > that as a problem versus having "X" more checks in the code. well, when i looked at the code, i saw that both functions do USB_BUS_LOCK() and USB_BUS_UNLOCK(). i do not know enough about those locks and usb2 in general, so i decided to err on the side of caution and move all the operations that could potentially sleep into the taskqueue context. this actually completely decouples netgraph from usb2, and that is a "good thing (tm)" imo :) a little bit of complexity is totally justified here imo. also, now that you mentioned it, i should call usb2_transfer_drain() in ubt_task() instead of usb2_transfer_stop() to make transfer stop completely synchronous as well. please let me reiterate, sleeping in netgraph is NOT allowed. even if its for a few milliseconds. please accept it as a fact. think of all netgraph methods as fast interrupt handlers. it is very typical for fast interrupt handlers to do minimal amount of work and schedule swi to do more heavy processing. that is exactly what the code does here. >> netgraph is essentially single threaded and by >> sleeping you will stall entire netgraph subsystem and not just current >> thread. > > If we sleep 10 milliseconds on a UBT hook disconnect, is that a big problem? > How often will UBT hook disconnect be called? it does not matter how often it will or will not be. please read my comments about. once again, no sleeping in netgraph :) >> so, objection #1 (the biggest one) is: please leave sc_mbufq_mtx and >> ubt_task() glue in place. it is needed as far as i can tell. > > What I see is that USB already has a separate process handling the callback so > that when you call "usb2_transfer_start()" this other process is woken up. > Are you sure that there is a measurable gain using "ubt_task()" versus the > way I'm doing it? yes, i'm sure. i did not invent anything new here. it all follows typical fast interrupt handler/swi (upper/bottom half for linux foks :) model. there is really nothing complicated about it, except "scary" calls to NG_NODE_REF/UNREF and NG_NODE[_NOT]_VALID() :) i'm quite happy to make an additional cleanups that you would require, but asynchronous design is something that need to stay in place, imo. >> objection #2 (somewhat major). please do NOT remove NG_NODE_REF() call >> in detach() before calling ng_rmnode_self() (unless you remove >> NG_NODE_UNREF() below as well). again the reason here is to tell >> netgraph node that we are dying, but make sure we keep node_p pointer >> pointing to a valid structure as long as possible. to summarize, > > We are already holding a reference to the node from ubt_attach(), right? Why > do we need another node reference? there is no NG_NODE_REF in attach(). when we create node is comes with one reference and that reference is removed by ng_rmnode_self(). please read my comments about detach() above. hopefully it will make sense now. [...] >> more of a question than objection. why you insist on having single >> mutex for both interfaces? isoc transfers callbacks will be called >> much more often that control, bulk and interrupt callbacks, so >> wouldn't it make sense to use different lock for isoc transfers? > > Because a single mutex is much easier to maintain and I see no gain fine > graining more for a bluetooth device :-) i do not really have strong opinion about it. i just thought there would be less contention between isoc and bulk/intr/ctrl transfers when they use different locks. probably does not matter, since everything is going over the same bus. i'm fine with this change utill someone has credible evidence otherwise. >> changes in attach() and usb2_config structures are fine (i guess). but >> please keep asynchronous design in place. it is required. > > Is it possible we can make a compromise here? From my experience synchronous > code is smaller and easier to understand than asynchronous code! The only > disadvantage about synchronous code is that more threads might be required. > And hence Netgraph is single threaded other signalling might be delayed, but > is that a real problem if we are talking about delays around 1x10ms ever time > you disconnect the hook of an UBT node? like i said, i'm quite happy to compromise here. i will make any change that would help to understand/maintain code better. unfortunately, asynchronous design would have to stay in one form or another. netgraph has to be completely decoupled from any other subsystem, imo. it is just what it is. not really related to this conversation, but think about how many changes went into freebsd between version 6 and 8, and, yet, netgraph (including bluetooth) code changed very little in comparison. so keeping things "separate" is a "good thing(tm)" :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:45:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4B9F106564A; Fri, 23 Jan 2009 21:45:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id A940E8FC1B; Fri, 23 Jan 2009 21:45:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5016028rvf.43 for ; Fri, 23 Jan 2009 13:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HuJgWXD0zp0jCQUls7SQCykM4HPpWKYtPf6KwbKbK0Y=; b=lxMY5qOtxToLKWOvSQJH819LEn23NKQEub2oCWKLuuQ462/GYPA3p3mHD3qrhsVWKT zfDf726mDOr54sI0aBDkmeJ7oHL2by+wefnABfR7DKKHfpf0KRXcgWYbc3PlmSttQfre 0g6X+0pqNIkizD4ObcY7jnzLdr6rp5urvtwPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HX8wUwdfmjlNEklE2fuMFOb8vQO9p4yfmfoyLI/wq0UF9c13KIT6fKnbXiGglyKbgO APNFEWtDGCn1hLRg1H3Xsuc+K88qNttUHpygCNbHd6fop9Di+q5Qlpgn1/cM1ELITUon M5UjsGYtFv1B/vO1HCPIdZORp/ItqoDe5SExE= MIME-Version: 1.0 Received: by 10.140.165.21 with SMTP id n21mr3240292rve.240.1232747134303; Fri, 23 Jan 2009 13:45:34 -0800 (PST) In-Reply-To: <200901232146.58360.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232029.10538.hselasky@c2i.net> <200901232146.58360.hselasky@c2i.net> Date: Fri, 23 Jan 2009 13:45:34 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:45:35 -0000 Hans Petter, [...] >> > First of all I've made some patches which try to tidy up the USB blutooth >> > driver. Please see: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=156577 >> > http://perforce.freebsd.org/chv.cgi?CH=156579 >> >> thanks! unfortunately, i have few problems with those patches. please >> read below. >> >> >> that should not be needed (in theory) but i will add it. >> > >> > Yes! We are multithreaded! >> >> please tell me that you read the blob about locking strategy at the >> top of ng_ubt2.c file. when ubt_task() is pending, it holds a >> reference to the netgraph node. that means the pointer is still >> pointing to a valid structure, but the node is marked as "dead" and >> NG_NODE[_NOT]_VALID() macros can be use to check for that. so, even if >> task is still pending while the rest of ng_ubt2 stuff is gone, it does >> not matter because task holds netgraph node. so the next time task is >> executed it will see that the node is "dead", release the node and >> simply return doing nothing. > > This kind of complexity is unneccesary. We should be able to drain a node, or > sleep until a node is released. > > 0) stop all USB activity > 1) free node > 2) wait until the node is actually freed > 3) free USB resources which might access node fields > > Conclusion: > > No checks are required inside any of the USB callbacks. i've added taskqueue_drain() to detach() in my "stall" diff that i posted few hours back. is that addresses some of your concerns? also keep in mind that while netgraph node is created and destroyed primarily by the driver in response to hardware arrival and departure, nothing protects it from the netgraph side. in other words there is another way to manipulate netgraph node using netgraph api. for example user can request shutdown of a netgraph node, etc. so all of this has to be taking into consideration. in fact, if i understand you correctly, with addition of taskqueue_drain() to detach(), the later becomes completely synchronous. that is 1) NG_NODE_REF() 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the hooks, etc. etc.) 3) taskqueue_drain() (i.e. sleep until task has finished) 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) 5) NG_NODE_UNREF() 6) free everything up in theory, items (1) and (5) above just an additional protection because i was not sure about inner workings of usb2. i think, when we sort everything out they can be removed. >> >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called >> >> > unlocked. >> >> >> >> yes, usb2_transfer_unsetup() does that, does it not? >> > >> > That is correct, but sometimes you need to stop the transfers at an >> > earlier point. It depends on your design. right >> when detach() is called its already out of driver's hands. all it can >> do now is to call unsetup(), or am i missing something here? > > The correct thing is to do a usb2_transfer_drain() which will wait until the > callback has been called back, if a transfer is pending. i do not understand. if usb2_transfer_unsetup() calls usb2_transfer_drain() and sleeps, then what difference does it make in detach()? i just followed original code that did it this way, i.e. drain and unsetup all transfers in one call. > In USB2 a "usb2_start_hardware()" call is always paired with a USB transfer > callback, no matter what you do! This way of design has been chosen so that > you can do refcounts inside the callback! ok, and that is exactly what code does. the only thing is that refcounts are on netgraph node and not on softc structure. again the reason for that is because netgraph node can be accessed from both usb2 driver and netgraph subsystem directly. > > I see in your code that you try to do things Asynchronously. This >> > complicates stuff quite a lot. In my patches I've tried to do some things >> > synchronously. >> >> no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. >> period. you _CAN_NOT_ grab usb interface mutexes unless you can >> absolutely guarantee that they will not sleep for any significant >> amount of time. > > usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will never > sleep. The exception is "usb2_transfer_drain()" which can sleep for a few > milliseconds and is only called when the hook is disconnected. I do not see > that as a problem versus having "X" more checks in the code. well, when i looked at the code, i saw that both functions do USB_BUS_LOCK() and USB_BUS_UNLOCK(). i do not know enough about those locks and usb2 in general, so i decided to err on the side of caution and move all the operations that could potentially sleep into the taskqueue context. this actually completely decouples netgraph from usb2, and that is a "good thing (tm)" imo :) a little bit of complexity is totally justified here imo. also, now that you mentioned it, i should call usb2_transfer_drain() in ubt_task() instead of usb2_transfer_stop() to make transfer stop completely synchronous as well. please let me reiterate, sleeping in netgraph is NOT allowed. even if its for a few milliseconds. please accept it as a fact. think of all netgraph methods as fast interrupt handlers. it is very typical for fast interrupt handlers to do minimal amount of work and schedule swi to do more heavy processing. that is exactly what the code does here. >> netgraph is essentially single threaded and by >> sleeping you will stall entire netgraph subsystem and not just current >> thread. > > If we sleep 10 milliseconds on a UBT hook disconnect, is that a big problem? > How often will UBT hook disconnect be called? it does not matter how often it will or will not be. please read my comments about. once again, no sleeping in netgraph :) >> so, objection #1 (the biggest one) is: please leave sc_mbufq_mtx and >> ubt_task() glue in place. it is needed as far as i can tell. > > What I see is that USB already has a separate process handling the callback so > that when you call "usb2_transfer_start()" this other process is woken up. > Are you sure that there is a measurable gain using "ubt_task()" versus the > way I'm doing it? yes, i'm sure. i did not invent anything new here. it all follows typical fast interrupt handler/swi (upper/bottom half for linux foks :) model. there is really nothing complicated about it, except "scary" calls to NG_NODE_REF/UNREF and NG_NODE[_NOT]_VALID() :) i'm quite happy to make an additional cleanups that you would require, but asynchronous design is something that need to stay in place, imo. >> objection #2 (somewhat major). please do NOT remove NG_NODE_REF() call >> in detach() before calling ng_rmnode_self() (unless you remove >> NG_NODE_UNREF() below as well). again the reason here is to tell >> netgraph node that we are dying, but make sure we keep node_p pointer >> pointing to a valid structure as long as possible. to summarize, > > We are already holding a reference to the node from ubt_attach(), right? Why > do we need another node reference? there is no NG_NODE_REF in attach(). when we create node is comes with one reference and that reference is removed by ng_rmnode_self(). please read my comments about detach() above. hopefully it will make sense now. [...] >> more of a question than objection. why you insist on having single >> mutex for both interfaces? isoc transfers callbacks will be called >> much more often that control, bulk and interrupt callbacks, so >> wouldn't it make sense to use different lock for isoc transfers? > > Because a single mutex is much easier to maintain and I see no gain fine > graining more for a bluetooth device :-) i do not really have strong opinion about it. i just thought there would be less contention between isoc and bulk/intr/ctrl transfers when they use different locks. probably does not matter, since everything is going over the same bus. i'm fine with this change utill someone has credible evidence otherwise. >> changes in attach() and usb2_config structures are fine (i guess). but >> please keep asynchronous design in place. it is required. > > Is it possible we can make a compromise here? From my experience synchronous > code is smaller and easier to understand than asynchronous code! The only > disadvantage about synchronous code is that more threads might be required. > And hence Netgraph is single threaded other signalling might be delayed, but > is that a real problem if we are talking about delays around 1x10ms ever time > you disconnect the hook of an UBT node? like i said, i'm quite happy to compromise here. i will make any change that would help to understand/maintain code better. unfortunately, asynchronous design would have to stay in one form or another. netgraph has to be completely decoupled from any other subsystem, imo. it is just what it is. not really related to this conversation, but think about how many changes went into freebsd between version 6 and 8, and, yet, netgraph (including bluetooth) code changed very little in comparison. so keeping things "separate" is a "good thing(tm)" :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:47:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A9E1065678; Fri, 23 Jan 2009 21:47:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id BFB798FC29; Fri, 23 Jan 2009 21:47:02 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=WvNHzc6HU6V8RphWTfIA:9 a=dWkBLp-Za2aCqeivcawA:7 a=R2xTSYDhVxSXAMLanItQv7ipj0kA:4 a=LY0hPdMaydYA:10 a=zW2DpKW1sIPgwngOTDEA:9 a=6tkT_cbIcdb0Gs1O_hIA:7 a=lvNXzYixo1PJBOmekOodzc1mFdsA:4 a=NfA2RSpTaHsA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 134186860; Fri, 23 Jan 2009 22:47:00 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Lars Engels Date: Fri, 23 Jan 2009 22:49:23 +0100 User-Agent: KMail/1.9.7 References: <20090123212952.GM60948@e.0x20.net> <20090123213323.GO60948@e.0x20.net> In-Reply-To: <20090123213323.GO60948@e.0x20.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ltjeJufHBsVDcXZ" Message-Id: <200901232249.25153.hselasky@c2i.net> Cc: current@freebsd.org, Maksim Yevmenkin Subject: [PATCH2] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:47:05 -0000 --Boundary-00=_ltjeJufHBsVDcXZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 23 January 2009, Lars Engels wrote: > I forgot to mention that both bt devices worked without problems with > the old stack, so there is no hardware issue. :) Hi, Bluetooth has worked fine with the new USB stack aswell. I have tested this myself. It is just some small problems with the latest changes from Maksim that needs to be ironed out. Maybe you can give my patch a try? cvsup first Then: cd /usr/src/sys/dev/usb2/bluetooth; cat bt_patch.diff | patch recompile "/usr/src/sys/modules/usb2/bluetooth_ng" module only and test, assuming you are loading the module. I'm not sure if my patch is 100% correct, Maksim is the bluetooth+Netgraph expert, but at least my bluetooth dongle now works again. --HPS --Boundary-00=_ltjeJufHBsVDcXZ Content-Type: text/x-diff; charset="iso-8859-1"; name="bt_patch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bt_patch.diff" diff -u ng_ubt2.c ng_ubt2.c --- ng_ubt2.c Wed Jan 21 17:51:04 2009 +++ ng_ubt2.c Fri Jan 23 20:17:44 2009 @@ -28,7 +28,7 @@ * SUCH DAMAGE. * * $Id: ng_ubt.c,v 1.16 2003/10/10 19:15:06 max Exp $ - * $FreeBSD$ + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2.c,v 1.6 2009/01/20 23:25:27 emax Exp $ */ /* @@ -37,22 +37,12 @@ * driver will *NOT* create traditional /dev/ enties, only Netgraph * node. * - * NOTE ON LOCKS USED: ng_ubt2 drives uses 3 locks (mutexes) + * NOTE ON LOCKS USED: ng_ubt2 drives uses 1 lock * - * 1) sc_if_mtx[0] - lock for device's interface #0. This lock is used - * by USB2 for any USB request going over device's interface #0, i.e. - * interrupt, control and bulk transfers. - * - * 2) sc_if_mtx[1] - lock for device's interface #1. This lock is used - * by USB2 for any USB request going over device's interface #1, i.e - * isoc. transfers. - * - * 3) sc_mbufq_mtx - lock for mbufq and task flags. This lock is used - * to protect device's outgoing mbuf queues and task flags. This lock - * *SHOULD NOT* be grabbed for a long time. In fact, think of it as a - * spin lock. + * The "sc_mtx" lock protects both USB and Netgraph data. The "sc_mtx" + * lock should not be grabbed for a long time. * - * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 3 different contexts. + * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 2 different contexts. * * 1) USB context. This is where all the USB related stuff happens. All * callbacks run in this context. All callbacks are called (by USB2) with @@ -67,26 +57,6 @@ * grab any long-sleep lock in the Netgraph context. In fact, the only * lock that is allowed in the Netgraph context is the sc_mbufq_mtx lock. * - * 3) Taskqueue context. This is where ubt_task runs. Since we are NOT allowed - * to grab any locks in the Netgraph context, and, USB2 requires us to - * grab interface lock before doing things with transfers, we need to - * transition from the Netgraph context to the Taskqueue context before - * we can call into USB2 subsystem. - * - * So, to put everything together, the rules are as follows. - * It is OK to call from the USB context or the Taskqueue context into - * the Netgraph context (i.e. call NG_SEND_xxx functions). In other words - * it is allowed to call into the Netgraph context with locks held. - * Is it *NOT* OK to call from the Netgraph context into the USB context, - * because USB2 requires us to grab interface locks and we can not do that. - * To avoid this, we set task flags to indicate which actions we want to - * perform and schedule ubt_task which would run in the Taskqueue context. - * Is is OK to call from the Taskqueue context into the USB context, - * and, ubt_task does just that (i.e. grabs appropriate interface locks - * before calling into USB2). - * Access to the outgoing queues and task flags is controlled by the - * sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should - * really be a spin lock. * All USB callbacks accept Netgraph node pointer as private data. To * ensure that Netgraph node pointer remains valid for the duration of the * transfer, we grab a referrence to the node. In other words, if transfer is @@ -111,7 +81,6 @@ #include #include -#include #include #include @@ -128,10 +97,6 @@ static device_attach_t ubt_attach; static device_detach_t ubt_detach; -static int ubt_task_schedule(ubt_softc_p, int); -static task_fn_t ubt_task; -static void ubt_xfer_start(ubt_softc_p, int); - /* Netgraph methods */ static ng_constructor_t ng_ubt_constructor; static ng_shutdown_t ng_ubt_shutdown; @@ -279,6 +244,7 @@ .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 0, .mh.bufsize = UBT_BULK_WRITE_BUFFER_SIZE, .mh.flags = { .pipe_bof = 1, }, .mh.callback = &ubt_bulk_write_callback, @@ -288,6 +254,7 @@ .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 0, .mh.bufsize = UBT_BULK_READ_BUFFER_SIZE, .mh.flags = { .pipe_bof = 1, .short_xfer_ok = 1, }, .mh.callback = &ubt_bulk_read_callback, @@ -297,6 +264,7 @@ .type = UE_INTERRUPT, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 0, .mh.flags = { .pipe_bof = 1, .short_xfer_ok = 1, }, .mh.bufsize = UBT_INTR_BUFFER_SIZE, .mh.callback = &ubt_intr_read_callback, @@ -306,6 +274,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = UBT_CTRL_BUFFER_SIZE, .mh.callback = &ubt_ctrl_write_callback, .mh.timeout = 5000, /* 5 seconds */ @@ -315,6 +284,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_bulk_write_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -325,6 +295,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_bulk_read_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -338,6 +309,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_intr_read_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -353,6 +325,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -363,6 +336,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -373,6 +347,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -383,6 +358,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -450,7 +426,8 @@ struct ubt_softc *sc = device_get_softc(dev); struct usb2_endpoint_descriptor *ed; uint16_t wMaxPacketSize; - uint8_t alt_index, iface_index, i, j; + uint8_t alt_index, i, j; + uint8_t iface_index[2]; device_set_usb2_desc(dev); @@ -483,28 +460,22 @@ /* state */ sc->sc_debug = NG_UBT_WARN_LEVEL; - sc->sc_flags = 0; + UBT_STAT_RESET(sc); /* initialize locks */ - mtx_init(&sc->sc_mbufq_mtx, "ubt mbufq", NULL, MTX_DEF); - mtx_init(&sc->sc_if_mtx[0], "ubt if0", NULL, MTX_DEF | MTX_RECURSE); - mtx_init(&sc->sc_if_mtx[1], "ubt if1", NULL, MTX_DEF | MTX_RECURSE); + mtx_init(&sc->sc_mtx, "UBT", NULL, MTX_DEF | MTX_RECURSE); /* initialize packet queues */ NG_BT_MBUFQ_INIT(&sc->sc_cmdq, UBT_DEFAULT_QLEN); NG_BT_MBUFQ_INIT(&sc->sc_aclq, UBT_DEFAULT_QLEN); NG_BT_MBUFQ_INIT(&sc->sc_scoq, UBT_DEFAULT_QLEN); - /* initialize glue task */ - sc->sc_task_flags = 0; - TASK_INIT(&sc->sc_task, 0, ubt_task, sc->sc_node); - /* * Configure Bluetooth USB device. Discover all required USB * interfaces and endpoints. * - * Device is expected to be a high-speed device. + * Device is expected to be a full-speed device. * * USB device must present two interfaces: * 1) Interface 0 that has 3 endpoints @@ -520,20 +491,11 @@ * configurations with different packet size. */ - bzero(&sc->sc_xfer, sizeof(sc->sc_xfer)); - /* * Interface 0 */ - iface_index = 0; - if (usb2_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, - ubt_config, UBT_IF_0_N_TRANSFER, - sc->sc_node, &sc->sc_if_mtx[0])) { - device_printf(dev, "could not allocate transfers for " \ - "interface 0!\n"); - goto detach; - } + iface_index[0] = 0; /* * Interface 1 @@ -580,13 +542,11 @@ goto detach; } - iface_index = 1; - if (usb2_transfer_setup(uaa->device, &iface_index, - &sc->sc_xfer[UBT_IF_0_N_TRANSFER], - &ubt_config[UBT_IF_0_N_TRANSFER], UBT_IF_1_N_TRANSFER, - sc->sc_node, &sc->sc_if_mtx[1])) { - device_printf(dev, "could not allocate transfers for " \ - "interface 1!\n"); + iface_index[1] = 1; + if (usb2_transfer_setup(uaa->device, iface_index, + sc->sc_xfer, ubt_config, UBT_N_TRANSFER, + sc->sc_node, &sc->sc_mtx)) { + device_printf(dev, "could not allocate transfers\n"); goto detach; } @@ -594,6 +554,10 @@ for (i = 1; usb2_get_iface(uaa->device, i) != NULL; i ++) usb2_set_parent_iface(uaa->device, i, uaa->info.bIfaceIndex); + UBT_LOCK(sc); + sc->sc_flags |= UBT_FLAG_READY; + UBT_UNLOCK(sc); + return (0); /* success */ detach: @@ -612,17 +576,33 @@ { struct ubt_softc *sc = device_get_softc(dev); node_p node = sc->sc_node; + uint8_t i; + + UBT_LOCK(sc); + sc->sc_flags &= ~UBT_FLAG_READY; + UBT_UNLOCK(sc); + + /* make sure that all USB transfers are stopped! */ + for (i = 0; i != UBT_N_TRANSFER; i++) + usb2_transfer_drain(sc->sc_xfer[i]); /* Destroy Netgraph node */ if (node != NULL) { sc->sc_node = NULL; - NG_NODE_SET_PRIVATE(node, NULL); NG_NODE_REALLY_DIE(node); - NG_NODE_REF(node); ng_rmnode_self(node); - } + /* Need to wait until Netgraph has shutdown the node! */ + UBT_LOCK(sc); + while (!(sc->sc_flags & UBT_FLAG_SHUTDOWN)) + usb2_pause_mtx(&sc->sc_mtx, 100); + UBT_UNLOCK(sc); + + /* Check if there is a leftover hook */ + if (sc->sc_hook != NULL) + NG_NODE_UNREF(node); + } /* Free USB transfers, if any */ usb2_transfer_unsetup(sc->sc_xfer, UBT_N_TRANSFER); @@ -630,15 +610,13 @@ NG_NODE_UNREF(node); /* Destroy queues */ - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); NG_BT_MBUFQ_DESTROY(&sc->sc_cmdq); NG_BT_MBUFQ_DESTROY(&sc->sc_aclq); NG_BT_MBUFQ_DESTROY(&sc->sc_scoq); - UBT_MBUFQ_UNLOCK(sc); + UBT_UNLOCK(sc); - mtx_destroy(&sc->sc_if_mtx[0]); - mtx_destroy(&sc->sc_if_mtx[1]); - mtx_destroy(&sc->sc_mbufq_mtx); + mtx_destroy(&sc->sc_mtx); return (0); } /* ubt_detach */ @@ -657,37 +635,25 @@ struct usb2_device_request req; struct mbuf *m; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error != 0) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to control pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to control pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: send_next: /* Get next command mbuf, if any */ - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_cmdq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) { UBT_INFO(sc, "HCI command queue is empty\n"); - NG_NODE_UNREF(node); - return; + break; } /* Initialize a USB control request and then schedule it */ @@ -719,8 +685,6 @@ UBT_STAT_OERROR(sc); goto send_next; } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /* ubt_ctrl_write_callback */ @@ -740,19 +704,8 @@ ng_hci_event_pkt_t *hdr; int error; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - m = NULL; switch (USB_GET_STATE(xfer)) { @@ -836,8 +789,7 @@ /* Try to clear stall first */ sc->sc_flags |= UBT_FLAG_INTR_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_CS_RD]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_intr_read_callback */ @@ -855,11 +807,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_INTR_DT_RD]; @@ -867,8 +814,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_INTR_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_intr_read_clear_stall_callback */ /* @@ -887,19 +833,7 @@ uint16_t len; int error; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - m = NULL; switch (USB_GET_STATE(xfer)) { @@ -983,8 +917,7 @@ /* Try to clear stall first */ sc->sc_flags |= UBT_FLAG_READ_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_RD]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_bulk_read_callback */ @@ -1002,11 +935,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_BULK_DT_RD]; @@ -1014,8 +942,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_READ_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_bulk_read_clear_stall_callback */ /* @@ -1031,36 +958,24 @@ struct ubt_softc *sc; struct mbuf *m; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error != 0) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: /* Get next mbuf, if any */ - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_aclq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) { UBT_INFO(sc, "ACL data queue is empty\n"); - NG_NODE_UNREF(node); - return; /* transfer completed */ + break; } /* @@ -1089,8 +1004,7 @@ /* try to clear stall first */ sc->sc_flags |= UBT_FLAG_WRITE_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_WR]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_bulk_write_callback */ @@ -1108,11 +1022,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_BULK_DT_WR]; @@ -1120,8 +1029,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_WRITE_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_bulk_write_clear_stall_callback */ /* @@ -1137,19 +1045,8 @@ struct ubt_softc *sc; int n; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: for (n = 0; n < xfer->nframes; n ++) @@ -1171,8 +1068,6 @@ goto read_next; /* NOT REACHED */ } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /* ubt_isoc_read_callback */ @@ -1277,24 +1172,16 @@ struct mbuf *m; int n, space, offset; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: @@ -1305,10 +1192,7 @@ while (space > 0) { if (m == NULL) { - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_scoq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) break; } @@ -1328,9 +1212,7 @@ /* Put whatever is left from mbuf back on queue */ if (m != NULL) { - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_PREPEND(&sc->sc_scoq, m); - UBT_MBUFQ_UNLOCK(sc); } /* @@ -1355,174 +1237,12 @@ goto send_next; /* NOT REACHED */ } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /**************************************************************************** **************************************************************************** - ** Glue - **************************************************************************** - ****************************************************************************/ - -/* - * Schedule glue task. Should be called with sc_mbufq_mtx held. - * Netgraph context. - */ - -static int -ubt_task_schedule(ubt_softc_p sc, int action) -{ - mtx_assert(&sc->sc_mbufq_mtx, MA_OWNED); - - if ((sc->sc_task_flags & action) == 0) { - /* - * Try to handle corner case when "start all" and "stop all" - * actions can both be set before task is executed. - * - * Assume the following: - * 1) "stop all" after "start all" cancels "start all", and, - * keeps "stop all" - * - * 2) "start all" after "stop all" is fine because task is - * executing "stop all" first - */ - - if (action == UBT_FLAG_T_STOP_ALL && - (sc->sc_task_flags & UBT_FLAG_T_START_ALL) != 0) - sc->sc_task_flags &= ~UBT_FLAG_T_START_ALL; - - sc->sc_task_flags |= action; - } - - if (sc->sc_task_flags & UBT_FLAG_T_PENDING) - return (1); - - if (taskqueue_enqueue(taskqueue_swi, &sc->sc_task) == 0) { - NG_NODE_REF(sc->sc_node); - sc->sc_task_flags |= UBT_FLAG_T_PENDING; - return (1); - } - - /* XXX: i think this should never happen */ - - return (0); -} /* ubt_task_schedule */ - -/* - * Glue task. Examines sc_task_flags and does things depending on it. - * Taskqueue context. - */ - -static void -ubt_task(void *context, int pending) -{ - node_p node = context; - ubt_softc_p sc; - int task_flags; - - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - - sc = NG_NODE_PRIVATE(node); - - UBT_MBUFQ_LOCK(sc); - task_flags = sc->sc_task_flags; - sc->sc_task_flags = 0; - UBT_MBUFQ_UNLOCK(sc); - - /* Stop all USB transfers */ - if (task_flags & UBT_FLAG_T_STOP_ALL) { - int i; - - /* - * Interface #0 - */ - - mtx_lock(&sc->sc_if_mtx[0]); - - for (i = UBT_IF_0_BULK_DT_WR; i < UBT_IF_0_N_TRANSFER; i ++) - usb2_transfer_stop(sc->sc_xfer[i]); - - mtx_unlock(&sc->sc_if_mtx[0]); - - /* - * Interface #1 - */ - - mtx_lock(&sc->sc_if_mtx[1]); - - for (i = UBT_IF_1_ISOC_DT_RD1; i < UBT_N_TRANSFER; i ++) - usb2_transfer_stop(sc->sc_xfer[i]); - - mtx_unlock(&sc->sc_if_mtx[1]); - } - - /* Start all incoming USB transfers */ - if (task_flags & UBT_FLAG_T_START_ALL) { - /* - * Interface #0 - */ - - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_INTR_DT_RD); - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_RD); - mtx_unlock(&sc->sc_if_mtx[0]); - - /* - * Interface #1 - * Start both read and write isoc. transfers by default. - * Get them going all the time even if we have nothing - * to send to avoid any delays. - */ - - mtx_lock(&sc->sc_if_mtx[1]); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD1); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD2); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR1); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR2); - mtx_unlock(&sc->sc_if_mtx[1]); - } - - /* Start outgoing control transfer */ - if (task_flags & UBT_FLAG_T_START_CTRL) { - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_CTRL_DT_WR); - mtx_unlock(&sc->sc_if_mtx[0]); - } - - /* Start outgoing bulk transfer */ - if (task_flags & UBT_FLAG_T_START_BULK) { - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_WR); - mtx_unlock(&sc->sc_if_mtx[0]); - } - - NG_NODE_UNREF(node); -} /* ubt_task */ - -/* - * Start USB transfer. - * Helper function called from ubt_task. Must be called with appropriate - * interface lock held. - * Taskqueue context. - */ - -static void -ubt_xfer_start(ubt_softc_p sc, int transfer) -{ - if (!usb2_transfer_pending(sc->sc_xfer[transfer])) { - NG_NODE_REF(sc->sc_node); - usb2_transfer_start(sc->sc_xfer[transfer]); - } -} /* ubt_xfer_start */ - -/**************************************************************************** - **************************************************************************** ** Netgraph specific **************************************************************************** ****************************************************************************/ @@ -1546,13 +1266,18 @@ static int ng_ubt_shutdown(node_p node) { + struct ubt_softc *sc = NG_NODE_PRIVATE(node); + if (node->nd_flags & NGF_REALLY_DIE) { /* * We came here because the USB device is being * detached, so stop being persistant. */ + UBT_LOCK(sc); + sc->sc_flags |= UBT_FLAG_SHUTDOWN; + UBT_UNLOCK(sc); + NG_NODE_SET_PRIVATE(node, NULL); - NG_NODE_UNREF(node); } else NG_NODE_REVIVE(node); /* tell ng_rmnode we are persisant */ @@ -1592,9 +1317,21 @@ NG_HOOK_FORCE_QUEUE(NG_HOOK_PEER(hook)); - UBT_MBUFQ_LOCK(sc); - ubt_task_schedule(sc, UBT_FLAG_T_START_ALL); - UBT_MBUFQ_UNLOCK(sc); + if (!(sc->sc_flags & UBT_FLAG_READY)) { + /* called too early */ + return (EINVAL); + } + + NG_NODE_REF(sc->sc_node); + + UBT_LOCK(sc); + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_DT_RD]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_DT_RD]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD1]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD2]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR1]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR2]); + UBT_UNLOCK(sc); return (0); } /* ng_ubt_connect */ @@ -1609,6 +1346,7 @@ { node_p node = NG_HOOK_NODE(hook); struct ubt_softc *sc; + uint8_t i; if (NG_NODE_NOT_VALID(node)) return (0); @@ -1618,19 +1356,25 @@ if (hook != sc->sc_hook) return (EINVAL); + /* + * Synchronously drain all USB transfers: + * Can take some milliseconds! + */ + for (i = 0; i != UBT_N_TRANSFER; i++) + usb2_transfer_drain(sc->sc_xfer[i]); + sc->sc_hook = NULL; - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); /* Drain queues */ NG_BT_MBUFQ_DRAIN(&sc->sc_cmdq); NG_BT_MBUFQ_DRAIN(&sc->sc_aclq); NG_BT_MBUFQ_DRAIN(&sc->sc_scoq); - /* Kick off task to stop all USB xfers */ - ubt_task_schedule(sc, UBT_FLAG_T_STOP_ALL); + UBT_UNLOCK(sc); - UBT_MBUFQ_UNLOCK(sc); + NG_NODE_UNREF(node); return (0); } /* ng_ubt_disconnect */ @@ -1664,7 +1408,6 @@ "Refs: %d\n" \ "Hook: %s\n" \ "Flags: %#x\n" \ - "Task flags: %#x\n" \ "Debug: %d\n" \ "CMD queue: [have:%d,max:%d]\n" \ "ACL queue: [have:%d,max:%d]\n" \ @@ -1672,7 +1415,6 @@ node->nd_refs, (sc->sc_hook != NULL) ? NG_UBT_HOOK:"", sc->sc_flags, - sc->sc_task_flags, sc->sc_debug, sc->sc_cmdq.len, sc->sc_cmdq.maxlen, @@ -1823,7 +1565,8 @@ struct ubt_softc *sc = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); struct mbuf *m; struct ng_bt_mbufq *q; - int action, error = 0; + int error = 0; + uint8_t xfer_action; if (hook != sc->sc_hook) { error = EINVAL; @@ -1853,7 +1596,7 @@ UBT_CTRL_BUFFER_SIZE, m->m_pkthdr.len); q = &sc->sc_cmdq; - action = UBT_FLAG_T_START_CTRL; + xfer_action = UBT_IF_0_CTRL_DT_WR; break; case NG_HCI_ACL_DATA_PKT: @@ -1863,12 +1606,12 @@ UBT_BULK_WRITE_BUFFER_SIZE, m->m_pkthdr.len); q = &sc->sc_aclq; - action = UBT_FLAG_T_START_BULK; + xfer_action = UBT_IF_0_BULK_DT_WR; break; case NG_HCI_SCO_DATA_PKT: q = &sc->sc_scoq; - action = 0; + xfer_action = 255; break; default: @@ -1881,10 +1624,10 @@ /* NOT REACHED */ } - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); if (NG_BT_MBUFQ_FULL(q)) { NG_BT_MBUFQ_DROP(q); - UBT_MBUFQ_UNLOCK(sc); + UBT_UNLOCK(sc); UBT_ERR(sc, "Dropping HCI frame 0x%02x, len=%d. Queue full\n", *mtod(m, uint8_t *), m->m_pkthdr.len); @@ -1894,9 +1637,9 @@ /* Loose HCI packet type, enqueue mbuf and kick off task */ m_adj(m, sizeof(uint8_t)); NG_BT_MBUFQ_ENQUEUE(q, m); - ubt_task_schedule(sc, action); - - UBT_MBUFQ_UNLOCK(sc); + if (xfer_action != 255) + usb2_transfer_start(sc->sc_xfer[xfer_action]); + UBT_UNLOCK(sc); } done: NG_FREE_ITEM(item); @@ -1962,4 +1705,3 @@ MODULE_DEPEND(ng_ubt, ng_hci, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION); MODULE_DEPEND(ng_ubt, usb2_bluetooth, 1, 1, 1); MODULE_DEPEND(ng_ubt, usb2_core, 1, 1, 1); - diff -u ng_ubt2_var.h ng_ubt2_var.h --- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 +++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 @@ -28,7 +28,7 @@ * SUCH DAMAGE. * * $Id: ng_ubt_var.h,v 1.2 2003/03/22 23:44:36 max Exp $ - * $FreeBSD$ + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2_var.h,v 1.2 2009/01/20 22:17:05 emax Exp $ */ #ifndef _NG_UBT_VAR_H_ @@ -47,8 +47,8 @@ #define UBT_WARN(...) UBT_DEBUG(NG_UBT_WARN_LEVEL, __VA_ARGS__) #define UBT_INFO(...) UBT_DEBUG(NG_UBT_INFO_LEVEL, __VA_ARGS__) -#define UBT_MBUFQ_LOCK(sc) mtx_lock(&(sc)->sc_mbufq_mtx) -#define UBT_MBUFQ_UNLOCK(sc) mtx_unlock(&(sc)->sc_mbufq_mtx) +#define UBT_LOCK(sc) mtx_lock(&(sc)->sc_mtx) +#define UBT_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) /* Bluetooth USB control request type */ #define UBT_HCI_REQUEST 0x20 @@ -65,17 +65,14 @@ UBT_IF_0_BULK_CS_WR, UBT_IF_0_BULK_CS_RD, UBT_IF_0_INTR_CS_RD, - UBT_IF_0_N_TRANSFER, /* number of interface 0's transfers */ /* Interface #1 transfers */ - UBT_IF_1_ISOC_DT_RD1 = UBT_IF_0_N_TRANSFER, + UBT_IF_1_ISOC_DT_RD1, UBT_IF_1_ISOC_DT_RD2, UBT_IF_1_ISOC_DT_WR1, UBT_IF_1_ISOC_DT_WR2, UBT_N_TRANSFER, /* total number of transfers */ - - UBT_IF_1_N_TRANSFER = UBT_N_TRANSFER - UBT_IF_1_ISOC_DT_RD1, }; /* USB device softc structure */ @@ -89,6 +86,8 @@ #define UBT_FLAG_READ_STALL (1 << 0) /* read transfer has stalled */ #define UBT_FLAG_WRITE_STALL (1 << 1) /* write transfer has stalled */ #define UBT_FLAG_INTR_STALL (1 << 2) /* inter transfer has stalled */ +#define UBT_FLAG_READY (1 << 4) /* set when we are ready */ +#define UBT_FLAG_SHUTDOWN (1 << 5) /* set when we are shutdown */ ng_ubt_node_stat_ep sc_stat; /* statistic */ #define UBT_STAT_PCKTS_SENT(sc) (sc)->sc_stat.pckts_sent ++ @@ -100,11 +99,9 @@ #define UBT_STAT_RESET(sc) bzero(&(sc)->sc_stat, sizeof((sc)->sc_stat)) /* USB device specific */ - struct mtx sc_if_mtx[2]; /* interface locks */ + struct mtx sc_mtx; struct usb2_xfer *sc_xfer[UBT_N_TRANSFER]; - struct mtx sc_mbufq_mtx; /* lock for all queues */ - /* HCI commands */ struct ng_bt_mbufq sc_cmdq; /* HCI command queue */ #define UBT_CTRL_BUFFER_SIZE (sizeof(struct usb2_device_request) + \ @@ -123,17 +120,6 @@ /* Netgraph specific */ node_p sc_node; /* pointer back to node */ hook_p sc_hook; /* upstream hook */ - - /* Glue */ - int sc_task_flags; /* task flags */ -#define UBT_FLAG_T_PENDING (1 << 0) /* task pending */ -#define UBT_FLAG_T_STOP_ALL (1 << 1) /* stop all xfers */ -#define UBT_FLAG_T_START_ALL (1 << 2) /* start all read and isoc - write xfers */ -#define UBT_FLAG_T_START_CTRL (1 << 3) /* start control xfer (write) */ -#define UBT_FLAG_T_START_BULK (1 << 4) /* start bulk xfer (write) */ - - struct task sc_task; }; typedef struct ubt_softc ubt_softc_t; typedef struct ubt_softc * ubt_softc_p; --Boundary-00=_ltjeJufHBsVDcXZ-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:47:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A9E1065678; Fri, 23 Jan 2009 21:47:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id BFB798FC29; Fri, 23 Jan 2009 21:47:02 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=WvNHzc6HU6V8RphWTfIA:9 a=dWkBLp-Za2aCqeivcawA:7 a=R2xTSYDhVxSXAMLanItQv7ipj0kA:4 a=LY0hPdMaydYA:10 a=zW2DpKW1sIPgwngOTDEA:9 a=6tkT_cbIcdb0Gs1O_hIA:7 a=lvNXzYixo1PJBOmekOodzc1mFdsA:4 a=NfA2RSpTaHsA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 134186860; Fri, 23 Jan 2009 22:47:00 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Lars Engels Date: Fri, 23 Jan 2009 22:49:23 +0100 User-Agent: KMail/1.9.7 References: <20090123212952.GM60948@e.0x20.net> <20090123213323.GO60948@e.0x20.net> In-Reply-To: <20090123213323.GO60948@e.0x20.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ltjeJufHBsVDcXZ" Message-Id: <200901232249.25153.hselasky@c2i.net> Cc: current@freebsd.org, Maksim Yevmenkin Subject: [PATCH2] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:47:05 -0000 --Boundary-00=_ltjeJufHBsVDcXZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 23 January 2009, Lars Engels wrote: > I forgot to mention that both bt devices worked without problems with > the old stack, so there is no hardware issue. :) Hi, Bluetooth has worked fine with the new USB stack aswell. I have tested this myself. It is just some small problems with the latest changes from Maksim that needs to be ironed out. Maybe you can give my patch a try? cvsup first Then: cd /usr/src/sys/dev/usb2/bluetooth; cat bt_patch.diff | patch recompile "/usr/src/sys/modules/usb2/bluetooth_ng" module only and test, assuming you are loading the module. I'm not sure if my patch is 100% correct, Maksim is the bluetooth+Netgraph expert, but at least my bluetooth dongle now works again. --HPS --Boundary-00=_ltjeJufHBsVDcXZ Content-Type: text/x-diff; charset="iso-8859-1"; name="bt_patch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bt_patch.diff" diff -u ng_ubt2.c ng_ubt2.c --- ng_ubt2.c Wed Jan 21 17:51:04 2009 +++ ng_ubt2.c Fri Jan 23 20:17:44 2009 @@ -28,7 +28,7 @@ * SUCH DAMAGE. * * $Id: ng_ubt.c,v 1.16 2003/10/10 19:15:06 max Exp $ - * $FreeBSD$ + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2.c,v 1.6 2009/01/20 23:25:27 emax Exp $ */ /* @@ -37,22 +37,12 @@ * driver will *NOT* create traditional /dev/ enties, only Netgraph * node. * - * NOTE ON LOCKS USED: ng_ubt2 drives uses 3 locks (mutexes) + * NOTE ON LOCKS USED: ng_ubt2 drives uses 1 lock * - * 1) sc_if_mtx[0] - lock for device's interface #0. This lock is used - * by USB2 for any USB request going over device's interface #0, i.e. - * interrupt, control and bulk transfers. - * - * 2) sc_if_mtx[1] - lock for device's interface #1. This lock is used - * by USB2 for any USB request going over device's interface #1, i.e - * isoc. transfers. - * - * 3) sc_mbufq_mtx - lock for mbufq and task flags. This lock is used - * to protect device's outgoing mbuf queues and task flags. This lock - * *SHOULD NOT* be grabbed for a long time. In fact, think of it as a - * spin lock. + * The "sc_mtx" lock protects both USB and Netgraph data. The "sc_mtx" + * lock should not be grabbed for a long time. * - * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 3 different contexts. + * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 2 different contexts. * * 1) USB context. This is where all the USB related stuff happens. All * callbacks run in this context. All callbacks are called (by USB2) with @@ -67,26 +57,6 @@ * grab any long-sleep lock in the Netgraph context. In fact, the only * lock that is allowed in the Netgraph context is the sc_mbufq_mtx lock. * - * 3) Taskqueue context. This is where ubt_task runs. Since we are NOT allowed - * to grab any locks in the Netgraph context, and, USB2 requires us to - * grab interface lock before doing things with transfers, we need to - * transition from the Netgraph context to the Taskqueue context before - * we can call into USB2 subsystem. - * - * So, to put everything together, the rules are as follows. - * It is OK to call from the USB context or the Taskqueue context into - * the Netgraph context (i.e. call NG_SEND_xxx functions). In other words - * it is allowed to call into the Netgraph context with locks held. - * Is it *NOT* OK to call from the Netgraph context into the USB context, - * because USB2 requires us to grab interface locks and we can not do that. - * To avoid this, we set task flags to indicate which actions we want to - * perform and schedule ubt_task which would run in the Taskqueue context. - * Is is OK to call from the Taskqueue context into the USB context, - * and, ubt_task does just that (i.e. grabs appropriate interface locks - * before calling into USB2). - * Access to the outgoing queues and task flags is controlled by the - * sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should - * really be a spin lock. * All USB callbacks accept Netgraph node pointer as private data. To * ensure that Netgraph node pointer remains valid for the duration of the * transfer, we grab a referrence to the node. In other words, if transfer is @@ -111,7 +81,6 @@ #include #include -#include #include #include @@ -128,10 +97,6 @@ static device_attach_t ubt_attach; static device_detach_t ubt_detach; -static int ubt_task_schedule(ubt_softc_p, int); -static task_fn_t ubt_task; -static void ubt_xfer_start(ubt_softc_p, int); - /* Netgraph methods */ static ng_constructor_t ng_ubt_constructor; static ng_shutdown_t ng_ubt_shutdown; @@ -279,6 +244,7 @@ .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 0, .mh.bufsize = UBT_BULK_WRITE_BUFFER_SIZE, .mh.flags = { .pipe_bof = 1, }, .mh.callback = &ubt_bulk_write_callback, @@ -288,6 +254,7 @@ .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 0, .mh.bufsize = UBT_BULK_READ_BUFFER_SIZE, .mh.flags = { .pipe_bof = 1, .short_xfer_ok = 1, }, .mh.callback = &ubt_bulk_read_callback, @@ -297,6 +264,7 @@ .type = UE_INTERRUPT, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 0, .mh.flags = { .pipe_bof = 1, .short_xfer_ok = 1, }, .mh.bufsize = UBT_INTR_BUFFER_SIZE, .mh.callback = &ubt_intr_read_callback, @@ -306,6 +274,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = UBT_CTRL_BUFFER_SIZE, .mh.callback = &ubt_ctrl_write_callback, .mh.timeout = 5000, /* 5 seconds */ @@ -315,6 +284,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_bulk_write_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -325,6 +295,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_bulk_read_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -338,6 +309,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* control pipe */ .direction = UE_DIR_ANY, + .if_index = 0, .mh.bufsize = sizeof(struct usb2_device_request), .mh.callback = &ubt_intr_read_clear_stall_callback, .mh.timeout = 1000, /* 1 second */ @@ -353,6 +325,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -363,6 +336,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -373,6 +347,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -383,6 +358,7 @@ .type = UE_ISOCHRONOUS, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_OUT, + .if_index = 1, .mh.bufsize = 0, /* use "wMaxPacketSize * frames" */ .mh.frames = UBT_ISOC_NFRAMES, .mh.flags = { .short_xfer_ok = 1, }, @@ -450,7 +426,8 @@ struct ubt_softc *sc = device_get_softc(dev); struct usb2_endpoint_descriptor *ed; uint16_t wMaxPacketSize; - uint8_t alt_index, iface_index, i, j; + uint8_t alt_index, i, j; + uint8_t iface_index[2]; device_set_usb2_desc(dev); @@ -483,28 +460,22 @@ /* state */ sc->sc_debug = NG_UBT_WARN_LEVEL; - sc->sc_flags = 0; + UBT_STAT_RESET(sc); /* initialize locks */ - mtx_init(&sc->sc_mbufq_mtx, "ubt mbufq", NULL, MTX_DEF); - mtx_init(&sc->sc_if_mtx[0], "ubt if0", NULL, MTX_DEF | MTX_RECURSE); - mtx_init(&sc->sc_if_mtx[1], "ubt if1", NULL, MTX_DEF | MTX_RECURSE); + mtx_init(&sc->sc_mtx, "UBT", NULL, MTX_DEF | MTX_RECURSE); /* initialize packet queues */ NG_BT_MBUFQ_INIT(&sc->sc_cmdq, UBT_DEFAULT_QLEN); NG_BT_MBUFQ_INIT(&sc->sc_aclq, UBT_DEFAULT_QLEN); NG_BT_MBUFQ_INIT(&sc->sc_scoq, UBT_DEFAULT_QLEN); - /* initialize glue task */ - sc->sc_task_flags = 0; - TASK_INIT(&sc->sc_task, 0, ubt_task, sc->sc_node); - /* * Configure Bluetooth USB device. Discover all required USB * interfaces and endpoints. * - * Device is expected to be a high-speed device. + * Device is expected to be a full-speed device. * * USB device must present two interfaces: * 1) Interface 0 that has 3 endpoints @@ -520,20 +491,11 @@ * configurations with different packet size. */ - bzero(&sc->sc_xfer, sizeof(sc->sc_xfer)); - /* * Interface 0 */ - iface_index = 0; - if (usb2_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, - ubt_config, UBT_IF_0_N_TRANSFER, - sc->sc_node, &sc->sc_if_mtx[0])) { - device_printf(dev, "could not allocate transfers for " \ - "interface 0!\n"); - goto detach; - } + iface_index[0] = 0; /* * Interface 1 @@ -580,13 +542,11 @@ goto detach; } - iface_index = 1; - if (usb2_transfer_setup(uaa->device, &iface_index, - &sc->sc_xfer[UBT_IF_0_N_TRANSFER], - &ubt_config[UBT_IF_0_N_TRANSFER], UBT_IF_1_N_TRANSFER, - sc->sc_node, &sc->sc_if_mtx[1])) { - device_printf(dev, "could not allocate transfers for " \ - "interface 1!\n"); + iface_index[1] = 1; + if (usb2_transfer_setup(uaa->device, iface_index, + sc->sc_xfer, ubt_config, UBT_N_TRANSFER, + sc->sc_node, &sc->sc_mtx)) { + device_printf(dev, "could not allocate transfers\n"); goto detach; } @@ -594,6 +554,10 @@ for (i = 1; usb2_get_iface(uaa->device, i) != NULL; i ++) usb2_set_parent_iface(uaa->device, i, uaa->info.bIfaceIndex); + UBT_LOCK(sc); + sc->sc_flags |= UBT_FLAG_READY; + UBT_UNLOCK(sc); + return (0); /* success */ detach: @@ -612,17 +576,33 @@ { struct ubt_softc *sc = device_get_softc(dev); node_p node = sc->sc_node; + uint8_t i; + + UBT_LOCK(sc); + sc->sc_flags &= ~UBT_FLAG_READY; + UBT_UNLOCK(sc); + + /* make sure that all USB transfers are stopped! */ + for (i = 0; i != UBT_N_TRANSFER; i++) + usb2_transfer_drain(sc->sc_xfer[i]); /* Destroy Netgraph node */ if (node != NULL) { sc->sc_node = NULL; - NG_NODE_SET_PRIVATE(node, NULL); NG_NODE_REALLY_DIE(node); - NG_NODE_REF(node); ng_rmnode_self(node); - } + /* Need to wait until Netgraph has shutdown the node! */ + UBT_LOCK(sc); + while (!(sc->sc_flags & UBT_FLAG_SHUTDOWN)) + usb2_pause_mtx(&sc->sc_mtx, 100); + UBT_UNLOCK(sc); + + /* Check if there is a leftover hook */ + if (sc->sc_hook != NULL) + NG_NODE_UNREF(node); + } /* Free USB transfers, if any */ usb2_transfer_unsetup(sc->sc_xfer, UBT_N_TRANSFER); @@ -630,15 +610,13 @@ NG_NODE_UNREF(node); /* Destroy queues */ - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); NG_BT_MBUFQ_DESTROY(&sc->sc_cmdq); NG_BT_MBUFQ_DESTROY(&sc->sc_aclq); NG_BT_MBUFQ_DESTROY(&sc->sc_scoq); - UBT_MBUFQ_UNLOCK(sc); + UBT_UNLOCK(sc); - mtx_destroy(&sc->sc_if_mtx[0]); - mtx_destroy(&sc->sc_if_mtx[1]); - mtx_destroy(&sc->sc_mbufq_mtx); + mtx_destroy(&sc->sc_mtx); return (0); } /* ubt_detach */ @@ -657,37 +635,25 @@ struct usb2_device_request req; struct mbuf *m; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error != 0) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to control pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to control pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: send_next: /* Get next command mbuf, if any */ - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_cmdq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) { UBT_INFO(sc, "HCI command queue is empty\n"); - NG_NODE_UNREF(node); - return; + break; } /* Initialize a USB control request and then schedule it */ @@ -719,8 +685,6 @@ UBT_STAT_OERROR(sc); goto send_next; } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /* ubt_ctrl_write_callback */ @@ -740,19 +704,8 @@ ng_hci_event_pkt_t *hdr; int error; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - m = NULL; switch (USB_GET_STATE(xfer)) { @@ -836,8 +789,7 @@ /* Try to clear stall first */ sc->sc_flags |= UBT_FLAG_INTR_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_CS_RD]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_intr_read_callback */ @@ -855,11 +807,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_INTR_DT_RD]; @@ -867,8 +814,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_INTR_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_intr_read_clear_stall_callback */ /* @@ -887,19 +833,7 @@ uint16_t len; int error; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - m = NULL; switch (USB_GET_STATE(xfer)) { @@ -983,8 +917,7 @@ /* Try to clear stall first */ sc->sc_flags |= UBT_FLAG_READ_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_RD]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_bulk_read_callback */ @@ -1002,11 +935,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_BULK_DT_RD]; @@ -1014,8 +942,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_READ_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_bulk_read_clear_stall_callback */ /* @@ -1031,36 +958,24 @@ struct ubt_softc *sc; struct mbuf *m; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error != 0) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: /* Get next mbuf, if any */ - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_aclq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) { UBT_INFO(sc, "ACL data queue is empty\n"); - NG_NODE_UNREF(node); - return; /* transfer completed */ + break; } /* @@ -1089,8 +1004,7 @@ /* try to clear stall first */ sc->sc_flags |= UBT_FLAG_WRITE_STALL; usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_WR]); - } else - NG_NODE_UNREF(node); /* cancelled */ + } break; } } /* ubt_bulk_write_callback */ @@ -1108,11 +1022,6 @@ struct ubt_softc *sc; struct usb2_xfer *xfer_other; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); xfer_other = sc->sc_xfer[UBT_IF_0_BULK_DT_WR]; @@ -1120,8 +1029,7 @@ DPRINTF("stall cleared\n"); sc->sc_flags &= ~UBT_FLAG_WRITE_STALL; usb2_transfer_start(xfer_other); - } else - NG_NODE_UNREF(node); /* cant clear stall */ + } } /* ubt_bulk_write_clear_stall_callback */ /* @@ -1137,19 +1045,8 @@ struct ubt_softc *sc; int n; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); - if ((sc->sc_hook == NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { - UBT_INFO(sc, "no upstream hook\n"); - NG_NODE_UNREF(node); - return; /* upstream hook is gone */ - } - switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: for (n = 0; n < xfer->nframes; n ++) @@ -1171,8 +1068,6 @@ goto read_next; /* NOT REACHED */ } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /* ubt_isoc_read_callback */ @@ -1277,24 +1172,16 @@ struct mbuf *m; int n, space, offset; - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - sc = NG_NODE_PRIVATE(node); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if (xfer->error) - UBT_STAT_OERROR(sc); - else { - UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", - xfer->actlen); + UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", + xfer->actlen); + + UBT_STAT_BYTES_SENT(sc, xfer->actlen); + UBT_STAT_PCKTS_SENT(sc); - UBT_STAT_BYTES_SENT(sc, xfer->actlen); - UBT_STAT_PCKTS_SENT(sc); - } /* FALLTHROUGH */ case USB_ST_SETUP: @@ -1305,10 +1192,7 @@ while (space > 0) { if (m == NULL) { - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_DEQUEUE(&sc->sc_scoq, m); - UBT_MBUFQ_UNLOCK(sc); - if (m == NULL) break; } @@ -1328,9 +1212,7 @@ /* Put whatever is left from mbuf back on queue */ if (m != NULL) { - UBT_MBUFQ_LOCK(sc); NG_BT_MBUFQ_PREPEND(&sc->sc_scoq, m); - UBT_MBUFQ_UNLOCK(sc); } /* @@ -1355,174 +1237,12 @@ goto send_next; /* NOT REACHED */ } - - NG_NODE_UNREF(node); /* cancelled */ break; } } /**************************************************************************** **************************************************************************** - ** Glue - **************************************************************************** - ****************************************************************************/ - -/* - * Schedule glue task. Should be called with sc_mbufq_mtx held. - * Netgraph context. - */ - -static int -ubt_task_schedule(ubt_softc_p sc, int action) -{ - mtx_assert(&sc->sc_mbufq_mtx, MA_OWNED); - - if ((sc->sc_task_flags & action) == 0) { - /* - * Try to handle corner case when "start all" and "stop all" - * actions can both be set before task is executed. - * - * Assume the following: - * 1) "stop all" after "start all" cancels "start all", and, - * keeps "stop all" - * - * 2) "start all" after "stop all" is fine because task is - * executing "stop all" first - */ - - if (action == UBT_FLAG_T_STOP_ALL && - (sc->sc_task_flags & UBT_FLAG_T_START_ALL) != 0) - sc->sc_task_flags &= ~UBT_FLAG_T_START_ALL; - - sc->sc_task_flags |= action; - } - - if (sc->sc_task_flags & UBT_FLAG_T_PENDING) - return (1); - - if (taskqueue_enqueue(taskqueue_swi, &sc->sc_task) == 0) { - NG_NODE_REF(sc->sc_node); - sc->sc_task_flags |= UBT_FLAG_T_PENDING; - return (1); - } - - /* XXX: i think this should never happen */ - - return (0); -} /* ubt_task_schedule */ - -/* - * Glue task. Examines sc_task_flags and does things depending on it. - * Taskqueue context. - */ - -static void -ubt_task(void *context, int pending) -{ - node_p node = context; - ubt_softc_p sc; - int task_flags; - - if (NG_NODE_NOT_VALID(node)) { - NG_NODE_UNREF(node); - return; /* netgraph node is gone */ - } - - sc = NG_NODE_PRIVATE(node); - - UBT_MBUFQ_LOCK(sc); - task_flags = sc->sc_task_flags; - sc->sc_task_flags = 0; - UBT_MBUFQ_UNLOCK(sc); - - /* Stop all USB transfers */ - if (task_flags & UBT_FLAG_T_STOP_ALL) { - int i; - - /* - * Interface #0 - */ - - mtx_lock(&sc->sc_if_mtx[0]); - - for (i = UBT_IF_0_BULK_DT_WR; i < UBT_IF_0_N_TRANSFER; i ++) - usb2_transfer_stop(sc->sc_xfer[i]); - - mtx_unlock(&sc->sc_if_mtx[0]); - - /* - * Interface #1 - */ - - mtx_lock(&sc->sc_if_mtx[1]); - - for (i = UBT_IF_1_ISOC_DT_RD1; i < UBT_N_TRANSFER; i ++) - usb2_transfer_stop(sc->sc_xfer[i]); - - mtx_unlock(&sc->sc_if_mtx[1]); - } - - /* Start all incoming USB transfers */ - if (task_flags & UBT_FLAG_T_START_ALL) { - /* - * Interface #0 - */ - - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_INTR_DT_RD); - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_RD); - mtx_unlock(&sc->sc_if_mtx[0]); - - /* - * Interface #1 - * Start both read and write isoc. transfers by default. - * Get them going all the time even if we have nothing - * to send to avoid any delays. - */ - - mtx_lock(&sc->sc_if_mtx[1]); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD1); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD2); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR1); - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR2); - mtx_unlock(&sc->sc_if_mtx[1]); - } - - /* Start outgoing control transfer */ - if (task_flags & UBT_FLAG_T_START_CTRL) { - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_CTRL_DT_WR); - mtx_unlock(&sc->sc_if_mtx[0]); - } - - /* Start outgoing bulk transfer */ - if (task_flags & UBT_FLAG_T_START_BULK) { - mtx_lock(&sc->sc_if_mtx[0]); - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_WR); - mtx_unlock(&sc->sc_if_mtx[0]); - } - - NG_NODE_UNREF(node); -} /* ubt_task */ - -/* - * Start USB transfer. - * Helper function called from ubt_task. Must be called with appropriate - * interface lock held. - * Taskqueue context. - */ - -static void -ubt_xfer_start(ubt_softc_p sc, int transfer) -{ - if (!usb2_transfer_pending(sc->sc_xfer[transfer])) { - NG_NODE_REF(sc->sc_node); - usb2_transfer_start(sc->sc_xfer[transfer]); - } -} /* ubt_xfer_start */ - -/**************************************************************************** - **************************************************************************** ** Netgraph specific **************************************************************************** ****************************************************************************/ @@ -1546,13 +1266,18 @@ static int ng_ubt_shutdown(node_p node) { + struct ubt_softc *sc = NG_NODE_PRIVATE(node); + if (node->nd_flags & NGF_REALLY_DIE) { /* * We came here because the USB device is being * detached, so stop being persistant. */ + UBT_LOCK(sc); + sc->sc_flags |= UBT_FLAG_SHUTDOWN; + UBT_UNLOCK(sc); + NG_NODE_SET_PRIVATE(node, NULL); - NG_NODE_UNREF(node); } else NG_NODE_REVIVE(node); /* tell ng_rmnode we are persisant */ @@ -1592,9 +1317,21 @@ NG_HOOK_FORCE_QUEUE(NG_HOOK_PEER(hook)); - UBT_MBUFQ_LOCK(sc); - ubt_task_schedule(sc, UBT_FLAG_T_START_ALL); - UBT_MBUFQ_UNLOCK(sc); + if (!(sc->sc_flags & UBT_FLAG_READY)) { + /* called too early */ + return (EINVAL); + } + + NG_NODE_REF(sc->sc_node); + + UBT_LOCK(sc); + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_DT_RD]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_DT_RD]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD1]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD2]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR1]); + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR2]); + UBT_UNLOCK(sc); return (0); } /* ng_ubt_connect */ @@ -1609,6 +1346,7 @@ { node_p node = NG_HOOK_NODE(hook); struct ubt_softc *sc; + uint8_t i; if (NG_NODE_NOT_VALID(node)) return (0); @@ -1618,19 +1356,25 @@ if (hook != sc->sc_hook) return (EINVAL); + /* + * Synchronously drain all USB transfers: + * Can take some milliseconds! + */ + for (i = 0; i != UBT_N_TRANSFER; i++) + usb2_transfer_drain(sc->sc_xfer[i]); + sc->sc_hook = NULL; - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); /* Drain queues */ NG_BT_MBUFQ_DRAIN(&sc->sc_cmdq); NG_BT_MBUFQ_DRAIN(&sc->sc_aclq); NG_BT_MBUFQ_DRAIN(&sc->sc_scoq); - /* Kick off task to stop all USB xfers */ - ubt_task_schedule(sc, UBT_FLAG_T_STOP_ALL); + UBT_UNLOCK(sc); - UBT_MBUFQ_UNLOCK(sc); + NG_NODE_UNREF(node); return (0); } /* ng_ubt_disconnect */ @@ -1664,7 +1408,6 @@ "Refs: %d\n" \ "Hook: %s\n" \ "Flags: %#x\n" \ - "Task flags: %#x\n" \ "Debug: %d\n" \ "CMD queue: [have:%d,max:%d]\n" \ "ACL queue: [have:%d,max:%d]\n" \ @@ -1672,7 +1415,6 @@ node->nd_refs, (sc->sc_hook != NULL) ? NG_UBT_HOOK:"", sc->sc_flags, - sc->sc_task_flags, sc->sc_debug, sc->sc_cmdq.len, sc->sc_cmdq.maxlen, @@ -1823,7 +1565,8 @@ struct ubt_softc *sc = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); struct mbuf *m; struct ng_bt_mbufq *q; - int action, error = 0; + int error = 0; + uint8_t xfer_action; if (hook != sc->sc_hook) { error = EINVAL; @@ -1853,7 +1596,7 @@ UBT_CTRL_BUFFER_SIZE, m->m_pkthdr.len); q = &sc->sc_cmdq; - action = UBT_FLAG_T_START_CTRL; + xfer_action = UBT_IF_0_CTRL_DT_WR; break; case NG_HCI_ACL_DATA_PKT: @@ -1863,12 +1606,12 @@ UBT_BULK_WRITE_BUFFER_SIZE, m->m_pkthdr.len); q = &sc->sc_aclq; - action = UBT_FLAG_T_START_BULK; + xfer_action = UBT_IF_0_BULK_DT_WR; break; case NG_HCI_SCO_DATA_PKT: q = &sc->sc_scoq; - action = 0; + xfer_action = 255; break; default: @@ -1881,10 +1624,10 @@ /* NOT REACHED */ } - UBT_MBUFQ_LOCK(sc); + UBT_LOCK(sc); if (NG_BT_MBUFQ_FULL(q)) { NG_BT_MBUFQ_DROP(q); - UBT_MBUFQ_UNLOCK(sc); + UBT_UNLOCK(sc); UBT_ERR(sc, "Dropping HCI frame 0x%02x, len=%d. Queue full\n", *mtod(m, uint8_t *), m->m_pkthdr.len); @@ -1894,9 +1637,9 @@ /* Loose HCI packet type, enqueue mbuf and kick off task */ m_adj(m, sizeof(uint8_t)); NG_BT_MBUFQ_ENQUEUE(q, m); - ubt_task_schedule(sc, action); - - UBT_MBUFQ_UNLOCK(sc); + if (xfer_action != 255) + usb2_transfer_start(sc->sc_xfer[xfer_action]); + UBT_UNLOCK(sc); } done: NG_FREE_ITEM(item); @@ -1962,4 +1705,3 @@ MODULE_DEPEND(ng_ubt, ng_hci, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION); MODULE_DEPEND(ng_ubt, usb2_bluetooth, 1, 1, 1); MODULE_DEPEND(ng_ubt, usb2_core, 1, 1, 1); - diff -u ng_ubt2_var.h ng_ubt2_var.h --- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 +++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 @@ -28,7 +28,7 @@ * SUCH DAMAGE. * * $Id: ng_ubt_var.h,v 1.2 2003/03/22 23:44:36 max Exp $ - * $FreeBSD$ + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2_var.h,v 1.2 2009/01/20 22:17:05 emax Exp $ */ #ifndef _NG_UBT_VAR_H_ @@ -47,8 +47,8 @@ #define UBT_WARN(...) UBT_DEBUG(NG_UBT_WARN_LEVEL, __VA_ARGS__) #define UBT_INFO(...) UBT_DEBUG(NG_UBT_INFO_LEVEL, __VA_ARGS__) -#define UBT_MBUFQ_LOCK(sc) mtx_lock(&(sc)->sc_mbufq_mtx) -#define UBT_MBUFQ_UNLOCK(sc) mtx_unlock(&(sc)->sc_mbufq_mtx) +#define UBT_LOCK(sc) mtx_lock(&(sc)->sc_mtx) +#define UBT_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) /* Bluetooth USB control request type */ #define UBT_HCI_REQUEST 0x20 @@ -65,17 +65,14 @@ UBT_IF_0_BULK_CS_WR, UBT_IF_0_BULK_CS_RD, UBT_IF_0_INTR_CS_RD, - UBT_IF_0_N_TRANSFER, /* number of interface 0's transfers */ /* Interface #1 transfers */ - UBT_IF_1_ISOC_DT_RD1 = UBT_IF_0_N_TRANSFER, + UBT_IF_1_ISOC_DT_RD1, UBT_IF_1_ISOC_DT_RD2, UBT_IF_1_ISOC_DT_WR1, UBT_IF_1_ISOC_DT_WR2, UBT_N_TRANSFER, /* total number of transfers */ - - UBT_IF_1_N_TRANSFER = UBT_N_TRANSFER - UBT_IF_1_ISOC_DT_RD1, }; /* USB device softc structure */ @@ -89,6 +86,8 @@ #define UBT_FLAG_READ_STALL (1 << 0) /* read transfer has stalled */ #define UBT_FLAG_WRITE_STALL (1 << 1) /* write transfer has stalled */ #define UBT_FLAG_INTR_STALL (1 << 2) /* inter transfer has stalled */ +#define UBT_FLAG_READY (1 << 4) /* set when we are ready */ +#define UBT_FLAG_SHUTDOWN (1 << 5) /* set when we are shutdown */ ng_ubt_node_stat_ep sc_stat; /* statistic */ #define UBT_STAT_PCKTS_SENT(sc) (sc)->sc_stat.pckts_sent ++ @@ -100,11 +99,9 @@ #define UBT_STAT_RESET(sc) bzero(&(sc)->sc_stat, sizeof((sc)->sc_stat)) /* USB device specific */ - struct mtx sc_if_mtx[2]; /* interface locks */ + struct mtx sc_mtx; struct usb2_xfer *sc_xfer[UBT_N_TRANSFER]; - struct mtx sc_mbufq_mtx; /* lock for all queues */ - /* HCI commands */ struct ng_bt_mbufq sc_cmdq; /* HCI command queue */ #define UBT_CTRL_BUFFER_SIZE (sizeof(struct usb2_device_request) + \ @@ -123,17 +120,6 @@ /* Netgraph specific */ node_p sc_node; /* pointer back to node */ hook_p sc_hook; /* upstream hook */ - - /* Glue */ - int sc_task_flags; /* task flags */ -#define UBT_FLAG_T_PENDING (1 << 0) /* task pending */ -#define UBT_FLAG_T_STOP_ALL (1 << 1) /* stop all xfers */ -#define UBT_FLAG_T_START_ALL (1 << 2) /* start all read and isoc - write xfers */ -#define UBT_FLAG_T_START_CTRL (1 << 3) /* start control xfer (write) */ -#define UBT_FLAG_T_START_BULK (1 << 4) /* start bulk xfer (write) */ - - struct task sc_task; }; typedef struct ubt_softc ubt_softc_t; typedef struct ubt_softc * ubt_softc_p; --Boundary-00=_ltjeJufHBsVDcXZ-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 21:47:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23E410657AF; Fri, 23 Jan 2009 21:47:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id AF1518FC1A; Fri, 23 Jan 2009 21:47:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5016813rvf.43 for ; Fri, 23 Jan 2009 13:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RhD/Z/HFc2nAFtJKEw8c2FXC4Xa7TqrnCGp9ODpliwU=; b=LVv44nNWOIOircnivbZntv9gvSWuhMoLr+7eHpYMTDR7AcMMswfQy7drMcheWJubhu bqpT8ZAwMJ5cfi3qWDTfMYpIozuEk5uk+3ncK9VVC7rm0cgKZ3tIVDQcXbsE2pPgaUpL x2enxjbwZtUQCc3rlBun/CncpmO8HIqsIKHWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=czIyF28h4WH3p+15MP5m2/ChToCvZ9+YBwjYtBInZ6vbuPHTjjhCpx5Xzn3LZgO6XJ 4+kpppUDVvCnWYl5mz41KWHGu3e8+vEIKCWdPkpz1pBtMOJrmUhJ5OuG61Ew7v/RF0JC /0HMFYj7iTYKTTM6Ha44KHteX6NJsyH41CzC4= MIME-Version: 1.0 Received: by 10.141.177.2 with SMTP id e2mr5330892rvp.53.1232747245350; Fri, 23 Jan 2009 13:47:25 -0800 (PST) In-Reply-To: <20090123213142.GN60948@e.0x20.net> References: <20090123154336.GJ60948@e.0x20.net> <20090123162920.GT41248@hoeg.nl> <20090123213142.GN60948@e.0x20.net> Date: Fri, 23 Jan 2009 13:47:25 -0800 Message-ID: From: Maksim Yevmenkin To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ed Schouten , current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:47:26 -0000 On Fri, Jan 23, 2009 at 1:31 PM, Lars Engels wrote: > On Fri, Jan 23, 2009 at 05:29:20PM +0100, Ed Schouten wrote: >> Hello Lars, >> >> As HPS said, the issue seems to be related to ubt, but there's still >> something else that is interesting to see here: >> >> * Lars Engels wrote: >> > #2 0xc0859512 in panic (fmt=Variable "fmt" is not available. >> > ) at /usr/src/sys/kern/kern_shutdown.c:576 >> > #3 0xc0849fc7 in _mtx_assert (m=0xc0d76e90, what=4, file=0xc0c30b4c "/usr/src/sys/kern/tty_ttydisc.c", line=1127) at /usr/src/sys/kern/kern_mutex.c:639 >> > #4 0xc08aebad in ttydisc_getc (tp=0xc4650c00, buf=0xf12ea920, len=128) at /usr/src/sys/kern/tty_ttydisc.c:1127 >> > #5 0xc0740604 in sctty_outwakeup (tp=0xc4650c00) at /usr/src/sys/dev/syscons/syscons.c:323 >> > #6 0xc0740b6c in scgetc (sc=0xc0f11f20, flags=3) at /usr/src/sys/dev/syscons/syscons.c:3281 >> > #7 0xc0741190 in sc_cngetc (cd=0xc0cc9be0) at /usr/src/sys/dev/syscons/syscons.c:1607 >> > #8 0xc0821a28 in cncheckc () at /usr/src/sys/kern/kern_cons.c:379 >> > #9 0xc0821a66 in cngetc () at /usr/src/sys/kern/kern_cons.c:357 >> > #10 0xc04bfb15 in db_readline (lstart=0xc0d45cc0 "\n", lsize=120) at /usr/src/sys/ddb/db_input.c:326 >> >> Sam Leffler also reported this issue to me privately. I'll see what I >> can do to fix this. > > Thanks a lot. BTW it doesn't panic on every boot but only from time to > time. does the system panics if you remove usb2_bluetooth_ng? in other words, i'm interested to know if usb2_bluetooth_ng is somehow still causing the panic. thanks, max > From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 22:17:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3E31065676; Fri, 23 Jan 2009 22:17:06 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 65F768FC14; Fri, 23 Jan 2009 22:17:04 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 5C04F3A6A4; Fri, 23 Jan 2009 23:17:03 +0100 (CET) Date: Fri, 23 Jan 2009 23:17:03 +0100 From: Lars Engels To: Hans Petter Selasky Message-ID: <20090123221703.GR60948@e.0x20.net> Mail-Followup-To: Lars Engels , Hans Petter Selasky , freebsd-current@freebsd.org, Maksim Yevmenkin , current@freebsd.org References: <20090123212952.GM60948@e.0x20.net> <20090123213323.GO60948@e.0x20.net> <200901232249.25153.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zbynv6TNPa9FrOf6" Content-Disposition: inline In-Reply-To: <200901232249.25153.hselasky@c2i.net> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-current@freebsd.org, current@freebsd.org, Maksim Yevmenkin Subject: Re: [PATCH2] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:17:07 -0000 --Zbynv6TNPa9FrOf6 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 10:49:23PM +0100, Hans Petter Selasky wrote: > On Friday 23 January 2009, Lars Engels wrote: > > I forgot to mention that both bt devices worked without problems with > > the old stack, so there is no hardware issue. :) >=20 > Hi, >=20 > Bluetooth has worked fine with the new USB stack aswell. I have tested th= is=20 > myself. It is just some small problems with the latest changes from Maksi= m=20 > that needs to be ironed out. >=20 > Maybe you can give my patch a try? >=20 > cvsup first >=20 > Then: >=20 > cd /usr/src/sys/dev/usb2/bluetooth; cat bt_patch.diff | patch >=20 > recompile "/usr/src/sys/modules/usb2/bluetooth_ng" module only and test,= =20 > assuming you are loading the module. >=20 > I'm not sure if my patch is 100% correct, Maksim is the bluetooth+Netgrap= h=20 > expert, but at least my bluetooth dongle now works again. >=20 This didn't work too well, the patch did not apply: ng collection src-all/cvs Checkout src/sys/dev/usb2/bluetooth/TODO.TXT Checkout src/sys/dev/usb2/bluetooth/ng_ubt2.c Checkout src/sys/dev/usb2/bluetooth/ng_ubt2_var.h Checkout src/sys/dev/usb2/bluetooth/ubtbcmfw2.c Checkout src/sys/dev/usb2/bluetooth/usb2_bluetooth.c Checkout src/sys/dev/usb2/bluetooth/usb2_bluetooth.h Shutting down connection to server Finished successfully = = Fri, 23. Jan 2009, 23:14:44 = = [maggie:/usr/src/sy= s/dev/usb2/bluetooth] = lars@pts/3 # cat ~/local= -patches/bt_patch.diff | patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -u ng_ubt2.c ng_ubt2.c |--- ng_ubt2.c Wed Jan 21 17:51:04 2009 |+++ ng_ubt2.c Fri Jan 23 20:17:44 2009 -------------------------- Patching file ng_ubt2.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 28. Hunk #2 failed at 37. Hunk #3 failed at 67. Hunk #4 failed at 111. Hunk #5 succeeded at 163 with fuzz 2 (offset 35 lines). Hunk #6 failed at 314. Hunk #7 failed at 323. Hunk #8 failed at 332. Hunk #9 failed at 341. Hunk #10 failed at 350. Hunk #11 failed at 360. Hunk #12 failed at 373. Hunk #13 failed at 388. Hunk #14 failed at 398. Hunk #15 failed at 408. Hunk #16 failed at 418. Hunk #17 failed at 485. Hunk #18 failed at 518. Hunk #19 failed at 555. Hunk #20 failed at 615. Hunk #21 failed at 629. Hunk #22 failed at 647. Hunk #23 failed at 665. Hunk #24 failed at 692. Hunk #25 succeeded at 825 with fuzz 2 (offset 106 lines). Hunk #26 failed at 846. Hunk #27 failed at 942. Hunk #28 succeeded at 834 with fuzz 2 (offset -21 lines). Hunk #29 failed at 846. Hunk #30 failed at 866. Hunk #31 failed at 962. Hunk #32 succeeded at 980 with fuzz 2 (offset -22 lines). Hunk #33 failed at 992. Hunk #34 failed at 1009. Hunk #35 failed at 1067. Hunk #36 succeeded at 1115 with fuzz 2 (offset 7 lines). Hunk #37 failed at 1127. Hunk #38 succeeded at 1121 with fuzz 2 (offset -16 lines). Hunk #39 failed at 1155. Hunk #40 failed at 1261. Hunk #41 failed at 1289. Hunk #42 failed at 1312. Hunk #43 failed at 1339. Hunk #44 failed at 1530. Hunk #45 failed at 1576. Hunk #46 failed at 1593. Hunk #47 failed at 1602. Hunk #48 failed at 1648. Hunk #49 failed at 1656. Hunk #50 failed at 1807. Hunk #51 failed at 1837. Hunk #52 failed at 1847. Hunk #53 failed at 1865. Hunk #54 failed at 1878. Hunk #55 succeeded at 2235 (offset 273 lines). 47 out of 55 hunks failed--saving rejects to ng_ubt2.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -u ng_ubt2_var.h ng_ubt2_var.h |--- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 |+++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 -------------------------- Patching file ng_ubt2_var.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 28. Hunk #2 failed at 47. Hunk #3 failed at 65. Hunk #4 failed at 89. Hunk #5 failed at 100. Hunk #6 failed at 123. 5 out of 6 hunks failed--saving rejects to ng_ubt2_var.h.rej done Exit 52 > diff -u ng_ubt2.c ng_ubt2.c > --- ng_ubt2.c Wed Jan 21 17:51:04 2009 > +++ ng_ubt2.c Fri Jan 23 20:17:44 2009 > @@ -28,7 +28,7 @@ > * SUCH DAMAGE. > * > * $Id: ng_ubt.c,v 1.16 2003/10/10 19:15:06 max Exp $ > - * $FreeBSD$ > + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2.c,v 1.6 2009/01/20 23:25= :27 emax Exp $ > */ > =20 > /* > @@ -37,22 +37,12 @@ > * driver will *NOT* create traditional /dev/ enties, only Netgraph=20 > * node. > * > - * NOTE ON LOCKS USED: ng_ubt2 drives uses 3 locks (mutexes) > + * NOTE ON LOCKS USED: ng_ubt2 drives uses 1 lock > * > - * 1) sc_if_mtx[0] - lock for device's interface #0. This lock is used > - * by USB2 for any USB request going over device's interface #0, i.e. > - * interrupt, control and bulk transfers. > - *=20 > - * 2) sc_if_mtx[1] - lock for device's interface #1. This lock is used > - * by USB2 for any USB request going over device's interface #1, i.e > - * isoc. transfers. > - *=20 > - * 3) sc_mbufq_mtx - lock for mbufq and task flags. This lock is used > - * to protect device's outgoing mbuf queues and task flags. This lock > - * *SHOULD NOT* be grabbed for a long time. In fact, think of it as a= =20 > - * spin lock. > + * The "sc_mtx" lock protects both USB and Netgraph data. The "sc_mtx" > + * lock should not be grabbed for a long time. > * > - * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 3 different cont= exts. > + * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 2 different cont= exts. > * > * 1) USB context. This is where all the USB related stuff happens. All > * callbacks run in this context. All callbacks are called (by USB2) = with > @@ -67,26 +57,6 @@ > * grab any long-sleep lock in the Netgraph context. In fact, the only > * lock that is allowed in the Netgraph context is the sc_mbufq_mtx l= ock. > * > - * 3) Taskqueue context. This is where ubt_task runs. Since we are NOT a= llowed > - * to grab any locks in the Netgraph context, and, USB2 requires us to > - * grab interface lock before doing things with transfers, we need to > - * transition from the Netgraph context to the Taskqueue context befo= re > - * we can call into USB2 subsystem. > - * > - * So, to put everything together, the rules are as follows. > - * It is OK to call from the USB context or the Taskqueue context into > - * the Netgraph context (i.e. call NG_SEND_xxx functions). In other words > - * it is allowed to call into the Netgraph context with locks held. > - * Is it *NOT* OK to call from the Netgraph context into the USB context, > - * because USB2 requires us to grab interface locks and we can not do th= at. > - * To avoid this, we set task flags to indicate which actions we want to > - * perform and schedule ubt_task which would run in the Taskqueue contex= t. > - * Is is OK to call from the Taskqueue context into the USB context, > - * and, ubt_task does just that (i.e. grabs appropriate interface locks > - * before calling into USB2). > - * Access to the outgoing queues and task flags is controlled by the > - * sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx sho= uld > - * really be a spin lock. > * All USB callbacks accept Netgraph node pointer as private data. To > * ensure that Netgraph node pointer remains valid for the duration of t= he > * transfer, we grab a referrence to the node. In other words, if transf= er is > @@ -111,7 +81,6 @@ > #include > =20 > #include > -#include > =20 > #include > #include > @@ -128,10 +97,6 @@ > static device_attach_t ubt_attach; > static device_detach_t ubt_detach; > =20 > -static int ubt_task_schedule(ubt_softc_p, int); > -static task_fn_t ubt_task; > -static void ubt_xfer_start(ubt_softc_p, int); > - > /* Netgraph methods */ > static ng_constructor_t ng_ubt_constructor; > static ng_shutdown_t ng_ubt_shutdown; > @@ -279,6 +244,7 @@ > .type =3D UE_BULK, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 0, > .mh.bufsize =3D UBT_BULK_WRITE_BUFFER_SIZE, > .mh.flags =3D { .pipe_bof =3D 1, }, > .mh.callback =3D &ubt_bulk_write_callback, > @@ -288,6 +254,7 @@ > .type =3D UE_BULK, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 0, > .mh.bufsize =3D UBT_BULK_READ_BUFFER_SIZE, > .mh.flags =3D { .pipe_bof =3D 1, .short_xfer_ok =3D 1, }, > .mh.callback =3D &ubt_bulk_read_callback, > @@ -297,6 +264,7 @@ > .type =3D UE_INTERRUPT, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 0, > .mh.flags =3D { .pipe_bof =3D 1, .short_xfer_ok =3D 1, }, > .mh.bufsize =3D UBT_INTR_BUFFER_SIZE, > .mh.callback =3D &ubt_intr_read_callback, > @@ -306,6 +274,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D UBT_CTRL_BUFFER_SIZE, > .mh.callback =3D &ubt_ctrl_write_callback, > .mh.timeout =3D 5000, /* 5 seconds */ > @@ -315,6 +284,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_bulk_write_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -325,6 +295,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_bulk_read_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -338,6 +309,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_intr_read_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -353,6 +325,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -363,6 +336,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -373,6 +347,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -383,6 +358,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -450,7 +426,8 @@ > struct ubt_softc *sc =3D device_get_softc(dev); > struct usb2_endpoint_descriptor *ed; > uint16_t wMaxPacketSize; > - uint8_t alt_index, iface_index, i, j; > + uint8_t alt_index, i, j; > + uint8_t iface_index[2]; > =20 > device_set_usb2_desc(dev); > =20 > @@ -483,28 +460,22 @@ > =20 > /* state */ > sc->sc_debug =3D NG_UBT_WARN_LEVEL; > - sc->sc_flags =3D 0; > + > UBT_STAT_RESET(sc); > =20 > /* initialize locks */ > - mtx_init(&sc->sc_mbufq_mtx, "ubt mbufq", NULL, MTX_DEF); > - mtx_init(&sc->sc_if_mtx[0], "ubt if0", NULL, MTX_DEF | MTX_RECURSE); > - mtx_init(&sc->sc_if_mtx[1], "ubt if1", NULL, MTX_DEF | MTX_RECURSE); > + mtx_init(&sc->sc_mtx, "UBT", NULL, MTX_DEF | MTX_RECURSE); > =20 > /* initialize packet queues */ > NG_BT_MBUFQ_INIT(&sc->sc_cmdq, UBT_DEFAULT_QLEN); > NG_BT_MBUFQ_INIT(&sc->sc_aclq, UBT_DEFAULT_QLEN); > NG_BT_MBUFQ_INIT(&sc->sc_scoq, UBT_DEFAULT_QLEN); > =20 > - /* initialize glue task */ > - sc->sc_task_flags =3D 0; > - TASK_INIT(&sc->sc_task, 0, ubt_task, sc->sc_node); > - > /* > * Configure Bluetooth USB device. Discover all required USB > * interfaces and endpoints. > * > - * Device is expected to be a high-speed device. > + * Device is expected to be a full-speed device. > * > * USB device must present two interfaces: > * 1) Interface 0 that has 3 endpoints > @@ -520,20 +491,11 @@ > * configurations with different packet size. > */ > =20 > - bzero(&sc->sc_xfer, sizeof(sc->sc_xfer)); > - > /* > * Interface 0 > */ > =20 > - iface_index =3D 0; > - if (usb2_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, > - ubt_config, UBT_IF_0_N_TRANSFER, > - sc->sc_node, &sc->sc_if_mtx[0])) { > - device_printf(dev, "could not allocate transfers for " \ > - "interface 0!\n"); > - goto detach; > - } > + iface_index[0] =3D 0; > =20 > /* > * Interface 1 > @@ -580,13 +542,11 @@ > goto detach; > } > =20 > - iface_index =3D 1; > - if (usb2_transfer_setup(uaa->device, &iface_index, > - &sc->sc_xfer[UBT_IF_0_N_TRANSFER], > - &ubt_config[UBT_IF_0_N_TRANSFER], UBT_IF_1_N_TRANSFER, > - sc->sc_node, &sc->sc_if_mtx[1])) { > - device_printf(dev, "could not allocate transfers for " \ > - "interface 1!\n"); > + iface_index[1] =3D 1; > + if (usb2_transfer_setup(uaa->device, iface_index, > + sc->sc_xfer, ubt_config, UBT_N_TRANSFER, > + sc->sc_node, &sc->sc_mtx)) { > + device_printf(dev, "could not allocate transfers\n"); > goto detach; > } > =20 > @@ -594,6 +554,10 @@ > for (i =3D 1; usb2_get_iface(uaa->device, i) !=3D NULL; i ++) > usb2_set_parent_iface(uaa->device, i, uaa->info.bIfaceIndex); > =20 > + UBT_LOCK(sc); > + sc->sc_flags |=3D UBT_FLAG_READY; > + UBT_UNLOCK(sc); > + > return (0); /* success */ > =20 > detach: > @@ -612,17 +576,33 @@ > { > struct ubt_softc *sc =3D device_get_softc(dev); > node_p node =3D sc->sc_node; > + uint8_t i; > + > + UBT_LOCK(sc); > + sc->sc_flags &=3D ~UBT_FLAG_READY; > + UBT_UNLOCK(sc); > + > + /* make sure that all USB transfers are stopped! */ > + for (i =3D 0; i !=3D UBT_N_TRANSFER; i++) > + usb2_transfer_drain(sc->sc_xfer[i]); > =20 > /* Destroy Netgraph node */ > if (node !=3D NULL) { > sc->sc_node =3D NULL; > =20 > - NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > - NG_NODE_REF(node); > ng_rmnode_self(node); > - } > =20 > + /* Need to wait until Netgraph has shutdown the node! */ > + UBT_LOCK(sc); > + while (!(sc->sc_flags & UBT_FLAG_SHUTDOWN)) > + usb2_pause_mtx(&sc->sc_mtx, 100); > + UBT_UNLOCK(sc); > + > + /* Check if there is a leftover hook */ > + if (sc->sc_hook !=3D NULL) > + NG_NODE_UNREF(node); > + } > /* Free USB transfers, if any */ > usb2_transfer_unsetup(sc->sc_xfer, UBT_N_TRANSFER); > =20 > @@ -630,15 +610,13 @@ > NG_NODE_UNREF(node); > =20 > /* Destroy queues */ > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > NG_BT_MBUFQ_DESTROY(&sc->sc_cmdq); > NG_BT_MBUFQ_DESTROY(&sc->sc_aclq); > NG_BT_MBUFQ_DESTROY(&sc->sc_scoq); > - UBT_MBUFQ_UNLOCK(sc); > + UBT_UNLOCK(sc); > =20 > - mtx_destroy(&sc->sc_if_mtx[0]); > - mtx_destroy(&sc->sc_if_mtx[1]); > - mtx_destroy(&sc->sc_mbufq_mtx); > + mtx_destroy(&sc->sc_mtx); > =20 > return (0); > } /* ubt_detach */ > @@ -657,37 +635,25 @@ > struct usb2_device_request req; > struct mbuf *m; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error !=3D 0) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to control pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to control pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > send_next: > /* Get next command mbuf, if any */ > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_cmdq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) { > UBT_INFO(sc, "HCI command queue is empty\n"); > - NG_NODE_UNREF(node); > - return; > + break; > } > =20 > /* Initialize a USB control request and then schedule it */ > @@ -719,8 +685,6 @@ > UBT_STAT_OERROR(sc); > goto send_next; > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } /* ubt_ctrl_write_callback */ > @@ -740,19 +704,8 @@ > ng_hci_event_pkt_t *hdr; > int error; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > m =3D NULL; > =20 > switch (USB_GET_STATE(xfer)) { > @@ -836,8 +789,7 @@ > /* Try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_INTR_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_CS_RD]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_intr_read_callback */ > @@ -855,11 +807,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_INTR_DT_RD]; > =20 > @@ -867,8 +814,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_INTR_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_intr_read_clear_stall_callback */ > =20 > /* > @@ -887,19 +833,7 @@ > uint16_t len; > int error; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > - > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > m =3D NULL; > =20 > switch (USB_GET_STATE(xfer)) { > @@ -983,8 +917,7 @@ > /* Try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_READ_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_RD]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_bulk_read_callback */ > @@ -1002,11 +935,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_BULK_DT_RD]; > =20 > @@ -1014,8 +942,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_READ_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_bulk_read_clear_stall_callback */ > =20 > /* > @@ -1031,36 +958,24 @@ > struct ubt_softc *sc; > struct mbuf *m; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error !=3D 0) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > /* Get next mbuf, if any */ > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_aclq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) { > UBT_INFO(sc, "ACL data queue is empty\n"); > - NG_NODE_UNREF(node); > - return; /* transfer completed */ > + break; > } > =20 > /* > @@ -1089,8 +1004,7 @@ > /* try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_WRITE_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_WR]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_bulk_write_callback */ > @@ -1108,11 +1022,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_BULK_DT_WR]; > =20 > @@ -1120,8 +1029,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_WRITE_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_bulk_write_clear_stall_callback */ > =20 > /* > @@ -1137,19 +1045,8 @@ > struct ubt_softc *sc; > int n; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > for (n =3D 0; n < xfer->nframes; n ++) > @@ -1171,8 +1068,6 @@ > goto read_next; > /* NOT REACHED */ > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } /* ubt_isoc_read_callback */ > @@ -1277,24 +1172,16 @@ > struct mbuf *m; > int n, space, offset; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > @@ -1305,10 +1192,7 @@ > =20 > while (space > 0) { > if (m =3D=3D NULL) { > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_scoq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) > break; > } > @@ -1328,9 +1212,7 @@ > =20 > /* Put whatever is left from mbuf back on queue */ > if (m !=3D NULL) { > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_PREPEND(&sc->sc_scoq, m); > - UBT_MBUFQ_UNLOCK(sc); > } > =20 > /* > @@ -1355,174 +1237,12 @@ > goto send_next; > /* NOT REACHED */ > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } > =20 > /***********************************************************************= ***** > ***********************************************************************= ***** > - ** Glue=20 > - ***********************************************************************= ***** > - ***********************************************************************= *****/ > - > -/* > - * Schedule glue task. Should be called with sc_mbufq_mtx held. > - * Netgraph context. > - */ > - > -static int > -ubt_task_schedule(ubt_softc_p sc, int action) > -{ > - mtx_assert(&sc->sc_mbufq_mtx, MA_OWNED); > - > - if ((sc->sc_task_flags & action) =3D=3D 0) { > - /* > - * Try to handle corner case when "start all" and "stop all" > - * actions can both be set before task is executed. > - * > - * Assume the following: > - * 1) "stop all" after "start all" cancels "start all", and, > - * keeps "stop all" > - * > - * 2) "start all" after "stop all" is fine because task is > - * executing "stop all" first > - */ > - > - if (action =3D=3D UBT_FLAG_T_STOP_ALL && > - (sc->sc_task_flags & UBT_FLAG_T_START_ALL) !=3D 0) > - sc->sc_task_flags &=3D ~UBT_FLAG_T_START_ALL; > - > - sc->sc_task_flags |=3D action; > - } > - > - if (sc->sc_task_flags & UBT_FLAG_T_PENDING) > - return (1); > - > - if (taskqueue_enqueue(taskqueue_swi, &sc->sc_task) =3D=3D 0) { > - NG_NODE_REF(sc->sc_node); > - sc->sc_task_flags |=3D UBT_FLAG_T_PENDING; > - return (1); > - } > - > - /* XXX: i think this should never happen */ > - > - return (0); > -} /* ubt_task_schedule */ > - > -/* > - * Glue task. Examines sc_task_flags and does things depending on it. > - * Taskqueue context. > - */ > - > -static void > -ubt_task(void *context, int pending) > -{ > - node_p node =3D context; > - ubt_softc_p sc; > - int task_flags; > - > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > - sc =3D NG_NODE_PRIVATE(node); > - > - UBT_MBUFQ_LOCK(sc); > - task_flags =3D sc->sc_task_flags; > - sc->sc_task_flags =3D 0; > - UBT_MBUFQ_UNLOCK(sc); > - > - /* Stop all USB transfers */ > - if (task_flags & UBT_FLAG_T_STOP_ALL) { > - int i; > - > - /* > - * Interface #0 > - */ > - > - mtx_lock(&sc->sc_if_mtx[0]); > - > - for (i =3D UBT_IF_0_BULK_DT_WR; i < UBT_IF_0_N_TRANSFER; i ++) > - usb2_transfer_stop(sc->sc_xfer[i]); > - > - mtx_unlock(&sc->sc_if_mtx[0]); > - > - /* > - * Interface #1 > - */ > - > - mtx_lock(&sc->sc_if_mtx[1]); > - > - for (i =3D UBT_IF_1_ISOC_DT_RD1; i < UBT_N_TRANSFER; i ++)=20 > - usb2_transfer_stop(sc->sc_xfer[i]); > - > - mtx_unlock(&sc->sc_if_mtx[1]); > - } > - > - /* Start all incoming USB transfers */ > - if (task_flags & UBT_FLAG_T_START_ALL) { > - /* > - * Interface #0 > - */ > - > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_INTR_DT_RD); > - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_RD); > - mtx_unlock(&sc->sc_if_mtx[0]); > - > - /* > - * Interface #1 > - * Start both read and write isoc. transfers by default. > - * Get them going all the time even if we have nothing > - * to send to avoid any delays. > - */ > - > - mtx_lock(&sc->sc_if_mtx[1]); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD1); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD2); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR1); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR2); > - mtx_unlock(&sc->sc_if_mtx[1]); > - } > - > - /* Start outgoing control transfer */ > - if (task_flags & UBT_FLAG_T_START_CTRL) { > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_CTRL_DT_WR); > - mtx_unlock(&sc->sc_if_mtx[0]); > - } > - > - /* Start outgoing bulk transfer */ > - if (task_flags & UBT_FLAG_T_START_BULK) { > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_WR); > - mtx_unlock(&sc->sc_if_mtx[0]); > - } > - > - NG_NODE_UNREF(node); > -} /* ubt_task */ > - > -/* > - * Start USB transfer. > - * Helper function called from ubt_task. Must be called with appropriate > - * interface lock held. > - * Taskqueue context. > - */ > - > -static void > -ubt_xfer_start(ubt_softc_p sc, int transfer) > -{ > - if (!usb2_transfer_pending(sc->sc_xfer[transfer])) { > - NG_NODE_REF(sc->sc_node); > - usb2_transfer_start(sc->sc_xfer[transfer]); > - } > -} /* ubt_xfer_start */ > - > -/***********************************************************************= ***** > - ***********************************************************************= ***** > ** Netgraph specific > ***********************************************************************= ***** > ***********************************************************************= *****/ > @@ -1546,13 +1266,18 @@ > static int > ng_ubt_shutdown(node_p node) > { > + struct ubt_softc *sc =3D NG_NODE_PRIVATE(node); > + > if (node->nd_flags & NGF_REALLY_DIE) { > /* > * We came here because the USB device is being > * detached, so stop being persistant. > */ > + UBT_LOCK(sc); > + sc->sc_flags |=3D UBT_FLAG_SHUTDOWN; > + UBT_UNLOCK(sc); > + > NG_NODE_SET_PRIVATE(node, NULL); > - NG_NODE_UNREF(node); > } else > NG_NODE_REVIVE(node); /* tell ng_rmnode we are persisant */ > =20 > @@ -1592,9 +1317,21 @@ > =20 > NG_HOOK_FORCE_QUEUE(NG_HOOK_PEER(hook)); > =20 > - UBT_MBUFQ_LOCK(sc); > - ubt_task_schedule(sc, UBT_FLAG_T_START_ALL); > - UBT_MBUFQ_UNLOCK(sc); > + if (!(sc->sc_flags & UBT_FLAG_READY)) { > + /* called too early */ > + return (EINVAL); > + } > + > + NG_NODE_REF(sc->sc_node); > + > + UBT_LOCK(sc); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_DT_RD]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_DT_RD]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD1]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD2]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR1]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR2]); > + UBT_UNLOCK(sc); > =20 > return (0); > } /* ng_ubt_connect */ > @@ -1609,6 +1346,7 @@ > { > node_p node =3D NG_HOOK_NODE(hook); > struct ubt_softc *sc; > + uint8_t i; > =20 > if (NG_NODE_NOT_VALID(node)) > return (0); > @@ -1618,19 +1356,25 @@ > if (hook !=3D sc->sc_hook) > return (EINVAL); > =20 > + /*=20 > + * Synchronously drain all USB transfers: > + * Can take some milliseconds! > + */ > + for (i =3D 0; i !=3D UBT_N_TRANSFER; i++) > + usb2_transfer_drain(sc->sc_xfer[i]); > + > sc->sc_hook =3D NULL; > =20 > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > =20 > /* Drain queues */ > NG_BT_MBUFQ_DRAIN(&sc->sc_cmdq); > NG_BT_MBUFQ_DRAIN(&sc->sc_aclq); > NG_BT_MBUFQ_DRAIN(&sc->sc_scoq); > =20 > - /* Kick off task to stop all USB xfers */ > - ubt_task_schedule(sc, UBT_FLAG_T_STOP_ALL); > + UBT_UNLOCK(sc); > =20 > - UBT_MBUFQ_UNLOCK(sc); > + NG_NODE_UNREF(node); > =20 > return (0); > } /* ng_ubt_disconnect */ > @@ -1664,7 +1408,6 @@ > "Refs: %d\n" \ > "Hook: %s\n" \ > "Flags: %#x\n" \ > - "Task flags: %#x\n" \ > "Debug: %d\n" \ > "CMD queue: [have:%d,max:%d]\n" \ > "ACL queue: [have:%d,max:%d]\n" \ > @@ -1672,7 +1415,6 @@ > node->nd_refs, > (sc->sc_hook !=3D NULL) ? NG_UBT_HOOK:"", > sc->sc_flags, > - sc->sc_task_flags, > sc->sc_debug, > sc->sc_cmdq.len, > sc->sc_cmdq.maxlen, > @@ -1823,7 +1565,8 @@ > struct ubt_softc *sc =3D NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); > struct mbuf *m; > struct ng_bt_mbufq *q; > - int action, error =3D 0; > + int error =3D 0; > + uint8_t xfer_action; > =20 > if (hook !=3D sc->sc_hook) { > error =3D EINVAL; > @@ -1853,7 +1596,7 @@ > UBT_CTRL_BUFFER_SIZE, m->m_pkthdr.len); > =20 > q =3D &sc->sc_cmdq; > - action =3D UBT_FLAG_T_START_CTRL; > + xfer_action =3D UBT_IF_0_CTRL_DT_WR; > break; > =20 > case NG_HCI_ACL_DATA_PKT: > @@ -1863,12 +1606,12 @@ > UBT_BULK_WRITE_BUFFER_SIZE, m->m_pkthdr.len); > =20 > q =3D &sc->sc_aclq; > - action =3D UBT_FLAG_T_START_BULK; > + xfer_action =3D UBT_IF_0_BULK_DT_WR; > break; > =20 > case NG_HCI_SCO_DATA_PKT: > q =3D &sc->sc_scoq; > - action =3D 0; > + xfer_action =3D 255; > break; > =20 > default: > @@ -1881,10 +1624,10 @@ > /* NOT REACHED */ > } > =20 > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > if (NG_BT_MBUFQ_FULL(q)) { > NG_BT_MBUFQ_DROP(q); > - UBT_MBUFQ_UNLOCK(sc); > + UBT_UNLOCK(sc); > =09 > UBT_ERR(sc, "Dropping HCI frame 0x%02x, len=3D%d. Queue full\n", > *mtod(m, uint8_t *), m->m_pkthdr.len); > @@ -1894,9 +1637,9 @@ > /* Loose HCI packet type, enqueue mbuf and kick off task */ > m_adj(m, sizeof(uint8_t)); > NG_BT_MBUFQ_ENQUEUE(q, m); > - ubt_task_schedule(sc, action); > - > - UBT_MBUFQ_UNLOCK(sc); > + if (xfer_action !=3D 255) > + usb2_transfer_start(sc->sc_xfer[xfer_action]); > + UBT_UNLOCK(sc); > } > done: > NG_FREE_ITEM(item); > @@ -1962,4 +1705,3 @@ > MODULE_DEPEND(ng_ubt, ng_hci, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION= , NG_BLUETOOTH_VERSION); > MODULE_DEPEND(ng_ubt, usb2_bluetooth, 1, 1, 1); > MODULE_DEPEND(ng_ubt, usb2_core, 1, 1, 1); > - > diff -u ng_ubt2_var.h ng_ubt2_var.h > --- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 > +++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 > @@ -28,7 +28,7 @@ > * SUCH DAMAGE. > * > * $Id: ng_ubt_var.h,v 1.2 2003/03/22 23:44:36 max Exp $ > - * $FreeBSD$ > + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2_var.h,v 1.2 2009/01/20 2= 2:17:05 emax Exp $ > */ > =20 > #ifndef _NG_UBT_VAR_H_ > @@ -47,8 +47,8 @@ > #define UBT_WARN(...) UBT_DEBUG(NG_UBT_WARN_LEVEL, __VA_ARGS__) > #define UBT_INFO(...) UBT_DEBUG(NG_UBT_INFO_LEVEL, __VA_ARGS__) > =20 > -#define UBT_MBUFQ_LOCK(sc) mtx_lock(&(sc)->sc_mbufq_mtx) > -#define UBT_MBUFQ_UNLOCK(sc) mtx_unlock(&(sc)->sc_mbufq_mtx) > +#define UBT_LOCK(sc) mtx_lock(&(sc)->sc_mtx) > +#define UBT_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) > =20 > /* Bluetooth USB control request type */ > #define UBT_HCI_REQUEST 0x20 > @@ -65,17 +65,14 @@ > UBT_IF_0_BULK_CS_WR, > UBT_IF_0_BULK_CS_RD, > UBT_IF_0_INTR_CS_RD, > - UBT_IF_0_N_TRANSFER, /* number of interface 0's transfers */ > =09 > /* Interface #1 transfers */ > - UBT_IF_1_ISOC_DT_RD1 =3D UBT_IF_0_N_TRANSFER, > + UBT_IF_1_ISOC_DT_RD1, > UBT_IF_1_ISOC_DT_RD2, > UBT_IF_1_ISOC_DT_WR1, > UBT_IF_1_ISOC_DT_WR2, > =20 > UBT_N_TRANSFER, /* total number of transfers */ > - > - UBT_IF_1_N_TRANSFER =3D UBT_N_TRANSFER - UBT_IF_1_ISOC_DT_RD1, > }; > =20 > /* USB device softc structure */ > @@ -89,6 +86,8 @@ > #define UBT_FLAG_READ_STALL (1 << 0) /* read transfer has stalled */ > #define UBT_FLAG_WRITE_STALL (1 << 1) /* write transfer has stalled */ > #define UBT_FLAG_INTR_STALL (1 << 2) /* inter transfer has stalled */ > +#define UBT_FLAG_READY (1 << 4) /* set when we are ready */ > +#define UBT_FLAG_SHUTDOWN (1 << 5) /* set when we are shutdown */ > =20 > ng_ubt_node_stat_ep sc_stat; /* statistic */ > #define UBT_STAT_PCKTS_SENT(sc) (sc)->sc_stat.pckts_sent ++ > @@ -100,11 +99,9 @@ > #define UBT_STAT_RESET(sc) bzero(&(sc)->sc_stat, sizeof((sc)->sc_stat)) > =20 > /* USB device specific */ > - struct mtx sc_if_mtx[2]; /* interface locks */ > + struct mtx sc_mtx; > struct usb2_xfer *sc_xfer[UBT_N_TRANSFER]; > =20 > - struct mtx sc_mbufq_mtx; /* lock for all queues */ > - > /* HCI commands */ > struct ng_bt_mbufq sc_cmdq; /* HCI command queue */ > #define UBT_CTRL_BUFFER_SIZE (sizeof(struct usb2_device_request) + \ > @@ -123,17 +120,6 @@ > /* Netgraph specific */ > node_p sc_node; /* pointer back to node */ > hook_p sc_hook; /* upstream hook */ > - > - /* Glue */ > - int sc_task_flags; /* task flags */ > -#define UBT_FLAG_T_PENDING (1 << 0) /* task pending */ > -#define UBT_FLAG_T_STOP_ALL (1 << 1) /* stop all xfers */ > -#define UBT_FLAG_T_START_ALL (1 << 2) /* start all read and isoc > - write xfers */ > -#define UBT_FLAG_T_START_CTRL (1 << 3) /* start control xfer (write) */ > -#define UBT_FLAG_T_START_BULK (1 << 4) /* start bulk xfer (write) */ > - > - struct task sc_task; > }; > typedef struct ubt_softc ubt_softc_t; > typedef struct ubt_softc * ubt_softc_p; --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --Zbynv6TNPa9FrOf6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6Qd8ACgkQKc512sD3afjbZwCgjF1ln3UHqXH4MHL2MG5Hnf6f 030AnjJJDtNP4PcHcFyWo48ypWf+qH5t =xthe -----END PGP SIGNATURE----- --Zbynv6TNPa9FrOf6-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 22:17:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3E31065676; Fri, 23 Jan 2009 22:17:06 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 65F768FC14; Fri, 23 Jan 2009 22:17:04 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 5C04F3A6A4; Fri, 23 Jan 2009 23:17:03 +0100 (CET) Date: Fri, 23 Jan 2009 23:17:03 +0100 From: Lars Engels To: Hans Petter Selasky Message-ID: <20090123221703.GR60948@e.0x20.net> Mail-Followup-To: Lars Engels , Hans Petter Selasky , freebsd-current@freebsd.org, Maksim Yevmenkin , current@freebsd.org References: <20090123212952.GM60948@e.0x20.net> <20090123213323.GO60948@e.0x20.net> <200901232249.25153.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zbynv6TNPa9FrOf6" Content-Disposition: inline In-Reply-To: <200901232249.25153.hselasky@c2i.net> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-current@freebsd.org, current@freebsd.org, Maksim Yevmenkin Subject: Re: [PATCH2] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:17:07 -0000 --Zbynv6TNPa9FrOf6 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 10:49:23PM +0100, Hans Petter Selasky wrote: > On Friday 23 January 2009, Lars Engels wrote: > > I forgot to mention that both bt devices worked without problems with > > the old stack, so there is no hardware issue. :) >=20 > Hi, >=20 > Bluetooth has worked fine with the new USB stack aswell. I have tested th= is=20 > myself. It is just some small problems with the latest changes from Maksi= m=20 > that needs to be ironed out. >=20 > Maybe you can give my patch a try? >=20 > cvsup first >=20 > Then: >=20 > cd /usr/src/sys/dev/usb2/bluetooth; cat bt_patch.diff | patch >=20 > recompile "/usr/src/sys/modules/usb2/bluetooth_ng" module only and test,= =20 > assuming you are loading the module. >=20 > I'm not sure if my patch is 100% correct, Maksim is the bluetooth+Netgrap= h=20 > expert, but at least my bluetooth dongle now works again. >=20 This didn't work too well, the patch did not apply: ng collection src-all/cvs Checkout src/sys/dev/usb2/bluetooth/TODO.TXT Checkout src/sys/dev/usb2/bluetooth/ng_ubt2.c Checkout src/sys/dev/usb2/bluetooth/ng_ubt2_var.h Checkout src/sys/dev/usb2/bluetooth/ubtbcmfw2.c Checkout src/sys/dev/usb2/bluetooth/usb2_bluetooth.c Checkout src/sys/dev/usb2/bluetooth/usb2_bluetooth.h Shutting down connection to server Finished successfully = = Fri, 23. Jan 2009, 23:14:44 = = [maggie:/usr/src/sy= s/dev/usb2/bluetooth] = lars@pts/3 # cat ~/local= -patches/bt_patch.diff | patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -u ng_ubt2.c ng_ubt2.c |--- ng_ubt2.c Wed Jan 21 17:51:04 2009 |+++ ng_ubt2.c Fri Jan 23 20:17:44 2009 -------------------------- Patching file ng_ubt2.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 28. Hunk #2 failed at 37. Hunk #3 failed at 67. Hunk #4 failed at 111. Hunk #5 succeeded at 163 with fuzz 2 (offset 35 lines). Hunk #6 failed at 314. Hunk #7 failed at 323. Hunk #8 failed at 332. Hunk #9 failed at 341. Hunk #10 failed at 350. Hunk #11 failed at 360. Hunk #12 failed at 373. Hunk #13 failed at 388. Hunk #14 failed at 398. Hunk #15 failed at 408. Hunk #16 failed at 418. Hunk #17 failed at 485. Hunk #18 failed at 518. Hunk #19 failed at 555. Hunk #20 failed at 615. Hunk #21 failed at 629. Hunk #22 failed at 647. Hunk #23 failed at 665. Hunk #24 failed at 692. Hunk #25 succeeded at 825 with fuzz 2 (offset 106 lines). Hunk #26 failed at 846. Hunk #27 failed at 942. Hunk #28 succeeded at 834 with fuzz 2 (offset -21 lines). Hunk #29 failed at 846. Hunk #30 failed at 866. Hunk #31 failed at 962. Hunk #32 succeeded at 980 with fuzz 2 (offset -22 lines). Hunk #33 failed at 992. Hunk #34 failed at 1009. Hunk #35 failed at 1067. Hunk #36 succeeded at 1115 with fuzz 2 (offset 7 lines). Hunk #37 failed at 1127. Hunk #38 succeeded at 1121 with fuzz 2 (offset -16 lines). Hunk #39 failed at 1155. Hunk #40 failed at 1261. Hunk #41 failed at 1289. Hunk #42 failed at 1312. Hunk #43 failed at 1339. Hunk #44 failed at 1530. Hunk #45 failed at 1576. Hunk #46 failed at 1593. Hunk #47 failed at 1602. Hunk #48 failed at 1648. Hunk #49 failed at 1656. Hunk #50 failed at 1807. Hunk #51 failed at 1837. Hunk #52 failed at 1847. Hunk #53 failed at 1865. Hunk #54 failed at 1878. Hunk #55 succeeded at 2235 (offset 273 lines). 47 out of 55 hunks failed--saving rejects to ng_ubt2.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -u ng_ubt2_var.h ng_ubt2_var.h |--- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 |+++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 -------------------------- Patching file ng_ubt2_var.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 28. Hunk #2 failed at 47. Hunk #3 failed at 65. Hunk #4 failed at 89. Hunk #5 failed at 100. Hunk #6 failed at 123. 5 out of 6 hunks failed--saving rejects to ng_ubt2_var.h.rej done Exit 52 > diff -u ng_ubt2.c ng_ubt2.c > --- ng_ubt2.c Wed Jan 21 17:51:04 2009 > +++ ng_ubt2.c Fri Jan 23 20:17:44 2009 > @@ -28,7 +28,7 @@ > * SUCH DAMAGE. > * > * $Id: ng_ubt.c,v 1.16 2003/10/10 19:15:06 max Exp $ > - * $FreeBSD$ > + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2.c,v 1.6 2009/01/20 23:25= :27 emax Exp $ > */ > =20 > /* > @@ -37,22 +37,12 @@ > * driver will *NOT* create traditional /dev/ enties, only Netgraph=20 > * node. > * > - * NOTE ON LOCKS USED: ng_ubt2 drives uses 3 locks (mutexes) > + * NOTE ON LOCKS USED: ng_ubt2 drives uses 1 lock > * > - * 1) sc_if_mtx[0] - lock for device's interface #0. This lock is used > - * by USB2 for any USB request going over device's interface #0, i.e. > - * interrupt, control and bulk transfers. > - *=20 > - * 2) sc_if_mtx[1] - lock for device's interface #1. This lock is used > - * by USB2 for any USB request going over device's interface #1, i.e > - * isoc. transfers. > - *=20 > - * 3) sc_mbufq_mtx - lock for mbufq and task flags. This lock is used > - * to protect device's outgoing mbuf queues and task flags. This lock > - * *SHOULD NOT* be grabbed for a long time. In fact, think of it as a= =20 > - * spin lock. > + * The "sc_mtx" lock protects both USB and Netgraph data. The "sc_mtx" > + * lock should not be grabbed for a long time. > * > - * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 3 different cont= exts. > + * NOTE ON LOCKING STRATEGY: ng_ubt2 driver operates in 2 different cont= exts. > * > * 1) USB context. This is where all the USB related stuff happens. All > * callbacks run in this context. All callbacks are called (by USB2) = with > @@ -67,26 +57,6 @@ > * grab any long-sleep lock in the Netgraph context. In fact, the only > * lock that is allowed in the Netgraph context is the sc_mbufq_mtx l= ock. > * > - * 3) Taskqueue context. This is where ubt_task runs. Since we are NOT a= llowed > - * to grab any locks in the Netgraph context, and, USB2 requires us to > - * grab interface lock before doing things with transfers, we need to > - * transition from the Netgraph context to the Taskqueue context befo= re > - * we can call into USB2 subsystem. > - * > - * So, to put everything together, the rules are as follows. > - * It is OK to call from the USB context or the Taskqueue context into > - * the Netgraph context (i.e. call NG_SEND_xxx functions). In other words > - * it is allowed to call into the Netgraph context with locks held. > - * Is it *NOT* OK to call from the Netgraph context into the USB context, > - * because USB2 requires us to grab interface locks and we can not do th= at. > - * To avoid this, we set task flags to indicate which actions we want to > - * perform and schedule ubt_task which would run in the Taskqueue contex= t. > - * Is is OK to call from the Taskqueue context into the USB context, > - * and, ubt_task does just that (i.e. grabs appropriate interface locks > - * before calling into USB2). > - * Access to the outgoing queues and task flags is controlled by the > - * sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx sho= uld > - * really be a spin lock. > * All USB callbacks accept Netgraph node pointer as private data. To > * ensure that Netgraph node pointer remains valid for the duration of t= he > * transfer, we grab a referrence to the node. In other words, if transf= er is > @@ -111,7 +81,6 @@ > #include > =20 > #include > -#include > =20 > #include > #include > @@ -128,10 +97,6 @@ > static device_attach_t ubt_attach; > static device_detach_t ubt_detach; > =20 > -static int ubt_task_schedule(ubt_softc_p, int); > -static task_fn_t ubt_task; > -static void ubt_xfer_start(ubt_softc_p, int); > - > /* Netgraph methods */ > static ng_constructor_t ng_ubt_constructor; > static ng_shutdown_t ng_ubt_shutdown; > @@ -279,6 +244,7 @@ > .type =3D UE_BULK, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 0, > .mh.bufsize =3D UBT_BULK_WRITE_BUFFER_SIZE, > .mh.flags =3D { .pipe_bof =3D 1, }, > .mh.callback =3D &ubt_bulk_write_callback, > @@ -288,6 +254,7 @@ > .type =3D UE_BULK, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 0, > .mh.bufsize =3D UBT_BULK_READ_BUFFER_SIZE, > .mh.flags =3D { .pipe_bof =3D 1, .short_xfer_ok =3D 1, }, > .mh.callback =3D &ubt_bulk_read_callback, > @@ -297,6 +264,7 @@ > .type =3D UE_INTERRUPT, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 0, > .mh.flags =3D { .pipe_bof =3D 1, .short_xfer_ok =3D 1, }, > .mh.bufsize =3D UBT_INTR_BUFFER_SIZE, > .mh.callback =3D &ubt_intr_read_callback, > @@ -306,6 +274,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D UBT_CTRL_BUFFER_SIZE, > .mh.callback =3D &ubt_ctrl_write_callback, > .mh.timeout =3D 5000, /* 5 seconds */ > @@ -315,6 +284,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_bulk_write_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -325,6 +295,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_bulk_read_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -338,6 +309,7 @@ > .type =3D UE_CONTROL, > .endpoint =3D 0x00, /* control pipe */ > .direction =3D UE_DIR_ANY, > + .if_index =3D 0, > .mh.bufsize =3D sizeof(struct usb2_device_request), > .mh.callback =3D &ubt_intr_read_clear_stall_callback, > .mh.timeout =3D 1000, /* 1 second */ > @@ -353,6 +325,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -363,6 +336,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_IN, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -373,6 +347,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -383,6 +358,7 @@ > .type =3D UE_ISOCHRONOUS, > .endpoint =3D UE_ADDR_ANY, > .direction =3D UE_DIR_OUT, > + .if_index =3D 1, > .mh.bufsize =3D 0, /* use "wMaxPacketSize * frames" */ > .mh.frames =3D UBT_ISOC_NFRAMES, > .mh.flags =3D { .short_xfer_ok =3D 1, }, > @@ -450,7 +426,8 @@ > struct ubt_softc *sc =3D device_get_softc(dev); > struct usb2_endpoint_descriptor *ed; > uint16_t wMaxPacketSize; > - uint8_t alt_index, iface_index, i, j; > + uint8_t alt_index, i, j; > + uint8_t iface_index[2]; > =20 > device_set_usb2_desc(dev); > =20 > @@ -483,28 +460,22 @@ > =20 > /* state */ > sc->sc_debug =3D NG_UBT_WARN_LEVEL; > - sc->sc_flags =3D 0; > + > UBT_STAT_RESET(sc); > =20 > /* initialize locks */ > - mtx_init(&sc->sc_mbufq_mtx, "ubt mbufq", NULL, MTX_DEF); > - mtx_init(&sc->sc_if_mtx[0], "ubt if0", NULL, MTX_DEF | MTX_RECURSE); > - mtx_init(&sc->sc_if_mtx[1], "ubt if1", NULL, MTX_DEF | MTX_RECURSE); > + mtx_init(&sc->sc_mtx, "UBT", NULL, MTX_DEF | MTX_RECURSE); > =20 > /* initialize packet queues */ > NG_BT_MBUFQ_INIT(&sc->sc_cmdq, UBT_DEFAULT_QLEN); > NG_BT_MBUFQ_INIT(&sc->sc_aclq, UBT_DEFAULT_QLEN); > NG_BT_MBUFQ_INIT(&sc->sc_scoq, UBT_DEFAULT_QLEN); > =20 > - /* initialize glue task */ > - sc->sc_task_flags =3D 0; > - TASK_INIT(&sc->sc_task, 0, ubt_task, sc->sc_node); > - > /* > * Configure Bluetooth USB device. Discover all required USB > * interfaces and endpoints. > * > - * Device is expected to be a high-speed device. > + * Device is expected to be a full-speed device. > * > * USB device must present two interfaces: > * 1) Interface 0 that has 3 endpoints > @@ -520,20 +491,11 @@ > * configurations with different packet size. > */ > =20 > - bzero(&sc->sc_xfer, sizeof(sc->sc_xfer)); > - > /* > * Interface 0 > */ > =20 > - iface_index =3D 0; > - if (usb2_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, > - ubt_config, UBT_IF_0_N_TRANSFER, > - sc->sc_node, &sc->sc_if_mtx[0])) { > - device_printf(dev, "could not allocate transfers for " \ > - "interface 0!\n"); > - goto detach; > - } > + iface_index[0] =3D 0; > =20 > /* > * Interface 1 > @@ -580,13 +542,11 @@ > goto detach; > } > =20 > - iface_index =3D 1; > - if (usb2_transfer_setup(uaa->device, &iface_index, > - &sc->sc_xfer[UBT_IF_0_N_TRANSFER], > - &ubt_config[UBT_IF_0_N_TRANSFER], UBT_IF_1_N_TRANSFER, > - sc->sc_node, &sc->sc_if_mtx[1])) { > - device_printf(dev, "could not allocate transfers for " \ > - "interface 1!\n"); > + iface_index[1] =3D 1; > + if (usb2_transfer_setup(uaa->device, iface_index, > + sc->sc_xfer, ubt_config, UBT_N_TRANSFER, > + sc->sc_node, &sc->sc_mtx)) { > + device_printf(dev, "could not allocate transfers\n"); > goto detach; > } > =20 > @@ -594,6 +554,10 @@ > for (i =3D 1; usb2_get_iface(uaa->device, i) !=3D NULL; i ++) > usb2_set_parent_iface(uaa->device, i, uaa->info.bIfaceIndex); > =20 > + UBT_LOCK(sc); > + sc->sc_flags |=3D UBT_FLAG_READY; > + UBT_UNLOCK(sc); > + > return (0); /* success */ > =20 > detach: > @@ -612,17 +576,33 @@ > { > struct ubt_softc *sc =3D device_get_softc(dev); > node_p node =3D sc->sc_node; > + uint8_t i; > + > + UBT_LOCK(sc); > + sc->sc_flags &=3D ~UBT_FLAG_READY; > + UBT_UNLOCK(sc); > + > + /* make sure that all USB transfers are stopped! */ > + for (i =3D 0; i !=3D UBT_N_TRANSFER; i++) > + usb2_transfer_drain(sc->sc_xfer[i]); > =20 > /* Destroy Netgraph node */ > if (node !=3D NULL) { > sc->sc_node =3D NULL; > =20 > - NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > - NG_NODE_REF(node); > ng_rmnode_self(node); > - } > =20 > + /* Need to wait until Netgraph has shutdown the node! */ > + UBT_LOCK(sc); > + while (!(sc->sc_flags & UBT_FLAG_SHUTDOWN)) > + usb2_pause_mtx(&sc->sc_mtx, 100); > + UBT_UNLOCK(sc); > + > + /* Check if there is a leftover hook */ > + if (sc->sc_hook !=3D NULL) > + NG_NODE_UNREF(node); > + } > /* Free USB transfers, if any */ > usb2_transfer_unsetup(sc->sc_xfer, UBT_N_TRANSFER); > =20 > @@ -630,15 +610,13 @@ > NG_NODE_UNREF(node); > =20 > /* Destroy queues */ > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > NG_BT_MBUFQ_DESTROY(&sc->sc_cmdq); > NG_BT_MBUFQ_DESTROY(&sc->sc_aclq); > NG_BT_MBUFQ_DESTROY(&sc->sc_scoq); > - UBT_MBUFQ_UNLOCK(sc); > + UBT_UNLOCK(sc); > =20 > - mtx_destroy(&sc->sc_if_mtx[0]); > - mtx_destroy(&sc->sc_if_mtx[1]); > - mtx_destroy(&sc->sc_mbufq_mtx); > + mtx_destroy(&sc->sc_mtx); > =20 > return (0); > } /* ubt_detach */ > @@ -657,37 +635,25 @@ > struct usb2_device_request req; > struct mbuf *m; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error !=3D 0) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to control pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to control pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > send_next: > /* Get next command mbuf, if any */ > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_cmdq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) { > UBT_INFO(sc, "HCI command queue is empty\n"); > - NG_NODE_UNREF(node); > - return; > + break; > } > =20 > /* Initialize a USB control request and then schedule it */ > @@ -719,8 +685,6 @@ > UBT_STAT_OERROR(sc); > goto send_next; > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } /* ubt_ctrl_write_callback */ > @@ -740,19 +704,8 @@ > ng_hci_event_pkt_t *hdr; > int error; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > m =3D NULL; > =20 > switch (USB_GET_STATE(xfer)) { > @@ -836,8 +789,7 @@ > /* Try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_INTR_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_CS_RD]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_intr_read_callback */ > @@ -855,11 +807,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_INTR_DT_RD]; > =20 > @@ -867,8 +814,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_INTR_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_intr_read_clear_stall_callback */ > =20 > /* > @@ -887,19 +833,7 @@ > uint16_t len; > int error; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > - > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > m =3D NULL; > =20 > switch (USB_GET_STATE(xfer)) { > @@ -983,8 +917,7 @@ > /* Try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_READ_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_RD]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_bulk_read_callback */ > @@ -1002,11 +935,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_BULK_DT_RD]; > =20 > @@ -1014,8 +942,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_READ_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_bulk_read_clear_stall_callback */ > =20 > /* > @@ -1031,36 +958,24 @@ > struct ubt_softc *sc; > struct mbuf *m; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error !=3D 0) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to bulk-out pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > /* Get next mbuf, if any */ > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_aclq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) { > UBT_INFO(sc, "ACL data queue is empty\n"); > - NG_NODE_UNREF(node); > - return; /* transfer completed */ > + break; > } > =20 > /* > @@ -1089,8 +1004,7 @@ > /* try to clear stall first */ > sc->sc_flags |=3D UBT_FLAG_WRITE_STALL; > usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_CS_WR]); > - } else > - NG_NODE_UNREF(node); /* cancelled */ > + } > break; > } > } /* ubt_bulk_write_callback */ > @@ -1108,11 +1022,6 @@ > struct ubt_softc *sc; > struct usb2_xfer *xfer_other; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > xfer_other =3D sc->sc_xfer[UBT_IF_0_BULK_DT_WR]; > =20 > @@ -1120,8 +1029,7 @@ > DPRINTF("stall cleared\n"); > sc->sc_flags &=3D ~UBT_FLAG_WRITE_STALL; > usb2_transfer_start(xfer_other); > - } else > - NG_NODE_UNREF(node); /* cant clear stall */ > + } > } /* ubt_bulk_write_clear_stall_callback */ > =20 > /* > @@ -1137,19 +1045,8 @@ > struct ubt_softc *sc; > int n; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > - if ((sc->sc_hook =3D=3D NULL) || NG_HOOK_NOT_VALID(sc->sc_hook)) { > - UBT_INFO(sc, "no upstream hook\n"); > - NG_NODE_UNREF(node); > - return; /* upstream hook is gone */ > - } > - > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > for (n =3D 0; n < xfer->nframes; n ++) > @@ -1171,8 +1068,6 @@ > goto read_next; > /* NOT REACHED */ > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } /* ubt_isoc_read_callback */ > @@ -1277,24 +1172,16 @@ > struct mbuf *m; > int n, space, offset; > =20 > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > sc =3D NG_NODE_PRIVATE(node); > =20 > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > - if (xfer->error) > - UBT_STAT_OERROR(sc); > - else { > - UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", > - xfer->actlen); > + UBT_INFO(sc, "sent %d bytes to isoc-out pipe\n", > + xfer->actlen); > + > + UBT_STAT_BYTES_SENT(sc, xfer->actlen); > + UBT_STAT_PCKTS_SENT(sc); > =20 > - UBT_STAT_BYTES_SENT(sc, xfer->actlen); > - UBT_STAT_PCKTS_SENT(sc); > - } > /* FALLTHROUGH */ > =20 > case USB_ST_SETUP: > @@ -1305,10 +1192,7 @@ > =20 > while (space > 0) { > if (m =3D=3D NULL) { > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_DEQUEUE(&sc->sc_scoq, m); > - UBT_MBUFQ_UNLOCK(sc); > - > if (m =3D=3D NULL) > break; > } > @@ -1328,9 +1212,7 @@ > =20 > /* Put whatever is left from mbuf back on queue */ > if (m !=3D NULL) { > - UBT_MBUFQ_LOCK(sc); > NG_BT_MBUFQ_PREPEND(&sc->sc_scoq, m); > - UBT_MBUFQ_UNLOCK(sc); > } > =20 > /* > @@ -1355,174 +1237,12 @@ > goto send_next; > /* NOT REACHED */ > } > - > - NG_NODE_UNREF(node); /* cancelled */ > break; > } > } > =20 > /***********************************************************************= ***** > ***********************************************************************= ***** > - ** Glue=20 > - ***********************************************************************= ***** > - ***********************************************************************= *****/ > - > -/* > - * Schedule glue task. Should be called with sc_mbufq_mtx held. > - * Netgraph context. > - */ > - > -static int > -ubt_task_schedule(ubt_softc_p sc, int action) > -{ > - mtx_assert(&sc->sc_mbufq_mtx, MA_OWNED); > - > - if ((sc->sc_task_flags & action) =3D=3D 0) { > - /* > - * Try to handle corner case when "start all" and "stop all" > - * actions can both be set before task is executed. > - * > - * Assume the following: > - * 1) "stop all" after "start all" cancels "start all", and, > - * keeps "stop all" > - * > - * 2) "start all" after "stop all" is fine because task is > - * executing "stop all" first > - */ > - > - if (action =3D=3D UBT_FLAG_T_STOP_ALL && > - (sc->sc_task_flags & UBT_FLAG_T_START_ALL) !=3D 0) > - sc->sc_task_flags &=3D ~UBT_FLAG_T_START_ALL; > - > - sc->sc_task_flags |=3D action; > - } > - > - if (sc->sc_task_flags & UBT_FLAG_T_PENDING) > - return (1); > - > - if (taskqueue_enqueue(taskqueue_swi, &sc->sc_task) =3D=3D 0) { > - NG_NODE_REF(sc->sc_node); > - sc->sc_task_flags |=3D UBT_FLAG_T_PENDING; > - return (1); > - } > - > - /* XXX: i think this should never happen */ > - > - return (0); > -} /* ubt_task_schedule */ > - > -/* > - * Glue task. Examines sc_task_flags and does things depending on it. > - * Taskqueue context. > - */ > - > -static void > -ubt_task(void *context, int pending) > -{ > - node_p node =3D context; > - ubt_softc_p sc; > - int task_flags; > - > - if (NG_NODE_NOT_VALID(node)) { > - NG_NODE_UNREF(node); > - return; /* netgraph node is gone */ > - } > - > - sc =3D NG_NODE_PRIVATE(node); > - > - UBT_MBUFQ_LOCK(sc); > - task_flags =3D sc->sc_task_flags; > - sc->sc_task_flags =3D 0; > - UBT_MBUFQ_UNLOCK(sc); > - > - /* Stop all USB transfers */ > - if (task_flags & UBT_FLAG_T_STOP_ALL) { > - int i; > - > - /* > - * Interface #0 > - */ > - > - mtx_lock(&sc->sc_if_mtx[0]); > - > - for (i =3D UBT_IF_0_BULK_DT_WR; i < UBT_IF_0_N_TRANSFER; i ++) > - usb2_transfer_stop(sc->sc_xfer[i]); > - > - mtx_unlock(&sc->sc_if_mtx[0]); > - > - /* > - * Interface #1 > - */ > - > - mtx_lock(&sc->sc_if_mtx[1]); > - > - for (i =3D UBT_IF_1_ISOC_DT_RD1; i < UBT_N_TRANSFER; i ++)=20 > - usb2_transfer_stop(sc->sc_xfer[i]); > - > - mtx_unlock(&sc->sc_if_mtx[1]); > - } > - > - /* Start all incoming USB transfers */ > - if (task_flags & UBT_FLAG_T_START_ALL) { > - /* > - * Interface #0 > - */ > - > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_INTR_DT_RD); > - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_RD); > - mtx_unlock(&sc->sc_if_mtx[0]); > - > - /* > - * Interface #1 > - * Start both read and write isoc. transfers by default. > - * Get them going all the time even if we have nothing > - * to send to avoid any delays. > - */ > - > - mtx_lock(&sc->sc_if_mtx[1]); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD1); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_RD2); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR1); > - ubt_xfer_start(sc, UBT_IF_1_ISOC_DT_WR2); > - mtx_unlock(&sc->sc_if_mtx[1]); > - } > - > - /* Start outgoing control transfer */ > - if (task_flags & UBT_FLAG_T_START_CTRL) { > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_CTRL_DT_WR); > - mtx_unlock(&sc->sc_if_mtx[0]); > - } > - > - /* Start outgoing bulk transfer */ > - if (task_flags & UBT_FLAG_T_START_BULK) { > - mtx_lock(&sc->sc_if_mtx[0]); > - ubt_xfer_start(sc, UBT_IF_0_BULK_DT_WR); > - mtx_unlock(&sc->sc_if_mtx[0]); > - } > - > - NG_NODE_UNREF(node); > -} /* ubt_task */ > - > -/* > - * Start USB transfer. > - * Helper function called from ubt_task. Must be called with appropriate > - * interface lock held. > - * Taskqueue context. > - */ > - > -static void > -ubt_xfer_start(ubt_softc_p sc, int transfer) > -{ > - if (!usb2_transfer_pending(sc->sc_xfer[transfer])) { > - NG_NODE_REF(sc->sc_node); > - usb2_transfer_start(sc->sc_xfer[transfer]); > - } > -} /* ubt_xfer_start */ > - > -/***********************************************************************= ***** > - ***********************************************************************= ***** > ** Netgraph specific > ***********************************************************************= ***** > ***********************************************************************= *****/ > @@ -1546,13 +1266,18 @@ > static int > ng_ubt_shutdown(node_p node) > { > + struct ubt_softc *sc =3D NG_NODE_PRIVATE(node); > + > if (node->nd_flags & NGF_REALLY_DIE) { > /* > * We came here because the USB device is being > * detached, so stop being persistant. > */ > + UBT_LOCK(sc); > + sc->sc_flags |=3D UBT_FLAG_SHUTDOWN; > + UBT_UNLOCK(sc); > + > NG_NODE_SET_PRIVATE(node, NULL); > - NG_NODE_UNREF(node); > } else > NG_NODE_REVIVE(node); /* tell ng_rmnode we are persisant */ > =20 > @@ -1592,9 +1317,21 @@ > =20 > NG_HOOK_FORCE_QUEUE(NG_HOOK_PEER(hook)); > =20 > - UBT_MBUFQ_LOCK(sc); > - ubt_task_schedule(sc, UBT_FLAG_T_START_ALL); > - UBT_MBUFQ_UNLOCK(sc); > + if (!(sc->sc_flags & UBT_FLAG_READY)) { > + /* called too early */ > + return (EINVAL); > + } > + > + NG_NODE_REF(sc->sc_node); > + > + UBT_LOCK(sc); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_INTR_DT_RD]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_0_BULK_DT_RD]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD1]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_RD2]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR1]); > + usb2_transfer_start(sc->sc_xfer[UBT_IF_1_ISOC_DT_WR2]); > + UBT_UNLOCK(sc); > =20 > return (0); > } /* ng_ubt_connect */ > @@ -1609,6 +1346,7 @@ > { > node_p node =3D NG_HOOK_NODE(hook); > struct ubt_softc *sc; > + uint8_t i; > =20 > if (NG_NODE_NOT_VALID(node)) > return (0); > @@ -1618,19 +1356,25 @@ > if (hook !=3D sc->sc_hook) > return (EINVAL); > =20 > + /*=20 > + * Synchronously drain all USB transfers: > + * Can take some milliseconds! > + */ > + for (i =3D 0; i !=3D UBT_N_TRANSFER; i++) > + usb2_transfer_drain(sc->sc_xfer[i]); > + > sc->sc_hook =3D NULL; > =20 > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > =20 > /* Drain queues */ > NG_BT_MBUFQ_DRAIN(&sc->sc_cmdq); > NG_BT_MBUFQ_DRAIN(&sc->sc_aclq); > NG_BT_MBUFQ_DRAIN(&sc->sc_scoq); > =20 > - /* Kick off task to stop all USB xfers */ > - ubt_task_schedule(sc, UBT_FLAG_T_STOP_ALL); > + UBT_UNLOCK(sc); > =20 > - UBT_MBUFQ_UNLOCK(sc); > + NG_NODE_UNREF(node); > =20 > return (0); > } /* ng_ubt_disconnect */ > @@ -1664,7 +1408,6 @@ > "Refs: %d\n" \ > "Hook: %s\n" \ > "Flags: %#x\n" \ > - "Task flags: %#x\n" \ > "Debug: %d\n" \ > "CMD queue: [have:%d,max:%d]\n" \ > "ACL queue: [have:%d,max:%d]\n" \ > @@ -1672,7 +1415,6 @@ > node->nd_refs, > (sc->sc_hook !=3D NULL) ? NG_UBT_HOOK:"", > sc->sc_flags, > - sc->sc_task_flags, > sc->sc_debug, > sc->sc_cmdq.len, > sc->sc_cmdq.maxlen, > @@ -1823,7 +1565,8 @@ > struct ubt_softc *sc =3D NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); > struct mbuf *m; > struct ng_bt_mbufq *q; > - int action, error =3D 0; > + int error =3D 0; > + uint8_t xfer_action; > =20 > if (hook !=3D sc->sc_hook) { > error =3D EINVAL; > @@ -1853,7 +1596,7 @@ > UBT_CTRL_BUFFER_SIZE, m->m_pkthdr.len); > =20 > q =3D &sc->sc_cmdq; > - action =3D UBT_FLAG_T_START_CTRL; > + xfer_action =3D UBT_IF_0_CTRL_DT_WR; > break; > =20 > case NG_HCI_ACL_DATA_PKT: > @@ -1863,12 +1606,12 @@ > UBT_BULK_WRITE_BUFFER_SIZE, m->m_pkthdr.len); > =20 > q =3D &sc->sc_aclq; > - action =3D UBT_FLAG_T_START_BULK; > + xfer_action =3D UBT_IF_0_BULK_DT_WR; > break; > =20 > case NG_HCI_SCO_DATA_PKT: > q =3D &sc->sc_scoq; > - action =3D 0; > + xfer_action =3D 255; > break; > =20 > default: > @@ -1881,10 +1624,10 @@ > /* NOT REACHED */ > } > =20 > - UBT_MBUFQ_LOCK(sc); > + UBT_LOCK(sc); > if (NG_BT_MBUFQ_FULL(q)) { > NG_BT_MBUFQ_DROP(q); > - UBT_MBUFQ_UNLOCK(sc); > + UBT_UNLOCK(sc); > =09 > UBT_ERR(sc, "Dropping HCI frame 0x%02x, len=3D%d. Queue full\n", > *mtod(m, uint8_t *), m->m_pkthdr.len); > @@ -1894,9 +1637,9 @@ > /* Loose HCI packet type, enqueue mbuf and kick off task */ > m_adj(m, sizeof(uint8_t)); > NG_BT_MBUFQ_ENQUEUE(q, m); > - ubt_task_schedule(sc, action); > - > - UBT_MBUFQ_UNLOCK(sc); > + if (xfer_action !=3D 255) > + usb2_transfer_start(sc->sc_xfer[xfer_action]); > + UBT_UNLOCK(sc); > } > done: > NG_FREE_ITEM(item); > @@ -1962,4 +1705,3 @@ > MODULE_DEPEND(ng_ubt, ng_hci, NG_BLUETOOTH_VERSION, NG_BLUETOOTH_VERSION= , NG_BLUETOOTH_VERSION); > MODULE_DEPEND(ng_ubt, usb2_bluetooth, 1, 1, 1); > MODULE_DEPEND(ng_ubt, usb2_core, 1, 1, 1); > - > diff -u ng_ubt2_var.h ng_ubt2_var.h > --- ng_ubt2_var.h Wed Jan 21 17:51:04 2009 > +++ ng_ubt2_var.h Fri Jan 23 20:08:04 2009 > @@ -28,7 +28,7 @@ > * SUCH DAMAGE. > * > * $Id: ng_ubt_var.h,v 1.2 2003/03/22 23:44:36 max Exp $ > - * $FreeBSD$ > + * $FreeBSD: src/sys/dev/usb2/bluetooth/ng_ubt2_var.h,v 1.2 2009/01/20 2= 2:17:05 emax Exp $ > */ > =20 > #ifndef _NG_UBT_VAR_H_ > @@ -47,8 +47,8 @@ > #define UBT_WARN(...) UBT_DEBUG(NG_UBT_WARN_LEVEL, __VA_ARGS__) > #define UBT_INFO(...) UBT_DEBUG(NG_UBT_INFO_LEVEL, __VA_ARGS__) > =20 > -#define UBT_MBUFQ_LOCK(sc) mtx_lock(&(sc)->sc_mbufq_mtx) > -#define UBT_MBUFQ_UNLOCK(sc) mtx_unlock(&(sc)->sc_mbufq_mtx) > +#define UBT_LOCK(sc) mtx_lock(&(sc)->sc_mtx) > +#define UBT_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) > =20 > /* Bluetooth USB control request type */ > #define UBT_HCI_REQUEST 0x20 > @@ -65,17 +65,14 @@ > UBT_IF_0_BULK_CS_WR, > UBT_IF_0_BULK_CS_RD, > UBT_IF_0_INTR_CS_RD, > - UBT_IF_0_N_TRANSFER, /* number of interface 0's transfers */ > =09 > /* Interface #1 transfers */ > - UBT_IF_1_ISOC_DT_RD1 =3D UBT_IF_0_N_TRANSFER, > + UBT_IF_1_ISOC_DT_RD1, > UBT_IF_1_ISOC_DT_RD2, > UBT_IF_1_ISOC_DT_WR1, > UBT_IF_1_ISOC_DT_WR2, > =20 > UBT_N_TRANSFER, /* total number of transfers */ > - > - UBT_IF_1_N_TRANSFER =3D UBT_N_TRANSFER - UBT_IF_1_ISOC_DT_RD1, > }; > =20 > /* USB device softc structure */ > @@ -89,6 +86,8 @@ > #define UBT_FLAG_READ_STALL (1 << 0) /* read transfer has stalled */ > #define UBT_FLAG_WRITE_STALL (1 << 1) /* write transfer has stalled */ > #define UBT_FLAG_INTR_STALL (1 << 2) /* inter transfer has stalled */ > +#define UBT_FLAG_READY (1 << 4) /* set when we are ready */ > +#define UBT_FLAG_SHUTDOWN (1 << 5) /* set when we are shutdown */ > =20 > ng_ubt_node_stat_ep sc_stat; /* statistic */ > #define UBT_STAT_PCKTS_SENT(sc) (sc)->sc_stat.pckts_sent ++ > @@ -100,11 +99,9 @@ > #define UBT_STAT_RESET(sc) bzero(&(sc)->sc_stat, sizeof((sc)->sc_stat)) > =20 > /* USB device specific */ > - struct mtx sc_if_mtx[2]; /* interface locks */ > + struct mtx sc_mtx; > struct usb2_xfer *sc_xfer[UBT_N_TRANSFER]; > =20 > - struct mtx sc_mbufq_mtx; /* lock for all queues */ > - > /* HCI commands */ > struct ng_bt_mbufq sc_cmdq; /* HCI command queue */ > #define UBT_CTRL_BUFFER_SIZE (sizeof(struct usb2_device_request) + \ > @@ -123,17 +120,6 @@ > /* Netgraph specific */ > node_p sc_node; /* pointer back to node */ > hook_p sc_hook; /* upstream hook */ > - > - /* Glue */ > - int sc_task_flags; /* task flags */ > -#define UBT_FLAG_T_PENDING (1 << 0) /* task pending */ > -#define UBT_FLAG_T_STOP_ALL (1 << 1) /* stop all xfers */ > -#define UBT_FLAG_T_START_ALL (1 << 2) /* start all read and isoc > - write xfers */ > -#define UBT_FLAG_T_START_CTRL (1 << 3) /* start control xfer (write) */ > -#define UBT_FLAG_T_START_BULK (1 << 4) /* start bulk xfer (write) */ > - > - struct task sc_task; > }; > typedef struct ubt_softc ubt_softc_t; > typedef struct ubt_softc * ubt_softc_p; --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --Zbynv6TNPa9FrOf6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6Qd8ACgkQKc512sD3afjbZwCgjF1ln3UHqXH4MHL2MG5Hnf6f 030AnjJJDtNP4PcHcFyWo48ypWf+qH5t =xthe -----END PGP SIGNATURE----- --Zbynv6TNPa9FrOf6-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 22:34:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E311065689; Fri, 23 Jan 2009 22:34:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 877D48FC0A; Fri, 23 Jan 2009 22:34:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=oWSvtglMsGghnkqxLvYA:9 a=fOFekdCCHLJb-4NVGNQA:7 a=OAMeedZ3YPCsO9wchdcBP6Tzsg0A:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 441916268; Fri, 23 Jan 2009 23:34:41 +0100 From: Hans Petter Selasky To: Maksim Yevmenkin Date: Fri, 23 Jan 2009 23:37:04 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232337.05627.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:34:45 -0000 Hi Maksim, On Friday 23 January 2009, Maksim Yevmenkin wrote: > > i've added taskqueue_drain() to detach() in my "stall" diff that i > posted few hours back. is that addresses some of your concerns? Yes, at detach you always need to drain by principle. > also > keep in mind that while netgraph node is created and destroyed > primarily by the driver in response to hardware arrival and departure, > nothing protects it from the netgraph side. in other words there is > another way to manipulate netgraph node using netgraph api. for > example user can request shutdown of a netgraph node, etc. so all of > this has to be taking into consideration. Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: http://perforce.freebsd.org/chv.cgi?CH=156586 > > in fact, if i understand you correctly, with addition of > taskqueue_drain() to detach(), the later becomes completely > synchronous. that is > > 1) NG_NODE_REF() > 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the > hooks, etc. etc.) > 3) taskqueue_drain() (i.e. sleep until task has finished) > 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) > 5) NG_NODE_UNREF() > 6) free everything up > > in theory, items (1) and (5) above just an additional protection > because i was not sure about inner workings of usb2. i think, when we > sort everything out they can be removed. I have a question. What is the following doing at the middle of the ubt_detach(): if (node != NULL) NG_NODE_UNREF(node); If you say that: ng_rmnode_self(node); Cleans up the last reference? > >> >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called > >> >> > unlocked. > >> >> > >> >> yes, usb2_transfer_unsetup() does that, does it not? > >> > > >> > That is correct, but sometimes you need to stop the transfers at an > >> > earlier point. It depends on your design. > > right > > >> when detach() is called its already out of driver's hands. all it can > >> do now is to call unsetup(), or am i missing something here? > > > > The correct thing is to do a usb2_transfer_drain() which will wait until > > the callback has been called back, if a transfer is pending. > > i do not understand. if usb2_transfer_unsetup() calls > usb2_transfer_drain() and sleeps, then what difference does it make in > detach()? You are right that USB-wise it does not matter if you call usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm just thinking with regard to the state inside bluetooth, because there are two contexts running in parallell. I.E. Callbacks might be executed in paralell to bluetooth tearing down. > i just followed original code that did it this way, i.e. > drain and unsetup all transfers in one call. Yes, that's fine. > > > In USB2 a "usb2_start_hardware()" call is always paired with a USB > > transfer callback, no matter what you do! This way of design has been > > chosen so that you can do refcounts inside the callback! > > ok, and that is exactly what code does. the only thing is that > refcounts are on netgraph node and not on softc structure. again the > reason for that is because netgraph node can be accessed from both > usb2 driver and netgraph subsystem directly. Isn't it enough to increment the refcount at attach and decrement it at detach ???? > > > I see in your code that you try to do things Asynchronously. This > > > > >> > complicates stuff quite a lot. In my patches I've tried to do some > >> > things synchronously. > >> > >> no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. > >> period. you _CAN_NOT_ grab usb interface mutexes unless you can > >> absolutely guarantee that they will not sleep for any significant > >> amount of time. > > > > usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will > > never sleep. The exception is "usb2_transfer_drain()" which can sleep for > > a few milliseconds and is only called when the hook is disconnected. I do > > not see that as a problem versus having "X" more checks in the code. > > well, when i looked at the code, i saw that both functions do > USB_BUS_LOCK() and USB_BUS_UNLOCK(). Well, this is the lock of the USB IRQ handler. One per USB controller. There are no more locks than this that will be locked. The IRQ handler is called from a high priority context and will not block very long. Same with USB callbacks. > i do not know enough about those > locks and usb2 in general, so i decided to err on the side of caution > and move all the operations that could potentially sleep into the > taskqueue context. this actually completely decouples netgraph from > usb2, and that is a "good thing (tm)" imo :) a little bit of > complexity is totally justified here imo. Ok, I see. > > also, now that you mentioned it, i should call usb2_transfer_drain() > in ubt_task() instead of usb2_transfer_stop() to make transfer stop > completely synchronous as well. When I think about it, usb2_transfer_stop() is enough. See my latest Patch in P4. > please let me reiterate, sleeping in netgraph is NOT allowed. even if > its for a few milliseconds. please accept it as a fact. think of all > netgraph methods as fast interrupt handlers. it is very typical for > fast interrupt handlers to do minimal amount of work and schedule swi > to do more heavy processing. that is exactly what the code does here. Fixed! > > there is no NG_NODE_REF in attach(). when we create node is comes with > one reference and that reference is removed by ng_rmnode_self(). > please read my comments about detach() above. hopefully it will make > sense now. Yes, I'm starting to understand it. > > i do not really have strong opinion about it. i just thought there > would be less contention between isoc and bulk/intr/ctrl transfers > when they use different locks. probably does not matter, since > everything is going over the same bus. i'm fine with this change utill > someone has credible evidence otherwise. Ok. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 22:34:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E311065689; Fri, 23 Jan 2009 22:34:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 877D48FC0A; Fri, 23 Jan 2009 22:34:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=oWSvtglMsGghnkqxLvYA:9 a=fOFekdCCHLJb-4NVGNQA:7 a=OAMeedZ3YPCsO9wchdcBP6Tzsg0A:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 441916268; Fri, 23 Jan 2009 23:34:41 +0100 From: Hans Petter Selasky To: Maksim Yevmenkin Date: Fri, 23 Jan 2009 23:37:04 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901232337.05627.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:34:45 -0000 Hi Maksim, On Friday 23 January 2009, Maksim Yevmenkin wrote: > > i've added taskqueue_drain() to detach() in my "stall" diff that i > posted few hours back. is that addresses some of your concerns? Yes, at detach you always need to drain by principle. > also > keep in mind that while netgraph node is created and destroyed > primarily by the driver in response to hardware arrival and departure, > nothing protects it from the netgraph side. in other words there is > another way to manipulate netgraph node using netgraph api. for > example user can request shutdown of a netgraph node, etc. so all of > this has to be taking into consideration. Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: http://perforce.freebsd.org/chv.cgi?CH=156586 > > in fact, if i understand you correctly, with addition of > taskqueue_drain() to detach(), the later becomes completely > synchronous. that is > > 1) NG_NODE_REF() > 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the > hooks, etc. etc.) > 3) taskqueue_drain() (i.e. sleep until task has finished) > 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) > 5) NG_NODE_UNREF() > 6) free everything up > > in theory, items (1) and (5) above just an additional protection > because i was not sure about inner workings of usb2. i think, when we > sort everything out they can be removed. I have a question. What is the following doing at the middle of the ubt_detach(): if (node != NULL) NG_NODE_UNREF(node); If you say that: ng_rmnode_self(node); Cleans up the last reference? > >> >> > 2) You drain all USB transfers: "usb2_transfer_drain()" called > >> >> > unlocked. > >> >> > >> >> yes, usb2_transfer_unsetup() does that, does it not? > >> > > >> > That is correct, but sometimes you need to stop the transfers at an > >> > earlier point. It depends on your design. > > right > > >> when detach() is called its already out of driver's hands. all it can > >> do now is to call unsetup(), or am i missing something here? > > > > The correct thing is to do a usb2_transfer_drain() which will wait until > > the callback has been called back, if a transfer is pending. > > i do not understand. if usb2_transfer_unsetup() calls > usb2_transfer_drain() and sleeps, then what difference does it make in > detach()? You are right that USB-wise it does not matter if you call usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm just thinking with regard to the state inside bluetooth, because there are two contexts running in parallell. I.E. Callbacks might be executed in paralell to bluetooth tearing down. > i just followed original code that did it this way, i.e. > drain and unsetup all transfers in one call. Yes, that's fine. > > > In USB2 a "usb2_start_hardware()" call is always paired with a USB > > transfer callback, no matter what you do! This way of design has been > > chosen so that you can do refcounts inside the callback! > > ok, and that is exactly what code does. the only thing is that > refcounts are on netgraph node and not on softc structure. again the > reason for that is because netgraph node can be accessed from both > usb2 driver and netgraph subsystem directly. Isn't it enough to increment the refcount at attach and decrement it at detach ???? > > > I see in your code that you try to do things Asynchronously. This > > > > >> > complicates stuff quite a lot. In my patches I've tried to do some > >> > things synchronously. > >> > >> no, No, NO (sorry for shouting). we _CAN_NOT_ sleep in netgraph. > >> period. you _CAN_NOT_ grab usb interface mutexes unless you can > >> absolutely guarantee that they will not sleep for any significant > >> amount of time. > > > > usb2_transfer_start() and usb2_transfer_stop() are non-blocking and will > > never sleep. The exception is "usb2_transfer_drain()" which can sleep for > > a few milliseconds and is only called when the hook is disconnected. I do > > not see that as a problem versus having "X" more checks in the code. > > well, when i looked at the code, i saw that both functions do > USB_BUS_LOCK() and USB_BUS_UNLOCK(). Well, this is the lock of the USB IRQ handler. One per USB controller. There are no more locks than this that will be locked. The IRQ handler is called from a high priority context and will not block very long. Same with USB callbacks. > i do not know enough about those > locks and usb2 in general, so i decided to err on the side of caution > and move all the operations that could potentially sleep into the > taskqueue context. this actually completely decouples netgraph from > usb2, and that is a "good thing (tm)" imo :) a little bit of > complexity is totally justified here imo. Ok, I see. > > also, now that you mentioned it, i should call usb2_transfer_drain() > in ubt_task() instead of usb2_transfer_stop() to make transfer stop > completely synchronous as well. When I think about it, usb2_transfer_stop() is enough. See my latest Patch in P4. > please let me reiterate, sleeping in netgraph is NOT allowed. even if > its for a few milliseconds. please accept it as a fact. think of all > netgraph methods as fast interrupt handlers. it is very typical for > fast interrupt handlers to do minimal amount of work and schedule swi > to do more heavy processing. that is exactly what the code does here. Fixed! > > there is no NG_NODE_REF in attach(). when we create node is comes with > one reference and that reference is removed by ng_rmnode_self(). > please read my comments about detach() above. hopefully it will make > sense now. Yes, I'm starting to understand it. > > i do not really have strong opinion about it. i just thought there > would be less contention between isoc and bulk/intr/ctrl transfers > when they use different locks. probably does not matter, since > everything is going over the same bus. i'm fine with this change utill > someone has credible evidence otherwise. Ok. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 22:38:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B36CD10656D2 for ; Fri, 23 Jan 2009 22:38:18 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9DE8FC1C for ; Fri, 23 Jan 2009 22:38:18 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LQUM8-0000Mi-NE for freebsd-current@freebsd.org; Sat, 24 Jan 2009 01:18:28 +0300 Received: from deprived.panopticon (unknown [192.168.0.34]) by hive.panopticon (Postfix) with ESMTP id B2BF9DE8D for ; Sat, 24 Jan 2009 01:18:42 +0300 (MSK) Received: by deprived.panopticon (Postfix, from userid 1000) id C863E1702D; Sat, 24 Jan 2009 01:18:26 +0300 (MSK) Date: Sat, 24 Jan 2009 01:18:26 +0300 From: Dmitry Marakasov To: freebsd-current@freebsd.org Message-ID: <20090123221826.GB30982@deprived.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: NFS data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:38:19 -0000 Hi! I'm using -CURRENT on my new desktop box (due to hardware support issues with 7.x), and I've experienced reproducible data corruptions with NFS. Server: 7.0-RELEASE amd64. Clients: 7.0-RELEASE i386 [no problems] CURRENT i386 [corruption] The problem showed itself as checksum mismatch when building a first port on a new box with distfiles/ mounted via NFS (using amd). For now I have two cases of corruption - in both cases it is single difference of one 128 byte block with file offsets 0x65F872 and 0x61A072. Seems like the corruption only appears once in either server lifetime or mount, as I've checked md5 for all 8GB of distfiles and only had single corruption, i.e. it shows itself once after the start of the client (in first 10-20MB's) and then everything is OK (I was able to build bunch of ports without problems). Is there any way I can help to diagnose and fix the problem? Here's amd.map file which is used to mount this filesystem: --- /defaults type:=nfs;rhost:=hive;opts:=rw,nosuid,noexec,-3,-i,-s,-T * rfs:=/pool/${key} --- Here's uname -a: FreeBSD hades.panopticon 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Jan 23 03:39:16 UTC 2009 root@chrysalis.panopticon:/mnt/usr/obj/mnt/usr/src/sys/HADES i386 -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 23:14:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E58106564A; Fri, 23 Jan 2009 23:14:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id ACBC38FC0A; Fri, 23 Jan 2009 23:14:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5050720rvf.43 for ; Fri, 23 Jan 2009 15:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1FCF8a5fmgbTSpV4ifLiKMFBeMbZo38KIt4wGHzjOqQ=; b=dWzSLaRHwyKVH92Ia6LMEue4hsUIe4Msxn7AHoQPU7J/fIKxDSWQOXBv6NwlCR+Aq+ 9uY/4G4zBKY7m4lga+iEvjGrFKJKr6j3ATKFL9BVSevGUEestagycvrMC69240IIvFNA HnQEksk9pWt2FlFwmu/TNBZqXGXZDMcgDM4H8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bibEUCsOywNHk4lUDAZX6qIiMfw53XeWuAmhMRz08a2KF3RJ6un6YmlGoM2AIxuiOY XynUegEE1Jm617F23l57uiwaqJmESHit74NdNXibuxrWyhlEUUGdnshVAA4mkvu5dcy6 B3vFpyWDTRnXwJaOc9k1KyxEhJNBscu3X7/sY= MIME-Version: 1.0 Received: by 10.141.113.3 with SMTP id q3mr5355244rvm.87.1232752461337; Fri, 23 Jan 2009 15:14:21 -0800 (PST) In-Reply-To: <200901232337.05627.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> <200901232337.05627.hselasky@c2i.net> Date: Fri, 23 Jan 2009 15:14:21 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 23:14:22 -0000 [...] >> i've added taskqueue_drain() to detach() in my "stall" diff that i >> posted few hours back. is that addresses some of your concerns? > > Yes, at detach you always need to drain by principle. ok, fine :) taskqueue_drain() in detach is go :) move to the next item :) >> also >> keep in mind that while netgraph node is created and destroyed >> primarily by the driver in response to hardware arrival and departure, >> nothing protects it from the netgraph side. in other words there is >> another way to manipulate netgraph node using netgraph api. for >> example user can request shutdown of a netgraph node, etc. so all of >> this has to be taking into consideration. > > Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: > > http://perforce.freebsd.org/chv.cgi?CH=156586 i'm sorry, did i mention there is no sleeping in netgraph? :-) again, sorry, but this is not going to work. you still doing UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to grab the same lock that is used for locking interfaces. more importantly, like i said before, usb2_transfer_stop() does USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb device will not do something synchronously over the same usb bus? i'm actually working on including some of your changes (except getting rid of ubt_task), so, please, lets just stop for a second and talk before we start commit war here :) please bear with me for just a second, ok? >> in fact, if i understand you correctly, with addition of >> taskqueue_drain() to detach(), the later becomes completely >> synchronous. that is >> >> 1) NG_NODE_REF() >> 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the >> hooks, etc. etc.) >> 3) taskqueue_drain() (i.e. sleep until task has finished) >> 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) >> 5) NG_NODE_UNREF() >> 6) free everything up >> >> in theory, items (1) and (5) above just an additional protection >> because i was not sure about inner workings of usb2. i think, when we >> sort everything out they can be removed. > > I have a question. What is the following doing at the middle of the > ubt_detach(): > > if (node != NULL) > NG_NODE_UNREF(node); > > If you say that: > > ng_rmnode_self(node); > > Cleans up the last reference? the complete code is node_p node = sc->sc_node; if (node != NULL) { sc->sc_node = NULL; <-- clear sc_node NG_NODE_SET_PRIVATE(node, NULL); NG_NODE_REALLY_DIE(node); NG_NODE_REF(node); <--- grab +1 reference ng_rmnode_self(node); <--- mark node as "dead", but not ensure its not free()d } /* bla, bla */ if (node != NULL) NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node so, say we enter detach() with only one reference (from attach()). when we see the sc_node pointer, we assume that there could be multiple (> 1) references on it. so just for added protection we grab one more (now reference count is 2). then we call ng_rmnode_self() which will mark node as "dead" and drop one reference (now reference count is 1). then we do "bla bla" stuff which could access node pointer. the important thing is that node pointer still points to a valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node is "dead" or "alive". finally when "bla bla" stuff is done, we know we are not going to access node pointer any mode and we drop our reference (now reference count is 0 and node is destroyed). >> i do not understand. if usb2_transfer_unsetup() calls >> usb2_transfer_drain() and sleeps, then what difference does it make in >> detach()? > > You are right that USB-wise it does not matter if you call > usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm > just thinking with regard to the state inside bluetooth, because there are > two contexts running in parallell. I.E. Callbacks might be executed in > paralell to bluetooth tearing down. do you mean transfer stop on hook disconnection? but those are protected by interface locks, no? and like i said, i'm changing ubt_task to call drain() instead of stop() to make stop completely synchronous (which is actually a nice thing). >> i just followed original code that did it this way, i.e. >> drain and unsetup all transfers in one call. > > Yes, that's fine. ok, fine. one more down :) >> > In USB2 a "usb2_start_hardware()" call is always paired with a USB >> > transfer callback, no matter what you do! This way of design has been >> > chosen so that you can do refcounts inside the callback! >> >> ok, and that is exactly what code does. the only thing is that >> refcounts are on netgraph node and not on softc structure. again the >> reason for that is because netgraph node can be accessed from both >> usb2 driver and netgraph subsystem directly. > > Isn't it enough to increment the refcount at attach and decrement it at > detach ???? it would be if we could sleep in netgraph, and we can not. in theory, we only need one extra reference which would tell us if there anything in usb2 that still could access node pointer. in practice, instead of checking every transfer and making sure its no pending before dropping that extra reference i just add multiple references for each usb2 transfer and ubt_task (i.e. things that could access node pointer). [...] >> well, when i looked at the code, i saw that both functions do >> USB_BUS_LOCK() and USB_BUS_UNLOCK(). > > Well, this is the lock of the USB IRQ handler. One per USB controller. There > are no more locks than this that will be locked. The IRQ handler is called > from a high priority context and will not block very long. Same with USB > callbacks. right, and what if some other usb device attached to the same usb controller is doing something synchronously? do you see that you could potentially block netgraph for arbitrary time and that is really out of ng_ubt2 driver control? >> also, now that you mentioned it, i should call usb2_transfer_drain() >> in ubt_task() instead of usb2_transfer_stop() to make transfer stop >> completely synchronous as well. > > When I think about it, usb2_transfer_stop() is enough. See my latest Patch in > P4. please read my comment above. >> please let me reiterate, sleeping in netgraph is NOT allowed. even if >> its for a few milliseconds. please accept it as a fact. think of all >> netgraph methods as fast interrupt handlers. it is very typical for >> fast interrupt handlers to do minimal amount of work and schedule swi >> to do more heavy processing. that is exactly what the code does here. > > Fixed! i beg to differ :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 23:14:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E58106564A; Fri, 23 Jan 2009 23:14:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id ACBC38FC0A; Fri, 23 Jan 2009 23:14:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5050720rvf.43 for ; Fri, 23 Jan 2009 15:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1FCF8a5fmgbTSpV4ifLiKMFBeMbZo38KIt4wGHzjOqQ=; b=dWzSLaRHwyKVH92Ia6LMEue4hsUIe4Msxn7AHoQPU7J/fIKxDSWQOXBv6NwlCR+Aq+ 9uY/4G4zBKY7m4lga+iEvjGrFKJKr6j3ATKFL9BVSevGUEestagycvrMC69240IIvFNA HnQEksk9pWt2FlFwmu/TNBZqXGXZDMcgDM4H8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bibEUCsOywNHk4lUDAZX6qIiMfw53XeWuAmhMRz08a2KF3RJ6un6YmlGoM2AIxuiOY XynUegEE1Jm617F23l57uiwaqJmESHit74NdNXibuxrWyhlEUUGdnshVAA4mkvu5dcy6 B3vFpyWDTRnXwJaOc9k1KyxEhJNBscu3X7/sY= MIME-Version: 1.0 Received: by 10.141.113.3 with SMTP id q3mr5355244rvm.87.1232752461337; Fri, 23 Jan 2009 15:14:21 -0800 (PST) In-Reply-To: <200901232337.05627.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> <200901232337.05627.hselasky@c2i.net> Date: Fri, 23 Jan 2009 15:14:21 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 23:14:22 -0000 [...] >> i've added taskqueue_drain() to detach() in my "stall" diff that i >> posted few hours back. is that addresses some of your concerns? > > Yes, at detach you always need to drain by principle. ok, fine :) taskqueue_drain() in detach is go :) move to the next item :) >> also >> keep in mind that while netgraph node is created and destroyed >> primarily by the driver in response to hardware arrival and departure, >> nothing protects it from the netgraph side. in other words there is >> another way to manipulate netgraph node using netgraph api. for >> example user can request shutdown of a netgraph node, etc. so all of >> this has to be taking into consideration. > > Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: > > http://perforce.freebsd.org/chv.cgi?CH=156586 i'm sorry, did i mention there is no sleeping in netgraph? :-) again, sorry, but this is not going to work. you still doing UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to grab the same lock that is used for locking interfaces. more importantly, like i said before, usb2_transfer_stop() does USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb device will not do something synchronously over the same usb bus? i'm actually working on including some of your changes (except getting rid of ubt_task), so, please, lets just stop for a second and talk before we start commit war here :) please bear with me for just a second, ok? >> in fact, if i understand you correctly, with addition of >> taskqueue_drain() to detach(), the later becomes completely >> synchronous. that is >> >> 1) NG_NODE_REF() >> 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the >> hooks, etc. etc.) >> 3) taskqueue_drain() (i.e. sleep until task has finished) >> 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) >> 5) NG_NODE_UNREF() >> 6) free everything up >> >> in theory, items (1) and (5) above just an additional protection >> because i was not sure about inner workings of usb2. i think, when we >> sort everything out they can be removed. > > I have a question. What is the following doing at the middle of the > ubt_detach(): > > if (node != NULL) > NG_NODE_UNREF(node); > > If you say that: > > ng_rmnode_self(node); > > Cleans up the last reference? the complete code is node_p node = sc->sc_node; if (node != NULL) { sc->sc_node = NULL; <-- clear sc_node NG_NODE_SET_PRIVATE(node, NULL); NG_NODE_REALLY_DIE(node); NG_NODE_REF(node); <--- grab +1 reference ng_rmnode_self(node); <--- mark node as "dead", but not ensure its not free()d } /* bla, bla */ if (node != NULL) NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node so, say we enter detach() with only one reference (from attach()). when we see the sc_node pointer, we assume that there could be multiple (> 1) references on it. so just for added protection we grab one more (now reference count is 2). then we call ng_rmnode_self() which will mark node as "dead" and drop one reference (now reference count is 1). then we do "bla bla" stuff which could access node pointer. the important thing is that node pointer still points to a valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node is "dead" or "alive". finally when "bla bla" stuff is done, we know we are not going to access node pointer any mode and we drop our reference (now reference count is 0 and node is destroyed). >> i do not understand. if usb2_transfer_unsetup() calls >> usb2_transfer_drain() and sleeps, then what difference does it make in >> detach()? > > You are right that USB-wise it does not matter if you call > usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm > just thinking with regard to the state inside bluetooth, because there are > two contexts running in parallell. I.E. Callbacks might be executed in > paralell to bluetooth tearing down. do you mean transfer stop on hook disconnection? but those are protected by interface locks, no? and like i said, i'm changing ubt_task to call drain() instead of stop() to make stop completely synchronous (which is actually a nice thing). >> i just followed original code that did it this way, i.e. >> drain and unsetup all transfers in one call. > > Yes, that's fine. ok, fine. one more down :) >> > In USB2 a "usb2_start_hardware()" call is always paired with a USB >> > transfer callback, no matter what you do! This way of design has been >> > chosen so that you can do refcounts inside the callback! >> >> ok, and that is exactly what code does. the only thing is that >> refcounts are on netgraph node and not on softc structure. again the >> reason for that is because netgraph node can be accessed from both >> usb2 driver and netgraph subsystem directly. > > Isn't it enough to increment the refcount at attach and decrement it at > detach ???? it would be if we could sleep in netgraph, and we can not. in theory, we only need one extra reference which would tell us if there anything in usb2 that still could access node pointer. in practice, instead of checking every transfer and making sure its no pending before dropping that extra reference i just add multiple references for each usb2 transfer and ubt_task (i.e. things that could access node pointer). [...] >> well, when i looked at the code, i saw that both functions do >> USB_BUS_LOCK() and USB_BUS_UNLOCK(). > > Well, this is the lock of the USB IRQ handler. One per USB controller. There > are no more locks than this that will be locked. The IRQ handler is called > from a high priority context and will not block very long. Same with USB > callbacks. right, and what if some other usb device attached to the same usb controller is doing something synchronously? do you see that you could potentially block netgraph for arbitrary time and that is really out of ng_ubt2 driver control? >> also, now that you mentioned it, i should call usb2_transfer_drain() >> in ubt_task() instead of usb2_transfer_stop() to make transfer stop >> completely synchronous as well. > > When I think about it, usb2_transfer_stop() is enough. See my latest Patch in > P4. please read my comment above. >> please let me reiterate, sleeping in netgraph is NOT allowed. even if >> its for a few milliseconds. please accept it as a fact. think of all >> netgraph methods as fast interrupt handlers. it is very typical for >> fast interrupt handlers to do minimal amount of work and schedule swi >> to do more heavy processing. that is exactly what the code does here. > > Fixed! i beg to differ :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 23:21:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680A81065676; Fri, 23 Jan 2009 23:21:22 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 34FE18FC0C; Fri, 23 Jan 2009 23:21:22 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so707846rvb.3 for ; Fri, 23 Jan 2009 15:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uP8UPvJGUVw5pLC70zZ8HpQMJU4MZ1EmvsYMI53T5Po=; b=pVTqYx/QoINH0T+dZGurjLszKg2Wmc1oAl6W/efy5Bu2ihnfy9FU+ZNO8bfaIiPHH0 DWDEZUqop5SR2vlm73ti0ME8+Kwm02fIrTB77v8sijZNycmz3g/Y0gA+1rJHwbIUX91v 5zkBiAdB1uRhAKTtKDQPBYB2gbyi470F8aCVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d6GLx8iHdlXU70DMhfPUlaLbqi9wN/deZCKV6wyDS/F+3R/t+Yvun3GPIXxAZMvnOP iZptSNERT56u9Fo2Gt4ku+7VYHT4xvAEoI7L2auQkNtysiYXbAmPii7vTmx4iamYNnWi 1B+L4fE3Q7dXZcRxWhxnefHX4G0wFJqYfvcjc= MIME-Version: 1.0 Received: by 10.141.98.13 with SMTP id a13mr726290rvm.20.1232752881819; Fri, 23 Jan 2009 15:21:21 -0800 (PST) In-Reply-To: <20090123212952.GM60948@e.0x20.net> References: <20090123212952.GM60948@e.0x20.net> Date: Fri, 23 Jan 2009 15:21:21 -0800 Message-ID: From: Maksim Yevmenkin To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 23:21:22 -0000 > Thanks for the quick patch, but that did not help: > > ubt0: on usbus2 > ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALLED > ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STALLED stalled transfers are NOT going to be fixed. the patch was to make sure the system would not crash with stalled transfers. > I also have another usb bluetooth stick which shows this on insertion: > > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1401: set address 2 failed (ignored) > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1436: getting device descriptor at addr 2 failed! this is something else. this happens earlier than usb2_bluetooth_ng > Jan 23 22:13:01 maggie kernel: ugen0.2: at usbus0 > Jan 23 22:13:01 maggie kernel: ubt1: on usbus0 that looks normal to me. thanks, max > > > > Lars > From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 23:30:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 187941065674 for ; Fri, 23 Jan 2009 23:30:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D50628FC0C for ; Fri, 23 Jan 2009 23:30:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2C8AF73098; Sat, 24 Jan 2009 00:36:11 +0100 (CET) Date: Sat, 24 Jan 2009 00:36:11 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090123233611.GA58363@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: quickly build a single program ? (was KERNCONF and KERNFAST related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 23:30:47 -0000 how hard would it be to modify the build scripts so that they only try to rebuild a single program from a tree where you already made a buildworld ? i usually do modifications to a single program at a time and it is slightly annoying to wait for the build process to scan through all the already-built programs to find there is nothing to do for them. I guess one would have to override SUBDIR in the main Makefile.inc1, and then again in the children Makefiles, taking each time the next component of the filename... cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 03:07:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE038106566B; Sat, 24 Jan 2009 03:07:50 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id B7FA48FC12; Sat, 24 Jan 2009 03:07:50 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 23 Jan 2009 18:40:11 -0800 Message-ID: <497A7F8E.60804@elischer.org> Date: Fri, 23 Jan 2009 18:40:14 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> <200901232337.05627.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 03:07:51 -0000 Maksim Yevmenkin wrote: > [...] > >>> i've added taskqueue_drain() to detach() in my "stall" diff that i >>> posted few hours back. is that addresses some of your concerns? >> Yes, at detach you always need to drain by principle. > > ok, fine :) taskqueue_drain() in detach is go :) move to the next item :) > >>> also >>> keep in mind that while netgraph node is created and destroyed >>> primarily by the driver in response to hardware arrival and departure, >>> nothing protects it from the netgraph side. in other words there is >>> another way to manipulate netgraph node using netgraph api. for >>> example user can request shutdown of a netgraph node, etc. so all of >>> this has to be taking into consideration. >> Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: >> >> http://perforce.freebsd.org/chv.cgi?CH=156586 > > i'm sorry, did i mention there is no sleeping in netgraph? :-) it's not just netgraph.. it's the network stack in general.. can you imagine tcp deciding to sleep? > > again, sorry, but this is not going to work. you still doing > UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to > grab the same lock that is used for locking interfaces. > > more importantly, like i said before, usb2_transfer_stop() does > USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb > device will not do something synchronously over the same usb bus? > > i'm actually working on including some of your changes (except getting > rid of ubt_task), so, please, lets just stop for a second and talk > before we start commit war here :) please bear with me for just a > second, ok? > >>> in fact, if i understand you correctly, with addition of >>> taskqueue_drain() to detach(), the later becomes completely >>> synchronous. that is >>> >>> 1) NG_NODE_REF() >>> 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the >>> hooks, etc. etc.) >>> 3) taskqueue_drain() (i.e. sleep until task has finished) >>> 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) >>> 5) NG_NODE_UNREF() >>> 6) free everything up >>> >>> in theory, items (1) and (5) above just an additional protection >>> because i was not sure about inner workings of usb2. i think, when we >>> sort everything out they can be removed. >> I have a question. What is the following doing at the middle of the >> ubt_detach(): >> >> if (node != NULL) >> NG_NODE_UNREF(node); >> >> If you say that: >> >> ng_rmnode_self(node); >> >> Cleans up the last reference? > > the complete code is > > node_p node = sc->sc_node; > > if (node != NULL) { > sc->sc_node = NULL; <-- clear sc_node > > NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > > NG_NODE_REF(node); <--- grab +1 reference > ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > not free()d > } > > /* bla, bla */ > > if (node != NULL) > NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > so, say we enter detach() with only one reference (from attach()). > when we see the sc_node pointer, we assume that there could be > multiple (> 1) references on it. so just for added protection we grab > one more (now reference count is 2). then we call ng_rmnode_self() > which will mark node as "dead" and drop one reference (now reference > count is 1). then we do "bla bla" stuff which could access node > pointer. the important thing is that node pointer still points to a > valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node > is "dead" or "alive". finally when "bla bla" stuff is done, we know we > are not going to access node pointer any mode and we drop our > reference (now reference count is 0 and node is destroyed). > > >>> i do not understand. if usb2_transfer_unsetup() calls >>> usb2_transfer_drain() and sleeps, then what difference does it make in >>> detach()? >> You are right that USB-wise it does not matter if you call >> usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm >> just thinking with regard to the state inside bluetooth, because there are >> two contexts running in parallell. I.E. Callbacks might be executed in >> paralell to bluetooth tearing down. > > do you mean transfer stop on hook disconnection? but those are > protected by interface locks, no? and like i said, i'm changing > ubt_task to call drain() instead of stop() to make stop completely > synchronous (which is actually a nice thing). > >>> i just followed original code that did it this way, i.e. >>> drain and unsetup all transfers in one call. >> Yes, that's fine. > > ok, fine. one more down :) > >>>> In USB2 a "usb2_start_hardware()" call is always paired with a USB >>>> transfer callback, no matter what you do! This way of design has been >>>> chosen so that you can do refcounts inside the callback! >>> ok, and that is exactly what code does. the only thing is that >>> refcounts are on netgraph node and not on softc structure. again the >>> reason for that is because netgraph node can be accessed from both >>> usb2 driver and netgraph subsystem directly. >> Isn't it enough to increment the refcount at attach and decrement it at >> detach ???? > > it would be if we could sleep in netgraph, and we can not. in theory, > we only need one extra reference which would tell us if there anything > in usb2 that still could access node pointer. in practice, instead of > checking every transfer and making sure its no pending before dropping > that extra reference i just add multiple references for each usb2 > transfer and ubt_task (i.e. things that could access node pointer). > > [...] > >>> well, when i looked at the code, i saw that both functions do >>> USB_BUS_LOCK() and USB_BUS_UNLOCK(). >> Well, this is the lock of the USB IRQ handler. One per USB controller. There >> are no more locks than this that will be locked. The IRQ handler is called >> from a high priority context and will not block very long. Same with USB >> callbacks. > > right, and what if some other usb device attached to the same usb > controller is doing something synchronously? do you see that you could > potentially block netgraph for arbitrary time and that is really out > of ng_ubt2 driver control? > >>> also, now that you mentioned it, i should call usb2_transfer_drain() >>> in ubt_task() instead of usb2_transfer_stop() to make transfer stop >>> completely synchronous as well. >> When I think about it, usb2_transfer_stop() is enough. See my latest Patch in >> P4. > > please read my comment above. > >>> please let me reiterate, sleeping in netgraph is NOT allowed. even if >>> its for a few milliseconds. please accept it as a fact. think of all >>> netgraph methods as fast interrupt handlers. it is very typical for >>> fast interrupt handlers to do minimal amount of work and schedule swi >>> to do more heavy processing. that is exactly what the code does here. >> Fixed! > > i beg to differ :) > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 03:07:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE038106566B; Sat, 24 Jan 2009 03:07:50 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id B7FA48FC12; Sat, 24 Jan 2009 03:07:50 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 23 Jan 2009 18:40:11 -0800 Message-ID: <497A7F8E.60804@elischer.org> Date: Fri, 23 Jan 2009 18:40:14 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232146.58360.hselasky@c2i.net> <200901232337.05627.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 03:07:51 -0000 Maksim Yevmenkin wrote: > [...] > >>> i've added taskqueue_drain() to detach() in my "stall" diff that i >>> posted few hours back. is that addresses some of your concerns? >> Yes, at detach you always need to drain by principle. > > ok, fine :) taskqueue_drain() in detach is go :) move to the next item :) > >>> also >>> keep in mind that while netgraph node is created and destroyed >>> primarily by the driver in response to hardware arrival and departure, >>> nothing protects it from the netgraph side. in other words there is >>> another way to manipulate netgraph node using netgraph api. for >>> example user can request shutdown of a netgraph node, etc. so all of >>> this has to be taking into consideration. >> Ok, I've fixed this: Destroy is now non-blocking USB-wise. See: >> >> http://perforce.freebsd.org/chv.cgi?CH=156586 > > i'm sorry, did i mention there is no sleeping in netgraph? :-) it's not just netgraph.. it's the network stack in general.. can you imagine tcp deciding to sleep? > > again, sorry, but this is not going to work. you still doing > UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to > grab the same lock that is used for locking interfaces. > > more importantly, like i said before, usb2_transfer_stop() does > USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb > device will not do something synchronously over the same usb bus? > > i'm actually working on including some of your changes (except getting > rid of ubt_task), so, please, lets just stop for a second and talk > before we start commit war here :) please bear with me for just a > second, ok? > >>> in fact, if i understand you correctly, with addition of >>> taskqueue_drain() to detach(), the later becomes completely >>> synchronous. that is >>> >>> 1) NG_NODE_REF() >>> 2) ng_rmnode_self (i.e. mark node as possibly dead, detach all the >>> hooks, etc. etc.) >>> 3) taskqueue_drain() (i.e. sleep until task has finished) >>> 4) usb2_transfer_unsetup() (which does "usb2_transfer_drain() and sleeps) >>> 5) NG_NODE_UNREF() >>> 6) free everything up >>> >>> in theory, items (1) and (5) above just an additional protection >>> because i was not sure about inner workings of usb2. i think, when we >>> sort everything out they can be removed. >> I have a question. What is the following doing at the middle of the >> ubt_detach(): >> >> if (node != NULL) >> NG_NODE_UNREF(node); >> >> If you say that: >> >> ng_rmnode_self(node); >> >> Cleans up the last reference? > > the complete code is > > node_p node = sc->sc_node; > > if (node != NULL) { > sc->sc_node = NULL; <-- clear sc_node > > NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > > NG_NODE_REF(node); <--- grab +1 reference > ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > not free()d > } > > /* bla, bla */ > > if (node != NULL) > NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > so, say we enter detach() with only one reference (from attach()). > when we see the sc_node pointer, we assume that there could be > multiple (> 1) references on it. so just for added protection we grab > one more (now reference count is 2). then we call ng_rmnode_self() > which will mark node as "dead" and drop one reference (now reference > count is 1). then we do "bla bla" stuff which could access node > pointer. the important thing is that node pointer still points to a > valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node > is "dead" or "alive". finally when "bla bla" stuff is done, we know we > are not going to access node pointer any mode and we drop our > reference (now reference count is 0 and node is destroyed). > > >>> i do not understand. if usb2_transfer_unsetup() calls >>> usb2_transfer_drain() and sleeps, then what difference does it make in >>> detach()? >> You are right that USB-wise it does not matter if you call >> usb2_transfer_drain() separately or if you call usb2_transfer_unsetup(). I'm >> just thinking with regard to the state inside bluetooth, because there are >> two contexts running in parallell. I.E. Callbacks might be executed in >> paralell to bluetooth tearing down. > > do you mean transfer stop on hook disconnection? but those are > protected by interface locks, no? and like i said, i'm changing > ubt_task to call drain() instead of stop() to make stop completely > synchronous (which is actually a nice thing). > >>> i just followed original code that did it this way, i.e. >>> drain and unsetup all transfers in one call. >> Yes, that's fine. > > ok, fine. one more down :) > >>>> In USB2 a "usb2_start_hardware()" call is always paired with a USB >>>> transfer callback, no matter what you do! This way of design has been >>>> chosen so that you can do refcounts inside the callback! >>> ok, and that is exactly what code does. the only thing is that >>> refcounts are on netgraph node and not on softc structure. again the >>> reason for that is because netgraph node can be accessed from both >>> usb2 driver and netgraph subsystem directly. >> Isn't it enough to increment the refcount at attach and decrement it at >> detach ???? > > it would be if we could sleep in netgraph, and we can not. in theory, > we only need one extra reference which would tell us if there anything > in usb2 that still could access node pointer. in practice, instead of > checking every transfer and making sure its no pending before dropping > that extra reference i just add multiple references for each usb2 > transfer and ubt_task (i.e. things that could access node pointer). > > [...] > >>> well, when i looked at the code, i saw that both functions do >>> USB_BUS_LOCK() and USB_BUS_UNLOCK(). >> Well, this is the lock of the USB IRQ handler. One per USB controller. There >> are no more locks than this that will be locked. The IRQ handler is called >> from a high priority context and will not block very long. Same with USB >> callbacks. > > right, and what if some other usb device attached to the same usb > controller is doing something synchronously? do you see that you could > potentially block netgraph for arbitrary time and that is really out > of ng_ubt2 driver control? > >>> also, now that you mentioned it, i should call usb2_transfer_drain() >>> in ubt_task() instead of usb2_transfer_stop() to make transfer stop >>> completely synchronous as well. >> When I think about it, usb2_transfer_stop() is enough. See my latest Patch in >> P4. > > please read my comment above. > >>> please let me reiterate, sleeping in netgraph is NOT allowed. even if >>> its for a few milliseconds. please accept it as a fact. think of all >>> netgraph methods as fast interrupt handlers. it is very typical for >>> fast interrupt handlers to do minimal amount of work and schedule swi >>> to do more heavy processing. that is exactly what the code does here. >> Fixed! > > i beg to differ :) > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 03:10:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7679D1065675 for ; Sat, 24 Jan 2009 03:10:31 +0000 (UTC) (envelope-from terry@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB338FC1E for ; Sat, 24 Jan 2009 03:10:31 +0000 (UTC) (envelope-from terry@tmk.com) Received: from tmk.com by tmk.com (PMDF V6.3-x13 #37010) id <01N4NECPTTYO00EQWX@tmk.com> for freebsd-current@freebsd.org; Fri, 23 Jan 2009 21:33:51 -0500 (EST) Date: Fri, 23 Jan 2009 21:30:50 -0500 (EST) From: Terry Kennedy To: freebsd-current@freebsd.org Message-id: <01N4NEOEB7LY00EQWX@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-Mailman-Approved-At: Sat, 24 Jan 2009 03:28:45 +0000 Subject: Help me select hardware and software options for very large server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 03:10:31 -0000 [I posted the following message to freebsd-questions, as I thought it woule be the most appropriate list. As it has received no replies in two weeks, I'm trying freebsd-current.] -------- [I decided to ask this question here as it overlaps -hardware, -current, and a couple other lists. I'd be glad to redirect the conversation to a list that's a better fit, if anyone would care to suggest one.] I'm in the process of planning the hardware and software for the second generation of my RAIDzilla file servers (see http://www.tmk.com/raidzilla for the current generation, in production for 4+ years). I expect that what I'm planning is probably "off the scale" in terms of processing and storage capacity, and I'd like to find out and address any issues before spending lots of money. Here's what I'm thinking of: o Chassis - CI Design SR316 (same model as current chassis, except i2c link between RAID controller and front panel o Motherboard - Intel S5000PSLSATAR o CPU - 2x Intel Xeon E5450 BX80574E5450P p Remote management - Intel Remote Management Module 2 - AXXRM2 o Memory - 16GB - 8x Kingston KVR667D2D4F5/2GI o RAID controller - 3Ware 9650SE-16ML w/ BBU-MODULE-04 o Drives - 16x 2TB drives [not mentioning manufacturer yet] o Cables - 4x multi-lane SATA cables o DVD-ROM drive o Auxiliary slot fan next to BBU card o Adaptec AHA-39160 (for Quantum Superloader 3 tape drive) So much for the hardware. On the software front: o FreeBSD 8.x? o amd64 architecture o MBR+UFS2 for operating system partitions (hard partition in controller) o GPT+ZFS for data partitions o Multiple 8TB data partitions (separate 8TB controller partitions or one big partition divided with GPT?) I looked at "Large data storage in FreeBSD", but that seems to be a stale page from 2005 or so: http://www.freebsd.org/projects/bigdisk/index.html I'm pretty sure I need ZFS, since even with the 2TB partitions I have now, taking snapshots for dump or doing a fsck take approximately forever 8-) I'll be using the harware RAID 6 on the 3Ware controller, so I'd only be using ZFS to get filesystems larger than 2TB. I've been following the ZFS discussions on -current and -stable, and I think that while it isn't quite ready yet, it probably will be ready in a few months, being available around the same time I get this hardware asssembled. I recall reading that there will be an import of newer ZFS code in the near future. Similarly, the ports collection seems to be moving along nicely with amd64 support. I think this system may have the most storage ever configured on a FreeBSD system, and it is probably up near the top in terms of CPU and memory. Once I have it assembled I'd be glad to let any FreeBSD devel- opers test and stress it if that would help improve FreeBSD on that type of configuration. In the meantime, any suggestions regarding the hardware or software con- figuration would be welcomed. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 03:46:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA4601065670 for ; Sat, 24 Jan 2009 03:46:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5A32A8FC17 for ; Sat, 24 Jan 2009 03:46:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl205-109.kln.forthnet.gr [79.103.18.109]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n0O3QZpR032756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Jan 2009 05:26:44 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0O3QZUX017531; Sat, 24 Jan 2009 05:26:35 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0O3QY8Q017530; Sat, 24 Jan 2009 05:26:34 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Luigi Rizzo References: <20090123233611.GA58363@onelab2.iet.unipi.it> Date: Sat, 24 Jan 2009 05:26:33 +0200 In-Reply-To: <20090123233611.GA58363@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Sat, 24 Jan 2009 00:36:11 +0100") Message-ID: <877i4lo046.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n0O3QZpR032756 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.963, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org Subject: Re: quickly build a single program ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 03:46:37 -0000 On Sat, 24 Jan 2009 00:36:11 +0100, Luigi Rizzo wrote: > how hard would it be to modify the build scripts so that they only try > to rebuild a single program from a tree where you already made a buildworld ? > > i usually do modifications to a single program at a time and it is > slightly annoying to wait for the build process to scan through all > the already-built programs to find there is nothing to do for them. Most of the time, when there are small changes I just change into the program's directory and `make'. But this doesn't work when there are dependencies with other parts of buildworld. > I guess one would have to override SUBDIR in the main Makefile.inc1, > and then again in the children Makefiles, taking each time the next > component of the filename... Overriding SUBDIR might be a bit hard to do `right' when there are libraries or header files involved. For example libexec/sendmail depends on stuff from contrib/ but rebuilding *only* the final `sendmail' binary may not work if it links with a stable static library like libsm.a from the OBJDIR. But it sounds like an interesting thing :) From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 06:49:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001F7106564A for ; Sat, 24 Jan 2009 06:49:52 +0000 (UTC) (envelope-from scott.gasch@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id CAB218FC13 for ; Sat, 24 Jan 2009 06:49:52 +0000 (UTC) (envelope-from scott.gasch@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so5557174wfg.7 for ; Fri, 23 Jan 2009 22:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=c3lKEdSpKCaGxnfw1xjKRaN8K2KyCmXdNF01dOf6Im8=; b=i9BsW0bNUNFPnkBLzt7uIbxJpGoCzjnRj+/mkbYDXt6vaBj5qdO41AC/wjiE/vHXnb SxB7rNtbVe/ULRyGPHmusJJDEAliVDucNLtdt2IW0MWYkJ7PrbFwxOnsmX3hENLt2mCD Tjw1ejJ26HO9WmrH0mrmdnYnQmWg28BIEVjDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fjLsVtRN1roYdnFgb4jMiXPn0ap6kL6R+JcI2w4w7TruCXdeSBHTaj3A0CyLVcsZKO G6hD2wZS49OkwwKVQPj3nMXkfmBWJa25wdI+Yv58LwH3mhCnhV82DwCO3C0Fp7zhQM3h W9RQO+lVzyX6TRFjgzBMLCm1TVVHU8tU1DgIM= MIME-Version: 1.0 Received: by 10.142.191.5 with SMTP id o5mr1008580wff.53.1232778531707; Fri, 23 Jan 2009 22:28:51 -0800 (PST) Date: Fri, 23 Jan 2009 22:28:51 -0800 Message-ID: From: Scott Gasch To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problems with ata driver on current / Asus P5Q-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 06:49:53 -0000 Hi, I've been running a 7.1-p1 (amd64) system and and seeing very high interrupt rates on irq19 which is shared between several devices. Over 60% of one core is used responding to interrupts. The machine also hangs frequently. irq19 is shared by atapci1, atapci2, fwohci0 and uhci4... the consensus response to my last question was that "it's probably the ata driver". Today I tried building and booting a GENERIC current kernel and got another piece of information. The freebsd-current GENERIC kernel does not boot; shortly after probing the drives it says "Cannot setup DMA" several times on the console and hangs. This machine is an Asus P5Q-E... I believe it has two ATA controllers: a Marvell 88SE6121 and a Silicon Image SIL5723. Is one of these chipsets generating interrupts that the driver doesn't understand and/or properly dismiss? Can it be put into a legacy mode that works? This machine has problems in 7.0, 7.1 and current... I'm running out of ideas. Thx, Scott From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 08:50:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897671065670; Sat, 24 Jan 2009 08:50:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 91A268FC12; Sat, 24 Jan 2009 08:49:59 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=Rsq1cAPvigA9vx5Vc2IA:9 a=5-tWRKUgxnYdVFAfiMUA:7 a=Mxq81XjTjli6FP15xCk4g4Atep8A:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 134334152; Sat, 24 Jan 2009 09:49:57 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 09:52:20 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901240952.21670.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 08:50:01 -0000 Hi Maksim, On Saturday 24 January 2009, Maksim Yevmenkin wrote: > [...] > i'm sorry, did i mention there is no sleeping in netgraph? :-) > > again, sorry, but this is not going to work. you still doing > UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to > grab the same lock that is used for locking interfaces. Yes, you have to do that. Else you end up with a state nightmare with the taskqueue where you don't know in the end if you should start or stop the USB interface! > more importantly, like i said before, usb2_transfer_stop() does > USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb > device will not do something synchronously over the same usb bus? Every time something is done synchronously the USB_BUS_LOCK() is dropped. This mutex is only used when filling out DMA structures and when touching USB hardware registers. I cannot see that this will take any time at all. We are talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and not a SX lock! A mutex cannot sleep in the same way an SX lock can. > i'm actually working on including some of your changes (except getting > rid of ubt_task), so, please, lets just stop for a second and talk > before we start commit war here :) please bear with me for just a > second, ok? Ok. > > > > > I have a question. What is the following doing at the middle of the > > ubt_detach(): > > > > if (node != NULL) > > NG_NODE_UNREF(node); > > > > If you say that: > > > > ng_rmnode_self(node); > > > > Cleans up the last reference? > > the complete code is > > node_p node = sc->sc_node; > > if (node != NULL) { > sc->sc_node = NULL; <-- clear sc_node > > NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > > NG_NODE_REF(node); <--- grab +1 reference > ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > not free()d > } > > /* bla, bla */ > > if (node != NULL) > NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node Yes, but you are already dropping an extra reference in ubt_shutdown(). What about that? > so, say we enter detach() with only one reference (from attach()). > when we see the sc_node pointer, we assume that there could be > multiple (> 1) references on it. so just for added protection we grab > one more (now reference count is 2). then we call ng_rmnode_self() > which will mark node as "dead" and drop one reference (now reference > count is 1). then we do "bla bla" stuff which could access node > pointer. the important thing is that node pointer still points to a > valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node > is "dead" or "alive". finally when "bla bla" stuff is done, we know we > are not going to access node pointer any mode and we drop our > reference (now reference count is 0 and node is destroyed). > do you mean transfer stop on hook disconnection? but those are > protected by interface locks, no? and like i said, i'm changing > ubt_task to call drain() instead of stop() to make stop completely > synchronous (which is actually a nice thing). I think you misunderstand. I'm using mutexes. They will not block for very long! There are no DELAY()'s with mutexes held! When another USB device is attached / detached it is: 1) Done from another thread 2) The USB locks in the critical path are dropped when waiting for wakeup or doing so called synchronous stuff. > > it would be if we could sleep in netgraph, and we can not. Do mutexes sleep? No? So my code should be fine? > in theory, > we only need one extra reference which would tell us if there anything > in usb2 that still could access node pointer. in practice, instead of > checking every transfer and making sure its no pending before dropping > that extra reference i just add multiple references for each usb2 > transfer and ubt_task (i.e. things that could access node pointer). I'm just thinking that this is starting to get complicated, and please understand I've spent much time on detach issues, and there is alot of builtin funcionality inside USB which will handle start/stop/re-start issues automagically. I see it like duplicate code when you check for USB transfer re-start in netgraph ??? > > right, and what if some other usb device attached to the same usb > controller is doing something synchronously? do you see that you could > potentially block netgraph for arbitrary time and that is really out > of ng_ubt2 driver control? Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is called from High Priority threads! See explanation further up. And will not block very long at all. > > i beg to differ :) Ok, I think we are going somewhere! --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 08:50:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897671065670; Sat, 24 Jan 2009 08:50:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 91A268FC12; Sat, 24 Jan 2009 08:49:59 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=Rsq1cAPvigA9vx5Vc2IA:9 a=5-tWRKUgxnYdVFAfiMUA:7 a=Mxq81XjTjli6FP15xCk4g4Atep8A:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 134334152; Sat, 24 Jan 2009 09:49:57 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 09:52:20 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901240952.21670.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 08:50:01 -0000 Hi Maksim, On Saturday 24 January 2009, Maksim Yevmenkin wrote: > [...] > i'm sorry, did i mention there is no sleeping in netgraph? :-) > > again, sorry, but this is not going to work. you still doing > UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to > grab the same lock that is used for locking interfaces. Yes, you have to do that. Else you end up with a state nightmare with the taskqueue where you don't know in the end if you should start or stop the USB interface! > more importantly, like i said before, usb2_transfer_stop() does > USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb > device will not do something synchronously over the same usb bus? Every time something is done synchronously the USB_BUS_LOCK() is dropped. This mutex is only used when filling out DMA structures and when touching USB hardware registers. I cannot see that this will take any time at all. We are talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and not a SX lock! A mutex cannot sleep in the same way an SX lock can. > i'm actually working on including some of your changes (except getting > rid of ubt_task), so, please, lets just stop for a second and talk > before we start commit war here :) please bear with me for just a > second, ok? Ok. > > > > > I have a question. What is the following doing at the middle of the > > ubt_detach(): > > > > if (node != NULL) > > NG_NODE_UNREF(node); > > > > If you say that: > > > > ng_rmnode_self(node); > > > > Cleans up the last reference? > > the complete code is > > node_p node = sc->sc_node; > > if (node != NULL) { > sc->sc_node = NULL; <-- clear sc_node > > NG_NODE_SET_PRIVATE(node, NULL); > NG_NODE_REALLY_DIE(node); > > NG_NODE_REF(node); <--- grab +1 reference > ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > not free()d > } > > /* bla, bla */ > > if (node != NULL) > NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node Yes, but you are already dropping an extra reference in ubt_shutdown(). What about that? > so, say we enter detach() with only one reference (from attach()). > when we see the sc_node pointer, we assume that there could be > multiple (> 1) references on it. so just for added protection we grab > one more (now reference count is 2). then we call ng_rmnode_self() > which will mark node as "dead" and drop one reference (now reference > count is 1). then we do "bla bla" stuff which could access node > pointer. the important thing is that node pointer still points to a > valid "dead" node, so NG_NODE_NOT_VALID() can be used to check if node > is "dead" or "alive". finally when "bla bla" stuff is done, we know we > are not going to access node pointer any mode and we drop our > reference (now reference count is 0 and node is destroyed). > do you mean transfer stop on hook disconnection? but those are > protected by interface locks, no? and like i said, i'm changing > ubt_task to call drain() instead of stop() to make stop completely > synchronous (which is actually a nice thing). I think you misunderstand. I'm using mutexes. They will not block for very long! There are no DELAY()'s with mutexes held! When another USB device is attached / detached it is: 1) Done from another thread 2) The USB locks in the critical path are dropped when waiting for wakeup or doing so called synchronous stuff. > > it would be if we could sleep in netgraph, and we can not. Do mutexes sleep? No? So my code should be fine? > in theory, > we only need one extra reference which would tell us if there anything > in usb2 that still could access node pointer. in practice, instead of > checking every transfer and making sure its no pending before dropping > that extra reference i just add multiple references for each usb2 > transfer and ubt_task (i.e. things that could access node pointer). I'm just thinking that this is starting to get complicated, and please understand I've spent much time on detach issues, and there is alot of builtin funcionality inside USB which will handle start/stop/re-start issues automagically. I see it like duplicate code when you check for USB transfer re-start in netgraph ??? > > right, and what if some other usb device attached to the same usb > controller is doing something synchronously? do you see that you could > potentially block netgraph for arbitrary time and that is really out > of ng_ubt2 driver control? Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is called from High Priority threads! See explanation further up. And will not block very long at all. > > i beg to differ :) Ok, I think we are going somewhere! --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:38:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4D2106564A; Sat, 24 Jan 2009 09:38:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id A1CD78FC08; Sat, 24 Jan 2009 09:38:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5218919rvf.43 for ; Sat, 24 Jan 2009 01:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MxG9QEIHjVDAkQRgPehDFtPK3mdFX4nRfDvLBMx32Fc=; b=UEjNGeHUEX2CDREyBv76jqCErVejK2gOydYEjA7CYTjXKcF1sVa9u4m2LwJyeOvCLG 0okiRORXKQ8XlpL4HkB027/ZMJ+i6zuOlqvlYEZNoU8AcqgcuVa8bxfJ0HROhjVYF1d4 qtwyMq03rMQ1Q+iV1MfEhT+Ert6/uCd673DvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FpyjdDkiHBfjh0iEjCpAG6raydYXsh3Ocy4q/QozxDrM2gwM2+crdvkpElFhEmJW7n PchgoOSKKcfc6GAUfxJhddNSRvgrIyEVyQfFSHACQNJS3Tnf3vupTjJqjG1eBPy3sjsW YZPIwvGWec5SISFydgSjpdL7Bkii4Hm/Wz0fQ= MIME-Version: 1.0 Received: by 10.140.201.8 with SMTP id y8mr2783254rvf.101.1232789883201; Sat, 24 Jan 2009 01:38:03 -0800 (PST) In-Reply-To: <200901240952.21670.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> Date: Sat, 24 Jan 2009 01:38:03 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 09:38:04 -0000 Hans Petter, >> i'm sorry, did i mention there is no sleeping in netgraph? :-) >> >> again, sorry, but this is not going to work. you still doing >> UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to >> grab the same lock that is used for locking interfaces. > > Yes, you have to do that. Else you end up with a state nightmare with the > taskqueue where you don't know in the end if you should start or stop the USB > interface! exactly! >> more importantly, like i said before, usb2_transfer_stop() does >> USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb >> device will not do something synchronously over the same usb bus? > > Every time something is done synchronously the USB_BUS_LOCK() is dropped. This > mutex is only used when filling out DMA structures and when touching USB > hardware registers. I cannot see that this will take any time at all. We are > talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and > not a SX lock! A mutex cannot sleep in the same way an SX lock can. from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin locks). you are using regular mutexes. let me quote locking(9) man page " Mutexes Basically (regular) mutexes will deschedule the thread if the mutex can not be acquired. A non-spin mutex can be considered to be equivalent to getting a write lock on an rw_lock (see below), " so, if thread can not get mutex it will be descheduled. this absolutely can not happen in netgraph! >> > I have a question. What is the following doing at the middle of the >> > ubt_detach(): >> > >> > if (node != NULL) >> > NG_NODE_UNREF(node); >> > >> > If you say that: >> > >> > ng_rmnode_self(node); >> > >> > Cleans up the last reference? >> >> the complete code is >> >> node_p node = sc->sc_node; >> >> if (node != NULL) { >> sc->sc_node = NULL; <-- clear sc_node >> >> NG_NODE_SET_PRIVATE(node, NULL); >> NG_NODE_REALLY_DIE(node); >> >> NG_NODE_REF(node); <--- grab +1 reference >> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its >> not free()d >> } >> >> /* bla, bla */ >> >> if (node != NULL) >> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > Yes, but you are already dropping an extra reference in ubt_shutdown(). What > about that? shutdown method is called as part of ng_rmnode_self() and drop the reference that node was born with. the extra reference before ng_rmnode_self() is to ensure that node pointer is still valid after ng_rmnode_self() returns. otherwise there is a change that node pointer becomes invalid while after ng_rmnode_self() calls shutdown method. [...] > I think you misunderstand. I'm using mutexes. They will not block for very > long! There are no DELAY()'s with mutexes held! When another USB device is > attached / detached it is: > > 1) Done from another thread > 2) The USB locks in the critical path are dropped when waiting for wakeup or > doing so called synchronous stuff. >> >> it would be if we could sleep in netgraph, and we can not. > > Do mutexes sleep? No? So my code should be fine? yes, regular mutexes sleep. >> in theory, >> we only need one extra reference which would tell us if there anything >> in usb2 that still could access node pointer. in practice, instead of >> checking every transfer and making sure its no pending before dropping >> that extra reference i just add multiple references for each usb2 >> transfer and ubt_task (i.e. things that could access node pointer). > > I'm just thinking that this is starting to get complicated, and please > understand I've spent much time on detach issues, and there is alot of > builtin funcionality inside USB which will handle start/stop/re-start issues > automagically. I see it like duplicate code when you check for USB transfer > re-start in netgraph ??? first of all, i do not think crashes are caused by detach(). in fact, detach() is clean. i've tested it and it worked for me. i tried to start/stop device while doing flood l2ping. i also tried to yank the device while doing flood l2ping. it works correctly. i think, the issue is related to stalled transfers. there is still something wrong with the code path that deals with stalled transfers. stalls do not happen on my test box, so i can not test it. also there is NO code duplication. asynchronous path is required to decouple netgraph from usb2. >> right, and what if some other usb device attached to the same usb >> controller is doing something synchronously? do you see that you could >> potentially block netgraph for arbitrary time and that is really out >> of ng_ubt2 driver control? > > Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is > called from High Priority threads! See explanation further up. And will not > block very long at all. regular mutexes can sleep. we are not allowed to sleep in netgraph. therefor we must transition out of netgraph context before calling into any code that tries to grab regular mutex. the async design is there not because i want to make things complicated. its there because it is needed. thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:38:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4D2106564A; Sat, 24 Jan 2009 09:38:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id A1CD78FC08; Sat, 24 Jan 2009 09:38:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5218919rvf.43 for ; Sat, 24 Jan 2009 01:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MxG9QEIHjVDAkQRgPehDFtPK3mdFX4nRfDvLBMx32Fc=; b=UEjNGeHUEX2CDREyBv76jqCErVejK2gOydYEjA7CYTjXKcF1sVa9u4m2LwJyeOvCLG 0okiRORXKQ8XlpL4HkB027/ZMJ+i6zuOlqvlYEZNoU8AcqgcuVa8bxfJ0HROhjVYF1d4 qtwyMq03rMQ1Q+iV1MfEhT+Ert6/uCd673DvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FpyjdDkiHBfjh0iEjCpAG6raydYXsh3Ocy4q/QozxDrM2gwM2+crdvkpElFhEmJW7n PchgoOSKKcfc6GAUfxJhddNSRvgrIyEVyQfFSHACQNJS3Tnf3vupTjJqjG1eBPy3sjsW YZPIwvGWec5SISFydgSjpdL7Bkii4Hm/Wz0fQ= MIME-Version: 1.0 Received: by 10.140.201.8 with SMTP id y8mr2783254rvf.101.1232789883201; Sat, 24 Jan 2009 01:38:03 -0800 (PST) In-Reply-To: <200901240952.21670.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> Date: Sat, 24 Jan 2009 01:38:03 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 09:38:04 -0000 Hans Petter, >> i'm sorry, did i mention there is no sleeping in netgraph? :-) >> >> again, sorry, but this is not going to work. you still doing >> UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to >> grab the same lock that is used for locking interfaces. > > Yes, you have to do that. Else you end up with a state nightmare with the > taskqueue where you don't know in the end if you should start or stop the USB > interface! exactly! >> more importantly, like i said before, usb2_transfer_stop() does >> USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb >> device will not do something synchronously over the same usb bus? > > Every time something is done synchronously the USB_BUS_LOCK() is dropped. This > mutex is only used when filling out DMA structures and when touching USB > hardware registers. I cannot see that this will take any time at all. We are > talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and > not a SX lock! A mutex cannot sleep in the same way an SX lock can. from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin locks). you are using regular mutexes. let me quote locking(9) man page " Mutexes Basically (regular) mutexes will deschedule the thread if the mutex can not be acquired. A non-spin mutex can be considered to be equivalent to getting a write lock on an rw_lock (see below), " so, if thread can not get mutex it will be descheduled. this absolutely can not happen in netgraph! >> > I have a question. What is the following doing at the middle of the >> > ubt_detach(): >> > >> > if (node != NULL) >> > NG_NODE_UNREF(node); >> > >> > If you say that: >> > >> > ng_rmnode_self(node); >> > >> > Cleans up the last reference? >> >> the complete code is >> >> node_p node = sc->sc_node; >> >> if (node != NULL) { >> sc->sc_node = NULL; <-- clear sc_node >> >> NG_NODE_SET_PRIVATE(node, NULL); >> NG_NODE_REALLY_DIE(node); >> >> NG_NODE_REF(node); <--- grab +1 reference >> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its >> not free()d >> } >> >> /* bla, bla */ >> >> if (node != NULL) >> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > Yes, but you are already dropping an extra reference in ubt_shutdown(). What > about that? shutdown method is called as part of ng_rmnode_self() and drop the reference that node was born with. the extra reference before ng_rmnode_self() is to ensure that node pointer is still valid after ng_rmnode_self() returns. otherwise there is a change that node pointer becomes invalid while after ng_rmnode_self() calls shutdown method. [...] > I think you misunderstand. I'm using mutexes. They will not block for very > long! There are no DELAY()'s with mutexes held! When another USB device is > attached / detached it is: > > 1) Done from another thread > 2) The USB locks in the critical path are dropped when waiting for wakeup or > doing so called synchronous stuff. >> >> it would be if we could sleep in netgraph, and we can not. > > Do mutexes sleep? No? So my code should be fine? yes, regular mutexes sleep. >> in theory, >> we only need one extra reference which would tell us if there anything >> in usb2 that still could access node pointer. in practice, instead of >> checking every transfer and making sure its no pending before dropping >> that extra reference i just add multiple references for each usb2 >> transfer and ubt_task (i.e. things that could access node pointer). > > I'm just thinking that this is starting to get complicated, and please > understand I've spent much time on detach issues, and there is alot of > builtin funcionality inside USB which will handle start/stop/re-start issues > automagically. I see it like duplicate code when you check for USB transfer > re-start in netgraph ??? first of all, i do not think crashes are caused by detach(). in fact, detach() is clean. i've tested it and it worked for me. i tried to start/stop device while doing flood l2ping. i also tried to yank the device while doing flood l2ping. it works correctly. i think, the issue is related to stalled transfers. there is still something wrong with the code path that deals with stalled transfers. stalls do not happen on my test box, so i can not test it. also there is NO code duplication. asynchronous path is required to decouple netgraph from usb2. >> right, and what if some other usb device attached to the same usb >> controller is doing something synchronously? do you see that you could >> potentially block netgraph for arbitrary time and that is really out >> of ng_ubt2 driver control? > > Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is > called from High Priority threads! See explanation further up. And will not > block very long at all. regular mutexes can sleep. we are not allowed to sleep in netgraph. therefor we must transition out of netgraph context before calling into any code that tries to grab regular mutex. the async design is there not because i want to make things complicated. its there because it is needed. thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:52:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848F8106564A; Sat, 24 Jan 2009 09:52:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8CADC8FC27; Sat, 24 Jan 2009 09:52:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=w3uX68szt58dvCyVyYAA:9 a=2OVIdxriSsmP6dbp0kIA:7 a=KAdawnMWUfuzbm46TTQzYsL2H60A:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 442075885; Sat, 24 Jan 2009 10:52:55 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 10:55:18 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241055.20054.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 09:52:59 -0000 On Saturday 24 January 2009, Maksim Yevmenkin wrote: > Hans Petter, > > i'm sorry, did i mention there is no sleeping in netgraph? :-) Can you elaborate this? Is netgraph run from fast interrupt context? So that only spin locks are possible? Or is it run from a thread? > > from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin > locks). you are using regular mutexes. let me quote locking(9) man > page > > " > Mutexes > Basically (regular) mutexes will deschedule the thread if the mutex > can not be acquired. A non-spin mutex can be considered to be equivalent > to getting a write lock on an rw_lock (see below), > " > > so, if thread can not get mutex it will be descheduled. this > absolutely can not happen in netgraph! There are mutexes inside the taskqueue aswell. The problem will be the same there if you don't use a so-called fast tasqueue. > > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. Ok, I need to fix that. > > first of all, i do not think crashes are caused by detach(). in fact, > detach() is clean. i've tested it and it worked for me. i tried to > start/stop device while doing flood l2ping. i also tried to yank the > device while doing flood l2ping. it works correctly. i think, the > issue is related to stalled transfers. there is still something wrong > with the code path that deals with stalled transfers. stalls do not > happen on my test box, so i can not test it. also there is NO code > duplication. asynchronous path is required to decouple netgraph from > usb2. Only if netgraph is run from fast interrupt context. > regular mutexes can sleep. we are not allowed to sleep in netgraph. > therefor we must transition out of netgraph context before calling > into any code that tries to grab regular mutex. the async design is > there not because i want to make things complicated. its there because > it is needed. I think there are two definitions of sleeping. 1) When a thread is waiting for a mutex it is not sleeping in the same way like if it was to call "tsleep()". 2) When a thread is waiting for a wakeup it is surely sleeping, which can happen inside sx_lock() and tsleep(). --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:52:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848F8106564A; Sat, 24 Jan 2009 09:52:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8CADC8FC27; Sat, 24 Jan 2009 09:52:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=w3uX68szt58dvCyVyYAA:9 a=2OVIdxriSsmP6dbp0kIA:7 a=KAdawnMWUfuzbm46TTQzYsL2H60A:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 442075885; Sat, 24 Jan 2009 10:52:55 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 10:55:18 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241055.20054.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 09:52:59 -0000 On Saturday 24 January 2009, Maksim Yevmenkin wrote: > Hans Petter, > > i'm sorry, did i mention there is no sleeping in netgraph? :-) Can you elaborate this? Is netgraph run from fast interrupt context? So that only spin locks are possible? Or is it run from a thread? > > from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin > locks). you are using regular mutexes. let me quote locking(9) man > page > > " > Mutexes > Basically (regular) mutexes will deschedule the thread if the mutex > can not be acquired. A non-spin mutex can be considered to be equivalent > to getting a write lock on an rw_lock (see below), > " > > so, if thread can not get mutex it will be descheduled. this > absolutely can not happen in netgraph! There are mutexes inside the taskqueue aswell. The problem will be the same there if you don't use a so-called fast tasqueue. > > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. Ok, I need to fix that. > > first of all, i do not think crashes are caused by detach(). in fact, > detach() is clean. i've tested it and it worked for me. i tried to > start/stop device while doing flood l2ping. i also tried to yank the > device while doing flood l2ping. it works correctly. i think, the > issue is related to stalled transfers. there is still something wrong > with the code path that deals with stalled transfers. stalls do not > happen on my test box, so i can not test it. also there is NO code > duplication. asynchronous path is required to decouple netgraph from > usb2. Only if netgraph is run from fast interrupt context. > regular mutexes can sleep. we are not allowed to sleep in netgraph. > therefor we must transition out of netgraph context before calling > into any code that tries to grab regular mutex. the async design is > there not because i want to make things complicated. its there because > it is needed. I think there are two definitions of sleeping. 1) When a thread is waiting for a mutex it is not sleeping in the same way like if it was to call "tsleep()". 2) When a thread is waiting for a wakeup it is surely sleeping, which can happen inside sx_lock() and tsleep(). --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 10:18:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886831065686; Sat, 24 Jan 2009 10:18:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id B41E98FC13; Sat, 24 Jan 2009 10:18:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=mdiO7SZdCJiK1SL9sm0A:9 a=kvW1Cs6bN2n2dYFjjsYA:7 a=dr3kDhPgbP65kStAx--lJPdw-NAA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1185899451; Sat, 24 Jan 2009 11:18:25 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 11:20:43 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241120.46889.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 10:18:28 -0000 Hi Maksim, On Saturday 24 January 2009, Maksim Yevmenkin wrote: > >> > I have a question. What is the following doing at the middle of the > >> > ubt_detach(): > >> > > >> > if (node != NULL) > >> > NG_NODE_UNREF(node); > >> > > >> > If you say that: > >> > > >> > ng_rmnode_self(node); > >> > > >> > Cleans up the last reference? > >> > >> the complete code is > >> > >> node_p node = sc->sc_node; > >> > >> if (node != NULL) { > >> sc->sc_node = NULL; <-- clear sc_node > >> > >> NG_NODE_SET_PRIVATE(node, NULL); > >> NG_NODE_REALLY_DIE(node); > >> > >> NG_NODE_REF(node); <--- grab +1 reference > >> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > >> not free()d > >> } > >> > >> /* bla, bla */ > >> > >> if (node != NULL) > >> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > > > Yes, but you are already dropping an extra reference in ubt_shutdown(). > > What about that? > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. I've now explicitly tested this and found that if I drop the node reference in shutdown I end up with a zero node reference in detach! So the NG_NODE_UNREF() should not be in the ubt_shutdown !!! This is maybe the reason why Lars was getting a panic! http://perforce.freebsd.org/chv.cgi?CH=156600 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 10:18:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886831065686; Sat, 24 Jan 2009 10:18:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id B41E98FC13; Sat, 24 Jan 2009 10:18:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=6I5d2MoRAAAA:8 a=mdiO7SZdCJiK1SL9sm0A:9 a=kvW1Cs6bN2n2dYFjjsYA:7 a=dr3kDhPgbP65kStAx--lJPdw-NAA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1185899451; Sat, 24 Jan 2009 11:18:25 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 11:20:43 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241120.46889.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 10:18:28 -0000 Hi Maksim, On Saturday 24 January 2009, Maksim Yevmenkin wrote: > >> > I have a question. What is the following doing at the middle of the > >> > ubt_detach(): > >> > > >> > if (node != NULL) > >> > NG_NODE_UNREF(node); > >> > > >> > If you say that: > >> > > >> > ng_rmnode_self(node); > >> > > >> > Cleans up the last reference? > >> > >> the complete code is > >> > >> node_p node = sc->sc_node; > >> > >> if (node != NULL) { > >> sc->sc_node = NULL; <-- clear sc_node > >> > >> NG_NODE_SET_PRIVATE(node, NULL); > >> NG_NODE_REALLY_DIE(node); > >> > >> NG_NODE_REF(node); <--- grab +1 reference > >> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its > >> not free()d > >> } > >> > >> /* bla, bla */ > >> > >> if (node != NULL) > >> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node > > > > Yes, but you are already dropping an extra reference in ubt_shutdown(). > > What about that? > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. I've now explicitly tested this and found that if I drop the node reference in shutdown I end up with a zero node reference in detach! So the NG_NODE_UNREF() should not be in the ubt_shutdown !!! This is maybe the reason why Lars was getting a panic! http://perforce.freebsd.org/chv.cgi?CH=156600 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 11:38:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B01CD106564A for ; Sat, 24 Jan 2009 11:38:10 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1088FC13 for ; Sat, 24 Jan 2009 11:38:10 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 7D7723A6A4; Sat, 24 Jan 2009 12:38:09 +0100 (CET) Date: Sat, 24 Jan 2009 12:38:09 +0100 From: Lars Engels To: Maksim Yevmenkin Message-ID: <20090124113809.GV60948@e.0x20.net> References: <20090123212952.GM60948@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5xr6Gr0irOxp3+3c" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] for ng_ubt2 stalled transfers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 11:38:11 -0000 --5xr6Gr0irOxp3+3c Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 03:21:21PM -0800, Maksim Yevmenkin wrote: > > Thanks for the quick patch, but that did not help: > > > > ubt0: on usbus2 > > ubt0:ubt_bulk_read_callback:981: bulk-in transfer failed: USB_ERR_STALL= ED > > ubt0:ubt_intr_read_callback:834: interrupt transfer failed: USB_ERR_STA= LLED >=20 > stalled transfers are NOT going to be fixed. the patch was to make > sure the system would not crash with stalled transfers. Yes, that's working now. Thanks. BTW what are stalled transfers and does that do any harm? > > I also have another usb bluetooth stick which shows this on insertion: > > > > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1401: set address 2 fa= iled (ignored) > > Jan 23 22:13:00 maggie kernel: usb2_alloc_device:1436: getting device d= escriptor at addr 2 failed! >=20 > this is something else. this happens earlier than usb2_bluetooth_ng Okay... >=20 > > Jan 23 22:13:01 maggie kernel: ugen0.2: at us= bus0 > > Jan 23 22:13:01 maggie kernel: ubt1: on usbus0 >=20 > that looks normal to me. Yup, it's working now with hccontrol -n ubt0hci inquiry --5xr6Gr0irOxp3+3c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl6/aEACgkQKc512sD3afjuYACeIj6B31mx+HJUHneEyYM5p9bD kTIAoITKc92boXASkleASuvCj03h1d5N =TlLD -----END PGP SIGNATURE----- --5xr6Gr0irOxp3+3c-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 14:25:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4269E106566B for ; Sat, 24 Jan 2009 14:25:28 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCF18FC16 for ; Sat, 24 Jan 2009 14:25:27 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.147.234] (port=17229 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LQjRu-0009OD-6W for freebsd-current@FreeBSD.org; Sat, 24 Jan 2009 17:25:26 +0300 Message-ID: <497B24D5.3010200@lissyara.su> Date: Sat, 24 Jan 2009 17:25:25 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.19) Gecko/20090110 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <497A159B.5050404@lissyara.su> In-Reply-To: <497A159B.5050404@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Re: acpi_throttle1: failed to attach P_CNT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 14:25:28 -0000 Alex Keda пишет: > After last update I have in dmesg > > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > > When I build somesing - laptop shutdown, because CPU temp > 105 Celsius > > HP# uname -a > FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Jan 22 > 19:49:57 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/HP amd64 > HP# HP$ dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sat Jan 24 16:14:52 MSK 2009 lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/HP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (1994.95-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 1996177408 (1903 MB) avail memory = 1927643136 (1838 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ 8800] [ 0 8100], using 64X [20070320] ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, 8000000 (3) failed acpi0: reservation of 100000, fff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x4000-0x40ff mem 0xc0000000-0xc7ffffff,0xd0200000-0xd020ffff,0xd0300000-0xd03fffff irq 19 at device 5.0 on pci1 acpi_video0: on vgapci0 pcib2: at device 4.0 on pci0 pci16: on pcib2 bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bge0: Ethernet address: 00:1f:29:89:38:f3 bge0: [ITHREAD] pcib3: at device 5.0 on pci0 pci32: on pcib3 pcib4: at device 6.0 on pci0 pci48: on pcib4 pci48: at device 0.0 (no driver attached) atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci0 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci0 ata5: port not implemented ata5: [ITHREAD] ohci0: mem 0xd0401000-0xd0401fff irq 23 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xd0402000-0xd0402fff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xd0403000-0xd0403fff irq 17 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xd0404000-0xd0404fff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xd0405000-0xd0405fff irq 17 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0406000-0xd04060ff irq 23 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090113_0125 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci2: on pcib5 cbb0: mem 0xd0100000-0xd0100fff irq 20 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x73 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 orm0: at iomem 0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ugen0: on uhub0 ums0: on uhub1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec cpufreq0: rejecting change, SMP not started yet acpi_tz0: failed to set new freq, disabling passive cooling acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master SATA300 hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: at cad 0 nid 1 on hdac0 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a lock order reversal: 1st 0xffffff0002320070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff00029587f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2071 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled lock order reversal: 1st 0xfffffffe66c95e50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xffffff00029dc800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x181 ufs_remove() at ufs_remove+0x92 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x249 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (10, FreeBSD ELF64, unlink), rip = 0x8007176ac, rsp = 0x7fffffffe468, rbp = 0x7fffffffef76 --- lock order reversal: 1st 0xffffff0005944448 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1047 2nd 0xffffff0005cc2098 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2071 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b devfs_allocv() at devfs_allocv+0x10c devfs_root() at devfs_root+0x52 vfs_donmount() at vfs_donmount+0x1106 nmount() at nmount+0xa6 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007a5cdc, rsp = 0x7fffffffdda8, rbp = 0x800a04048 --- WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() lock order reversal: 1st 0xffffff0002b8d4d8 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff0005419270 tmpfs (tmpfs) @ /usr/src/sys/kern/vfs_subr.c:2071 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x401705, rsp = 0x7fffffffeb80, rbp = 0x80106c000 --- fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading RS690/RS740 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] lock order reversal: 1st 0xffffff0005daec48 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xffffff00055e0270 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4057 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 knlist_remove_kq() at knlist_remove_kq+0x73 knote_fdclose() at knote_fdclose+0x177 kern_close() at kern_close+0xe6 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (6, FreeBSD ELF64, close), rip = 0x80108bc2c, rsp = 0x7fffffffe6c8, rbp = 0x802563840 --- HP$ From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 14:43:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 447751065679 for ; Sat, 24 Jan 2009 14:43:48 +0000 (UTC) (envelope-from cdk1@bsd.cl) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 277028FC0A for ; Sat, 24 Jan 2009 14:43:48 +0000 (UTC) (envelope-from cdk1@bsd.cl) Received: by wa-out-1112.google.com with SMTP id k34so184885wah.27 for ; Sat, 24 Jan 2009 06:43:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.182.1 with SMTP id e1mr497805waf.163.1232806453506; Sat, 24 Jan 2009 06:14:13 -0800 (PST) Date: Sat, 24 Jan 2009 11:14:13 -0300 Message-ID: From: Carlos Corona To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Prblem whit USB in FreeBSD 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 14:43:48 -0000 Hi * I'm running FreeBSD 8 i386 on my machine X2 AMD Athlon 64, I have devices such as USB keyboard and mouse, which works perfectly, but as to the pendrive, I had some problems when I connect my pendrive Fujitel for 1GB recognizes this, but will not let me do anything, I can open applications, etc. loggin a console, I managed to do the dmesg when connecting: (da0: UMass-sim0: 0:0:0): lost device (da0: UMass-sim0: 0:0:0): Synchronize cache failed, status == 0x39, scsi status == 0x0 (da0: UMass-sim0: 0:0:0): removing device entry GEOM_LABEL: Label msdosfs / [you: Qiufo] removed. umass0: detached Can onlydisconnect hold back my system, any thoughts on this? thanks in advance -- Carlos Corona CdK1 BSD Chile http://www.bsd.cl From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 15:35:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E633B106566C for ; Sat, 24 Jan 2009 15:35:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7C53D8FC22 for ; Sat, 24 Jan 2009 15:35:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=neEVqQTEdNsA:10 a=6I5d2MoRAAAA:8 a=E19gfujHKhs_ZpDzFHwA:9 a=iAPsMpTBKfDEp-iFg_zStWNXLwgA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 134476272; Sat, 24 Jan 2009 16:35:55 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 16:38:17 +0100 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241638.18591.hselasky@c2i.net> Cc: Carlos Corona Subject: Re: Prblem whit USB in FreeBSD 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 15:35:58 -0000 On Saturday 24 January 2009, Carlos Corona wrote: > Hi * > > I'm running FreeBSD 8 i386 on my machine X2 AMD Athlon 64, I have devices > such as USB keyboard and mouse, which works perfectly, but as to the > pendrive, I had some problems when I connect my pendrive Fujitel for 1GB > recognizes this, but will not let me do anything, I can open applications, > etc. loggin a console, I managed to do the dmesg when connecting: > > (da0: UMass-sim0: 0:0:0): lost device > (da0: UMass-sim0: 0:0:0): Synchronize cache failed, status == 0x39, scsi > status == 0x0 > (da0: UMass-sim0: 0:0:0): removing device entry > GEOM_LABEL: Label msdosfs / [you: Qiufo] removed. > umass0: detached > > Can onlydisconnect hold back my system, any thoughts on this? thanks in > advance Hi, Most likely The firmware on your pendrive is not fully SCSI compliant. Read: http://wiki.freebsd.org/USB and the section about adding an USB Mass Storage Quirk. You need to add something like this to "sys/dev/usb2/storage/umass2.c" : {USB_VENDOR_MEIZU, USB_PRODUCT_MEIZU_M6_SL, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_INQUIRY | NO_SYNCHRONIZE_CACHE }, --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:01:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049411065672; Sat, 24 Jan 2009 16:01:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-77-65.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D9FF78FC1D; Sat, 24 Jan 2009 16:01:05 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <497B3B40.3040306@FreeBSD.org> Date: Sat, 24 Jan 2009 16:01:04 +0000 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: obrien@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Noisy make -j output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 16:01:07 -0000 After a fresh buildworld on a system last built in November: hydra2# make buildworld -j8 -s --- upgrade_checks --- --- make --- -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- --- buildworld --- --- buildworld_prologue --- -------------------------------------------------------------- >>> World build started on Sat Jan 24 15:59:14 UTC 2009 -------------------------------------------------------------- --- _worldtmp --- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- [...] Why the extra-spammy output now? Kris From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:09:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96562106564A for ; Sat, 24 Jan 2009 16:09:39 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id BE1F78FC14 for ; Sat, 24 Jan 2009 16:09:38 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fxm4 with SMTP id 4so1506149fxm.19 for ; Sat, 24 Jan 2009 08:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tzQXvNJ/TUe/wbx728/K/LIB+NlMdu9iro3Kc9+v/0I=; b=LrMG08KKVdYT5PgifwRU4zBpiDOWfkgEESHqTA+MAm6N9liXIVO4lfJVzUwVw0K5WR G+h02Fd2xatuZirXlqvu0FYOrxRsvsBi8UYGSR77xn1mSvH5fvoiAT1ondyLHd9VDtsC gsqk9RpaHPuCEVdvDhtWyY8DoTUbe26tEKmVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IT27RFRRw4Tcx02FhTlfp5P4aX0spz971Vr3Hk9QQwMTk8g3rnA/1pGkZSfsnkjvxH RW28resn8UFB3ya1KPKo+XhHesXYsMlHfM12471b/iqIVxKXlrAycH+iQtUSj0/EpLam VRKCqf8ltbeLLuxEGMP1iwL3cy+j4RItmIrtc= MIME-Version: 1.0 Received: by 10.103.173.15 with SMTP id a15mr1638183mup.59.1232812150643; Sat, 24 Jan 2009 07:49:10 -0800 (PST) In-Reply-To: References: Date: Sat, 24 Jan 2009 16:49:10 +0100 Message-ID: <6101e8c40901240749h106916adya7d6a8caee4ed155@mail.gmail.com> From: Oliver Pinter To: Scott Gasch Content-Type: multipart/mixed; boundary=001636417647505c1504613c7279 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Problems with ata driver on current / Asus P5Q-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 16:09:40 -0000 --001636417647505c1504613c7279 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have the same MB, and it running perfect, but I have only 3 SATA HDD + 1 SATA DVD-RW The ICH is in RAID mode. Attached my conf and dmesg Which version of BIOS use You? [snip] Southbridge - 6 x SATA 3Gb/s - Intel(R) Matrix Storage Technology with RAID 0, 1, 5, 10 support Marvell 88SE6121 - 1 x UltraDMA 133/100/66 for up to 2 PATA devices - 1 x External SATA 3Gb/s port (SATA On-the-Go) Silicon Image Sil5723 (Drive Xpert technology) - 2 x SATA 3Gb/s - Supports EZ Backup and Super Speed functions [snip] http://www.asus.com/products.aspx?l1=3&l2=11&l3=709&l4=0&model=2267&modelmenu=2 /* sorry for bad english */ On 1/24/09, Scott Gasch wrote: > Hi, > I've been running a 7.1-p1 (amd64) system and and seeing very high interrupt > rates on irq19 which is shared between several devices. Over 60% of one > core is used responding to interrupts. The machine also hangs frequently. > irq19 is shared by atapci1, atapci2, fwohci0 and uhci4... > the consensus response to my last question was that "it's probably the ata > driver". > > Today I tried building and booting a GENERIC current kernel and got another > piece of information. The freebsd-current GENERIC kernel does not boot; > shortly after probing the drives it says "Cannot setup DMA" several times on > the console and hangs. > > This machine is an Asus P5Q-E... I believe it has two ATA controllers: > a Marvell > 88SE6121 and a Silicon Image SIL5723. Is one of these chipsets generating > interrupts that the driver doesn't understand and/or properly dismiss? Can > it be put into a legacy mode that works? This machine has problems in 7.0, > 7.1 and current... I'm running out of ideas. > > Thx, > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > --001636417647505c1504613c7279-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:45:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20BE106564A for ; Sat, 24 Jan 2009 16:45:08 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id B6E228FC13 for ; Sat, 24 Jan 2009 16:45:08 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so204158wah.27 for ; Sat, 24 Jan 2009 08:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wBI5rCUbH2ckoggdfZKn4NsbhWfkrdUKMZtc5/iIzEI=; b=SIF0DvD+3eREe8my8FOc4Ams63CdpDpN/8P27nrGY02iXAMct4Wxel4vBf+WgK4Lw1 jYP7jPPnHqO2lWZoX8hYzlnackY5ZQjGaUDvpPkvp6mc08Ybhqi3OVZ0iYuFkwzBbBuy 4ls3oY+90UEHV9jDS/ECG9K7MeuQoJlsOXVEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lxtqtp/di7GQtkh+A3qFkQj2vk2wSZYiEtKP1/PKFeougSRv1RfUdbuexHvyRPC/zW 0cIAr213E2o+pQqS9O0ySVZpfMktmfKfTtFGX3dXhQLq8N9VooxPfxk5DUQxpz7QUbsM v+yAcmSklxSugaFFHw/YbXohVjitSDToTc0dk= MIME-Version: 1.0 Received: by 10.114.25.19 with SMTP id 19mr3270252way.89.1232813870132; Sat, 24 Jan 2009 08:17:50 -0800 (PST) In-Reply-To: <01N4NEOEB7LY00EQWX@tmk.com> References: <01N4NEOEB7LY00EQWX@tmk.com> Date: Sat, 24 Jan 2009 08:17:50 -0800 Message-ID: From: Freddie Cash To: Terry Kennedy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Help me select hardware and software options for very large server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 16:45:09 -0000 On Fri, Jan 23, 2009 at 6:30 PM, Terry Kennedy wrote: > I'm in the process of planning the hardware and software for the second > generation of my RAIDzilla file servers (see http://www.tmk.com/raidzilla > for the current generation, in production for 4+ years). > > I expect that what I'm planning is probably "off the scale" in terms of > processing and storage capacity, and I'd like to find out and address any > issues before spending lots of money. Here's what I'm thinking of: > > o Chassis - CI Design SR316 (same model as current chassis, except i2c link > between RAID controller and front panel > o Motherboard - Intel S5000PSLSATAR > o CPU - 2x Intel Xeon E5450 BX80574E5450P > p Remote management - Intel Remote Management Module 2 - AXXRM2 > o Memory - 16GB - 8x Kingston KVR667D2D4F5/2GI > o RAID controller - 3Ware 9650SE-16ML w/ BBU-MODULE-04 > o Drives - 16x 2TB drives [not mentioning manufacturer yet] > o Cables - 4x multi-lane SATA cables > o DVD-ROM drive > o Auxiliary slot fan next to BBU card > o Adaptec AHA-39160 (for Quantum Superloader 3 tape drive) > > So much for the hardware. On the software front: > > o FreeBSD 8.x? > o amd64 architecture > o MBR+UFS2 for operating system partitions (hard partition in controller) > o GPT+ZFS for data partitions > o Multiple 8TB data partitions (separate 8TB controller partitions or one > big partition divided with GPT?) We did something similar for our off-site, automated backups box. Hardware (2 identical boxes): - Chenbro 5U chassis with 24 hot-swap drive bays - 1350 W 4-way redundant PSU - Tyan h2000M motherboard - 2x Opteron 2200-series CPUs (dual-core) @ 2.8 GHz - 8 GB DDR2-800 SDRAM - 3Ware 9650SE-12ML PCIe RAID controller - 3Ware 9550SX-12ML PCI-X RAID controller - 12x Seagate Barracude 7200.11 500 GB SATA drives - 12x WD 500 GB SATA drives - Intel Pro/1000MT 4-port gigabit NIC One box has 2x 2 GB CompactFlash in IDE adapters, the other has 2x 2 GB USB flash drives. Software: - 64-bit FreeBSD 7.1-RELEASE (started with 7.1-STABLE from August 08) - UFS for / partition, using gmirror across the two CF/USB drives - ZFS for everything else - uses rsync and ssh to backup 83 remote servers everynight, creating ZFS snapshots every night - uses rsync to transfer "snapshots" between the two servers The drives on each of the RAID controllers are configured as "Single Disk Array", so they appear as 24 separate drives to the OS, but still benefit from the controller's disk cache, management interface, and so on (as compared to JBOD where it acts like nothing more than a SATA controller). The drives on one box are configured as 1 large 24-drive raidz2 in ZFS (this box also has 12x 400 GB drives). The drives on the other box are configured as 2 separate 11-drive raidz2 arrays, with 2 hot spares. The usable space on box boxes is 9 TB. I'm experimenting with different ways to allocated the drives in ZFS, to get the best performance. The recommendations of the Solaris folks seems to be to use raidz arrays of fewer than 10 disks. Depending on the cost, for the next storage box, I may use 3x 3Ware 9550SX RAID controllers and use 3x raidz2 arrays of 8 disks each, to see how that compares. Other than a bit of kernel tuning back in August/September, these boxes have been running nice and smooth. Just waiting for either the release of FreeBSD 8.0 or an MFC of ZFS v13 to 7-STABLE to get support for auto-rebuild using hot spares. Also waiting for a pair of CF-to-SATA controllers to come in so that I can remove the USB flash drives from the one box. They're just too unreliable in my testing. The CF-to-IDE adapters work really well, but there's only a single IDE controller on the motherboard, so it's doing gmirror across master and slave devices on the same controller, which isn't the fastest way of doing things. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:47:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7974D1065686 for ; Sat, 24 Jan 2009 16:47:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id DA9EB8FC08 for ; Sat, 24 Jan 2009 16:47:19 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy14 with SMTP id 14so67168ewy.19 for ; Sat, 24 Jan 2009 08:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zizYIF0R8KCkAiD/wNqIxt4BKPuW4tXlI3qmB/b2jW8=; b=kh8cgzX8eW4iYCsLXRHsDi04Qfd3Lgjy0Kp/WUdBCnazoqbBeV34ywAA8TaW5MtZk9 gNXcrl0AVGDgLGOWBV5tQOyeLMaqAxlammTYs92mLB5Wc2CsIaXWxqGbdnFY3W3KO4aD XfHZG6fCf0nxczGJe5eFqjgN3N2KJQpzTgtQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SmNQT1Te/yX3YVNi6PacbCV/0hdWNyJqDVQ28NWF6/GoXcrXwn+YpiUpK1KvQ31MFb G5E7WwkClU5zI3PKJIaydn97CAsXChYicH+0lyj14q2P0gWa/mZo+DW8nEndgBINqd2E W5RXw6Boo76pveA7wWBOxmTG8t0IWG8DEoAzs= MIME-Version: 1.0 Received: by 10.210.87.19 with SMTP id k19mr2935716ebb.152.1232815639004; Sat, 24 Jan 2009 08:47:19 -0800 (PST) In-Reply-To: <497B24D5.3010200@lissyara.su> References: <497A159B.5050404@lissyara.su> <497B24D5.3010200@lissyara.su> Date: Sat, 24 Jan 2009 17:47:18 +0100 Message-ID: <3a142e750901240847o652c581erd1fe90c776824fbe@mail.gmail.com> From: "Paul B. Mahol" To: Alex Keda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: acpi_throttle1: failed to attach P_CNT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 16:47:20 -0000 On 1/24/09, Alex Keda wrote: > Alex Keda pishet: >> After last update I have in dmesg >> >> acpi_throttle1: on cpu1 >> acpi_throttle1: failed to attach P_CNT >> device_attach: acpi_throttle1 attach returned 6 >> >> When I build somesing - laptop shutdown, because CPU temp > 105 Celsius >> >> HP# uname -a >> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Jan 22 >> 19:49:57 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/HP amd64 >> HP# > > HP$ dmesg .... I get this one: GEOM: ad0s1: geometry does not match label (15h,63s != 16h,63s). Trying to mount root from ufs:/dev/ad0s1a ACPI Exception (utmutex-0376): AE_TIME, Thread 186B0 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] ACPI Exception (utmutex-0376): AE_TIME, Thread 186B0 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] The problem is it doesnt happens always, but with soft reset there is (perceived) bigger chance to happen. Also kernel without WITNESS and other debug options have much bigger chance for this error to happen. -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 17:40:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 695B3106566B for ; Sat, 24 Jan 2009 17:40:05 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 019548FC12 for ; Sat, 24 Jan 2009 17:40:04 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n0OHIfRc007385; Sat, 24 Jan 2009 17:18:41 GMT (envelope-from rb@gid.co.uk) Received: from rbPBP.gid.co.uk ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n0OHIZBR080271; Sat, 24 Jan 2009 17:18:35 GMT (envelope-from rb@gid.co.uk) Message-Id: <74082E20-648A-4B60-AB09-E89CAF0BBB2E@gid.co.uk> From: Bob Bishop To: Terry Kennedy In-Reply-To: <01N4NEOEB7LY00EQWX@tmk.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 24 Jan 2009 17:18:35 +0000 References: <01N4NEOEB7LY00EQWX@tmk.com> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Help me select hardware and software options for very large server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 17:40:05 -0000 Hi, On 24 Jan 2009, at 02:30, Terry Kennedy wrote: > [...] > o Motherboard - Intel S5000PSLSATAR > o CPU - 2x Intel Xeon E5450 BX80574E5450P We're using plenty of the closely related S5000PAL m/b with various Xeons and we're very happy with them. > p Remote management - Intel Remote Management Module 2 - AXXRM2 We tried this and decided it's not worth having (vs the piggybacked IPMI on that m/b). We found that RMM's power control sometimes doesn't work (usually when you need it!). Also it's very tricky indeed to use down an ssh tunnel. OTOH if you need the remote device functionality there's not really any alternative. Can't comment to the rest of your list, except that ZFS is definitely the way to go. -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 17:51:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D86431065670 for ; Sat, 24 Jan 2009 17:51:43 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5EFB58FC08 for ; Sat, 24 Jan 2009 17:51:43 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 280F8A0726; Sat, 24 Jan 2009 18:51:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1C957A0724; Sat, 24 Jan 2009 18:51:42 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 09A43A0712; Sat, 24 Jan 2009 18:51:42 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009012418514150-20605 ; Sat, 24 Jan 2009 18:51:41 +0100 Received: by wep4035 (sSMTP sendmail emulation); Sat, 24 Jan 2009 18:51:41 +0100 From: "Alexey Shuvaev" Date: Sat, 24 Jan 2009 18:51:41 +0100 To: John Baldwin Message-ID: <20090124175141.GA1583@wep4035.physik.uni-wuerzburg.de> References: <200811191503.02192.jhb@freebsd.org> <4937EC6D.7050703@FreeBSD.org> <200901211536.08297.jhb@freebsd.org> MIME-Version: 1.0 In-Reply-To: <200901211536.08297.jhb@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 01/24/2009 06:51:41 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 01/24/2009 06:51:41 PM, Serialize complete at 01/24/2009 06:51:41 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: current@freebsd.org Subject: Re: ppc hints ignored? Was: [PATCH] ppbus/ppc locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 17:51:44 -0000 John Baldwin wrote: > Please test! This is the last non-MPSAFE network driver at this point. > this patch adds locking for the ppbus(4)/ppc(4) devices and the various ppbus > child devices (lpt, vpo, lpbb, ppi, pps). The basic model is that a single > mutex in the ppc(4) driver protects the ppc0 hardware and is shared with the > various child drivers. Two drivers now have detach methods that did not have > them before (plip and ppi). I've done some simple testing on my laptop (able > to load the drivers and do some simple things w/o panic'ing or tripping > assertions), but I am not really able to test the peripheral drivers fully. > > http://www.FreeBSD.org/~jhb/patches/ppc_locking.patch > Hello! I have also got panic around PPC_ASSERT_LOCKED(ppc) in ppc.c:1983 (cvsup-ed at app. Sat Jan 24 16:30 UTC 2009) What I noticed is that having: hint.ppc.0.at="isa" hint.ppc.0.disabled="1" hint.ppc.0.irq="7" does not prevent ppc from attaching. Rebooted with old kernel: FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jan 14 22:02:23 CET 2009 root@wep4035:/usr/obj/usr/src/sys/NOUSB amd64 and it also attached ppc despite the line in device.hints. Looks like not a ppc fault. ??? Alexey. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 18:43:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C531065670; Sat, 24 Jan 2009 18:43:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAE18FC20; Sat, 24 Jan 2009 18:43:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5351174rvf.43 for ; Sat, 24 Jan 2009 10:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EFuadXZN4hrA8k7cZE3kZcrgmqW1Ibv3mRkyblI6IgU=; b=LsefckPb934DHhspJg6f4xRUoRYz/ZQjMUPGdPK4EA2h7Y7J2+xvAgO8ert4rYsbgp dtgMM82rR1anD6WaviBgqcJLMN11Ug1xbTjdly3oSHf1Tz1PPmwIxop8A5eyLnrsuBJG ZcAuO7iJXNdbbCcKJBcPTc1Z0b38BbTiw8hlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KxWL0GcuPkF0nP7mjPABByCYFd8bzrfOAjVXKZqG4v4UupYbKx5d8HTXNr0GCLU7sL pMHzmInT7fGQ6HUevMZ2I2c4cNoEODVdUVQt5M3CSXph01Nj3FwO+s7ttO3l1bQLjeve pi1z0NCaMDcoee7XvN/Pbx1fneOwaS0LdZcAY= MIME-Version: 1.0 Received: by 10.140.162.21 with SMTP id k21mr529570rve.256.1232822592133; Sat, 24 Jan 2009 10:43:12 -0800 (PST) In-Reply-To: <200901241055.20054.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> Date: Sat, 24 Jan 2009 10:43:12 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 18:43:13 -0000 On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky wrote: > On Saturday 24 January 2009, Maksim Yevmenkin wrote: >> Hans Petter, >> >> i'm sorry, did i mention there is no sleeping in netgraph? :-) > > Can you elaborate this? Is netgraph run from fast interrupt context? So that > only spin locks are possible? Or is it run from a thread? i already told you that netgraph is essentially single-threaded. for all intents and purposes think that only _ONE_ thread services _ALL_ netgraph nodes. if something can not be done immediately, netgraph queues it and returns back to it later. _ANY_ delay/sleep would stall _ENTIRE_ netgraph. think poll/select/callback driven programming model. >> from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin >> locks). you are using regular mutexes. let me quote locking(9) man >> page >> >> " >> Mutexes >> Basically (regular) mutexes will deschedule the thread if the mutex >> can not be acquired. A non-spin mutex can be considered to be equivalent >> to getting a write lock on an rw_lock (see below), >> " >> >> so, if thread can not get mutex it will be descheduled. this >> absolutely can not happen in netgraph! > > There are mutexes inside the taskqueue aswell. The problem will be the same > there if you don't use a so-called fast tasqueue. well, yes. technically, its not 100% correct, but it has to be like it because there is simply no way around this. if you read the blob at the top of the ng_ubt2.c you know that it uses regular sc_mbufq_mtx (which can sleep). let me quote the blob here again " Access to the outgoing queues and task flags is controlled by the sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should really be a spin lock." the sc_mbufq_mtx is _NOT_ marked as SPIN mutex only because WITNESS has to know about spin locks. it is generally NOT a good idea to add a spin lock when someone feels like it. now back to taskqueue_enqueue(), yes, taskqueue_enqueue_fast() is more appropriate here. however, taskqueue_enqueue() was chosen because taskqueue_enqueue() does not do anything that could cause sleep in TQ_LOCK()/TQ_UNLOCK() (its just basically a lookup). from taskqueue man page "Enqueueing a task does not perform any memory allocation which makes it suitable for calling from an interrupt handler." USB_BUS_LOCK()/USB_BUS_UNLOCK() are different is this regard because those locks used when usb2 does things with hardware. also, like i said, there could be few usb devices sharing the same bus and thus the same USB_BUS_LOCK. once again the rule is: NO SLEEPING/STALLING IN NETGRAPH. it DOES NOT mean that you can not use mutexes. it only means that you have to be very careful of how the mutex is used. >> first of all, i do not think crashes are caused by detach(). in fact, >> detach() is clean. i've tested it and it worked for me. i tried to >> start/stop device while doing flood l2ping. i also tried to yank the >> device while doing flood l2ping. it works correctly. i think, the >> issue is related to stalled transfers. there is still something wrong >> with the code path that deals with stalled transfers. stalls do not >> happen on my test box, so i can not test it. also there is NO code >> duplication. asynchronous path is required to decouple netgraph from >> usb2. > > Only if netgraph is run from fast interrupt context. no, no, no. we are going back in circles. i would very much like to do things synchronously, but i can not. imo, i've given you plenty reasoning behind async design. please understand, asyn design has to stay. even if "sync" code appears to work, its still wrong. >> regular mutexes can sleep. we are not allowed to sleep in netgraph. >> therefor we must transition out of netgraph context before calling >> into any code that tries to grab regular mutex. the async design is >> there not because i want to make things complicated. its there because >> it is needed. > > I think there are two definitions of sleeping. > > 1) When a thread is waiting for a mutex it is not sleeping in the same way > like if it was to call "tsleep()". > > 2) When a thread is waiting for a wakeup it is surely sleeping, which can > happen inside sx_lock() and tsleep(). when i say "sleeping" i mean that the thread that is trying to get the lock is de-scheduled. that is, it is not running anymore. i'm not talking about [tm]sleep() etc. just the fact that thread is not running. oh, and to possibly answer your next question, freebsd's mutexes are ADAPTIVE, meaning that thread will will spin on a mutex for a little bit if it can not grab it right away BEFORE going to sleep. this means that the sc_mbufq_mtx mutex is very likely to be an equivalent of a spin lock because it is mosty used to protect queue while en/dequeuing mbuf etc. the same COULD apply for TQ_LOCK in taskqueue_enqeue(). thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 18:43:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C531065670; Sat, 24 Jan 2009 18:43:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAE18FC20; Sat, 24 Jan 2009 18:43:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5351174rvf.43 for ; Sat, 24 Jan 2009 10:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EFuadXZN4hrA8k7cZE3kZcrgmqW1Ibv3mRkyblI6IgU=; b=LsefckPb934DHhspJg6f4xRUoRYz/ZQjMUPGdPK4EA2h7Y7J2+xvAgO8ert4rYsbgp dtgMM82rR1anD6WaviBgqcJLMN11Ug1xbTjdly3oSHf1Tz1PPmwIxop8A5eyLnrsuBJG ZcAuO7iJXNdbbCcKJBcPTc1Z0b38BbTiw8hlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KxWL0GcuPkF0nP7mjPABByCYFd8bzrfOAjVXKZqG4v4UupYbKx5d8HTXNr0GCLU7sL pMHzmInT7fGQ6HUevMZ2I2c4cNoEODVdUVQt5M3CSXph01Nj3FwO+s7ttO3l1bQLjeve pi1z0NCaMDcoee7XvN/Pbx1fneOwaS0LdZcAY= MIME-Version: 1.0 Received: by 10.140.162.21 with SMTP id k21mr529570rve.256.1232822592133; Sat, 24 Jan 2009 10:43:12 -0800 (PST) In-Reply-To: <200901241055.20054.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> Date: Sat, 24 Jan 2009 10:43:12 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 18:43:13 -0000 On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky wrote: > On Saturday 24 January 2009, Maksim Yevmenkin wrote: >> Hans Petter, >> >> i'm sorry, did i mention there is no sleeping in netgraph? :-) > > Can you elaborate this? Is netgraph run from fast interrupt context? So that > only spin locks are possible? Or is it run from a thread? i already told you that netgraph is essentially single-threaded. for all intents and purposes think that only _ONE_ thread services _ALL_ netgraph nodes. if something can not be done immediately, netgraph queues it and returns back to it later. _ANY_ delay/sleep would stall _ENTIRE_ netgraph. think poll/select/callback driven programming model. >> from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin >> locks). you are using regular mutexes. let me quote locking(9) man >> page >> >> " >> Mutexes >> Basically (regular) mutexes will deschedule the thread if the mutex >> can not be acquired. A non-spin mutex can be considered to be equivalent >> to getting a write lock on an rw_lock (see below), >> " >> >> so, if thread can not get mutex it will be descheduled. this >> absolutely can not happen in netgraph! > > There are mutexes inside the taskqueue aswell. The problem will be the same > there if you don't use a so-called fast tasqueue. well, yes. technically, its not 100% correct, but it has to be like it because there is simply no way around this. if you read the blob at the top of the ng_ubt2.c you know that it uses regular sc_mbufq_mtx (which can sleep). let me quote the blob here again " Access to the outgoing queues and task flags is controlled by the sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should really be a spin lock." the sc_mbufq_mtx is _NOT_ marked as SPIN mutex only because WITNESS has to know about spin locks. it is generally NOT a good idea to add a spin lock when someone feels like it. now back to taskqueue_enqueue(), yes, taskqueue_enqueue_fast() is more appropriate here. however, taskqueue_enqueue() was chosen because taskqueue_enqueue() does not do anything that could cause sleep in TQ_LOCK()/TQ_UNLOCK() (its just basically a lookup). from taskqueue man page "Enqueueing a task does not perform any memory allocation which makes it suitable for calling from an interrupt handler." USB_BUS_LOCK()/USB_BUS_UNLOCK() are different is this regard because those locks used when usb2 does things with hardware. also, like i said, there could be few usb devices sharing the same bus and thus the same USB_BUS_LOCK. once again the rule is: NO SLEEPING/STALLING IN NETGRAPH. it DOES NOT mean that you can not use mutexes. it only means that you have to be very careful of how the mutex is used. >> first of all, i do not think crashes are caused by detach(). in fact, >> detach() is clean. i've tested it and it worked for me. i tried to >> start/stop device while doing flood l2ping. i also tried to yank the >> device while doing flood l2ping. it works correctly. i think, the >> issue is related to stalled transfers. there is still something wrong >> with the code path that deals with stalled transfers. stalls do not >> happen on my test box, so i can not test it. also there is NO code >> duplication. asynchronous path is required to decouple netgraph from >> usb2. > > Only if netgraph is run from fast interrupt context. no, no, no. we are going back in circles. i would very much like to do things synchronously, but i can not. imo, i've given you plenty reasoning behind async design. please understand, asyn design has to stay. even if "sync" code appears to work, its still wrong. >> regular mutexes can sleep. we are not allowed to sleep in netgraph. >> therefor we must transition out of netgraph context before calling >> into any code that tries to grab regular mutex. the async design is >> there not because i want to make things complicated. its there because >> it is needed. > > I think there are two definitions of sleeping. > > 1) When a thread is waiting for a mutex it is not sleeping in the same way > like if it was to call "tsleep()". > > 2) When a thread is waiting for a wakeup it is surely sleeping, which can > happen inside sx_lock() and tsleep(). when i say "sleeping" i mean that the thread that is trying to get the lock is de-scheduled. that is, it is not running anymore. i'm not talking about [tm]sleep() etc. just the fact that thread is not running. oh, and to possibly answer your next question, freebsd's mutexes are ADAPTIVE, meaning that thread will will spin on a mutex for a little bit if it can not grab it right away BEFORE going to sleep. this means that the sc_mbufq_mtx mutex is very likely to be an equivalent of a spin lock because it is mosty used to protect queue while en/dequeuing mbuf etc. the same COULD apply for TQ_LOCK in taskqueue_enqeue(). thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 18:47:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAE1106566B; Sat, 24 Jan 2009 18:47:37 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 04F858FC0A; Sat, 24 Jan 2009 18:47:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5352356rvf.43 for ; Sat, 24 Jan 2009 10:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+UFE9/w15MlOJwyJRhcwJa+oWdOBGOcm2yLxHCg9QKk=; b=ICdnu2v00Y926MIPH4PJRGccfQXqRvNg4jFDoAcwwDAg0oZaYY2MtWJbA0Diraj7Bp pVZ4WDZ8EA4xtINhKZ6J5n1xpMKVSc5FSxBSDpjm7ftHBUGhUcXuJZEWHTtKiD7pWg/a 1LvoL6gmNwNfCiZUFW9bFi8YctS7Li+g7lf4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RCjEP3SRxFZGs/+mBo0U7lrGFRjL7X4dJZt2J4xyN0vtvhir2P/zb2wICr12ygGse8 iLdnOi1LGBTyw6ayebfMsywogFG+rxTZyxW9hbfnt1Z+DsOUgqmKlDKVmg47RvvA1QlK 2ydE8HX4PXSRMu6bXFxDOhbl+JzvO5ZP3td6Y= MIME-Version: 1.0 Received: by 10.141.175.5 with SMTP id c5mr1005711rvp.243.1232822856786; Sat, 24 Jan 2009 10:47:36 -0800 (PST) In-Reply-To: <200901241120.46889.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241120.46889.hselasky@c2i.net> Date: Sat, 24 Jan 2009 10:47:36 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 18:47:37 -0000 >> > Yes, but you are already dropping an extra reference in ubt_shutdown(). >> > What about that? >> >> shutdown method is called as part of ng_rmnode_self() and drop the >> reference that node was born with. the extra reference before >> ng_rmnode_self() is to ensure that node pointer is still valid after >> ng_rmnode_self() returns. otherwise there is a change that node >> pointer becomes invalid while after ng_rmnode_self() calls shutdown >> method. > > I've now explicitly tested this and found that if I drop the node reference in > shutdown I end up with a zero node reference in detach! So the > NG_NODE_UNREF() should not be in the ubt_shutdown !!! > > This is maybe the reason why Lars was getting a panic! > > http://perforce.freebsd.org/chv.cgi?CH=156600 i think those changes are not correct. Lars's panic has nothing to do with detach(), imo. i beg you to stop posing your private ng_ubt2 patches for just one sec and let me work on this. right now, i'm confused because i do not know what code Lars is running and it makes it very hard to troubleshoot problems. thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 18:47:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAE1106566B; Sat, 24 Jan 2009 18:47:37 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 04F858FC0A; Sat, 24 Jan 2009 18:47:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5352356rvf.43 for ; Sat, 24 Jan 2009 10:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+UFE9/w15MlOJwyJRhcwJa+oWdOBGOcm2yLxHCg9QKk=; b=ICdnu2v00Y926MIPH4PJRGccfQXqRvNg4jFDoAcwwDAg0oZaYY2MtWJbA0Diraj7Bp pVZ4WDZ8EA4xtINhKZ6J5n1xpMKVSc5FSxBSDpjm7ftHBUGhUcXuJZEWHTtKiD7pWg/a 1LvoL6gmNwNfCiZUFW9bFi8YctS7Li+g7lf4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RCjEP3SRxFZGs/+mBo0U7lrGFRjL7X4dJZt2J4xyN0vtvhir2P/zb2wICr12ygGse8 iLdnOi1LGBTyw6ayebfMsywogFG+rxTZyxW9hbfnt1Z+DsOUgqmKlDKVmg47RvvA1QlK 2ydE8HX4PXSRMu6bXFxDOhbl+JzvO5ZP3td6Y= MIME-Version: 1.0 Received: by 10.141.175.5 with SMTP id c5mr1005711rvp.243.1232822856786; Sat, 24 Jan 2009 10:47:36 -0800 (PST) In-Reply-To: <200901241120.46889.hselasky@c2i.net> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241120.46889.hselasky@c2i.net> Date: Sat, 24 Jan 2009 10:47:36 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 18:47:37 -0000 >> > Yes, but you are already dropping an extra reference in ubt_shutdown(). >> > What about that? >> >> shutdown method is called as part of ng_rmnode_self() and drop the >> reference that node was born with. the extra reference before >> ng_rmnode_self() is to ensure that node pointer is still valid after >> ng_rmnode_self() returns. otherwise there is a change that node >> pointer becomes invalid while after ng_rmnode_self() calls shutdown >> method. > > I've now explicitly tested this and found that if I drop the node reference in > shutdown I end up with a zero node reference in detach! So the > NG_NODE_UNREF() should not be in the ubt_shutdown !!! > > This is maybe the reason why Lars was getting a panic! > > http://perforce.freebsd.org/chv.cgi?CH=156600 i think those changes are not correct. Lars's panic has nothing to do with detach(), imo. i beg you to stop posing your private ng_ubt2 patches for just one sec and let me work on this. right now, i'm confused because i do not know what code Lars is running and it makes it very hard to troubleshoot problems. thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 20:30:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0944B106564A for ; Sat, 24 Jan 2009 20:30:56 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id F17818FC0A for ; Sat, 24 Jan 2009 20:30:54 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.147.234] (port=52218 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LQp9W-000AjZ-Ey; Sat, 24 Jan 2009 23:30:51 +0300 Message-ID: <497B7A7A.3080103@lissyara.su> Date: Sat, 24 Jan 2009 23:30:50 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.19) Gecko/20090110 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Paul B. Mahol" References: <497A159B.5050404@lissyara.su> <497B24D5.3010200@lissyara.su> <3a142e750901240847o652c581erd1fe90c776824fbe@mail.gmail.com> In-Reply-To: <3a142e750901240847o652c581erd1fe90c776824fbe@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: acpi_throttle1: failed to attach P_CNT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 20:30:56 -0000 Paul B. Mahol пишет: > On 1/24/09, Alex Keda wrote: >> Alex Keda pishet: >>> After last update I have in dmesg >>> >>> acpi_throttle1: on cpu1 >>> acpi_throttle1: failed to attach P_CNT >>> device_attach: acpi_throttle1 attach returned 6 >>> >>> When I build somesing - laptop shutdown, because CPU temp > 105 Celsius >>> >>> HP# uname -a >>> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Jan 22 >>> 19:49:57 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/HP amd64 >>> HP# >> HP$ dmesg > .... > > I get this one: > > GEOM: ad0s1: geometry does not match label (15h,63s != 16h,63s). > Trying to mount root from ufs:/dev/ad0s1a > ACPI Exception (utmutex-0376): AE_TIME, Thread 186B0 could not acquire > Mutex [0] [20070320] > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] > ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] > ACPI Exception (utmutex-0376): AE_TIME, Thread 186B0 could not acquire > Mutex [0] [20070320] > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] > ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] > > The problem is it doesnt happens always, but with soft reset there is > (perceived) > bigger chance to happen. Also kernel without WITNESS and other debug > options have much bigger > chance for this error to happen. nooptions KDB nooptions DDB nooptions GDB nooptions INVARIANTS nooptions INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIPSPIN no changes =( any idea? From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 20:31:44 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D093E1065676 for ; Sat, 24 Jan 2009 20:31:44 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8A21F8FC08 for ; Sat, 24 Jan 2009 20:31:44 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0OKVZuO096436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2009 12:31:36 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <497B7A80.4060002@FreeBSD.org> Date: Sat, 24 Jan 2009 12:30:56 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hans Petter Selasky References: <200901241638.18591.hselasky@c2i.net> In-Reply-To: <200901241638.18591.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carlos Corona , freebsd-current@FreeBSD.org Subject: Re: Prblem whit USB in FreeBSD 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 20:31:45 -0000 Hans Petter Selasky wrote: > On Saturday 24 January 2009, Carlos Corona wrote: >> Hi * >> >> I'm running FreeBSD 8 i386 on my machine X2 AMD Athlon 64, I have devices >> such as USB keyboard and mouse, which works perfectly, but as to the >> pendrive, I had some problems when I connect my pendrive Fujitel for 1GB >> recognizes this, but will not let me do anything, I can open applications, >> etc. loggin a console, I managed to do the dmesg when connecting: >> >> (da0: UMass-sim0: 0:0:0): lost device >> (da0: UMass-sim0: 0:0:0): Synchronize cache failed, status == 0x39, scsi >> status == 0x0 >> (da0: UMass-sim0: 0:0:0): removing device entry >> GEOM_LABEL: Label msdosfs / [you: Qiufo] removed. >> umass0: detached >> >> Can onlydisconnect hold back my system, any thoughts on this? thanks in >> advance > > Hi, > > Most likely The firmware on your pendrive is not fully SCSI compliant. > > Read: http://wiki.freebsd.org/USB > > and the section about adding an USB Mass Storage Quirk. > > You need to add something like this to "sys/dev/usb2/storage/umass2.c" : > > {USB_VENDOR_MEIZU, USB_PRODUCT_MEIZU_M6_SL, RID_WILDCARD, > UMASS_PROTO_SCSI | UMASS_PROTO_BBB, > NO_INQUIRY | NO_SYNCHRONIZE_CACHE > }, I wonder if this situation can be handled automatically. To my ignorant view, our USB mass storage driver can try sending "synchronize cache" command and if that fails then failback to the NO_SYNCHRONIZE_CACHE behavior. -Maxim From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:03:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B436106566C for ; Sat, 24 Jan 2009 23:03:51 +0000 (UTC) (envelope-from scott.gasch@gmail.com) Received: from rv-out-0304.google.com (rv-out-0304.google.com [209.85.198.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6952D8FC0A for ; Sat, 24 Jan 2009 23:03:51 +0000 (UTC) (envelope-from scott.gasch@gmail.com) Received: by rv-out-0304.google.com with SMTP id b20so2201212rvf.31 for ; Sat, 24 Jan 2009 15:03:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <6101e8c40901240749h106916adya7d6a8caee4ed155@mail.gmail.com> Received: by 10.115.110.15 with SMTP id n15mr1375217wam.11.1232838231189; Sat, 24 Jan 2009 15:03:51 -0800 (PST) Message-ID: <00163641792bd5eece046142843d@google.com> Date: Sat, 24 Jan 2009 23:03:51 +0000 From: scott.gasch@gmail.com To: Oliver Pinter , Scott Gasch , freebsd-amd64@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Re: Problems with ata driver on current / Asus P5Q-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:03:51 -0000 Hi Oliver, Thanks for the reply. I'm running bios version 02.61 American Megatrends Inc; it has never been updated. I just got the latest image (1703) from ASUS and will try flashing it. I don't have my controller set on RAID because I don't want hardware RAID... it's set on AHCI instead. Maybe this is the difference. Are you doing hardware RAID? I'm still looking over your config and dmesg, thanks for sending those. I'll report back if I figure anything out. Thx, Scott On Jan 24, 2009 7:49am, Oliver Pinter wrote: > I have the same MB, and it running perfect, but I have only 3 SATA HDD > > + 1 SATA DVD-RW > > > > The ICH is in RAID mode. > > > > Attached my conf and dmesg > > > > Which version of BIOS use You? > > > > [snip] > > Southbridge > > - 6 x SATA 3Gb/s > > - Intel(R) Matrix Storage Technology with RAID 0, 1, 5, 10 support > > Marvell 88SE6121 > > - 1 x UltraDMA 133/100/66 for up to 2 PATA devices > > - 1 x External SATA 3Gb/s port (SATA On-the-Go) > > Silicon Image Sil5723 (Drive Xpert technology) > > - 2 x SATA 3Gb/s > > - Supports EZ Backup and Super Speed functions > > [snip] > > > > http://www.asus.com/products.aspx?l1=3&l2=11&l3=709&l4=0&model=2267&modelmenu=2 > > > > /* sorry for bad english */ > > > > On 1/24/09, Scott Gasch scott.gasch@gmail.com> wrote: > > > Hi, > > > I've been running a 7.1-p1 (amd64) system and and seeing very high interrupt > > > rates on irq19 which is shared between several devices. Over 60% of one > > > core is used responding to interrupts. The machine also hangs frequently. > > > irq19 is shared by atapci1, atapci2, fwohci0 and uhci4... > > > the consensus response to my last question was that "it's probably the ata > > > driver". > > > > > > Today I tried building and booting a GENERIC current kernel and got another > > > piece of information. The freebsd-current GENERIC kernel does not boot; > > > shortly after probing the drives it says "Cannot setup DMA" several times on > > > the console and hangs. > > > > > > This machine is an Asus P5Q-E... I believe it has two ATA controllers: > > > a Marvell > > > 88SE6121 and a Silicon Image SIL5723. Is one of these chipsets generating > > > interrupts that the driver doesn't understand and/or properly dismiss? Can > > > it be put into a legacy mode that works? This machine has problems in 7.0, > > > 7.1 and current... I'm running out of ideas. > > > > > > Thx, > > > Scott > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:06:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91ED01065670; Sat, 24 Jan 2009 23:06:49 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0E58FC16; Sat, 24 Jan 2009 23:06:49 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:06:45 -0800 Message-ID: <497B9F08.5010209@elischer.org> Date: Sat, 24 Jan 2009 15:06:48 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:06:50 -0000 Maksim Yevmenkin wrote: > Hans Petter, > >>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >>> >>> again, sorry, but this is not going to work. you still doing >>> UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to >>> grab the same lock that is used for locking interfaces. >> Yes, you have to do that. Else you end up with a state nightmare with the >> taskqueue where you don't know in the end if you should start or stop the USB >> interface! > > exactly! > >>> more importantly, like i said before, usb2_transfer_stop() does >>> USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb >>> device will not do something synchronously over the same usb bus? >> Every time something is done synchronously the USB_BUS_LOCK() is dropped. This >> mutex is only used when filling out DMA structures and when touching USB >> hardware registers. I cannot see that this will take any time at all. We are >> talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and >> not a SX lock! A mutex cannot sleep in the same way an SX lock can. > > from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin > locks). you are using regular mutexes. let me quote locking(9) man > page > > " > Mutexes > Basically (regular) mutexes will deschedule the thread if the mutex can > not be acquired. A non-spin mutex can be considered to be equivalent to > getting a write lock on an rw_lock (see below), > " > > so, if thread can not get mutex it will be descheduled. this > absolutely can not happen in netgraph! Having said htat in the past I think that things have progressed to the point where this needs clarification. Mutexes are now ok as long as the transitive set doesn't include anything that takes too long. this has probably been true for a year or so. so if Hans Petter can guarantee that the lock is 'short' then probly the adaptive mutex code will spin for a few instructions and continue on. so I think we should allow this usage now. it was true earlier but as I said, I think things have progressed to the state where this is PROBABLY ok. > >>>> I have a question. What is the following doing at the middle of the >>>> ubt_detach(): >>>> >>>> if (node != NULL) >>>> NG_NODE_UNREF(node); >>>> >>>> If you say that: >>>> >>>> ng_rmnode_self(node); >>>> >>>> Cleans up the last reference? >>> the complete code is >>> >>> node_p node = sc->sc_node; >>> >>> if (node != NULL) { >>> sc->sc_node = NULL; <-- clear sc_node >>> >>> NG_NODE_SET_PRIVATE(node, NULL); >>> NG_NODE_REALLY_DIE(node); >>> >>> NG_NODE_REF(node); <--- grab +1 reference >>> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its >>> not free()d >>> } >>> >>> /* bla, bla */ >>> >>> if (node != NULL) >>> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node >> Yes, but you are already dropping an extra reference in ubt_shutdown(). What >> about that? > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. > > [...] > >> I think you misunderstand. I'm using mutexes. They will not block for very >> long! There are no DELAY()'s with mutexes held! When another USB device is >> attached / detached it is: >> >> 1) Done from another thread >> 2) The USB locks in the critical path are dropped when waiting for wakeup or >> doing so called synchronous stuff. >>> it would be if we could sleep in netgraph, and we can not. >> Do mutexes sleep? No? So my code should be fine? > > yes, regular mutexes sleep. > >>> in theory, >>> we only need one extra reference which would tell us if there anything >>> in usb2 that still could access node pointer. in practice, instead of >>> checking every transfer and making sure its no pending before dropping >>> that extra reference i just add multiple references for each usb2 >>> transfer and ubt_task (i.e. things that could access node pointer). >> I'm just thinking that this is starting to get complicated, and please >> understand I've spent much time on detach issues, and there is alot of >> builtin funcionality inside USB which will handle start/stop/re-start issues >> automagically. I see it like duplicate code when you check for USB transfer >> re-start in netgraph ??? > > first of all, i do not think crashes are caused by detach(). in fact, > detach() is clean. i've tested it and it worked for me. i tried to > start/stop device while doing flood l2ping. i also tried to yank the > device while doing flood l2ping. it works correctly. i think, the > issue is related to stalled transfers. there is still something wrong > with the code path that deals with stalled transfers. stalls do not > happen on my test box, so i can not test it. also there is NO code > duplication. asynchronous path is required to decouple netgraph from > usb2. > >>> right, and what if some other usb device attached to the same usb >>> controller is doing something synchronously? do you see that you could >>> potentially block netgraph for arbitrary time and that is really out >>> of ng_ubt2 driver control? >> Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is >> called from High Priority threads! See explanation further up. And will not >> block very long at all. > > regular mutexes can sleep. we are not allowed to sleep in netgraph. > therefor we must transition out of netgraph context before calling > into any code that tries to grab regular mutex. the async design is > there not because i want to make things complicated. its there because > it is needed. > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:06:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91ED01065670; Sat, 24 Jan 2009 23:06:49 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0E58FC16; Sat, 24 Jan 2009 23:06:49 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:06:45 -0800 Message-ID: <497B9F08.5010209@elischer.org> Date: Sat, 24 Jan 2009 15:06:48 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:06:50 -0000 Maksim Yevmenkin wrote: > Hans Petter, > >>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >>> >>> again, sorry, but this is not going to work. you still doing >>> UBT_LOCK()/UBT_UNLOCK() in netgraph method. that is you are trying to >>> grab the same lock that is used for locking interfaces. >> Yes, you have to do that. Else you end up with a state nightmare with the >> taskqueue where you don't know in the end if you should start or stop the USB >> interface! > > exactly! > >>> more importantly, like i said before, usb2_transfer_stop() does >>> USB_BUS_LOCK()/USB_BUS_UNLOCK(). is there a guarantee that another usb >>> device will not do something synchronously over the same usb bus? >> Every time something is done synchronously the USB_BUS_LOCK() is dropped. This >> mutex is only used when filling out DMA structures and when touching USB >> hardware registers. I cannot see that this will take any time at all. We are >> talking about microseconds of congestion time! USB_BUS_LOCK() is a mutex and >> not a SX lock! A mutex cannot sleep in the same way an SX lock can. > > from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin > locks). you are using regular mutexes. let me quote locking(9) man > page > > " > Mutexes > Basically (regular) mutexes will deschedule the thread if the mutex can > not be acquired. A non-spin mutex can be considered to be equivalent to > getting a write lock on an rw_lock (see below), > " > > so, if thread can not get mutex it will be descheduled. this > absolutely can not happen in netgraph! Having said htat in the past I think that things have progressed to the point where this needs clarification. Mutexes are now ok as long as the transitive set doesn't include anything that takes too long. this has probably been true for a year or so. so if Hans Petter can guarantee that the lock is 'short' then probly the adaptive mutex code will spin for a few instructions and continue on. so I think we should allow this usage now. it was true earlier but as I said, I think things have progressed to the state where this is PROBABLY ok. > >>>> I have a question. What is the following doing at the middle of the >>>> ubt_detach(): >>>> >>>> if (node != NULL) >>>> NG_NODE_UNREF(node); >>>> >>>> If you say that: >>>> >>>> ng_rmnode_self(node); >>>> >>>> Cleans up the last reference? >>> the complete code is >>> >>> node_p node = sc->sc_node; >>> >>> if (node != NULL) { >>> sc->sc_node = NULL; <-- clear sc_node >>> >>> NG_NODE_SET_PRIVATE(node, NULL); >>> NG_NODE_REALLY_DIE(node); >>> >>> NG_NODE_REF(node); <--- grab +1 reference >>> ng_rmnode_self(node); <--- mark node as "dead", but not ensure its >>> not free()d >>> } >>> >>> /* bla, bla */ >>> >>> if (node != NULL) >>> NG_NODE_UNREF(node); <--- drop 1 reference and possibly free() node >> Yes, but you are already dropping an extra reference in ubt_shutdown(). What >> about that? > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. > > [...] > >> I think you misunderstand. I'm using mutexes. They will not block for very >> long! There are no DELAY()'s with mutexes held! When another USB device is >> attached / detached it is: >> >> 1) Done from another thread >> 2) The USB locks in the critical path are dropped when waiting for wakeup or >> doing so called synchronous stuff. >>> it would be if we could sleep in netgraph, and we can not. >> Do mutexes sleep? No? So my code should be fine? > > yes, regular mutexes sleep. > >>> in theory, >>> we only need one extra reference which would tell us if there anything >>> in usb2 that still could access node pointer. in practice, instead of >>> checking every transfer and making sure its no pending before dropping >>> that extra reference i just add multiple references for each usb2 >>> transfer and ubt_task (i.e. things that could access node pointer). >> I'm just thinking that this is starting to get complicated, and please >> understand I've spent much time on detach issues, and there is alot of >> builtin funcionality inside USB which will handle start/stop/re-start issues >> automagically. I see it like duplicate code when you check for USB transfer >> re-start in netgraph ??? > > first of all, i do not think crashes are caused by detach(). in fact, > detach() is clean. i've tested it and it worked for me. i tried to > start/stop device while doing flood l2ping. i also tried to yank the > device while doing flood l2ping. it works correctly. i think, the > issue is related to stalled transfers. there is still something wrong > with the code path that deals with stalled transfers. stalls do not > happen on my test box, so i can not test it. also there is NO code > duplication. asynchronous path is required to decouple netgraph from > usb2. > >>> right, and what if some other usb device attached to the same usb >>> controller is doing something synchronously? do you see that you could >>> potentially block netgraph for arbitrary time and that is really out >>> of ng_ubt2 driver control? >> Again, USB_BUS_LOCK() is a mutex, not an SX lock. All code using this lock is >> called from High Priority threads! See explanation further up. And will not >> block very long at all. > > regular mutexes can sleep. we are not allowed to sleep in netgraph. > therefor we must transition out of netgraph context before calling > into any code that tries to grab regular mutex. the async design is > there not because i want to make things complicated. its there because > it is needed. > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:14:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACDAE1065677; Sat, 24 Jan 2009 23:14:57 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6628FC0C; Sat, 24 Jan 2009 23:14:57 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:14:55 -0800 Message-ID: <497BA0F2.5080004@elischer.org> Date: Sat, 24 Jan 2009 15:14:58 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:14:58 -0000 Maksim Yevmenkin wrote: > Hans Petter, >> Do mutexes sleep? No? So my code should be fine? > > yes, regular mutexes sleep. Yes and no. This is a semantic thing.. They don't actually 'sleep', but they do deschedule the thread. the difference is purely semantic. Users of mutexes "agree" to never do anything that in indeterminately long while holding the mutex so you are SUPPOSED to get control back in a "short" period of time. Even if multiple mutexes have dependencies on each other, the fact that none of them may wait for a "long" time is suposed to guarantee that your thread should get control again "shortly". It is illegal to sleep while holding a mutex. This helps enforce this (otherwise small) distinction. A Sleep may wait for an arbitrary amount of time.. e.g. until reboot. so doing so with a mutex held would break the agreement. Effectively the only real difference is that the agreement by users to not use a mutex when things may get slow. Spin locks are even more strict.. BTW A mutex that is waiting on a thread on another processor may spin for a short amount of time before taking the expensive step of descheduling the thread. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:14:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACDAE1065677; Sat, 24 Jan 2009 23:14:57 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6628FC0C; Sat, 24 Jan 2009 23:14:57 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:14:55 -0800 Message-ID: <497BA0F2.5080004@elischer.org> Date: Sat, 24 Jan 2009 15:14:58 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:14:58 -0000 Maksim Yevmenkin wrote: > Hans Petter, >> Do mutexes sleep? No? So my code should be fine? > > yes, regular mutexes sleep. Yes and no. This is a semantic thing.. They don't actually 'sleep', but they do deschedule the thread. the difference is purely semantic. Users of mutexes "agree" to never do anything that in indeterminately long while holding the mutex so you are SUPPOSED to get control back in a "short" period of time. Even if multiple mutexes have dependencies on each other, the fact that none of them may wait for a "long" time is suposed to guarantee that your thread should get control again "shortly". It is illegal to sleep while holding a mutex. This helps enforce this (otherwise small) distinction. A Sleep may wait for an arbitrary amount of time.. e.g. until reboot. so doing so with a mutex held would break the agreement. Effectively the only real difference is that the agreement by users to not use a mutex when things may get slow. Spin locks are even more strict.. BTW A mutex that is waiting on a thread on another processor may spin for a short amount of time before taking the expensive step of descheduling the thread. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:29:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BD41065679; Sat, 24 Jan 2009 23:29:52 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 27DBF8FC1B; Sat, 24 Jan 2009 23:29:51 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:29:51 -0800 Message-ID: <497BA473.6060007@elischer.org> Date: Sat, 24 Jan 2009 15:29:55 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:29:53 -0000 Maksim Yevmenkin wrote: > On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky wrote: >> On Saturday 24 January 2009, Maksim Yevmenkin wrote: >>> Hans Petter, >>> >>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >> Can you elaborate this? Is netgraph run from fast interrupt context? So that >> only spin locks are possible? Or is it run from a thread? > > i already told you that netgraph is essentially single-threaded. for > all intents and purposes think that only _ONE_ thread services _ALL_ > netgraph nodes. if something can not be done immediately, netgraph > queues it and returns back to it later. _ANY_ delay/sleep would stall > _ENTIRE_ netgraph. think poll/select/callback driven programming > model. it depends on the delay. if it's going to be 200usecs.. ok (with a grumble) if it's going to be 5mSec it is NOT ok.. netgraph itself does nothing that would block (except one mutex that is guaranteed to be really quick and is probably always satisfied in the 'spin' stage.) we have thought about having multipel netgraph threads. (and there is a patch to do this.. I don';t think it has been added yet). so you are both right.. a node should avoid doing a mutex if there is any chance that that mutex may end up taking any real time to satisfy, due to mutex chaining etc.) I almos think there should be a mutex type that is called 'leaf' mutex. no other mutex may be taken while it is held.. In other words, you can use a mutex in Netgraph IFF you can guarantee that all potential holders of the mutex will never acquire any other locks or do anything that may take real time. it's probably ok to take a lock to protect updating a statistics block if you know that the only other holders will be the same code you are writing, in another thread, and that that code will never need to do anything except update the memory. So the question becomes. If HPS uses a mutex, what are the other users of the mutex doing? > >>> from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin >>> locks). you are using regular mutexes. let me quote locking(9) man >>> page >>> >>> " >>> Mutexes >>> Basically (regular) mutexes will deschedule the thread if the mutex >>> can not be acquired. A non-spin mutex can be considered to be equivalent >>> to getting a write lock on an rw_lock (see below), >>> " >>> >>> so, if thread can not get mutex it will be descheduled. this >>> absolutely can not happen in netgraph! >> There are mutexes inside the taskqueue aswell. The problem will be the same >> there if you don't use a so-called fast tasqueue. > > well, yes. technically, its not 100% correct, but it has to be like it > because there is simply no way around this. if you read the blob at > the top of the ng_ubt2.c you know that it uses regular sc_mbufq_mtx > (which can sleep). let me quote the blob here again > > " Access to the outgoing queues and task flags is controlled by the > sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should > really be a spin lock." > > the sc_mbufq_mtx is _NOT_ marked as SPIN mutex only because WITNESS > has to know about spin locks. it is generally NOT a good idea to add a > spin lock when someone feels like it. > > now back to taskqueue_enqueue(), yes, taskqueue_enqueue_fast() is more > appropriate here. however, taskqueue_enqueue() was chosen because > taskqueue_enqueue() does not do anything that could cause sleep in > TQ_LOCK()/TQ_UNLOCK() (its just basically a lookup). > > from taskqueue man page > > "Enqueueing a task does not perform any memory allocation which makes > it suitable for calling from an interrupt handler." > > USB_BUS_LOCK()/USB_BUS_UNLOCK() are different is this regard because > those locks used when usb2 does things with hardware. also, like i > said, there could be few usb devices sharing the same bus and thus the > same USB_BUS_LOCK. > > once again the rule is: NO SLEEPING/STALLING IN NETGRAPH. it DOES NOT > mean that you can not use mutexes. it only means that you have to be > very careful of how the mutex is used. > >>> first of all, i do not think crashes are caused by detach(). in fact, >>> detach() is clean. i've tested it and it worked for me. i tried to >>> start/stop device while doing flood l2ping. i also tried to yank the >>> device while doing flood l2ping. it works correctly. i think, the >>> issue is related to stalled transfers. there is still something wrong >>> with the code path that deals with stalled transfers. stalls do not >>> happen on my test box, so i can not test it. also there is NO code >>> duplication. asynchronous path is required to decouple netgraph from >>> usb2. >> Only if netgraph is run from fast interrupt context. > > no, no, no. we are going back in circles. i would very much like to do > things synchronously, but i can not. imo, i've given you plenty > reasoning behind async design. please understand, asyn design has to > stay. even if "sync" code appears to work, its still wrong. > >>> regular mutexes can sleep. we are not allowed to sleep in netgraph. >>> therefor we must transition out of netgraph context before calling >>> into any code that tries to grab regular mutex. the async design is >>> there not because i want to make things complicated. its there because >>> it is needed. >> I think there are two definitions of sleeping. >> >> 1) When a thread is waiting for a mutex it is not sleeping in the same way >> like if it was to call "tsleep()". >> >> 2) When a thread is waiting for a wakeup it is surely sleeping, which can >> happen inside sx_lock() and tsleep(). > > when i say "sleeping" i mean that the thread that is trying to get the > lock is de-scheduled. that is, it is not running anymore. i'm not > talking about [tm]sleep() etc. just the fact that thread is not > running. > > oh, and to possibly answer your next question, freebsd's mutexes are > ADAPTIVE, meaning that thread will will spin on a mutex for a little > bit if it can not grab it right away BEFORE going to sleep. this means > that the sc_mbufq_mtx mutex is very likely to be an equivalent of a > spin lock because it is mosty used to protect queue while en/dequeuing > mbuf etc. the same COULD apply for TQ_LOCK in taskqueue_enqeue(). > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:29:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BD41065679; Sat, 24 Jan 2009 23:29:52 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 27DBF8FC1B; Sat, 24 Jan 2009 23:29:51 +0000 (UTC) (envelope-from prvs=julian=268335b7e@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:29:51 -0800 Message-ID: <497BA473.6060007@elischer.org> Date: Sat, 24 Jan 2009 15:29:55 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:29:53 -0000 Maksim Yevmenkin wrote: > On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky wrote: >> On Saturday 24 January 2009, Maksim Yevmenkin wrote: >>> Hans Petter, >>> >>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >> Can you elaborate this? Is netgraph run from fast interrupt context? So that >> only spin locks are possible? Or is it run from a thread? > > i already told you that netgraph is essentially single-threaded. for > all intents and purposes think that only _ONE_ thread services _ALL_ > netgraph nodes. if something can not be done immediately, netgraph > queues it and returns back to it later. _ANY_ delay/sleep would stall > _ENTIRE_ netgraph. think poll/select/callback driven programming > model. it depends on the delay. if it's going to be 200usecs.. ok (with a grumble) if it's going to be 5mSec it is NOT ok.. netgraph itself does nothing that would block (except one mutex that is guaranteed to be really quick and is probably always satisfied in the 'spin' stage.) we have thought about having multipel netgraph threads. (and there is a patch to do this.. I don';t think it has been added yet). so you are both right.. a node should avoid doing a mutex if there is any chance that that mutex may end up taking any real time to satisfy, due to mutex chaining etc.) I almos think there should be a mutex type that is called 'leaf' mutex. no other mutex may be taken while it is held.. In other words, you can use a mutex in Netgraph IFF you can guarantee that all potential holders of the mutex will never acquire any other locks or do anything that may take real time. it's probably ok to take a lock to protect updating a statistics block if you know that the only other holders will be the same code you are writing, in another thread, and that that code will never need to do anything except update the memory. So the question becomes. If HPS uses a mutex, what are the other users of the mutex doing? > >>> from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin >>> locks). you are using regular mutexes. let me quote locking(9) man >>> page >>> >>> " >>> Mutexes >>> Basically (regular) mutexes will deschedule the thread if the mutex >>> can not be acquired. A non-spin mutex can be considered to be equivalent >>> to getting a write lock on an rw_lock (see below), >>> " >>> >>> so, if thread can not get mutex it will be descheduled. this >>> absolutely can not happen in netgraph! >> There are mutexes inside the taskqueue aswell. The problem will be the same >> there if you don't use a so-called fast tasqueue. > > well, yes. technically, its not 100% correct, but it has to be like it > because there is simply no way around this. if you read the blob at > the top of the ng_ubt2.c you know that it uses regular sc_mbufq_mtx > (which can sleep). let me quote the blob here again > > " Access to the outgoing queues and task flags is controlled by the > sc_mbufq_mtx lock. It is an unavoidable evil. Again, sc_mbufq_mtx should > really be a spin lock." > > the sc_mbufq_mtx is _NOT_ marked as SPIN mutex only because WITNESS > has to know about spin locks. it is generally NOT a good idea to add a > spin lock when someone feels like it. > > now back to taskqueue_enqueue(), yes, taskqueue_enqueue_fast() is more > appropriate here. however, taskqueue_enqueue() was chosen because > taskqueue_enqueue() does not do anything that could cause sleep in > TQ_LOCK()/TQ_UNLOCK() (its just basically a lookup). > > from taskqueue man page > > "Enqueueing a task does not perform any memory allocation which makes > it suitable for calling from an interrupt handler." > > USB_BUS_LOCK()/USB_BUS_UNLOCK() are different is this regard because > those locks used when usb2 does things with hardware. also, like i > said, there could be few usb devices sharing the same bus and thus the > same USB_BUS_LOCK. > > once again the rule is: NO SLEEPING/STALLING IN NETGRAPH. it DOES NOT > mean that you can not use mutexes. it only means that you have to be > very careful of how the mutex is used. > >>> first of all, i do not think crashes are caused by detach(). in fact, >>> detach() is clean. i've tested it and it worked for me. i tried to >>> start/stop device while doing flood l2ping. i also tried to yank the >>> device while doing flood l2ping. it works correctly. i think, the >>> issue is related to stalled transfers. there is still something wrong >>> with the code path that deals with stalled transfers. stalls do not >>> happen on my test box, so i can not test it. also there is NO code >>> duplication. asynchronous path is required to decouple netgraph from >>> usb2. >> Only if netgraph is run from fast interrupt context. > > no, no, no. we are going back in circles. i would very much like to do > things synchronously, but i can not. imo, i've given you plenty > reasoning behind async design. please understand, asyn design has to > stay. even if "sync" code appears to work, its still wrong. > >>> regular mutexes can sleep. we are not allowed to sleep in netgraph. >>> therefor we must transition out of netgraph context before calling >>> into any code that tries to grab regular mutex. the async design is >>> there not because i want to make things complicated. its there because >>> it is needed. >> I think there are two definitions of sleeping. >> >> 1) When a thread is waiting for a mutex it is not sleeping in the same way >> like if it was to call "tsleep()". >> >> 2) When a thread is waiting for a wakeup it is surely sleeping, which can >> happen inside sx_lock() and tsleep(). > > when i say "sleeping" i mean that the thread that is trying to get the > lock is de-scheduled. that is, it is not running anymore. i'm not > talking about [tm]sleep() etc. just the fact that thread is not > running. > > oh, and to possibly answer your next question, freebsd's mutexes are > ADAPTIVE, meaning that thread will will spin on a mutex for a little > bit if it can not grab it right away BEFORE going to sleep. this means > that the sc_mbufq_mtx mutex is very likely to be an equivalent of a > spin lock because it is mosty used to protect queue while en/dequeuing > mbuf etc. the same COULD apply for TQ_LOCK in taskqueue_enqeue(). > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:31:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46567106567E; Sat, 24 Jan 2009 23:31:30 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 08F408FC08; Sat, 24 Jan 2009 23:31:29 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5416649rvf.43 for ; Sat, 24 Jan 2009 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1A2A6DBf9LVciepX/aK5BqI5zYpM0cPOoFPfYUh5erg=; b=tkrtaYDpG6tImDOmI2eKEHYcL1jGDtsFirr7ugclZYsMxSmz+uWy/HKD3V1i9b1ofB IgQlnFBusy6HbkqFgZIxvg1gDCfHSUXm/C4bhI/+w2+lOWURZwAunJQnwh++05GA9eOZ jt3DrIdl+KeSAJDy+DQQ8D0N2dmX3cV41Kq7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nck4kSTXkWBUsCPhU4Y+EQwN0YD6uGDMVA/6O2N1h1IqPWX2yZAZe67a0huY90BQlW OdFYcqOs2sTe+IXHx7lvC/i7XsxC35kcTD/dumg7cZwuaosBA1lAXr/q02Qb1U9mF1rw SCZ+K4iWMYFWZGnx+6KqM7tuKu/KOnuShe5tI= MIME-Version: 1.0 Received: by 10.141.20.6 with SMTP id x6mr1188233rvi.159.1232839889648; Sat, 24 Jan 2009 15:31:29 -0800 (PST) In-Reply-To: <497BA0F2.5080004@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> <497BA0F2.5080004@elischer.org> Date: Sat, 24 Jan 2009 15:31:29 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:31:30 -0000 On Sat, Jan 24, 2009 at 3:14 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> Hans Petter, > >>> Do mutexes sleep? No? So my code should be fine? >> >> yes, regular mutexes sleep. > > Yes and no. > > This is a semantic thing.. > > They don't actually 'sleep', but they do deschedule the thread. > > the difference is purely semantic. > > Users of mutexes "agree" to never do anything that in indeterminately long > while holding the mutex so you are SUPPOSED to get control back in a "short" > period of time. Even if multiple mutexes have > dependencies on each other, the fact that none of them may wait > for a "long" time is suposed to guarantee that your thread should get > control again "shortly". > > It is illegal to sleep while holding a mutex. This helps enforce > this (otherwise small) distinction. > > A Sleep may wait for an arbitrary amount of time.. e.g. until reboot. > so doing so with a mutex held would break the agreement. > > Effectively the only real difference is that the agreement > by users to not use a mutex when things may get slow. > > Spin locks are even more strict.. > > BTW A mutex that is waiting on a thread on another processor > may spin for a short amount of time before taking the expensive > step of descheduling the thread. yes, i guess i used "sleep" word too much and it became overloaded. as i tried to explain in previous email, when i talk about "sleep" i really mean de-schedule. in any case, i sent another patch to Hans Petter (privately) which hopefully addresses most of his concerns. as i understood, the biggest was excessive amount of NG_XXX macros and node reference counting. all of those are now mostly gone and the resulting code is more clean (or so i hope). i kept async design which allows to completely decouple netgraph from usb2 and, like i said, it is a "good thing(tm)" thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:31:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46567106567E; Sat, 24 Jan 2009 23:31:30 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 08F408FC08; Sat, 24 Jan 2009 23:31:29 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5416649rvf.43 for ; Sat, 24 Jan 2009 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1A2A6DBf9LVciepX/aK5BqI5zYpM0cPOoFPfYUh5erg=; b=tkrtaYDpG6tImDOmI2eKEHYcL1jGDtsFirr7ugclZYsMxSmz+uWy/HKD3V1i9b1ofB IgQlnFBusy6HbkqFgZIxvg1gDCfHSUXm/C4bhI/+w2+lOWURZwAunJQnwh++05GA9eOZ jt3DrIdl+KeSAJDy+DQQ8D0N2dmX3cV41Kq7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nck4kSTXkWBUsCPhU4Y+EQwN0YD6uGDMVA/6O2N1h1IqPWX2yZAZe67a0huY90BQlW OdFYcqOs2sTe+IXHx7lvC/i7XsxC35kcTD/dumg7cZwuaosBA1lAXr/q02Qb1U9mF1rw SCZ+K4iWMYFWZGnx+6KqM7tuKu/KOnuShe5tI= MIME-Version: 1.0 Received: by 10.141.20.6 with SMTP id x6mr1188233rvi.159.1232839889648; Sat, 24 Jan 2009 15:31:29 -0800 (PST) In-Reply-To: <497BA0F2.5080004@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> <497BA0F2.5080004@elischer.org> Date: Sat, 24 Jan 2009 15:31:29 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:31:30 -0000 On Sat, Jan 24, 2009 at 3:14 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> Hans Petter, > >>> Do mutexes sleep? No? So my code should be fine? >> >> yes, regular mutexes sleep. > > Yes and no. > > This is a semantic thing.. > > They don't actually 'sleep', but they do deschedule the thread. > > the difference is purely semantic. > > Users of mutexes "agree" to never do anything that in indeterminately long > while holding the mutex so you are SUPPOSED to get control back in a "short" > period of time. Even if multiple mutexes have > dependencies on each other, the fact that none of them may wait > for a "long" time is suposed to guarantee that your thread should get > control again "shortly". > > It is illegal to sleep while holding a mutex. This helps enforce > this (otherwise small) distinction. > > A Sleep may wait for an arbitrary amount of time.. e.g. until reboot. > so doing so with a mutex held would break the agreement. > > Effectively the only real difference is that the agreement > by users to not use a mutex when things may get slow. > > Spin locks are even more strict.. > > BTW A mutex that is waiting on a thread on another processor > may spin for a short amount of time before taking the expensive > step of descheduling the thread. yes, i guess i used "sleep" word too much and it became overloaded. as i tried to explain in previous email, when i talk about "sleep" i really mean de-schedule. in any case, i sent another patch to Hans Petter (privately) which hopefully addresses most of his concerns. as i understood, the biggest was excessive amount of NG_XXX macros and node reference counting. all of those are now mostly gone and the resulting code is more clean (or so i hope). i kept async design which allows to completely decouple netgraph from usb2 and, like i said, it is a "good thing(tm)" thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:36:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09055106564A; Sat, 24 Jan 2009 23:36:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id BF1DE8FC1A; Sat, 24 Jan 2009 23:36:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5417674rvf.43 for ; Sat, 24 Jan 2009 15:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MAyZg6uZXFZzdlMZ31MTlxwaoisOxsO2xoqlapNZD/Y=; b=ekGYLA6R3HKDXjSPbCZV3ZPaH0HSTFcw3ucrl/NMRqykbgpQxhkweUGpOeLlQ8zSWp htfR12RomPUrRTqB5a/weB/FOhkWG1udjeUsnDSTdSdCjGAvLqCz3rxmkVGv/LiZ2Px5 37dk0nDjpH9O/5gpbqFegeJu0DuTLEgycGxwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pTtv420a7BAnB30zo9XUiDL+Yv9Qi11LhALMIrE8nyKSFAvAutMy1XBAAt5dwn1rVx zJyexipbnf9IEes9CfnyjWAsLrCFxWC4Kkn1rh6DCeW4o9IAqIeS4CjqJfsTjWwJfcid 60spTKcQNVJ0COJyh7fi8E741qQET0NgvrJ6w= MIME-Version: 1.0 Received: by 10.141.132.1 with SMTP id j1mr5911413rvn.282.1232840187592; Sat, 24 Jan 2009 15:36:27 -0800 (PST) In-Reply-To: <497BA473.6060007@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> <497BA473.6060007@elischer.org> Date: Sat, 24 Jan 2009 15:36:27 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:36:28 -0000 On Sat, Jan 24, 2009 at 3:29 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky >> wrote: >>> >>> On Saturday 24 January 2009, Maksim Yevmenkin wrote: >>>> >>>> Hans Petter, >>>> >>>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >>> >>> Can you elaborate this? Is netgraph run from fast interrupt context? So >>> that >>> only spin locks are possible? Or is it run from a thread? >> >> i already told you that netgraph is essentially single-threaded. for >> all intents and purposes think that only _ONE_ thread services _ALL_ >> netgraph nodes. if something can not be done immediately, netgraph >> queues it and returns back to it later. _ANY_ delay/sleep would stall >> _ENTIRE_ netgraph. think poll/select/callback driven programming >> model. > > it depends on the delay. > if it's going to be 200usecs.. ok (with a grumble) > if it's going to be 5mSec it is NOT ok.. > > netgraph itself does nothing that would block > (except one mutex that is guaranteed to be really quick > and is probably always satisfied in the 'spin' stage.) > we have thought about having multipel netgraph threads. > (and there is a patch to do this.. I don';t think it has been > added yet). so you are both right.. > a node should avoid doing a mutex if there is any chance that that > mutex may end up taking any real time to satisfy, due to mutex chaining > etc.) I almos think there should be a mutex type > that is called 'leaf' mutex. no other mutex may be taken > while it is held.. > In other words, you can use a mutex in Netgraph IFF you can guarantee > that all potential holders of the mutex will never acquire > any other locks or do anything that may take real time. > it's probably ok to take a lock to protect updating a statistics block > if you know that the only other holders will be the same code you are > writing, in another thread, and that that code will never need to do > anything except update the memory. > > So the question becomes. If HPS uses a mutex, what are the other users of > the mutex doing? my concern was primarily over USB_BUS_LOCK() that usb2 code uses internally. since the same bus can be shared between multiple devices, i assumed there would cases when "bad" device could potentially do things that would take some time while holding USB_BUS_LOCK(). in any case, scheduling task seemed like a right/safe thing to do. this way netgraph is protected from any delays. it also makes it less defendant on usb2 internals (i.e. we no longer need to make any assumptions about locks usb2 uses internally). thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:36:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09055106564A; Sat, 24 Jan 2009 23:36:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id BF1DE8FC1A; Sat, 24 Jan 2009 23:36:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5417674rvf.43 for ; Sat, 24 Jan 2009 15:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MAyZg6uZXFZzdlMZ31MTlxwaoisOxsO2xoqlapNZD/Y=; b=ekGYLA6R3HKDXjSPbCZV3ZPaH0HSTFcw3ucrl/NMRqykbgpQxhkweUGpOeLlQ8zSWp htfR12RomPUrRTqB5a/weB/FOhkWG1udjeUsnDSTdSdCjGAvLqCz3rxmkVGv/LiZ2Px5 37dk0nDjpH9O/5gpbqFegeJu0DuTLEgycGxwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pTtv420a7BAnB30zo9XUiDL+Yv9Qi11LhALMIrE8nyKSFAvAutMy1XBAAt5dwn1rVx zJyexipbnf9IEes9CfnyjWAsLrCFxWC4Kkn1rh6DCeW4o9IAqIeS4CjqJfsTjWwJfcid 60spTKcQNVJ0COJyh7fi8E741qQET0NgvrJ6w= MIME-Version: 1.0 Received: by 10.141.132.1 with SMTP id j1mr5911413rvn.282.1232840187592; Sat, 24 Jan 2009 15:36:27 -0800 (PST) In-Reply-To: <497BA473.6060007@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> <497BA473.6060007@elischer.org> Date: Sat, 24 Jan 2009 15:36:27 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:36:28 -0000 On Sat, Jan 24, 2009 at 3:29 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky >> wrote: >>> >>> On Saturday 24 January 2009, Maksim Yevmenkin wrote: >>>> >>>> Hans Petter, >>>> >>>> i'm sorry, did i mention there is no sleeping in netgraph? :-) >>> >>> Can you elaborate this? Is netgraph run from fast interrupt context? So >>> that >>> only spin locks are possible? Or is it run from a thread? >> >> i already told you that netgraph is essentially single-threaded. for >> all intents and purposes think that only _ONE_ thread services _ALL_ >> netgraph nodes. if something can not be done immediately, netgraph >> queues it and returns back to it later. _ANY_ delay/sleep would stall >> _ENTIRE_ netgraph. think poll/select/callback driven programming >> model. > > it depends on the delay. > if it's going to be 200usecs.. ok (with a grumble) > if it's going to be 5mSec it is NOT ok.. > > netgraph itself does nothing that would block > (except one mutex that is guaranteed to be really quick > and is probably always satisfied in the 'spin' stage.) > we have thought about having multipel netgraph threads. > (and there is a patch to do this.. I don';t think it has been > added yet). so you are both right.. > a node should avoid doing a mutex if there is any chance that that > mutex may end up taking any real time to satisfy, due to mutex chaining > etc.) I almos think there should be a mutex type > that is called 'leaf' mutex. no other mutex may be taken > while it is held.. > In other words, you can use a mutex in Netgraph IFF you can guarantee > that all potential holders of the mutex will never acquire > any other locks or do anything that may take real time. > it's probably ok to take a lock to protect updating a statistics block > if you know that the only other holders will be the same code you are > writing, in another thread, and that that code will never need to do > anything except update the memory. > > So the question becomes. If HPS uses a mutex, what are the other users of > the mutex doing? my concern was primarily over USB_BUS_LOCK() that usb2 code uses internally. since the same bus can be shared between multiple devices, i assumed there would cases when "bad" device could potentially do things that would take some time while holding USB_BUS_LOCK(). in any case, scheduling task seemed like a right/safe thing to do. this way netgraph is protected from any delays. it also makes it less defendant on usb2 internals (i.e. we no longer need to make any assumptions about locks usb2 uses internally). thanks, max