From owner-freebsd-amd64@FreeBSD.ORG Sun Oct 23 18:36:55 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 050B716A420; Sun, 23 Oct 2005 18:36:55 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B754B43D45; Sun, 23 Oct 2005 18:36:54 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9NIasMO002810; Sun, 23 Oct 2005 18:36:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9NIasC1002806; Sun, 23 Oct 2005 18:36:54 GMT (envelope-from linimon) Date: Sun, 23 Oct 2005 18:36:54 GMT From: Mark Linimon Message-Id: <200510231836.j9NIasC1002806@freefall.freebsd.org> To: wkwu.amd64@csie.nctu.edu.tw, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/71644: [panic] amd64 5.3-BETA4 crash when heavy load X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2005 18:36:55 -0000 Synopsis: [panic] amd64 5.3-BETA4 crash when heavy load State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Sun Oct 23 18:36:24 GMT 2005 State-Changed-Why: Feedback was received quite some time ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=71644 From owner-freebsd-amd64@FreeBSD.ORG Sun Oct 23 20:40:21 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8582516A41F for ; Sun, 23 Oct 2005 20:40:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D5DC43D48 for ; Sun, 23 Oct 2005 20:40:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9NKeKQv023017 for ; Sun, 23 Oct 2005 20:40:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9NKeKPF023016; Sun, 23 Oct 2005 20:40:20 GMT (envelope-from gnats) Resent-Date: Sun, 23 Oct 2005 20:40:20 GMT Resent-Message-Id: <200510232040.j9NKeKPF023016@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Sven Gaerner Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A164716A41F for ; Sun, 23 Oct 2005 20:38:49 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7432143D46 for ; Sun, 23 Oct 2005 20:38:49 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j9NKcnxo006738 for ; Sun, 23 Oct 2005 20:38:49 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j9NKcnCC006737; Sun, 23 Oct 2005 20:38:49 GMT (envelope-from nobody) Message-Id: <200510232038.j9NKcnCC006737@www.freebsd.org> Date: Sun, 23 Oct 2005 20:38:49 GMT From: Sven Gaerner To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/87882: emu10k1 and APCI on amd64 is just noisy X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2005 20:40:21 -0000 >Number: 87882 >Category: amd64 >Synopsis: emu10k1 and APCI on amd64 is just noisy >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 23 20:40:20 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Sven Gaerner >Release: 5.4-STABLE >Organization: >Environment: FreeBSD insomnia.shadow.local 5.4-STABLE FreeBSD 5.4-STABLE #11: Sun Oct 23 22:22:25 CEST 2005 root@insomnia.shadow.local:/usr/obj/usr/src/sys/INSOMNIA amd64 >Description: I build the kernel with snd_emu10k1 device support. When ACPI is enabled and I run 'esd -beeps' it's just noisy. Also playing WAV files with play doesn't work. When ACPI is disabled I can use the soundcard as expected. >How-To-Repeat: -build a kernel on amd64 with ACPI support -run 'esd -beeps' do the same with acpi disabled >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 01:50:09 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C90516A41F; Mon, 24 Oct 2005 01:50:08 +0000 (GMT) (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 6F04443D45; Mon, 24 Oct 2005 01:50:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9O1o7XP028776; Sun, 23 Oct 2005 21:50:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9O1o6IN027317; Sun, 23 Oct 2005 21:50:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B99E67302F; Sun, 23 Oct 2005 21:50:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051024015006.B99E67302F@freebsd-current.sentex.ca> Date: Sun, 23 Oct 2005 21:50:06 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 01:50:09 -0000 TB --- 2005-10-24 00:01:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-24 00:01:58 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-24 00:01:58 - cleaning the object tree TB --- 2005-10-24 00:02:37 - checking out the source tree TB --- 2005-10-24 00:02:37 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-24 00:02:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-24 00:09:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-24 00:09:39 - cd /src TB --- 2005-10-24 00:09:39 - /usr/bin/make -B buildworld >>> 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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-10-24 01:41:12 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-24 01:41:12 - cd /src TB --- 2005-10-24 01:41:12 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Oct 24 01:41:12 UTC 2005 >>> 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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/isa/vga_isa.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/kern/link_elf_obj.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/pci/agp_amd64.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/pci/agp_intel.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/amd64/ia32/ia32_reg.c In file included from /src/sys/amd64/ia32/ia32_reg.c:64: /src/sys/compat/freebsd32/freebsd32_proto.h:66: error: syntax error before "osigset_t" /src/sys/compat/freebsd32/freebsd32_proto.h:66: error: `osigset_t' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-24 01:50:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-24 01:50:06 - ERROR: failed to build generic kernel TB --- 2005-10-24 01:50:06 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 03:50:15 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79FE216A420 for ; Mon, 24 Oct 2005 03:50:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 816F643D46 for ; Mon, 24 Oct 2005 03:50:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9O3oEMk087057 for ; Mon, 24 Oct 2005 03:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9O3oEjc087056; Mon, 24 Oct 2005 03:50:14 GMT (envelope-from gnats) Resent-Date: Mon, 24 Oct 2005 03:50:14 GMT Resent-Message-Id: <200510240350.j9O3oEjc087056@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Chunwei Han Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575CC16A41F for ; Mon, 24 Oct 2005 03:47:14 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C4843D46 for ; Mon, 24 Oct 2005 03:47:14 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j9O3lDQR068342 for ; Mon, 24 Oct 2005 03:47:13 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j9O3lD49068341; Mon, 24 Oct 2005 03:47:13 GMT (envelope-from nobody) Message-Id: <200510240347.j9O3lD49068341@www.freebsd.org> Date: Mon, 24 Oct 2005 03:47:13 GMT From: Chunwei Han To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 03:50:15 -0000 >Number: 87898 >Category: amd64 >Synopsis: Failt to init X: can't open device/io >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 24 03:50:14 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Chunwei Han >Release: 6.0 RC1 >Organization: Peking University, P.R.China >Environment: FreeBSD 6.0 RC1 >Description: I have tried to compile the kernel with "device io" and "device mem" option but with no result Here is the output of /var/log/Xorg.0.log. *********************************************************************** X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: FreeBSD 6.0 amd64 [ELF] Current Operating System: FreeBSD 6.0-RC1 FreeBSD 6.0-RC1 #1: Mon Oct 24 00:33:51 CST 2005 /home/src/sys/amd64/compile/HERO amd64 Build Date: 02 October 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 24 00:41:05 2005 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Layout0" (**) |-->Input Device "Keyboard0" (**) Option "XkbModel" "pc104" (**) XKB: model: "pc104" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse0" (WW) The directory "/usr/X11R6/lib/X11/fonts/misc/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi/" does not exist. Entry deleted from font path. (==) FontPath set to "/usr/X11R6/lib/X11/fonts/TTF/" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) Using syscons driver with X support (version 549739036674.0) (--) using VT number 9 Fatal server error: xf86EnableIO: Failed to open /dev/io for extended I/O >How-To-Repeat: X >Fix: no >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 05:20:17 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78F6B16A437 for ; Mon, 24 Oct 2005 05:20:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 463CE43D45 for ; Mon, 24 Oct 2005 05:20:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9O5KHR6006069 for ; Mon, 24 Oct 2005 05:20:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9O5KH6j006068; Mon, 24 Oct 2005 05:20:17 GMT (envelope-from gnats) Date: Mon, 24 Oct 2005 05:20:17 GMT Message-Id: <200510240520.j9O5KH6j006068@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Eric Anholt Cc: Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Anholt List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 05:20:18 -0000 The following reply was made to PR amd64/87898; it has been noted by GNATS. From: Eric Anholt To: Chunwei Han Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/87898: Failt to init X: can't open device/io Date: Sun, 23 Oct 2005 22:16:33 -0700 --=-/yi0xpXgnCPhe8rVkQA7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable If you've been following -current, please follow /usr/src/UPDATING and add "device io" And "device mem" to your kernel config. If you've set securelevel (sysctl kern.securelevel) to a level higher than the default -1, please do not set it, as it's mutually exclusive with running an X Server. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-/yi0xpXgnCPhe8rVkQA7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDXG4xHUdvYGzw6vcRAoDuAKCYv/vcOyQ22A74TaqcdYPYSUlmcgCdEYdQ RJLHgnt6X1rHnEPi63Gcwi8= =lAvr -----END PGP SIGNATURE----- --=-/yi0xpXgnCPhe8rVkQA7-- From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 10:26:04 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8595A16A41F; Mon, 24 Oct 2005 10:26:04 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E83443D46; Mon, 24 Oct 2005 10:26:03 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ETzWk-000Nbc-Ed; Mon, 24 Oct 2005 12:26:02 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Oct 2005 12:26:02 +0200 From: Danny Braniss Message-ID: Cc: freebsd-amd64@FreeBSD.org Subject: em/amd64 on 6.0-RC1 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 10:26:04 -0000 I have been running this box (an Intel SR1435VP2/Xeon-NOCOMA), of which we have 6, under several different configurations to try and pin down some problems, initialy I suspected am-utils, but now it's almost certain the if_em. The problem is sometimes on i386, but always on amd64. it seems that the problem starts right after the em is re-initialized, after it was used via PXE to boot. Sniffing shows that the kernel sends a GETATTR, the server responds, but the client does not see it, and after some time it will resend, and so on ... pinging from the server to the client works. btw, booting off the local disk (not diskless/PXE) em works fine, though the logs seems a bit baffling: ... em0: no link ... got link DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 9 DHCPOFFER from 132.65.16.10 unknown dhcp option value 0xfc DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 132.65.16.10 unknown dhcp option value 0xfc bound to 132.65.16.104 -- renewal in 7200 seconds. lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 em0: flags=8843 mtu 1500 options=b inet6 fe80::20e:cff:fe6a:8973%em0 prefixlen 64 scopeid 0x1 inet 132.65.16.104 netmask 0xfffff000 broadcast 132.65.31.255 ether 00:0e:0c:6a:89:73 media: Ethernet autoselect status: no carrier **************** HU? ************* later on, ifconfig em0 shows that all is ok. danny From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 11:02:02 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A25A16A41F for ; Mon, 24 Oct 2005 11:02:02 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A7E43D45 for ; Mon, 24 Oct 2005 11:02:02 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9OB21Xr061885 for ; Mon, 24 Oct 2005 11:02:01 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9OB20Yl061872 for freebsd-amd64@freebsd.org; Mon, 24 Oct 2005 11:02:00 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Oct 2005 11:02:00 GMT Message-Id: <200510241102.j9OB20Yl061872@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 11:02:02 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 o [2005/08/09] amd64/84693 amd64 Keyboard not recognized during first step 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/09/12] amd64/71644 amd64 [panic] amd64 5.3-BETA4 crash when heavy o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 unarchiving /etc to msdos fs locks up amd o [2004/11/01] amd64/73369 amd64 on-board firewire unreliable with Asus K8 o [2004/11/07] amd64/73650 amd64 5.3-release panics on boot o [2004/11/10] amd64/73775 amd64 Kernel panic (trap 12) when booting with o [2004/11/16] amd64/74014 amd64 5.3-RELEASE-AMD64 freezes on boot during o [2004/12/05] amd64/74747 amd64 System panic on shutdown when process wil o [2004/12/18] amd64/75209 amd64 5.3-Release panics on attempted boot from o [2004/12/23] amd64/75417 amd64 ACPI: SATA Hard-disk o [2005/01/12] amd64/76136 amd64 system halts before reboot o [2005/01/17] amd64/76336 amd64 racoon/setkey -D cases instant "Fatal Tra o [2005/02/02] amd64/77011 amd64 consisten 5.3-p5 make crash on installwor o [2005/02/04] amd64/77101 amd64 Please include ULi M1689 LAN, SATA, and A o [2005/02/17] amd64/77629 amd64 aMule hardlocks AMD64 system o [2005/02/23] amd64/77949 amd64 Pb boot FreeBSD 64 o [2005/03/04] amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/p o [2005/03/07] amd64/78558 amd64 installation o [2005/03/14] amd64/78848 amd64 [sis] sis driver on FreeBSD 5.x does not o [2005/04/12] amd64/79813 amd64 Will not install/run on amd64 nForce 4 pl o [2005/04/19] amd64/80114 amd64 kldload snd_ich causes interrupt storm wh o [2005/05/06] amd64/80691 amd64 amd64 kernel hangs on load o [2005/05/14] amd64/81037 amd64 SATA problem o [2005/05/19] amd64/81272 amd64 JDK 1.5 port doesn't build. o [2005/05/20] amd64/81325 amd64 KLD if_ath.ko: depends on ath_hal - not a o [2005/05/28] amd64/81602 amd64 SATA crashes with parallel pcm access o [2005/06/09] amd64/82071 amd64 incorrect -march's parameter to build 32b o [2005/06/19] amd64/82425 amd64 fxp0: device timeout, fxp interface dies o [2005/06/23] amd64/82555 amd64 Kernel Panic - after i connect to my "amd o [2005/07/05] amd64/83005 amd64 Memory Occupied during installation of th o [2005/07/25] amd64/84027 amd64 if_nve gets stuck o [2005/08/12] amd64/84832 amd64 Installation crashes just at boot AMD64/ o [2005/08/14] amd64/84930 amd64 [msdosfs] something wrong with msdosfs on o [2005/08/18] amd64/85081 amd64 TeamSpeak o [2005/08/29] amd64/85431 amd64 AMD64 has short but temporary freezes (ha o [2005/08/29] amd64/85451 amd64 6.0-BETA3 lockups on AMD64 o [2005/09/13] amd64/86080 amd64 [radeon] [hang] radeon DRI causes system o [2005/09/16] amd64/86199 amd64 Missed AMD64 motherboard o [2005/09/23] amd64/86503 amd64 [atapicam] [panic] k3b crash the system l o [2005/10/08] amd64/87112 amd64 Boot problems on a 16 processor AMD64 com o [2005/10/09] amd64/87156 amd64 First Installation: Kernel crashes o [2005/10/11] amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Are o [2005/10/12] amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powe o [2005/10/12] amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD a [2005/10/12] amd64/87328 amd64 [boot] BTX halted error o [2005/10/12] amd64/87348 amd64 amd64+smp+startkde always crashing a [2005/10/14] amd64/87436 amd64 gui does not start on the ATI RS480 M2-IL o [2005/10/15] amd64/87472 amd64 I downloaded 5.4 and went to install it, o [2005/10/16] amd64/87514 amd64 6.0-CURRENT freezes machine using >4GB on o [2005/10/19] amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron o [2005/10/20] amd64/87748 amd64 can't initialize X o [2005/10/24] amd64/87898 amd64 Failt to init X: can't open device/io 56 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 [ti] ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/07/28] amd64/69709 amd64 ACPI enabled then floppy don't work (5.2. o [2004/08/15] amd64/70500 amd64 [bge] bge driver for 3Com 3C996B on amd64 o [2004/12/02] amd64/74608 amd64 [mpt] [hang] mpt hangs 5 minutes when boo o [2004/12/07] amd64/74811 amd64 df, nfs mount, negative Avail -> 32/64-bi o [2004/12/13] ports/75015 amd64 cvsup on amd64 coredumps with either runs o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/05/16] amd64/81089 amd64 [bge] [patch] FreeBSD 5.4 released versio o [2005/06/12] amd64/82178 amd64 missing 32bit subsystem o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported o [2005/07/20] amd64/83806 amd64 Can not comple /usr/src/lib/msun/amd64/fe o [2005/08/07] amd64/84652 amd64 kbdmap -r dumps core o [2005/08/20] amd64/85144 amd64 Asus K8S-MX mobo, integ LAN not recognize o [2005/09/02] amd64/85626 amd64 java/jdk15 compile error o [2005/09/06] amd64/85812 amd64 "Rebooting..." on serial console appears o [2005/09/07] amd64/85820 amd64 1.5 times slower performance with SCHED_U o [2005/09/17] amd64/86244 amd64 dfi nf4 ulta-d o [2005/10/23] amd64/87882 amd64 emu10k1 and APCI on amd64 is just noisy 20 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 13:57:25 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7BDD16A420 for ; Mon, 24 Oct 2005 13:57:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A60F43D49 for ; Mon, 24 Oct 2005 13:57:24 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9ODvI8M005175; Mon, 24 Oct 2005 07:57:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435CE83E.8070402@samsco.org> Date: Mon, 24 Oct 2005 07:57:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anholt References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> In-Reply-To: <200510240520.j9O5KH6j006068@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Mark Murray , freebsd-amd64@freebsd.org Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 13:57:25 -0000 I think that we should revert to making the mem and io devices present by default in the kernel. People are constantly tripping over the current scheme. We can define a kernel option (i.e. NO_IO_DEVICE) for those who specifically want to exclude it. Scott Eric Anholt wrote: > The following reply was made to PR amd64/87898; it has been noted by GNATS. > > From: Eric Anholt > To: Chunwei Han > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: amd64/87898: Failt to init X: can't open device/io > Date: Sun, 23 Oct 2005 22:16:33 -0700 > > --=-/yi0xpXgnCPhe8rVkQA7 > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > If you've been following -current, please follow /usr/src/UPDATING and > add "device io" And "device mem" to your kernel config. > > If you've set securelevel (sysctl kern.securelevel) to a level higher > than the default -1, please do not set it, as it's mutually exclusive > with running an X Server. > > --=20 > Eric Anholt eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > > --=-/yi0xpXgnCPhe8rVkQA7 > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (FreeBSD) > > iD8DBQBDXG4xHUdvYGzw6vcRAoDuAKCYv/vcOyQ22A74TaqcdYPYSUlmcgCdEYdQ > RJLHgnt6X1rHnEPi63Gcwi8= > =lAvr > -----END PGP SIGNATURE----- > > --=-/yi0xpXgnCPhe8rVkQA7-- > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Mon Oct 24 16:05:41 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18F7516A41F for ; Mon, 24 Oct 2005 16:05:41 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BE4643D45 for ; Mon, 24 Oct 2005 16:05:40 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb.matik.com.br (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.3/8.13.1) with ESMTP id j9OG5dID005618 for ; Mon, 24 Oct 2005 13:05:40 -0300 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-amd64@freebsd.org Date: Mon, 24 Oct 2005 14:05:32 -0300 User-Agent: KMail/1.8.2 References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> <435CE83E.8070402@samsco.org> In-Reply-To: <435CE83E.8070402@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510241405.32776.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 16:05:41 -0000 On Monday 24 October 2005 10:57, Scott Long wrote: > I think that we should revert to making the mem and io devices present > by default in the kernel. People are constantly tripping over the > current scheme. We can define a kernel option (i.e. NO_IO_DEVICE) for > those who specifically want to exclude it. > I think most are used to it already and overall both devices (io and mem) a= re=20 present in GENERIC Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Tue Oct 25 10:30:25 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6504016A420 for ; Tue, 25 Oct 2005 10:30:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 263CB43D58 for ; Tue, 25 Oct 2005 10:30:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9PAUF0f068821 for ; Tue, 25 Oct 2005 10:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9PAUFfU068811; Tue, 25 Oct 2005 10:30:15 GMT (envelope-from gnats) Resent-Date: Tue, 25 Oct 2005 10:30:15 GMT Resent-Message-Id: <200510251030.j9PAUFfU068811@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jacques Caron Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AED1016A41F for ; Tue, 25 Oct 2005 10:24:35 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7472F43D45 for ; Tue, 25 Oct 2005 10:24:35 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j9PAOZIC021885 for ; Tue, 25 Oct 2005 10:24:35 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j9PAOZ65021884; Tue, 25 Oct 2005 10:24:35 GMT (envelope-from nobody) Message-Id: <200510251024.j9PAOZ65021884@www.freebsd.org> Date: Tue, 25 Oct 2005 10:24:35 GMT From: Jacques Caron To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/87977: amd64 busdma dflt_lock called (by ata) if physmem>4G X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 10:30:25 -0000 >Number: 87977 >Category: amd64 >Synopsis: amd64 busdma dflt_lock called (by ata) if physmem>4G >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 25 10:30:15 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Jacques Caron >Release: 5.4 >Organization: Oxado >Environment: FreeBSD db4.fr1.oxado.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Thu Oct 20 23:46:49 UTC 2005 root@artemis.oxado.com:/usr/obj/usr/src/sys/SMP amd64 >Description: FreeBSD/amd64 5.4-RELEASE on Tyan K8SD Pro (S2882D) with two Opteron processors and 8 GB RAM, on-board SiI 3114 SATA controller and additional Promise SATA300TX4 SATA controller. 5.4-RELEASE was patched to add support for the Promise controller: diff -c sys/dev/ata/ata-chipset.c.orig sys/dev/ata/ata-chipset.c *** sys/dev/ata/ata-chipset.c.orig Wed May 11 17:15:35 2005 --- sys/dev/ata/ata-chipset.c Fri Sep 2 16:19:05 2005 *************** *** 1312,1317 **** --- 1312,1320 ---- { ATA_PDC20621, 0, PRMIO, PRSX4X, ATA_UDMA5, "Promise PDC20621" }, { ATA_PDC20622, 0, PRMIO, PRSX4X, ATA_SA150, "Promise PDC20622" }, { ATA_PDC40518, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40518" }, + { ATA_PDC40519, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40519" }, + { ATA_PDC40718, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40718" }, + { ATA_PDC40719, 0, PRMIO, PRSATA2, ATA_SA150, "Promise PDC40719" }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; uintptr_t devid = 0; diff -c sys/dev/ata/ata-pci.h.orig sys/dev/ata/ata-pci.h *** sys/dev/ata/ata-pci.h.orig Wed May 11 17:15:35 2005 --- sys/dev/ata/ata-pci.h Fri Sep 2 16:19:56 2005 *************** *** 180,185 **** --- 180,188 ---- #define ATA_PDC20579 0x3574105a #define ATA_PDC20580 0x3570105a #define ATA_PDC40518 0x3d18105a + #define ATA_PDC40519 0x3519105a + #define ATA_PDC40718 0x3d17105a + #define ATA_PDC40719 0x3515105a #define ATA_PDC20617 0x6617105a #define ATA_PDC20618 0x6626105a #define ATA_PDC20619 0x6629105a Any kind of serious I/O involving several of the Promise-based disks or a combination of the Promise-based disks and the SiI-based ones will cause a panic "busdma dflt_lock called". Any level of I/O on the SiI only apparently never causes the problem. Setting hw.physmem=3g in /boot/loader.conf apparently makes the problem go away, but I need the additional memory... Similar issues with other drivers are found here: http://www.monkey.org/freebsd/archive/freebsd-amd64/200411/msg00070.html and possibly here: http://www.mail-archive.com/freebsd-hardware@freebsd.org/msg00536.html It seems the issue is either in the busdma code, or the way the busdma code is used by those drivers. As an aside, fxp has a long delay during boot with 8G, but this goes away when hw.physmem is set to 3g. >How-To-Repeat: amd64 with 8G RAM and 4 disks on a Promise SATA300TX4, dd of=/dev/null if=/dev/ad12 bs=256000 & dd of=/dev/null if=/dev/ad14 bs=256000 & dd of=/dev/null if=/dev/ad16 bs=256000 & dd of=/dev/null if=/dev/ad18 bs=256000 & You will never get to the last one. >Fix: Workaround (not fix): set hw.physmem to less than 4G. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Tue Oct 25 18:08:45 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6766616A420 for ; Tue, 25 Oct 2005 18:08:45 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFFCB43D73 for ; Tue, 25 Oct 2005 18:08:41 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A0FA11A3C2E; Tue, 25 Oct 2005 11:08:41 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1BAC05121A; Tue, 25 Oct 2005 14:08:41 -0400 (EDT) Date: Tue, 25 Oct 2005 14:08:40 -0400 From: Kris Kennaway To: JoaoBR Message-ID: <20051025180840.GA48844@xor.obsecurity.org> References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> <435CE83E.8070402@samsco.org> <200510241405.32776.joao@matik.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <200510241405.32776.joao@matik.com.br> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 18:08:45 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2005 at 02:05:32PM -0300, JoaoBR wrote: > On Monday 24 October 2005 10:57, Scott Long wrote: > > I think that we should revert to making the mem and io devices present > > by default in the kernel. People are constantly tripping over the > > current scheme. We can define a kernel option (i.e. NO_IO_DEVICE) for > > those who specifically want to exclude it. > > >=20 > I think most are used to it already and overall both devices (io and mem)= are=20 > present in GENERIC You don't read support lists often enough, then :-) This comes up every day or two. Kris --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDXnSoWry0BWjoQKURAptgAKD4nzg1+66ytmdrXmV5dqFkSEtYRwCePnPs y43zEcUyW4/XONxSIpzoqb0= =CrFD -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-amd64@FreeBSD.ORG Tue Oct 25 19:51:28 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F115716A420 for ; Tue, 25 Oct 2005 19:51:28 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id A352443D53 for ; Tue, 25 Oct 2005 19:51:28 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 7E190B811 for ; Tue, 25 Oct 2005 15:51:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <20051025180840.GA48844@xor.obsecurity.org> References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> <435CE83E.8070402@samsco.org> <200510241405.32776.joao@matik.com.br> <20051025180840.GA48844@xor.obsecurity.org> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 25 Oct 2005 15:51:26 -0400 To: freebsd-amd64 List X-Mailer: Apple Mail (2.734) Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 19:51:29 -0000 On Oct 25, 2005, at 2:08 PM, Kris Kennaway wrote: >> >> I think most are used to it already and overall both devices (io >> and mem) are >> present in GENERIC >> > > You don't read support lists often enough, then :-) This comes up > every day or two. > > it caught me by surprise, too, when some commands were failing to run. google helped me out, though, because it is asked and answered so often... it should be more prominent in the UPGRADING file, though. i normally don't adjust my custom kernel config files between minor version releases. From owner-freebsd-amd64@FreeBSD.ORG Tue Oct 25 22:10:09 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF14316A41F for ; Tue, 25 Oct 2005 22:10:09 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264C043D49 for ; Tue, 25 Oct 2005 22:10:08 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9PMA3PR061723 for ; Wed, 26 Oct 2005 00:10:04 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 00:09:55 +0200 To: freebsd-amd64@freebsd.org From: Jacques Caron Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 22:10:10 -0000 Hi all, It seems there is a continuing story about bus_dma (or rather its use by drivers) and systems with more than 4 GB RAM. I submitted a pr for this issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=87977 I know it happens on amd64 machines, though after looking a bit further and trying to figure out the whole busdma thing, the issue might be more general (as busdma_machdep.c is exactly the same for i386 and amd64), but as it has been discussed around here a number of times and because there are probably more amd64 systems with more than 4 GB RAM than other types, I've selected this list, let me know if another list would be more suitable. What I understand (please correct me if I'm wrong) is that: - busdma will use bounce buffers when needed, and this includes the use of devices that are limited to 32-bit addressing (most of them, I would guess?) when there is more than 4 GB RAM - I'm not 100% sure, but it seems bounce buffers are a limited ressource (that's at least what sysctl -a | grep busdma tells me, and that really looks like a bottleneck, btw) - apparently busdma will defer the allocation of bounce buffers when there aren't enough available (and this can happen pretty quickly in some situations, though I haven't yet figured out the difference between the two zones): two simultaneous dd's from two disks with a large block size (bs=256000) will use up all available bounce buffer pages in zone1... - if that happens, busdma_swi will eventually call the lockfunc associated with the dma tag, and panic if none is defined Now, it seems that many drivers don't provide a lockfunc to bus_dma_tag_create. The commit log for the lockfunc addition says: "The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred." The problem is: what does this mean? How can a driver "ensure that bus_dmamap_load will not be deferred"? Calls to bus_dma_tag_create are not consistent in drivers: - some drivers are apparently cautious: twe will either have BUS_DMA_ALLOCNOW and no lockfunc, or no flags and use busdma_lock_mutex and Giant. Is this the right approach? - other drivers are *very* cautious: fxp will always use busdma_lock_mutex and Giant. - other drivers don't care at all: bge and ata never provide a lockfunc, and in most cases don't use any flags either. My (humble) opinion and a few questions: - clarification of the cases when a lockfunc is required or not is needed. I fear it is always needed unless the created tag is only used as a "parent" for others, or (maybe?) if BUS_DMA_ALLOCNOW is set. - an audit of bus_dma_tag_create calls in most drivers is needed, at least regarding lockfunc args (bge also has weird lowaddr/hiaddr, as has already been reported) - maybe the dflt_lock should actually use the Giant mutex by default rather than panicking - or maybe the lockfunc call in busdma_swi is not needed? I'm really not versed into kernelese, so I really have no idea - is using Giant the best option, or should each driver use a different mutex, or...? I will try a kernel with a modified ata driver with busdma_lock_mutex,&Giant where needed tomorrow and report back. I think that this will actually fix the issue, but I don't know if it might not cause other issues or degrade performance or if there is a better solution... Any hints welcome, Jacques. From owner-freebsd-amd64@FreeBSD.ORG Tue Oct 25 22:25:22 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE1D516A41F for ; Tue, 25 Oct 2005 22:25:22 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10DCF43D45 for ; Tue, 25 Oct 2005 22:25:21 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from [192.168.2.2] (nbc.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.3/8.13.1) with ESMTP id j9PLPMVN029924 for ; Tue, 25 Oct 2005 19:25:22 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-amd64@freebsd.org Date: Tue, 25 Oct 2005 20:25:11 -0300 User-Agent: KMail/1.8.2 References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> <20051025180840.GA48844@xor.obsecurity.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510252025.11989.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 22:25:22 -0000 On Tuesday 25 October 2005 16:51, Vivek Khera wrote: > > it caught me by surprise, too, when some commands were failing to > run. google helped me out, though, because it is asked and answered > so often... > > it should be more prominent in the UPGRADING file, though. i > normally don't adjust my custom kernel config files between minor > version releases. don't know and do not agree either ...=20 any version comes wit GENERIC and this changes are correctly adviced by bee= ing=20 set device io and mem in it we are talking 6.0 I guess and this was an issue from 5.2.1 to 5.3 so IMO y= our=20 claim is almost a year too late and this is not exactly an amd64-issue jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 03:57:09 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE89F16A41F; Wed, 26 Oct 2005 03:57:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6921543D4C; Wed, 26 Oct 2005 03:57:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9Q3v72o073822; Tue, 25 Oct 2005 23:57:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9Q3v8P1026241; Tue, 25 Oct 2005 23:57:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E50677302F; Tue, 25 Oct 2005 23:57:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051026035707.E50677302F@freebsd-current.sentex.ca> Date: Tue, 25 Oct 2005 23:57:07 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 03:57:10 -0000 TB --- 2005-10-26 02:02:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-26 02:02:53 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-26 02:02:53 - cleaning the object tree TB --- 2005-10-26 02:03:34 - checking out the source tree TB --- 2005-10-26 02:03:34 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-26 02:03:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-26 02:10:38 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-26 02:10:38 - cd /src TB --- 2005-10-26 02:10:38 - /usr/bin/make -B buildworld >>> 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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-10-26 03:43:33 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-26 03:43:33 - cd /src TB --- 2005-10-26 03:43:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 26 03:43:33 UTC 2005 >>> 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 [...] /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:648: error: (Each undeclared identifier is reported only once /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:648: error: for each function it appears in.) /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:685: warning: implicit declaration of function `ithread_remove_handler' /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:685: warning: nested extern declaration of `ithread_remove_handler' /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c: In function `bt3c_pccard_detach': /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:727: warning: nested extern declaration of `ithread_remove_handler' /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:685: warning: redundant redeclaration of 'ithread_remove_handler' /src/sys/modules/netgraph/bluetooth/bt3c/../../../../netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c:685: warning: previous implicit declaration of 'ithread_remove_handler' was here *** Error code 1 Stop in /src/sys/modules/netgraph/bluetooth/bt3c. *** Error code 1 Stop in /src/sys/modules/netgraph/bluetooth. *** Error code 1 Stop in /src/sys/modules/netgraph. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-26 03:57:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-26 03:57:07 - ERROR: failed to build generic kernel TB --- 2005-10-26 03:57:07 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 09:10:42 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAA0916A420; Wed, 26 Oct 2005 09:10:42 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (omega.nanophys.kth.se [130.237.35.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D2143D69; Wed, 26 Oct 2005 09:10:37 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (localhost [127.0.0.1]) by omega.nanophys.kth.se (8.13.4/8.13.1) with ESMTP id j9Q9APwM001468; Wed, 26 Oct 2005 11:10:25 +0200 (CEST) (envelope-from kono@kth.se) Received: from localhost (localhost [[UNIX: localhost]]) by omega.nanophys.kth.se (8.13.4/8.13.1/Submit) id j9Q9APMU001467; Wed, 26 Oct 2005 11:10:25 +0200 (CEST) (envelope-from kono@kth.se) X-Authentication-Warning: omega.nanophys.kth.se: kono set sender to kono@kth.se using -f From: Alexander Konovalenko Organization: KTH Date: Wed, 26 Oct 2005 11:10:24 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Disposition: inline To: kde-freebsd@freebsd.kde.org, freebsd-ports@freebsd.org, freebsd-amd64@freebsd.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200510261110.25207.kono@kth.se> Cc: Subject: xfig freezes on amd64 with KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kono@kth.se List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 09:10:42 -0000 Hello, recently I've got a problem with xfig 3.2.4 on amd64 FreeBSD 5.4 (STABLE) when running it under KDE 3.4.2, with other X managers it works fine After pressing any button on the left panel xfig freezes and CPU load goes up. However if I run the same xfig from the same amd64 machine remotely via SSH then it works. It could be something wrong with KDE or Xorg libraries after recent port upgrade... Any suggestions? -- /Alexander Konovalenko +46-8-5537-8142 (office) +46-7-3752-2116 http://daemon.nanophys.kth.se/~kono Royal Institute of Technology (KTH) Nanostructure Physics Department, Albanova Roslagstullsbacken 21 10691 Stockholm Sweden From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 10:34:57 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E11916A41F for ; Wed, 26 Oct 2005 10:34:57 +0000 (GMT) (envelope-from groot@kde.org) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D45F243D45 for ; Wed, 26 Oct 2005 10:34:56 +0000 (GMT) (envelope-from groot@kde.org) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost.englishbreakfastnetwork.org) by pandora.cs.kun.nl (8.13.5/5.2) with ESMTP id j9QAYoHH018881; Wed, 26 Oct 2005 12:34:50 +0200 (MEST) From: Adriaan de Groot To: freebsd-amd64@freebsd.org, kono@kth.se Date: Wed, 26 Oct 2005 12:34:50 +0200 User-Agent: KMail/1.8.92 References: <200510261110.25207.kono@kth.se> In-Reply-To: <200510261110.25207.kono@kth.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2010133.MAyTIWYvqg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510261234.50639.groot@kde.org> X-Spam-Score: -1.399 () BAYES_00,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 131.174.33.4 Cc: kde-freebsd@freebsd.kde.org Subject: Re: xfig freezes on amd64 with KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 10:34:57 -0000 --nextPart2010133.MAyTIWYvqg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 26 October 2005 11:10, Alexander Konovalenko wrote: > recently I've got a problem with xfig 3.2.4 on amd64 FreeBSD 5.4 (STABLE) > when running it under KDE 3.4.2, with other X managers it works fine > > After pressing any button on the left panel xfig freezes and CPU load goes > up. The same happened on i386; I didn't get around to debugging it properly. XF= ig=20 starts under KWin, does its splash screen, is responsive and you can use th= e=20 menus, but as soon as you click on one of the tools on the left hand side, = it=20 hangs. Under twm it's fine. There _are_ a few complaints to stderr on=20 startup, let me install it here and check ... Warning: Actions not found: StartScroll I remember that on the machine where it kept hanging, there were _more_=20 complains about missing Actions. Anyway, I don't think this is amd64=20 specific. =2D-=20 These are your friends - Adem GPG: FEA2 A3FE Adriaan de Groot --nextPart2010133.MAyTIWYvqg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDX1vKdqzuAf6io/4RAo8JAKCZ4uwMU1kGo5kPOS2WDsMiEnQObwCeJQeF O+JOXpcATP3Oi1yjk9EUwC0= =a8lr -----END PGP SIGNATURE----- --nextPart2010133.MAyTIWYvqg-- From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 11:33:34 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCEC216A426; Wed, 26 Oct 2005 11:33:34 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C37F43D49; Wed, 26 Oct 2005 11:33:32 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9QBXMrg007119; Wed, 26 Oct 2005 13:33:26 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 13:33:19 +0200 To: freebsd-amd64@freebsd.org From: Jacques Caron In-Reply-To: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafact ory.net> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: scottl@freebsd.org, sos@freebsd.org Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 11:33:34 -0000 Hi all, Continuing on this story... [I took the liberty of CC'ing Scott and Soren], pr is amd64/87977 though it finally isn't amd64-specific but >4GB-specific. There is really a big problem somewhere between ata and bus_dma for boxes with more than 4 GB RAM and more than 2 ata disks: * bounce buffers will be needed * ata will have bus_dma allocate bounce buffers: hw.busdma.zone1.total_bpages: 32 hw.busdma.zone1.free_bpages: 32 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 27718 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 * if I do a dd with a bs=256000, 16 bounce pages will be used (most of the time). As long as I stay on the same disk, no more pages will be used. * as soon as I access another disk (e.g. with another dd with the same bs=256000), another set of 16 pages will be used (bus_dma tags and maps are allocated on a per-channel basis), and all 32 bounce pages will be used (most of the time) * and if I try to access a third disk, more bounce pages are needed and: - one of ata_dmaalloc calls to bus_dma_tag_create has ALLOCNOW set - busdma_machdep will not allocate more bounce pages in that case (the limit is imposed by maxsize in that situation, which has already been reached) - ata_dmaalloc will fail - but some other bus_dma_tag_create call without ALLOCNOW set will still cause bounce pages to be allocated, but deferred, and the non-existent lockfunc to be called, and panic. Adding the standard lockfunc will (probably) solve the panic issue, but there will still be a problem with DMA in ata. The same problems most probably exist with many other drivers. I think we thus have two issues: - providing a lockfunc in nearly all bus_dma_tag_create calls (or have a better default than a panic) - allocating more bounce pages when needed in the ALLOCNOW case (with a logic similar to that used to allocate bounce pages in the non-ALLOCNOW case) Thoughts? Jacques. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 12:00:16 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE64616A41F; Wed, 26 Oct 2005 12:00:15 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A4AC43D45; Wed, 26 Oct 2005 12:00:15 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9QBxeGt081902; Wed, 26 Oct 2005 13:59:40 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Wed, 26 Oct 2005 14:00:12 +0200 To: Jacques Caron X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: scottl@FreeBSD.ORG, freebsd-amd64@FreeBSD.ORG Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 12:00:16 -0000 On 26/10/2005, at 13:33, Jacques Caron wrote: > Hi all, > > Continuing on this story... [I took the liberty of CC'ing Scott and =20= > Soren], pr is amd64/87977 though it finally isn't amd64-specific =20 > but >4GB-specific. > > There is really a big problem somewhere between ata and bus_dma for =20= > boxes with more than 4 GB RAM and more than 2 ata disks: > * bounce buffers will be needed > * ata will have bus_dma allocate bounce buffers: > hw.busdma.zone1.total_bpages: 32 > hw.busdma.zone1.free_bpages: 32 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.active_bpages: 0 > hw.busdma.zone1.total_bounced: 27718 > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.lowaddr: 0xffffffff > hw.busdma.zone1.alignment: 2 > hw.busdma.zone1.boundary: 65536 > > * if I do a dd with a bs=3D256000, 16 bounce pages will be used (most =20= > of the time). As long as I stay on the same disk, no more pages =20 > will be used. > * as soon as I access another disk (e.g. with another dd with the =20 > same bs=3D256000), another set of 16 pages will be used (bus_dma tags =20= > and maps are allocated on a per-channel basis), and all 32 bounce =20 > pages will be used (most of the time) > * and if I try to access a third disk, more bounce pages are needed =20= > and: > - one of ata_dmaalloc calls to bus_dma_tag_create has ALLOCNOW set > - busdma_machdep will not allocate more bounce pages in that case =20 > (the limit is imposed by maxsize in that situation, which has =20 > already been reached) > - ata_dmaalloc will fail > - but some other bus_dma_tag_create call without ALLOCNOW set will =20 > still cause bounce pages to be allocated, but deferred, and the non-=20= > existent lockfunc to be called, and panic. > > Adding the standard lockfunc will (probably) solve the panic issue, =20= > but there will still be a problem with DMA in ata. > > The same problems most probably exist with many other drivers. > > I think we thus have two issues: > - providing a lockfunc in nearly all bus_dma_tag_create calls (or =20 > have a better default than a panic) > - allocating more bounce pages when needed in the ALLOCNOW case =20 > (with a logic similar to that used to allocate bounce pages in the =20 > non-ALLOCNOW case) > > Thoughts? The below patch makes ATA always use the ALLOCNOW flag which actually =20= was intended. How to patch busdma I'll let scottl decide... Index: ata-dma.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v retrieving revision 1.138 diff -u -r1.138 ata-dma.c --- ata-dma.c 6 Oct 2005 15:44:07 -0000 1.138 +++ ata-dma.c 26 Oct 2005 11:56:15 -0000 @@ -102,13 +102,13 @@ BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, ch->dma->max_iosize, ATA_DMA_ENTRIES, ch->dma->segsize, - 0, NULL, NULL, &ch->dma->dmatag)) + BUS_DMA_ALLOCNOW, NULL, NULL, &ch->dma-=20 >dmatag)) goto error; if (bus_dma_tag_create(ch->dma->dmatag, PAGE_SIZE, PAGE_SIZE, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MAXTABSZ, 1, MAXTABSZ, - 0, NULL, NULL, &ch->dma->sg_tag)) + BUS_DMA_ALLOCNOW, NULL, NULL, &ch->dma-=20 >sg_tag)) goto error; if (bus_dma_tag_create(ch->dma->dmatag,ch->dma->alignment,ch-=20 >dma->boundary, @@ -135,7 +135,7 @@ if (bus_dma_tag_create(ch->dma->dmatag, PAGE_SIZE, 64 * 1024, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MAXWSPCSZ, 1, MAXWSPCSZ, - 0, NULL, NULL, &ch->dma->work_tag)) + BUS_DMA_ALLOCNOW, NULL, NULL, &ch->dma-=20 >work_tag)) goto error; if (bus_dmamem_alloc(ch->dma->work_tag, (void **)&ch->dma-=20 >work, 0, S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 13:56:40 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8E7C16A420 for ; Wed, 26 Oct 2005 13:56:40 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C86943D6D for ; Wed, 26 Oct 2005 13:56:32 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id C9136B80A for ; Wed, 26 Oct 2005 09:56:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <200510252025.11989.joao@matik.com.br> References: <200510240520.j9O5KH6j006068@freefall.freebsd.org> <20051025180840.GA48844@xor.obsecurity.org> <200510252025.11989.joao@matik.com.br> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AC768D9-B3DF-4C19-91AC-D1C9DC5646A3@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Wed, 26 Oct 2005 09:56:29 -0400 To: freebsd-amd64 List X-Mailer: Apple Mail (2.734) Subject: Re: amd64/87898: Failt to init X: can't open device/io X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 13:56:41 -0000 On Oct 25, 2005, at 7:25 PM, JoaoBR wrote: > any version comes wit GENERIC and this changes are correctly > adviced by beeing > set device io and mem in it > yes, but how many people replace their custom kernel with GENERIC on an upgrade from a minor version? > we are talking 6.0 I guess and this was an issue from 5.2.1 to 5.3 > so IMO your > claim is almost a year too late and this is not exactly an amd64-issue > my point was that changes like this should be documented more prominently. either that or 5.3 /really/ should have been called 6.0 due to the massive changes that went into it. and no it is not an amd64 issue, but the conversation is here, so I comment here. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 14:09:13 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81B9F16A41F; Wed, 26 Oct 2005 14:09:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEA2B43D5A; Wed, 26 Oct 2005 14:09:12 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QE9AZ5011970; Wed, 26 Oct 2005 08:09:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435F8E06.9060507@samsco.org> Date: Wed, 26 Oct 2005 08:09:10 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Caron References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> In-Reply-To: <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@freebsd.org, sos@freebsd.org Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 14:09:13 -0000 Jacques Caron wrote: > Hi all, > > Continuing on this story... [I took the liberty of CC'ing Scott and > Soren], pr is amd64/87977 though it finally isn't amd64-specific but > >4GB-specific. > > There is really a big problem somewhere between ata and bus_dma for > boxes with more than 4 GB RAM and more than 2 ata disks: > * bounce buffers will be needed > * ata will have bus_dma allocate bounce buffers: > hw.busdma.zone1.total_bpages: 32 > hw.busdma.zone1.free_bpages: 32 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.active_bpages: 0 > hw.busdma.zone1.total_bounced: 27718 > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.lowaddr: 0xffffffff > hw.busdma.zone1.alignment: 2 > hw.busdma.zone1.boundary: 65536 > > * if I do a dd with a bs=256000, 16 bounce pages will be used (most of > the time). As long as I stay on the same disk, no more pages will be used. > * as soon as I access another disk (e.g. with another dd with the same > bs=256000), another set of 16 pages will be used (bus_dma tags and maps > are allocated on a per-channel basis), and all 32 bounce pages will be > used (most of the time) > * and if I try to access a third disk, more bounce pages are needed and: > - one of ata_dmaalloc calls to bus_dma_tag_create has ALLOCNOW set > - busdma_machdep will not allocate more bounce pages in that case (the > limit is imposed by maxsize in that situation, which has already been > reached) > - ata_dmaalloc will fail > - but some other bus_dma_tag_create call without ALLOCNOW set will still > cause bounce pages to be allocated, but deferred, and the non-existent > lockfunc to be called, and panic. > > Adding the standard lockfunc will (probably) solve the panic issue, but > there will still be a problem with DMA in ata. Actually, it won't. It'll result in silent data corruption. What is happening is that bus_dmamap_load() is returning EINPROGRESS, but the ATA driver ignores it and assumes that the load failed. Later on the busdma subsystem tries to run the callback but trips over the intentional assertion. If the standard lock was used, then the callback would succeed and start spamming memory that either had been freed or is in the process of being used by other ATA commands. So, the panic is doing exactly what it is supposed to do. It's guarding against bugs in the driver. The workaround for this is to use the NOWAIT flag in all instances of bus_dmamap_load() where deferals can happen. This, however, means that using bounce pages still remains fragile and that the driver is still likely to return ENOMEM to the upper layers. C'est la vie, I guess. At one time I had patches that made ATA use the busdma API correctly (it is one of the few remaining that does not), but they rotted over time. > > The same problems most probably exist with many other drivers. > > I think we thus have two issues: > - providing a lockfunc in nearly all bus_dma_tag_create calls (or have a > better default than a panic) No. Some tags specifically should not permit deferals. A good example is tags for static memory that is allocated with bus_dmamem_alloc(). Just about every other modern driver honors the API correctly. iir is one exception that I can think of, but it'll require a significant rewrite to fix. > - allocating more bounce pages when needed in the ALLOCNOW case (with a > logic similar to that used to allocate bounce pages in the non-ALLOCNOW > case) Bounce pages cannot be reclaimed to the system, so overallocating just wastes memory. The whole point of the deferal mechanism is to allow you to allocate enough pages for a normal load while also being able to handle sporadic spikes in load (like when the syncer runs) without trapping memory. Eight years of use has shown this to be a good strategy; FreeBSD continues to perform better under memory pressure than other operating systems like Linux. Scott From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 14:09:56 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83C7A16A41F for ; Wed, 26 Oct 2005 14:09:56 +0000 (GMT) (envelope-from kp@west-call.com) Received: from r3.mxs.WestCall.Ru (r3.mxs.WestCall.Ru [195.94.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA8B43D6E for ; Wed, 26 Oct 2005 14:09:55 +0000 (GMT) (envelope-from kp@west-call.com) Received: from rumata.west-call.com (rumata.west-call.com [195.94.224.203]) (authenticated as kp bits=0) by r3.mxs.WestCall.Ru (8.12.7-V/8.12.5-V) with ESMTP id j9QE9rMu096346 for ; Wed, 26 Oct 2005 18:09:53 +0400 (MSD) Date: Wed, 26 Oct 2005 18:09:55 +0400 From: Pavel Kovalenko To: freebsd-amd64@freebsd.org Message-Id: <20051026180955.2cdda6f7.kp@west-call.com> Organization: west-call X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Spinlock problem in 7.0-CURRENT amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 14:09:56 -0000 I cvsuped last week, and since then I've installed mplayer from the ports, I receive following error: >mplayer KVN_Vinni_puh.mp3 Fatal error 'Spinlock called when not threaded.' at line 87 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) Abort (core dumped) >gdb mplayer -core=mplayer.core 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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `mplayer'. Program terminated with signal 6, Aborted. #0 0x000000080412023c in kill () from /lib/libc.so.6 [New LWP 100163] (gdb) backtrace #0 0x000000080412023c in kill () from /lib/libc.so.6 #1 0x000000080389549d in raise () from /usr/lib/libpthread.so.2 #2 0x000000080411f10c in abort () from /lib/libc.so.6 #3 0x00000008038ac4d8 in pthread_testcancel () from /usr/lib/libpthread.so.2 #4 0x00000008038989e8 in _spinlock () from /usr/lib/libpthread.so.2 #5 0x0000000803898a39 in _spinlock_debug () from /usr/lib/libpthread.so.2 #6 0x00000008048d00ff in _thread_fd_table_init () from /usr/lib/libc_r.so.5 #7 0x00000008048ce6f1 in _thread_init () from /usr/lib/libc_r.so.5 #8 0x00000008048c4179 in _thread_init_hack () from /usr/lib/libc_r.so.5 #9 0x00000008048d13c2 in _find_thread () from /usr/lib/libc_r.so.5 #10 0x00000008048c092e in _init () from /usr/lib/libc_r.so.5 #11 0x0000000804f5be62 in _init () from /usr/local/lib/compat/pkg/libintl.so.5 #12 0x0000000800b0a8ca in find_symdef () from /libexec/ld-elf.so.1 #13 0x0000000800b09499 in _rtld () from /libexec/ld-elf.so.1 #14 0x0000000800b08789 in .rtld_start () from /libexec/ld-elf.so.1 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () ... etc. after googling the problem, I've try to add this in /etc/libmap.conf: libc_r.so.6 libpthread.so.2 libc_r.so.5 libpthread.so.1 libc_r.so libpthread.so and try again: >mplayer KVN_Vinni_puh.mp3 MPlayer 1.0pre7try2-3.4.4 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices (Family: 8, Stepping: 0) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing KVN_Vinni_puh.mp3. XMMS: found plugin: libcdaudio.so (CD Audio Player 1.2.10) XMMS: found plugin: libmpg123.so (MPEG Layer 1/2/3 Player 1.2.10) XMMS: found plugin: libtonegen.so (Tone Generator 1.2.10) XMMS: found plugin: libwav.so (Wave Player 1.2.10) XMMS: found plugin: libmikmod.so (MikMod Player 1.2.10) XMMS: found plugin: libvorbis.so (Ogg Vorbis Player 1.2.10) Waiting for the XMMS plugin to start playback of 'KVN_Vinni_puh.mp3'... Audio file detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400) Selected audio codec: [pcm] afm:pcm (Uncompressed PCM) ========================================================================== Checking audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le... AF_pre: 44100Hz/2ch/s16le AO: [oss] 44100Hz 2ch s16le (2 bps) Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le... Video: no video Starting playback... A: 1.9 (01.8) 8.5% Fatal error 'kse_exit() failed for system scope thread' at line 1215 in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 22) I've googled again, but hasn't found any suitable solution. Is there any way to solve this problem? mplayer for FreeBSD 5_4 i386 works fine. Any help greatly appreciated... -- Cheers, Pavel. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 15:11:20 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C435116A41F for ; Wed, 26 Oct 2005 15:11:20 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4073143D45 for ; Wed, 26 Oct 2005 15:11:20 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9QFAg8e083943; Wed, 26 Oct 2005 17:10:42 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <435F8E06.9060507@samsco.org> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Wed, 26 Oct 2005 17:11:14 +0200 To: Scott Long X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-amd64@FreeBSD.ORG Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 15:11:21 -0000 On 26/10/2005, at 16:09, Scott Long wrote: > Jacques Caron wrote: >> Hi all, >> Continuing on this story... [I took the liberty of CC'ing Scott =20 >> and Soren], pr is amd64/87977 though it finally isn't amd64-=20 >> specific but >4GB-specific. >> There is really a big problem somewhere between ata and bus_dma =20 >> for boxes with more than 4 GB RAM and more than 2 ata disks: >> * bounce buffers will be needed >> * ata will have bus_dma allocate bounce buffers: >> hw.busdma.zone1.total_bpages: 32 >> hw.busdma.zone1.free_bpages: 32 >> hw.busdma.zone1.reserved_bpages: 0 >> hw.busdma.zone1.active_bpages: 0 >> hw.busdma.zone1.total_bounced: 27718 >> hw.busdma.zone1.total_deferred: 0 >> hw.busdma.zone1.lowaddr: 0xffffffff >> hw.busdma.zone1.alignment: 2 >> hw.busdma.zone1.boundary: 65536 >> * if I do a dd with a bs=3D256000, 16 bounce pages will be used =20 >> (most of the time). As long as I stay on the same disk, no more =20 >> pages will be used. >> * as soon as I access another disk (e.g. with another dd with the =20 >> same bs=3D256000), another set of 16 pages will be used (bus_dma =20 >> tags and maps are allocated on a per-channel basis), and all 32 =20 >> bounce pages will be used (most of the time) >> * and if I try to access a third disk, more bounce pages are =20 >> needed and: >> - one of ata_dmaalloc calls to bus_dma_tag_create has ALLOCNOW set >> - busdma_machdep will not allocate more bounce pages in that case =20 >> (the limit is imposed by maxsize in that situation, which has =20 >> already been reached) >> - ata_dmaalloc will fail >> - but some other bus_dma_tag_create call without ALLOCNOW set will =20= >> still cause bounce pages to be allocated, but deferred, and the =20 >> non-existent lockfunc to be called, and panic. >> Adding the standard lockfunc will (probably) solve the panic =20 >> issue, but there will still be a problem with DMA in ata. >> > > Actually, it won't. It'll result in silent data corruption. What is > happening is that bus_dmamap_load() is returning EINPROGRESS, but the > ATA driver ignores it and assumes that the load failed. Later on the > busdma subsystem tries to run the callback but trips over the =20 > intentional assertion. If the standard lock was used, then the =20 > callback > would succeed and start spamming memory that either had been freed or > is in the process of being used by other ATA commands. Ehm, according to the man page the load should succed for at least =20 one map when the ALLOCNOW flag is set. ATA only use one map so there =20 is no way that spamming can happen. The bug i ATA is that the sg_tag and the work_tag is not created with =20= the ALLOCNOW flag so if all resources are used before they are called =20= things get messy. The below patch takes care of that problem. > So, the panic is doing exactly what it is supposed to do. It's =20 > guarding > against bugs in the driver. The workaround for this is to use the =20 > NOWAIT flag in all instances of bus_dmamap_load() where deferals can > happen. This, however, means that using bounce pages still remains =20= > fragile and that the driver is still likely to return ENOMEM to the =20= > upper layers. C'est la vie, I guess. At one time I had patches that > made ATA use the busdma API correctly (it is one of the few remaining > that does not), but they rotted over time. As long as ATA doesn't do tags there is no gain by changing this at =20 all except spamming the code with all the callback crap thats not =20 needed. According to the man page bus_dmamap_load takes no flags, so thats =20 why thats not done. Besides its not needed as shown above. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 15:46:49 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75F0E16A41F for ; Wed, 26 Oct 2005 15:46:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0CA943D46 for ; Wed, 26 Oct 2005 15:46:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 26 Oct 2005 12:03:33 -0400 From: John Baldwin To: freebsd-amd64@freebsd.org Date: Wed, 26 Oct 2005 11:37:51 -0400 User-Agent: KMail/1.8.2 References: <20051026180955.2cdda6f7.kp@west-call.com> In-Reply-To: <20051026180955.2cdda6f7.kp@west-call.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261137.52717.jhb@freebsd.org> Cc: Pavel Kovalenko Subject: Re: Spinlock problem in 7.0-CURRENT amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 15:46:49 -0000 On Wednesday 26 October 2005 10:09 am, Pavel Kovalenko wrote: > I cvsuped last week, and since then I've installed mplayer from the ports, I receive following error: > >mplayer KVN_Vinni_puh.mp3 Do ldd on mplayer. It is probably linked againts two thread libraries because one of its libraries is linked against one and mplayer itself is linked against another. Try rebuilding mplayer and its dependencies from source. You might also see that mplayer is linked against two versions of the same library due to the recent bump_every_library_in_the_system madness, in which case rebuilding mplayer and its dependencies will fix that as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 15:48:21 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BEF316A41F; Wed, 26 Oct 2005 15:48:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E79B43D45; Wed, 26 Oct 2005 15:48:19 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QFmI30023221; Wed, 26 Oct 2005 09:48:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435FA542.3030209@samsco.org> Date: Wed, 26 Oct 2005 09:48:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> In-Reply-To: <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@FreeBSD.ORG Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 15:48:21 -0000 Søren Schmidt wrote: > On 26/10/2005, at 16:09, Scott Long wrote: > >> Jacques Caron wrote: >> >>> Hi all, >>> Continuing on this story... [I took the liberty of CC'ing Scott and >>> Soren], pr is amd64/87977 though it finally isn't amd64- specific >>> but >4GB-specific. >>> There is really a big problem somewhere between ata and bus_dma for >>> boxes with more than 4 GB RAM and more than 2 ata disks: >>> * bounce buffers will be needed >>> * ata will have bus_dma allocate bounce buffers: >>> hw.busdma.zone1.total_bpages: 32 >>> hw.busdma.zone1.free_bpages: 32 >>> hw.busdma.zone1.reserved_bpages: 0 >>> hw.busdma.zone1.active_bpages: 0 >>> hw.busdma.zone1.total_bounced: 27718 >>> hw.busdma.zone1.total_deferred: 0 >>> hw.busdma.zone1.lowaddr: 0xffffffff >>> hw.busdma.zone1.alignment: 2 >>> hw.busdma.zone1.boundary: 65536 >>> * if I do a dd with a bs=256000, 16 bounce pages will be used (most >>> of the time). As long as I stay on the same disk, no more pages will >>> be used. >>> * as soon as I access another disk (e.g. with another dd with the >>> same bs=256000), another set of 16 pages will be used (bus_dma tags >>> and maps are allocated on a per-channel basis), and all 32 bounce >>> pages will be used (most of the time) >>> * and if I try to access a third disk, more bounce pages are needed >>> and: >>> - one of ata_dmaalloc calls to bus_dma_tag_create has ALLOCNOW set >>> - busdma_machdep will not allocate more bounce pages in that case >>> (the limit is imposed by maxsize in that situation, which has >>> already been reached) >>> - ata_dmaalloc will fail >>> - but some other bus_dma_tag_create call without ALLOCNOW set will >>> still cause bounce pages to be allocated, but deferred, and the >>> non-existent lockfunc to be called, and panic. >>> Adding the standard lockfunc will (probably) solve the panic issue, >>> but there will still be a problem with DMA in ata. >>> >> >> Actually, it won't. It'll result in silent data corruption. What is >> happening is that bus_dmamap_load() is returning EINPROGRESS, but the >> ATA driver ignores it and assumes that the load failed. Later on the >> busdma subsystem tries to run the callback but trips over the >> intentional assertion. If the standard lock was used, then the callback >> would succeed and start spamming memory that either had been freed or >> is in the process of being used by other ATA commands. > > > Ehm, according to the man page the load should succed for at least one > map when the ALLOCNOW flag is set. ATA only use one map so there is no > way that spamming can happen. > The bug i ATA is that the sg_tag and the work_tag is not created with > the ALLOCNOW flag so if all resources are used before they are called > things get messy. The below patch takes care of that problem. All ALLOCNOW does is guarantee that there are enough bounce pages for one consumer of the bounce zone to succeed. Bounce pages are pooled into zones that correspond to similar attributes. If you create a bunch of tags that have similar attributes, then they'll map to the same zone and you won't necessarily get more pages pre-allocated to that zone. Not well documented, I know. The justification for this behaviour is to prevent excessive amounts of RAM from being reserved by careless drivers. The pools can grow when maps are created, though. > >> So, the panic is doing exactly what it is supposed to do. It's guarding >> against bugs in the driver. The workaround for this is to use the >> NOWAIT flag in all instances of bus_dmamap_load() where deferals can >> happen. This, however, means that using bounce pages still remains >> fragile and that the driver is still likely to return ENOMEM to the >> upper layers. C'est la vie, I guess. At one time I had patches that >> made ATA use the busdma API correctly (it is one of the few remaining >> that does not), but they rotted over time. > > > As long as ATA doesn't do tags there is no gain by changing this at all > except spamming the code with all the callback crap thats not needed. > According to the man page bus_dmamap_load takes no flags, so thats why > thats not done. Besides its not needed as shown above. Ah, you're right, it's not documented. I'll fix that. FYI, if you specify BUS_DMA_NOWAIT as the flag, it'll return ENOMEM if bounce pages are required but not immediately available. It's been this way for years, but never documented. The perils of porting a manpage from NetBSD without doing a single bit of sanity checking or understanding on it =-( As for the callbacks, you're already using them. They are there to make driver more robust in the face of resource shortages. 8-10 years ago it was about dealing with the 16MB limit of ISA, now it's about dealing with the 4GB limit of 32-bit devices. Re-arranging the code to use it correctly is not hard, and I've published a number of pieces on how to do it. There are also ample examples in the source tree, with the only incorrect ones being those that are no longer popular enough to warrant the work. The API has been around since FreeBSD 3.0, so it's nothing new. Scott > > Søren Schmidt > sos@FreeBSD.org > > > From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 16:01:53 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC5AF16A41F; Wed, 26 Oct 2005 16:01:52 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C4043D4C; Wed, 26 Oct 2005 16:01:51 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9QG1kka034893; Wed, 26 Oct 2005 18:01:48 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051026163501.03b7d3e8@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 18:01:34 +0200 To: Scott Long From: Jacques Caron In-Reply-To: <435F8E06.9060507@samsco.org> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-amd64@freebsd.org, sos@freebsd.org Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 16:01:53 -0000 Hi Scott, Thanks for the input. I'm utterly lost in unknown terrain, but I'm trying to understand... At 16:09 26/10/2005, Scott Long wrote: >So, the panic is doing exactly what it is supposed to do. It's guarding >against bugs in the driver. The workaround for this is to use the >NOWAIT flag in all instances of bus_dmamap_load() where deferals can >happen. As pointed out by Soren, this is not documented in man bus_dma :-/ It says bus_dmamap_load flags are supposed to be 0, and BUS_DMA_ALLOCNOW should be set at tag creation to avoid EINPROGRESS. I'm not sure the two would actually be equivalent, either. And from what I understand, even a call to bus_dma_tag_create with BUS_DMA_ALLOCNOW can be successful but not actually allocate what will be needed later (see below). > This, however, means that using bounce pages still remains > fragile and that the driver is still likely to return ENOMEM to the > upper layers. C'est la vie, I guess. At one time I had patches that >made ATA use the busdma API correctly (it is one of the few remaining >that does not), but they rotted over time. So what would be the "correct" way? Move the part that's after the DMA setup in the callback? I suppose there are limitations as to what can happen in the callback, though, so it would complicate things quite a bit. Obviously, a lockfunc would be needed in this situation, right? Also, I believe many other drivers just have lots of BUS_DMA_ALLOCNOW or BUS_DMA_NOWAIT all over the place, I'm not sure that's the "correct" way, is it? >No. Some tags specifically should not permit deferals. How do they do that? Setting BUS_DMA_ALLOCNOW in the tag, or BUS_DMA_NOWAIT in the map_load, or both, or something else? What should make one decide when deferrals should not be permitted? It is my impression that quite a few drivers happily decide they don't like deferrals at all whatever happens... >Just about every other modern driver honors the API correctly. Depends what you mean by "correctly". I'm not sure using BUS_DMA_NOWAIT is the right way to go as it fails if there is contention for bounce buffers. >Bounce pages cannot be reclaimed to the system, so overallocating just >wastes memory. I'm not talking about over-allocating, but rather allocating what is needed: I don't understand why bus_dma_tag_create limits the total number of bounce pages in a bounce zone to maxsize if BUS_DMA_ALLOCNOW is set (which prevents bus_dmamap_create from allocating any further bounce pages as long as there's only one map per tag, which seems pretty common), while bus_dmamap_create will allocate maxsize additional pages if BUS_DMA_ALLOCNOW was not set. The end result is that the ata driver is limited to 32 bounce pages whatever the number of instances (I guess that's channels, or disks?), while other drivers get hundreds of bounce pages which they hardly use. Maybe this is intended and it's just the way the ata driver uses tags and maps that is wrong, maybe it's the busdma logic that is wrong, I don't know... > The whole point of the deferal mechanism is to allow >you to allocate enough pages for a normal load while also being able to >handle sporadic spikes in load (like when the syncer runs) without >trapping memory. In this case 32 bounce pages (out of 8 GB RAM) for 6 disks seems like a very tight bottleneck to me. Jacques. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 16:29:30 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A6516A41F; Wed, 26 Oct 2005 16:29:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7915543D66; Wed, 26 Oct 2005 16:29:24 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QGTMwJ027963; Wed, 26 Oct 2005 10:29:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435FAEE1.6000506@samsco.org> Date: Wed, 26 Oct 2005 10:29:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Caron References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <6.2.3.4.0.20051026163501.03b7d3e8@wheresmymailserver.com> In-Reply-To: <6.2.3.4.0.20051026163501.03b7d3e8@wheresmymailserver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@freebsd.org, sos@freebsd.org Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 16:29:30 -0000 Jacques Caron wrote: > Hi Scott, > > Thanks for the input. I'm utterly lost in unknown terrain, but I'm > trying to understand... > > At 16:09 26/10/2005, Scott Long wrote: > >> So, the panic is doing exactly what it is supposed to do. It's guarding >> against bugs in the driver. The workaround for this is to use the >> NOWAIT flag in all instances of bus_dmamap_load() where deferals can >> happen. > > > As pointed out by Soren, this is not documented in man bus_dma :-/ It > says bus_dmamap_load flags are supposed to be 0, and BUS_DMA_ALLOCNOW > should be set at tag creation to avoid EINPROGRESS. I'm not sure the two > would actually be equivalent, either. They are not. The point of the ALLOCNOW flag is to try to avoid mallocing buffers later when the map is created. It's not the solution to any problem, just a shortcut. It's really only useful for drivers that allocate maps on the fly instead of pre-allocating them. > And from what I understand, even a > call to bus_dma_tag_create with BUS_DMA_ALLOCNOW can be successful but > not actually allocate what will be needed later (see below). Like I replied to Soeren, each bounce zone is guaranteed to have enough pages for one transaction by one consumer. Allocating more maps can increase the size of the pool, but allocating more tags cannot. Again, this is to guard against over-allocation. busdma doesn't know whether a tag will be used for static buffers or dynamic buffers, and static buffers tend to be large and not require a map or bouncing. It used to be that bus_dma_tag_create() would always increase the page allocation in the zone, but then we got into problems with drivers wanting large static allocations and fooling busdma into exhausting physical memory by allocating too many bounce pages, non of which were needed. Another approach that I've been considering is adding a BUS_DMA_STATICMAP flag bus_dma_tag_create() that tells it to not allocate bounce pages and not allow deferals. Then the bounce page limit heuristics can be removed from tags that don't have that flag, and the code will be more simple and predictable. But, since any time you touch busdma you have to consider many dozens of drivers, it's not something that I'm ready to do without more thought. > >> This, however, means that using bounce pages still remains fragile >> and that the driver is still likely to return ENOMEM to the upper >> layers. C'est la vie, I guess. At one time I had patches that >> made ATA use the busdma API correctly (it is one of the few remaining >> that does not), but they rotted over time. > > > So what would be the "correct" way? Move the part that's after the DMA > setup in the callback? I suppose there are limitations as to what can > happen in the callback, though, so it would complicate things quite a bit. > > Obviously, a lockfunc would be needed in this situation, right? I sent a long email on this on Dec 14, 2004. I'll pull it up and forward it out. What I really should do is publish a definitive article on the whole topic. As for 'limitations as to what can happen in the callback', there are none if you use the correct code structure. > > Also, I believe many other drivers just have lots of BUS_DMA_ALLOCNOW or > BUS_DMA_NOWAIT all over the place, I'm not sure that's the "correct" > way, is it? Most network drivers use these because they prefer to handle the ENOMEM case rather than handle the possibility of out-of-order packets caused by deferals (though this is really not possible; busdma guards against it). The network stack is designed to handle loss both on the trasmitting end as well as the receiving end, unlike the storage layer. Keep in mind that this discussion started with talking about ATA =-) > >> No. Some tags specifically should not permit deferals. > > > How do they do that? Setting BUS_DMA_ALLOCNOW in the tag, or > BUS_DMA_NOWAIT in the map_load, or both, or something else? They set it by using NULL as the lockfunc. > What should > make one decide when deferrals should not be permitted? Static allocations should never require bouncing, and thus should never have a deferal. The assertion is there to make sure that a driver doesn't accidentally try to use a tag created for static buffers for dynamic buffers. > It is my > impression that quite a few drivers happily decide they don't like > deferrals at all whatever happens... Again, these are mostly network drivers, and the network stack is designed to reliably handle this. The storage stack tries a little bit to handle it, but it's not reliable. Nor should it have to handle it; direct I/O _must_always_succeed_. What if you're out of RAM and the VM system tries to write some pages to swap in order to free up RAM, but those writes fail on ENOMEM? Again, FreeBSD has shown excellent handling in high memory pressure situations over the years where other OS's die horribly. This is one of the reasons why. > >> Just about every other modern driver honors the API correctly. > > > Depends what you mean by "correctly". I'm not sure using BUS_DMA_NOWAIT > is the right way to go as it fails if there is contention for bounce > buffers. > >> Bounce pages cannot be reclaimed to the system, so overallocating just >> wastes memory. > > > I'm not talking about over-allocating, but rather allocating what is > needed: I don't understand why bus_dma_tag_create limits the total > number of bounce pages in a bounce zone to maxsize if BUS_DMA_ALLOCNOW > is set (which prevents bus_dmamap_create from allocating any further > bounce pages as long as there's only one map per tag, which seems pretty > common), while bus_dmamap_create will allocate maxsize additional pages > if BUS_DMA_ALLOCNOW was not set. Actually, one map per tag is not common. If the ATA driver supported tagged queuing (which I assume that it will someday for SATAII, yes?) then it would have multiple maps. Just about every other modern block driver supports multiple concurrent transactions and thus multiple maps. > > The end result is that the ata driver is limited to 32 bounce pages > whatever the number of instances (I guess that's channels, or disks?), > while other drivers get hundreds of bounce pages which they hardly use. > Maybe this is intended and it's just the way the ata driver uses tags > and maps that is wrong, maybe it's the busdma logic that is wrong, I > don't know... If a map is being created for every drive in the system, and the result is that not enough bounce pages are being reserved for all three drives to operate concurrently, then there might be a bug in busdma. We should discuss this offline. > >> The whole point of the deferal mechanism is to allow >> you to allocate enough pages for a normal load while also being able to >> handle sporadic spikes in load (like when the syncer runs) without >> trapping memory. > > > In this case 32 bounce pages (out of 8 GB RAM) for 6 disks seems like a > very tight bottleneck to me. If that's all that is needed to saturate non-tagged ATA, then there is nothing wrong with that. But once tagged queuing comes into the picture, more resources will need to be reserved of course. This should all just work, since it works for other drivers, but I'm happy to help investigate bugs. Scott From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 16:57:28 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B16B16A41F; Wed, 26 Oct 2005 16:57:28 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2399043D48; Wed, 26 Oct 2005 16:57:26 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9QGvKQx040469; Wed, 26 Oct 2005 18:57:23 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 18:34:57 +0200 To: Scott Long From: Jacques Caron In-Reply-To: <435FA542.3030209@samsco.org> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> <435FA542.3030209@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-amd64@FreeBSD.ORG, Søren Schmidt Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 16:57:28 -0000 Hi again Scott, At 17:48 26/10/2005, Scott Long wrote: >All ALLOCNOW does is guarantee that there are enough bounce pages >for one consumer of the bounce zone to succeed. Bounce pages are >pooled into zones that correspond to similar attributes. If you create a >bunch of tags that have similar attributes, then they'll map to the >same zone and you won't necessarily get more pages pre-allocated to >that zone. Not well documented, I know. The justification for this >behaviour is to prevent excessive amounts of RAM from being reserved >by careless drivers. The pools can grow when maps are created, though. As stated in my other post, if I undertand the busdma code correctly, additional pages will not be allocated if ALLOCNOW was set unless it's an additional map on the same tag. So the first map on a tag will not get any additional pages, and if other tags (created by other instances of the same driver, thus hitting the same bounce zones) have already used all pre-allocated pages, no more pages will be allocated, and hence a deferral happens even though the number of bounce pages is still very low and way way lower than maxpages. >As for the callbacks, you're already using them. They are used, but in a minimalist way, the rest of the processing is not deferred until the callback is called, this may require quite a bit more work. >Re-arranging the code to use it >correctly is not hard, and I've published a number of pieces on how to >do it. Do you have pointers? I've been looking quite a bit for documentation about bus_dma, and it's quite scattered and (in my opinion) incomplete. Actually the place I found that was most descriptive is in the ISA device driver chapter of the "architecture handbook" (which I can't find on the FreeBSD site): http://freebsd.active-venture.com/arch-handbook/isa-driver-busmem.html > There are also ample examples in the source tree, with the only >incorrect ones being those that are no longer popular enough to warrant >the work. I didn't think ata was unpopular :-) I've looked around few drivers and there are quite a few different ways the API is used, and I'm not sure any is "correct" (see the ALLOCNOW and NO_WAIT used in many places). Having a reference implementation would be a good thing (tm). For instance, some drivers like ata create/allocate/load/whatever tags and maps for each request, while others prepare some of the stuff upon attach and only do the minimum at I/O time. That's probably better in terms of I/O performance but has the drawback that some memory might be wasted by unused or little-used devices. I'm sure the "guys who know" have an opinion on which option is better. Thanks, Jacques. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 16:57:29 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08EF616A41F; Wed, 26 Oct 2005 16:57:29 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA0F43D45; Wed, 26 Oct 2005 16:57:28 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9QGvKR0040469; Wed, 26 Oct 2005 18:57:26 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051026183714.03b48e20@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 18:56:28 +0200 To: Scott Long From: Jacques Caron In-Reply-To: <435FAEE1.6000506@samsco.org> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <6.2.3.4.0.20051026163501.03b7d3e8@wheresmymailserver.com> <435FAEE1.6000506@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-amd64@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 16:57:29 -0000 Hi Scott, Thank you for your time on this issue... At 18:29 26/10/2005, Scott Long wrote: >I sent a long email on this on Dec 14, 2004. I'll pull it up and >forward it out. What I really should do is publish a definitive article >on the whole topic. Definitely! And add a link in the bus_dma man page, or expand its contents... >As for 'limitations as to what can happen in the callback', there are >none if you use the correct code structure. Isn't the callback called from an interrupt context of some kind? (if you think I don't know a thing about kernel internals you've guessed right!) Would it be possible, for instance, to move this whole bunch of code: /* start ATAPI operation */ if (ch->hw.command(request->device, ATA_PACKET_CMD, 0, 0, ATA_F_DMA)) { ata_prtdev(request->device, "error issuing ATAPI packet command\n"); request->result = EIO; break; } /* wait for ready to write ATAPI command block */ { int timeout = 5000; /* might be less for fast devices */ while (timeout--) { int reason = ATA_IDX_INB(ch, ATA_IREASON); int status = ATA_IDX_INB(ch, ATA_STATUS); if (((reason & (ATA_I_CMD | ATA_I_IN)) | (status & (ATA_S_DRQ | ATA_S_BUSY))) == ATAPI_P_CMDOUT) break; DELAY(20); } if (timeout <= 0) { ata_prtdev(request->device,"timeout waiting for ATAPI ready\n"); request->result = EIO; break; } } /* this seems to be needed for some (slow) devices */ DELAY(10); /* output actual command block */ ATA_IDX_OUTSW_STRM(ch, ATA_DATA, (int16_t *)request->u.atapi.ccb, (request->device->param->config & ATA_PROTO_MASK) == ATA_PROTO_ATAPI_12 ? 6 : 8); /* start DMA engine */ if (ch->dma->start(ch)) { request->result = EIO; break; } into a callback? It's mainly all the DELAY's that seem out of place in a callback to me... Note for Soren: there is a good explanation at the end of http://freebsd.active-venture.com/arch-handbook/isa-driver-busmem.html of callback integration strategies... >>>No. Some tags specifically should not permit deferals. >> >>How do they do that? Setting BUS_DMA_ALLOCNOW in the tag, or >>BUS_DMA_NOWAIT in the map_load, or both, or something else? > >They set it by using NULL as the lockfunc. Errrr... I'm lost here. I understood that you should use NULL as the lockfunc if and only if you know there won't be any deferrals (and I know by experience now that not having a lockfunc and having a deferral cause a panic!). So having NULL as the lockfunc is a consequence of not having any deferrals, it won't prevent them. >Actually, one map per tag is not common. If the ATA driver supported >tagged queuing (which I assume that it will someday for SATAII, yes?) I'm waiting for it eagerly, I have quite a bunch of hardware all set for it :-) >If a map is being created for every drive in the system, and the result >is that not enough bounce pages are being reserved for all three drives >to operate concurrently, then there might be a bug in busdma. We should >discuss this offline. Maps are created for every busy drive in the system, but I believe they each belong to a separate tag (all tags and maps are created on the fly for each I/O operation, as I understand it). If three drives are (really) busy at the same time, a panic is guaranteed if bounce buffers are needed. I'm trying to figure out since yesterday where the problem is (busdma or ata), but I think it's "somewhere in between", with each part assuming that the other does things some way or another. >>In this case 32 bounce pages (out of 8 GB RAM) for 6 disks seems >>like a very tight bottleneck to me. > >If that's all that is needed to saturate non-tagged ATA, then there is >nothing wrong with that. It might be enough to saturate one or two non-tagged ATA drives, but certainly not 6... Anyway, right now, it's not even saturation I have to deal with, but just a brutal panic :-( Jacques. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 17:44:13 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F2A416A41F; Wed, 26 Oct 2005 17:44:13 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 108E343D4C; Wed, 26 Oct 2005 17:44:04 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id B39FD9D592; Wed, 26 Oct 2005 19:44:01 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 9E4AC1EFA83; Wed, 26 Oct 2005 19:44:01 +0200 (CEST) Received: from lofi.dyndns.org (dslb-084-061-130-219.pools.arcor-ip.net [84.61.130.219]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 307C8AF0ED; Wed, 26 Oct 2005 19:44:01 +0200 (CEST) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.4]) by lofi.dyndns.org (8.13.4/8.13.3) with ESMTP id j9QHhwLJ043471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 19:43:58 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.4/8.13.1) with ESMTP id j9QHhvHc007960; Wed, 26 Oct 2005 19:43:57 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.4/8.13.1/Submit) id j9QHhuQ3007959; Wed, 26 Oct 2005 19:43:56 +0200 (CEST) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: kono@kth.se Date: Wed, 26 Oct 2005 19:43:49 +0200 User-Agent: KMail/1.8.2 References: <200510261110.25207.kono@kth.se> In-Reply-To: <200510261110.25207.kono@kth.se> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o; >bD>c:]^; :>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new Cc: freebsd-amd64@freebsd.org, freebsd-ports@freebsd.org, kde-freebsd@freebsd.kde.org Subject: Re: [kde-freebsd] xfig freezes on amd64 with KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 17:44:13 -0000 --nextPart1277408.DWcCV5RuFW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 26. October 2005 11:10, Alexander Konovalenko wrote: > Hello, > > recently I've got a problem with xfig 3.2.4 on amd64 FreeBSD 5.4 (STABLE) > when running it under KDE 3.4.2, with other X managers it works fine > > After pressing any button on the left panel xfig freezes and CPU load goes > up. xfig does some funky things with X resources to adjust its own looks and se= ems=20 to get into a race with KDE while doing so when "Apply colors to non-KDE=20 applications" is checked in KControl/Appearance&Themes/Colors. I've just committed a fix to the xfig port which should get rid of this=20 problem, please update to xfig-3.2.4_3. Cheers, =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1277408.DWcCV5RuFW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDX8BbXhc68WspdLARAoFtAJ97A2Zx2HNOFepj9Wiw1Obsx/yUxQCfdDR3 zq+x2+Zx4g8737R85FzGL8Q= =KvoH -----END PGP SIGNATURE----- --nextPart1277408.DWcCV5RuFW-- From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 17:53:18 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75E5D16A41F; Wed, 26 Oct 2005 17:53:18 +0000 (GMT) (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 2CFCA43D45; Wed, 26 Oct 2005 17:53:18 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j9QHr1QR008986; Wed, 26 Oct 2005 10:53:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j9QHqxTe008985; Wed, 26 Oct 2005 10:52:59 -0700 (PDT) (envelope-from sgk) Date: Wed, 26 Oct 2005 10:52:59 -0700 From: Steve Kargl To: Michael Nottebrock Message-ID: <20051026175259.GA8859@troutmask.apl.washington.edu> References: <200510261110.25207.kono@kth.se> <200510261943.56012.lofi@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510261943.56012.lofi@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: kono@kth.se, freebsd-ports@freebsd.org, freebsd-amd64@freebsd.org, kde-freebsd@freebsd.kde.org Subject: Re: [kde-freebsd] xfig freezes on amd64 with KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 17:53:18 -0000 On Wed, Oct 26, 2005 at 07:43:49PM +0200, Michael Nottebrock wrote: > On Wednesday, 26. October 2005 11:10, Alexander Konovalenko wrote: > > Hello, > > > > recently I've got a problem with xfig 3.2.4 on amd64 FreeBSD 5.4 (STABLE) > > when running it under KDE 3.4.2, with other X managers it works fine > > > > After pressing any button on the left panel xfig freezes and CPU load goes > > up. > > xfig does some funky things with X resources to adjust its own looks and seems > to get into a race with KDE while doing so when "Apply colors to non-KDE > applications" is checked in KControl/Appearance&Themes/Colors. > > I've just committed a fix to the xfig port which should get rid of this > problem, please update to xfig-3.2.4_3. > What is the effect on xfig when run under other window managers? -- Steve From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 18:01:56 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC02116A41F for ; Wed, 26 Oct 2005 18:01:56 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2F0B43D45 for ; Wed, 26 Oct 2005 18:01:55 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9QI1IoC085936; Wed, 26 Oct 2005 20:01:18 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> <435FA542.3030209@samsco.org> <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <42A1B51D-5A5E-4849-96D0-BC5C2DD1AE97@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Wed, 26 Oct 2005 20:01:52 +0200 To: Jacques Caron X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-amd64@FreeBSD.ORG Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 18:01:56 -0000 On 26/10/2005, at 18:34, Jacques Caron wrote: > > I've looked around few drivers and there are quite a few different =20 > ways the API is used, and I'm not sure any is "correct" (see the =20 > ALLOCNOW and NO_WAIT used in many places). Having a reference =20 > implementation would be a good thing (tm). > > For instance, some drivers like ata create/allocate/load/whatever =20 > tags and maps for each request, while others prepare some of the =20 > stuff upon attach and only do the minimum at I/O time. That's =20 > probably better in terms of I/O performance but has the drawback =20 > that some memory might be wasted by unused or little-used devices. =20 > I'm sure the "guys who know" have an opinion on which option is =20 > better. OK, lets take this apart for ATA. ATA does all the tag/map creates/allocs/loads for the SGlist and =20 simple workspace stuff at channel attach time, there are NO further =20 creates or allocs after that. So that is exactly what I would expect =20 the ALLOCNOW flags to make busdma support, if that doesn't work =20 busdma needs to be fixed IMNHO. Then when a request is sent to a device the data is =20 bus_dmamap_load'ed into place and unloaded when the resquest =20 finishes. It is not possible to have more than one request running on =20= a channel at a time. This means I have no need for callbacks or anything, and they =20 actually wouldn't bring me anything but increased code complexity =20 which I dont need, in fact dont need at all. I know this might change when tags get official support but it =20 doesn't bring anything but complexity there either (HINT: ATA has a =20 max of 32 tags). Now, bounce buffers might be something entirely different, but I'd =20 expect the system to alloc at least one buffer of maxsize pr tag so =20 it has what it needs if and when. That might be a waste of memory but =20= for ATA its at max 128K pr channel, and that IMNHO is not a problem =20 today.. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 18:11:13 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F0BF16A41F; Wed, 26 Oct 2005 18:11:13 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DEF643D46; Wed, 26 Oct 2005 18:11:11 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9QIB6gq046719; Wed, 26 Oct 2005 20:11:08 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051026200858.03adbcd8@pop.interactivemediafactory.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 26 Oct 2005 20:10:26 +0200 To: Scott Long From: Jacques Caron In-Reply-To: <6.2.3.4.0.20051026183714.03b48e20@wheresmymailserver.com> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <6.2.3.4.0.20051026163501.03b7d3e8@wheresmymailserver.com> <435FAEE1.6000506@samsco.org> <6.2.3.4.0.20051026183714.03b48e20@wheresmymailserver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-amd64@freebsd.org, sos@freebsd.org Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 18:11:13 -0000 Ooops... At 18:56 26/10/2005, Jacques Caron wrote: >Maps are created for every busy drive in the system, but I believe >they each belong to a separate tag (all tags and maps are created on >the fly for each I/O operation, as I understand it). As Soren pointed out, not at all, I got it completely mixed up :-( Jacques. From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 20:01:55 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D9FC16A41F; Wed, 26 Oct 2005 20:01:55 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A2443D4C; Wed, 26 Oct 2005 20:01:54 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id A9EEE7D34A; Wed, 26 Oct 2005 22:01:52 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 9721B75E6B; Wed, 26 Oct 2005 22:01:52 +0200 (CEST) Received: from lofi.dyndns.org (dslb-084-061-130-219.pools.arcor-ip.net [84.61.130.219]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 0D2CFAE538; Wed, 26 Oct 2005 22:01:52 +0200 (CEST) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.4]) by lofi.dyndns.org (8.13.4/8.13.3) with ESMTP id j9QK1nsK045515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 22:01:50 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.4/8.13.1) with ESMTP id j9QK1lUH010321; Wed, 26 Oct 2005 22:01:47 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.4/8.13.1/Submit) id j9QK1koG010317; Wed, 26 Oct 2005 22:01:46 +0200 (CEST) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: Steve Kargl Date: Wed, 26 Oct 2005 22:01:37 +0200 User-Agent: KMail/1.8.2 References: <200510261110.25207.kono@kth.se> <200510261943.56012.lofi@freebsd.org> <20051026175259.GA8859@troutmask.apl.washington.edu> In-Reply-To: <20051026175259.GA8859@troutmask.apl.washington.edu> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o; >bD>c:]^; :>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new Cc: kono@kth.se, freebsd-ports@freebsd.org, freebsd-amd64@freebsd.org, kde-freebsd@freebsd.kde.org Subject: Re: [kde-freebsd] xfig freezes on amd64 with KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 20:01:55 -0000 --nextPart8084171.KClVN26Bcz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 26. October 2005 19:52, Steve Kargl wrote: > > xfig does some funky things with X resources to adjust its own looks and > > seems to get into a race with KDE while doing so when "Apply colors to > > non-KDE applications" is checked in KControl/Appearance&Themes/Colors. > > > > I've just committed a fix to the xfig port which should get rid of this > > problem, please update to xfig-3.2.4_3. > > What is the effect on xfig when run under other window managers? None. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart8084171.KClVN26Bcz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDX+CpXhc68WspdLARAiLBAJ9wuY0pupaJBHd8JlMw6jbKjW1WZwCdFS4X uNkMHqOrOMfoS1crXgoUegU= =5j2d -----END PGP SIGNATURE----- --nextPart8084171.KClVN26Bcz-- From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 23:18:33 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E603016A41F for ; Wed, 26 Oct 2005 23:18:33 +0000 (GMT) (envelope-from pete@altadena.net) Received: from puffin.altadena.net (puffin.altadena.net [207.151.161.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9087543D48 for ; Wed, 26 Oct 2005 23:18:33 +0000 (GMT) (envelope-from pete@altadena.net) Received: from nat-gw.home.altadena.net ([66.127.158.99] helo=[192.168.169.28]) by puffin.altadena.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1EUuXQ-0000SP-K8 for amd64@freebsd.org; Wed, 26 Oct 2005 16:18:32 -0700 Message-ID: <43600EC7.20608@altadena.net> Date: Wed, 26 Oct 2005 16:18:31 -0700 From: Peter Carah User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051024) X-Accept-Language: en-us, en MIME-Version: 1.0 To: amd64@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Compaq V2310 (about TI cardbus) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 23:18:34 -0000 The Compaq V2310 has a TI combination bus controller chip that runs firewire (works), SD/SM/MS/MM card (doesn't work in either 32 or 64 bit FreeBSD) and the PCCard slot (works fine for 16 bit cards but doesn't recognize Cardbus insertions at all). The problem with flash cards is just that the driver doesn't exist - there are 2 PCI vendor/product pairs involved, both of which aren't recognized. TI claims in the datasheet (which, miraculously, is public) for their chipset that both of these interfaces are "standard", requiring one to buy $$$$$ a book from the sd card consortium. The problem with cardbus is stranger since 16 bit cards work fine. Since HP in their infinite wisdom messed up the internal wireless card for anything but windoze (uses Broadcom 4318, the supplied driver doesn't work in 32-bit FBSD, and neither the Acer 64-bit driver nor the one at Linuxant work in 64-bit FBSD) *then* they fixed the bios up so that if one supplies e.g. an Atheros minipci (like a CM9; this is a very nice ABG card), the machine won't boot, with no apparent bypass. Best solution is to somehow bypass this... There are 2 workarounds - use a modern wireless pccard (needs cardbus) or a USB (needs ralink; the manufacturers seem to shift chipsets at a whim and so one can't necessarily count on which usb dongles contain ralink chips.) I did see a nice Atheros usb dongle but our Atheros driver doesn't cover that interface :-( Anyhow, I wondered about the cardbus problem... (hits both my 802.11 card and my 5220 card, so is pretty generic). I enabled debug for the cardbus driver and get NO output whatever on cardbus insertion (lots of output for 16-bit, and the card even works). At the moment, I can't get a dmesg because someone messed up the kldloader to put out several thousand error messages on boot (bad relocation type 10). I'll try another cvsup tonight to see if that is fixed and resend this with an attached dmesg whenever possible, if it would help whoever works on this stuff. (or I *could* boot in single user, dmesg, then go to multi...) -- Pete From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 23:29:48 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8C2E16A421 for ; Wed, 26 Oct 2005 23:29:48 +0000 (GMT) (envelope-from pete@altadena.net) Received: from puffin.altadena.net (puffin.altadena.net [207.151.161.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69AF843D45 for ; Wed, 26 Oct 2005 23:29:48 +0000 (GMT) (envelope-from pete@altadena.net) Received: from nat-gw.home.altadena.net ([66.127.158.99] helo=[192.168.169.28]) by puffin.altadena.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1EUuiJ-0000Sq-Kw for amd64@freebsd.org; Wed, 26 Oct 2005 16:29:47 -0700 Message-ID: <4360116A.5080202@altadena.net> Date: Wed, 26 Oct 2005 16:29:46 -0700 From: Peter Carah User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051024) X-Accept-Language: en-us, en MIME-Version: 1.0 To: amd64@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Compaq V2310 (about TI cardbus) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 23:29:49 -0000 The Compaq V2310 has a TI combination bus controller chip that runs firewire (works), SD/SM/MS/MM card (doesn't work in either 32 or 64 bit FreeBSD) and the PCCard slot (works fine for 16 bit cards but doesn't recognize Cardbus insertions at all). The problem with flash cards is just that the driver doesn't exist - there are 2 PCI vendor/product pairs involved, both of which aren't recognized. TI claims in the datasheet (which, miraculously, is public) for their chipset that both of these interfaces are "standard", requiring one to buy $$$$$ a book from the sd card consortium. The problem with cardbus is stranger since 16 bit cards work fine. Since HP in their infinite wisdom messed up the internal wireless card for anything but windoze (uses Broadcom 4318, the supplied driver doesn't work in 32-bit FBSD, and neither the Acer 64-bit driver nor the one at Linuxant work in 64-bit FBSD) *then* they fixed the bios up so that if one supplies e.g. an Atheros minipci (like a CM9; this is a very nice ABG card), the machine won't boot, with no apparent bypass. Best solution is to somehow bypass this... There are 2 workarounds - use a modern wireless pccard (needs cardbus) or a USB (needs ralink; the manufacturers seem to shift chipsets at a whim and so one can't necessarily count on which usb dongles contain ralink chips.) I did see a nice Atheros usb dongle but our Atheros driver doesn't cover that interface :-( Anyhow, I wondered about the cardbus problem... (hits both my 802.11 card and my 5220 card, so is pretty generic). I enabled debug for the cardbus driver and get NO output whatever on cardbus insertion (lots of output for 16-bit, and the card even works). At the moment, I can't get a dmesg because someone messed up the kldloader to put out several thousand error messages on boot (bad relocation type 10). I'll try another cvsup tonight to see if that is fixed and resend this with an attached dmesg whenever possible, if it would help whoever works on this stuff. (or I *could* boot in single user, dmesg, then go to multi...) -- Pete From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 26 23:40:26 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D46CE16A41F for ; Wed, 26 Oct 2005 23:40:26 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7337343D55 for ; Wed, 26 Oct 2005 23:40:26 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j9QNmmWm031258; Wed, 26 Oct 2005 19:48:48 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Wed, 26 Oct 2005 19:40:06 -0400 User-Agent: KMail/1.6.2 References: <43600EC7.20608@altadena.net> In-Reply-To: <43600EC7.20608@altadena.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200510261940.09870.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1148/Tue Oct 25 15:34:12 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Peter Carah Subject: Re: Compaq V2310 (about TI cardbus) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 23:40:27 -0000 On Wednesday 26 October 2005 07:18 pm, Peter Carah wrote: > Anyhow, I wondered about the cardbus problem... (hits both my > 802.11 card and my 5220 card, so is pretty generic). I enabled > debug for the cardbus driver and get NO output whatever on cardbus > insertion (lots of output for 16-bit, and the card even works). Sounds very familiar... Can you send me verbose boot messages when you have it back on line? > At the moment, I can't get a dmesg because someone messed up the > kldloader to put out several thousand error messages on boot (bad > relocation type 10). I'll try another cvsup tonight to see if that > is fixed and resend this with an attached dmesg whenever possible, > if it would help whoever works on this stuff. (or I *could* boot > in single user, dmesg, then go to multi...) I guess you have 'makeoptions DEBUG=-g' in you kernel config. Comment it out and rebuild. Alternatively you can back these out for now: http://docs.freebsd.org/cgi/mid.cgi?200510250905.j9P9575Z002500 http://docs.freebsd.org/cgi/mid.cgi?200510242354.j9ONsd0S052397 Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 00:42:38 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE5116A41F for ; Thu, 27 Oct 2005 00:42:38 +0000 (GMT) (envelope-from eduardoschettini@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D0C743D45 for ; Thu, 27 Oct 2005 00:42:37 +0000 (GMT) (envelope-from eduardoschettini@gmail.com) Received: by xproxy.gmail.com with SMTP id t5so547596wxc for ; Wed, 26 Oct 2005 17:42:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K6+C1cSg6M2VrQ+JVUmBZZrGw5yYnOeXpREcw5zFCfouUHMHHntMxCS+vhYwPPBXmzr/W3tZm2jdfhpHcdTOATObv7tjY2QA/yDZF6CwTwyvs8T4eyjlqkHzqrtBQ/BLj3mWdiH4lRo/xkXMqynfcu6c2G5P5kv3VoZ+2Upchz8= Received: by 10.64.251.6 with SMTP id y6mr1199230qbh; Wed, 26 Oct 2005 17:35:55 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 26 Oct 2005 17:35:55 -0700 (PDT) Message-ID: <121b80f60510261735u94e58adhed7a0a4eac6d9a54@mail.gmail.com> Date: Thu, 27 Oct 2005 00:35:55 +0000 From: Eduardo Schettini To: freebsd-amd64@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Help if /usr/ports/java/jdk15 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 00:42:38 -0000 Hi, I'm trying install the jdk15 in my NoteBook, Compac Presario R3000 AMD64, and in a moment the system tell to download the following file: glibc-common-2.3.2-4.80.8.amd64.rpm But i'm searching in google and all sites i know, but i not found this rpms file. Can you help to find to install this file ( glibc-common-2.3.2-4.80.8.amd64.rpm)? -- Atenciosamente; Eduardo Schettini Guimar=E3es Cel: (61) 92913883 From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 07:05:16 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A79F16A425 for ; Thu, 27 Oct 2005 07:05:07 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (glewis.dsl.xmission.com [166.70.56.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23D4743D45 for ; Thu, 27 Oct 2005 07:05:07 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.3/8.13.3) with ESMTP id j9R755EM035374; Thu, 27 Oct 2005 01:05:05 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.3/8.13.3/Submit) id j9R754LA035373; Thu, 27 Oct 2005 01:05:04 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Thu, 27 Oct 2005 01:05:04 -0600 From: Greg Lewis To: Eduardo Schettini Message-ID: <20051027070504.GA35320@misty.eyesbeyond.com> References: <121b80f60510261735u94e58adhed7a0a4eac6d9a54@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <121b80f60510261735u94e58adhed7a0a4eac6d9a54@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Help if /usr/ports/java/jdk15 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 07:05:16 -0000 On Thu, Oct 27, 2005 at 12:35:55AM +0000, Eduardo Schettini wrote: > I'm trying install the jdk15 in my NoteBook, Compac Presario R3000 > AMD64, and in a moment the system tell to download the following file: > glibc-common-2.3.2-4.80.8.amd64.rpm > But i'm searching in google and all sites i know, but i not found this > rpms file. Can you help to find to install this file ( > glibc-common-2.3.2-4.80.8.amd64.rpm)? Your ports collection may be out of date. Try updating it and trying it again. If you still get it, try installing the linux_base-8 port directly before installing the jdk15 port. The file it should actually be asking for is glibc-common-2.3.2-4.80.8.i386.rpm. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 11:08:44 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F06AC16A420; Thu, 27 Oct 2005 11:08:43 +0000 (GMT) (envelope-from andreas@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 914C243D49; Thu, 27 Oct 2005 11:08:43 +0000 (GMT) (envelope-from andreas@FreeBSD.org) Received: from freefall.freebsd.org (andreas@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9RB8hG2096309; Thu, 27 Oct 2005 11:08:43 GMT (envelope-from andreas@freefall.freebsd.org) Received: (from andreas@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9RB8h7P096305; Thu, 27 Oct 2005 11:08:43 GMT (envelope-from andreas) Date: Thu, 27 Oct 2005 11:08:43 GMT From: Andreas Klemm Message-Id: <200510271108.j9RB8h7P096305@freefall.freebsd.org> To: meka@softhome.net, andreas@FreeBSD.org, freebsd-amd64@FreeBSD.org, obrien@FreeBSD.org Cc: Subject: Re: amd64/84027: if_nve gets stuck X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 11:08:44 -0000 Synopsis: if_nve gets stuck State-Changed-From-To: open->analyzed State-Changed-By: andreas State-Changed-When: Thu Oct 27 11:06:34 GMT 2005 State-Changed-Why: Could you please check the following patch from Quentin, see: http://www.freebsd.org/cgi/query-pr.cgi?pr=88045 Index: if_nve.c =================================================================== RCS file: /data/ncvs/src/sys/dev/nve/if_nve.c,v retrieving revision 1.7.2.4 diff -u -r1.7.2.4 if_nve.c --- if_nve.c 9 Oct 2005 04:18:17 -0000 1.7.2.4 +++ if_nve.c 27 Oct 2005 09:58:45 -0000 @@ -727,7 +727,7 @@ DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n"); - sc->cur_rx = sc->cur_tx = sc->pending_rxs = sc->pending_txs = 0; + sc->cur_rx = sc->cur_tx = sc->pending_rxs = 0; /* Initialise RX ring */ for (i = 0; i < RX_RING_SIZE; i++) { struct nve_rx_desc *desc = sc->rx_desc + i; Responsible-Changed-From-To: freebsd-amd64->obrien Responsible-Changed-By: andreas Responsible-Changed-When: Thu Oct 27 11:06:34 GMT 2005 Responsible-Changed-Why: obrien is author of driver according to source http://www.freebsd.org/cgi/query-pr.cgi?pr=84027 From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 12:37:11 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CA3416A41F; Thu, 27 Oct 2005 12:37:11 +0000 (GMT) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (mars.imfeurope.net [194.2.222.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14CC843D49; Thu, 27 Oct 2005 12:37:10 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id j9RCb4Sn008458; Thu, 27 Oct 2005 14:37:07 +0200 (CEST) (envelope-from jc@oxado.com) Message-Id: <6.2.3.4.0.20051027121824.03d34dd8@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 27 Oct 2005 14:36:52 +0200 To: Scott Long From: Jacques Caron In-Reply-To: <42A1B51D-5A5E-4849-96D0-BC5C2DD1AE97@FreeBSD.ORG> References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> <435FA542.3030209@samsco.org> <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> <42A1B51D-5A5E-4849-96D0-BC5C2DD1AE97@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@FreeBSD.ORG, Søren Schmidt Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 12:37:11 -0000 Hi, At 20:01 26/10/2005, Søren Schmidt wrote: ATA does all the tag/map creates/allocs/loads for the SGlist and >simple workspace stuff at channel attach time, there are NO further >creates or allocs after that. So that is exactly what I would expect >the ALLOCNOW flags to make busdma support, if that doesn't work >busdma needs to be fixed IMNHO. So I tested with ALLOCNOW set on all 4 tags, and the end result is exactly the same, ch->dma->load fails (due to EINPROGRESS, most probably), and a panic is trigerred by busdma dflt_lock . And I agree that this is a busdma bug, as the busdma manpage says, in the description of bus_dmamap_load: EINPROGRESS The mapping has been deferred for lack of resources. The callback will be called as soon as resources are available. Callbacks are serviced in FIFO order. DMA maps created from DMA tags that are allocated with the BUS_DMA_ALLOCNOW flag will never return this status for a load operation. So either the busdma API needs to be changed and ALLOCNOW no longer means that EINPROGRESS cannot happen (and that might break other things), or busdma needs to be fixed to conform to the documentation. Interestingly, if I remove the ALLOCNOW in all tag creations in ata, then: - ata attaches during boot are a bit longer (like fxp which is really long) - 320 bounces pages are allocated - I can do apparently do everything I want and not panic the machine. - I suppose that since there's plenty of available bounce pages, I should not have problems with ENOMEM. I'll go with that configuration for now, but that's most probably not the correct fix, just a workaround. The correct fix is to make busdma work as documented. Here I see several things to look into: - make sure enough ressources are actually allocated at tag create time if ALLOCNOW is set (this does not necessarily mean allocating maxsize additional pages, some logic about already required pages needs to be added I think) - let bus_dmamap_create allocate additional bounce pages if needed even if ALLOCNOW was set initially (i.e. don't use BUS_DMA_MIN_ALLOC_COMP), though I'm not sure the page allocation logic there is entirely correct either, as it will allocate additional pages even if there are already enough - in _bus_dmamap_load_buffer, consider ALLOCNOW like the undocumented NOWAIT, i.e. return ENOMEM if enough ressources aren't available (which I believe wouldn't be correct either: ALLOCNOW should prevent EINPROGRESS but also ENOMEM at map load time and should return ENOMEM immediately if there aren't enough ressources, not later). Another thing to look into is why bounce page allocation is that long (at least I believe that's what is taking so long), but I haven't looked at that bit at all yet. I also wonder if allocating bounce pages on <=4G configurations is really needed/useful? There are probably situations where this is needed, but I'm not sure I understand why. Jacques. From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 14:03:40 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.ORG Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69DBA16A41F; Thu, 27 Oct 2005 14:03:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEAE143D48; Thu, 27 Oct 2005 14:03:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9RE3cJs073160; Thu, 27 Oct 2005 08:03:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4360DE3C.6010209@samsco.org> Date: Thu, 27 Oct 2005 08:03:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Caron References: <6.2.3.4.0.20051025171333.03a15490@pop.interactivemediafactory.net> <6.2.3.4.0.20051026131012.03a80a20@pop.interactivemediafactory.net> <435F8E06.9060507@samsco.org> <08A81034-AB5D-4BFC-8F53-21501073D674@FreeBSD.ORG> <435FA542.3030209@samsco.org> <6.2.3.4.0.20051026180325.03ad7558@wheresmymailserver.com> <42A1B51D-5A5E-4849-96D0-BC5C2DD1AE97@FreeBSD.ORG> <6.2.3.4.0.20051027121824.03d34dd8@wheresmymailserver.com> In-Reply-To: <6.2.3.4.0.20051027121824.03d34dd8@wheresmymailserver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@FreeBSD.ORG, SXren Schmidt Subject: Re: busdma dflt_lock on amd64 > 4 GB X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 14:03:40 -0000 Jacques Caron wrote: > Hi, > > At 20:01 26/10/2005, Søren Schmidt wrote: > ATA does all the tag/map creates/allocs/loads for the SGlist and > >> simple workspace stuff at channel attach time, there are NO further >> creates or allocs after that. So that is exactly what I would expect >> the ALLOCNOW flags to make busdma support, if that doesn't work >> busdma needs to be fixed IMNHO. > > > So I tested with ALLOCNOW set on all 4 tags, and the end result is > exactly the same, ch->dma->load fails (due to EINPROGRESS, most > probably), and a panic is trigerred by busdma dflt_lock . And I agree > that this is a busdma bug, as the busdma manpage says, in the > description of bus_dmamap_load: > > EINPROGRESS The mapping has been deferred for lack of > resources. The callback will be called as > soon as > resources are available. Callbacks are > serviced in > FIFO order. DMA maps created from DMA tags that > are allocated with the BUS_DMA_ALLOCNOW flag > will > never return this status for a load operation. > > So either the busdma API needs to be changed and ALLOCNOW no longer > means that EINPROGRESS cannot happen (and that might break other > things), or busdma needs to be fixed to conform to the documentation. > > Interestingly, if I remove the ALLOCNOW in all tag creations in ata, then: > - ata attaches during boot are a bit longer (like fxp which is really long) > - 320 bounces pages are allocated > - I can do apparently do everything I want and not panic the machine. > - I suppose that since there's plenty of available bounce pages, I > should not have problems with ENOMEM. > > I'll go with that configuration for now, but that's most probably not > the correct fix, just a workaround. The correct fix is to make busdma > work as documented. > > Here I see several things to look into: > - make sure enough ressources are actually allocated at tag create time > if ALLOCNOW is set (this does not necessarily mean allocating maxsize > additional pages, some logic about already required pages needs to be > added I think) > - let bus_dmamap_create allocate additional bounce pages if needed even > if ALLOCNOW was set initially (i.e. don't use BUS_DMA_MIN_ALLOC_COMP), > though I'm not sure the page allocation logic there is entirely correct > either, as it will allocate additional pages even if there are already > enough > - in _bus_dmamap_load_buffer, consider ALLOCNOW like the undocumented > NOWAIT, i.e. return ENOMEM if enough ressources aren't available (which > I believe wouldn't be correct either: ALLOCNOW should prevent > EINPROGRESS but also ENOMEM at map load time and should return ENOMEM > immediately if there aren't enough ressources, not later). > > Another thing to look into is why bounce page allocation is that long > (at least I believe that's what is taking so long), but I haven't looked > at that bit at all yet. > > I also wonder if allocating bounce pages on <=4G configurations is > really needed/useful? There are probably situations where this is > needed, but I'm not sure I understand why. > > Jacques. > > It sounds like the only real bug in busdma is that it gets confused by ALLOCNOW and doesn't allow enough pages to be allocated when bus_dmamap_create() is called. I'll look into this. Scott From owner-freebsd-amd64@FreeBSD.ORG Thu Oct 27 15:32:30 2005 Return-Path: X-Original-To: amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA3C16A41F; Thu, 27 Oct 2005 15:32:30 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E0143D45; Thu, 27 Oct 2005 15:32:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9RFWR2q023715; Thu, 27 Oct 2005 18:32:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 82407-04-2; Thu, 27 Oct 2005 18:32:24 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9RFTFSE023609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 18:29:15 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id j9RFTHod063640; Thu, 27 Oct 2005 18:29:17 +0300 (EEST) (envelope-from ru) Date: Thu, 27 Oct 2005 18:29:17 +0300 From: Ruslan Ermilov To: Jung-uk Kim , Peter Wemm , Ian Dowse Message-ID: <20051027152917.GE68470@ip.net.ua> References: <200510250905.j9P9575Z002500@repoman.freebsd.org> <200510261706.50768.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: <200510261706.50768.jkim@FreeBSD.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: amd64@FreeBSD.org Subject: kldloading foo.ko.debug on amd64 (was: Re: cvs commit: src/release Makefile src/sys/conf kern.post.mk kmod.mk) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 15:32:30 -0000 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2005 at 05:06:49PM -0400, Jung-uk Kim wrote: > On Tuesday 25 October 2005 05:05 am, Ruslan Ermilov wrote: [...] > > Now, if kernel was configured for debugging (through DEBUG=3D-g in > > the kernel config file or "config -g"), doing "make install" will > > install debug versions of kernel and module objects with their > > canonical names, > > > > kernel.debug -> /boot/kernel/kernel > > if_fxp.ko.debug -> /boot/kernel/if_fxp.ko > > > > Installing a kernel not configured for debugging, or debug kernel > > with INSTALL_NODEBUG variable defined, will install non-debug > > kernel and module objects. > > > > Also, restore the install.debug and reinstall.debug targets that > > are part of the existing API (they cause some additional gdb(1) > > scripts to be installed). > > > > Revision Changes Path > > 1.891 +0 -4 src/release/Makefile > > 1.86 +4 -2 src/sys/conf/kern.post.mk > > 1.197 +3 -8 src/sys/conf/kmod.mk >=20 > It's broken amd64. I had DEBUG=3D-g in the configuration and it's=20 > spewing a lot of 'kldload: unexpected relocation type 10' while=20 > preloading modules. :-( >=20 Fixing the above warning would be easy, but the problem was worse: kldloading a module object with debugging infomation would consume a lot more memory, on amd64. This has something to do with a different format of kernel object flies, because on i386 loading either module consumes the same amount of memory (as reported by kldstat(8)). Peter, Ian, can you please explain what's different here? I.e., why loading a foo.ko.debug on amd64 consumes more space than loading a foo.ko, contrary to say i386? After figuring this out, I adopted the code proposed by obrien. Now we build a "two part executable", foo.ko and accompanying foo.ko.dbg that the gdb(1) knows how to pick up. This upsets kldxref(8), because they have the module metadata section to be of type SHT_NOBITS instead of SHT_PROGBITS, so reading from this section essentially returns zeroes: kldxref: unknown metdata record 0 in file if_xl.ko.dbg kldxref: unknown metdata record 0 in file if_xl.ko.dbg kldxref: unknown metdata record 0 in file if_xl.ko.dbg kldxref: unknown metdata record 0 in file if_xl.ko.dbg kldxref: unknown metdata record 0 in file if_xl.ko.dbg kldxref: unknown metdata record 0 in file if_xl.ko.dbg I have a fix for this, but I'm not sure if it's right: %%% Index: ef_obj.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.sbin/kldxref/ef_obj.c,v retrieving revision 1.3 diff -u -p -r1.3 ef_obj.c --- ef_obj.c 28 Aug 2004 19:31:10 -0000 1.3 +++ ef_obj.c 27 Oct 2005 13:50:52 -0000 @@ -164,7 +164,8 @@ ef_obj_lookup_set(elf_file_t ef, const c =20 for (i =3D 0; i < ef->nprogtab; i++) { if ((strncmp(ef->progtab[i].name, "set_", 4) =3D=3D 0) && - strcmp(ef->progtab[i].name + 4, name) =3D=3D 0) { + (strcmp(ef->progtab[i].name + 4, name) =3D=3D 0) && + ef->e_shdr[ef->progtab[i].sec].sh_type =3D=3D SHT_PROG= BITS) { *startp =3D (char *)ef->progtab[i].addr - ef->address; *stopp =3D (char *)ef->progtab[i].addr + ef->progtab[i].size - ef->address; %%% Anyway, I'd appreciate some enlightment and help. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDYPJNqRfpzJluFF4RAjUtAJ9JH0+FWA2ued4f4iuIayMaJRJ76wCgnvoR 0Pddc2tKZF7E7zJAZWoEo/0= =E9bT -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF-- From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 03:13:46 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44B5B16A41F for ; Fri, 28 Oct 2005 03:13:46 +0000 (GMT) (envelope-from webmaster@machowto.com) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id E317443D45 for ; Fri, 28 Oct 2005 03:13:45 +0000 (GMT) (envelope-from webmaster@machowto.com) Received: from [192.168.0.4] (c-67-177-44-144.hsd1.ut.comcast.net[67.177.44.144]) by comcast.net (sccrmhc11) with SMTP id <20051028030802011002vf75e>; Fri, 28 Oct 2005 03:08:07 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Thu, 27 Oct 2005 21:08:00 -0600 From: "David S. Besade" To: Message-ID: Thread-Topic: Build Failure - Lastest Source Thread-Index: AcXbbM12DDb3MEdgEdqodwADk1TWeA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Build Failure - Lastest Source X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 03:13:46 -0000 ===> etc/sendmail (all) find: /usr/local/share/sendmail/cf: No such file or directory "/usr/src/etc/sendmail/Makefile", line 14: warning: "find /usr/local/share/sendmail/cf -type f -name '*.m4' -print" returned non-zero status rm -f freebsd.cf m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/ /usr/local/share/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf m4: /usr/local/share/sendmail/cf/m4/cf.m4: No such file or directory *** Error code 1 Stop in /usr/src/etc/sendmail. *** Error code 1 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. s3# -------- Any Suggestions? -Dave From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 06:24:36 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C9B616A420; Fri, 28 Oct 2005 06:24:36 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 054CF43D49; Fri, 28 Oct 2005 06:24:36 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9S6OZbg069629; Fri, 28 Oct 2005 06:24:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9S6OZuw069625; Fri, 28 Oct 2005 06:24:35 GMT (envelope-from linimon) Date: Fri, 28 Oct 2005 06:24:35 GMT From: Mark Linimon Message-Id: <200510280624.j9S6OZuw069625@freefall.freebsd.org> To: jfclisham@adelphia.net, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/77101: feature request: please include ULi M1689 LAN, SATA, and AMD64 AGP drivers X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 06:24:36 -0000 Synopsis: feature request: please include ULi M1689 LAN, SATA, and AMD64 AGP drivers State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Fri Oct 28 06:24:18 GMT 2005 State-Changed-Why: Mark suspended awaiting someone to take an interest in this. http://www.freebsd.org/cgi/query-pr.cgi?pr=77101 From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 07:20:51 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52AC216A41F for ; Fri, 28 Oct 2005 07:20:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F3243D53 for ; Fri, 28 Oct 2005 07:20:46 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9S7KhjK067666; Fri, 28 Oct 2005 10:20:43 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 96485-02-2; Fri, 28 Oct 2005 10:20:39 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9S7H3Xa067571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 10:17:03 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id j9S7H5uh078677; Fri, 28 Oct 2005 10:17:05 +0300 (EEST) (envelope-from ru) Date: Fri, 28 Oct 2005 10:17:05 +0300 From: Ruslan Ermilov To: "David S. Besade" Message-ID: <20051028071705.GA58306@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-amd64@freebsd.org Subject: Re: Build Failure - Lastest Source X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 07:20:51 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2005 at 09:08:00PM -0600, David S. Besade wrote: > =3D=3D=3D> etc/sendmail (all) > find: /usr/local/share/sendmail/cf: No such file or directory > "/usr/src/etc/sendmail/Makefile", line 14: warning: "find > /usr/local/share/sendmail/cf -type f -name '*.m4' -print" returned non-ze= ro > status > rm -f freebsd.cf > m4 -D_CF_DIR_=3D/usr/local/share/sendmail/cf/ > /usr/local/share/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > > freebsd.cf > m4: /usr/local/share/sendmail/cf/m4/cf.m4: No such file or directory > *** Error code 1 >=20 > Stop in /usr/src/etc/sendmail. > *** Error code 1 >=20 The "/usr/local" part looks suspicious enough to assume you have something odd in your build environment (e.g., in /etc/make.conf). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDYdBxqRfpzJluFF4RAlQ+AJ4ljAZv04OnhbCQ+TqMzUxa+SNtHACeJj5V rmH/ddr78F11bI+1k5LChDI= =2JwN -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 18:39:27 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3BC216A423; Fri, 28 Oct 2005 18:39:27 +0000 (GMT) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F20443D45; Fri, 28 Oct 2005 18:39:27 +0000 (GMT) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (obrien@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9SIdRnv074669; Fri, 28 Oct 2005 18:39:27 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9SIdRu5074665; Fri, 28 Oct 2005 18:39:27 GMT (envelope-from obrien) Date: Fri, 28 Oct 2005 18:39:27 GMT From: "David E. O'Brien" Message-Id: <200510281839.j9SIdRu5074665@freefall.freebsd.org> To: jfclisham@adelphia.net, obrien@FreeBSD.org, freebsd-amd64@FreeBSD.org, obrien@FreeBSD.org Cc: Subject: Re: amd64/77101: feature request: please include ULi M1689 LAN, SATA, and AMD64 AGP drivers X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 18:39:27 -0000 Synopsis: feature request: please include ULi M1689 LAN, SATA, and AMD64 AGP drivers State-Changed-From-To: suspended->open State-Changed-By: obrien State-Changed-When: Fri Oct 28 18:38:53 GMT 2005 State-Changed-Why: I've got access to one of these systems. Responsible-Changed-From-To: freebsd-amd64->obrien Responsible-Changed-By: obrien Responsible-Changed-When: Fri Oct 28 18:38:53 GMT 2005 Responsible-Changed-Why: I've got access to one of these systems. http://www.freebsd.org/cgi/query-pr.cgi?pr=77101 From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 21:23:28 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92E0616A420; Fri, 28 Oct 2005 21:23:28 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EAE643D46; Fri, 28 Oct 2005 21:23:28 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9SLNSav097074; Fri, 28 Oct 2005 21:23:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9SLNRnt097070; Fri, 28 Oct 2005 21:23:27 GMT (envelope-from linimon) Date: Fri, 28 Oct 2005 21:23:27 GMT From: Mark Linimon Message-Id: <200510282123.j9SLNRnt097070@freefall.freebsd.org> To: bra@fsn.hu, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/87112: Boot problems on a 16 processor AMD64 compatible machine X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 21:23:28 -0000 Synopsis: Boot problems on a 16 processor AMD64 compatible machine State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Fri Oct 28 21:22:21 GMT 2005 State-Changed-Why: Should be fixed by commit to sys/amd64/amd64/machdep.c by peter. http://www.freebsd.org/cgi/query-pr.cgi?pr=87112 From owner-freebsd-amd64@FreeBSD.ORG Fri Oct 28 21:23:49 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3158816A41F; Fri, 28 Oct 2005 21:23:49 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E13AA43D49; Fri, 28 Oct 2005 21:23:48 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9SLNmpu097136; Fri, 28 Oct 2005 21:23:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9SLNmco097132; Fri, 28 Oct 2005 21:23:48 GMT (envelope-from linimon) Date: Fri, 28 Oct 2005 21:23:48 GMT From: Mark Linimon Message-Id: <200510282123.j9SLNmco097132@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, peter@FreeBSD.org Cc: Subject: Re: amd64/87112: Boot problems on a 16 processor AMD64 compatible machine X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 21:23:49 -0000 Synopsis: Boot problems on a 16 processor AMD64 compatible machine Responsible-Changed-From-To: freebsd-amd64->peter Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 28 21:23:34 GMT 2005 Responsible-Changed-Why: Assign as a possible MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=87112 From owner-freebsd-amd64@FreeBSD.ORG Sat Oct 29 20:29:50 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF37416A420; Sat, 29 Oct 2005 20:29:50 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D36343D46; Sat, 29 Oct 2005 20:29:49 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.5/jtpda-5.4) with ESMTP id j9TKTmoO004136 ; Sat, 29 Oct 2005 22:29:48 +0200 (CEST) X-Ids: 165 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id j9TKTlsG020753 ; Sat, 29 Oct 2005 22:29:47 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id j9TKTlwA020750; Sat, 29 Oct 2005 22:29:47 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" Date: 29 Oct 2005 22:29:47 +0200 Message-ID: Lines: 97 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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-1.7.2 (shiva.jussieu.fr [134.157.0.165]); Sat, 29 Oct 2005 22:29:48 +0200 (CEST) X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Miltered: at shiva.jussieu.fr with ID 4363DBBC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Subject: RELENG_6 linux emulation problem on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2005 20:29:51 -0000 Hello, I get an easy to reproduce panic on recent RELENG_6/amd64 : -su-2.05b# /compat/linux/bin/bash bash-2.05b# cd /dev bash-2.05b# ls panic : kmem_malloc: entry not found or misaligned Setup is as follows : /dev/ad0s3d mounted on / /dev/ad0s4d mount on /files /usr is a symlink to /files/amd64/usr if ever that might be of importance (the rest of ad0s3 is RELENG_5/i386) uname -a : FreeBSD demo 6.0-RC1 FreeBSD 6.0-RC1 #1: Sat Oct 29 17:04:50 CEST 2005 toor@demo:/files/amd64/obj/files/bsd/src6/sys/D470K amd64 generic config-file with outcommented non-needed drivers and extra options : device cpufreq device tap device atapicam device sound device smbus device iicbus device iicsmb options NTFS options TCP_DROP_SYNFIN linux_base-8-8.0_7 installed. NB, please respond preferentially to list; i still need a good solution to filter important email from my flooding "misc" procmail-filter output ;( Arno ##### kgdb trace : #### (kgdb) where #0 doadump () at /files/bsd/src6/sys/kern/kern_shutdown.c:234 #1 0xffffffff8030c10b in boot (howto=260) at /files/bsd/src6/sys/kern/kern_shutdown.c:399 #2 0xffffffff8030c5de in panic ( fmt=0xffffffff805cdea8 "kmem_malloc: entry not found or misaligned") at /files/bsd/src6/sys/kern/kern_shutdown.c:555 #3 0xffffffff804ed2cf in kmem_malloc (map=0xffffff003e0b0160, size=0, flags=258) at /files/bsd/src6/sys/vm/vm_kern.c:382 #4 0xffffffff804e00a2 in page_alloc (zone=0x0, bytes=0, pflag=0xffffffffa7aba5e7 "\002\200\202®-", wait=258) at /files/bsd/src6/sys/vm/uma_core.c:957 #5 0xffffffff804e3bbb in uma_large_malloc (size=0, wait=258) at /files/bsd/src6/sys/vm/uma_core.c:2711 #6 0xffffffff802fc503 in malloc (size=0, mtp=0xffffffff80706880, flags=258) at /files/bsd/src6/sys/kern/kern_malloc.c:327 #7 0xffffffff802fc6fe in realloc (addr=0x0, size=18446744073709549576, mtp=0xffffffff80706880, flags=258) at /files/bsd/src6/sys/kern/kern_malloc.c:416 #8 0xffffffff80398412 in vfs_read_dirent (ap=0xffffffffa7aba790, dp=0xffffff0000e16298, off=0) at /files/bsd/src6/sys/kern/vfs_subr.c:3877 #9 0xffffffff80290f56 in devfs_readdir (ap=0xffffffffa7aba790) at /files/bsd/src6/sys/fs/devfs/devfs_vnops.c:828 #10 0xffffffff805815ec in VOP_READDIR_APV (vop=0xffffffff806fc480, a=0xffffffffa7aba790) at vnode_if.c:1427 #11 0xffffffff8056f559 in VOP_READDIR (vp=0xffffff0002f6e000, uio=0xffffffffa7abaab0, cred=0xffffff002e93c700, eofflag=0xffffffffa7aba854, ncookies=0xffffffffa7aba834, cookies=0xffffffffa7aba840) at vnode_if.h:747 #12 0xffffffff8056efe6 in getdents_common (td=0xffffff002ff22be0, args=0xffffffffa7abab90, is64bit=1) at /files/bsd/src6/sys/compat/linux/linux_file.c:328 #13 0xffffffff8056f612 in linux_getdents64 (td=0xffffff002ff22be0, args=0xffffffffa7abab90) at /files/bsd/src6/sys/compat/linux/linux_file.c:476 #14 0xffffffff80564f54 in ia32_syscall (frame= {tf_rdi = 3, tf_rsi = 0, tf_rdx = 4096, tf_rcx = 134598592, tf_r8 = 0, tf_r9 = 0, tf_rax = 220, tf_rbx = 3, tf_rbp = 4294958168, tf_r10 = 0, tf_r11 = 0, tf_r12 = 0, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 12, tf_addr = 134602692, tf_flags = 0, tf_err = 2, tf_rip = 672250937, tf_cs = 27, tf_rflags = 582, tf_rsp = 4294958092, tf_ss = 35}) at /files/bsd/src6/sys/amd64/ia32/ia32_syscall.c:186 #15 0xffffffff8050c1ad in Xint0x80_syscall () at ia32_exception.S:64 #16 0x000000002811bc39 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com