From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:00:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A3B106566C for ; Sun, 22 Mar 2009 00:00:49 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4B58FC16 for ; Sun, 22 Mar 2009 00:00:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n2LNKUcI072088; Sun, 22 Mar 2009 00:20:53 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n2LNKUjQ072087; Sun, 22 Mar 2009 00:20:30 +0100 (CET) (envelope-from marius) Date: Sun, 22 Mar 2009 00:20:30 +0100 From: Marius Strobl To: Andreas Tobler Message-ID: <20090321232030.GA70685@alchemy.franken.de> References: <49C55EBC.1070602@fgznet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C55EBC.1070602@fgznet.ch> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , freebsd-sparc64@freebsd.org Subject: Re: kdb enter when upgrading from 7.1 to current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:00:49 -0000 On Sat, Mar 21, 2009 at 10:40:12PM +0100, Andreas Tobler wrote: > Hi, > > I get this stacktrace when I try to boot from a Kernel as of today (svn: > 190217). > > My setup is a 7.1 install where I'd like to upgrade to current. > The kernel is built cross, amd64 -> sparc64: > make -j4 buildkernel TARGET_ARCH=sparc64 KERNCONF=GENERIC > > The target machine itself is a u60, details below. > > Does anyone have a pointer to help me, would be great! > > TIA, > Andreas > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > jumping to kernel entry at 0xc0080000. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #2 r190217M: Sat Mar 21 22:27:46 CET 2009 > > andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/sparc64/export/devel/ > fbsd_svn/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > real memory = 1610612736 (1536 MB) > avail memory = 1554710528 (1482 MB) > cpu0: Sun Microsystems UltraSparc-II Processor (449.99 MHz CPU) > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > ispfw: registered firmware > kbd0 at kbdmux0 > nexus0: > pcib0: mem > 0x1fe00004000-0x1fe00005fff,0x1fe01000000-0x1fe0 > 10000ff,0x1fe00000000-0x1fe0000cfff irq 2033,2030,2031,2021,2024,2034 on > nexus0 > pcib0: Psycho, impl 0, version 4, IGN 0x1f, bus B, 33MHz > initializing counter-timer > Timecounter "pcib0" frequency 1000000 Hz quality 100 > pcib0: DVMA map: 0xfc000000 to 0xffffffff, streaming buffer > pcib0: [FILTER] > pcib0: [FILTER] > pcib0: [GIANT-LOCKED] > pcib0: [ITHREAD] > pcib0: [GIANT-LOCKED] > pcib0: [ITHREAD] > pcib0: [FILTER] > pci0: on pcib0 > ebus0: mem > 0x70000000-0x70ffffff,0x71000000-0x717fffff at dev > ice 1.0 on pci0 > auxio0: addr > 0x1400726000-0x1400726003,0x1400728000-0x140072 > 8003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f0 > 03 on ebus0 > ebus0: addr 0x1400724000-0x1400724003 (no driver attached) > ebus0: addr 0x1400504000-0x1400504002 (no driver attached) > ebus0: addr 0x1400500000-0x1400500007 (no driver attached) > scc0: addr > 0x1400400000-0x140040007f irq 43 > on ebus0 > scc0: [FILTER] > uart0: on scc0 > uart0: [FILTER] > uart0: CTS oflow > uart0: console (9600,n,8,1) > uart1: on scc0 > uart1: [FILTER] > uart1: CTS oflow > uart2: <16550 or compatible> addr 0x14003083f8-0x14003083ff irq 41 on ebus0 > uart2: [FILTER] > uart2: keyboard (1200,n,8,1) > uart2: keyboard not present > uart3: <16550 or compatible> addr 0x14003062f8-0x14003062ff irq 42 on ebus0 > uart3: [FILTER] > ebus0: addr > 0x14003043bc-0x14003043cb,0x1400300398-0x1400300399,0x1400700 > 000-0x140070000f irq 34 (no driver attached) > ebus0: addr > 0x14003023f0-0x14003023f7,0x1400706000-0x140070600f,0x1400 > 720000-0x1400720003 irq 39 (no driver attached) > eeprom0: addr 0x1400000000-0x1400001fff on ebus0 > eeprom0: model mk48t59 > ebus0: addr 0x1000000000-0x10000fffff (no driver attached) > ebus0: addr > 0x1400200000-0x14002000ff,0x1400702000-0x140070200f,0x > 1400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 (no driver > attached) > hme0: mem 0x100000-0x107fff at device 1.1 on pci0 > miibus0: on hme0 > qsphy0: PHY 1 on miibus0 > qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > hme0: Ethernet address: 08:00:20:a3:71:69 > hme0: [ITHREAD] > sym0: <875> port 0x1000-0x10ff mem 0x108000-0x1080ff,0x10a000-0x10afff > at device > 3.0 on pci0 > sym0: No NVRAM, ID 7, Fast-20, SE, parity checking > sym0: [ITHREAD] > sym1: <875> port 0x1400-0x14ff mem 0x10c000-0x10c0ff,0x10e000-0x10efff > at device > 3.1 on pci0 > sym1: No NVRAM, ID 7, Fast-20, SE, parity checking > sym1: [ITHREAD] > pcib1: mem > 0x1fe00002000-0x1fe00003fff,0x1fe01800000-0x1fe0 > 18000ff,0x1fe00000000-0x1fe0000cfff irq 2032,2030,2031,2021,2024,2034 on > nexus0 > pcib1: Psycho, impl 0, version 4, IGN 0x1f, bus A, 66MHz > pcib1: [FILTER] > pci1: on pcib1 > pci1: at device 1.0 (no driver attached) > creator0: mem > 0x1fc00000000-0x1fc000003ff,0x1fc00400000-0x1fc005ffff > f,0x1fc00600000-0x1fc007fffff,0x1fc01000000-0x1fc013fffff,0x1fc01400000-0x1fc017 > fffff,0x1fc01800000-0x1fc01bfffff,0x1fc01c00000-0x1fc01ffffff,0x1fc02000000-0x1f > c02ffffff,0x1fc03000000-0x1fc03ffffff,0x1fc04000000-0x1fc043fffff,0x1fc04400000- > 0x1fc047fffff,0x1fc04800000-0x1fc04bfffff,0x1fc04c00000-0x1fc04ffffff,0x1fc05000 > 000-0x1fc05ffffff,0x1fc06000000-0x1fc07ffffff,0x1fc09000000-0x1fc097fffff,0x1fc0 > 9800000-0x1fc09ffffff,0x1fc0a000000-0x1fc0affffff,0x1fc0b000000-0x1fc0b7fffff,0x > 1fc0b800000-0x1fc0bffffff,0x1fc0c000000-0x1fc0c3fffff,0x1fc0c800000-0x1fc0cfffff > f,0x1fc0d000000-0x1fc0d7fffff,0x1fc0d800000-0x1fc0dffffff irq 1925 on nexus0 > creator0: resolution 1152x900 > syscons0: on nexus0 > syscons0: Unknown <16 virtual consoles, flags=0x100> > Timecounter "tick" frequency 449992390 Hz quality 1000 > Timecounters tick every 1.000 msec > Waiting 5 seconds for SCSI devices to settle > (probe6:sym0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe6:sym0:0:6:0): CAM Status: SCSI Status Error > (probe6:sym0:0:6:0): SCSI Status: Check Condition > (probe6:sym0:0:6:0): NOT READY asc:3a,0 > (probe6:sym0:0:6:0): Medium not present > (probe6:sym0:0:6:0): Unretryable error > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da1: Command Queueing Enabled > da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da0: Command Queueing Enabled > da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) > cd0 at sym0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 16) > cd0: Attempt to query device size failed: NOT READY, Medium not present > WARNING: WITNESS option enabled, expect reduced performance. > GEOM: da0: adding VTOC8 information. > GEOM: da1: adding VTOC8 information. > Trying to mount root from ufs:/dev/da0a > Loading configuration files. > kernel dumps on /dev/da0b > Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: > memory addres > s not aligned > cpuid = 0 > KDB: enter: panic > [thread pid 41 tid 100042 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> > db> bt > Tracing pid 41 tid 100042 td 0xfffff800213dc370 > panic() at panic+0x20c > trap() at trap+0x570 > -- memory address not aligned sfar=0xf2fe2877 sfsr=0x40029 %o7=0xc06654b8 -- > stack_capture() at stack_capture+0x114 > stack_save_td() at stack_save_td+0x60 > sysctl_kern_proc_kstack() at sysctl_kern_proc_kstack+0x36c > sysctl_root() at sysctl_root+0x1ec > userland_sysctl() at userland_sysctl+0x174 > __sysctl() at __sysctl+0x70 > syscall() at syscall+0x2f0 > -- syscall (202, FreeBSD ELF64, __sysctl) %o7=0x101628 -- > userland() at 0x40445788 > user trace: trap %o7=0x101628 > pc 0x40445788, sp 0x7fdffffd031 > pc 0x101ef8, sp 0x7fdffffd971 > pc 0x102ac4, sp 0x7fdffffdaf1 > pc 0x100ef0, sp 0x7fdffffe451 > pc 0x40208094, sp 0x7fdffffe511 > done Hrm, this looks like the problem solved with r184376. Do you cross-compile with a GCC older than 4.2 maybe? Marius From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:01:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C22C106564A; Sun, 22 Mar 2009 00:01:18 +0000 (UTC) (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 18DE98FC13; Sun, 22 Mar 2009 00:01:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2M01GuS045766; Sat, 21 Mar 2009 20:01:16 -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.14.3/8.14.3) with ESMTP id n2M01GgE064964; Sat, 21 Mar 2009 20:01:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 00BBD7302F; Sat, 21 Mar 2009 19:01:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090322000116.00BBD7302F@freebsd-current.sentex.ca> Date: Sat, 21 Mar 2009 19:01:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:01:19 -0000 TB --- 2009-03-21 23:22:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-21 23:22:56 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-03-21 23:22:56 - cleaning the object tree TB --- 2009-03-21 23:23:29 - cvsupping the source tree TB --- 2009-03-21 23:23:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-03-21 23:23:46 - building world TB --- 2009-03-21 23:23:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-21 23:23:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-21 23:23:46 - TARGET=powerpc TB --- 2009-03-21 23:23:46 - TARGET_ARCH=powerpc TB --- 2009-03-21 23:23:46 - TZ=UTC TB --- 2009-03-21 23:23:46 - __MAKE_CONF=/dev/null TB --- 2009-03-21 23:23:46 - cd /src TB --- 2009-03-21 23:23:46 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 21 23:23:47 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libpam/libpam (all) ===> lib/libpcap (all) cc -O2 -pipe -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H -I/src/lib/libpcap/../../contrib/libpcap -std=gnu99 -fstack-protector -c grammar.c cc -O2 -pipe -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H -I/src/lib/libpcap/../../contrib/libpcap -std=gnu99 -fstack-protector -c /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c: In function 'pcap_activate_bpf': /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: 'to_ms' undeclared (first use in this function) /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: (Each undeclared identifier is reported only once /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-22 00:01:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-22 00:01:15 - ERROR: failed to build world TB --- 2009-03-22 00:01:15 - 1786.95 user 191.24 system 2299.67 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:03:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F001F1065670; Sun, 22 Mar 2009 00:03:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 99B8A8FC12; Sun, 22 Mar 2009 00:03:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2M03EU1023232; Sat, 21 Mar 2009 20:03:14 -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.14.3/8.14.3) with ESMTP id n2M03EjH021674; Sat, 21 Mar 2009 20:03:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F265E7302F; Sat, 21 Mar 2009 19:03:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090322000313.F265E7302F@freebsd-current.sentex.ca> Date: Sat, 21 Mar 2009 19:03:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:03:20 -0000 TB --- 2009-03-21 23:27:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-21 23:27:03 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-03-21 23:27:03 - cleaning the object tree TB --- 2009-03-21 23:27:27 - cvsupping the source tree TB --- 2009-03-21 23:27:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-03-21 23:27:39 - building world TB --- 2009-03-21 23:27:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-21 23:27:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-21 23:27:39 - TARGET=sparc64 TB --- 2009-03-21 23:27:39 - TARGET_ARCH=sparc64 TB --- 2009-03-21 23:27:39 - TZ=UTC TB --- 2009-03-21 23:27:39 - __MAKE_CONF=/dev/null TB --- 2009-03-21 23:27:39 - cd /src TB --- 2009-03-21 23:27:39 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 21 23:27:41 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libpam/libpam (all) ===> lib/libpcap (all) cc -O2 -pipe -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H -I/src/lib/libpcap/../../contrib/libpcap -std=gnu99 -fstack-protector -c grammar.c cc -O2 -pipe -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H -I/src/lib/libpcap/../../contrib/libpcap -std=gnu99 -fstack-protector -c /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c: In function 'pcap_activate_bpf': /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: 'to_ms' undeclared (first use in this function) /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: (Each undeclared identifier is reported only once /src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1897: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-22 00:03:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-22 00:03:13 - ERROR: failed to build world TB --- 2009-03-22 00:03:13 - 1677.20 user 186.70 system 2170.06 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:03:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A4E1065716 for ; Sun, 22 Mar 2009 00:03:37 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 439988FC0A for ; Sun, 22 Mar 2009 00:03:37 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 3B214FF31; Sun, 22 Mar 2009 13:03:36 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsuB0xFUkWLo; Sun, 22 Mar 2009 13:03:32 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sun, 22 Mar 2009 13:03:32 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 77C951142F; Sun, 22 Mar 2009 13:03:31 +1300 (NZDT) Date: Sat, 21 Mar 2009 17:03:31 -0700 From: Andrew Thompson To: Anonymous Message-ID: <20090322000331.GA50126@citylink.fud.org.nz> References: <200903211448.28590.pieter@degoeje.nl> <200903211706.58474.hselasky@c2i.net> <200903212222.23952.pieter@degoeje.nl> <861vsqe8n2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <861vsqe8n2.fsf@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Pieter de Goeje , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:03:38 -0000 On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > Pieter de Goeje writes: > > > On Saturday 21 March 2009, Hans Petter Selasky wrote: > >> On Saturday 21 March 2009, Pieter de Goeje wrote: > >> > Since a couple of weeks usbconfig and hal-device no longer list my usb > >> > devices. I know it worked before (also with the new USB stack). I think > >> > this causes my mouse to not work in X, while it works fine on the > >> > console. I've double checked that I don't have libusb from ports > >> > installed. I've rebuild kernel/world, make delete-old && make delete-old > >> > libs, recompiled hald, but still no success. > >> > > >> > $ uname -a > >> > FreeBSD nox.student.utwente.nl 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat > >> > Mar 21 13:37:32 CET 2009 > >> > pyotr@nox.student.utwente.nl:/usr/obj/FreeBSD/FreeBSD-current/src/sys/GEN > >> >ER IC i386 > >> > > [...] > >> > >> Make sure that the devices under /dev/usb/xxx have proper permissions. > >> > >> --HPS > > > > Yes, they all have the same permissions: crw-------. I'm running usbconfig as > > root btw, so it shouldn't matter. > > > > I added a bunch of printf()s to libusb, specifically ugen20_enumerate(). > > Both ugen0.2 and ugen1.2 failed at ioctl(f, USB_GET_PLUGTIME, &plugtime) > > because it returned EINVAL. The ugenX.2 files were opened successfully. > > > > At this point it looks like the problem lies somewhere in the kernel, which > > makes it a lot harder for me to debug. > > Can you try to back out r189906? Doing so makes my keyboard to appear in > usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 -a 3'. > What does sysctl hw.usb2.dev.debug=2 show with usbconfig on the latest HEAD code? Andrew From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:04:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2518106570C; Sun, 22 Mar 2009 00:04:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6618FC0C; Sun, 22 Mar 2009 00:04:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M03NtY099273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 20:03:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: freebsd-x11 , freebsd-current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-x1k8ey71H+B5aF+1Sov1" Organization: FreeBSD Date: Sat, 21 Mar 2009 19:04:23 -0500 Message-Id: <1237680263.1938.10.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Subject: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:04:46 -0000 --=-x1k8ey71H+B5aF+1Sov1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok, this patch should work on NV50 chips also. What you get is EXA and Xv. You still need: A recent -CURRENT or -STABLE. git master of libdrm and xf86-video-nouveau. This patch. Things I've figured out since the last patch... On NV50 class hardware you need to have a compositing manager running for Xv to work. That means xcompmgr, metacity with composite enabled, xfce (rumored to work as well, haven't tried). If your running Gnome with metacity, open gconf-editor and go to apps->metacity->general and check the composite box. On NV40 class hardware, you don't need the composite manager. In fact (at least with Xserver 1.6 which I'm running now), if a composite manager is enabled, I'm seeing high cpu utilization from Xorg under some circumstances. I don't think this is a drm issue, but still an issue. For me, if I start a video using mplayer in an xterm, cpu is fine as long as that xterm is the foreground window. If it is not the foreground window, even if it isn't obscured I see the cpu utilization. Disabling the composite manager makes everything fine. http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch robert. --=20 Robert Noland FreeBSD --=-x1k8ey71H+B5aF+1Sov1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFgIcACgkQM4TrQ4qfRONLQgCfSqCyQn5naAsZyidgzfpzd8oO vV4An1rzwBAmTPx7Lk+6q9gwpYqn3IU3 =qIHs -----END PGP SIGNATURE----- --=-x1k8ey71H+B5aF+1Sov1-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:06:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86A61065729; Sun, 22 Mar 2009 00:06:35 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 99D368FC15; Sun, 22 Mar 2009 00:06:35 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id 6AA411CC64; Sat, 21 Mar 2009 17:06:33 -0700 (PDT) Date: Sat, 21 Mar 2009 17:06:33 -0700 From: Ulf Zimmermann To: Mike Tancsa Message-ID: <20090322000633.GI51533@evil.alameda.net> References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <200903212149.n2LLnC94037010@lava.sentex.ca> <20090321222116.GG51533@evil.alameda.net> <200903212323.n2LNN3La037490@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903212323.n2LNN3La037490@lava.sentex.ca> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.5-PRERELEASE MailScanner-NULL-Check: 1238285195.31393@EJLZPLkBS5ttkNLkaGJrVQ X-ANI-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 6AA411CC64.99761 X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:06:36 -0000 On Sat, Mar 21, 2009 at 07:23:19PM -0400, Mike Tancsa wrote: > At 06:21 PM 3/21/2009, Ulf Zimmermann wrote: > >> > >> Nothing in the BIOS for the eSATA port other than "IDE/RAID" or > >> "enable/disable". Its set to IDE and enabled. > >> > >> >Don't you have any datasheet for this device? > >> > >> No, its just a generic Intel branded board (Intel DX58SO) > >> > >> >Also a bit strange for me this messages: > >> >ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > >> >ata0: reset tp1 mask=00 ostat0=ff ostat1=ff > >> >ata0: [MPSAFE] > >> >ata0: [ITHREAD] > >> >ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > >> >ata1: reset tp1 mask=00 ostat0=ff ostat1=ff > >> >ata1: [MPSAFE] > >> >ata1: [ITHREAD] > >> >channels 0 and 1 are legacy ATA channels. A bit strange to see them > >> >when AFAIK there is no PATA support on ICH10. If it is not a parts > >> >of Marvell, then I have no idea what is this. > >> > >> Interesting, pciconf shows it as sata > >> > >> 0[i7]# pciconf -lvc > >> hostb0@pci0:0:0:0: class=0x060000 card=0x4f538086 > >> chip=0x34058086 rev=0x12 hdr=0x00 > >> vendor = 'Intel Corporation' > >> class = bridge > >> subclass = HOST-PCI > >> cap 00[40] = unknown > >> atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 > >> chip=0x612111ab rev=0xb2 hdr=0x00 > >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > >> device = '6121 SATA2 Controller' > >> class = mass storage > >> subclass = ATA > >> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 > >> cap 05[50] = MSI supports 1 message > >> cap 10[e0] = PCI-Express 1 legacy endpoint > > > >I would try to run it as RAID, as per the technical product spec from > >Intel it supports running single non-raid configs. > > No difference, the dmesg looks the same with RAID enabled > > atapci0: port > 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f > mem 0xe1100000-0xe11003ff irq 16 at device 0.0 on pci6 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > > atapci0@pci0:6:0:0: class=0x01048f card=0x4f538086 > chip=0x612111ab rev=0xb2 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '6121 SATA2 Controller' > class = mass storage > subclass = RAID > cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 > cap 05[50] = MSI supports 1 message > cap 10[e0] = PCI-Express 1 legacy endpoint > > > 0[i7]# atacontrol list > ATA channel 0: > Master: no device present > Slave: no device present > ATA channel 1: > Master: no device present > Slave: no device present > ATA channel 2: > Master: no device present > Slave: no device present > ATA channel 3: > Master: no device present > Slave: no device present > ATA channel 4: > Master: ad8 SATA revision 1.x > Slave: no device present > ATA channel 5: > Master: no device present > Slave: no device present > ATA channel 6: > Master: no device present > Slave: no device present > ATA channel 7: > Master: no device present > Slave: no device present > ATA channel 8: > Master: no device present > Slave: no device present > 0[i7]# > > ---Mike Soren was asking for controller cards which have this chip on board before he stopped working on the ATA/SATA stuff. Specific because of ESATA support I believe. So it might just not work with the current driver. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 00:38:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7835106566B; Sun, 22 Mar 2009 00:38:00 +0000 (UTC) (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 53B588FC0A; Sun, 22 Mar 2009 00:38:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2M0bwUm048704; Sat, 21 Mar 2009 20:37:58 -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.14.3/8.14.3) with ESMTP id n2M0bwfw076576; Sat, 21 Mar 2009 20:37:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8E35B7302F; Sat, 21 Mar 2009 19:37:58 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090322003758.8E35B7302F@freebsd-current.sentex.ca> Date: Sat, 21 Mar 2009 19:37:58 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 00:38:01 -0000 TB --- 2009-03-22 00:01:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-22 00:01:15 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-03-22 00:01:16 - cleaning the object tree TB --- 2009-03-22 00:01:45 - cvsupping the source tree TB --- 2009-03-22 00:01:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-03-22 00:01:59 - building world TB --- 2009-03-22 00:01:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-22 00:01:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-22 00:01:59 - TARGET=sun4v TB --- 2009-03-22 00:01:59 - TARGET_ARCH=sparc64 TB --- 2009-03-22 00:01:59 - TZ=UTC TB --- 2009-03-22 00:01:59 - __MAKE_CONF=/dev/null TB --- 2009-03-22 00:01:59 - cd /src TB --- 2009-03-22 00:01:59 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 22 00:02:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] sed -e 's/yy/ipf_yy/g' -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' y.tab.c > ipf_y.c sed -e 's/yy/ipf_yy/g' y.tab.h > ipf_y.h sed -e 's/yy/ipf_yy/g' -e 's/y.tab.h/ipf_y.h/' -e 's/lexer.h/ipf_l.h/' /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/lexer.c > ipf_l.c rm -f .depend mkdep -f .depend -a -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipfcomp.c ipf_y.c ipf_l.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/bpf_filter.c In file included from /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf_y.y:15: /obj/sun4v/src/tmp/usr/include/pcap.h:74:23: error: pcap/pcap.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sbin/ipf/ipf. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-22 00:37:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-22 00:37:58 - ERROR: failed to build world TB --- 2009-03-22 00:37:58 - 1852.62 user 209.92 system 2202.52 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 01:16:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6984106564A; Sun, 22 Mar 2009 01:16:54 +0000 (UTC) (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 926918FC12; Sun, 22 Mar 2009 01:16:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2M1Gq2i050643; Sat, 21 Mar 2009 21:16:52 -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.14.3/8.14.3) with ESMTP id n2M1Gq7d089658; Sat, 21 Mar 2009 21:16:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4D3877302F; Sat, 21 Mar 2009 20:16:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090322011652.4D3877302F@freebsd-current.sentex.ca> Date: Sat, 21 Mar 2009 20:16:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 01:16:55 -0000 TB --- 2009-03-22 00:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-22 00:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-03-22 00:40:00 - cleaning the object tree TB --- 2009-03-22 00:40:39 - cvsupping the source tree TB --- 2009-03-22 00:40:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-03-22 00:40:58 - building world TB --- 2009-03-22 00:40:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-22 00:40:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-22 00:40:58 - TARGET=arm TB --- 2009-03-22 00:40:58 - TARGET_ARCH=arm TB --- 2009-03-22 00:40:58 - TZ=UTC TB --- 2009-03-22 00:40:58 - __MAKE_CONF=/dev/null TB --- 2009-03-22 00:40:58 - cd /src TB --- 2009-03-22 00:40:58 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 22 00:41:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] sed -e 's/yy/ipf_yy/g' -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' y.tab.c > ipf_y.c sed -e 's/yy/ipf_yy/g' y.tab.h > ipf_y.h sed -e 's/yy/ipf_yy/g' -e 's/y.tab.h/ipf_y.h/' -e 's/lexer.h/ipf_l.h/' /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/lexer.c > ipf_l.c rm -f .depend mkdep -f .depend -a -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipfcomp.c ipf_y.c ipf_l.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/bpf_filter.c In file included from /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf_y.y:15: /obj/arm/src/tmp/usr/include/pcap.h:74:23: error: pcap/pcap.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sbin/ipf/ipf. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-22 01:16:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-22 01:16:52 - ERROR: failed to build world TB --- 2009-03-22 01:16:52 - 1623.99 user 219.03 system 2211.60 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 01:21:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39389106566B for ; Sun, 22 Mar 2009 01:21:52 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by mx1.freebsd.org (Postfix) with ESMTP id ADEC68FC16 for ; Sun, 22 Mar 2009 01:21:51 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.170.109]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n2M1LbIS018384; Sun, 22 Mar 2009 02:21:37 +0100 From: Pieter de Goeje To: Andrew Thompson Date: Sun, 22 Mar 2009 01:52:54 +0100 User-Agent: KMail/1.9.10 References: <200903211448.28590.pieter@degoeje.nl> <861vsqe8n2.fsf@gmail.com> <20090322000331.GA50126@citylink.fud.org.nz> In-Reply-To: <20090322000331.GA50126@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903220152.55252.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Anonymous , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 01:21:52 -0000 On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > Pieter de Goeje writes: > > > On Saturday 21 March 2009, Hans Petter Selasky wrote: > > >> On Saturday 21 March 2009, Pieter de Goeje wrote: > > >> > Since a couple of weeks usbconfig and hal-device no longer list my > > >> > usb devices. I know it worked before (also with the new USB stack). > > >> > I think this causes my mouse to not work in X, while it works fine > > >> > on the console. I've double checked that I don't have libusb from > > >> > ports installed. I've rebuild kernel/world, make delete-old && make > > >> > delete-old libs, recompiled hald, but still no success. > > >> > > > >> > $ uname -a > > >> > FreeBSD nox.student.utwente.nl 8.0-CURRENT FreeBSD 8.0-CURRENT #0: > > >> > Sat Mar 21 13:37:32 CET 2009 > > >> > pyotr@nox.student.utwente.nl:/usr/obj/FreeBSD/FreeBSD-current/src/sy > > >> >s/GEN ER IC i386 > > > > [...] > > > > >> Make sure that the devices under /dev/usb/xxx have proper permissions. > > >> > > >> --HPS > > > > > > Yes, they all have the same permissions: crw-------. I'm running > > > usbconfig as root btw, so it shouldn't matter. > > > > > > I added a bunch of printf()s to libusb, specifically > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The ugenX.2 > > > files were opened successfully. > > > > > > At this point it looks like the problem lies somewhere in the kernel, > > > which makes it a lot harder for me to debug. > > > > Can you try to back out r189906? Doing so makes my keyboard to appear in > > usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 -a 3'. I'll give it a shot. It's rather late so the results will probably have to wait until tomorrow. > > What does sysctl hw.usb2.dev.debug=2 show with usbconfig on the latest > HEAD code? Output is quite long so I put it on the web: http://unforgiven.student.utwente.nl/~pyotr/dump/usbconfig_debug_2.txt -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 01:24:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C8EE106576E; Sun, 22 Mar 2009 01:24:44 +0000 (UTC) (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 078198FC2B; Sun, 22 Mar 2009 01:24:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2M1OccD050982; Sat, 21 Mar 2009 21:24:38 -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.14.3/8.14.3) with ESMTP id n2M1Ocw6092115; Sat, 21 Mar 2009 21:24:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 011727302F; Sat, 21 Mar 2009 20:24:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090322012438.011727302F@freebsd-current.sentex.ca> Date: Sat, 21 Mar 2009 20:24:37 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 01:24:48 -0000 TB --- 2009-03-22 00:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-22 00:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-03-22 00:40:00 - cleaning the object tree TB --- 2009-03-22 00:41:16 - cvsupping the source tree TB --- 2009-03-22 00:41:16 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-03-22 00:41:30 - building world TB --- 2009-03-22 00:41:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-22 00:41:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-22 00:41:30 - TARGET=amd64 TB --- 2009-03-22 00:41:30 - TARGET_ARCH=amd64 TB --- 2009-03-22 00:41:30 - TZ=UTC TB --- 2009-03-22 00:41:30 - __MAKE_CONF=/dev/null TB --- 2009-03-22 00:41:30 - cd /src TB --- 2009-03-22 00:41:30 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 22 00:41:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] sed -e 's/yy/ipf_yy/g' -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' y.tab.c > ipf_y.c sed -e 's/yy/ipf_yy/g' y.tab.h > ipf_y.h sed -e 's/yy/ipf_yy/g' -e 's/y.tab.h/ipf_y.h/' -e 's/lexer.h/ipf_l.h/' /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/lexer.c > ipf_l.c rm -f .depend mkdep -f .depend -a -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipfcomp.c ipf_y.c ipf_l.c /src/sbin/ipf/ipf/../../../contrib/ipfilter/bpf_filter.c In file included from /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf_y.y:15: /obj/amd64/src/tmp/usr/include/pcap.h:74:23: error: pcap/pcap.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sbin/ipf/ipf. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-22 01:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-22 01:24:37 - ERROR: failed to build world TB --- 2009-03-22 01:24:37 - 1992.59 user 228.91 system 2677.34 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 02:18:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED4C1065672 for ; Sun, 22 Mar 2009 02:18:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6764E8FC0A for ; Sun, 22 Mar 2009 02:18:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M2Iqp6048558 for ; Sat, 21 Mar 2009 19:18:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M2IqiX048557 for freebsd-current@freebsd.org; Sat, 21 Mar 2009 19:18:52 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 19:18:52 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20090322021852.GA48543@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 02:18:52 -0000 Kernel and world are from today sources. If I start firefox3, redraws become painfully slow. Top(1) shows last pid: 22285; load averages: 0.06, 0.06, 0.02 up 0+20:53:52 19:14:55 52 processes: 1 running, 51 sleeping CPU: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle Mem: 123M Active, 15M Inact, 170M Wired, 5228K Cache, 110M Buf, 671M Free Swap: 1024M Total, 8K Used, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 22281 kargl 8 96 0 59440K 39328K ucond 0 0:01 7.81% firefox-bi 22190 kargl 1 96 0 286M 270M drmwtq 1 0:13 2.20% Xorg REMOVE:kargl[33] dmesg | grep drm drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] error: [drm:pid1757:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 drm0: [ITHREAD] error: [drm:pid21228:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 drm0: [ITHREAD] -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 02:25:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 412E9106566C for ; Sun, 22 Mar 2009 02:25:18 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id E37308FC17 for ; Sun, 22 Mar 2009 02:25:17 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M2NuFZ099923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 22:23:56 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322021852.GA48543@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Chr+eWpPPdjWe6YALhDB" Organization: FreeBSD Date: Sat, 21 Mar 2009 21:24:56 -0500 Message-Id: <1237688696.1756.3.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 02:25:18 -0000 --=-Chr+eWpPPdjWe6YALhDB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 19:18 -0700, Steve Kargl wrote: > Kernel and world are from today sources. If I start firefox3, > redraws become painfully slow. Top(1) shows Todays, -CURRENT or -STABLE? robert. > last pid: 22285; load averages: 0.06, 0.06, 0.02 up 0+20:53:52 19= :14:55 > 52 processes: 1 running, 51 sleeping > CPU: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle > Mem: 123M Active, 15M Inact, 170M Wired, 5228K Cache, 110M Buf, 671M Free > Swap: 1024M Total, 8K Used, 1024M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMM= AND > 22281 kargl 8 96 0 59440K 39328K ucond 0 0:01 7.81% fire= fox-bi > 22190 kargl 1 96 0 286M 270M drmwtq 1 0:13 2.20% Xorg >=20 > REMOVE:kargl[33] dmesg | grep drm > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xe0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 > drm0: [ITHREAD] > error: [drm:pid1757:i915_get_vblank_counter] *ERROR* trying to get vblank= count for disabled pipe 0 > drm0: [ITHREAD] > error: [drm:pid21228:i915_get_vblank_counter] *ERROR* trying to get vblan= k count for disabled pipe 0 > drm0: [ITHREAD] --=20 Robert Noland FreeBSD --=-Chr+eWpPPdjWe6YALhDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFoXgACgkQM4TrQ4qfROOu6QCbBtHY0rzHrJ1hfllXGgCzFk7x e5IAn3dcpErv6hmUjHjpRfZFnnkz8D4+ =ZFIC -----END PGP SIGNATURE----- --=-Chr+eWpPPdjWe6YALhDB-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 02:28:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467E31065672; Sun, 22 Mar 2009 02:28:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0AE8FC15; Sun, 22 Mar 2009 02:28:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M2Skgu048662; Sat, 21 Mar 2009 19:28:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M2Skr5048661; Sat, 21 Mar 2009 19:28:46 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 19:28:46 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20090322022846.GA48644@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237688696.1756.3.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 02:28:46 -0000 On Sat, Mar 21, 2009 at 09:24:56PM -0500, Robert Noland wrote: > On Sat, 2009-03-21 at 19:18 -0700, Steve Kargl wrote: > > Kernel and world are from today sources. If I start firefox3, > > redraws become painfully slow. Top(1) shows > > Todays, -CURRENT or -STABLE? > -current. This is a Dell Latitude D530 laptop. Do you need any other info. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 02:33:10 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58091065673 for ; Sun, 22 Mar 2009 02:33:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id A91F88FC19 for ; Sun, 22 Mar 2009 02:33:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M2VnYc099962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 22:31:49 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322022846.GA48644@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Mx7Lx3jjhXFbomK5D3+j" Organization: FreeBSD Date: Sat, 21 Mar 2009 21:32:49 -0500 Message-Id: <1237689169.1756.5.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 02:33:11 -0000 --=-Mx7Lx3jjhXFbomK5D3+j Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 19:28 -0700, Steve Kargl wrote: > On Sat, Mar 21, 2009 at 09:24:56PM -0500, Robert Noland wrote: > > On Sat, 2009-03-21 at 19:18 -0700, Steve Kargl wrote: > > > Kernel and world are from today sources. If I start firefox3, > > > redraws become painfully slow. Top(1) shows > >=20 > > Todays, -CURRENT or -STABLE? > >=20 >=20 > -current. This is a Dell Latitude D530 laptop. Do you need > any other info. I assume that it is fine before a vt switch, then bad after. Does that match with what you are seeing? robert. --=20 Robert Noland FreeBSD --=-Mx7Lx3jjhXFbomK5D3+j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFo1EACgkQM4TrQ4qfROOLTQCfdlqjOGA9wlfLwK3n6ntZ6/UD k80An1SKBxe4fABJdVcQxomviETUz/RZ =t96M -----END PGP SIGNATURE----- --=-Mx7Lx3jjhXFbomK5D3+j-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 02:47:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED16106564A; Sun, 22 Mar 2009 02:47:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1BC8FC08; Sun, 22 Mar 2009 02:47:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M2ltce048841; Sat, 21 Mar 2009 19:47:55 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M2ltpa048840; Sat, 21 Mar 2009 19:47:55 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 19:47:55 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20090322024755.GA48794@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237689169.1756.5.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 02:47:55 -0000 On Sat, Mar 21, 2009 at 09:32:49PM -0500, Robert Noland wrote: > On Sat, 2009-03-21 at 19:28 -0700, Steve Kargl wrote: > > On Sat, Mar 21, 2009 at 09:24:56PM -0500, Robert Noland wrote: > > > On Sat, 2009-03-21 at 19:18 -0700, Steve Kargl wrote: > > > > Kernel and world are from today sources. If I start firefox3, > > > > redraws become painfully slow. Top(1) shows > > > > > > Todays, -CURRENT or -STABLE? > > > > > > > -current. This is a Dell Latitude D530 laptop. Do you need > > any other info. > > I assume that it is fine before a vt switch, then bad after. Does that > match with what you are seeing? > I boot. Login in at a vt, then almost immediately do ssh-agent startx -- -depth 16 >& ~/tmp/.x.out I do not switch from X11 back to a console. Note xterm works fine. The sluggish only appears when I fire up firefox3, but I haven't tried other big apps like openoffice. Also, note I just installed a kernel without drm. Starting firefox3 with this new kernel does not cause the sluggish behavior. I also just noticed that dmesg had drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) Is it possible to disable MSI and still run drm? -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:09:42 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FEB2106566B for ; Sun, 22 Mar 2009 03:09:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id EEFAB8FC14 for ; Sun, 22 Mar 2009 03:09:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M38KN5000230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 23:08:20 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322024755.GA48794@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1WgzFqYmCOWildTp37hv" Organization: FreeBSD Date: Sat, 21 Mar 2009 22:09:20 -0500 Message-Id: <1237691360.1756.13.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:09:42 -0000 --=-1WgzFqYmCOWildTp37hv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote: > On Sat, Mar 21, 2009 at 09:32:49PM -0500, Robert Noland wrote: > > On Sat, 2009-03-21 at 19:28 -0700, Steve Kargl wrote: > > > On Sat, Mar 21, 2009 at 09:24:56PM -0500, Robert Noland wrote: > > > > On Sat, 2009-03-21 at 19:18 -0700, Steve Kargl wrote: > > > > > Kernel and world are from today sources. If I start firefox3, > > > > > redraws become painfully slow. Top(1) shows > > > >=20 > > > > Todays, -CURRENT or -STABLE? > > > >=20 > > >=20 > > > -current. This is a Dell Latitude D530 laptop. Do you need > > > any other info. > >=20 > > I assume that it is fine before a vt switch, then bad after. Does that > > match with what you are seeing? > >=20 >=20 > I boot. Login in at a vt, then almost immediately do >=20 > ssh-agent startx -- -depth 16 >& ~/tmp/.x.out >=20 > I do not switch from X11 back to a console. =20 >=20 > Note xterm works fine. The sluggish only appears when I > fire up firefox3, but I haven't tried other big apps like > openoffice. >=20 > Also, note I just installed a kernel without drm. Starting > firefox3 with this new kernel does not cause the sluggish > behavior. >=20 > I also just noticed that dmesg had >=20 > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) >=20 > Is it possible to disable MSI and still run drm? Yes, There is a tuneable hw.drm.msi I did do all of the msi development on a 965gm. Unfortunately, I no longer have access to that hardware. Do you have witness enabled? robert. --=20 Robert Noland FreeBSD --=-1WgzFqYmCOWildTp37hv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFq+AACgkQM4TrQ4qfRONU+ACdF685pT9HUvJ53cELFLFgDjyg uZkAnA/8k7mKld2lUBbYRvsySsijfmsv =bxeS -----END PGP SIGNATURE----- --=-1WgzFqYmCOWildTp37hv-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:16:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6EAB106566B for ; Sun, 22 Mar 2009 03:16:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 810A18FC14 for ; Sun, 22 Mar 2009 03:16:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2M3F3Fo029794; Sat, 21 Mar 2009 21:15:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 21 Mar 2009 21:15:38 -0600 (MDT) Message-Id: <20090321.211538.-957825438.imp@bsdimp.com> To: pluknet@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:16:23 -0000 In message: pluknet writes: : Hi. : : Is it ok (and how much harmfull) to see this message? : : driver bug: Unable to set devclass (devname: (null)) When do you see it? Warner From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:19:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21740106566C; Sun, 22 Mar 2009 03:19:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D59468FC08; Sun, 22 Mar 2009 03:19:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2M3GJtW029801; Sat, 21 Mar 2009 21:16:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 21 Mar 2009 21:16:54 -0600 (MDT) Message-Id: <20090321.211654.1102538138.imp@bsdimp.com> To: pluknet@gmail.com From: "M. Warner Losh" In-Reply-To: References: <49B58CF6.7070104@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:19:26 -0000 In message: pluknet writes: : 2009/3/10 Alexander Motin : : > pluknet wrote: : >> : >> Is it ok (and how much harmfull) to see this message? : >> : >> driver bug: Unable to set devclass (devname: (null)) : >> : >> P.S. : >> This is introduced in subr_bus.c, v1.216 : >> - PDEBUG(("Unable to set device : >> class")); : >> + printf("driver bug: Unable to set : >> devclass (devname: %s)\n", : >> + (child ? : >> device_get_name(child) : : >> + "no device")); : >> : >> where PDEBUG was moved from BUS_DEBUG to general output. : > : > Actually this check was introduced in rev. 1.214, just was not logged. : > Before this change system could crash soon after this message. Now it should : > not, but related device probably will not work properly. It is probably not : > good and should be fixed, but it can be just a low memory symptom. It was : > noticed for ata driver, but I hope it was fixed. Where have you get it? : : This is during the boot, see dmesg (attached). Looks like something to do with atakbd or psm. What does your hints file look like? Warner From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:19:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490DD106564A; Sun, 22 Mar 2009 03:19:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EAAD58FC0A; Sun, 22 Mar 2009 03:19:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2M3J7Hc029816; Sat, 21 Mar 2009 21:19:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 21 Mar 2009 21:19:42 -0600 (MDT) Message-Id: <20090321.211942.-1540398823.imp@bsdimp.com> To: pluknet@gmail.com From: "M. Warner Losh" In-Reply-To: References: <49B594B5.2060706@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:19:28 -0000 In message: pluknet writes: : 2009/3/10 pluknet : : > 2009/3/10 Alexander Motin : : >> pluknet wrote: : >>> : >>> 2009/3/10 Alexander Motin : : >>>> : >>>> pluknet wrote: : >>>>> : >>>>> Is it ok (and how much harmfull) to see this message? : >>>>> : >>>>> driver bug: Unable to set devclass (devname: (null)) : >>>>> : >>>>> P.S. : >>>>> This is introduced in subr_bus.c, v1.216 : >>>>> - PDEBUG(("Unable to set device : >>>>> class")); : >>>>> + printf("driver bug: Unable to : >>>>> set : >>>>> devclass (devname: %s)\n", : >>>>> + (child ? : >>>>> device_get_name(child) : : >>>>> + "no device")); : >>>>> : >>>>> where PDEBUG was moved from BUS_DEBUG to general output. : >>>> : >>>> Actually this check was introduced in rev. 1.214, just was not logged. : >>>> Before this change system could crash soon after this message. Now it : >>>> should : >>>> not, but related device probably will not work properly. It is probably : >>>> not : >>>> good and should be fixed, but it can be just a low memory symptom. It was : >>>> noticed for ata driver, but I hope it was fixed. Where have you get it? : >>> : >>> This is during the boot, see dmesg (attached). : >> : >> It does not gives much info. Can you try to add dl->driver->name, : >> device_get_unit(child) and device_set_devclass() result printing there? : >> : > : > That gives: : > atkbd0: [GIANT-LOCKED] : > atkbd0: [ITHREAD] : > driver bug: Unable to set devclass (devname: (null)) : > dl->driver->name: atkbdc : > device_get_unit(child): -1 : > device_set_devclass(): 17 : > : : Well, yes. That confirms with numerous devclass_alloc_unit() EEXIST : hidden messages; : : atkbdc0: port 0x60,0x64 irq 1 on acpi0 : atkbd0: irq 1 on atkbdc0 : atkbd: the current kbd controller command byte 0065 : atkbd: keyboard ID 0x83ab (2) : kbd0 at atkbd0 : kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 : ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 : atkbd0: [GIANT-LOCKED] : atkbd0: [ITHREAD] : psm0: unable to allocate IRQ : atkbdc: atkbdc-1 already exists; skipping it Can you set a breakpoint on this line and give a traceback? : driver bug: Unable to set devclass (devname: (null)) : dl->driver->name: atkbdc : device_get_unit(child): -1 : atkbdc: atkbdc-1 already exists; skipping it Ditto : device_set_devclass(): 17 : psmcpnp0: port 0x60,0x64 irq 12 on acpi0 : psm0: current command byte:0065 : psm0: irq 12 on atkbdc0 : ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 55 : psm0: [GIANT-LOCKED] : psm0: [ITHREAD] : psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons : psm0: config:00000000, flags:00000008, packet size:4 : psm0: syncmask:08, syncbits:00 : ppc0: using extended I/O port range : ppc0: using extended I/O port range : pnp_identify: Trying Read_Port at 203 : pnp_identify: Trying Read_Port at 243 : pnp_identify: Trying Read_Port at 283 : pnp_identify: Trying Read_Port at 2c3 : pnp_identify: Trying Read_Port at 303 : pnp_identify: Trying Read_Port at 343 : pnp_identify: Trying Read_Port at 383 : pnp_identify: Trying Read_Port at 3c3 : PNP Identify complete : isa_probe_children: disabling PnP devices : pmtimer0 on isa0 : ata: ata0 already exists; skipping it : ata: ata1 already exists; skipping it : atkbdc: atkbdc0 already exists; skipping it : sc: sc0 already exists; skipping it : vga: vga0 already exists; skipping it No need for these... Warner From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:27:07 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 296A51065675; Sun, 22 Mar 2009 03:27:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0791A8FC13; Sun, 22 Mar 2009 03:27:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M3R70v049085; Sat, 21 Mar 2009 20:27:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M3R7L8049084; Sat, 21 Mar 2009 20:27:07 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 20:27:07 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20090322032707.GA49072@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237691360.1756.13.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:27:07 -0000 On Sat, Mar 21, 2009 at 10:09:20PM -0500, Robert Noland wrote: > On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote: > > > > I also just noticed that dmesg had > > > > drm0: on vgapci0 > > info: [drm] MSI enabled 1 message(s) > > > > Is it possible to disable MSI and still run drm? > > Yes, There is a tuneable hw.drm.msi > > I did do all of the msi development on a 965gm. Unfortunately, I no > longer have access to that hardware. > > Do you have witness enabled? > Yes. And invariants. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:39:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC5611065670 for ; Sun, 22 Mar 2009 03:39:21 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5788FC12 for ; Sun, 22 Mar 2009 03:39:21 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M3bx7T000372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 23:37:59 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322032707.GA49072@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> <20090322032707.GA49072@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+E1gLg8s1llXfgxeqoge" Organization: FreeBSD Date: Sat, 21 Mar 2009 22:38:59 -0500 Message-Id: <1237693139.1756.22.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:39:22 -0000 --=-+E1gLg8s1llXfgxeqoge Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 20:27 -0700, Steve Kargl wrote: > On Sat, Mar 21, 2009 at 10:09:20PM -0500, Robert Noland wrote: > > On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote: > > >=20 > > > I also just noticed that dmesg had > > >=20 > > > drm0: on vgapci0 > > > info: [drm] MSI enabled 1 message(s) > > >=20 > > > Is it possible to disable MSI and still run drm? > >=20 > > Yes, There is a tuneable hw.drm.msi > >=20 > > I did do all of the msi development on a 965gm. Unfortunately, I no > > longer have access to that hardware. > >=20 > > Do you have witness enabled? > >=20 >=20 > Yes. And invariants. Ok, and it isn't screaming that I did something bad? Mostly this is just a sync to what Intel is shipping... I did replace my irq handler with anholt's, but they were pretty close. robert. >=20 --=20 Robert Noland FreeBSD --=-+E1gLg8s1llXfgxeqoge Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFstMACgkQM4TrQ4qfROPj2wCeMYj0lnfyrgHNVr+1mUPAocDV nR0AnAv6k9pHQK3p21M+8DIjoiQjPuE8 =AHmg -----END PGP SIGNATURE----- --=-+E1gLg8s1llXfgxeqoge-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 03:57:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05A74106566C; Sun, 22 Mar 2009 03:57:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B73EB8FC0A; Sun, 22 Mar 2009 03:57:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M3vJ2G049303; Sat, 21 Mar 2009 20:57:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M3vJ6N049302; Sat, 21 Mar 2009 20:57:19 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 20:57:19 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20090322035719.GA49263@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> <20090322032707.GA49072@troutmask.apl.washington.edu> <1237693139.1756.22.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237693139.1756.22.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 03:57:19 -0000 On Sat, Mar 21, 2009 at 10:38:59PM -0500, Robert Noland wrote: > On Sat, 2009-03-21 at 20:27 -0700, Steve Kargl wrote: > > On Sat, Mar 21, 2009 at 10:09:20PM -0500, Robert Noland wrote: > > > On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote: > > > > > > > > I also just noticed that dmesg had > > > > > > > > drm0: on vgapci0 > > > > info: [drm] MSI enabled 1 message(s) > > > > > > > > Is it possible to disable MSI and still run drm? > > > > > > Yes, There is a tuneable hw.drm.msi > > > > > > I did do all of the msi development on a 965gm. Unfortunately, I no > > > longer have access to that hardware. > > > > > > Do you have witness enabled? > > > > > > > Yes. And invariants. > > Ok, and it isn't screaming that I did something bad? Mostly this is > just a sync to what Intel is shipping... I did replace my irq handler > with anholt's, but they were pretty close. > Neither witness nor invariant appear unhappy. The only think I see in /var/log/messages is Mar 21 19:30:33 REMOVE kernel: error: [drm:pid22190:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 IIRC, you said this can be ignored. I'll try disabling MSI later tonight. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 04:14:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3A99106566C for ; Sun, 22 Mar 2009 04:14:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id B41288FC08 for ; Sun, 22 Mar 2009 04:14:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M4DasJ000533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 00:13:37 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322035719.GA49263@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> <20090322032707.GA49072@troutmask.apl.washington.edu> <1237693139.1756.22.camel@balrog.2hip.net> <20090322035719.GA49263@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8Qzh9ffMx2/zfkJcVYiZ" Organization: FreeBSD Date: Sat, 21 Mar 2009 23:14:37 -0500 Message-Id: <1237695277.1756.32.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 04:14:59 -0000 --=-8Qzh9ffMx2/zfkJcVYiZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 20:57 -0700, Steve Kargl wrote: > On Sat, Mar 21, 2009 at 10:38:59PM -0500, Robert Noland wrote: > > On Sat, 2009-03-21 at 20:27 -0700, Steve Kargl wrote: > > > On Sat, Mar 21, 2009 at 10:09:20PM -0500, Robert Noland wrote: > > > > On Sat, 2009-03-21 at 19:47 -0700, Steve Kargl wrote: > > > > >=20 > > > > > I also just noticed that dmesg had > > > > >=20 > > > > > drm0: on vgapci0 > > > > > info: [drm] MSI enabled 1 message(s) > > > > >=20 > > > > > Is it possible to disable MSI and still run drm? > > > >=20 > > > > Yes, There is a tuneable hw.drm.msi > > > >=20 > > > > I did do all of the msi development on a 965gm. Unfortunately, I n= o > > > > longer have access to that hardware. > > > >=20 > > > > Do you have witness enabled? > > > >=20 > > >=20 > > > Yes. And invariants. > >=20 > > Ok, and it isn't screaming that I did something bad? Mostly this is > > just a sync to what Intel is shipping... I did replace my irq handler > > with anholt's, but they were pretty close. > >=20 >=20 > Neither witness nor invariant appear unhappy. The only think I see > in /var/log/messages is=20 >=20 > Mar 21 19:30:33 REMOVE kernel: error: [drm:pid22190:i915_get_vblank_count= er] *ERROR* trying to get vblank count for disabled pipe 0 I thought that I fixed this... I guess not. On the 965gm's LVDS is on pipe 1, so if your using a laptop with only the built in display, pipe 1 is active and pipe 0 is not. Something is being brain damaged and asking for vblank on both pipes or the wrong pipe. Are you seeing it only on vt switch, or in the logs while things are running? It should be harmless, at one point I had converted it to a debug message, but it slipped back in as an error. > IIRC, you said this can be ignored. >=20 > I'll try disabling MSI later tonight. There is a hardware errata on the 965gm regarding msi. Intel had huge trouble when they tried enabling it, but I could never produce the issue. They disabled msi for a while, but were still having problems. Then Eric reworked the irq handler much like mine and they re-enabled it. I ran that way on my 965 for quite a while before I pushed that code into the tree. It looks like what is happening is that user interrupts which Intel uses as markers in the command stream, are getting lost. Then it stuck waiting on things to catch up. I'm betting that if you enable drm debugging you will see several ioctl interrupted or restarting ioctl messages. I'm really frustrated with interrupts on Intel... You would think they could get this right. robert. --=20 Robert Noland FreeBSD --=-8Qzh9ffMx2/zfkJcVYiZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknFuy0ACgkQM4TrQ4qfROM+AgCeN1tc/r73jMGGwowtwmUs02Tq WjwAnidL1avsgTGaYAERslIoLH+1EHER =4r7W -----END PGP SIGNATURE----- --=-8Qzh9ffMx2/zfkJcVYiZ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 04:24:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB0D1065670 for ; Sun, 22 Mar 2009 04:24:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 429438FC0A for ; Sun, 22 Mar 2009 04:24:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 96839FF32; Sun, 22 Mar 2009 17:24:05 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnrnCUZjT+3e; Sun, 22 Mar 2009 17:24:01 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sun, 22 Mar 2009 17:24:01 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 349D31142F; Sun, 22 Mar 2009 17:24:01 +1300 (NZDT) Date: Sat, 21 Mar 2009 21:24:01 -0700 From: Andrew Thompson To: Pieter de Goeje Message-ID: <20090322042401.GB50126@citylink.fud.org.nz> References: <200903211448.28590.pieter@degoeje.nl> <861vsqe8n2.fsf@gmail.com> <20090322000331.GA50126@citylink.fud.org.nz> <200903220152.55252.pieter@degoeje.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903220152.55252.pieter@degoeje.nl> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Anonymous , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 04:24:06 -0000 On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > > > I added a bunch of printf()s to libusb, specifically > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The ugenX.2 > > > > files were opened successfully. > > > > > > > > At this point it looks like the problem lies somewhere in the kernel, > > > > which makes it a lot harder for me to debug. > > > > > > Can you try to back out r189906? Doing so makes my keyboard to appear in > > > usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 -a 3'. > > I'll give it a shot. It's rather late so the results will probably have to > wait until tomorrow. > > > > > What does sysctl hw.usb2.dev.debug=2 show with usbconfig on the latest > > HEAD code? > > Output is quite long so I put it on the web: > http://unforgiven.student.utwente.nl/~pyotr/dump/usbconfig_debug_2.txt I cant see anything obviously wrong with r189906 so I have committed some more debugging traces. Can you update your sources/kernel and run usbconfig again with hw.usb2.dev.debug=5 Andrew From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 05:39:33 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED4541065670; Sun, 22 Mar 2009 05:39:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id AE5368FC0A; Sun, 22 Mar 2009 05:39:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2M5dYCO050030; Sat, 21 Mar 2009 22:39:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2M5dY5I050029; Sat, 21 Mar 2009 22:39:34 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Mar 2009 22:39:34 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20090322053934.GA50002@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> <20090322032707.GA49072@troutmask.apl.washington.edu> <1237693139.1756.22.camel@balrog.2hip.net> <20090322035719.GA49263@troutmask.apl.washington.edu> <1237695277.1756.32.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237695277.1756.32.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 05:39:34 -0000 On Sat, Mar 21, 2009 at 11:14:37PM -0500, Robert Noland wrote: > On Sat, 2009-03-21 at 20:57 -0700, Steve Kargl wrote: > > > > Neither witness nor invariant appear unhappy. The only think I see > > in /var/log/messages is > > > > Mar 21 19:30:33 REMOVE kernel: error: [drm:pid22190:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 > > I thought that I fixed this... I guess not. It seems I was missing your last commit to one of the i915*.c files. Another csup picked up the file and new kernel seems much more robust. I add DRM_DEBUG to my kernel config file. You can see the output of 'dmesg | grep -i drm' at http:/troutmask.apl.washington.edu/~kargl/drm.txt -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 05:45:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD5D91065675 for ; Sun, 22 Mar 2009 05:45:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 735A78FC0A for ; Sun, 22 Mar 2009 05:45:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-19-214-182.bna.bellsouth.net [68.19.214.182]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2M5hfO9000877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 01:43:41 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20090322053934.GA50002@troutmask.apl.washington.edu> References: <20090322021852.GA48543@troutmask.apl.washington.edu> <1237688696.1756.3.camel@balrog.2hip.net> <20090322022846.GA48644@troutmask.apl.washington.edu> <1237689169.1756.5.camel@balrog.2hip.net> <20090322024755.GA48794@troutmask.apl.washington.edu> <1237691360.1756.13.camel@balrog.2hip.net> <20090322032707.GA49072@troutmask.apl.washington.edu> <1237693139.1756.22.camel@balrog.2hip.net> <20090322035719.GA49263@troutmask.apl.washington.edu> <1237695277.1756.32.camel@balrog.2hip.net> <20090322053934.GA50002@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-D2EHECtWu6+g8Dd+shfh" Organization: FreeBSD Date: Sun, 22 Mar 2009 00:44:41 -0500 Message-Id: <1237700681.1756.34.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm on i965GM is very sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 05:45:03 -0000 --=-D2EHECtWu6+g8Dd+shfh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 22:39 -0700, Steve Kargl wrote: > On Sat, Mar 21, 2009 at 11:14:37PM -0500, Robert Noland wrote: > > On Sat, 2009-03-21 at 20:57 -0700, Steve Kargl wrote: > > >=20 > > > Neither witness nor invariant appear unhappy. The only think I see > > > in /var/log/messages is=20 > > >=20 > > > Mar 21 19:30:33 REMOVE kernel: error: [drm:pid22190:i915_get_vblank_c= ounter] *ERROR* trying to get vblank count for disabled pipe 0 > >=20 > > I thought that I fixed this... I guess not. >=20 > It seems I was missing your last commit to one of the i915*.c=20 > files. Another csup picked up the file and new kernel seems > much more robust. I add DRM_DEBUG to my kernel config file. > You can see the output of 'dmesg | grep -i drm' at Good, because I'm going blind looking for the failure case... > http:/troutmask.apl.washington.edu/~kargl/drm.txt checking it out now... robert. --=20 Robert Noland FreeBSD --=-D2EHECtWu6+g8Dd+shfh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknF0EkACgkQM4TrQ4qfROMd+wCfferJtgAn89tit5gxnGncSCkk baAAniy2/72uKlzFHc3TK83m22WkvBnJ =0kR4 -----END PGP SIGNATURE----- --=-D2EHECtWu6+g8Dd+shfh-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 09:24:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1771065672; Sun, 22 Mar 2009 09:24:19 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 2021D8FC0A; Sun, 22 Mar 2009 09:24:18 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2M9NrEr000905; Sun, 22 Mar 2009 10:23:53 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49C603A8.2010805@fgznet.ch> Date: Sun, 22 Mar 2009 10:23:52 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marius Strobl References: <49C55EBC.1070602@fgznet.ch> <20090321232030.GA70685@alchemy.franken.de> In-Reply-To: <20090321232030.GA70685@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-sparc64@freebsd.org Subject: Re: kdb enter when upgrading from 7.1 to current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 09:24:20 -0000 Marius Strobl wrote: > On Sat, Mar 21, 2009 at 10:40:12PM +0100, Andreas Tobler wrote: >> Hi, >> >> I get this stacktrace when I try to boot from a Kernel as of today (svn: >> 190217). >> >> My setup is a 7.1 install where I'd like to upgrade to current. >> The kernel is built cross, amd64 -> sparc64: >> make -j4 buildkernel TARGET_ARCH=sparc64 KERNCONF=GENERIC >> >> The target machine itself is a u60, details below. >> >> Does anyone have a pointer to help me, would be great! >> >> TIA, >> Andreas >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> jumping to kernel entry at 0xc0080000. >> GDB: no debug ports present >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-CURRENT #2 r190217M: Sat Mar 21 22:27:46 CET 2009 >> >> andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/sparc64/export/devel/ >> fbsd_svn/src/sys/GENERIC >> WARNING: WITNESS option enabled, expect reduced performance. >> real memory = 1610612736 (1536 MB) >> avail memory = 1554710528 (1482 MB) >> cpu0: Sun Microsystems UltraSparc-II Processor (449.99 MHz CPU) >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> ispfw: registered firmware >> kbd0 at kbdmux0 >> nexus0: >> pcib0: mem >> 0x1fe00004000-0x1fe00005fff,0x1fe01000000-0x1fe0 >> 10000ff,0x1fe00000000-0x1fe0000cfff irq 2033,2030,2031,2021,2024,2034 on >> nexus0 >> pcib0: Psycho, impl 0, version 4, IGN 0x1f, bus B, 33MHz >> initializing counter-timer >> Timecounter "pcib0" frequency 1000000 Hz quality 100 >> pcib0: DVMA map: 0xfc000000 to 0xffffffff, streaming buffer >> pcib0: [FILTER] >> pcib0: [FILTER] >> pcib0: [GIANT-LOCKED] >> pcib0: [ITHREAD] >> pcib0: [GIANT-LOCKED] >> pcib0: [ITHREAD] >> pcib0: [FILTER] >> pci0: on pcib0 >> ebus0: mem >> 0x70000000-0x70ffffff,0x71000000-0x717fffff at dev >> ice 1.0 on pci0 >> auxio0: addr >> 0x1400726000-0x1400726003,0x1400728000-0x140072 >> 8003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f0 >> 03 on ebus0 >> ebus0: addr 0x1400724000-0x1400724003 (no driver attached) >> ebus0: addr 0x1400504000-0x1400504002 (no driver attached) >> ebus0: addr 0x1400500000-0x1400500007 (no driver attached) >> scc0: addr >> 0x1400400000-0x140040007f irq 43 >> on ebus0 >> scc0: [FILTER] >> uart0: on scc0 >> uart0: [FILTER] >> uart0: CTS oflow >> uart0: console (9600,n,8,1) >> uart1: on scc0 >> uart1: [FILTER] >> uart1: CTS oflow >> uart2: <16550 or compatible> addr 0x14003083f8-0x14003083ff irq 41 on ebus0 >> uart2: [FILTER] >> uart2: keyboard (1200,n,8,1) >> uart2: keyboard not present >> uart3: <16550 or compatible> addr 0x14003062f8-0x14003062ff irq 42 on ebus0 >> uart3: [FILTER] >> ebus0: addr >> 0x14003043bc-0x14003043cb,0x1400300398-0x1400300399,0x1400700 >> 000-0x140070000f irq 34 (no driver attached) >> ebus0: addr >> 0x14003023f0-0x14003023f7,0x1400706000-0x140070600f,0x1400 >> 720000-0x1400720003 irq 39 (no driver attached) >> eeprom0: addr 0x1400000000-0x1400001fff on ebus0 >> eeprom0: model mk48t59 >> ebus0: addr 0x1000000000-0x10000fffff (no driver attached) >> ebus0: addr >> 0x1400200000-0x14002000ff,0x1400702000-0x140070200f,0x >> 1400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 (no driver >> attached) >> hme0: mem 0x100000-0x107fff at device 1.1 on pci0 >> miibus0: on hme0 >> qsphy0: PHY 1 on miibus0 >> qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> hme0: Ethernet address: 08:00:20:a3:71:69 >> hme0: [ITHREAD] >> sym0: <875> port 0x1000-0x10ff mem 0x108000-0x1080ff,0x10a000-0x10afff >> at device >> 3.0 on pci0 >> sym0: No NVRAM, ID 7, Fast-20, SE, parity checking >> sym0: [ITHREAD] >> sym1: <875> port 0x1400-0x14ff mem 0x10c000-0x10c0ff,0x10e000-0x10efff >> at device >> 3.1 on pci0 >> sym1: No NVRAM, ID 7, Fast-20, SE, parity checking >> sym1: [ITHREAD] >> pcib1: mem >> 0x1fe00002000-0x1fe00003fff,0x1fe01800000-0x1fe0 >> 18000ff,0x1fe00000000-0x1fe0000cfff irq 2032,2030,2031,2021,2024,2034 on >> nexus0 >> pcib1: Psycho, impl 0, version 4, IGN 0x1f, bus A, 66MHz >> pcib1: [FILTER] >> pci1: on pcib1 >> pci1: at device 1.0 (no driver attached) >> creator0: mem >> 0x1fc00000000-0x1fc000003ff,0x1fc00400000-0x1fc005ffff >> f,0x1fc00600000-0x1fc007fffff,0x1fc01000000-0x1fc013fffff,0x1fc01400000-0x1fc017 >> fffff,0x1fc01800000-0x1fc01bfffff,0x1fc01c00000-0x1fc01ffffff,0x1fc02000000-0x1f >> c02ffffff,0x1fc03000000-0x1fc03ffffff,0x1fc04000000-0x1fc043fffff,0x1fc04400000- >> 0x1fc047fffff,0x1fc04800000-0x1fc04bfffff,0x1fc04c00000-0x1fc04ffffff,0x1fc05000 >> 000-0x1fc05ffffff,0x1fc06000000-0x1fc07ffffff,0x1fc09000000-0x1fc097fffff,0x1fc0 >> 9800000-0x1fc09ffffff,0x1fc0a000000-0x1fc0affffff,0x1fc0b000000-0x1fc0b7fffff,0x >> 1fc0b800000-0x1fc0bffffff,0x1fc0c000000-0x1fc0c3fffff,0x1fc0c800000-0x1fc0cfffff >> f,0x1fc0d000000-0x1fc0d7fffff,0x1fc0d800000-0x1fc0dffffff irq 1925 on nexus0 >> creator0: resolution 1152x900 >> syscons0: on nexus0 >> syscons0: Unknown <16 virtual consoles, flags=0x100> >> Timecounter "tick" frequency 449992390 Hz quality 1000 >> Timecounters tick every 1.000 msec >> Waiting 5 seconds for SCSI devices to settle >> (probe6:sym0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >> (probe6:sym0:0:6:0): CAM Status: SCSI Status Error >> (probe6:sym0:0:6:0): SCSI Status: Check Condition >> (probe6:sym0:0:6:0): NOT READY asc:3a,0 >> (probe6:sym0:0:6:0): Medium not present >> (probe6:sym0:0:6:0): Unretryable error >> da1 at sym0 bus 0 target 1 lun 0 >> da1: Fixed Direct Access SCSI-2 device >> da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) >> da1: Command Queueing Enabled >> da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) >> da0 at sym0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 device >> da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) >> da0: Command Queueing Enabled >> da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) >> cd0 at sym0 bus 0 target 6 lun 0 >> cd0: Removable CD-ROM SCSI-2 device >> cd0: 10.000MB/s transfers (10.000MHz, offset 16) >> cd0: Attempt to query device size failed: NOT READY, Medium not present >> WARNING: WITNESS option enabled, expect reduced performance. >> GEOM: da0: adding VTOC8 information. >> GEOM: da1: adding VTOC8 information. >> Trying to mount root from ufs:/dev/da0a >> Loading configuration files. >> kernel dumps on /dev/da0b >> Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: >> memory addres >> s not aligned >> cpuid = 0 >> KDB: enter: panic >> [thread pid 41 tid 100042 ] >> Stopped at kdb_enter+0x80: ta %xcc, 1 >> db> >> db> bt >> Tracing pid 41 tid 100042 td 0xfffff800213dc370 >> panic() at panic+0x20c >> trap() at trap+0x570 >> -- memory address not aligned sfar=0xf2fe2877 sfsr=0x40029 %o7=0xc06654b8 -- >> stack_capture() at stack_capture+0x114 >> stack_save_td() at stack_save_td+0x60 >> sysctl_kern_proc_kstack() at sysctl_kern_proc_kstack+0x36c >> sysctl_root() at sysctl_root+0x1ec >> userland_sysctl() at userland_sysctl+0x174 >> __sysctl() at __sysctl+0x70 >> syscall() at syscall+0x2f0 >> -- syscall (202, FreeBSD ELF64, __sysctl) %o7=0x101628 -- >> userland() at 0x40445788 >> user trace: trap %o7=0x101628 >> pc 0x40445788, sp 0x7fdffffd031 >> pc 0x101ef8, sp 0x7fdffffd971 >> pc 0x102ac4, sp 0x7fdffffdaf1 >> pc 0x100ef0, sp 0x7fdffffe451 >> pc 0x40208094, sp 0x7fdffffe511 >> done > > Hrm, this looks like the problem solved with r184376. Do you > cross-compile with a GCC older than 4.2 maybe? No, I cross compile on current. cc -v: Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] I continue. Thx, Andreas From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 09:49:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC831065670; Sun, 22 Mar 2009 09:49:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id E823D8FC14; Sun, 22 Mar 2009 09:49:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=AjWy0yrHG2sA:10 a=OhxIi9mhZdoA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=g5yxMloZAAAA:8 a=h4Pan5sWhH5qlUVsMuIA:9 a=pZutJQqQepD3IlHIgH8A:7 a=AXdRHRnEketBltvSMecREoruvf0A:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1044545358; Sun, 22 Mar 2009 10:49:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 22 Mar 2009 10:51:38 +0100 User-Agent: KMail/1.9.7 References: <200903211448.28590.pieter@degoeje.nl> <200903220152.55252.pieter@degoeje.nl> <20090322042401.GB50126@citylink.fud.org.nz> In-Reply-To: <20090322042401.GB50126@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903221051.39652.hselasky@c2i.net> Cc: Anonymous , Pieter de Goeje , Andrew Thompson Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 09:49:10 -0000 On Sunday 22 March 2009, Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: > > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > > > > I added a bunch of printf()s to libusb, specifically > > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The > > > > > ugenX.2 files were opened successfully. > > > > > > > > > > At this point it looks like the problem lies somewhere in the > > > > > kernel, which makes it a lot harder for me to debug. > > > > > > > > Can you try to back out r189906? Doing so makes my keyboard to appear > > > > in usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 > > > > -a 3'. > > > > I'll give it a shot. It's rather late so the results will probably have > > to wait until tomorrow. > > > > > What does sysctl hw.usb2.dev.debug=2 show with usbconfig on the latest > > > HEAD code? > > > > Output is quite long so I put it on the web: > > http://unforgiven.student.utwente.nl/~pyotr/dump/usbconfig_debug_2.txt > > I cant see anything obviously wrong with r189906 so I have committed > some more debugging traces. Can you update your sources/kernel and run > usbconfig again with hw.usb2.dev.debug=5 > Just to check if your sources are clean: 1) cp /usr/src/sys/dev/usb/*.h /usr/include/dev/usb 2) Rebuild and install /usr/src/lib/libusb 3) Rebuild and install /usr/src/usr.sbin/usbconfig --HPS From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 09:58:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F26A1065672 for ; Sun, 22 Mar 2009 09:58:02 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 822888FC18 for ; Sun, 22 Mar 2009 09:58:01 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238130883; Sun, 22 Mar 2009 11:58:00 +0200 Message-ID: <49C60BA8.8080404@FreeBSD.org> Date: Sun, 22 Mar 2009 11:58:00 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ulf@Alameda.net References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <200903212149.n2LLnC94037010@lava.sentex.ca> <20090321222116.GG51533@evil.alameda.net> <200903212323.n2LNN3La037490@lava.sentex.ca> <20090322000633.GI51533@evil.alameda.net> In-Reply-To: <20090322000633.GI51533@evil.alameda.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Mike Tancsa Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 09:58:02 -0000 Ulf Zimmermann wrote: > Soren was asking for controller cards which have this chip on board > before he stopped working on the ATA/SATA stuff. Specific because of > ESATA support I believe. So it might just not work with the current > driver. I think it is not an eSATA specific. IMHO it is more probable that either this card just reports itself as regular ATA while is also supports AHCI (and we can try to force AHCI driver attach it), but there still question about PATA channels, or like JMicron chips it provides combination of regular PATA and AHCI SATA via the same PCI device function. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:02:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA06106564A for ; Sun, 22 Mar 2009 10:02:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8327C8FC23 for ; Sun, 22 Mar 2009 10:02:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238131052; Sun, 22 Mar 2009 12:02:26 +0200 Message-ID: <49C60CB2.9030101@FreeBSD.org> Date: Sun, 22 Mar 2009 12:02:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Mike Tancsa References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <200903212149.n2LLnC94037010@lava.sentex.ca> <20090321222116.GG51533@evil.alameda.net> <200903212323.n2LNN3La037490@lava.sentex.ca> In-Reply-To: <200903212323.n2LNN3La037490@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:02:28 -0000 Mike Tancsa wrote: >> > atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 >> > chip=0x612111ab rev=0xb2 hdr=0x00 >> > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> > device = '6121 SATA2 Controller' >> > class = mass storage >> > subclass = ATA >> > cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >> > cap 05[50] = MSI supports 1 message >> > cap 10[e0] = PCI-Express 1 legacy endpoint >> >> I would try to run it as RAID, as per the technical product spec from >> Intel it supports running single non-raid configs. > > No difference, the dmesg looks the same with RAID enabled Not exactly: > atapci0@pci0:6:0:0: class=0x01048f card=0x4f538086 chip=0x612111ab > rev=0xb2 hdr=0x00 > subclass = RAID was: subclass = ATA But it does not change anything. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:06:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAC7106566B for ; Sun, 22 Mar 2009 10:06:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4032C8FC08 for ; Sun, 22 Mar 2009 10:06:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238131195; Sun, 22 Mar 2009 12:06:47 +0200 Message-ID: <49C60DB6.4010406@FreeBSD.org> Date: Sun, 22 Mar 2009 12:06:46 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ulf@Alameda.net References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <20090321220946.GF51533@evil.alameda.net> In-Reply-To: <20090321220946.GF51533@evil.alameda.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:06:49 -0000 Ulf Zimmermann wrote: > On Sat, Mar 21, 2009 at 07:51:43PM +0200, Alexander Motin wrote: >> Mike Tancsa wrote: >>> I turned it on, but still no luck. Attached is the verbose >>> dmesg.boot. I wonder if the extra controller is being mis-identified as >>> being PATA ? As far as I can tell, there are no legacy PATA connectors >>> on the board >>> >>> Yet >>> atapci0: port >>> 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f >>> mem 0xe1100000-0xe11003ff irq 16 at device 0.0 on pci6 >>> >>> implies its a PATA device ? >> It is or PATA controller, or SATA in legacy emulation mode. As I can see >> on web, there are also AHCI capable SATA channels present on this chip: >> http://lists.laptop.org/pipermail/server-devel/2007-July/000070.html >> How it is reported in pciconf? May be there is some way to make AHCI >> attach it? Isn't there any options about it's operation in BIOS? >> >> Don't you have any datasheet for this device? >> >> Also a bit strange for me this messages: >> ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 >> ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata0: [MPSAFE] >> ata0: [ITHREAD] >> ata1 at port 0x170-0x177,0x376 irq 15 on isa0 >> ata1: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata1: [MPSAFE] >> ata1: [ITHREAD] >> channels 0 and 1 are legacy ATA channels. A bit strange to see them when >> AFAIK there is no PATA support on ICH10. If it is not a parts of >> Marvell, then I have no idea what is this. > > Many boards which have an ICH10 use the Marvell (or similar chips) to provide > 1 PATA board for like CD-Rom drives. The DFI board I have does the same. Sure, I just was surprised that external PCI controller reported as legacy. If it is parts of the same controller, then it looks messy. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:14:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C63F106566B; Sun, 22 Mar 2009 10:14:54 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 74C208FC1C; Sun, 22 Mar 2009 10:14:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz8 with SMTP id 8so1293990bwz.43 for ; Sun, 22 Mar 2009 03:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+xXWZSLSXoveNMlEBSaZqJT1LvpbgedDEass2ADpg3c=; b=nj/Conx0IUpAZ+gy0yehhVd1Wxwf3CyEwWMkTvOYuXCrXWPDY+MnOsRFLGvoIBIkLo 6yQBsFGeHH0pLkNALwwIcHylxDpbRlj51qMXCfMk7b2gub/e7AOJ0SUxtdxhLWn526Bj 25Z3adBhrZ9aNmE7+r5jjsa3T9rV6tqsBjS0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XFw7pC3+rZ9pVn7NQScpPpWydQmyMHuD+k2XH4lTbYVdxzc6LlbmPJLIQnDra0sbFB jtbvSF2pTJwtaez/cXyWHrOVzYBwjvz115jHPgm/CTukPOffNKib8oc6sX4tKNeO7jg+ eX+G0UHfHdbZ2wrJwaggU3R6zjX3aMq9x0Qdg= MIME-Version: 1.0 Received: by 10.103.226.10 with SMTP id d10mr2519807mur.105.1237716892199; Sun, 22 Mar 2009 03:14:52 -0700 (PDT) In-Reply-To: <20090321.211654.1102538138.imp@bsdimp.com> References: <49B58CF6.7070104@FreeBSD.org> <20090321.211654.1102538138.imp@bsdimp.com> Date: Sun, 22 Mar 2009 13:14:52 +0300 Message-ID: From: pluknet To: "M. Warner Losh" Content-Type: multipart/mixed; boundary=0016e6dd96a0b12a610465b26bed Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:14:54 -0000 --0016e6dd96a0b12a610465b26bed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/3/22 M. Warner Losh : > In message: > pluknet writes: > : 2009/3/10 Alexander Motin : > : > pluknet wrote: > : >> > : >> Is it ok (and how much harmfull) to see this message? > : >> > : >> driver bug: Unable to set devclass (devname: (null)) > : >> > : >> P.S. > : >> This is introduced in subr_bus.c, v1.216 > : >> - PDEBUG(("Unable to set device > : >> class")); > : >> + printf("driver bug: Unable to set > : >> devclass (devname: %s)\n", > : >> + (child ? > : >> device_get_name(child) : > : >> + "no device")); > : >> > : >> where PDEBUG was moved from BUS_DEBUG to general output. > : > > : > Actually this check was introduced in rev. 1.214, just was not logged. > : > Before this change system could crash soon after this message. Now it should > : > not, but related device probably will not work properly. It is probably not > : > good and should be fixed, but it can be just a low memory symptom. It was > : > noticed for ata driver, but I hope it was fixed. Where have you get it? > : > : This is during the boot, see dmesg (attached). > > Looks like something to do with atakbd or psm. What does your hints > file look like? Pretty standard (see attach). -- wbr, pluknet --0016e6dd96a0b12a610465b26bed Content-Type: application/octet-stream; name="device.hints" Content-Disposition: attachment; filename="device.hints" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fslkpcwt0 IyAkRnJlZUJTRDogc3JjL3N5cy9pMzg2L2NvbmYvR0VORVJJQy5oaW50cyx2IDEuMjEgMjAwOC8w Ny8xMyAwNzoyMDoxNCBlZCBFeHAgJApoaW50LmZkYy4wLmF0PSJpc2EiCmhpbnQuZmRjLjAucG9y dD0iMHgzRjAiCmhpbnQuZmRjLjAuaXJxPSI2IgpoaW50LmZkYy4wLmRycT0iMiIKaGludC5mZC4w LmF0PSJmZGMwIgpoaW50LmZkLjAuZHJpdmU9IjAiCmhpbnQuZmQuMS5hdD0iZmRjMCIKaGludC5m ZC4xLmRyaXZlPSIxIgpoaW50LmF0YS4wLmF0PSJpc2EiCmhpbnQuYXRhLjAucG9ydD0iMHgxRjAi CmhpbnQuYXRhLjAuaXJxPSIxNCIKaGludC5hdGEuMS5hdD0iaXNhIgpoaW50LmF0YS4xLnBvcnQ9 IjB4MTcwIgpoaW50LmF0YS4xLmlycT0iMTUiCmhpbnQuYWR2LjAuYXQ9ImlzYSIKaGludC5hZHYu MC5kaXNhYmxlZD0iMSIKaGludC5idC4wLmF0PSJpc2EiCmhpbnQuYnQuMC5kaXNhYmxlZD0iMSIK aGludC5haGEuMC5hdD0iaXNhIgpoaW50LmFoYS4wLmRpc2FibGVkPSIxIgpoaW50LmFpYy4wLmF0 PSJpc2EiCmhpbnQuYWljLjAuZGlzYWJsZWQ9IjEiCmhpbnQuYXRrYmRjLjAuYXQ9ImlzYSIKaGlu dC5hdGtiZGMuMC5wb3J0PSIweDA2MCIKaGludC5hdGtiZC4wLmF0PSJhdGtiZGMiCmhpbnQuYXRr YmQuMC5pcnE9IjEiCmhpbnQucHNtLjAuYXQ9ImF0a2JkYyIKaGludC5wc20uMC5pcnE9IjEyIgpo aW50LnZnYS4wLmF0PSJpc2EiCmhpbnQuc2MuMC5hdD0iaXNhIgpoaW50LnNjLjAuZmxhZ3M9IjB4 MTAwIgpoaW50LmFwbS4wLmRpc2FibGVkPSIxIgpoaW50LmFwbS4wLmZsYWdzPSIweDIwIgpoaW50 LnVhcnQuMC5hdD0iaXNhIgpoaW50LnVhcnQuMC5wb3J0PSIweDNGOCIKaGludC51YXJ0LjAuZmxh Z3M9IjB4MTAiCmhpbnQudWFydC4wLmlycT0iNCIKaGludC51YXJ0LjEuYXQ9ImlzYSIKaGludC51 YXJ0LjEucG9ydD0iMHgyRjgiCmhpbnQudWFydC4xLmlycT0iMyIKaGludC51YXJ0LjIuYXQ9Imlz YSIKaGludC51YXJ0LjIuZGlzYWJsZWQ9IjEiCmhpbnQudWFydC4yLnBvcnQ9IjB4M0U4IgpoaW50 LnVhcnQuMi5pcnE9IjUiCmhpbnQudWFydC4zLmF0PSJpc2EiCmhpbnQudWFydC4zLmRpc2FibGVk PSIxIgpoaW50LnVhcnQuMy5wb3J0PSIweDJFOCIKaGludC51YXJ0LjMuaXJxPSI5IgpoaW50LnBw Yy4wLmF0PSJpc2EiCmhpbnQucHBjLjAuaXJxPSI3IgpoaW50LmVkLjAuYXQ9ImlzYSIKaGludC5l ZC4wLmRpc2FibGVkPSIxIgpoaW50LmVkLjAucG9ydD0iMHgyODAiCmhpbnQuZWQuMC5pcnE9IjEw IgpoaW50LmVkLjAubWFkZHI9IjB4ZDgwMDAiCmhpbnQuY3MuMC5hdD0iaXNhIgpoaW50LmNzLjAu ZGlzYWJsZWQ9IjEiCmhpbnQuY3MuMC5wb3J0PSIweDMwMCIKaGludC5zbi4wLmF0PSJpc2EiCmhp bnQuc24uMC5kaXNhYmxlZD0iMSIKaGludC5zbi4wLnBvcnQ9IjB4MzAwIgpoaW50LnNuLjAuaXJx PSIxMCIKaGludC5pZS4wLmF0PSJpc2EiCmhpbnQuaWUuMC5kaXNhYmxlZD0iMSIKaGludC5pZS4w LnBvcnQ9IjB4MzAwIgpoaW50LmllLjAuaXJxPSIxMCIKaGludC5pZS4wLm1hZGRyPSIweGQwMDAw IgpoaW50LmZlLjAuYXQ9ImlzYSIKaGludC5mZS4wLmRpc2FibGVkPSIxIgpoaW50LmZlLjAucG9y dD0iMHgzMDAiCmhpbnQubGUuMC5hdD0iaXNhIgpoaW50LmxlLjAuZGlzYWJsZWQ9IjEiCmhpbnQu bGUuMC5wb3J0PSIweDI4MCIKaGludC5sZS4wLmlycT0iMTAiCmhpbnQubGUuMC5kcnE9IjAiCmhp bnQuYXRydGMuMC5hdD0iaXNhIgpoaW50LmF0cnRjLjAucG9ydD0iMHg3MCIKaGludC5hdHJ0Yy4w LmlycT0iOCIK --0016e6dd96a0b12a610465b26bed-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:18:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B17106564A for ; Sun, 22 Mar 2009 10:18:26 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C4B548FC14 for ; Sun, 22 Mar 2009 10:18:25 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238131680; Sun, 22 Mar 2009 12:18:24 +0200 Message-ID: <49C61070.9070201@FreeBSD.org> Date: Sun, 22 Mar 2009 12:18:24 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Mike Tancsa References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <200903212149.n2LLnC94037010@lava.sentex.ca> In-Reply-To: <200903212149.n2LLnC94037010@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:18:26 -0000 Mike Tancsa wrote: >> Don't you have any datasheet for this device? > > No, its just a generic Intel branded board (Intel DX58SO) I mean this Marvell chip. >> Also a bit strange for me this messages: >> ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 >> ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata0: [MPSAFE] >> ata0: [ITHREAD] >> ata1 at port 0x170-0x177,0x376 irq 15 on isa0 >> ata1: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata1: [MPSAFE] >> ata1: [ITHREAD] >> channels 0 and 1 are legacy ATA channels. A bit strange to see them >> when AFAIK there is no PATA support on ICH10. If it is not a parts of >> Marvell, then I have no idea what is this. > > Interesting, pciconf shows it as sata > > 0[i7]# pciconf -lvc > atapci1@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = mass storage > subclass = SATA > cap 05[80] = MSI supports 16 messages > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 12[a8] = SATA Index-Data Pair ICH10 internal controller reported as AHCI capable SATA. > atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab > rev=0xb2 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '6121 SATA2 Controller' > class = mass storage > subclass = ATA > cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 > cap 05[50] = MSI supports 1 message > cap 10[e0] = PCI-Express 1 legacy endpoint But Marvel reported as regular PATA -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:33:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67FBA106567C; Sun, 22 Mar 2009 10:33:44 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDFA8FC1E; Sun, 22 Mar 2009 10:33:43 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz8 with SMTP id 8so1297144bwz.43 for ; Sun, 22 Mar 2009 03:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Dpbw37qyHzxGoxN+T/I4zby7OGINs2n6CN1Tgh/WoA4=; b=GvQM9Dx+421RUrvZ9xhu5GH0Ugq/yAuEA5pDl6rYDa5CTVk3q3PMc0+3Vu68k8VNXO fr17EfcLYmbABqmAtAEnla84PUzC23J5ud6GERoIVoQrFY/A0krXOCPqCTNsMJ/e7abx RxDVFj7RdPbKR7RQ7UD4OIBwR8sZ1fq7rIAk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aQ3qr960dtWMjZw2arx6EXF7LDO5YF0ORPJSK67RBC0s7cS65J9/Wf+qTeZJ9Jmw9J /kKSN+lbCJm7OLaKXVqWEb8qUzzbjJnyAbfVPR6mFbw8zMuIQvMQsZ9OYAIYf2rfCe7j 0cHJ1u9+KWe6/hhELvMDg4HtCl9PoRwv1QrwI= MIME-Version: 1.0 Received: by 10.103.11.5 with SMTP id o5mr2517748mui.132.1237718022360; Sun, 22 Mar 2009 03:33:42 -0700 (PDT) In-Reply-To: <20090321.211942.-1540398823.imp@bsdimp.com> References: <49B594B5.2060706@FreeBSD.org> <20090321.211942.-1540398823.imp@bsdimp.com> Date: Sun, 22 Mar 2009 13:33:42 +0300 Message-ID: From: pluknet To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:33:45 -0000 2009/3/22 M. Warner Losh : > In message: > pluknet writes: > : 2009/3/10 pluknet : > : > 2009/3/10 Alexander Motin : > : >> pluknet wrote: > : >>> > : >>> 2009/3/10 Alexander Motin : > : >>>> > : >>>> pluknet wrote: > : >>>>> > : >>>>> Is it ok (and how much harmfull) to see this message? > : >>>>> > : >>>>> driver bug: Unable to set devclass (devname: (null)) > : >>>>> > : >>>>> P.S. > : >>>>> This is introduced in subr_bus.c, v1.216 > : >>>>> - PDEBUG(("Unable to set device > : >>>>> class")); > : >>>>> + printf("driver bug: Unable to > : >>>>> set > : >>>>> devclass (devname: %s)\n", > : >>>>> + (child ? > : >>>>> device_get_name(child) : > : >>>>> + "no device")); > : >>>>> > : >>>>> where PDEBUG was moved from BUS_DEBUG to general output. > : >>>> > : >>>> Actually this check was introduced in rev. 1.214, just was not logged. > : >>>> Before this change system could crash soon after this message. Now it > : >>>> should > : >>>> not, but related device probably will not work properly. It is probably > : >>>> not > : >>>> good and should be fixed, but it can be just a low memory symptom. It was > : >>>> noticed for ata driver, but I hope it was fixed. Where have you get it? > : >>> > : >>> This is during the boot, see dmesg (attached). > : >> > : >> It does not gives much info. Can you try to add dl->driver->name, > : >> device_get_unit(child) and device_set_devclass() result printing there? > : >> > : > > : > That gives: > : > atkbd0: [GIANT-LOCKED] > : > atkbd0: [ITHREAD] > : > driver bug: Unable to set devclass (devname: (null)) > : > dl->driver->name: atkbdc > : > device_get_unit(child): -1 > : > device_set_devclass(): 17 > : > > : > : Well, yes. That confirms with numerous devclass_alloc_unit() EEXIST > : hidden messages; > : > : atkbdc0: port 0x60,0x64 irq 1 on acpi0 > : atkbd0: irq 1 on atkbdc0 > : atkbd: the current kbd controller command byte 0065 > : atkbd: keyboard ID 0x83ab (2) > : kbd0 at atkbd0 > : kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > : ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 > : atkbd0: [GIANT-LOCKED] > : atkbd0: [ITHREAD] > : psm0: unable to allocate IRQ > : atkbdc: atkbdc-1 already exists; skipping it > > Can you set a breakpoint on this line and give a traceback? > > : driver bug: Unable to set devclass (devname: (null)) > : dl->driver->name: atkbdc > : device_get_unit(child): -1 > : atkbdc: atkbdc-1 already exists; skipping it > > Ditto > > : device_set_devclass(): 17 > : psmcpnp0: port 0x60,0x64 irq 12 on acpi0 > : psm0: current command byte:0065 > : psm0: irq 12 on atkbdc0 > : ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 55 > : psm0: [GIANT-LOCKED] > : psm0: [ITHREAD] > : psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons > : psm0: config:00000000, flags:00000008, packet size:4 > : psm0: syncmask:08, syncbits:00 > : ppc0: using extended I/O port range > : ppc0: using extended I/O port range > : pnp_identify: Trying Read_Port at 203 > : pnp_identify: Trying Read_Port at 243 > : pnp_identify: Trying Read_Port at 283 > : pnp_identify: Trying Read_Port at 2c3 > : pnp_identify: Trying Read_Port at 303 > : pnp_identify: Trying Read_Port at 343 > : pnp_identify: Trying Read_Port at 383 > : pnp_identify: Trying Read_Port at 3c3 > : PNP Identify complete > : isa_probe_children: disabling PnP devices > : pmtimer0 on isa0 > : ata: ata0 already exists; skipping it > : ata: ata1 already exists; skipping it > : atkbdc: atkbdc0 already exists; skipping it > : sc: sc0 already exists; skipping it > : vga: vga0 already exists; skipping it > > No need for these... > > Warner > While rebuilding the kernel from newest sources, I have a dmesg from a bit older kernel (where atkbdc-1 was detected only once): atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ atkbdc: atkbdc-1 already exists; skipping it driver bug: Unable to set devclass (devname: (null)) KDB: stack backtrace: db_trace_self_wrapper(c08240e7,c0c20ba4,c05ecfd1,c08239a5,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08239a5,0,c0824f45,c3d7253c,c3d7253c,...) at kdb_backtrace+0x29 device_probe_child(c3de4400,c3d72500,c0823799,981,c3d72500,...) at device_probe_child+0xf1 device_probe(c3d72500,4,c0823799,9a2,c3d72500,...) at device_probe+0x93 device_probe_and_attach(c3d72500,1,c0c20c64,c048a0a6,c3de4400,...) at device_probe_and_attach+0x36 bus_generic_attach(c3de4400,c3de4400,c086aca8,c048a640,c3de4400,...) at bus_generic_attach+0x19 acpi_attach(c3de4400,c3d95054,c086ade8,c0823810,80000000,...) at acpi_attach+0xba6 device_attach(c3de4400,4,c0823799,9a2) at device_attach+0x36f device_probe_and_attach(c3de4400,c3de4980,c0c20cf0,c0796a2e,c3de4980,...) at device_probe_and_attach+0x4e bus_generic_attach(c3de4980,a,c07fd14d,0) at bus_generic_attach+0x19 nexus_acpi_attach(c3de4980,c3da0054,c086ade8,c0823810,80000000,...) at nexus_acpi_attach+0x7e device_attach(c3de4980,4,c0823799,9a2) at device_attach+0x36f device_probe_and_attach(c3de4980,c3d0cb6c,c0c20d6c,c079b9bc,c07fc469,...) at device_probe_and_attach+0x4e root_bus_configure(c07fc469,c0c20d88,c05874f6,0,c1ec00,...) at root_bus_configure+0x1b configure(0,c1ec00,c1ec00,c1e000,c25000,...) at configure+0xc mi_startup() at mi_startup+0x96 begin() at begin+0x2c -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:50:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05426106564A; Sun, 22 Mar 2009 10:50:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 358358FC18; Sun, 22 Mar 2009 10:50:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so524738mue.3 for ; Sun, 22 Mar 2009 03:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vwqJ0D5UNInPxzxwhe0w+UCUjtVtLhYAMcD4dUKz/k0=; b=EkCHyL3E9xSC62Ov18NiI8EUcWspXMoj/FoGfKPgwIL52L1xiy99IjdNAWUqZ5Isvk NmhNhR5G0SudDo8/8vpe9MdDmbdOzl7wFGbDLPNW7frJVpOHdBnjjoGfekP2VvILjUKU rEftj3wjGBxSSSfK3DJkWrC6RK8DL5BY5IjQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FGnLB/uHGhRiAFjebC7OgiBRBjIYmA92MDqQv7J+1bhSRVFojSuOQ4dYpRjPxloerJ swckx4iT1wzLMRNs5zkzfIMByNBU6X1kaBI0nzAOEN3spS5eCSSNtjbDCAHi+Y5Jjl+j +F5DrRX+kGJddFzp4Sdgb0UGc5v36Usz5muc0= MIME-Version: 1.0 Received: by 10.103.169.18 with SMTP id w18mr2171788muo.73.1237719038064; Sun, 22 Mar 2009 03:50:38 -0700 (PDT) In-Reply-To: References: <49B594B5.2060706@FreeBSD.org> <20090321.211942.-1540398823.imp@bsdimp.com> Date: Sun, 22 Mar 2009 13:50:38 +0300 Message-ID: From: pluknet To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to set devclass (devname: (null) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:50:40 -0000 2009/3/22 pluknet : > 2009/3/22 M. Warner Losh : >> In message: >> pluknet writes: >> : 2009/3/10 pluknet : >> : > 2009/3/10 Alexander Motin : >> : >> pluknet wrote: >> : >>> >> : >>> 2009/3/10 Alexander Motin : >> : >>>> >> : >>>> pluknet wrote: >> : >>>>> >> : >>>>> Is it ok (and how much harmfull) to see this message? >> : >>>>> >> : >>>>> driver bug: Unable to set devclass (devname: (null)) >> : >>>>> >> : >>>>> P.S. >> : >>>>> This is introduced in subr_bus.c, v1.216 >> : >>>>> - PDEBUG(("Unable to set device >> : >>>>> class")); >> : >>>>> + printf("driver bug: Unable to >> : >>>>> set >> : >>>>> devclass (devname: %s)\n", >> : >>>>> + (child ? >> : >>>>> device_get_name(child) : >> : >>>>> + "no device")); >> : >>>>> >> : >>>>> where PDEBUG was moved from BUS_DEBUG to general output. >> : >>>> >> : >>>> Actually this check was introduced in rev. 1.214, just was not logged. >> : >>>> Before this change system could crash soon after this message. Now it >> : >>>> should >> : >>>> not, but related device probably will not work properly. It is probably >> : >>>> not >> : >>>> good and should be fixed, but it can be just a low memory symptom. It was >> : >>>> noticed for ata driver, but I hope it was fixed. Where have you get it? >> : >>> >> : >>> This is during the boot, see dmesg (attached). >> : >> >> : >> It does not gives much info. Can you try to add dl->driver->name, >> : >> device_get_unit(child) and device_set_devclass() result printing there? >> : >> >> : > >> : > That gives: >> : > atkbd0: [GIANT-LOCKED] >> : > atkbd0: [ITHREAD] >> : > driver bug: Unable to set devclass (devname: (null)) >> : > dl->driver->name: atkbdc >> : > device_get_unit(child): -1 >> : > device_set_devclass(): 17 >> : > >> : >> : Well, yes. That confirms with numerous devclass_alloc_unit() EEXIST >> : hidden messages; >> : >> : atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> : atkbd0: irq 1 on atkbdc0 >> : atkbd: the current kbd controller command byte 0065 >> : atkbd: keyboard ID 0x83ab (2) >> : kbd0 at atkbd0 >> : kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 >> : ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 >> : atkbd0: [GIANT-LOCKED] >> : atkbd0: [ITHREAD] >> : psm0: unable to allocate IRQ >> : atkbdc: atkbdc-1 already exists; skipping it >> >> Can you set a breakpoint on this line and give a traceback? >> >> : driver bug: Unable to set devclass (devname: (null)) >> : dl->driver->name: atkbdc >> : device_get_unit(child): -1 >> : atkbdc: atkbdc-1 already exists; skipping it >> >> Ditto >> >> : device_set_devclass(): 17 >> : psmcpnp0: port 0x60,0x64 irq 12 on acpi0 >> : psm0: current command byte:0065 >> : psm0: irq 12 on atkbdc0 >> : ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 55 >> : psm0: [GIANT-LOCKED] >> : psm0: [ITHREAD] >> : psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons >> : psm0: config:00000000, flags:00000008, packet size:4 >> : psm0: syncmask:08, syncbits:00 >> : ppc0: using extended I/O port range >> : ppc0: using extended I/O port range >> : pnp_identify: Trying Read_Port at 203 >> : pnp_identify: Trying Read_Port at 243 >> : pnp_identify: Trying Read_Port at 283 >> : pnp_identify: Trying Read_Port at 2c3 >> : pnp_identify: Trying Read_Port at 303 >> : pnp_identify: Trying Read_Port at 343 >> : pnp_identify: Trying Read_Port at 383 >> : pnp_identify: Trying Read_Port at 3c3 >> : PNP Identify complete >> : isa_probe_children: disabling PnP devices >> : pmtimer0 on isa0 >> : ata: ata0 already exists; skipping it >> : ata: ata1 already exists; skipping it >> : atkbdc: atkbdc0 already exists; skipping it >> : sc: sc0 already exists; skipping it >> : vga: vga0 already exists; skipping it >> >> No need for these... >> >> Warner >> > > While rebuilding the kernel from newest sources, I have a dmesg from a > bit older kernel > (where atkbdc-1 was detected only once): > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x83ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > atkbdc: atkbdc-1 already exists; skipping it > driver bug: Unable to set devclass (devname: (null)) > KDB: stack backtrace: > db_trace_self_wrapper(c08240e7,c0c20ba4,c05ecfd1,c08239a5,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08239a5,0,c0824f45,c3d7253c,c3d7253c,...) at kdb_backtrace+0x29 > device_probe_child(c3de4400,c3d72500,c0823799,981,c3d72500,...) at > device_probe_child+0xf1 > device_probe(c3d72500,4,c0823799,9a2,c3d72500,...) at device_probe+0x93 > device_probe_and_attach(c3d72500,1,c0c20c64,c048a0a6,c3de4400,...) at > device_probe_and_attach+0x36 > bus_generic_attach(c3de4400,c3de4400,c086aca8,c048a640,c3de4400,...) > at bus_generic_attach+0x19 > acpi_attach(c3de4400,c3d95054,c086ade8,c0823810,80000000,...) at > acpi_attach+0xba6 > device_attach(c3de4400,4,c0823799,9a2) at device_attach+0x36f > device_probe_and_attach(c3de4400,c3de4980,c0c20cf0,c0796a2e,c3de4980,...) > at device_probe_and_attach+0x4e > bus_generic_attach(c3de4980,a,c07fd14d,0) at bus_generic_attach+0x19 > nexus_acpi_attach(c3de4980,c3da0054,c086ade8,c0823810,80000000,...) at > nexus_acpi_attach+0x7e > device_attach(c3de4980,4,c0823799,9a2) at device_attach+0x36f > device_probe_and_attach(c3de4980,c3d0cb6c,c0c20d6c,c079b9bc,c07fc469,...) > at device_probe_and_attach+0x4e > root_bus_configure(c07fc469,c0c20d88,c05874f6,0,c1ec00,...) at > root_bus_configure+0x1b > configure(0,c1ec00,c1ec00,c1e000,c25000,...) at configure+0xc > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > Hm.. the same on new kernel; only one atkbdc-1 event: atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ atkbdc: atkbdc-1 already exists; skipping it KDB: stack backtrace: db_trace_self_wrapper(c082979d,c0c20b58,c05ea65b,c0828da6,c3d118b0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0828da6,c3d118b0,c3d118b0,ffffffff,ffffffff,...) at kdb_backtrace+0x29 devclass_add_device(101,c3d31460,6,c0c20ba4,c05ed817,...) at devclass_add_device+0x12b device_set_devclass(c3d73500,c084668e,c082a661,c3d7353c,c3d7353c,...) at device_set_devclass+0x6f device_probe_child(c3de5400,c3d73500,c0828e4f,97f,c3d73500,...) at device_probe_child+0xc7 device_probe(c3d73500,4,c0828e4f,9a0,c3d73500,...) at device_probe+0x93 device_probe_and_attach(c3d73500,1,c0c20c64,c048a556,c3de5400,...) at device_probe_and_attach+0x36 bus_generic_attach(c3de5400,c3de5400,c08708a8,c048aaf0,c3de5400,...) at bus_generic_attach+0x19 acpi_attach(c3de5400,c3d98054,c08709e8,c0828ec6,80000000,...) at acpi_attach+0xba6 device_attach(c3de5400,4,c0828e4f,9a0) at device_attach+0x36f device_probe_and_attach(c3de5400,c3de5980,c0c20cf0,c079bdee,c3de5980,...) at device_probe_and_attach+0x4e bus_generic_attach(c3de5980,a,c080276d,0) at bus_generic_attach+0x19 nexus_acpi_attach(c3de5980,c3da1054,c08709e8,c0828ec6,80000000,...) at nexus_acpi_attach+0x7e device_attach(c3de5980,4,c0828e4f,9a0) at device_attach+0x36f device_probe_and_attach(c3de5980,c3d0db78,c0c20d6c,c07a0d7c,c086edc8,...) at device_probe_and_attach+0x4e root_bus_configure(c086edc8,c0c20d88,c0587b46,0,c1ec00,...) at root_bus_configure+0x1b configure(0,c1ec00,c1ec00,c1e000,c25000,...) at configure+0xc mi_startup() at mi_startup+0x96 begin() at begin+0x2c driver bug: Unable to set devclass (devname: (null)) -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 10:56:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210601065680 for ; Sun, 22 Mar 2009 10:56:56 +0000 (UTC) (envelope-from DeBardeleben@aol.com) Received: from imo-m13.mail.aol.com (imo-m13.mx.aol.com [64.12.143.101]) by mx1.freebsd.org (Postfix) with ESMTP id E2D458FC08 for ; Sun, 22 Mar 2009 10:56:55 +0000 (UTC) (envelope-from DeBardeleben@aol.com) Received: from DeBardeleben@aol.com by imo-m13.mx.aol.com (mail_out_v39.1.) id v.d19.3af15290 (37565); Sun, 22 Mar 2009 06:46:36 -0400 (EDT) Received: from smtprly-ma02.mx.aol.com (smtprly-ma02.mx.aol.com [64.12.207.141]) by cia-mb04.mx.aol.com (v123.3) with ESMTP id MAILCIAMB042-5c4f49c61706371; Sun, 22 Mar 2009 06:46:38 -0400 Received: from WEBMAIL-MY24 (webmail-my24.sim.aol.com [64.12.109.82]) by smtprly-ma02.mx.aol.com (v123.3) with ESMTP id MAILSMTPRLYMA025-5c4f49c61706371; Sun, 22 Mar 2009 06:46:30 -0400 To: freebsd-current@freebsd.org Date: Sun, 22 Mar 2009 06:46:30 -0400 X-AOL-IP: 67.100.119.58 X-MB-Message-Source: WebUI Received: from 67.100.119.58 by WEBMAIL-MY24.sysops.aol.com (64.12.109.82) with HTTP (WebMailUI); Sun, 22 Mar 2009 06:46:30 -0400 MIME-Version: 1.0 From: debardeleben@aol.com X-MB-Message-Type: User Content-Type: multipart/mixed; boundary="--------MB_8CB78F2983E7D3F_1574_7BDB_WEBMAIL-MY24.sysops.aol.com" X-Mailer: AOL Webmail 41921-STANDARD Message-Id: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> X-Spam-Flag: NO X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd@cfdhome.com Subject: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 10:56:56 -0000 ----------MB_8CB78F2983E7D3F_1574_7BDB_WEBMAIL-MY24.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" I finally got fed up enough with not being able to print with -CURRENT, and found a fix that make ulpt work for me with my epson stylus photo 835. I am using cups, and I have always needed to use the non-reset device, even with the old USB stack. Hopefully a committer can pick this up and include an appropriate version of this fix to the source tree. In the mean time, if you are having trouble with a usb printer with -CURRENT, you may want to try this patch. I am attaching a patch file (referenced at /usr/src/sys/dev/usb/serial from my system. The change is to initialize sc_fflags to 0 when attaching the device. This is allowing open to stop returning EBUSY. Now on to finding out why using my newly accessible firewire disks resulted in filesystem corruption on all of my filesystems. I suspect some missing lock. Its very annoying, and I lost a lot of important files. (I will be doing a full backup of all of my disks before connecting my firewire disks back up). -Charles ----------MB_8CB78F2983E7D3F_1574_7BDB_WEBMAIL-MY24.sysops.aol.com Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-ulpt.c" Content-Type: application/octet-stream; name="patch-ulpt.c" LS0tIHVscHQuYy5vcmlnCShyZXZpc2lvbiAxOTAyNTQpCisrKyB1bHB0LmMJKHdvcmtpbmcg Y29weSkKQEAgLTQ5OSw2ICs0OTksNyBAQCB1bHB0X2F0dGFjaChkZXZpY2VfdCBkZXYpCiAK IAlzYy0+c2NfZGV2ID0gZGV2OwogCXNjLT5zY191ZGV2ID0gdWFhLT5kZXZpY2U7CisJc2Mt PnNjX2ZmbGFncyA9IDA7CiAKIAlkZXZpY2Vfc2V0X3VzYjJfZGVzYyhkZXYpOwog ----------MB_8CB78F2983E7D3F_1574_7BDB_WEBMAIL-MY24.sysops.aol.com-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 11:10:56 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C57F8106566B; Sun, 22 Mar 2009 11:10:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 76A2A8FC0A; Sun, 22 Mar 2009 11:10:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n2MBAX6O041797; Sun, 22 Mar 2009 07:10:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200903221110.n2MBAX6O041797@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Mar 2009 07:10:50 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <49C60DB6.4010406@FreeBSD.org> References: <1237594983.00089764.1237583401@10.7.7.3> <49C4B848.1010906@mavhome.dp.ua> <200903211449.n2LEmxwC034905@lava.sentex.ca> <49C5292F.1050802@FreeBSD.org> <20090321220946.GF51533@evil.alameda.net> <49C60DB6.4010406@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Intel X58 eSATA port ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 11:10:57 -0000 At 06:06 AM 3/22/2009, Alexander Motin wrote: >>Many boards which have an ICH10 use the Marvell (or similar chips) to provide >>1 PATA board for like CD-Rom drives. The DFI board I have does the same. > >Sure, I just was surprised that external PCI controller reported as >legacy. If it is parts of the same controller, then it looks messy. Hi, Just to clarify, this is built into the motherboard. ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 11:26:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1F2106566C for ; Sun, 22 Mar 2009 11:26:25 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id D01678FC14 for ; Sun, 22 Mar 2009 11:26:24 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by bwz8 with SMTP id 8so1306404bwz.43 for ; Sun, 22 Mar 2009 04:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.116.19 with SMTP id k19mr2065145bkq.70.1237721182996; Sun, 22 Mar 2009 04:26:22 -0700 (PDT) Date: Sun, 22 Mar 2009 12:26:22 +0100 Message-ID: From: TooMany Secrets To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Messages about ffs. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 11:26:26 -0000 Hi! Excuse me my bad english, but I have installed a FreeBSD-CURRENT (8) in my laptop, because I would to help to debug. My laptop is a Dell Vostro 1400. Because is my first time running a CURRENT system with witness and debug options enabled, I don't know if the tty/log obtained messages are normal or not: The uname: $ FreeBSD leonsio.toomany.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Mar 19 20:38:56 CET 2009 root@leonsio.toomany.net:/usr/obj/usr/src/sys/LEONSIO i386 The system is compiled with witness and debug symbols. Every time I put in off the laptop, I obtain this message: Mar 18 19:46:25 leonsio login: ROOT LOGIN (root) ON ttyv0 Mar 18 19:53:53 leonsio power_profile: changed to 'performance' Mar 18 19:54:17 leonsio kernel: lock order reversal: Mar 18 19:54:17 leonsio kernel: 1st 0xd95c9020 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 Mar 18 19:54:17 leonsio kernel: 2nd 0xc6230400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 Mar 18 19:54:17 leonsio kernel: KDB: stack backtrace: Mar 18 19:54:17 leonsio kernel: db_trace_self_wrapper(c0c2021d,e813d778,c08954d5,4,c0c1b831,...) at db_trace_self_wrapper+0x26 Mar 18 19:54:17 leonsio kernel: kdb_backtrace(4,c0c1b831,c5523810,c5526a70,e813d7d4,...) at kdb_backtrace+0x29 Mar 18 19:54:17 leonsio kernel: _witness_debugger(c0c22f42,c6230400,c0c41f16,c5526a70,c0c41baf,...) at _witness_debugger+0x25 Mar 18 19:54:17 leonsio kernel: witness_checkorder(c6230400,9,c0c41baf,113,0,...) at witness_checkorder+0x839 Mar 18 19:54:17 leonsio kernel: _sx_xlock(c6230400,0,c0c41baf,113,c65eb000,...) at _sx_xlock+0x85 Mar 18 19:54:17 leonsio kernel: ufsdirhash_acquire(d95c8fc0,dc289db4,4c,dc289dc4,e813d8a4,...) at ufsdirhash_acquire+0x35 Mar 18 19:54:17 leonsio kernel: ufsdirhash_add(c65eb000,e813d8ec,2dc4,e813d890,e813d894,...) at ufsdirhash_add+0x13 Mar 18 19:54:17 leonsio kernel: ufs_direnter(c65f2c90,c657ed9c,e813d8ec,e813dbd4,0,...) at ufs_direnter+0x729 Mar 18 19:54:17 leonsio kernel: ufs_makeinode(e813dbd4,e813dacc,e813dacc,e813da34,c0b67265,...) at ufs_makeinode+0x519 Mar 18 19:54:17 leonsio kernel: ufs_create(e813dacc,e813dacc,0,e813dacc,e813dba8,...) at ufs_create+0x30 Mar 18 19:54:17 leonsio kernel: VOP_CREATE_APV(c0d241a0,e813dacc,2,c0c15f88,3,...) at VOP_CREATE_APV+0xa5 Mar 18 19:54:17 leonsio kernel: vn_open_cred(e813dba8,e813dc5c,180,c5cf6800,c5cfc038,...) at vn_open_cred+0x1d0 Mar 18 19:54:17 leonsio kernel: vn_open(e813dba8,e813dc5c,180,c5cfc038,4,...) at vn_open+0x33 Mar 18 19:54:17 leonsio kernel: kern_openat(c60ae000,ffffff9c,28528f80,0,602,...) at kern_openat+0x110 Mar 18 19:54:17 leonsio kernel: kern_open(c60ae000,28528f80,0,601,180,...) at kern_open+0x35 Mar 18 19:54:17 leonsio kernel: open(c60ae000,e813dcf8,c,c0c202d9,c0d01838,...) at open+0x30 Mar 18 19:54:17 leonsio kernel: syscall(e813dd38) at syscall+0x2a3 Mar 18 19:54:17 leonsio kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 18 19:54:17 leonsio kernel: --- syscall (5, FreeBSD ELF32, open), eip = 0x282fb333, esp = 0xbf4f9cdc, ebp = 0xbf4f9d08 --- Other times, when, like now, install a port like xorg, appears this message: Mar 22 10:49:04 leonsio kernel: lock order reversal: Mar 22 10:49:04 leonsio kernel: 1st 0xd9542500 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2549 Mar 22 10:49:04 leonsio kernel: 2nd 0xc5b7c800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 Mar 22 10:49:04 leonsio kernel: KDB: stack backtrace: Mar 22 10:49:04 leonsio kernel: db_trace_self_wrapper(c0bf0c2d,e813d780,c0870a7f,c08633e6,c0bf39d1,...) at db_trace_self_wrapp er+0x26 Mar 22 10:49:04 leonsio kernel: kdb_backtrace(c08633e6,c0bf39d1,c5524a18,c5527ce0,e813d7dc,...) at kdb_backtrac Mar 22 10:49:04 leonsio kernel: e+0x29 Mar 22 10:49:04 leonsio kernel: _witness_debugger(c0bf39d1,c5b7c800,c0c12faa,c5527ce0,c0c12c43,...) at _witness_debugger+0x1e Mar 22 10:49:04 leonsio kernel: witness_checkorder(c5b7c800,9,c0c12c43,113,0,...) at witness_checkorder+0x818 Mar 22 10:49:04 leonsio kernel: _sx_xlock(c5b7c800,0,c0c12c43,113,c609264c,...) at _sx_xlock+0x7f Mar 22 10:49:04 leonsio kernel: ufsdirhash_acquire(d95424a0,da8dfd7c,84,da8dfd88,e813d8ac,...) at ufsdirhash_acquire+0x31 Mar 22 10:49:04 leonsio kernel: ufsdirhash_add(c609264c,e813d8f4,d88,e813d898,e813d89c,...) at ufsdirhash_add+0x13 Mar 22 10:49:04 leonsio kernel: ufs_direnter(c6094430,c61ab860,e813d8f4,e813dbd8,0,...) at ufs_direnter+0x70b Mar 22 10:49:04 leonsio kernel: ufs_makeinode(e813dbd8) at ufs_makeinode+0x4f2 Mar 22 10:49:04 leonsio kernel: ufs_create(e813dad0,e813dad0,0,e813dad0,e813dbac,...) at ufs_create+0x2c Mar 22 10:49:04 leonsio kernel: VOP_CREATE_APV(c0cf3080,e813dad0,2,c0be6967,3,...) at VOP_CREATE_APV+0xa2 Mar 22 10:49:04 leonsio kernel: vn_open_cred(e813dbac,e813dc60,180,c5f92500,c5eea0a8,...) at vn_open_cred+0x1d0 Mar 22 10:49:04 leonsio kernel: vn_open(e813dbac,e813dc60,180,c5eea0a8,c0ce18a0,...) at vn_open+0x33 Mar 22 10:49:04 leonsio kernel: kern_openat(c6038000,ffffff9c,28528f80,0,603,...) at kern_openat+0x107 Mar 22 10:49:04 leonsio kernel: kern_open(c6038000,28528f80,0,602,180,...) at kern_open+0x35 Mar 22 10:49:04 leonsio kernel: open(c6038000,e813dcf8,c,c0bd0226,c0cd04f8,...) at open+0x30 Mar 22 10:49:04 leonsio kernel: syscall(e813dd38) at syscall+0x27a Mar 22 10:49:04 leonsio kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 22 10:49:04 leonsio kernel: --- syscall (5, FreeBSD ELF32, open), eip = 0x282eecdb, esp = 0xbf4f9d2c, ebp = 0xbf4f9d58 --- Others messages obtained when plug a Lacie external usb hard disk (congrats for the new USB2!! it runs (for me up to now) like a charm!!), the message is: Mar 22 11:17:55 leonsio root: Unknown USB device: vendor 0x059f product 0x1010 bus uhub6 Mar 22 11:17:55 leonsio kernel: ugen6.2: at usbus6 Mar 22 11:17:55 leonsio kernel: umass0: on usbus6 Mar 22 11:17:55 leonsio kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Mar 22 11:17:56 leonsio kernel: umass0:1:0:-1: Attached to scbus1 Mar 22 11:17:56 leonsio kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Mar 22 11:17:56 leonsio kernel: da0: Fixed Direct Access SCSI-2 device Mar 22 11:17:56 leonsio kernel: da0: 40.000MB/s transfers Mar 22 11:17:56 leonsio kernel: da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) Mar 22 11:17:56 leonsio kernel: GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. Mar 22 11:18:42 leonsio su: toomany to root on /dev/ttyv1 Mar 22 11:18:58 leonsio kernel: GEOM_LABEL: Label msdosfs/LaCie removed. Mar 22 11:18:58 leonsio kernel: GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. Mar 22 11:19:09 leonsio kernel: GEOM_LABEL: Label msdosfs/LaCie removed. Mar 22 11:19:29 leonsio kernel: lock order reversal: Mar 22 11:19:29 leonsio kernel: 1st 0xc8a5437c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1193 Mar 22 11:19:29 leonsio kernel: 2nd 0xc9687270 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:939 Mar 22 11:19:29 leonsio kernel: KDB: stack backtrace: Mar 22 11:19:29 leonsio kernel: db_trace_self_wrapper(c0bf0c2d,e8191a5c,c0870a7f,c08633e6,c0bf39d1,...) at db_trace_self_wrapper+0x26 Mar 22 11:19:29 leonsio kernel: kdb_backtrace(c08633e6,c0bf39d1,c5527c78,c5527b40,e8191ab8,...) at kdb_backtrace+0x29 Mar 22 11:19:29 leonsio kernel: _witness_debugger(c0bf39d1,c9687270,c0be379e,c5527b40,c0be4014,...) at _witness_debugger+0x1e Mar 22 11:19:29 leonsio kernel: witness_checkorder(c9687270,9,c0be4014,3ab,c968728c,...) at witness_checkorder+0x818 Mar 22 11:19:29 leonsio kernel: __lockmgr_args(c9687270,80400,c968728c,0,0,0,c0be4014,3ab) at __lockmgr_args+0x762 Mar 22 11:19:29 leonsio kernel: vop_stdlock(e8191bb4,c0e7df68,cb0bb964,80400,c9687218,...) at vop_stdlock+0x5c Mar 22 11:19:29 leonsio kernel: VOP_LOCK1_APV(c0cccf40,e8191bb4,e8191bd4,c0d0b9a0,c9687218,...) at VOP_LOCK1_APV+0xaf Mar 22 11:19:29 leonsio kernel: _vn_lock(c9687218,80400,c0be4014,3ab,c5ac6780,...) at _vn_lock+0x5e Mar 22 11:19:29 leonsio kernel: msdosfs_sync(c5ac6780,1,cb0bb8c0,4ee,1,...) at msdosfs_sync+0x285 Mar 22 11:19:29 leonsio kernel: dounmount(c5ac6780,8000000,cb0bb8c0,474,7,...) at dounmount+0x451 Mar 22 11:19:29 leonsio kernel: unmount(cb0bb8c0,e8191cf8,8,e8191d2c,c0cd0690,...) at unmount+0x2d8 Mar 22 11:19:29 leonsio kernel: syscall(e8191d38) at syscall+0x27a Mar 22 11:19:29 leonsio kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 22 11:19:29 leonsio kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d292f, esp = 0xbfbfe4ec, ebp = 0xbfbfe5b8 --- Mar 22 11:19:30 leonsio kernel: GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. Mar 22 11:19:43 leonsio kernel: umass0: at uhub6, port 1, addr 2 (disconnected) Mar 22 11:19:43 leonsio kernel: (da0:umass-sim0G:E0O:M0_:LA0B)E:L :l osLta bdeelv imcsedos Mar 22 11:19:43 leonsio kernel: f(sd/aL0a:Cuimea srse-msoivme0d:.0: Mar 22 11:19:43 leonsio kernel: 0:0): removing device entry Mar 22 11:19:43 leonsio kernel: ugen6.2: at usbus6 (disconnected) This is the pciconf -l -v output: hostb0@pci0:0:0:0: class=0x060000 card=0x02271028 chip=0x2a008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02271028 chip=0x2a018086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'Mobile PM965/GM965/GL960 Express PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:26:0: class=0x0c0300 card=0x02271028 chip=0x28348086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x02271028 chip=0x28358086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x02271028 chip=0x283a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller' class = serial bus subclass = USB none0@pci0:0:27:0: class=0x040300 card=0x02271028 chip=0x284b8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x02271028 chip=0x283f8086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 1' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x02271028 chip=0x28418086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 2' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x02271028 chip=0x28458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 4' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:5: class=0x060400 card=0x02271028 chip=0x28498086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 6' class = bridge subclass = PCI-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x02271028 chip=0x28308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci3@pci0:0:29:1: class=0x0c0300 card=0x02271028 chip=0x28318086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci4@pci0:0:29:2: class=0x0c0300 card=0x02271028 chip=0x28328086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x02271028 chip=0x28368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI' class = serial bus subclass = USB pcib6@pci0:0:30:0: class=0x060401 card=0x02271028 chip=0x24488086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x02271028 chip=0x28158086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M-E (ICH8 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x02271028 chip=0x28508086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x02271028 chip=0x28298086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801 Intel(R) 82801HEM/HBM SATA AHCI Controller' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x02271028 chip=0x283e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x02271028 chip=0x042710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'unknown Geforce 8600' class = display subclass = VGA none2@pci0:12:0:0: class=0x028000 card=0x10218086 chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '10418086 Intel 3945ABG Wireless LAN controller' class = network bge0@pci0:9:0:0: class=0x020000 card=0x02271028 chip=0x171314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetLink BCM5906M Fast Ethernet PCIe' class = network subclass = ethernet fwohci0@pci0:3:1:0: class=0x0c0010 card=0x02271028 chip=0x08321180 rev=0x05 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'unknown IEEE 1394 (4 pin firewire) chip)' class = serial bus subclass = FireWire none3@pci0:3:1:1: class=0x080501 card=0x02271028 chip=0x08221180 rev=0x22 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'R5C832, R5C843 SDA Standard Compliant SD Host Controller' class = base peripheral subclass = SD host controller none4@pci0:3:1:2: class=0x088000 card=0x02271028 chip=0x08431180 rev=0x12 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh MMC Host Controller' class = base peripheral none5@pci0:3:1:3: class=0x088000 card=0x02271028 chip=0x05921180 rev=0x12 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = '13871043 Ricoh Memory Stick Host Controller' class = base peripheral none6@pci0:3:1:4: class=0x088000 card=0x02271028 chip=0x08521180 rev=0x12 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh xD-Picture Card Host Controller' class = base peripheral And here it is the dmesg output (complete from this morning): Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Thu Mar 19 20:38:56 CET 2009 root@leonsio.toomany.net:/usr/obj/usr/src/sys/LEONSIO WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant Cores per package: 2 real memory = 2145832960 (2046 MB) avail memory = 2087342080 (1990 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, 7fd6d800 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xef00-0xef7f mem 0xfd000000-0xfdffffff,0xe0000000-0xefffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci1 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f00 usbus0: on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f00 usbus1: on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 pci12: at device 0.0 (no driver attached) pcib4: at device 28.3 on pci0 pci13: on pcib4 pcib5: at device 28.5 on pci0 pci9: on pcib5 bge0: mem 0xf9bf0000-0xf9bfffff irq 17 at device 0.0 on pci9 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bge0: Ethernet address: 00:1c:23:fa:ed:62 bge0: [ITHREAD] uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f00 usbus3: on uhci2 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f00 usbus4: on uhci3 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0f00 usbus5: on uhci4 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 fwohci0: <1394 Open Host Controller Interface> mem 0xf9aff800-0xf9afffff irq 19 at device 1.0 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 43:4f:c0:00:1f:0b:34:70 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x14a0000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 42:4f:c0:0b:34:70 fwe0: Ethernet address: 42:4f:c0:0b:34:70 fwip0: on firewire0 fwip0: Firewire address: 43:4f:c0:00:1f:0b:34:70 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode pci3: at device 1.1 (no driver attached) pci3: at device 1.2 (no driver attached) pci3: at device 1.3 (no driver attached) pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 0xfebfb800-0xfebfbfff irq 17 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 3 ports PM not supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcd7ff,0xcd800-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 acd0: DVDR at ata0-master UDMA33 ad4: 114473MB at ata2-master SATA300 GEOM: ad4: partition 3 does not start on a track boundary. GEOM: ad4: partition 3 does not end on a track boundary. GEOM: ad4: partition 2 does not end on a track boundary. GEOM_LABEL: Label for provider ad4s1 is msdosfs/DellUtility. GEOM: ad4s3: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered ugen4.2: at usbus4 ums0: on usbus4 ums0: 5 buttons and [XYZ] coordinates SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s3a bge0: link state changed to UP logo_saver: the console does not support M_VGA_CG320 module_register_init: MOD_LOAD (logo_saver, 0xc5eef827, 0) error 19 lock order reversal: 1st 0xd9542500 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2549 2nd 0xc5b7c800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c0bf0c2d,e813d780,c0870a7f,c08633e6,c0bf39d1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08633e6,c0bf39d1,c5524a18,c5527ce0,e813d7dc,...) at kdb_backtrace+0x29 _witness_debugger(c0bf39d1,c5b7c800,c0c12faa,c5527ce0,c0c12c43,...) at _witness_debugger+0x1e witness_checkorder(c5b7c800,9,c0c12c43,113,0,...) at witness_checkorder+0x818 _sx_xlock(c5b7c800,0,c0c12c43,113,c609264c,...) at _sx_xlock+0x7f ufsdirhash_acquire(d95424a0,da8dfd7c,84,da8dfd88,e813d8ac,...) at ufsdirhash_acquire+0x31 ufsdirhash_add(c609264c,e813d8f4,d88,e813d898,e813d89c,...) at ufsdirhash_add+0x13 ufs_direnter(c6094430,c61ab860,e813d8f4,e813dbd8,0,...) at ufs_direnter+0x70b ufs_makeinode(e813dbd8) at ufs_makeinode+0x4f2 ufs_create(e813dad0,e813dad0,0,e813dad0,e813dbac,...) at ufs_create+0x2c VOP_CREATE_APV(c0cf3080,e813dad0,2,c0be6967,3,...) at VOP_CREATE_APV+0xa2 vn_open_cred(e813dbac,e813dc60,180,c5f92500,c5eea0a8,...) at vn_open_cred+0x1d0 vn_open(e813dbac,e813dc60,180,c5eea0a8,c0ce18a0,...) at vn_open+0x33 kern_openat(c6038000,ffffff9c,28528f80,0,603,...) at kern_openat+0x107 kern_open(c6038000,28528f80,0,602,180,...) at kern_open+0x35 open(c6038000,e813dcf8,c,c0bd0226,c0cd04f8,...) at open+0x30 syscall(e813dd38) at syscall+0x27a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x282eecdb, esp = 0xbf4f9d2c, ebp = 0xbf4f9d58 --- lock order reversal: 1st 0xc7ffead0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2100 2nd 0xd966df90 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6150 3rd 0xc81956a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2100 KDB: stack backtrace: db_trace_self_wrapper(c0bf0c2d,e813d3dc,c0870a7f,c08633e6,c0bf39ea,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08633e6,c0bf39ea,c5524a18,c5527c78,e813d438,...) at kdb_backtrace+0x29 _witness_debugger(c0bf39ea,c81956a0,c0be7288,c5527c78,c0bfa714,...) at _witness_debugger+0x1e witness_checkorder(c81956a0,9,c0bfa714,834,0,...) at witness_checkorder+0x818 __lockmgr_args(c81956a0,80100,c81956bc,0,0,...) at __lockmgr_args+0x762 ffs_lock(e813d540,c087085b,c0bf9d9e,80100,c8195648,...) at ffs_lock+0x7d VOP_LOCK1_APV(c0cf3080,e813d540,c60380a4,c0d0b9a0,c8195648,...) at VOP_LOCK1_APV+0xaf _vn_lock(c8195648,80100,c0bfa714,834,4,...) at _vn_lock+0x5e vget(c8195648,80100,c6038000,50,0,...) at vget+0xc1 vfs_hash_get(c5b8b500,1ab270,80000,c6038000,e813d69c,...) at vfs_hash_get+0xdf ffs_vgetf(c5b8b500,1ab270,80000,e813d69c,1,...) at ffs_vgetf+0x43 softdep_sync_metadata(c7ffea78,0,c0c128c0,131,0,...) at softdep_sync_metadata+0x59e ffs_syncvnode(c7ffea78,1,e813d734,c087085b,c0bec21d,...) at ffs_syncvnode+0x3c9 ffs_truncate(c7ffea78,e00,0,880,c5f92500,...) at ffs_truncate+0x644 ufs_direnter(c7ffea78,c8195648,e813da24,e813dc08,d94fcf90,...) at ufs_direnter+0x8d1 ufs_mkdir(e813dc2c,e813dc2c,0,e813dc2c,e813dbdc,...) at ufs_mkdir+0x8f2 VOP_MKDIR_APV(c0cf3080,e813dc2c,ebf,ebd,0,...) at VOP_MKDIR_APV+0xa2 kern_mkdirat(c6038000,ffffff9c,28528f80,0,1ed,...) at kern_mkdirat+0x278 kern_mkdir(c6038000,28528f80,0,1ed,e813dd2c,...) at kern_mkdir+0x2e mkdir(c6038000,e813dcf8,8,c0bf0ce9,c0cd1140,...) at mkdir+0x29 syscall(e813dd38) at syscall+0x27a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x282eec9b, esp = 0xbf4f9cdc, ebp = 0xbf4f9d18 --- ugen6.2: at usbus6 umass0: on usbus6 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. GEOM_LABEL: Label msdosfs/LaCie removed. GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. GEOM_LABEL: Label msdosfs/LaCie removed. lock order reversal: 1st 0xc8a5437c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1193 2nd 0xc9687270 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:939 KDB: stack backtrace: db_trace_self_wrapper(c0bf0c2d,e8191a5c,c0870a7f,c08633e6,c0bf39d1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08633e6,c0bf39d1,c5527c78,c5527b40,e8191ab8,...) at kdb_backtrace+0x29 _witness_debugger(c0bf39d1,c9687270,c0be379e,c5527b40,c0be4014,...) at _witness_debugger+0x1e witness_checkorder(c9687270,9,c0be4014,3ab,c968728c,...) at witness_checkorder+0x818 __lockmgr_args(c9687270,80400,c968728c,0,0,0,c0be4014,3ab) at __lockmgr_args+0x762 vop_stdlock(e8191bb4,c0e7df68,cb0bb964,80400,c9687218,...) at vop_stdlock+0x5c VOP_LOCK1_APV(c0cccf40,e8191bb4,e8191bd4,c0d0b9a0,c9687218,...) at VOP_LOCK1_APV+0xaf _vn_lock(c9687218,80400,c0be4014,3ab,c5ac6780,...) at _vn_lock+0x5e msdosfs_sync(c5ac6780,1,cb0bb8c0,4ee,1,...) at msdosfs_sync+0x285 dounmount(c5ac6780,8000000,cb0bb8c0,474,7,...) at dounmount+0x451 unmount(cb0bb8c0,e8191cf8,8,e8191d2c,c0cd0690,...) at unmount+0x2d8 syscall(e8191d38) at syscall+0x27a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d292f, esp = 0xbfbfe4ec, ebp = 0xbfbfe5b8 --- GEOM_LABEL: Label for provider da0s1 is msdosfs/LaCie. umass0: at uhub6, port 1, addr 2 (disconnected) (da0:umass-sim0G:E0O:M0_:LA0B)E:L :l osLta bdeelv imcsedos f(sd/aL0a:Cuimea srse-msoivme0d:.0: 0:0): removing device entry ugen6.2: at usbus6 (disconnected) Thank you! -- --------------------------------------------------------------------------------------- Have a nice day ;-) TooManySecrets /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | GNU/Linux Since 1994. X - NO Word docs in e-mail | / \ - http://www.toomany.net --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 12:26:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AFE81065673; Sun, 22 Mar 2009 12:26:30 +0000 (UTC) (envelope-from arved@FreeBSD.org) Received: from mailbackup.inode.at (mailbackup.inode.at [213.229.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id 47DB98FC0A; Sun, 22 Mar 2009 12:26:30 +0000 (UTC) (envelope-from arved@FreeBSD.org) Received: from [62.99.145.22] (port=42937 helo=mx.inode.at) by mailbackup.inode.at with esmtp (Exim 4.67) (envelope-from ) id 1LlMHn-0007ra-Kr; Sun, 22 Mar 2009 12:56:15 +0100 Received: from [62.178.208.15] (port=12765 helo=[192.168.1.28]) by smartmx-20.inode.at with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LlMHg-00055i-UX; Sun, 22 Mar 2009 12:56:09 +0100 In-Reply-To: <20090320043115.3b46177e.ota@j.email.ne.jp> References: <20090319223756.GF2118@citylink.fud.org.nz> <20090320043115.3b46177e.ota@j.email.ne.jp> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C4A9CBD-486C-40E5-AE91-C2B281625C1B@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Tilman Linneweh Date: Sun, 22 Mar 2009 12:55:57 +0100 To: Yoshihiro Ota X-Mailer: Apple Mail (2.753.1) Cc: usb , current@freebsd.org Subject: Re: USBTODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 12:26:31 -0000 * Yoshihiro Ota [ Mar 20, 2009 (09:31 )]: >> >> Remember there is a page tracking the new USB stack to the 8.0 >> release. >> Please add any items/regressions or even better would be to pick up a >> task and work on it. >> >> http://wiki.freebsd.org/USBTODO > > Can I create an account and update the page freely or do I need > someone's > permission to do so? You can create an account and then ask a FreeBSD Developer to give editing permissions to this account. From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 12:55:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A9010656BC for ; Sun, 22 Mar 2009 12:55:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CE94E8FC08 for ; Sun, 22 Mar 2009 12:55:39 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=djDbEolmZ0EA:10 a=weFJKH8iETMA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=3oc9M9_CAAAA:8 a=3Zc74pW6NOn_oxQ6vFQA:9 a=sKPWZKmxhxj1O-1Y9I0A:7 a=8aP90OyOG-WLnxYw04dOn1YyeSYA:4 a=LY0hPdMaydYA:10 a=U8Ie8EnqySEA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1111294253; Sun, 22 Mar 2009 13:55:38 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 22 Mar 2009 13:58:07 +0100 User-Agent: KMail/1.9.7 References: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> In-Reply-To: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903221358.08655.hselasky@c2i.net> Cc: debardeleben@aol.com, freebsd@cfdhome.com Subject: Re: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 12:55:40 -0000 On Sunday 22 March 2009, debardeleben@aol.com wrote: > I finally got fed up enough with not being able to print with -CURRENT, > and found a fix that make ulpt work for me with my epson stylus photo 835. > > I am using cups, and I have always needed to use the non-reset device, > even with the old USB stack. Hopefully a committer can pick this up and > include an appropriate version of this fix to the source tree. In the mean > time, if you are having trouble with a usb printer with -CURRENT, you > may want to try this patch. Hi, The memory allocated by malloc() when M_ZERO is passed should be all zero, so the patch you are suggesting is redundant. See "device_set_driver()": dev->softc = malloc(driver->size, M_BUS_SC, M_NOWAIT | M_ZERO); So there must be a problem with malloc then, or someone that is using freed memory! Try compiling a kernel with the INVARIANTS kernel options and perhaps some malloc debugging. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 14:26:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F4A1065673; Sun, 22 Mar 2009 14:26:43 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD688FC14; Sun, 22 Mar 2009 14:26:40 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.148.109] (port=64916 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlOdI-000LrT-G4; Sun, 22 Mar 2009 17:26:38 +0300 Message-ID: <49C64AA5.3000509@lissyara.su> Date: Sun, 22 Mar 2009 17:26:45 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.19 (X11/20090209) MIME-Version: 1.0 To: freebsd-current@freebsd.org, Robert Noland Content-Type: multipart/mixed; boundary="------------000407070504010200060901" X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 14:26:44 -0000 This is a multi-part message in MIME format. --------------000407070504010200060901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit After last update (4 hour ago) I have problem with X - no signal. --------------000407070504010200060901 Content-Type: text/plain; name="Xorg.0.log.old" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Xorg.0.log.old" ClguT3JnIFggU2VydmVyIDEuNS4zClJlbGVhc2UgRGF0ZTogNSBOb3ZlbWJlciAyMDA4Clgg UHJvdG9jb2wgVmVyc2lvbiAxMSwgUmV2aXNpb24gMApCdWlsZCBPcGVyYXRpbmcgU3lzdGVt OiBGcmVlQlNEIDguMC1DVVJSRU5UIGFtZDY0IApDdXJyZW50IE9wZXJhdGluZyBTeXN0ZW06 IEZyZWVCU0QgSFAubGlzc3lhcmEuc3UgOC4wLUNVUlJFTlQgRnJlZUJTRCA4LjAtQ1VSUkVO VCAjMDogU3VuIE1hciAyMiAxNDo1Mjo0NyBNU0sgMjAwOSAgICAgbGlzc3lhcmFASFAubGlz c3lhcmEuc3U6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApCdWlsZCBEYXRl OiAwOSBNYXJjaCAyMDA5ICAwMjozMjozMlBNCiAKCUJlZm9yZSByZXBvcnRpbmcgcHJvYmxl bXMsIGNoZWNrIGh0dHA6Ly93aWtpLngub3JnCgl0byBtYWtlIHN1cmUgdGhhdCB5b3UgaGF2 ZSB0aGUgbGF0ZXN0IHZlcnNpb24uCk1hcmtlcnM6ICgtLSkgcHJvYmVkLCAoKiopIGZyb20g Y29uZmlnIGZpbGUsICg9PSkgZGVmYXVsdCBzZXR0aW5nLAoJKCsrKSBmcm9tIGNvbW1hbmQg bGluZSwgKCEhKSBub3RpY2UsIChJSSkgaW5mb3JtYXRpb25hbCwKCShXVykgd2FybmluZywg KEVFKSBlcnJvciwgKE5JKSBub3QgaW1wbGVtZW50ZWQsICg/PykgdW5rbm93bi4KKD09KSBM b2cgZmlsZTogIi92YXIvbG9nL1hvcmcuMC5sb2ciLCBUaW1lOiBTdW4gTWFyIDIyIDE2OjQ4 OjEwIDIwMDkKKEVFKSBVbmFibGUgdG8gbG9jYXRlL29wZW4gY29uZmlnIGZpbGUKKElJKSBM b2FkZXIgbWFnaWM6IDB4NjcxMjQwCihJSSkgTW9kdWxlIEFCSSB2ZXJzaW9uczoKCVguT3Jn IEFOU0kgQyBFbXVsYXRpb246IDAuNAoJWC5PcmcgVmlkZW8gRHJpdmVyOiA0LjEKCVguT3Jn IFhJbnB1dCBkcml2ZXIgOiAyLjEKCVguT3JnIFNlcnZlciBFeHRlbnNpb24gOiAxLjEKCVgu T3JnIEZvbnQgUmVuZGVyZXIgOiAwLjYKKElJKSBMb2FkZXIgcnVubmluZyBvbiBmcmVlYnNk CigtLSkgVXNpbmcgc3lzY29ucyBkcml2ZXIgd2l0aCBYIHN1cHBvcnQgKHZlcnNpb24gMi4w KQooLS0pIHVzaW5nIFZUIG51bWJlciA5CgooLS0pIFBDSToqKDBAMTo1OjApIEFUSSBUZWNo bm9sb2dpZXMgSW5jIFJTNjkwTSBbUmFkZW9uIFgxMjAwIFNlcmllc10gcmV2IDAsIE1lbSBA IDB4YzAwMDAwMDAvMTM0MjE3NzI4LCAweGQwMjAwMDAwLzY1NTM2LCAweGQwMzAwMDAwLzEw NDg1NzYsIEkvTyBAIDB4MDAwMDQwMDAvMjU2LCBCSU9TIEAgMHg/Pz8/Pz8/Py82NTUzNgoo PT0pIE1hdGNoZWQgYXRpIGZvciB0aGUgYXV0b2NvbmZpZ3VyZWQgZHJpdmVyCk5ldyBkcml2 ZXIgaXMgImF0aSIKKD09KSBVc2luZyBkZWZhdWx0IGJ1aWx0LWluIGNvbmZpZ3VyYXRpb24g KDMwIGxpbmVzKQooPT0pIC0tLSBTdGFydCBvZiBidWlsdC1pbiBjb25maWd1cmF0aW9uIC0t LQoJU2VjdGlvbiAiRGV2aWNlIgoJCUlkZW50aWZpZXIJIkJ1aWx0aW4gRGVmYXVsdCBhdGkg RGV2aWNlIDAiCgkJRHJpdmVyCSJhdGkiCglFbmRTZWN0aW9uCglTZWN0aW9uICJTY3JlZW4i CgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IGF0aSBTY3JlZW4gMCIKCQlEZXZpY2UJ IkJ1aWx0aW4gRGVmYXVsdCBhdGkgRGV2aWNlIDAiCglFbmRTZWN0aW9uCglTZWN0aW9uICJE ZXZpY2UiCgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IGZiZGV2IERldmljZSAwIgoJ CURyaXZlcgkiZmJkZXYiCglFbmRTZWN0aW9uCglTZWN0aW9uICJTY3JlZW4iCgkJSWRlbnRp ZmllcgkiQnVpbHRpbiBEZWZhdWx0IGZiZGV2IFNjcmVlbiAwIgoJCURldmljZQkiQnVpbHRp biBEZWZhdWx0IGZiZGV2IERldmljZSAwIgoJRW5kU2VjdGlvbgoJU2VjdGlvbiAiRGV2aWNl IgoJCUlkZW50aWZpZXIJIkJ1aWx0aW4gRGVmYXVsdCB2ZXNhIERldmljZSAwIgoJCURyaXZl cgkidmVzYSIKCUVuZFNlY3Rpb24KCVNlY3Rpb24gIlNjcmVlbiIKCQlJZGVudGlmaWVyCSJC dWlsdGluIERlZmF1bHQgdmVzYSBTY3JlZW4gMCIKCQlEZXZpY2UJIkJ1aWx0aW4gRGVmYXVs dCB2ZXNhIERldmljZSAwIgoJRW5kU2VjdGlvbgoJU2VjdGlvbiAiU2VydmVyTGF5b3V0IgoJ CUlkZW50aWZpZXIJIkJ1aWx0aW4gRGVmYXVsdCBMYXlvdXQiCgkJU2NyZWVuCSJCdWlsdGlu IERlZmF1bHQgYXRpIFNjcmVlbiAwIgoJCVNjcmVlbgkiQnVpbHRpbiBEZWZhdWx0IGZiZGV2 IFNjcmVlbiAwIgoJCVNjcmVlbgkiQnVpbHRpbiBEZWZhdWx0IHZlc2EgU2NyZWVuIDAiCglF bmRTZWN0aW9uCig9PSkgLS0tIEVuZCBvZiBidWlsdC1pbiBjb25maWd1cmF0aW9uIC0tLQoo PT0pIFNlcnZlckxheW91dCAiQnVpbHRpbiBEZWZhdWx0IExheW91dCIKKCoqKSB8LS0+U2Ny ZWVuICJCdWlsdGluIERlZmF1bHQgYXRpIFNjcmVlbiAwIiAoMCkKKCoqKSB8ICAgfC0tPk1v bml0b3IgIjxkZWZhdWx0IG1vbml0b3I+IgooKiopIHwgICB8LS0+RGV2aWNlICJCdWlsdGlu IERlZmF1bHQgYXRpIERldmljZSAwIgooPT0pIE5vIG1vbml0b3Igc3BlY2lmaWVkIGZvciBz Y3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCBhdGkgU2NyZWVuIDAiLgoJVXNpbmcgYSBkZWZhdWx0 IG1vbml0b3IgY29uZmlndXJhdGlvbi4KKCoqKSB8LS0+U2NyZWVuICJCdWlsdGluIERlZmF1 bHQgZmJkZXYgU2NyZWVuIDAiICgxKQooKiopIHwgICB8LS0+TW9uaXRvciAiPGRlZmF1bHQg bW9uaXRvcj4iCigqKikgfCAgIHwtLT5EZXZpY2UgIkJ1aWx0aW4gRGVmYXVsdCBmYmRldiBE ZXZpY2UgMCIKKD09KSBObyBtb25pdG9yIHNwZWNpZmllZCBmb3Igc2NyZWVuICJCdWlsdGlu IERlZmF1bHQgZmJkZXYgU2NyZWVuIDAiLgoJVXNpbmcgYSBkZWZhdWx0IG1vbml0b3IgY29u ZmlndXJhdGlvbi4KKCoqKSB8LS0+U2NyZWVuICJCdWlsdGluIERlZmF1bHQgdmVzYSBTY3Jl ZW4gMCIgKDIpCigqKikgfCAgIHwtLT5Nb25pdG9yICI8ZGVmYXVsdCBtb25pdG9yPiIKKCoq KSB8ICAgfC0tPkRldmljZSAiQnVpbHRpbiBEZWZhdWx0IHZlc2EgRGV2aWNlIDAiCig9PSkg Tm8gbW9uaXRvciBzcGVjaWZpZWQgZm9yIHNjcmVlbiAiQnVpbHRpbiBEZWZhdWx0IHZlc2Eg U2NyZWVuIDAiLgoJVXNpbmcgYSBkZWZhdWx0IG1vbml0b3IgY29uZmlndXJhdGlvbi4KKD09 KSBBdXRvbWF0aWNhbGx5IGFkZGluZyBkZXZpY2VzCig9PSkgQXV0b21hdGljYWxseSBlbmFi bGluZyBkZXZpY2VzCig9PSkgTm8gRm9udFBhdGggc3BlY2lmaWVkLiAgVXNpbmcgY29tcGls ZWQtaW4gZGVmYXVsdC4KKD09KSBGb250UGF0aCBzZXQgdG86CgkvdXNyL2xvY2FsL2xpYi9Y MTEvZm9udHMvbWlzYy8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVFRGLywKCS91c3Iv bG9jYWwvbGliL1gxMS9mb250cy9PVEYsCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVHlw ZTEvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8sCgkvdXNyL2xvY2FsL2xp Yi9YMTEvZm9udHMvNzVkcGkvCig9PSkgTW9kdWxlUGF0aCBzZXQgdG8gIi91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcyIKKElJKSBDYW5ub3QgbG9jYXRlIGEgY29yZSBwb2ludGVyIGRl dmljZS4KKElJKSBDYW5ub3QgbG9jYXRlIGEgY29yZSBrZXlib2FyZCBkZXZpY2UuCihJSSkg VGhlIHNlcnZlciByZWxpZXMgb24gSEFMIHRvIHByb3ZpZGUgdGhlIGxpc3Qgb2YgaW5wdXQg ZGV2aWNlcy4KCUlmIG5vIGRldmljZXMgYmVjb21lIGF2YWlsYWJsZSwgcmVjb25maWd1cmUg SEFMIG9yIGRpc2FibGUgQWxsb3dFbXB0eUlucHV0LgooSUkpIFN5c3RlbSByZXNvdXJjZSBy YW5nZXM6CglbMF0gLTEJMAkweDAwMTAwMDAwIC0gMHgzZmZmZmZmZiAoMHgzZmYwMDAwMCkg TVhbQl1FKEIpCglbMV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkg TVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtC XQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglb NF0gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzVdIC0xCTAJ MHgwMDAwMDAwMCAtIDB4MDAwMDAwZmYgKDB4MTAwKSBJWFtCXQooSUkpIExvYWRNb2R1bGU6 ICJleHRtb2QiCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2V4 dGVuc2lvbnMvL2xpYmV4dG1vZC5zbwooSUkpIE1vZHVsZSBleHRtb2Q6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMS4xCihJSSkgTG9hZGluZyBleHRl bnNpb24gU0hBUEUKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBNSVQtU1VORFJZLU5PTlNUQU5E QVJECihJSSkgTG9hZGluZyBleHRlbnNpb24gQklHLVJFUVVFU1RTCihJSSkgTG9hZGluZyBl eHRlbnNpb24gU1lOQwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIE1JVC1TQ1JFRU4tU0FWRVIK KElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYQy1NSVNDCihJSSkgTG9hZGluZyBleHRlbnNpb24g WEZyZWU4Ni1WaWRNb2RlRXh0ZW5zaW9uCihJSSkgTG9hZGluZyBleHRlbnNpb24gWEZyZWU4 Ni1NaXNjCihJSSkgTG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1ER0EKKElJKSBMb2FkaW5n IGV4dGVuc2lvbiBEUE1TCihJSSkgTG9hZGluZyBleHRlbnNpb24gVE9HLUNVUAooSUkpIExv YWRpbmcgZXh0ZW5zaW9uIEV4dGVuZGVkLVZpc3VhbC1JbmZvcm1hdGlvbgooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIFhWaWRlbwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhWaWRlby1Nb3Rp b25Db21wZW5zYXRpb24KKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYLVJlc291cmNlCihJSSkg TG9hZE1vZHVsZTogImRiZSIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21v ZHVsZXMvZXh0ZW5zaW9ucy8vbGliZGJlLnNvCihJSSkgTW9kdWxlIGRiZTogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9 IDEuMC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFz czogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAxLjEKKElJKSBMb2FkaW5nIGV4 dGVuc2lvbiBET1VCTEUtQlVGRkVSCihJSSkgTG9hZE1vZHVsZTogImdseCIKCihJSSkgTG9h ZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGliZ2x4LnNv CihJSSkgTW9kdWxlIGdseDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQg Zm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFNl cnZlciBFeHRlbnNpb24sIHZlcnNpb24gMS4xCig9PSkgQUlHTFggZGlzYWJsZWQKKD09KSBF eHBvcnRpbmcgdHlwaWNhbCBzZXQgb2YgR0xYIHZpc3VhbHMKKElJKSBMb2FkaW5nIGV4dGVu c2lvbiBHTFgKKElJKSBMb2FkTW9kdWxlOiAiZnJlZXR5cGUiCgooSUkpIExvYWRpbmcgL3Vz ci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2ZvbnRzLy9saWJmcmVldHlwZS5zbwooSUkpIE1v ZHVsZSBmcmVldHlwZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uICYgdGhlIEFmdGVyIFgt VFQgUHJvamVjdCIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAyLjEu MAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBGb250IFJlbmRlcmVyCglBQkkgY2xhc3M6IFguT3Jn IEZvbnQgUmVuZGVyZXIsIHZlcnNpb24gMC42CihJSSkgTG9hZGluZyBmb250IEZyZWVUeXBl CihJSSkgTG9hZE1vZHVsZTogInJlY29yZCIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xp Yi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGlicmVjb3JkLnNvCihJSSkgTW9kdWxlIHJl Y29yZDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBt b2R1bGUgdmVyc2lvbiA9IDEuMTMuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0 ZW5zaW9uCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMS4x CihJSSkgTG9hZGluZyBleHRlbnNpb24gUkVDT1JECihJSSkgTG9hZE1vZHVsZTogImRyaSIK CihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8v bGliZHJpLnNvCihJSSkgTW9kdWxlIGRyaTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMS4xCihJSSkgTG9hZGluZyBleHRl bnNpb24gWEZyZWU4Ni1EUkkKKElJKSBMb2FkTW9kdWxlOiAiYXRpIgoKKElJKSBMb2FkaW5n IC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9kcml2ZXJzLy9hdGlfZHJ2LnNvCihJSSkg TW9kdWxlIGF0aTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEu NS4zLCBtb2R1bGUgdmVyc2lvbiA9IDYuMTIuMQoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRl byBEcml2ZXIKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDQuMQoo SUkpIExvYWRNb2R1bGU6ICJyYWRlb24iCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIv eG9yZy9tb2R1bGVzL2RyaXZlcnMvL3JhZGVvbl9kcnYuc28KKElJKSBNb2R1bGUgcmFkZW9u OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS41LjMsIG1vZHVs ZSB2ZXJzaW9uID0gNi4xMi4xCglNb2R1bGUgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZlcgoJ QUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gNC4xCihJSSkgTG9hZE1v ZHVsZTogImZiZGV2IgoKKFdXKSBXYXJuaW5nLCBjb3VsZG4ndCBvcGVuIG1vZHVsZSBmYmRl dgooSUkpIFVubG9hZE1vZHVsZTogImZiZGV2IgooRUUpIEZhaWxlZCB0byBsb2FkIG1vZHVs ZSAiZmJkZXYiIChtb2R1bGUgZG9lcyBub3QgZXhpc3QsIDApCihJSSkgTG9hZE1vZHVsZTog InZlc2EiCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2RyaXZl cnMvL3Zlc2FfZHJ2LnNvCihJSSkgTW9kdWxlIHZlc2E6IHZlbmRvcj0iWC5PcmcgRm91bmRh dGlvbiIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAyLjEuMAoJTW9k dWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8g RHJpdmVyLCB2ZXJzaW9uIDQuMQooSUkpIFJBREVPTjogRHJpdmVyIGZvciBBVEkgUmFkZW9u IGNoaXBzZXRzOgoJQVRJIFJhZGVvbiBNb2JpbGl0eSBYNjAwIChNMjQpIDMxNTAgKFBDSUUp LCBBVEkgRmlyZU1WIDI0MDAgKFBDSSksCglBVEkgUmFkZW9uIE1vYmlsaXR5IFgzMDAgKE0y NCkgMzE1MiAoUENJRSksCglBVEkgRmlyZUdMIE0yNCBHTCAzMTU0IChQQ0lFKSwgQVRJIFJh ZGVvbiBYNjAwIChSVjM4MCkgM0U1MCAoUENJRSksCglBVEkgRmlyZUdMIFYzMjAwIChSVjM4 MCkgM0U1NCAoUENJRSksIEFUSSBSYWRlb24gSUdQMzIwIChBMykgNDEzNiwKCUFUSSBSYWRl b24gSUdQMzMwLzM0MC8zNTAgKEE0KSA0MTM3LCBBVEkgUmFkZW9uIDk1MDAgQUQgKEFHUCks CglBVEkgUmFkZW9uIDk1MDAgQUUgKEFHUCksIEFUSSBSYWRlb24gOTYwMFRYIEFGIChBR1Ap LAoJQVRJIEZpcmVHTCBaMSBBRyAoQUdQKSwgQVRJIFJhZGVvbiA5ODAwU0UgQUggKEFHUCks CglBVEkgUmFkZW9uIDk4MDAgQUkgKEFHUCksIEFUSSBSYWRlb24gOTgwMCBBSiAoQUdQKSwK CUFUSSBGaXJlR0wgWDIgQUsgKEFHUCksIEFUSSBSYWRlb24gOTYwMCBBUCAoQUdQKSwKCUFU SSBSYWRlb24gOTYwMFNFIEFRIChBR1ApLCBBVEkgUmFkZW9uIDk2MDBYVCBBUiAoQUdQKSwK CUFUSSBSYWRlb24gOTYwMCBBUyAoQUdQKSwgQVRJIEZpcmVHTCBUMiBBVCAoQUdQKSwgQVRJ IFJhZGVvbiA5NjUwLAoJQVRJIEZpcmVHTCBSVjM2MCBBViAoQUdQKSwgQVRJIFJhZGVvbiA3 MDAwIElHUCAoQTQrKSA0MjM3LAoJQVRJIFJhZGVvbiA4NTAwIEFJVyBCQiAoQUdQKSwgQVRJ IFJhZGVvbiA4NTAwIEFJVyBCQyAoQUdQKSwKCUFUSSBSYWRlb24gSUdQMzIwTSAoVTEpIDQz MzYsIEFUSSBSYWRlb24gSUdQMzMwTS8zNDBNLzM1ME0gKFUyKSA0MzM3LAoJQVRJIFJhZGVv biBNb2JpbGl0eSA3MDAwIElHUCA0NDM3LCBBVEkgUmFkZW9uIDkwMDAvUFJPIElmIChBR1Av UENJKSwKCUFUSSBSYWRlb24gOTAwMCBJZyAoQUdQL1BDSSksIEFUSSBSYWRlb24gWDgwMCAo UjQyMCkgSkggKEFHUCksCglBVEkgUmFkZW9uIFg4MDBQUk8gKFI0MjApIEpJIChBR1ApLAoJ QVRJIFJhZGVvbiBYODAwU0UgKFI0MjApIEpKIChBR1ApLCBBVEkgUmFkZW9uIFg4MDAgKFI0 MjApIEpLIChBR1ApLAoJQVRJIFJhZGVvbiBYODAwIChSNDIwKSBKTCAoQUdQKSwgQVRJIEZp cmVHTCBYMyAoUjQyMCkgSk0gKEFHUCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IDk4MDAgKE0x OCkgSk4gKEFHUCksCglBVEkgUmFkZW9uIFg4MDAgU0UgKFI0MjApIChBR1ApLCBBVEkgUmFk ZW9uIFg4MDBYVCAoUjQyMCkgSlAgKEFHUCksCglBVEkgUmFkZW9uIFg4NTAgWFQgKFI0ODAp IChBR1ApLCBBVEkgUmFkZW9uIFg4NTAgU0UgKFI0ODApIChBR1ApLAoJQVRJIFJhZGVvbiBY ODUwIFBSTyAoUjQ4MCkgKEFHUCksIEFUSSBSYWRlb24gWDg1MCBYVCBQRSAoUjQ4MCkgKEFH UCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IE03IExXIChBR1ApLAoJQVRJIE1vYmlsaXR5IEZp cmVHTCA3ODAwIE03IExYIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBNNiBMWSAoQUdQ KSwgQVRJIFJhZGVvbiBNb2JpbGl0eSBNNiBMWiAoQUdQKSwKCUFUSSBGaXJlR0wgTW9iaWxp dHkgOTAwMCAoTTkpIExkIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MDAwIChNOSkg TGYgKEFHUCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IDkwMDAgKE05KSBMZyAoQUdQKSwgQVRJ IFJhZGVvbiA5NzAwIFBybyBORCAoQUdQKSwKCUFUSSBSYWRlb24gOTcwMC85NTAwUHJvIE5F IChBR1ApLCBBVEkgUmFkZW9uIDk2MDBUWCBORiAoQUdQKSwKCUFUSSBGaXJlR0wgWDEgTkcg KEFHUCksIEFUSSBSYWRlb24gOTgwMFBSTyBOSCAoQUdQKSwKCUFUSSBSYWRlb24gOTgwMCBO SSAoQUdQKSwgQVRJIEZpcmVHTCBYMiBOSyAoQUdQKSwKCUFUSSBSYWRlb24gOTgwMFhUIE5K IChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5NjAwLzk3MDAgKE0xMC9NMTEpIE5QIChB R1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5NjAwIChNMTApIE5RIChBR1ApLAoJQVRJIFJh ZGVvbiBNb2JpbGl0eSA5NjAwIChNMTEpIE5SIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0 eSA5NjAwIChNMTApIE5TIChBR1ApLAoJQVRJIEZpcmVHTCBNb2JpbGl0eSBUMiAoTTEwKSBO VCAoQUdQKSwKCUFUSSBGaXJlR0wgTW9iaWxpdHkgVDJlIChNMTEpIE5WIChBR1ApLCBBVEkg UmFkZW9uIFFEIChBR1ApLAoJQVRJIFJhZGVvbiBRRSAoQUdQKSwgQVRJIFJhZGVvbiBRRiAo QUdQKSwgQVRJIFJhZGVvbiBRRyAoQUdQKSwKCUFUSSBGaXJlR0wgODcwMC84ODAwIFFIIChB R1ApLCBBVEkgUmFkZW9uIDg1MDAgUUwgKEFHUCksCglBVEkgUmFkZW9uIDkxMDAgUU0gKEFH UCksIEFUSSBSYWRlb24gNzUwMCBRVyAoQUdQL1BDSSksCglBVEkgUmFkZW9uIDc1MDAgUVgg KEFHUC9QQ0kpLCBBVEkgUmFkZW9uIFZFLzcwMDAgUVkgKEFHUC9QQ0kpLAoJQVRJIFJhZGVv biBWRS83MDAwIFFaIChBR1AvUENJKSwgQVRJIEVTMTAwMCA1MTVFIChQQ0kpLAoJQVRJIFJh ZGVvbiBNb2JpbGl0eSBYMzAwIChNMjIpIDU0NjAgKFBDSUUpLAoJQVRJIFJhZGVvbiBNb2Jp bGl0eSBYNjAwIFNFIChNMjRDKSA1NDYyIChQQ0lFKSwKCUFUSSBGaXJlR0wgTTIyIEdMIDU0 NjQgKFBDSUUpLCBBVEkgUmFkZW9uIFg4MDAgKFI0MjMpIFVIIChQQ0lFKSwKCUFUSSBSYWRl b24gWDgwMFBSTyAoUjQyMykgVUkgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODAwTEUgKFI0MjMp IFVKIChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMFNFIChSNDIzKSBVSyAoUENJRSksCglBVEkg UmFkZW9uIFg4MDAgWFRQIChSNDMwKSAoUENJRSksIEFUSSBSYWRlb24gWDgwMCBYTCAoUjQz MCkgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODAwIFNFIChSNDMwKSAoUENJRSksIEFUSSBSYWRl b24gWDgwMCAoUjQzMCkgKFBDSUUpLAoJQVRJIEZpcmVHTCBWNzEwMCAoUjQyMykgKFBDSUUp LCBBVEkgRmlyZUdMIFY1MTAwIChSNDIzKSBVUSAoUENJRSksCglBVEkgRmlyZUdMIHVua25v d24gKFI0MjMpIFVSIChQQ0lFKSwKCUFUSSBGaXJlR0wgdW5rbm93biAoUjQyMykgVVQgKFBD SUUpLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTAwMCAoTTI2KSAoUENJRSksCglBVEkgTW9i aWxpdHkgRmlyZUdMIFY1MDAwIChNMjYpIChQQ0lFKSwKCUFUSSBNb2JpbGl0eSBSYWRlb24g WDcwMCBYTCAoTTI2KSAoUENJRSksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg3MDAgKE0yNikg KFBDSUUpLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYNzAwIChNMjYpIChQQ0lFKSwKCUFUSSBS YWRlb24gWDU1MFhUWCA1NjU3IChQQ0lFKSwgQVRJIFJhZGVvbiA5MTAwIElHUCAoQTUpIDU4 MzQsCglBVEkgUmFkZW9uIE1vYmlsaXR5IDkxMDAgSUdQIChVMykgNTgzNSwKCUFUSSBSYWRl b24gWFBSRVNTIDIwMCA1OTU0IChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwME0gNTk1 NSAoUENJRSksIEFUSSBSYWRlb24gOTI1MCA1OTYwIChBR1ApLAoJQVRJIFJhZGVvbiA5MjAw IDU5NjEgKEFHUCksIEFUSSBSYWRlb24gOTIwMCA1OTYyIChBR1ApLAoJQVRJIFJhZGVvbiA5 MjAwU0UgNTk2NCAoQUdQKSwgQVRJIEZpcmVNViAyMjAwIChQQ0kpLAoJQVRJIEVTMTAwMCA1 OTY5IChQQ0kpLCBBVEkgUmFkZW9uIFhQUkVTUyAyMDAgNTk3NCAoUENJRSksCglBVEkgUmFk ZW9uIFhQUkVTUyAyMDBNIDU5NzUgKFBDSUUpLAoJQVRJIFJhZGVvbiBYUFJFU1MgMjAwIDVB NDEgKFBDSUUpLAoJQVRJIFJhZGVvbiBYUFJFU1MgMjAwTSA1QTQyIChQQ0lFKSwKCUFUSSBS YWRlb24gWFBSRVNTIDIwMCA1QTYxIChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwME0g NUE2MiAoUENJRSksCglBVEkgUmFkZW9uIFgzMDAgKFJWMzcwKSA1QjYwIChQQ0lFKSwKCUFU SSBSYWRlb24gWDYwMCAoUlYzNzApIDVCNjIgKFBDSUUpLAoJQVRJIFJhZGVvbiBYNTUwIChS VjM3MCkgNUI2MyAoUENJRSksCglBVEkgRmlyZUdMIFYzMTAwIChSVjM3MCkgNUI2NCAoUENJ RSksCglBVEkgRmlyZU1WIDIyMDAgUENJRSAoUlYzNzApIDVCNjUgKFBDSUUpLAoJQVRJIFJh ZGVvbiBNb2JpbGl0eSA5MjAwIChNOSspIDVDNjEgKEFHUCksCglBVEkgUmFkZW9uIE1vYmls aXR5IDkyMDAgKE05KykgNUM2MyAoQUdQKSwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDgwMCBY VCAoTTI4KSAoUENJRSksCglBVEkgTW9iaWxpdHkgRmlyZUdMIFY1MTAwIChNMjgpIChQQ0lF KSwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDgwMCAoTTI4KSAoUENJRSksIEFUSSBSYWRlb24g WDg1MCA1RDRDIChQQ0lFKSwKCUFUSSBSYWRlb24gWDg1MCBYVCBQRSAoUjQ4MCkgKFBDSUUp LAoJQVRJIFJhZGVvbiBYODUwIFNFIChSNDgwKSAoUENJRSksIEFUSSBSYWRlb24gWDg1MCBQ Uk8gKFI0ODApIChQQ0lFKSwKCUFUSSB1bmtub3duIFJhZGVvbiAvIEZpcmVHTCAoUjQ4MCkg NUQ1MCAoUENJRSksCglBVEkgUmFkZW9uIFg4NTAgWFQgKFI0ODApIChQQ0lFKSwKCUFUSSBS YWRlb24gWDgwMFhUIChSNDIzKSA1RDU3IChQQ0lFKSwKCUFUSSBGaXJlR0wgVjUwMDAgKFJW NDEwKSAoUENJRSksIEFUSSBSYWRlb24gWDcwMCBYVCAoUlY0MTApIChQQ0lFKSwKCUFUSSBS YWRlb24gWDcwMCBQUk8gKFJWNDEwKSAoUENJRSksCglBVEkgUmFkZW9uIFg3MDAgU0UgKFJW NDEwKSAoUENJRSksIEFUSSBSYWRlb24gWDcwMCAoUlY0MTApIChQQ0lFKSwKCUFUSSBSYWRl b24gWDcwMCBTRSAoUlY0MTApIChQQ0lFKSwgQVRJIFJhZGVvbiBYMTgwMCwKCUFUSSBNb2Jp bGl0eSBSYWRlb24gWDE4MDAgWFQsIEFUSSBNb2JpbGl0eSBSYWRlb24gWDE4MDAsCglBVEkg TW9iaWxpdHkgRmlyZUdMIFY3MjAwLCBBVEkgRmlyZUdMIFY3MjAwLCBBVEkgRmlyZUdMIFY1 MzAwLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNzEwMCwgQVRJIFJhZGVvbiBYMTgwMCwgQVRJ IFJhZGVvbiBYMTgwMCwKCUFUSSBSYWRlb24gWDE4MDAsIEFUSSBSYWRlb24gWDE4MDAsIEFU SSBSYWRlb24gWDE4MDAsCglBVEkgRmlyZUdMIFY3MzAwLCBBVEkgRmlyZUdMIFY3MzUwLCBB VEkgUmFkZW9uIFgxNjAwLCBBVEkgUlY1MDUsCglBVEkgUmFkZW9uIFgxMzAwL1gxNTUwLCBB VEkgUmFkZW9uIFgxNTUwLCBBVEkgTTU0LUdMLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTQw MCwgQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwKCUFUSSBSYWRlb24gWDE1NTAgNjQtYml0LCBB VEkgTW9iaWxpdHkgUmFkZW9uIFgxMzAwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTMwMCwg QVRJIE1vYmlsaXR5IFJhZGVvbiBYMTMwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDEzMDAs IEFUSSBSYWRlb24gWDEzMDAsIEFUSSBSYWRlb24gWDEzMDAsCglBVEkgUlY1MDUsIEFUSSBS VjUwNSwgQVRJIEZpcmVHTCBWMzMwMCwgQVRJIEZpcmVHTCBWMzM1MCwKCUFUSSBSYWRlb24g WDEzMDAsIEFUSSBSYWRlb24gWDE1NTAgNjQtYml0LCBBVEkgUmFkZW9uIFgxMzAwL1gxNTUw LAoJQVRJIFJhZGVvbiBYMTYwMCwgQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwgQVRJIE1vYmls aXR5IFJhZGVvbiBYMTQ1MCwKCUFUSSBSYWRlb24gWDEzMDAvWDE1NTAsIEFUSSBNb2JpbGl0 eSBSYWRlb24gWDIzMDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgyMzAwLCBBVEkgTW9iaWxp dHkgUmFkZW9uIFgxMzUwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTM1MCwgQVRJIE1vYmls aXR5IFJhZGVvbiBYMTQ1MCwKCUFUSSBSYWRlb24gWDEzMDAsIEFUSSBSYWRlb24gWDE1NTAs IEFUSSBNb2JpbGl0eSBSYWRlb24gWDEzNTAsCglBVEkgRmlyZU1WIDIyNTAsIEFUSSBSYWRl b24gWDE1NTAgNjQtYml0LCBBVEkgUmFkZW9uIFgxNjAwLAoJQVRJIFJhZGVvbiBYMTY1MCwg QVRJIFJhZGVvbiBYMTYwMCwgQVRJIFJhZGVvbiBYMTYwMCwKCUFUSSBNb2JpbGl0eSBGaXJl R0wgVjUyMDAsIEFUSSBNb2JpbGl0eSBSYWRlb24gWDE2MDAsCglBVEkgUmFkZW9uIFgxNjUw LCBBVEkgUmFkZW9uIFgxNjUwLCBBVEkgUmFkZW9uIFgxNjAwLAoJQVRJIFJhZGVvbiBYMTMw MCBYVC9YMTYwMCBQcm8sIEFUSSBGaXJlR0wgVjM0MDAsCglBVEkgTW9iaWxpdHkgRmlyZUdM IFY1MjUwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNzAwLAoJQVRJIE1vYmlsaXR5IFJhZGVv biBYMTcwMCBYVCwgQVRJIEZpcmVHTCBWNTIwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDE3 MDAsIEFUSSBSYWRlb24gWDIzMDBIRCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMjMwMCwg QVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAyMzAwLAoJQVRJIFJhZGVvbiBYMTk1MCwgQVRJIFJh ZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTk1MCwKCUFUSSBSYWRlb24gWDE5MDAsIEFUSSBS YWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5MDAsCglBVEkgUmFkZW9uIFgxOTAwLCBBVEkg UmFkZW9uIFgxOTAwLCBBVEkgUmFkZW9uIFgxOTAwLAoJQVRJIFJhZGVvbiBYMTkwMCwgQVRJ IFJhZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTkwMCwKCUFUSSBBTUQgU3RyZWFtIFByb2Nl c3NvciwgQVRJIFJhZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTk1MCwKCUFUSSBSVjU2MCwg QVRJIFJWNTYwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxOTAwLCBBVEkgUlY1NjAsCglBVEkg UmFkZW9uIFgxOTUwIEdULCBBVEkgUlY1NzAsIEFUSSBSVjU3MCwgQVRJIEZpcmVHTCBWNzQw MCwKCUFUSSBSVjU2MCwgQVRJIFJhZGVvbiBYMTY1MCwgQVRJIFJhZGVvbiBYMTY1MCwgQVRJ IFJWNTYwLAoJQVRJIFJhZGVvbiA5MTAwIFBSTyBJR1AgNzgzNCwgQVRJIFJhZGVvbiBNb2Jp bGl0eSA5MjAwIElHUCA3ODM1LAoJQVRJIFJhZGVvbiBYMTIwMCwgQVRJIFJhZGVvbiBYMTIw MCwgQVRJIFJhZGVvbiBYMTIwMCwKCUFUSSBSYWRlb24gWDEyMDAsIEFUSSBSYWRlb24gWDEy MDAsIEFUSSBSUzc0MCwgQVRJIFJTNzQwTSwgQVRJIFJTNzQwLAoJQVRJIFJTNzQwTSwgQVRJ IFJhZGVvbiBIRCAyOTAwIFhULCBBVEkgUmFkZW9uIEhEIDI5MDAgWFQsCglBVEkgUmFkZW9u IEhEIDI5MDAgWFQsIEFUSSBSYWRlb24gSEQgMjkwMCBQcm8sIEFUSSBSYWRlb24gSEQgMjkw MCBHVCwKCUFUSSBGaXJlR0wgVjg2NTAsIEFUSSBGaXJlR0wgVjg2MDAsIEFUSSBGaXJlR0wg Vjc2MDAsCglBVEkgUmFkZW9uIDQ4MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDQ4NzAgeDIs CglBVEkgUmFkZW9uIDQ4MDAgU2VyaWVzLCBBVEkgRmlyZVBybyBWODc1MCAoRmlyZUdMKSwK CUFUSSBGaXJlUHJvIFY3NzYwIChGaXJlR0wpLCBBVEkgTW9iaWxpdHkgUkFERU9OIEhEIDQ4 NTAsCglBVEkgTW9iaWxpdHkgUkFERU9OIEhEIDQ4NTAgWDIsIEFUSSBSYWRlb24gNDgwMCBT ZXJpZXMsCglBVEkgRmlyZVBybyBSVjc3MCwgQU1EIEZpcmVTdHJlYW0gOTI3MCwgQU1EIEZp cmVTdHJlYW0gOTI1MCwKCUFUSSBGaXJlUHJvIFY4NzAwIChGaXJlR0wpLCBBVEkgTW9iaWxp dHkgUkFERU9OIEhEIDQ4NzAsCglBVEkgTW9iaWxpdHkgUkFERU9OIE05OCwgQVRJIEZpcmVQ cm8gTTc3NTAsIEFUSSBNOTgsIEFUSSBNOTgsCglBVEkgTTk4LCBBVEkgUmFkZW9uIFJWNzMw IChBR1ApLCBBVEkgRmlyZVBybyBNNTc1MCwKCUFUSSBSYWRlb24gUlY3MzAgKEFHUCksIEFU SSBSVjczMFhUIFtSYWRlb24gSEQgNDY3MF0sCglBVEkgUkFERU9OIEU0NjAwLCBBVEkgUlY3 MzAgUFJPIFtSYWRlb24gSEQgNDY1MF0sCglBVEkgRmlyZVBybyBWNzc1MCAoRmlyZUdMKSwg QVRJIEZpcmVQcm8gVjU3MDAgKEZpcmVHTCksCglBVEkgRmlyZVBybyBWMzc1MCAoRmlyZUdM KSwgQVRJIFJWNjEwLCBBVEkgUmFkZW9uIEhEIDI0MDAgWFQsCglBVEkgUmFkZW9uIEhEIDI0 MDAgUHJvLCBBVEkgUmFkZW9uIEhEIDI0MDAgUFJPIEFHUCwgQVRJIEZpcmVHTCBWNDAwMCwK CUFUSSBSVjYxMCwgQVRJIFJhZGVvbiBIRCAyMzUwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEhE IDI0MDAgWFQsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI0MDAsIEFUSSBSQURFT04gRTI0 MDAsIEFUSSBSVjYxMCwKCUFUSSBGaXJlTVYgMjI2MCwgQVRJIFJWNjcwLCBBVEkgUmFkZW9u IEhEMzg3MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg1MCwgQVRJIFJhZGVvbiBIRDM4 NTAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM4NTAgWDIsIEFUSSBSVjY3MCwKCUFUSSBN b2JpbGl0eSBSYWRlb24gSEQgMzg3MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzODcwIFgy LAoJQVRJIFJhZGVvbiBIRDM4NzAgWDIsIEFUSSBGaXJlR0wgVjc3MDAsIEFUSSBSYWRlb24g SEQzODUwLAoJQVRJIFJhZGVvbiBIRDM2OTAsIEFNRCBGaXJlc3RyZWFtIDkxNzAsIEFUSSBS YWRlb24gSEQgNDU1MCwKCUFUSSBSYWRlb24gUlY3MTAsIEFUSSBSYWRlb24gUlY3MTAsIEFU SSBSYWRlb24gSEQgNDM1MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gNDMwMCBTZXJpZXMsIEFU SSBNb2JpbGl0eSBSYWRlb24gNDUwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1 MDAgU2VyaWVzLCBBVEkgUlY2MzAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI2MDAsIEFU SSBNb2JpbGl0eSBSYWRlb24gSEQgMjYwMCBYVCwKCUFUSSBSYWRlb24gSEQgMjYwMCBYVCBB R1AsIEFUSSBSYWRlb24gSEQgMjYwMCBQcm8gQUdQLAoJQVRJIFJhZGVvbiBIRCAyNjAwIFhU LCBBVEkgUmFkZW9uIEhEIDI2MDAgUHJvLCBBVEkgR2VtaW5pIFJWNjMwLAoJQVRJIEdlbWlu aSBNb2JpbGl0eSBSYWRlb24gSEQgMjYwMCBYVCwgQVRJIEZpcmVHTCBWNTYwMCwKCUFUSSBG aXJlR0wgVjM2MDAsIEFUSSBSYWRlb24gSEQgMjYwMCBMRSwKCUFUSSBNb2JpbGl0eSBGaXJl R0wgR3JhcGhpY3MgUHJvY2Vzc29yLCBBVEkgUmFkZW9uIFJWNzEwLAoJQVRJIFJhZGVvbiBI RCAzNDcwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM0MzAsCglBVEkgTW9iaWxpdHkgUmFk ZW9uIEhEIDM0MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDM0NTAsCglBVEkgUmFkZW9uIEhE IDM0NTAsIEFUSSBSYWRlb24gSEQgMzQzMCwgQVRJIFJhZGVvbiBIRCAzNDUwLAoJQVRJIEZp cmVQcm8gVjM3MDAsIEFUSSBGaXJlTVYgMjQ1MCwgQVRJIEZpcmVNViAyMjYwLCBBVEkgRmly ZU1WIDIyNjAsCglBVEkgUmFkZW9uIEhEIDM2MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDM2 NTAgQUdQLAoJQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywgQVRJIFJhZGVvbiBIRCAzNjAwIFhU LAoJQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNjUw LAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNjcwLCBBVEkgTW9iaWxpdHkgRmlyZUdMIFY1 NzAwLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTcyNSwgQVRJIFJhZGVvbiBIRCAzMjAwIEdy YXBoaWNzLAoJQVRJIFJhZGVvbiAzMTAwIEdyYXBoaWNzLCBBVEkgUmFkZW9uIEhEIDMyMDAg R3JhcGhpY3MsCglBVEkgUmFkZW9uIDMxMDAgR3JhcGhpY3MsIEFUSSBSYWRlb24gSEQgMzMw MCBHcmFwaGljcwooSUkpIFZFU0E6IGRyaXZlciBmb3IgVkVTQSBjaGlwc2V0czogdmVzYQoo SUkpIFByaW1hcnkgRGV2aWNlIGlzOiBQQ0kgMDFAMDA6MDU6MAooSUkpIHJlc291cmNlIHJh bmdlcyBhZnRlciB4Zjg2Q2xhaW1GaXhlZFJlc291cmNlcygpIGNhbGw6CglbMF0gLTEJMAkw eDAwMTAwMDAwIC0gMHgzZmZmZmZmZiAoMHgzZmYwMDAwMCkgTVhbQl1FKEIpCglbMV0gLTEJ MAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4 MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAw MDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglbNF0gLTEJMAkweDAwMDBmZmZm IC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzVdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAw MDAwZmYgKDB4MTAwKSBJWFtCXQooV1cpIEZhbGxpbmcgYmFjayB0byBvbGQgcHJvYmUgbWV0 aG9kIGZvciB2ZXNhCihJSSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHByb2Jpbmc6CglbMF0g LTEJMAkweDAwMTAwMDAwIC0gMHgzZmZmZmZmZiAoMHgzZmYwMDAwMCkgTVhbQl1FKEIpCglb MV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAt MQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0xCTAJ MHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglbNF0gMAkwCTB4MDAw YTAwMDAgLSAweDAwMGFmZmZmICgweDEwMDAwKSBNU1tCXQoJWzVdIDAJMAkweDAwMGIwMDAw IC0gMHgwMDBiN2ZmZiAoMHg4MDAwKSBNU1tCXQoJWzZdIDAJMAkweDAwMGI4MDAwIC0gMHgw MDBiZmZmZiAoMHg4MDAwKSBNU1tCXQoJWzddIC0xCTAJMHgwMDAwZmZmZiAtIDB4MDAwMGZm ZmYgKDB4MSkgSVhbQl0KCVs4XSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEw MCkgSVhbQl0KCVs5XSAwCTAJMHgwMDAwMDNiMCAtIDB4MDAwMDAzYmIgKDB4YykgSVNbQl0K CVsxMF0gMAkwCTB4MDAwMDAzYzAgLSAweDAwMDAwM2RmICgweDIwKSBJU1tCXQooSUkpIFNl dHRpbmcgdmdhIGZvciBzY3JlZW4gMC4KKElJKSBSQURFT04oMCk6IFRPVE8gU0FZUyAwMDAw MDAwMGQwMjAwMDAwCihJSSkgUkFERU9OKDApOiBNTUlPIHJlZ2lzdGVycyBhdCAweDAwMDAw MDAwZDAyMDAwMDA6IHNpemUgNjRLQgooSUkpIFJBREVPTigwKTogUENJIGJ1cyAxIGNhcmQg NSBmdW5jIDAKKElJKSBSQURFT04oMCk6IENyZWF0aW5nIGRlZmF1bHQgRGlzcGxheSBzdWJz ZWN0aW9uIGluIFNjcmVlbiBzZWN0aW9uCgkiQnVpbHRpbiBEZWZhdWx0IGF0aSBTY3JlZW4g MCIgZm9yIGRlcHRoL2ZiYnBwIDI0LzMyCig9PSkgUkFERU9OKDApOiBEZXB0aCAyNCwgKD09 KSBmcmFtZWJ1ZmZlciBicHAgMzIKKElJKSBSQURFT04oMCk6IFBpeGVsIGRlcHRoID0gMjQg Yml0cyBzdG9yZWQgaW4gNCBieXRlcyAoMzIgYnBwIHBpeG1hcHMpCig9PSkgUkFERU9OKDAp OiBEZWZhdWx0IHZpc3VhbCBpcyBUcnVlQ29sb3IKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUg InZnYWh3IgooSUkpIExvYWRNb2R1bGU6ICJ2Z2FodyIKCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvL2xpYnZnYWh3LnNvCihJSSkgTW9kdWxlIHZnYWh3OiB2 ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS41LjMsIG1vZHVsZSB2 ZXJzaW9uID0gMC4xLjAKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9u IDQuMQooSUkpIFJBREVPTigwKTogdmdhSFdHZXRJT0Jhc2U6IGh3cC0+SU9CYXNlIGlzIDB4 MDNkMCwgaHdwLT5QSU9PZmZzZXQgaXMgMHgwMDAwCig9PSkgUkFERU9OKDApOiBSR0Igd2Vp Z2h0IDg4OAooSUkpIFJBREVPTigwKTogVXNpbmcgOCBiaXRzIHBlciBSR0IgKDggYml0IERB QykKKC0tKSBSQURFT04oMCk6IENoaXBzZXQ6ICJBVEkgUmFkZW9uIFgxMjAwIiAoQ2hpcElE ID0gMHg3OTFmKQooV1cpIFJBREVPTigwKTogUjUwMCBzdXBwb3J0IGlzIHVuZGVyIGRldmVs b3BtZW50LiBQbGVhc2UgcmVwb3J0IGFueSBpc3N1ZXMgdG8geG9yZy1kcml2ZXItYXRpQGxp c3RzLngub3JnCigtLSkgUkFERU9OKDApOiBMaW5lYXIgZnJhbWVidWZmZXIgYXQgMHgwMDAw MDAwMGMwMDAwMDAwCihJSSkgUkFERU9OKDApOiBQQ0kgY2FyZCBkZXRlY3RlZAooSUkpIExv YWRpbmcgc3ViIG1vZHVsZSAiaW50MTAiCihJSSkgTG9hZE1vZHVsZTogImludDEwIgoKKElJ KSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy8vbGliaW50MTAuc28KKElJ KSBNb2R1bGUgaW50MTA6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZv ciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNsYXNzOiBYLk9yZyBWaWRl byBEcml2ZXIsIHZlcnNpb24gNC4xCihJSSkgUkFERU9OKDApOiBpbml0aWFsaXppbmcgaW50 MTAKKD09KSBSQURFT04oMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHhhMDAwMCwweDIw MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweGMwMDAwLDB4NDAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgUkFERU9O KDApOiBQcmltYXJ5IFZfQklPUyBzZWdtZW50IGlzOiAweGMwMDAKKD09KSBSQURFT04oMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KElJKSBSQURFT04oMCk6IEFUT00gQklPUyBkZXRlY3RlZAooSUkpIFJBREVPTigwKTogQVRP TSBCSU9TIFJvbTogCglTdWJzeXN0ZW1WZW5kb3JJRDogMHgxMDAyIFN1YnN5c3RlbUlEOiAw eDc5MWYKCUlPQmFzZUFkZHJlc3M6IDB4NDAwMAoJRmlsZW5hbWU6IGJyMjgxNTIuYmluIAoJ QklPUyBCb290dXAgTWVzc2FnZTogDQpBVEkgUmFkZW9uIFhwcmVzcyA/MTI1MD8gZm9yIEhQ X1RUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoKKElJKSBS QURFT04oMCk6IEZyYW1lYnVmZmVyIHNwYWNlIHVzZWQgYnkgRmlybXdhcmUgKGtiKTogMjAK KElJKSBSQURFT04oMCk6IFN0YXJ0IG9mIFZSQU0gYXJlYSB1c2VkIGJ5IEZpcm13YXJlOiAw eDdmZmIwMDAKKElJKSBSQURFT04oMCk6IEF0b21CSU9TIHJlcXVlc3RzIDIwa0Igb2YgVlJB TSBzY3JhdGNoIHNwYWNlCihJSSkgUkFERU9OKDApOiBBdG9tQklPUyBWUkFNIHNjcmF0Y2gg YmFzZTogMHg3ZmZiMDAwCihJSSkgUkFERU9OKDApOiBDYW5ub3QgZ2V0IFZSQU0gc2NyYXRj aCBzcGFjZS4gQWxsb2NhdGluZyBpbiBtYWluIG1lbW9yeSBpbnN0ZWFkCihJSSkgUkFERU9O KDApOiBEZWZhdWx0IEVuZ2luZSBDbG9jazogNDAwMDAwCihJSSkgUkFERU9OKDApOiBEZWZh dWx0IE1lbW9yeSBDbG9jazogMjAwMDAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBpeGVs IENsb2NrUExMIEZyZXF1ZW5jeSBPdXRwdXQ6IDEyMDAwMDAKKElJKSBSQURFT04oMCk6IE1p bmltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJlcXVlbmN5IE91dHB1dDogMAooSUkpIFJBREVPTigw KTogTWF4aW11bSBQaXhlbCBDbG9ja1BMTCBGcmVxdWVuY3kgSW5wdXQ6IDEzNTAwCihJSSkg UkFERU9OKDApOiBNaW5pbXVtIFBpeGVsIENsb2NrUExMIEZyZXF1ZW5jeSBJbnB1dDogMTAw MAooSUkpIFJBREVPTigwKTogTWF4aW11bSBQaXhlbCBDbG9jazogNDAwMDAwCihJSSkgUkFE RU9OKDApOiBSZWZlcmVuY2UgQ2xvY2s6IDE0MzIwCmRybU9wZW5EZXZpY2U6IG5vZGUgbmFt ZSBpcyAvZGV2L2RyaS9jYXJkMApkcm1PcGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBpcyAtMSwg KE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0 IGlzIC0xLCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKZHJtT3BlbkRldmljZTogT3Bl biBmYWlsZWQKZHJtT3BlbkJ5QnVzaWQ6IFNlYXJjaGluZyBmb3IgQnVzSUQgcGNpOjAwMDA6 MDE6MDUuMApkcm1PcGVuRGV2aWNlOiBub2RlIG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJt T3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMgOCwgKE9LKQpkcm1PcGVuQnlCdXNpZDogZHJt T3Blbk1pbm9yIHJldHVybnMgOApkcm1PcGVuQnlCdXNpZDogZHJtR2V0QnVzaWQgcmVwb3J0 cyBwY2k6MDAwMDowMTowNS4wCihJSSkgUkFERU9OKDApOiBbZHJpXSBGb3VuZCBEUkkgbGli cmFyeSB2ZXJzaW9uIDEuMy4wIGFuZCBrZXJuZWwgbW9kdWxlIHZlcnNpb24gMS4yOS4wCig9 PSkgUkFERU9OKDApOiBQYWdlIEZsaXBwaW5nIGRpc2FibGVkIG9uIHI1eHggYW5kIG5ld2Vy IGNoaXBzLgoKKElJKSBSQURFT04oMCk6IFdpbGwgdHJ5IHRvIHVzZSBETUEgZm9yIFh2IGlt YWdlIHRyYW5zZmVycwooSUkpIFJBREVPTigwKTogR2VuZXJhdGlvbiAyIFBDSSBpbnRlcmZh Y2UsIHVzaW5nIG1heCBhY2Nlc3NpYmxlIG1lbW9yeQooSUkpIFJBREVPTigwKTogRGV0ZWN0 ZWQgdG90YWwgdmlkZW8gUkFNPTEzMTA3MkssIGFjY2Vzc2libGU9MTMxMDcySyAoUENJIEJB Uj0xMzEwNzJLKQooLS0pIFJBREVPTigwKTogTWFwcGVkIFZpZGVvUkFNOiAxMzEwNzIga0J5 dGUgKDEyOCBiaXQgRERSIFNEUkFNKQooSUkpIFJBREVPTigwKTogQ29sb3IgdGlsaW5nIGVu YWJsZWQgYnkgZGVmYXVsdAooSUkpIFJBREVPTigwKTogTWF4IGRlc2t0b3Agc2l6ZSBzZXQg dG8gMjU2MHgxNjAwCihJSSkgUkFERU9OKDApOiBGb3IgYSBsYXJnZXIgb3Igc21hbGxlciBt YXggZGVza3RvcCBzaXplLCBhZGQgYSBWaXJ0dWFsIGxpbmUgdG8geW91ciB4b3JnLmNvbmYK KElJKSBSQURFT04oMCk6IElmIHlvdSBhcmUgaGF2aW5nIHRyb3VibGUgd2l0aCAzRCwgcmVk dWNlIHRoZSBkZXNrdG9wIHNpemUgYnkgYWRqdXN0aW5nIHRoZSBWaXJ0dWFsIGxpbmUgdG8g eW91ciB4b3JnLmNvbmYKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImRkYyIKKElJKSBMb2Fk TW9kdWxlOiAiZGRjIgooSUkpIE1vZHVsZSAiZGRjIiBhbHJlYWR5IGJ1aWx0LWluCihJSSkg TG9hZGluZyBzdWIgbW9kdWxlICJpMmMiCihJSSkgTG9hZE1vZHVsZTogImkyYyIKKElJKSBN b2R1bGUgImkyYyIgYWxyZWFkeSBidWlsdC1pbgooSUkpIFJBREVPTigwKTogcmVmX2ZyZXE6 IDE0MzIsIG1pbl9vdXRfcGxsOiA2NDgwMCwgbWF4X291dF9wbGw6IDEyMDAwMCwgbWluX2lu X3BsbDogMTAwLCBtYXhfaW5fcGxsOiAxMzUwLCB4Y2xrOiA0MDAwMCwgc2NsazogNDAwLjAw MDAwMCwgbWNsazogMjAwLjAwMDAwMAooSUkpIFJBREVPTigwKTogUExMIHBhcmFtZXRlcnM6 IHJmPTE0MzIgcmQ9MTIgbWluPTY0ODAwIG1heD0xMjAwMDA7IHhjbGs9NDAwMDAKKFdXKSBS QURFT04oMCk6IExWRFMgSW5mbzoKWFJlczogMTI4MCwgWVJlczogODAwLCBEb3RDbG9jazog NjkzMDAKSEJsYW5rOiAxMzYsIEhPdmVyUGx1czogMTYsIEhTeW5jV2lkdGg6IDQ4ClZCbGFu azogMTYsIFZPdmVyUGx1czogMSwgVlN5bmNXaWR0aDogMwooSUkpIFJBREVPTigwKTogU2tp cHBpbmcgVFYtT3V0CihJSSkgUkFERU9OKDApOiBTa2lwcGluZyBDb21wb25lbnQgVmlkZW8K ZW5jb2RlcjogMHgxNQplbmNvZGVyOiAweGYKKElJKSBSQURFT04oMCk6IE91dHB1dCBWR0Et MCBoYXMgbm8gbW9uaXRvciBzZWN0aW9uCihJSSkgUkFERU9OKDApOiBJMkMgYnVzICJWR0Et MCIgaW5pdGlhbGl6ZWQuCihJSSkgUkFERU9OKDApOiBPdXRwdXQgTFZEUyBoYXMgbm8gbW9u aXRvciBzZWN0aW9uCihJSSkgUkFERU9OKDApOiBJMkMgYnVzICJMVkRTIiBpbml0aWFsaXpl ZC4KKElJKSBSQURFT04oMCk6IFBvcnQwOgogIFhSQU5EUiBuYW1lOiBWR0EtMAogIENvbm5l Y3RvcjogVkdBCiAgQ1JUMTogSU5URVJOQUxfS0xEU0NQX0RBQzEKICBEREMgcmVnOiAweDdl NTAKKElJKSBSQURFT04oMCk6IFBvcnQxOgogIFhSQU5EUiBuYW1lOiBMVkRTCiAgQ29ubmVj dG9yOiBMVkRTCiAgTENEMTogSU5URVJOQUxfTFZUTTEKICBEREMgcmVnOiAweDdlNDAKKElJ KSBSQURFT04oMCk6IEkyQyBkZXZpY2UgIlZHQS0wOmRkYzIiIHJlZ2lzdGVyZWQgYXQgYWRk cmVzcyAweEEwLgooSUkpIFJBREVPTigwKTogSTJDIGRldmljZSAiVkdBLTA6ZGRjMiIgcmVt b3ZlZC4KKElJKSBSQURFT04oMCk6IE91dHB1dDogVkdBLTAsIERldGVjdGVkIE1vbml0b3Ig VHlwZTogMApEYWMgZGV0ZWN0aW9uIHN1Y2Nlc3MKZmluaXNoZWQgb3V0cHV0IGRldGVjdDog MAooSUkpIFJBREVPTigwKTogSTJDIGRldmljZSAiTFZEUzpkZGMyIiByZWdpc3RlcmVkIGF0 IGFkZHJlc3MgMHhBMC4KKElJKSBSQURFT04oMCk6IEkyQyBkZXZpY2UgIkxWRFM6ZGRjMiIg cmVtb3ZlZC4KKElJKSBSQURFT04oMCk6IE91dHB1dDogTFZEUywgRGV0ZWN0ZWQgTW9uaXRv ciBUeXBlOiAwCmZpbmlzaGVkIG91dHB1dCBkZXRlY3Q6IDEKZmluaXNoZWQgYWxsIGRldGVj dApiZWZvcmUgeGY4NkluaXRpYWxDb25maWd1cmF0aW9uCihJSSkgUkFERU9OKDApOiBJMkMg ZGV2aWNlICJWR0EtMDpkZGMyIiByZWdpc3RlcmVkIGF0IGFkZHJlc3MgMHhBMC4KKElJKSBS QURFT04oMCk6IEkyQyBkZXZpY2UgIlZHQS0wOmRkYzIiIHJlbW92ZWQuCihJSSkgUkFERU9O KDApOiBPdXRwdXQ6IFZHQS0wLCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDAKRGFjIGRldGVj dGlvbiBzdWNjZXNzCihJSSkgUkFERU9OKDApOiBJMkMgZGV2aWNlICJMVkRTOmRkYzIiIHJl Z2lzdGVyZWQgYXQgYWRkcmVzcyAweEEwLgooSUkpIFJBREVPTigwKTogSTJDIGRldmljZSAi TFZEUzpkZGMyIiByZW1vdmVkLgooSUkpIFJBREVPTigwKTogT3V0cHV0OiBMVkRTLCBEZXRl Y3RlZCBNb25pdG9yIFR5cGU6IDAKKElJKSBSQURFT04oMCk6IFF1ZXJ5IGZvciBBdG9tQklP UyBHZXQgUGFuZWwgRURJRDogZmFpbGVkCihJSSkgUkFERU9OKDApOiBBZGRlZCBuYXRpdmUg cGFuZWwgbW9kZTogMTI4MHg4MDAKKElJKSBSQURFT04oMCk6IE91dHB1dCBWR0EtMCBkaXNj b25uZWN0ZWQKKElJKSBSQURFT04oMCk6IE91dHB1dCBMVkRTIGNvbm5lY3RlZAooSUkpIFJB REVPTigwKTogVXNpbmcgZXhhY3Qgc2l6ZXMgZm9yIGluaXRpYWwgbW9kZXMKKElJKSBSQURF T04oMCk6IE91dHB1dCBMVkRTIHVzaW5nIGluaXRpYWwgbW9kZSAxMjgweDgwMAphZnRlciB4 Zjg2SW5pdGlhbENvbmZpZ3VyYXRpb24KKD09KSBSQURFT04oMCk6IERQSSBzZXQgdG8gKDk2 LCA5NikKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImZiIgooSUkpIExvYWRNb2R1bGU6ICJm YiIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvL2xpYmZiLnNv CihJSSkgTW9kdWxlIGZiOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS41LjMsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgQU5T SSBDIEVtdWxhdGlvbiwgdmVyc2lvbiAwLjQKKD09KSBSQURFT04oMCk6IFVzaW5nIGdhbW1h IGNvcnJlY3Rpb24gKDEuMCwgMS4wLCAxLjApCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJy YW1kYWMiCihJSSkgTG9hZE1vZHVsZTogInJhbWRhYyIKKElJKSBNb2R1bGUgInJhbWRhYyIg YWxyZWFkeSBidWlsdC1pbgooPT0pIFJBREVPTigwKTogVXNpbmcgWEFBIGFjY2VsZXJhdGlv biBhcmNoaXRlY3R1cmUKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgInhhYSIKKElJKSBMb2Fk TW9kdWxlOiAieGFhIgoKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxl cy8vbGlieGFhLnNvCihJSSkgTW9kdWxlIHhhYTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9u IgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMi4wCglBQkkgY2xh c3M6IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiA0LjEKKD09KSBSQURFT04oMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKCEh KSBSQURFT04oMCk6IEZvciBpbmZvcm1hdGlvbiBvbiB1c2luZyB0aGUgbXVsdGltZWRpYSBj YXBhYmlsaXRpZXMKCW9mIHRoaXMgYWRhcHRlciwgcGxlYXNlIHNlZSBodHRwOi8vZ2F0b3Mu c2YubmV0LgooISEpIFJBREVPTigwKTogTWVyZ2VkRkIgc3VwcG9ydCBoYXMgYmVlbiByZW1v dmVkIGFuZCByZXBsYWNlZCB3aXRoIHhyYW5kciAxLjIgc3VwcG9ydAooSUkpIFVubG9hZE1v ZHVsZTogInZlc2EiCihJSSkgVW5sb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxl cy9kcml2ZXJzLy92ZXNhX2Rydi5zbwooLS0pIERlcHRoIDI0IHBpeG1hcCBmb3JtYXQgaXMg MzIgYnBwCihJSSkgZG8gSSBuZWVkIFJBQz8gIE5vLCBJIGRvbid0LgooSUkpIHJlc291cmNl IHJhbmdlcyBhZnRlciBwcmVJbml0OgoJWzBdIC0xCTAJMHgwMDEwMDAwMCAtIDB4M2ZmZmZm ZmYgKDB4M2ZmMDAwMDApIE1YW0JdRShCKQoJWzFdIC0xCTAJMHgwMDBmMDAwMCAtIDB4MDAw ZmZmZmYgKDB4MTAwMDApIE1YW0JdCglbMl0gLTEJMAkweDAwMGMwMDAwIC0gMHgwMDBlZmZm ZiAoMHgzMDAwMCkgTVhbQl0KCVszXSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDlmZmZmICgw eGEwMDAwKSBNWFtCXQoJWzRdIDAJMAkweDAwMGEwMDAwIC0gMHgwMDBhZmZmZiAoMHgxMDAw MCkgTVNbQl0oT3ByVSkKCVs1XSAwCTAJMHgwMDBiMDAwMCAtIDB4MDAwYjdmZmYgKDB4ODAw MCkgTVNbQl0oT3ByVSkKCVs2XSAwCTAJMHgwMDBiODAwMCAtIDB4MDAwYmZmZmYgKDB4ODAw MCkgTVNbQl0oT3ByVSkKCVs3XSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBmZmZmICgweDEp IElYW0JdCglbOF0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDBmZiAoMHgxMDApIElYW0Jd CglbOV0gMAkwCTB4MDAwMDAzYjAgLSAweDAwMDAwM2JiICgweGMpIElTW0JdKE9wclUpCglb MTBdIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAoMHgyMCkgSVNbQl0oT3ByVSkKKElJ KSBSQURFT04oMCk6IFJBREVPTlNjcmVlbkluaXQgYzAwMDAwMDAgMCAwCig9PSkgUkFERU9O KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YTAwMDAsMHgxMDAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKT3V0cHV0IExDRDEgZGlzYWJsZSBzdWNjZXNzCkJsYW5rIENSVEMgMCBzdWNj ZXNzCkRpc2FibGUgQ1JUQyAwIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAxIHN1Y2Nlc3MKRGlzYWJs ZSBDUlRDIDEgc3VjY2VzcwooPT0pIFJBREVPTigwKTogVXNpbmcgMjQgYml0IGRlcHRoIGJ1 ZmZlcgooSUkpIFJBREVPTigwKTogUkFERU9OSW5pdE1lbW9yeU1hcCgpIDogCihJSSkgUkFE RU9OKDApOiAgIG1lbV9zaXplICAgICAgICAgOiAweDA4MDAwMDAwCihJSSkgUkFERU9OKDAp OiAgIE1DX0ZCX0xPQ0FUSU9OICAgOiAweDdmZmY3ODAwCihJSSkgUkFERU9OKDApOiAgIE1D X0FHUF9MT0NBVElPTiAgOiAweDAwM2YwMDAwCihJSSkgUkFERU9OKDApOiBEZXB0aCBtb3Zl cyBkaXNhYmxlZCBieSBkZWZhdWx0CihJSSkgUkFERU9OKDApOiBVc2luZyAzMiBNQiBHQVJU IGFwZXJ0dXJlCihJSSkgUkFERU9OKDApOiBVc2luZyAxIE1CIGZvciB0aGUgcmluZyBidWZm ZXIKKElJKSBSQURFT04oMCk6IFVzaW5nIDIgTUIgZm9yIHZlcnRleC9pbmRpcmVjdCBidWZm ZXJzCihJSSkgUkFERU9OKDApOiBVc2luZyAyOSBNQiBmb3IgR0FSVCB0ZXh0dXJlcwooSUkp IFJBREVPTigwKTogTWVtb3J5IG1hbmFnZXIgaW5pdGlhbGl6ZWQgdG8gKDAsMCkgKDEyODAs ODE5MSkKKElJKSBSQURFT04oMCk6IFJlc2VydmVkIGFyZWEgZnJvbSAoMCwxMjgwKSB0byAo MTI4MCwxMjgyKQooSUkpIFJBREVPTigwKTogTGFyZ2VzdCBvZmZzY3JlZW4gYXJlYSBhdmFp bGFibGU6IDEyODAgeCA2OTA5CihJSSkgUkFERU9OKDApOiBXaWxsIHVzZSBmcm9udCBidWZm ZXIgYXQgb2Zmc2V0IDB4MAooSUkpIFJBREVPTigwKTogV2lsbCB1c2UgYmFjayBidWZmZXIg YXQgb2Zmc2V0IDB4MTk3ODAwMAooSUkpIFJBREVPTigwKTogV2lsbCB1c2UgZGVwdGggYnVm ZmVyIGF0IG9mZnNldCAweDFmYjgwMDAKKElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDkyMTYw IGtiIGZvciB0ZXh0dXJlcyBhdCBvZmZzZXQgMHgyNWY4MDAwCmRybU9wZW5EZXZpY2U6IG5v ZGUgbmFtZSBpcyAvZGV2L2RyaS9jYXJkMApkcm1PcGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBp cyA4LCAoT0spCmRybU9wZW5EZXZpY2U6IG5vZGUgbmFtZSBpcyAvZGV2L2RyaS9jYXJkMApk cm1PcGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBpcyA4LCAoT0spCmRybU9wZW5CeUJ1c2lkOiBT ZWFyY2hpbmcgZm9yIEJ1c0lEIHBjaTowMDAwOjAxOjA1LjAKZHJtT3BlbkRldmljZTogbm9k ZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlz IDgsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IGRybU9wZW5NaW5vciByZXR1cm5zIDgKZHJtT3Bl bkJ5QnVzaWQ6IGRybUdldEJ1c2lkIHJlcG9ydHMgcGNpOjAwMDA6MDE6MDUuMAooSUkpIFtk cm1dIERSTSBpbnRlcmZhY2UgdmVyc2lvbiAxLjIKKElJKSBbZHJtXSBEUk0gb3BlbiBtYXN0 ZXIgc3VjY2VlZGVkLgooSUkpIFJBREVPTigwKTogW2RybV0gVXNpbmcgdGhlIERSTSBsb2Nr IFNBUkVBIGFsc28gZm9yIGRyYXdhYmxlcy4KKElJKSBSQURFT04oMCk6IFtkcm1dIGZyYW1l YnVmZmVyIGhhbmRsZSA9IDB4YzAwMDAwMDAKKElJKSBSQURFT04oMCk6IFtkcm1dIGFkZGVk IDEgcmVzZXJ2ZWQgY29udGV4dCBmb3Iga2VybmVsCihJSSkgUkFERU9OKDApOiBYIGNvbnRl eHQgaGFuZGxlID0gMHgxCihJSSkgUkFERU9OKDApOiBbZHJtXSBpbnN0YWxsZWQgRFJNIHNp Z25hbCBoYW5kbGVyCihJSSkgUkFERU9OKDApOiBbcGNpXSAzMjc2OCBrQiBhbGxvY2F0ZWQg d2l0aCBoYW5kbGUgMHg3YzcxYTAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gcmluZyBoYW5k bGUgPSAweDdjNzFhMDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSBSaW5nIG1hcHBlZCBhdCAw eDgwMjc1MjAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gUmluZyBjb250ZW50cyAweDAwMDAw MDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSByaW5nIHJlYWQgcHRyIGhhbmRsZSA9IDB4N2M4 MWIwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFJpbmcgcmVhZCBwdHIgbWFwcGVkIGF0IDB4 ODAwNmMwMDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSBSaW5nIHJlYWQgcHRyIGNvbnRlbnRz IDB4MDAwMDAwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIHZlcnRleC9pbmRpcmVjdCBidWZm ZXJzIGhhbmRsZSA9IDB4N2M4MWMwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFZlcnRleC9p bmRpcmVjdCBidWZmZXJzIG1hcHBlZCBhdCAweDgwYjAwMDAwMAooSUkpIFJBREVPTigwKTog W3BjaV0gVmVydGV4L2luZGlyZWN0IGJ1ZmZlcnMgY29udGVudHMgMHgwMDAwMDAwMAooSUkp IFJBREVPTigwKTogW3BjaV0gR0FSVCB0ZXh0dXJlIG1hcCBoYW5kbGUgPSAweDdjYTFjMDAw CihJSSkgUkFERU9OKDApOiBbcGNpXSBHQVJUIFRleHR1cmUgbWFwIG1hcHBlZCBhdCAweDgw YjIxYzAwMAooSUkpIFJBREVPTigwKTogW2RybV0gcmVnaXN0ZXIgaGFuZGxlID0gMHhkMDIw MDAwMAooSUkpIFJBREVPTigwKTogW2RyaV0gVmlzdWFsIGNvbmZpZ3MgaW5pdGlhbGl6ZWQK KElJKSBSQURFT04oMCk6IFJBREVPTlJlc3RvcmVNZW1NYXBSZWdpc3RlcnMoKSA6IAooSUkp IFJBREVPTigwKTogICBNQ19GQl9MT0NBVElPTiAgIDogMHg3ZmZmNzgwMCAweDdmZmY3ODAw CihJSSkgUkFERU9OKDApOiAgIE1DX0FHUF9MT0NBVElPTiAgOiAweDAwM2YwMDAwCig9PSkg UkFERU9OKDApOiBCYWNraW5nIHN0b3JlIGRpc2FibGVkCihJSSkgUkFERU9OKDApOiBbRFJJ XSBpbnN0YWxsYXRpb24gY29tcGxldGUKKElJKSBSQURFT04oMCk6IFtkcm1dIEFkZGVkIDMy IDY1NTM2IGJ5dGUgdmVydGV4L2luZGlyZWN0IGJ1ZmZlcnMKKElJKSBSQURFT04oMCk6IFtk cm1dIE1hcHBlZCAzMiB2ZXJ0ZXgvaW5kaXJlY3QgYnVmZmVycwooSUkpIFJBREVPTigwKTog W2RybV0gZG1hIGNvbnRyb2wgaW5pdGlhbGl6ZWQsIHVzaW5nIElSUSAyNTcKKElJKSBSQURF T04oMCk6IFtkcm1dIEluaXRpYWxpemVkIGtlcm5lbCBHQVJUIGhlYXAgbWFuYWdlciwgMjk4 ODQ0MTYKKFdXKSBSQURFT04oMCk6IERSSSBpbml0IGNoYW5nZWQgbWVtb3J5IG1hcCwgYWRq dXN0aW5nIC4uLgooV1cpIFJBREVPTigwKTogICBNQ19GQl9MT0NBVElPTiAgd2FzOiAweDdm ZmY3ODAwIGlzOiAweDdmZmY3ODAwCihXVykgUkFERU9OKDApOiAgIE1DX0FHUF9MT0NBVElP TiB3YXM6IDB4MDAzZjAwMDAgaXM6IDB4ODFmZjgwMDAKKElJKSBSQURFT04oMCk6IFJBREVP TlJlc3RvcmVNZW1NYXBSZWdpc3RlcnMoKSA6IAooSUkpIFJBREVPTigwKTogICBNQ19GQl9M T0NBVElPTiAgIDogMHg3ZmZmNzgwMCAweDdmZmY3ODAwCihJSSkgUkFERU9OKDApOiAgIE1D X0FHUF9MT0NBVElPTiAgOiAweDgxZmY4MDAwCihJSSkgUkFERU9OKDApOiBEaXJlY3QgcmVu ZGVyaW5nIGVuYWJsZWQKKElJKSBSQURFT04oMCk6IFhBQSBSZW5kZXIgYWNjZWxlcmF0aW9u IHVuc3VwcG9ydGVkIG9uIFJhZGVvbiA5NTAwLzk3MDAgYW5kIG5ld2VyLiBQbGVhc2UgdXNl IEVYQSBpbnN0ZWFkLgooSUkpIFJBREVPTigwKTogUmVuZGVyIGFjY2VsZXJhdGlvbiBkaXNh YmxlZAooSUkpIFJBREVPTigwKTogbnVtIHF1YWQtcGlwZXMgaXMgMQooSUkpIFJBREVPTigw KTogVXNpbmcgWEZyZWU4NiBBY2NlbGVyYXRpb24gQXJjaGl0ZWN0dXJlIChYQUEpCglTY3Jl ZW4gdG8gc2NyZWVuIGJpdCBibGl0cwoJU29saWQgZmlsbGVkIHJlY3RhbmdsZXMKCTh4OCBt b25vIHBhdHRlcm4gZmlsbGVkIHJlY3RhbmdsZXMKCUluZGlyZWN0IENQVSB0byBTY3JlZW4g Y29sb3IgZXhwYW5zaW9uCglTb2xpZCBMaW5lcwoJU2NhbmxpbmUgSW1hZ2UgV3JpdGVzCglT ZXR0aW5nIHVwIHRpbGUgYW5kIHN0aXBwbGUgY2FjaGU6CgkJMzIgMTI4eDEyOCBzbG90cwoJ CTMyIDI1NngyNTYgc2xvdHMKCQkxNiA1MTJ4NTEyIHNsb3RzCihJSSkgUkFERU9OKDApOiBB Y2NlbGVyYXRpb24gZW5hYmxlZAooSUkpIFJBREVPTigwKTogRFBNUyBlbmFibGVkCig9PSkg UkFERU9OKDApOiBTaWxrZW4gbW91c2UgZW5hYmxlZAooSUkpIFJBREVPTigwKTogV2lsbCB1 c2UgMzIga2IgZm9yIGhhcmR3YXJlIGN1cnNvciAwIGF0IG9mZnNldCAweDAwNjQzMDAwCihJ SSkgUkFERU9OKDApOiBXaWxsIHVzZSAzMiBrYiBmb3IgaGFyZHdhcmUgY3Vyc29yIDEgYXQg b2Zmc2V0IDB4MDA2NDgwMDAKKElJKSBSQURFT04oMCk6IExhcmdlc3Qgb2Zmc2NyZWVuIGFy ZWEgYXZhaWxhYmxlOiAxMjgwIHggNjkwMQooSUkpIFJBREVPTigwKTogU2V0IHVwIHRleHR1 cmVkIHZpZGVvCk91dHB1dCBDUlQxIGRpc2FibGUgc3VjY2VzcwpPdXRwdXQgTENEMSBkaXNh YmxlIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAwIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDAgc3VjY2Vz cwpCbGFuayBDUlRDIDEgc3VjY2VzcwpEaXNhYmxlIENSVEMgMSBzdWNjZXNzCg== --------------000407070504010200060901 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="pciconf.txt" aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgzMGMyMTAzYyBjaGlw PTB4NzkxMDEwMDIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQVRJIFRl Y2hub2xvZ2llcyBJbmMnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAg ID0gSE9TVC1QQ0kKcGNpYjFAcGNpMDowOjE6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDMw YzIxMDNjIGNoaXA9MHg3OTEyMTAwMiByZXY9MHgwMCBoZHI9MHgwMQogICAgdmVuZG9yICAg ICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAg IHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWIyQHBjaTA6MDo0OjA6CWNsYXNzPTB4MDYwNDAw IGNhcmQ9MHgzMGMyMTAzYyBjaGlwPTB4NzkxNDEwMDIgcmV2PTB4MDAgaGRyPTB4MDEKICAg IHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnCiAgICBjbGFzcyAgICAgID0g YnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liM0BwY2kwOjA6NTowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4MzBjMjEwM2MgY2hpcD0weDc5MTUxMDAyIHJldj0weDAwIGhk cj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjRAcGNpMDow OjY6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDMwYzIxMDNjIGNoaXA9MHg3OTE2MTAwMiBy ZXY9MHgwMCBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIElu YycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmF0 YXBjaTBAcGNpMDowOjE4OjA6CWNsYXNzPTB4MDEwMThmIGNhcmQ9MHg0MzgwMTAwMiBjaGlw PTB4NDM4MDEwMDIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQVRJIFRl Y2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ0lYUCBTQjYwMCBTZXJpYWwgQVRB IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFz cyAgID0gQVRBCm9oY2kwQHBjaTA6MDoxOTowOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4MzBj MjEwM2MgY2hpcD0weDQzODcxMDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAg ID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJWFAgU0I2MDAg VVNCIENvbnRyb2xsZXIgKE9IQ0kwKScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAg ICBzdWJjbGFzcyAgID0gVVNCCm9oY2kxQHBjaTA6MDoxOToxOgljbGFzcz0weDBjMDMxMCBj YXJkPTB4MzBjMjEwM2MgY2hpcD0weDQzODgxMDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2 ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJ WFAgU0I2MDAgVVNCIENvbnRyb2xsZXIgKE9IQ0kxKScKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm9oY2kyQHBjaTA6MDoxOToyOgljbGFzcz0w eDBjMDMxMCBjYXJkPTB4MzBjMjEwM2MgY2hpcD0weDQzODkxMDAyIHJldj0weDAwIGhkcj0w eDAwCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNl ICAgICA9ICdJWFAgU0I2MDAgVVNCIENvbnRyb2xsZXIgKE9IQ0kyKScKICAgIGNsYXNzICAg ICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm9oY2kzQHBjaTA6MDoxOToz OgljbGFzcz0weDBjMDMxMCBjYXJkPTB4MzBjMjEwM2MgY2hpcD0weDQzOGExMDAyIHJldj0w eDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwog ICAgZGV2aWNlICAgICA9ICdJWFAgU0I2MDAgVVNCIENvbnRyb2xsZXIgKE9IQ0kzKScKICAg IGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm9oY2k0QHBj aTA6MDoxOTo0OgljbGFzcz0weDBjMDMxMCBjYXJkPTB4MzBjMjEwM2MgY2hpcD0weDQzOGIx MDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dp ZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJWFAgU0I2MDAgVVNCIENvbnRyb2xsZXIgKE9I Q0k0KScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNC CmVoY2kwQHBjaTA6MDoxOTo1OgljbGFzcz0weDBjMDMyMCBjYXJkPTB4MzBjMjEwM2MgY2hp cD0weDQzODYxMDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBU ZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJWFAgU0I2MDAgVVNCIENvbnRy b2xsZXIgKEVIQ0kpJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNz ICAgPSBVU0IKbm9uZTBAcGNpMDowOjIwOjA6CWNsYXNzPTB4MGMwNTAwIGNhcmQ9MHgzMGMy MTAzYyBjaGlwPTB4NDM4NTEwMDIgcmV2PTB4MTQgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ0lYUCBTQjYwMCBT TUJVUyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNs YXNzICAgPSBTTUJ1cwphdGFwY2kxQHBjaTA6MDoyMDoxOgljbGFzcz0weDAxMDE4MiBjYXJk PTB4MzBjMjEwM2MgY2hpcD0weDQzOGMxMDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJWFAg U0I2MDAgQVRBIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAg ICBzdWJjbGFzcyAgID0gQVRBCmhkYWMwQHBjaTA6MDoyMDoyOgljbGFzcz0weDA0MDMwMCBj YXJkPTB4MzBjMjEwM2MgY2hpcD0weDQzODMxMDAyIHJldj0weDAwIGhkcj0weDAwCiAgICB2 ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdJ WFAgU0I2MDAgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXInCiAgICBjbGFzcyAg ICAgID0gbXVsdGltZWRpYQogICAgc3ViY2xhc3MgICA9IEhEQQppc2FiMEBwY2kwOjA6MjA6 MzoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDMwYzIxMDNjIGNoaXA9MHg0MzhkMTAwMiByZXY9 MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycK ICAgIGRldmljZSAgICAgPSAnSVhQIFNCNjAwIFBDSSB0byBMUEMgQnJpZGdlJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1JU0EKcGNpYjVAcGNpMDow OjIwOjQ6CWNsYXNzPTB4MDYwNDAxIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NDM4NDEwMDIg cmV2PTB4MDAgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJ bmMnCiAgICBkZXZpY2UgICAgID0gJ0lYUCBTQjYwMCBQQ0kgdG8gUENJIEJyaWRnZScKICAg IGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmhvc3RiMUBw Y2kwOjA6MjQ6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAw MTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNy byBEZXZpY2VzIChBTUQpJwogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRl cm9uIEh5cGVyVHJhbnNwb3J0IFRlY2hub2xvZ3kgQ29uZmlndXJhdGlvbicKICAgIGNsYXNz ICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjJAcGNpMDow OjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMTEwMjIg cmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2 aWNlcyAoQU1EKScKICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBB ZGRyZXNzIE1hcCcKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBI T1NULVBDSQpob3N0YjNAcGNpMDowOjI0OjI6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAw MDAwMCBjaGlwPTB4MTEwMjEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgICAgPSAnKEs4 KSBBdGhsb24gNjQvT3B0ZXJvbiBEUkFNIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0g YnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGI0QHBjaTA6MDoyNDozOglj bGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJldj0weDAw IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFN RCknCiAgICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0L09wdGVyb24gTWlzY2VsbGFu ZW91cyBDb250cm9sJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9 IEhPU1QtUENJCnZnYXBjaTBAcGNpMDoxOjU6MDoJY2xhc3M9MHgwMzAwMDAgY2FyZD0weDMw YzIxMDNjIGNoaXA9MHg3OTFmMTAwMiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAg ICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycKICAgIGRldmljZSAgICAgPSAnUlM2OTAgQVRJ IE1vYmlsaXR5IFJhZGVvbiB4MTI1MCcKICAgIGNsYXNzICAgICAgPSBkaXNwbGF5CiAgICBz dWJjbGFzcyAgID0gVkdBCmJnZTBAcGNpMDoxNjowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHgzMGMyMTAzYyBjaGlwPTB4MTcxMzE0ZTQgcmV2PTB4MDIgaGRyPTB4MDAKICAgIHZlbmRv ciAgICAgPSAnQnJvYWRjb20gQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ05ldExp bmsgQkNNNTkwNk0gRmFzdCBFdGhlcm5ldCBQQ0llJwogICAgY2xhc3MgICAgICA9IG5ldHdv cmsKICAgIHN1YmNsYXNzICAgPSBldGhlcm5ldApub25lMUBwY2kwOjQ4OjA6MDoJY2xhc3M9 MHgwMjgwMDAgY2FyZD0weDEzNzExMDNjIGNoaXA9MHg0MzEyMTRlNCByZXY9MHgwMiBoZHI9 MHgwMAogICAgdmVuZG9yICAgICA9ICdCcm9hZGNvbSBDb3Jwb3JhdGlvbicKICAgIGRldmlj ZSAgICAgPSAnQkNNNDMxMCBicm9hZGNvbSB3aXJlbGVzcyAxNDkwIChkZWxsKScKICAgIGNs YXNzICAgICAgPSBuZXR3b3JrCmNiYjBAcGNpMDoyOjQ6MDoJY2xhc3M9MHgwNjA3MDAgY2Fy ZD0weDMwYzIxMDNjIGNoaXA9MHgwNDc2MTE4MCByZXY9MHhiNiBoZHI9MHgwMgogICAgdmVu ZG9yICAgICA9ICdSaWNvaCBDb21wYW55LCBMdGQuJwogICAgZGV2aWNlICAgICA9ICd1bmtu b3duIFJpY29oIFIvUkwvNUM0NzYoSUkpJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgICA9IFBDSS1DYXJkQnVzCg== --------------000407070504010200060901 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0ClRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEu IEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFy ayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDguMC1DVVJSRU5UICMwOiBT dW4gTWFyIDIyIDE0OjUyOjQ3IE1TSyAyMDA5Cmxpc3N5YXJhQEhQLmxpc3N5YXJhLnN1Oi91 c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5h YmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClRpbWVjb3VudGVyICJpODI1NCIg ZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogQU1EIFR1cmlvbih0bSkgNjQg WDIgTW9iaWxlIFRlY2hub2xvZ3kgVEwtNjAgKDE5OTQuOTMtTUh6IEs4LWNsYXNzIENQVSkK T3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHg2MGY4MiAgU3RlcHBpbmcgPSAyCkZl YXR1cmVzPTB4MTc4YmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxB UElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxNTVgsRlhTUixT U0UsU1NFMixIVFQ+CkZlYXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgpBTUQgRmVhdHVyZXM9 MHhlYTUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsUkRUU0NQLExNLDNETm93ISssM0RO b3chPgpBTUQgRmVhdHVyZXMyPTB4MTFmPExBSEYsQ01QLFNWTSxFeHRBUElDLENSOCxQcmVm ZXRjaD4KQ29yZXMgcGVyIHBhY2thZ2U6IDIKdXNhYmxlIG1lbW9yeSA9IDE5OTU2MDgwNjQg KDE5MDMgTUIpCmF2YWlsIG1lbW9yeSAgPSAxOTI3MjIxMjQ4ICgxODM3IE1CKQpBQ1BJIEFQ SUMgVGFibGU6IDxIUCAgICAgMDk0NCAgICA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3Nv ciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpjcHUwIChCU1ApOiBBUElDIElEOiAgMApjcHUx IChBUCk6IEFQSUMgSUQ6ICAxCkFDUEkgRXJyb3IgKHRiZmFkdC0wNTE2KTogMzIvNjRYIGFk ZHJlc3MgbWlzbWF0Y2ggaW4gIlBtMkNvbnRyb2xCbG9jayI6IFsgICAgODgwMF0gWyAgICAg ICAwICAgIDgxMDBdLCB1c2luZyA2NFggWzIwMDcwMzIwXQppb2FwaWMwOiBDaGFuZ2luZyBB UElDIElEIHRvIDIKaW9hcGljMCA8VmVyc2lvbiAyLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJi b2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxIUFFPRU0gU0xJQy1NUEM+IG9uIG1vdGhl cmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCnVu a25vd246IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAw LCA4MDAwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgZmZm MDAwMDAgKDMpIGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3 OTU0NSBIeiBxdWFsaXR5IDg1MAphY3BpX3RpbWVyMDogPDMyLWJpdCB0aW1lciBhdCAzLjU3 OTU0NU1Iej4gcG9ydCAweDgwMDgtMHg4MDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRk ZWQgQ29udHJvbGxlcjogR1BFIDB4MTE+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEK dmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg0MDAwLTB4NDBmZiBt ZW0gMHhjMDAwMDAwMC0weGM3ZmZmZmZmLDB4ZDAyMDAwMDAtMHhkMDIwZmZmZiwweGQwMzAw MDAwLTB4ZDAzZmZmZmYgaXJxIDE5IGF0IGRldmljZSA1LjAgb24gcGNpMQpwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMApwY2kxNjogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjIKYmdlMDogPEJyb2FkY29tIEJDTTU5MDYgQTIsIEFTSUMgcmV2 LiAweGMwMDI+IG1lbSAweGQwMDAwMDAwLTB4ZDAwMGZmZmYgaXJxIDE2IGF0IGRldmljZSAw LjAgb24gcGNpMTYKbWlpYnVzMDogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MDogPEJDTTU5 MDYgMTAvMTAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMApicmdwaHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpiZ2UwOiBF dGhlcm5ldCBhZGRyZXNzOiAwMDoxZjoyOTo4OTozODpmMwpiZ2UwOiBbSVRIUkVBRF0KcGNp YjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNS4wIG9uIHBjaTAKcGNpMzI6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDYuMCBvbiBwY2kwCnBjaTQ4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApw Y2k0ODogPG5ldHdvcms+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRh cGNpMDogPEFUSSBJWFA2MDAgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4OTAwMC0weDkw MDcsMHg5MDA4LTB4OTAwYiwweDkwMTAtMHg5MDE3LDB4NTAxOC0weDUwMWIsMHg1MDIwLTB4 NTAyZiBtZW0gMHhkMDQwOTAwMC0weGQwNDA5M2ZmIGlycSAxNiBhdCBkZXZpY2UgMTguMCBv biBwY2kwCmF0YXBjaTA6IFtJVEhSRUFEXQphdGFwY2kwOiBBSENJIFZlcnNpb24gMDEuMTAg Y29udHJvbGxlciB3aXRoIDQgcG9ydHMgUE0gbm90IHN1cHBvcnRlZAphdGEyOiA8QVRBIGNo YW5uZWwgMD4gb24gYXRhcGNpMAphdGEyOiBbSVRIUkVBRF0Kb2hjaTA6IDxPSENJIChnZW5l cmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZDA0MDEwMDAtMHhkMDQwMWZmZiBpcnEgMjMg YXQgZGV2aWNlIDE5LjAgb24gcGNpMApvaGNpMDogW0lUSFJFQURdCnVzYnVzMDogPE9IQ0kg KGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMApvaGNpMTogPE9IQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhkMDQwMjAwMC0weGQwNDAyZmZmIGlycSAxNyBh dCBkZXZpY2UgMTkuMSBvbiBwY2kwCm9oY2kxOiBbSVRIUkVBRF0KdXNidXMxOiA8T0hDSSAo Z2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kxCm9oY2kyOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGQwNDAzMDAwLTB4ZDA0MDNmZmYgaXJxIDE3IGF0 IGRldmljZSAxOS4yIG9uIHBjaTAKb2hjaTI6IFtJVEhSRUFEXQp1c2J1czI6IDxPSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTIKb2hjaTM6IDxPSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZDA0MDQwMDAtMHhkMDQwNGZmZiBpcnEgMTcgYXQg ZGV2aWNlIDE5LjMgb24gcGNpMApvaGNpMzogW0lUSFJFQURdCnVzYnVzMzogPE9IQ0kgKGdl bmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMwpvaGNpNDogPE9IQ0kgKGdlbmVyaWMp IFVTQiBjb250cm9sbGVyPiBtZW0gMHhkMDQwNTAwMC0weGQwNDA1ZmZmIGlycSAxNyBhdCBk ZXZpY2UgMTkuNCBvbiBwY2kwCm9oY2k0OiBbSVRIUkVBRF0KdXNidXM0OiA8T0hDSSAoZ2Vu ZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2k0CmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykg VVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhkMDQwNjAwMC0weGQwNDA2MGZmIGlycSAyMyBh dCBkZXZpY2UgMTkuNSBvbiBwY2kwCmVoY2kwOiBbSVRIUkVBRF0KdXNidXM1OiBFSENJIHZl cnNpb24gMS4wCnVzYnVzNTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4g b24gZWhjaTAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMjAuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQphdGFwY2kxOiA8QVRJIElYUDYwMCBVRE1BMTMzIGNvbnRyb2xs ZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHg1MDQwLTB4 NTA0ZiBpcnEgMTYgYXQgZGV2aWNlIDIwLjEgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwg MD4gb24gYXRhcGNpMQphdGEwOiBbSVRIUkVBRF0KaGRhYzA6IDxBVEkgU0I2MDAgSGlnaCBE ZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+IGlycSAxNiBhdCBkZXZpY2UgMjAuMiBvbiBw Y2kwCmhkYWMwOiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDA5MDMxNl8wMTMwCmhkYWMwOiBb SVRIUkVBRF0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDIwLjMgb24gcGNp MAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMjAuNCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1 CmNiYjA6IDxSRjVDNDc2IFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4ZDAxMDAwMDAtMHhk MDEwMGZmZiBpcnEgMjAgYXQgZGV2aWNlIDQuMCBvbiBwY2kyCmNhcmRidXMwOiA8Q2FyZEJ1 cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBvbiBjYmIwCmNi YjA6IFtGSUxURVJdCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBv biBhY3BpMApiYXR0ZXJ5MTogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNw aTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNs ZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3 aXRjaD4gb24gYWNwaTAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmF0cnRj MDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSwweDcyLTB4NzMgaXJxIDgg b24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAw eDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9u IGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6 IFtJVEhSRUFEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDog W0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVsIFN5bmFwdGljcyBU b3VjaHBhZCwgZGV2aWNlIElEIDMKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Ro cm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTAKcG93ZXJub3cwOiA8UG93 ZXJOb3chIEs4PiBvbiBjcHUwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJv dHRsZTE6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUxCmFjcGlfdGhyb3R0bGUxOiBm YWlsZWQgdG8gYXR0YWNoIFBfQ05UCmRldmljZV9hdHRhY2g6IGFjcGlfdGhyb3R0bGUxIGF0 dGFjaCByZXR1cm5lZCA2CnBvd2Vybm93MTogPFBvd2VyTm93ISBLOD4gb24gY3B1MQpvcm0w OiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkMGZmZiBvbiBpc2EwCnNj MDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZH QT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApw cGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpUaW1lY291bnRlcnMgdGljayBl dmVyeSAxLjAwMCBtc2VjCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDEyTWJwcyBGdWxsIFNw ZWVkIFVTQiB2MS4wCnVzYnVzMzogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM0 OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czU6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAp1Z2VuMC4xOiA8QVRJPiBhdCB1c2J1czAKdWh1YjA6IDxBVEkgT0hDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1 Z2VuMS4xOiA8QVRJPiBhdCB1c2J1czEKdWh1YjE6IDxBVEkgT0hDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8QVRJ PiBhdCB1c2J1czIKdWh1YjI6IDxBVEkgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8QVRJPiBhdCB1c2J1czMK dWh1YjM6IDxBVEkgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8QVRJPiBhdCB1c2J1czQKdWh1YjQ6IDxBVEkg T0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzNAp1Z2VuNS4xOiA8QVRJPiBhdCB1c2J1czUKdWh1YjU6IDxBVEkgRUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQphY2QwOiBE VkRSIDxITC1EVC1TVCBEVkRSQU0gR1NBLVQyMEwvTkMwOD4gYXQgYXRhMC1tYXN0ZXIgUElP NAphZDQ6IDE1MjYyN01CIDxUT1NISUJBIE1LMTY0NkdTWCBMQjExNEM+IGF0IGF0YTItbWFz dGVyIFNBVEEzMDAKaGRhYzA6IEhEQSBDb2RlYyAjMDogQW5hbG9nIERldmljZXMgQUQxOTgx SEQKaGRhYzA6IEhEQSBDb2RlYyAjMTogTHVjZW50L0FnZXJlIFN5c3RlbXMgKFVua25vd24p CnBjbTA6IDxIREEgQW5hbG9nIERldmljZXMgQUQxOTgxSEQgUENNICMwIEFuYWxvZz4gYXQg Y2FkIDAgbmlkIDEgb24gaGRhYzAKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCldBUk5JTkc6 IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpH RU9NOiBhZDRzMTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1NWgsNjNzICE9 IDE2aCw2M3MpLgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czUgdXNidXM0IHVzYnVz MyB1c2J1czIgdXNidXMxIHVzYnVzMAp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1IHVzYnVzNCB1 c2J1czMgdXNidXMyIHVzYnVzMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1IHVzYnVzNCB1c2J1 czMgdXNidXMyCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czUgdXNidXM0IHVzYnVzMwp1aHViMzog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0 aW5nIGZvcjogdXNidXM1IHVzYnVzNAp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1CgphY2QwOiBG QUlMVVJFIC0gSU5RVUlSWSBJTExFR0FMIFJFUVVFU1QgYXNjPTB4MjQgYXNjcT0weDAwIHNr cz0weDQwIDB4MDAgMHgwMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czUKdWh1YjU6 IDEwIHBvcnRzIHdpdGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKKHByb2JlMDphdGEw OjA6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAgMCAwCihwcm9iZTA6YXRh MDowOjA6MCk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihwcm9iZTA6YXRhMDow OjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24KKHByb2JlMDphdGEwOjA6MDow KTogTk9UIFJFQURZIGNzaTowLDAsYmIsMCBhc2M6M2EsMAoocHJvYmUwOmF0YTA6MDowOjAp OiBNZWRpdW0gbm90IHByZXNlbnQKKHByb2JlMDphdGEwOjA6MDowKTogVW5yZXRyeWFibGUg ZXJyb3IKY2QwIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8SEwtRFQtU1Qg RFZEUkFNIEdTQS1UMjBMIE5DMDg+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZQpj ZDA6IDE2LjAwME1CL3MgdHJhbnNmZXJzCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ug c2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50ClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzNQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2 L2FkNHMxYQpXQVJOSU5HOiAvIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZAp1Z2VuMC4y OiA8QnJvYWRjb20gQ29ycD4gYXQgdXNidXMwCnVidDA6IDxCcm9hZGNvbSBDb3JwIEhQIElu dGVncmF0ZWQgTW9kdWxlLCBjbGFzcyAyMjQvMSwgcmV2IDIuMDAvMS4wMCwgYWRkciAyPiBv biB1c2J1czAKdWdlbjEuMjogPExvZ2l0ZWNoPiBhdCB1c2J1czEKdW1zMDogPExvZ2l0ZWNo IE9wdGljYWwgVVNCIE1vdXNlLCBjbGFzcyAwLzAsIHJldiAyLjAwLzMuNDAsIGFkZHIgMj4g b24gdXNidXMxCnVtczA6IDMgYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMKV0FSTklO RzogVE1QRlMgaXMgY29uc2lkZXJlZCB0byBiZSBhIGhpZ2hseSBleHBlcmltZW50YWwgZmVh dHVyZSBpbiBGcmVlQlNELgpXQVJOSU5HOiBhdHRlbXB0IHRvIG5ldF9hZGRfZG9tYWluKG5l dGdyYXBoKSBhZnRlciBkb21haW5maW5hbGl6ZSgpCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CjFz dCAweGZmZmZmZmZlNjZjODYxMjAgYnVmd2FpdCAoYnVmd2FpdCkgQCAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfYmlvLmM6MjU0OQoybmQgMHhmZmZmZmYwMDAzY2Y1NjAwIGRpcmhhc2ggKGRp cmhhc2gpIEAgL3Vzci9zcmMvc3lzL3Vmcy91ZnMvdWZzX2Rpcmhhc2guYzoyNzUKS0RCOiBz dGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3Nl bGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdn ZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4 MWUKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKdWZzZGlyaGFzaF9hY3F1aXJlKCkg YXQgdWZzZGlyaGFzaF9hY3F1aXJlKzB4MzMKdWZzZGlyaGFzaF9yZW1vdmUoKSBhdCB1ZnNk aXJoYXNoX3JlbW92ZSsweDE2CnVmc19kaXJyZW1vdmUoKSBhdCB1ZnNfZGlycmVtb3ZlKzB4 MTgxCnVmc19yZW1vdmUoKSBhdCB1ZnNfcmVtb3ZlKzB4OTIKVk9QX1JFTU9WRV9BUFYoKSBh dCBWT1BfUkVNT1ZFX0FQVisweDkzCmtlcm5fdW5saW5rYXQoKSBhdCBrZXJuX3VubGlua2F0 KzB4MjQ5CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MWJmClhmYXN0X3N5c2NhbGwoKSBhdCBY ZmFzdF9zeXNjYWxsKzB4YWIKLS0tIHN5c2NhbGwgKDEwLCBGcmVlQlNEIEVMRjY0LCB1bmxp bmspLCByaXAgPSAweDgwMDcxYzIyYywgcnNwID0gMHg3ZmZmZmZmZmU0MTgsIHJicCA9IDB4 N2ZmZmZmZmZlZjZlIC0tLQpsb2NrIG9yZGVyIHJldmVyc2FsOgoxc3QgMHhmZmZmZmYwMDA3 MmE1NDQ4IHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19tb3VudC5jOjEwNTAK Mm5kIDB4ZmZmZmZmMDAwNzQ4NzlkMCBkZXZmcyAoZGV2ZnMpIEAgL3Vzci9zcmMvc3lzL2tl cm4vdmZzX3N1YnIuYzoyMTAwCktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm X3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1 Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkg YXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODFlCl9fbG9ja21ncl9hcmdzKCkgYXQgX19sb2Nr bWdyX2FyZ3MrMHhjMmEKdm9wX3N0ZGxvY2soKSBhdCB2b3Bfc3RkbG9jaysweDM5ClZPUF9M T0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBWKzB4OWIKX3ZuX2xvY2soKSBhdCBfdm5fbG9j aysweDQ3CnZnZXQoKSBhdCB2Z2V0KzB4OGIKZGV2ZnNfYWxsb2N2KCkgYXQgZGV2ZnNfYWxs b2N2KzB4MTBjCmRldmZzX3Jvb3QoKSBhdCBkZXZmc19yb290KzB4NTIKdmZzX2Rvbm1vdW50 KCkgYXQgdmZzX2Rvbm1vdW50KzB4MTAxOQpubW91bnQoKSBhdCBubW91bnQrMHg1YQpzeXNj YWxsKCkgYXQgc3lzY2FsbCsweDFiZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2Fs bCsweGFiCi0tLSBzeXNjYWxsICgzNzgsIEZyZWVCU0QgRUxGNjQsIG5tb3VudCksIHJpcCA9 IDB4ODAwN2E5ZGZjLCByc3AgPSAweDdmZmZmZmZmZGQyOCwgcmJwID0gMHg4MDBhMDQwNDgg LS0tCgoKCgoKZnVzZTRic2Q6IHZlcnNpb24gMC4zLjktcHJlMSwgRlVTRSBBQkkgNy44Cgpk cm0wOiA8QVRJIFJhZGVvbiBSUzY5MCBYMTI3MCBJR1A+IG9uIHZnYXBjaTAKaW5mbzogW2Ry bV0gTVNJIGVuYWJsZWQgMSBtZXNzYWdlKHMpCnZnYXBjaTA6IGNoaWxkIGRybTAgcmVxdWVz dGVkIHBjaV9lbmFibGVfYnVzbWFzdGVyCmluZm86IFtkcm1dIEluaXRpYWxpemVkIHJhZGVv biAxLjI5LjAgMjAwODA1MjgKaW5mbzogW2RybV0gU2V0dGluZyBHQVJUIGxvY2F0aW9uIGJh c2VkIG9uIG5ldyBtZW1vcnkgbWFwCmluZm86IFtkcm1dIExvYWRpbmcgUlM2OTAvUlM3NDAg TWljcm9jb2RlCmluZm86IFtkcm1dIE51bSBwaXBlczogMQppbmZvOiBbZHJtXSB3cml0ZWJh Y2sgdGVzdCBmYWlsZWQKZHJtMDogW0lUSFJFQURdCg== --------------000407070504010200060901-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 14:41:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04107106564A; Sun, 22 Mar 2009 14:41:52 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7B47D8FC19; Sun, 22 Mar 2009 14:41:51 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.170.109]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n2MEfipw029898; Sun, 22 Mar 2009 15:41:44 +0100 From: Pieter de Goeje To: Andrew Thompson Date: Sun, 22 Mar 2009 15:41:44 +0100 User-Agent: KMail/1.9.10 References: <200903211448.28590.pieter@degoeje.nl> <200903220152.55252.pieter@degoeje.nl> <20090322042401.GB50126@citylink.fud.org.nz> In-Reply-To: <20090322042401.GB50126@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903221541.44336.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Anonymous , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 14:41:52 -0000 On Sunday 22 March 2009 05:24:01 Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: > > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > > > > I added a bunch of printf()s to libusb, specifically > > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The > > > > > ugenX.2 files were opened successfully. > > > > > > > > > > At this point it looks like the problem lies somewhere in the > > > > > kernel, which makes it a lot harder for me to debug. > > > > > > > > Can you try to back out r189906? Doing so makes my keyboard to appear > > > > in usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 > > > > -a 3'. > > > > I'll give it a shot. It's rather late so the results will probably have > > to wait until tomorrow. That didn't make a difference. > > > > > What does sysctl hw.usb2.dev.debug=2 show with usbconfig on the latest > > > HEAD code? > > > > Output is quite long so I put it on the web: > > http://unforgiven.student.utwente.nl/~pyotr/dump/usbconfig_debug_2.txt > > I cant see anything obviously wrong with r189906 so I have committed > some more debugging traces. Can you update your sources/kernel and run > usbconfig again with hw.usb2.dev.debug=5 http://unforgiven.student.utwente.nl/~pyotr/dump/usbconfig_debug_5.txt At line 494 & 511 the ioctls fail. I also did what HPS asked, I manually copied the usb headers, but that didnt help either. (I deleted /usr/obj and ran a full buildworld / buildkernel / installkernel / installworld before that). -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 16:18:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0BA21065672 for ; Sun, 22 Mar 2009 16:18:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFB38FC1F for ; Sun, 22 Mar 2009 16:18:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 939A1FF32; Mon, 23 Mar 2009 05:18:34 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmnT8+i36YAb; Mon, 23 Mar 2009 05:18:31 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 23 Mar 2009 05:18:31 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 8B81F1142F; Mon, 23 Mar 2009 05:18:30 +1300 (NZDT) Date: Sun, 22 Mar 2009 09:18:30 -0700 From: Andrew Thompson To: Pieter de Goeje Message-ID: <20090322161830.GA78270@citylink.fud.org.nz> References: <200903211448.28590.pieter@degoeje.nl> <200903220152.55252.pieter@degoeje.nl> <20090322042401.GB50126@citylink.fud.org.nz> <200903221541.44336.pieter@degoeje.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903221541.44336.pieter@degoeje.nl> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Anonymous , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:18:36 -0000 On Sun, Mar 22, 2009 at 03:41:44PM +0100, Pieter de Goeje wrote: > On Sunday 22 March 2009 05:24:01 Andrew Thompson wrote: > > On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: > > > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > > > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > > > > > I added a bunch of printf()s to libusb, specifically > > > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The > > > > > > ugenX.2 files were opened successfully. > > > > > > > > > > > > At this point it looks like the problem lies somewhere in the > > > > > > kernel, which makes it a lot harder for me to debug. > > > > > > > > > > Can you try to back out r189906? Doing so makes my keyboard to appear > > > > > in usbconfig output again. Here is a ktrace diff for `usbconfig -u 0 > > > > > -a 3'. > > > > > > I'll give it a shot. It's rather late so the results will probably have > > > to wait until tomorrow. > > That didn't make a difference. Does this fix it for you? http://people.freebsd.org/~thompsa/usb_dev.diff Andrew From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 16:29:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43041065670 for ; Sun, 22 Mar 2009 16:29:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 604B68FC27 for ; Sun, 22 Mar 2009 16:29:23 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n2MFt1Vs063720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Mar 2009 16:55:01 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n2MFswQp041098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 16:54:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n2MFswUi007509; Sun, 22 Mar 2009 16:54:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n2MFsv5F007508; Sun, 22 Mar 2009 16:54:57 +0100 (CET) (envelope-from ticso) Date: Sun, 22 Mar 2009 16:54:57 +0100 From: Bernd Walter To: debardeleben@aol.com Message-ID: <20090322155457.GB88917@cicely7.cicely.de> References: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org, freebsd@cfdhome.com Subject: Re: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:29:25 -0000 Interesting - I have problems with ulpt as well: ulpt0: on usbus2 ulpt0: using bi-directional mode ulpt1: on usbus1 ulpt1: using bi-directional mode ulpt1: out of paper ulpt2: on usbus1 ulpt2: using bi-directional mode ulpt2: out of paper ulpt0 prints and the others are just plugged in cables. But none of them is listed with usbconfig: [80]cicely13# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen2.2: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.3: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.4: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.4: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.6: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.7: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.8: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.5: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON With the prolific connected usbconfig even takes a few seconds, while it is fast otherwise. On Sun, Mar 22, 2009 at 06:46:30AM -0400, debardeleben@aol.com wrote: > I finally got fed up enough with not being able to print with -CURRENT, > and found a fix that make ulpt work for me with my epson stylus photo 835. > > I am using cups, and I have always needed to use the non-reset device, > even with the old USB stack. Hopefully a committer can pick this up and > include an appropriate version of this fix to the source tree. In the mean > time, if you are having trouble with a usb printer with -CURRENT, you > may want to try this patch. > > I am attaching a patch file (referenced at /usr/src/sys/dev/usb/serial > from my system. The change is to initialize sc_fflags to 0 when > attaching the device. This is allowing open to stop returning EBUSY. > > Now on to finding out why using my newly accessible firewire disks > resulted in filesystem corruption on all of my filesystems. I suspect > some missing lock. Its very annoying, and I lost a lot of important > files. (I will be doing a full backup of all of my disks before > connecting my firewire disks back up). > > -Charles > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 16:31:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37CB91065687 for ; Sun, 22 Mar 2009 16:31:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id E8C7F8FC29 for ; Sun, 22 Mar 2009 16:31:44 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 23321FF32; Mon, 23 Mar 2009 05:31:44 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I63Kc5DGhFmU; Mon, 23 Mar 2009 05:31:40 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 23 Mar 2009 05:31:40 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 39F4C1142F; Mon, 23 Mar 2009 05:31:40 +1300 (NZDT) Date: Sun, 22 Mar 2009 09:31:40 -0700 From: Andrew Thompson To: ticso@cicely.de Message-ID: <20090322163140.GB78270@citylink.fud.org.nz> References: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> <20090322155457.GB88917@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090322155457.GB88917@cicely7.cicely.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: debardeleben@aol.com, freebsd-current@freebsd.org, freebsd@cfdhome.com Subject: Re: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:31:45 -0000 On Sun, Mar 22, 2009 at 04:54:57PM +0100, Bernd Walter wrote: > Interesting - I have problems with ulpt as well: > ulpt0: on usbus2 > ulpt0: using bi-directional mode > ulpt1: on usbus1 > ulpt1: using bi-directional mode > ulpt1: out of paper > ulpt2: on usbus1 > ulpt2: using bi-directional mode > ulpt2: out of paper > > ulpt0 prints and the others are just plugged in cables. > > But none of them is listed with usbconfig: Does this fix the usbconfig printing? http://people.freebsd.org/~thompsa/usb_dev.diff Andrew From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 16:54:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2330D1065688; Sun, 22 Mar 2009 16:54:37 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3128FC1A; Sun, 22 Mar 2009 16:54:36 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.170.109]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n2MGsQWN003101; Sun, 22 Mar 2009 17:54:27 +0100 From: Pieter de Goeje To: Andrew Thompson Date: Sun, 22 Mar 2009 17:54:26 +0100 User-Agent: KMail/1.9.10 References: <200903211448.28590.pieter@degoeje.nl> <200903221541.44336.pieter@degoeje.nl> <20090322161830.GA78270@citylink.fud.org.nz> In-Reply-To: <20090322161830.GA78270@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903221754.26871.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Anonymous , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:54:37 -0000 On Sunday 22 March 2009 17:18:30 Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 03:41:44PM +0100, Pieter de Goeje wrote: > > On Sunday 22 March 2009 05:24:01 Andrew Thompson wrote: > > > On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: > > > > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: > > > > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: > > > > > > > I added a bunch of printf()s to libusb, specifically > > > > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, > > > > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The > > > > > > > ugenX.2 files were opened successfully. > > > > > > > > > > > > > > At this point it looks like the problem lies somewhere in the > > > > > > > kernel, which makes it a lot harder for me to debug. > > > > > > > > > > > > Can you try to back out r189906? Doing so makes my keyboard to > > > > > > appear in usbconfig output again. Here is a ktrace diff for > > > > > > `usbconfig -u 0 -a 3'. > > > > > > > > I'll give it a shot. It's rather late so the results will probably > > > > have to wait until tomorrow. > > > > That didn't make a difference. > > Does this fix it for you? > > http://people.freebsd.org/~thompsa/usb_dev.diff Yes! Excellent, thank you :-) -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 17:23:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5277106566C for ; Sun, 22 Mar 2009 17:23:48 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id EC0708FC1F for ; Sun, 22 Mar 2009 17:23:47 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fxm11 with SMTP id 11so1400941fxm.43 for ; Sun, 22 Mar 2009 10:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=fWJjGN5/pZOTNbUcbKIkRUiVv9FyJhHfj4bPwysC3+s=; b=TzpLuIievV8gRC7boSKafrUOkBLAb3CyTkBKwNzIYs4bPvGFK4ZQA1zk3lS2aoYJm1 4tpWGZsdyn9d2YZ1opUavO2XXMm/h5p8WmBKuRJGG6gVZq4fHCukGyeIQpV3RNbn16Cx Zgg9ur400WEDaFFT0q+47pT618RBED46RZ91Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=G4WnxQgocnWKelHNWARVMcOkJFAST+0wOkvs636Yvdw96ee+13e4exfjl8AFWAuD6X TwLw+1uRvxfy3mBP/S+a9PxcokOQ761EPrC46bkW9VrFWphAutEzwkpJR0+HcQVNumVs BOUSh6ep48Ofsq2hESjoqBoSl3/q1Tgi0l9IE= Received: by 10.86.3.4 with SMTP id 4mr2941952fgc.41.1237742626736; Sun, 22 Mar 2009 10:23:46 -0700 (PDT) Received: from localhost (95-24-174-59.broadband.corbina.ru [95.24.174.59]) by mx.google.com with ESMTPS id 4sm2044434fge.18.2009.03.22.10.23.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Mar 2009 10:23:46 -0700 (PDT) From: Anonymous To: Pieter de Goeje References: <200903211448.28590.pieter@degoeje.nl> <200903221541.44336.pieter@degoeje.nl> <20090322161830.GA78270@citylink.fud.org.nz> <200903221754.26871.pieter@degoeje.nl> Date: Sun, 22 Mar 2009 20:23:06 +0300 Message-ID: <867i2hmpz9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Andrew Thompson , Hans Petter Selasky Subject: Re: usbconfig / hal-device no longer lists usb devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:23:49 -0000 Pieter de Goeje writes: > On Sunday 22 March 2009 17:18:30 Andrew Thompson wrote: >> On Sun, Mar 22, 2009 at 03:41:44PM +0100, Pieter de Goeje wrote: >> > On Sunday 22 March 2009 05:24:01 Andrew Thompson wrote: >> > > On Sun, Mar 22, 2009 at 01:52:54AM +0100, Pieter de Goeje wrote: >> > > > On Sunday 22 March 2009 01:03:31 Andrew Thompson wrote: >> > > > > On Sun, Mar 22, 2009 at 02:52:33AM +0300, Anonymous wrote: >> > > > > > > I added a bunch of printf()s to libusb, specifically >> > > > > > > ugen20_enumerate(). Both ugen0.2 and ugen1.2 failed at ioctl(f, >> > > > > > > USB_GET_PLUGTIME, &plugtime) because it returned EINVAL. The >> > > > > > > ugenX.2 files were opened successfully. >> > > > > > > >> > > > > > > At this point it looks like the problem lies somewhere in the >> > > > > > > kernel, which makes it a lot harder for me to debug. >> > > > > > >> > > > > > Can you try to back out r189906? Doing so makes my keyboard to >> > > > > > appear in usbconfig output again. Here is a ktrace diff for >> > > > > > `usbconfig -u 0 -a 3'. >> > > > >> > > > I'll give it a shot. It's rather late so the results will probably >> > > > have to wait until tomorrow. >> > >> > That didn't make a difference. >> >> Does this fix it for you? >> >> http://people.freebsd.org/~thompsa/usb_dev.diff > > Yes! Excellent, thank you :-) And for me, too. my dmesg + hw.usb2.dev.debug=5 when running `usbconfig' without applying the patch - http://pastebin.com/m2e1db504 From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 17:34:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62A01065672 for ; Sun, 22 Mar 2009 17:34:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AF0318FC16 for ; Sun, 22 Mar 2009 17:34:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MHWsjT004467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 13:32:55 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C64AA5.3000509@lissyara.su> References: <49C64AA5.3000509@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5LwocyFNC5Cev7b/jKJw" Organization: FreeBSD Date: Sun, 22 Mar 2009 12:33:54 -0500 Message-Id: <1237743234.1687.7.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:34:17 -0000 --=-5LwocyFNC5Cev7b/jKJw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > (II) RADEON(0): XAA Render acceleration unsupported on Radeon > 9500/9700 and newer. Please use EXA instead. Everything looks like it's ok, except that you should be using EXA. Option "AccelMethod" "EXA" What was the last working kernel? If this is drm related, it almost has to be r190123, but I'm pretty sure that is correct. I'll double check it though... robert. =20 --=20 Robert Noland FreeBSD --=-5LwocyFNC5Cev7b/jKJw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGdoIACgkQM4TrQ4qfRONwngCeIb4K7gCnyGMwWc8y6t08BQcB qbkAnj+eMr10ySDxCHO4ScydeD5nDFZ/ =sBxI -----END PGP SIGNATURE----- --=-5LwocyFNC5Cev7b/jKJw-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 17:44:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503B110656D1 for ; Sun, 22 Mar 2009 17:44:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1F18FC08 for ; Sun, 22 Mar 2009 17:44:24 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MHh2tr004520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 13:43:03 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C64AA5.3000509@lissyara.su> References: <49C64AA5.3000509@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uuwBZS7wFieqJQqnNf+6" Organization: FreeBSD Date: Sun, 22 Mar 2009 12:44:02 -0500 Message-Id: <1237743842.1687.8.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:44:32 -0000 --=-uuwBZS7wFieqJQqnNf+6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > (II) Cannot locate a core pointer device. > (II) Cannot locate a core keyboard device. > (II) The server relies on HAL to provide the list of input devices. > If no devices become available, reconfigure HAL or disable > AllowEmptyInput. Actually, It looks like maybe it is waiting on hald? Did you just switch to usb2? robert. --=20 Robert Noland FreeBSD --=-uuwBZS7wFieqJQqnNf+6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGeOIACgkQM4TrQ4qfRONXUQCfWqiTKpGpZM4lWiojOfYisDH8 IkYAn0Rypxmpk6xGAN+57FUB2yCYKEFA =L5B8 -----END PGP SIGNATURE----- --=-uuwBZS7wFieqJQqnNf+6-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 18:06:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF489106576F; Sun, 22 Mar 2009 18:06:07 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 969C48FC0C; Sun, 22 Mar 2009 18:06:07 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.148.109] (port=45192 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlS3h-000K3m-TT; Sun, 22 Mar 2009 21:06:05 +0300 Message-ID: <49C67E10.2000202@lissyara.su> Date: Sun, 22 Mar 2009 21:06:08 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Robert Noland References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> In-Reply-To: <1237743234.1687.7.camel@balrog.2hip.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:06:08 -0000 Robert Noland ïèøåò: > On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: >> (II) RADEON(0): XAA Render acceleration unsupported on Radeon >> 9500/9700 and newer. Please use EXA instead. > > Everything looks like it's ok, except that you should be using EXA. > > Option "AccelMethod" "EXA" I'm not using Xorg.conf - I always start without it - all work OK. X-system by oneself configure all parameters. > What was the last working kernel? FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14 19:08:30 MSK 2009 lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 >Actually, It looks like maybe it is waiting on hald? Did you just switch to usb2? Yes, I use GENERIC. But, old kernel with new USB stack and work correct. From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 18:16:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E89591065909 for ; Sun, 22 Mar 2009 18:16:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AED3D8FC0A for ; Sun, 22 Mar 2009 18:16:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MIEhtj004686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 14:14:43 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C67E10.2000202@lissyara.su> References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-QhfPv8WaMFQRm3bVO6gD" Organization: FreeBSD Date: Sun, 22 Mar 2009 13:15:42 -0500 Message-Id: <1237745742.1687.12.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:16:05 -0000 --=-QhfPv8WaMFQRm3bVO6gD Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: > Robert Noland =D0=C9=DB=C5=D4: > > On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > >> (II) RADEON(0): XAA Render acceleration unsupported on Radeon > >> 9500/9700 and newer. Please use EXA instead. > >=20 > > Everything looks like it's ok, except that you should be using EXA. > >=20 > > Option "AccelMethod" "EXA" > I'm not using Xorg.conf - I always start without it - all work OK. > X-system by oneself configure all parameters. >=20 > > What was the last working kernel? > FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14=20 > 19:08:30 MSK 2009=20 > lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > >Actually, It looks like maybe it is waiting on hald? Did you just > switch to usb2? > Yes, I use GENERIC. But, old kernel with new USB stack and work correct. Please make sure that hald is running and that lshal shows you mouse and keyboard before we go digging any further. The rs690 is picky about how the gart is allocated, but I had the flags to bus_dmamem applied incorrectly. It should not have caused an issue and all of the allocations look to be correct. You should probably not be running configless on this chip, as the defaults are not optimum for it. robert. --=20 Robert Noland FreeBSD --=-QhfPv8WaMFQRm3bVO6gD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGgE4ACgkQM4TrQ4qfRONUYwCfY0+2cNX3tQc7++V1rhOCHh4D PfwAmgN16LV7CY1nEEF13mjvMO42XXH2 =HrPh -----END PGP SIGNATURE----- --=-QhfPv8WaMFQRm3bVO6gD-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 18:47:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D74141065672 for ; Sun, 22 Mar 2009 18:47:39 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 642298FC23 for ; Sun, 22 Mar 2009 18:47:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n2MIlYfE071246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Mar 2009 19:47:34 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n2MIlUuu046078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 19:47:30 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n2MIlUQS007977; Sun, 22 Mar 2009 19:47:30 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n2MIlT1l007976; Sun, 22 Mar 2009 19:47:29 +0100 (CET) (envelope-from ticso) Date: Sun, 22 Mar 2009 19:47:29 +0100 From: Bernd Walter To: Andrew Thompson Message-ID: <20090322184729.GH88917@cicely7.cicely.de> References: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> <20090322155457.GB88917@cicely7.cicely.de> <20090322163140.GB78270@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090322163140.GB78270@citylink.fud.org.nz> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: debardeleben@aol.com, freebsd-current@FreeBSD.org, ticso@cicely.de, freebsd@cfdhome.com Subject: Re: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:47:40 -0000 On Sun, Mar 22, 2009 at 09:31:40AM -0700, Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 04:54:57PM +0100, Bernd Walter wrote: > > Interesting - I have problems with ulpt as well: > > ulpt0: on usbus2 > > ulpt0: using bi-directional mode > > ulpt1: on usbus1 > > ulpt1: using bi-directional mode > > ulpt1: out of paper > > ulpt2: on usbus1 > > ulpt2: using bi-directional mode > > ulpt2: out of paper > > > > ulpt0 prints and the others are just plugged in cables. > > > > But none of them is listed with usbconfig: > > Does this fix the usbconfig printing? > > http://people.freebsd.org/~thompsa/usb_dev.diff Yes - no delay and all devices listed: [53]cicely13# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.4: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.5: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.6: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.7: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.8: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.9: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.10: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.2: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.3: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.5: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 19:03:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D101065672; Sun, 22 Mar 2009 19:03:44 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7878FC0C; Sun, 22 Mar 2009 19:03:43 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.148.109] (port=30648 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlSxP-0006K7-E8; Sun, 22 Mar 2009 22:03:39 +0300 Message-ID: <49C68B95.5020402@lissyara.su> Date: Sun, 22 Mar 2009 22:03:49 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Robert Noland References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> <1237745742.1687.12.camel@balrog.2hip.net> In-Reply-To: <1237745742.1687.12.camel@balrog.2hip.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:03:44 -0000 Robert Noland ÐÉÛÅÔ: > On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: >> Robert Noland ÐÉÛÅÔ: >>> On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: >>>> (II) RADEON(0): XAA Render acceleration unsupported on Radeon >>>> 9500/9700 and newer. Please use EXA instead. >>> Everything looks like it's ok, except that you should be using EXA. >>> >>> Option "AccelMethod" "EXA" >> I'm not using Xorg.conf - I always start without it - all work OK. >> X-system by oneself configure all parameters. >> >>> What was the last working kernel? >> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14 >> 19:08:30 MSK 2009 >> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 >> >> >Actually, It looks like maybe it is waiting on hald? Did you just >> switch to usb2? >> Yes, I use GENERIC. But, old kernel with new USB stack and work correct. > > Please make sure that hald is running and that lshal shows you mouse and > keyboard before we go digging any further. it show my mouse, my keyboard and my touchpad > The rs690 is picky about how the gart is allocated, but I had the flags > to bus_dmamem applied incorrectly. It should not have caused an issue > and all of the allocations look to be correct. > > You should probably not be running configless on this chip, as the > defaults are not optimum for it. I remove drm.ko and radeon.ko from /boot/kernel and copy it from /boot/kernel.old With new kernel and old modules - all work excellent. From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 19:16:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 522F8106564A for ; Sun, 22 Mar 2009 19:16:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 18BC68FC19 for ; Sun, 22 Mar 2009 19:16:09 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MJEl4W004998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 15:14:48 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C68B95.5020402@lissyara.su> References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> <1237745742.1687.12.camel@balrog.2hip.net> <49C68B95.5020402@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fUCpeDleQXIbNVyNf8Wt" Organization: FreeBSD Date: Sun, 22 Mar 2009 14:15:47 -0500 Message-Id: <1237749347.1687.19.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:16:10 -0000 --=-fUCpeDleQXIbNVyNf8Wt Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 22:03 +0300, Alex Keda wrote: > Robert Noland =D0=C9=DB=C5=D4: > > On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: > >> Robert Noland =D0=C9=DB=C5=D4: > >>> On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > >>>> (II) RADEON(0): XAA Render acceleration unsupported on Radeon > >>>> 9500/9700 and newer. Please use EXA instead. > >>> Everything looks like it's ok, except that you should be using EXA. > >>> > >>> Option "AccelMethod" "EXA" > >> I'm not using Xorg.conf - I always start without it - all work OK. > >> X-system by oneself configure all parameters. > >> > >>> What was the last working kernel? > >> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14=20 > >> 19:08:30 MSK 2009=20 > >> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> >Actually, It looks like maybe it is waiting on hald? Did you just > >> switch to usb2? > >> Yes, I use GENERIC. But, old kernel with new USB stack and work correc= t. > >=20 > > Please make sure that hald is running and that lshal shows you mouse an= d > > keyboard before we go digging any further. > it show my mouse, my keyboard and my touchpad >=20 > > The rs690 is picky about how the gart is allocated, but I had the flags > > to bus_dmamem applied incorrectly. It should not have caused an issue > > and all of the allocations look to be correct. > >=20 > > You should probably not be running configless on this chip, as the > > defaults are not optimum for it. > I remove drm.ko and radeon.ko from /boot/kernel and copy it from=20 > /boot/kernel.old > With new kernel and old modules - all work excellent. Ok, can you try reverting: r190123 | rnoland | 2009-03-19 23:48:27 -0500 (Thu, 19 Mar 2009) | 4 lines Adjust the flags to bus_dmamem around here too. and see what that does? robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-fUCpeDleQXIbNVyNf8Wt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGjmMACgkQM4TrQ4qfROORtwCbBXCPMwo35ViFV8XsgoOrOAeb m78An0SyRPNWsbpQlK2ypwDSZgLqGGk2 =b0aw -----END PGP SIGNATURE----- --=-fUCpeDleQXIbNVyNf8Wt-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 19:50:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF490106564A for ; Sun, 22 Mar 2009 19:50:56 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 951B68FC13 for ; Sun, 22 Mar 2009 19:50:56 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MJnYlr005186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 15:49:35 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C68B95.5020402@lissyara.su> References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> <1237745742.1687.12.camel@balrog.2hip.net> <49C68B95.5020402@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jEXssa3jXdE2bbsPwyJT" Organization: FreeBSD Date: Sun, 22 Mar 2009 14:50:33 -0500 Message-Id: <1237751433.1687.21.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:50:57 -0000 --=-jEXssa3jXdE2bbsPwyJT Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 22:03 +0300, Alex Keda wrote: > Robert Noland =D0=C9=DB=C5=D4: > > On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: > >> Robert Noland =D0=C9=DB=C5=D4: > >>> On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > >>>> (II) RADEON(0): XAA Render acceleration unsupported on Radeon > >>>> 9500/9700 and newer. Please use EXA instead. > >>> Everything looks like it's ok, except that you should be using EXA. > >>> > >>> Option "AccelMethod" "EXA" > >> I'm not using Xorg.conf - I always start without it - all work OK. > >> X-system by oneself configure all parameters. > >> > >>> What was the last working kernel? > >> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14=20 > >> 19:08:30 MSK 2009=20 > >> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> >Actually, It looks like maybe it is waiting on hald? Did you just > >> switch to usb2? > >> Yes, I use GENERIC. But, old kernel with new USB stack and work correc= t. > >=20 > > Please make sure that hald is running and that lshal shows you mouse an= d > > keyboard before we go digging any further. > it show my mouse, my keyboard and my touchpad >=20 > > The rs690 is picky about how the gart is allocated, but I had the flags > > to bus_dmamem applied incorrectly. It should not have caused an issue > > and all of the allocations look to be correct. > >=20 > > You should probably not be running configless on this chip, as the > > defaults are not optimum for it. > I remove drm.ko and radeon.ko from /boot/kernel and copy it from=20 > /boot/kernel.old > With new kernel and old modules - all work excellent. Ok, after a little discussion and looking at the bus_dma code... The documentation is incorrect. I'll fix this up shortly... robert. --=20 Robert Noland FreeBSD --=-jEXssa3jXdE2bbsPwyJT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGlokACgkQM4TrQ4qfROMq7QCcCu9iQ+HvnUqTQl0xQ/jRjZZN 8aEAnjW/uOqcfZNeiXa6eNn3ZJ8PFiyG =evU0 -----END PGP SIGNATURE----- --=-jEXssa3jXdE2bbsPwyJT-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 20:35:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6CE106564A; Sun, 22 Mar 2009 20:35:51 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 802018FC12; Sun, 22 Mar 2009 20:35:49 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2MKZMLv065384; Sun, 22 Mar 2009 21:35:22 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49C6A109.3040508@fgznet.ch> Date: Sun, 22 Mar 2009 21:35:21 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marius Strobl References: <49C55EBC.1070602@fgznet.ch> <20090321232030.GA70685@alchemy.franken.de> <49C603A8.2010805@fgznet.ch> In-Reply-To: <49C603A8.2010805@fgznet.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-sparc64@freebsd.org Subject: Re: kdb enter when upgrading from 7.1 to current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 20:35:51 -0000 Andreas Tobler wrote: > Marius Strobl wrote: >> On Sat, Mar 21, 2009 at 10:40:12PM +0100, Andreas Tobler wrote: >>> Hi, >>> >>> I get this stacktrace when I try to boot from a Kernel as of today >>> (svn: 190217). >>> >>> My setup is a 7.1 install where I'd like to upgrade to current. >>> The kernel is built cross, amd64 -> sparc64: >>> make -j4 buildkernel TARGET_ARCH=sparc64 KERNCONF=GENERIC >>> >>> The target machine itself is a u60, details below. >>> >>> Does anyone have a pointer to help me, would be great! >>> >>> TIA, >>> Andreas >>> >>> Hit [Enter] to boot immediately, or any other key for command prompt. >>> Booting [/boot/kernel/kernel]... >>> jumping to kernel entry at 0xc0080000. >>> GDB: no debug ports present >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Copyright (c) 1992-2009 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights >>> reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.0-CURRENT #2 r190217M: Sat Mar 21 22:27:46 CET 2009 >>> >>> andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/sparc64/export/devel/ >>> >>> fbsd_svn/src/sys/GENERIC >>> WARNING: WITNESS option enabled, expect reduced performance. >>> real memory = 1610612736 (1536 MB) >>> avail memory = 1554710528 (1482 MB) >>> cpu0: Sun Microsystems UltraSparc-II Processor (449.99 MHz CPU) >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> ispfw: registered firmware >>> kbd0 at kbdmux0 >>> nexus0: >>> pcib0: mem >>> 0x1fe00004000-0x1fe00005fff,0x1fe01000000-0x1fe0 >>> 10000ff,0x1fe00000000-0x1fe0000cfff irq 2033,2030,2031,2021,2024,2034 >>> on nexus0 >>> pcib0: Psycho, impl 0, version 4, IGN 0x1f, bus B, 33MHz >>> initializing counter-timer >>> Timecounter "pcib0" frequency 1000000 Hz quality 100 >>> pcib0: DVMA map: 0xfc000000 to 0xffffffff, streaming buffer >>> pcib0: [FILTER] >>> pcib0: [FILTER] >>> pcib0: [GIANT-LOCKED] >>> pcib0: [ITHREAD] >>> pcib0: [GIANT-LOCKED] >>> pcib0: [ITHREAD] >>> pcib0: [FILTER] >>> pci0: on pcib0 >>> ebus0: mem >>> 0x70000000-0x70ffffff,0x71000000-0x717fffff at dev >>> ice 1.0 on pci0 >>> auxio0: addr >>> 0x1400726000-0x1400726003,0x1400728000-0x140072 >>> 8003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f0 >>> >>> 03 on ebus0 >>> ebus0: addr 0x1400724000-0x1400724003 (no driver attached) >>> ebus0: addr 0x1400504000-0x1400504002 (no driver attached) >>> ebus0: addr 0x1400500000-0x1400500007 (no driver attached) >>> scc0: addr >>> 0x1400400000-0x140040007f irq 43 >>> on ebus0 >>> scc0: [FILTER] >>> uart0: on scc0 >>> uart0: [FILTER] >>> uart0: CTS oflow >>> uart0: console (9600,n,8,1) >>> uart1: on scc0 >>> uart1: [FILTER] >>> uart1: CTS oflow >>> uart2: <16550 or compatible> addr 0x14003083f8-0x14003083ff irq 41 on >>> ebus0 >>> uart2: [FILTER] >>> uart2: keyboard (1200,n,8,1) >>> uart2: keyboard not present >>> uart3: <16550 or compatible> addr 0x14003062f8-0x14003062ff irq 42 on >>> ebus0 >>> uart3: [FILTER] >>> ebus0: addr >>> 0x14003043bc-0x14003043cb,0x1400300398-0x1400300399,0x1400700 >>> 000-0x140070000f irq 34 (no driver attached) >>> ebus0: addr >>> 0x14003023f0-0x14003023f7,0x1400706000-0x140070600f,0x1400 >>> 720000-0x1400720003 irq 39 (no driver attached) >>> eeprom0: addr 0x1400000000-0x1400001fff on ebus0 >>> eeprom0: model mk48t59 >>> ebus0: addr 0x1000000000-0x10000fffff (no driver attached) >>> ebus0: addr >>> 0x1400200000-0x14002000ff,0x1400702000-0x140070200f,0x >>> 1400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 (no >>> driver attached) >>> hme0: mem 0x100000-0x107fff at device 1.1 >>> on pci0 >>> miibus0: on hme0 >>> qsphy0: PHY 1 on miibus0 >>> qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>> hme0: Ethernet address: 08:00:20:a3:71:69 >>> hme0: [ITHREAD] >>> sym0: <875> port 0x1000-0x10ff mem >>> 0x108000-0x1080ff,0x10a000-0x10afff at device >>> 3.0 on pci0 >>> sym0: No NVRAM, ID 7, Fast-20, SE, parity checking >>> sym0: [ITHREAD] >>> sym1: <875> port 0x1400-0x14ff mem >>> 0x10c000-0x10c0ff,0x10e000-0x10efff at device >>> 3.1 on pci0 >>> sym1: No NVRAM, ID 7, Fast-20, SE, parity checking >>> sym1: [ITHREAD] >>> pcib1: mem >>> 0x1fe00002000-0x1fe00003fff,0x1fe01800000-0x1fe0 >>> 18000ff,0x1fe00000000-0x1fe0000cfff irq 2032,2030,2031,2021,2024,2034 >>> on nexus0 >>> pcib1: Psycho, impl 0, version 4, IGN 0x1f, bus A, 66MHz >>> pcib1: [FILTER] >>> pci1: on pcib1 >>> pci1: at device 1.0 (no driver attached) >>> creator0: mem >>> 0x1fc00000000-0x1fc000003ff,0x1fc00400000-0x1fc005ffff >>> f,0x1fc00600000-0x1fc007fffff,0x1fc01000000-0x1fc013fffff,0x1fc01400000-0x1fc017 >>> >>> fffff,0x1fc01800000-0x1fc01bfffff,0x1fc01c00000-0x1fc01ffffff,0x1fc02000000-0x1f >>> >>> c02ffffff,0x1fc03000000-0x1fc03ffffff,0x1fc04000000-0x1fc043fffff,0x1fc04400000- >>> >>> 0x1fc047fffff,0x1fc04800000-0x1fc04bfffff,0x1fc04c00000-0x1fc04ffffff,0x1fc05000 >>> >>> 000-0x1fc05ffffff,0x1fc06000000-0x1fc07ffffff,0x1fc09000000-0x1fc097fffff,0x1fc0 >>> >>> 9800000-0x1fc09ffffff,0x1fc0a000000-0x1fc0affffff,0x1fc0b000000-0x1fc0b7fffff,0x >>> >>> 1fc0b800000-0x1fc0bffffff,0x1fc0c000000-0x1fc0c3fffff,0x1fc0c800000-0x1fc0cfffff >>> >>> f,0x1fc0d000000-0x1fc0d7fffff,0x1fc0d800000-0x1fc0dffffff irq 1925 on >>> nexus0 >>> creator0: resolution 1152x900 >>> syscons0: on nexus0 >>> syscons0: Unknown <16 virtual consoles, flags=0x100> >>> Timecounter "tick" frequency 449992390 Hz quality 1000 >>> Timecounters tick every 1.000 msec >>> Waiting 5 seconds for SCSI devices to settle >>> (probe6:sym0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >>> (probe6:sym0:0:6:0): CAM Status: SCSI Status Error >>> (probe6:sym0:0:6:0): SCSI Status: Check Condition >>> (probe6:sym0:0:6:0): NOT READY asc:3a,0 >>> (probe6:sym0:0:6:0): Medium not present >>> (probe6:sym0:0:6:0): Unretryable error >>> da1 at sym0 bus 0 target 1 lun 0 >>> da1: Fixed Direct Access SCSI-2 device >>> da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) >>> da1: Command Queueing Enabled >>> da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) >>> da0 at sym0 bus 0 target 0 lun 0 >>> da0: Fixed Direct Access SCSI-2 device >>> da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) >>> da0: Command Queueing Enabled >>> da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) >>> cd0 at sym0 bus 0 target 6 lun 0 >>> cd0: Removable CD-ROM SCSI-2 device >>> cd0: 10.000MB/s transfers (10.000MHz, offset 16) >>> cd0: Attempt to query device size failed: NOT READY, Medium not present >>> WARNING: WITNESS option enabled, expect reduced performance. >>> GEOM: da0: adding VTOC8 information. >>> GEOM: da1: adding VTOC8 information. >>> Trying to mount root from ufs:/dev/da0a >>> Loading configuration files. >>> kernel dumps on /dev/da0b >>> Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: >>> memory addres >>> s not aligned >>> cpuid = 0 >>> KDB: enter: panic >>> [thread pid 41 tid 100042 ] >>> Stopped at kdb_enter+0x80: ta %xcc, 1 >>> db> >>> db> bt >>> Tracing pid 41 tid 100042 td 0xfffff800213dc370 >>> panic() at panic+0x20c >>> trap() at trap+0x570 >>> -- memory address not aligned sfar=0xf2fe2877 sfsr=0x40029 >>> %o7=0xc06654b8 -- >>> stack_capture() at stack_capture+0x114 >>> stack_save_td() at stack_save_td+0x60 >>> sysctl_kern_proc_kstack() at sysctl_kern_proc_kstack+0x36c >>> sysctl_root() at sysctl_root+0x1ec >>> userland_sysctl() at userland_sysctl+0x174 >>> __sysctl() at __sysctl+0x70 >>> syscall() at syscall+0x2f0 >>> -- syscall (202, FreeBSD ELF64, __sysctl) %o7=0x101628 -- >>> userland() at 0x40445788 >>> user trace: trap %o7=0x101628 >>> pc 0x40445788, sp 0x7fdffffd031 >>> pc 0x101ef8, sp 0x7fdffffd971 >>> pc 0x102ac4, sp 0x7fdffffdaf1 >>> pc 0x100ef0, sp 0x7fdffffe451 >>> pc 0x40208094, sp 0x7fdffffe511 >>> done >> >> Hrm, this looks like the problem solved with r184376. Do you >> cross-compile with a GCC older than 4.2 maybe? > > No, I cross compile on current. cc -v: > > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > > I continue. It is a bit strange. I built a kernel with the native tools on the u60, same picture. Then I opened the machine and removed the 375-3116, a SunPCi III 1.4GHz Co-Processor Card. Rebooted again. Bingo boots fine. To be sure it is the card I retried again with the Co-Processor Card in and now it boots fine with a fresh built kernel..... Strange. Here the pciconf -lcv of the card: none0@pci1:128:1:0: class=0x068000 card=0x676a108e chip=0xb5558086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '21555 Non-Transparent PCI-to-PCI Bridge' class = bridge cap 01[dc] = powerspec 0 supports D0 D3 current D0 cap 03[e4] = VPD cap 06[ec] = unknown Well, for now I'm fine and continue with crossbuilding. Thanks for the ear. Andreas From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 20:38:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FBE106566B; Sun, 22 Mar 2009 20:38:45 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8BA8FC1D; Sun, 22 Mar 2009 20:38:44 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.148.109] (port=55672 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlURP-000Pxf-Lj; Sun, 22 Mar 2009 23:38:43 +0300 Message-ID: <49C6A1DD.1030500@lissyara.su> Date: Sun, 22 Mar 2009 23:38:53 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Robert Noland References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> <1237745742.1687.12.camel@balrog.2hip.net> <49C68B95.5020402@lissyara.su> <1237751433.1687.21.camel@balrog.2hip.net> In-Reply-To: <1237751433.1687.21.camel@balrog.2hip.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 20:38:45 -0000 Robert Noland ÐÉÛÅÔ: > On Sun, 2009-03-22 at 22:03 +0300, Alex Keda wrote: >> Robert Noland ÐÉÛÅÔ: >>> On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: >>>> Robert Noland ÐÉÛÅÔ: >>>>> On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: >>>>>> (II) RADEON(0): XAA Render acceleration unsupported on Radeon >>>>>> 9500/9700 and newer. Please use EXA instead. >>>>> Everything looks like it's ok, except that you should be using EXA. >>>>> >>>>> Option "AccelMethod" "EXA" >>>> I'm not using Xorg.conf - I always start without it - all work OK. >>>> X-system by oneself configure all parameters. >>>> >>>>> What was the last working kernel? >>>> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 14 >>>> 19:08:30 MSK 2009 >>>> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 >>>> >>>> >Actually, It looks like maybe it is waiting on hald? Did you just >>>> switch to usb2? >>>> Yes, I use GENERIC. But, old kernel with new USB stack and work correct. >>> Please make sure that hald is running and that lshal shows you mouse and >>> keyboard before we go digging any further. >> it show my mouse, my keyboard and my touchpad >> >>> The rs690 is picky about how the gart is allocated, but I had the flags >>> to bus_dmamem applied incorrectly. It should not have caused an issue >>> and all of the allocations look to be correct. >>> >>> You should probably not be running configless on this chip, as the >>> defaults are not optimum for it. >> I remove drm.ko and radeon.ko from /boot/kernel and copy it from >> /boot/kernel.old >> With new kernel and old modules - all work excellent. > > Ok, after a little discussion and looking at the bus_dma code... The > documentation is incorrect. I'll fix this up shortly... Big Thanks! From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 21:14:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6121065674 for ; Sun, 22 Mar 2009 21:14:32 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9302E8FC0C for ; Sun, 22 Mar 2009 21:14:32 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MLDAlf005655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 17:13:11 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <49C6A1DD.1030500@lissyara.su> References: <49C64AA5.3000509@lissyara.su> <1237743234.1687.7.camel@balrog.2hip.net> <49C67E10.2000202@lissyara.su> <1237745742.1687.12.camel@balrog.2hip.net> <49C68B95.5020402@lissyara.su> <1237751433.1687.21.camel@balrog.2hip.net> <49C6A1DD.1030500@lissyara.su> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-R2MwG1FO/jU0334VJnd+" Organization: FreeBSD Date: Sun, 22 Mar 2009 16:14:09 -0500 Message-Id: <1237756449.1687.25.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: last update and oldest ati|drm problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:14:33 -0000 --=-R2MwG1FO/jU0334VJnd+ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable On Sun, 2009-03-22 at 23:38 +0300, Alex Keda wrote: > Robert Noland =D0=C9=DB=C5=D4: > > On Sun, 2009-03-22 at 22:03 +0300, Alex Keda wrote: > >> Robert Noland =D0=C9=DB=C5=D4: > >>> On Sun, 2009-03-22 at 21:06 +0300, Alex Keda wrote: > >>>> Robert Noland =D0=C9=DB=C5=D4: > >>>>> On Sun, 2009-03-22 at 17:26 +0300, Alex Keda wrote: > >>>>>> (II) RADEON(0): XAA Render acceleration unsupported on Radeon > >>>>>> 9500/9700 and newer. Please use EXA instead. > >>>>> Everything looks like it's ok, except that you should be using EXA. > >>>>> > >>>>> Option "AccelMethod" "EXA" > >>>> I'm not using Xorg.conf - I always start without it - all work OK. > >>>> X-system by oneself configure all parameters. > >>>> > >>>>> What was the last working kernel? > >>>> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Mar 1= 4=20 > >>>> 19:08:30 MSK 2009=20 > >>>> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > >>>> > >>>> >Actually, It looks like maybe it is waiting on hald? Did you just > >>>> switch to usb2? > >>>> Yes, I use GENERIC. But, old kernel with new USB stack and work corr= ect. > >>> Please make sure that hald is running and that lshal shows you mouse = and > >>> keyboard before we go digging any further. > >> it show my mouse, my keyboard and my touchpad > >> > >>> The rs690 is picky about how the gart is allocated, but I had the fla= gs > >>> to bus_dmamem applied incorrectly. It should not have caused an issu= e > >>> and all of the allocations look to be correct. > >>> > >>> You should probably not be running configless on this chip, as the > >>> defaults are not optimum for it. > >> I remove drm.ko and radeon.ko from /boot/kernel and copy it from=20 > >> /boot/kernel.old > >> With new kernel and old modules - all work excellent. > >=20 > > Ok, after a little discussion and looking at the bus_dma code... The > > documentation is incorrect. I'll fix this up shortly... > Big Thanks! Ok, the fixes should be committed... robert. >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-R2MwG1FO/jU0334VJnd+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGqiEACgkQM4TrQ4qfROO+OQCeMsLPquxZh4NGeO/j0BFTwPLx 658An3RnM7cxRq0GAWEOhvCYVb9SqSiT =XCJD -----END PGP SIGNATURE----- --=-R2MwG1FO/jU0334VJnd+-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 21:16:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18841065696; Sun, 22 Mar 2009 21:16:40 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id B18678FC3E; Sun, 22 Mar 2009 21:16:39 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fxm11 with SMTP id 11so1455624fxm.43 for ; Sun, 22 Mar 2009 14:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=LXA90bUIzYwtI/6ouXkZwjnBC5wiGF1WR1CH8Id/sEg=; b=vRNBmoJWEP7rkJspTl6/WIgxhhTGPmmOe9dUWH94bvMhUPUVEyzv8A9y9o7qNcDtnY 9oknqWV2NhsUHMap0McdjlotodhbShOEjZBzBt6dGMIZv65e+ieWa1OyoVDnAD+f6vv9 q3pdCjFhACGuoW6D5Fq8ambNe7wzpsMf8/D5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=clN/1qanAmqA7k2Qwq0jJXsSJ8aasTY4Eu85gVyxQsq9sqBHDMLwmhfgOzNflqas3z GEiC5TJXy0QYm7CDpqBwiTqH1C3kKW6kc2vkLKvTPCrxgib6w8/Uo0t/DaI613XTxAuW 9N9yS9Eodlhd7+3Z5Tm/e8aqUkKWLJ4Lg87oY= Received: by 10.103.228.19 with SMTP id f19mr2751153mur.32.1237756598582; Sun, 22 Mar 2009 14:16:38 -0700 (PDT) Received: from localhost (95-24-174-59.broadband.corbina.ru [95.24.174.59]) by mx.google.com with ESMTPS id w5sm8810156mue.3.2009.03.22.14.16.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Mar 2009 14:16:37 -0700 (PDT) From: Anonymous To: Robert Noland References: <1237680263.1938.10.camel@balrog.2hip.net> Date: Mon, 23 Mar 2009 00:15:59 +0300 Message-ID: <86r60pp8c0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-x11 , freebsd-current Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:16:42 -0000 Robert Noland writes: > Ok, this patch should work on NV50 chips also. > > What you get is EXA and Xv. > > You still need: > > A recent -CURRENT or -STABLE. > > git master of libdrm and xf86-video-nouveau. > > This patch. > > Things I've figured out since the last patch... > > On NV50 class hardware you need to have a compositing manager running > for Xv to work. That means xcompmgr, metacity with composite enabled, > xfce (rumored to work as well, haven't tried). If your running Gnome > with metacity, open gconf-editor and go to apps->metacity->general and > check the composite box. [...] > > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > > robert. Here is my Xorg.log - http://pastebin.com/m6fab6feb (Xserver is from git master) and kernel messages logged via syslog DRM_DEBUG - http://pastebin.com/m263af8da They are with successfull `xcompmgr -a' run - Compared to previous patch now I get @@ -237,6 +237,7 @@ (II) NOUVEAU(0): nv50_output_detect is called. (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. (II) NOUVEAU(0): I2C device "DVI-0:ddc2" registered at address 0xA0. +(II) NOUVEAU(0): I2C device "DVI-0:DDC control interface" registered at address 0x6E. (II) NOUVEAU(0): Detected a Digital output on DVI-0 (II) NOUVEAU(0): Found a suitable output, index 1 (II) NOUVEAU(0): nv50_output_detect is called. @@ -382,8 +383,8 @@ [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (==) NOUVEAU(0): Write-combining range (0xa0000,0x10000) was already clear (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixmaps, at offset 0x20000000 -(II) NOUVEAU(0): AGPGART: 512MiB available -(EE) NOUVEAU(0): Unable to allocate GART memory +(II) NOUVEAU(0): AGPGART: 32MiB available +(II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables. (II) NOUVEAU(0): [drm] framebuffer handle = 0xe0000000 (II) NOUVEAU(0): [drm] added 1 reserved context for kernel - This error in Xorg.log is still present (II) NOUVEAU(0): [DRI] installation complete (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 Should I ignore it? - Got these errors in dmesg error: [drm:pid1424:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 and info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm] info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x00000000:0x00000000 error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x80000000 error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xfdb76b7b Should I ignore them? - Scrolling (shift+pgup/pgdn) in xterm is *slower* with DRM than without it but still faster than with NoAccel. I'm using xterm with TTF font (DejaVu Sans Mono). It's yet more noticeable when scrolling in less(1)/screen(1) when redrawing affects whole screen not half. Besides, there is more flickering with highly updating cli apps when using DRM. However, launching xcompmgr fixes this sluggishness. - XVideo works fine - EXAPixmaps uses DRI2 and works fine. I wasn't able to test with xcompmgr. - Launching `xcompmgr -a' is tricky. Most of the time it just leaves screen in unusable state, it's not possible to switch to console or move pointer. I want to help debug this one. Here are logs: http://pastebin.com/m1ca3fc2f http://pastebin.com/m579d358e From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 21:47:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAF9C106564A; Sun, 22 Mar 2009 21:47:26 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id ADC708FC12; Sun, 22 Mar 2009 21:47:26 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MLk4HY005848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 17:46:05 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Anonymous In-Reply-To: <86r60pp8c0.fsf@gmail.com> References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-BwhPknEy78+kSyEpkk4U" Organization: FreeBSD Date: Sun, 22 Mar 2009 16:47:03 -0500 Message-Id: <1237758423.1687.34.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-current Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:47:27 -0000 --=-BwhPknEy78+kSyEpkk4U Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > Robert Noland writes: >=20 > > Ok, this patch should work on NV50 chips also. > > > > What you get is EXA and Xv. > > > > You still need: > > > > A recent -CURRENT or -STABLE. > > > > git master of libdrm and xf86-video-nouveau. > > > > This patch. > > > > Things I've figured out since the last patch... > > > > On NV50 class hardware you need to have a compositing manager running > > for Xv to work. That means xcompmgr, metacity with composite enabled, > > xfce (rumored to work as well, haven't tried). If your running Gnome > > with metacity, open gconf-editor and go to apps->metacity->general and > > check the composite box. > [...] > > > > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > > > > robert. >=20 > Here is my Xorg.log - http://pastebin.com/m6fab6feb (Xserver is from git = master) > and kernel messages logged via syslog DRM_DEBUG - http://pastebin.com/m26= 3af8da > They are with successfull `xcompmgr -a' run >=20 > - Compared to previous patch now I get >=20 > @@ -237,6 +237,7 @@ > (II) NOUVEAU(0): nv50_output_detect is called. > (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. > (II) NOUVEAU(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > +(II) NOUVEAU(0): I2C device "DVI-0:DDC control interface" registered at = address 0x6E. > (II) NOUVEAU(0): Detected a Digital output on DVI-0 > (II) NOUVEAU(0): Found a suitable output, index 1 > (II) NOUVEAU(0): nv50_output_detect is called. > @@ -382,8 +383,8 @@ > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (=3D=3D) NOUVEAU(0): Write-combining range (0xa0000,0x10000) was already= clear > (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixma= ps, at offset 0x20000000 > -(II) NOUVEAU(0): AGPGART: 512MiB available > -(EE) NOUVEAU(0): Unable to allocate GART memory > +(II) NOUVEAU(0): AGPGART: 32MiB available > +(II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer > (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables. > (II) NOUVEAU(0): [drm] framebuffer handle =3D 0xe0000000 > (II) NOUVEAU(0): [drm] added 1 reserved context for kernel Ok, this is good... > - This error in Xorg.log is still present >=20 > (II) NOUVEAU(0): [DRI] installation complete > (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 >=20 > Should I ignore it? Let me switch back to the NV50 and look at that. > - Got these errors in dmesg >=20 > error: [drm:pid1424:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x2 This should be ok, it tries resource id 2, and if it can't find that it uses resource 3. It just means that resource 1 is a 64bit BAR. > and >=20 > info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo= : [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm]=20 > info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x0= 0000000:0x00000000 > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8= 0000000 > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xf= db76b7b >=20 > Should I ignore them? This I need to look at, it may be because I haven't fully implemented fencing. I thought it was ok like it was. I also just fixed an issue with allocating scatter / gather pages in -CURRENT, which may be related. > - Scrolling (shift+pgup/pgdn) in xterm is *slower* with DRM than > without it but still faster than with NoAccel. I'm using xterm with > TTF font (DejaVu Sans Mono). It's yet more noticeable when scrolling > in less(1)/screen(1) when redrawing affects whole screen not half. > Besides, there is more flickering with highly updating cli apps when > using DRM. However, launching xcompmgr fixes this sluggishness. This may be related to compositing with git server. Text rendering is causing considerable load on the Xserver with compositing enabled. The composite manager is only needed for Xv, can you try without it. > - XVideo works fine Ok, cool. > - EXAPixmaps uses DRI2 and works fine. I wasn't able to test with xcompmg= r. >=20 > - Launching `xcompmgr -a' is tricky. Most of the time it just leaves > screen in unusable state, it's not possible to switch to console or > move pointer. I want to help debug this one. Here are logs: > http://pastebin.com/m1ca3fc2f > http://pastebin.com/m579d358e I'll have to look at this, but I was able to enable/disable it ok, iirc. robert. --=20 Robert Noland FreeBSD --=-BwhPknEy78+kSyEpkk4U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGsdcACgkQM4TrQ4qfROPRMgCdEhuOOSFCFgjW1J6dX1SqP967 CmcAn1DpHMCtl/KO1EzokNWioS4ZZjhs =wRo4 -----END PGP SIGNATURE----- --=-BwhPknEy78+kSyEpkk4U-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 22:06:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1061065672 for ; Sun, 22 Mar 2009 22:06:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id C250A8FC12 for ; Sun, 22 Mar 2009 22:06:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 24659 invoked by uid 60001); 22 Mar 2009 22:06:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237759612; bh=EUu1oJsclGckG0sI7nqKzE2owGMf+4uNfqkAlHTQE3E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=B66calKP2JdMY0RvLe3WLg5TeolljLKmcNUBNO23ytjvffAUPieR6j1PpKFEdrhbOfChNvXDgcZ+HcN48aNifShj9IpkMs5c8BgVVYinwiG0djn0flMRmqAXAjXRrJCbaWpPgga3E0FuZLoVe46H740195SqGKiUY8+c/u00XoM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=okksd6mX1U5Ig7ikGtFejTSn8tZbxN2hui4O3ol7HH972QBBXxf1LvW8H6lHgXZbgyWjmG0rf9V+iiC5AVdo4HSlVKU7H1Lmv4lPBa1hti0Q4GlPM7zsx+6LRhVWaZyDm+StX4BDmfEdTPLfAb8ukutTApoK8mE3xbagjri/teE=; Message-ID: <976309.24341.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: vyMC92gVM1nin.04CQeVQdnmC9ZC.bWM3yQQNT1QT3eMuxJ6Z1KsAVOAvQtkZtFiGPE9i24d1dhiRdsYjUGeAhTyMUMi7AZ7.IuOj1LMyQjkBkkRkelMz31cT5fppyFunmvD8fFB9RWjMT8BJlsHaGpUeZ167iJbyHIzMX9WcNRd_KJkH2oY6Ix40Lu5wCUnX4aYTkQwQ32qFVeuGG91o4EGJBr8v4Ju Received: from [98.242.222.229] by web63902.mail.re1.yahoo.com via HTTP; Sun, 22 Mar 2009 15:06:52 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sun, 22 Mar 2009 15:06:52 -0700 (PDT) From: Barney Cordoba To: Scott Long In-Reply-To: <20090318150721.U22014@pooker.samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: current@freebsd.org Subject: Re: Interrupt routine usage not shown by top in 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 22:06:54 -0000 --- On Wed, 3/18/09, Scott Long wrote: > From: Scott Long > Subject: Re: Interrupt routine usage not shown by top in 8.0 > To: "Barney Cordoba" > Cc: "Sam Leffler" , current@freebsd.org > Date: Wednesday, March 18, 2009, 5:25 PM > On Wed, 18 Mar 2009, Barney Cordoba wrote: > > --- On Wed, 3/18/09, Scott Long > wrote: > >> > >> Filters were introduced into the em driver to get > around a > >> problem in > >> certain Intel chipsets that caused aliased > interrupts. > >> That's a > >> different topic of discussion that you are welcome > to > >> search the mail > >> archives on. The filter also solves performance > and > >> latency problems > >> that are inherent to the ithread model when > interrupts are > >> shared > >> between multiple devices. This is especially bad > when a > >> high speed > >> device like em shares an interrupt with a low > speed device > >> like usb. > >> In the course of testing and validating the filter > work, I > >> found that > >> filters caused no degradation in performance or > excess > >> context switches, > >> while cleanly solving the above two problems that > were > >> common on > >> workstation and server class machines of only a > few years > >> ago. > >> > >> However, both of these problems stemmed from using > legacy > >> PCI > >> interrupts. At the time, MSI was still very new > and very > >> unreliable. > >> As the state of the art progressed and MSI became > more > >> reliable, its > >> use has become more common and is the default in > several > >> drivers. The > >> igb and ixgbe drivers and hardware both prefer MSI > over > >> legacy > >> interrupts, while the em driver and hardware still > has a > >> lot of legacy > >> hardware to deal with. So when MSI is the > >> common/expected/default case, > >> there is less of a need for the filter/taskqueue > method. > >> > >> Filters rely on the driver being able to reliably > control > >> the interrupt > >> enable state of the hardware. This is possible > with em > >> hardware, but > >> not as reliable with bge hardware, so the stock > driver code > >> does not > >> have it implemented. I am running a > filter-enabled bge > >> driver in > >> large-scale production, but I also have precise > control > >> over the > >> hardware being used. I also have filter patches > for the > >> bce driver, but > >> bce also tends to prefer MSI, so there isn't > a > >> compelling reason to > >> continue to develop the patches. > >> > >> > >> Scott > > > > Assuming same technique is used within an ithread as > with a fast > > interrupt, that is: > > > > filtered_foo(){ > > taskqueue_enqueue(); > > return FILTER_HANDLED; > > } > > This will give you two context switches, one for the actual > interrupt, and > one for the taskqueue. It'll also encounter a spinlock > in the taskqueue > code, and a spinlock or two in the scheduler. > > > > > ithread_foo(){ > > taskqueue_enqueue(); > > return; > > } > > > > Is there any additional overhead/locking in the > ithread method? I'm > > looking to get better control over cpu distribution. > > > > This will give you 3 context switches. First one will be > for the actual > interrupts. Second one will be for the ithread (recall > that ithreads are > full process contexts and are scheduled as such). Third > one will be for > the taskqueue. Along with the spinlocks for the scheduler > and taskqueue > code mentioned above, there will also be spinlocks to > protect the APIC > registers, as well as extra bus cycles to service the APIC. > > So, that's 2 trips through the scheduler, plus the > associated spinlocks, > plus the overhead of going through the APIC code, whereas > the first method > only goes through the scheduler once. Both will have a > context switch to > service the low-level interrupt. The second method will > definitely have > more context switches, and will almost certainly have > higher overall > service latency and CPU usage. > > Scott Scott, I'm sure you're going to yell at me, but here I go anyway. I set up a little task that basically does: foo_task(){ while(1){ foo_doreceive(); pause("foo",1); } } which wakes hz times per second in 7 and hz/2 times per second in 8. The same accounting issue exists for this case, as I have it bridging 400K pps and usage shows 0 most of the time. I've added some firewall rules which should substantially increase the load, but still no usage. If I really hammer it, like 600Kpps, it starts registering 30% usage, with no ramp up in between. I suppose it could be just falling out of the cache or something, but it doesn't seem realistic. Is there some hack I can implement to make sure a task is accounted for, or some other way to monitor its usage? Barney From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 22:50:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB61106566C for ; Sun, 22 Mar 2009 22:50:39 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id C6D1B8FC0A for ; Sun, 22 Mar 2009 22:50:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1220847ewy.43 for ; Sun, 22 Mar 2009 15:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=cPden6mqH+gp7goIaZJK5KyNqjOhidZywHNACRynd08=; b=YOlU1NMJwjdC8wPXwTEz+nHsO1n3ijCL9GHUzlBrpl993/MtezMwuj+ppIlxsBOGpJ BnMv82pWerIGCFiGvtpiP3VgbD0kU0FUA9p2SUrVioOWU4w1404sTDq9JhTfQPjAndqk PlhlD9spLmpwPRvg3uN05h2st9yKj9cfU+M3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=jTfBY/IEPle5PzBQVJub0STGbYcUbN/lsxHKLkxYgPABgDWRk/MOZEZnd811gNcK1i cHvfkJfthXf4KQr8CZojFzZvadppJ2kz0GbeVwJmEjR8neoxeLPYJHrYG6iVOLocIPei WB3leEh08xKUFr47qKiWs2cn1G7kR4fYNSmQM= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr4901893ebc.69.1237762237894; Sun, 22 Mar 2009 15:50:37 -0700 (PDT) Date: Sun, 22 Mar 2009 23:50:37 +0100 Message-ID: <3a142e750903221550i51ef1fb5k2937fda8bfb7e47a@mail.gmail.com> From: "Paul B. Mahol" To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: empty /sys/modules/ata/ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 22:50:39 -0000 Directory /sys/modulest/ata/ata is empty and should probably be removed. btw MODULES_OVERRIDE= doesnt work with ata, for example entries: ata/atapci ata/atadisk .... are ignored and "all" modules bellow ata/ are build - but this issue is of very low priority. -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 23:07:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AEED106566B; Sun, 22 Mar 2009 23:07:33 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C15848FC08; Sun, 22 Mar 2009 23:07:32 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2MN6A7Q006321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 19:06:11 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Anonymous In-Reply-To: <86r60pp8c0.fsf@gmail.com> References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fvr0OqbkdDlmIstihsXX" Organization: FreeBSD Date: Sun, 22 Mar 2009 18:07:10 -0500 Message-Id: <1237763230.1694.0.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-current Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 23:07:33 -0000 --=-fvr0OqbkdDlmIstihsXX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > Robert Noland writes: >=20 > > Ok, this patch should work on NV50 chips also. > > > > What you get is EXA and Xv. > > > > You still need: > > > > A recent -CURRENT or -STABLE. > > > > git master of libdrm and xf86-video-nouveau. > > > > This patch. > > > > Things I've figured out since the last patch... > > > > On NV50 class hardware you need to have a compositing manager running > > for Xv to work. That means xcompmgr, metacity with composite enabled, > > xfce (rumored to work as well, haven't tried). If your running Gnome > > with metacity, open gconf-editor and go to apps->metacity->general and > > check the composite box. > [...] > > > > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > > > > robert. >=20 > Here is my Xorg.log - http://pastebin.com/m6fab6feb (Xserver is from git = master) > and kernel messages logged via syslog DRM_DEBUG - http://pastebin.com/m26= 3af8da > They are with successfull `xcompmgr -a' run >=20 > - Compared to previous patch now I get >=20 > @@ -237,6 +237,7 @@ > (II) NOUVEAU(0): nv50_output_detect is called. > (II) NOUVEAU(0): NV50ConnectorDDCDetect is called. > (II) NOUVEAU(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > +(II) NOUVEAU(0): I2C device "DVI-0:DDC control interface" registered at = address 0x6E. > (II) NOUVEAU(0): Detected a Digital output on DVI-0 > (II) NOUVEAU(0): Found a suitable output, index 1 > (II) NOUVEAU(0): nv50_output_detect is called. > @@ -382,8 +383,8 @@ > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (=3D=3D) NOUVEAU(0): Write-combining range (0xa0000,0x10000) was already= clear > (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixma= ps, at offset 0x20000000 > -(II) NOUVEAU(0): AGPGART: 512MiB available > -(EE) NOUVEAU(0): Unable to allocate GART memory > +(II) NOUVEAU(0): AGPGART: 32MiB available > +(II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer > (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables. > (II) NOUVEAU(0): [drm] framebuffer handle =3D 0xe0000000 > (II) NOUVEAU(0): [drm] added 1 reserved context for kernel >=20 > - This error in Xorg.log is still present >=20 > (II) NOUVEAU(0): [DRI] installation complete > (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 Ok, update your libdrm... this was fixed in the last few days. robert. > Should I ignore it? >=20 > - Got these errors in dmesg >=20 > error: [drm:pid1424:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x2 >=20 > and >=20 > info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo= : [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm]=20 > info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x0= 0000000:0x00000000 > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8= 0000000 > error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xf= db76b7b >=20 > Should I ignore them? >=20 > - Scrolling (shift+pgup/pgdn) in xterm is *slower* with DRM than > without it but still faster than with NoAccel. I'm using xterm with > TTF font (DejaVu Sans Mono). It's yet more noticeable when scrolling > in less(1)/screen(1) when redrawing affects whole screen not half. > Besides, there is more flickering with highly updating cli apps when > using DRM. However, launching xcompmgr fixes this sluggishness. >=20 > - XVideo works fine >=20 > - EXAPixmaps uses DRI2 and works fine. I wasn't able to test with xcompmg= r. >=20 > - Launching `xcompmgr -a' is tricky. Most of the time it just leaves > screen in unusable state, it's not possible to switch to console or > move pointer. I want to help debug this one. Here are logs: > http://pastebin.com/m1ca3fc2f > http://pastebin.com/m579d358e --=20 Robert Noland FreeBSD --=-fvr0OqbkdDlmIstihsXX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknGxJ0ACgkQM4TrQ4qfROMgngCdF1sVUgpbrwDrXVNC7FtbrK5y WkEAn1tUxCrcZGnnhA8URNZqLZf6YjRH =effa -----END PGP SIGNATURE----- --=-fvr0OqbkdDlmIstihsXX-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 00:22:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1ED10656FB; Mon, 23 Mar 2009 00:22:31 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF728FC20; Mon, 23 Mar 2009 00:22:30 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by bwz8 with SMTP id 8so1463205bwz.43 for ; Sun, 22 Mar 2009 17:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=6gTImmdT7k0FUus2uhe4PQA9gOkEa2/ddbS2diwl5Rs=; b=EKt7aHg6q6tEaOdyAI5OEH/LNmuxL6q6cSLaIczPNlVaK8oPEPxQnF56TuGMiokiFz chp+awSjK8n2wi2s3b8sAgCwLKVnImKvYJsWFopFlYPS2s6Of4BkACgW1BGnuiivaG4Q SjLIq0l0y0j/J/zYG7ERkLcKZh9NMPQYyFvVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=kBCKHlkdU4iPApL3RRRmkIrN2lQbiJwOT2XdL0+ly21oaX81hbOorOZUUCLyyyGII1 rd++XrxfPE5xKzjcQ8MJR4Wr2CrtAu3J+2GVadvaMbdLJfpBaXmyv8DpmMfx6vQTtK1U 2AvlNobJB5bPnUISfV5Eq/8GITOUVN6nXIxto= Received: by 10.103.165.18 with SMTP id s18mr2789780muo.124.1237767749252; Sun, 22 Mar 2009 17:22:29 -0700 (PDT) Received: from localhost (95-24-174-59.broadband.corbina.ru [95.24.174.59]) by mx.google.com with ESMTPS id n7sm9082335mue.36.2009.03.22.17.22.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Mar 2009 17:22:28 -0700 (PDT) From: Anonymous To: Robert Noland References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> <1237763230.1694.0.camel@balrog.2hip.net> Date: Mon, 23 Mar 2009 03:21:35 +0300 Message-ID: <86ab7dxf5c.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-x11 , freebsd-current Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 00:22:32 -0000 Robert Noland writes: > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: >> Robert Noland writes: >> >> > Ok, this patch should work on NV50 chips also. >> > >> > What you get is EXA and Xv. >> > >> > You still need: >> > >> > A recent -CURRENT or -STABLE. >> > >> > git master of libdrm and xf86-video-nouveau. >> > >> > This patch. >> > >> > Things I've figured out since the last patch... >> > >> > On NV50 class hardware you need to have a compositing manager running >> > for Xv to work. That means xcompmgr, metacity with composite enabled, >> > xfce (rumored to work as well, haven't tried). If your running Gnome >> > with metacity, open gconf-editor and go to apps->metacity->general and >> > check the composite box. >> [...] >> > >> > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >> > >> > robert. >> >> - This error in Xorg.log is still present >> >> (II) NOUVEAU(0): [DRI] installation complete >> (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 > > Ok, update your libdrm... this was fixed in the last few days. > > robert. > Oops, looks like libdrm installed here wasn't latest. Updated and this error is gone now. >> Should I ignore it? >> >> >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm] >> info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x00000000:0x00000000 >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x80000000 >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xfdb76b7b >> >> Should I ignore them? Looks like this one is not fixed in r190296M. Look into logs below. >> >> - Launching `xcompmgr -a' is tricky. Most of the time it just leaves >> screen in unusable state, it's not possible to switch to console or >> move pointer. I want to help debug this one. Here are logs: >> http://pastebin.com/m1ca3fc2f >> http://pastebin.com/m579d358e rebuild kernel, libdrm, xf86-video-nouveau, xserver just in case and reproduced the problem again http://pastebin.com/m2be24e75 http://pastebin.com/m6c80e1e From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 00:35:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51E79106589B; Mon, 23 Mar 2009 00:35:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 219518FC18; Mon, 23 Mar 2009 00:35:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2N0Yagh006775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 20:34:37 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Anonymous In-Reply-To: <86ab7dxf5c.fsf@gmail.com> References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> <1237763230.1694.0.camel@balrog.2hip.net> <86ab7dxf5c.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-wGi3POtlL/YO3AfzmrwC" Organization: FreeBSD Date: Sun, 22 Mar 2009 19:35:35 -0500 Message-Id: <1237768535.1712.3.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-current Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 00:36:02 -0000 --=-wGi3POtlL/YO3AfzmrwC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 03:21 +0300, Anonymous wrote: > Robert Noland writes: >=20 > > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > >> Robert Noland writes: > >>=20 > >> > Ok, this patch should work on NV50 chips also. > >> > > >> > What you get is EXA and Xv. > >> > > >> > You still need: > >> > > >> > A recent -CURRENT or -STABLE. > >> > > >> > git master of libdrm and xf86-video-nouveau. > >> > > >> > This patch. > >> > > >> > Things I've figured out since the last patch... > >> > > >> > On NV50 class hardware you need to have a compositing manager runnin= g > >> > for Xv to work. That means xcompmgr, metacity with composite enable= d, > >> > xfce (rumored to work as well, haven't tried). If your running Gnom= e > >> > with metacity, open gconf-editor and go to apps->metacity->general a= nd > >> > check the composite box. > >> [...] > >> > > >> > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > >> > > >> > robert. > >>=20 > >> - This error in Xorg.log is still present > >>=20 > >> (II) NOUVEAU(0): [DRI] installation complete > >> (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19 > > > > Ok, update your libdrm... this was fixed in the last few days. > > > > robert. > > >=20 > Oops, looks like libdrm installed here wasn't latest. Updated and this > error is gone now. >=20 > >> Should I ignore it? > >>=20 > >>=20 > >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORi= nfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm]=20 > >> info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data = 0x00000000:0x00000000 > >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1: > >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408900: = 0x80000000 > >> error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 0x00408904: = 0xfdb76b7b > >>=20 > >> Should I ignore them? >=20 > Looks like this one is not fixed in r190296M. Look into logs below. This is a fencing issue, I haven't ported the drm fence manager. Do you know what you are doing to trigger it? I can't seem to make it occur here... > >>=20 > >> - Launching `xcompmgr -a' is tricky. Most of the time it just leaves > >> screen in unusable state, it's not possible to switch to console or > >> move pointer. I want to help debug this one. Here are logs: > >> http://pastebin.com/m1ca3fc2f > >> http://pastebin.com/m579d358e FWIW, I don't seem to have any trouble enabling / disabling composite, so this may be a bug in git xserver or libraries. robert. > rebuild kernel, libdrm, xf86-video-nouveau, xserver just in case and > reproduced the problem again > http://pastebin.com/m2be24e75 > http://pastebin.com/m6c80e1e --=20 Robert Noland FreeBSD --=-wGi3POtlL/YO3AfzmrwC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknG2VcACgkQM4TrQ4qfROMjZwCfR1X5hVIQLorYzZ95ibTJd4Xl QqQAnRQWgWEL3ghAd96hGBm21LYSgCfI =wEs0 -----END PGP SIGNATURE----- --=-wGi3POtlL/YO3AfzmrwC-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 03:01:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0A5610656C6 for ; Mon, 23 Mar 2009 03:01:23 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 329A58FC19 for ; Mon, 23 Mar 2009 03:01:22 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.1.20]) by ns2.bafirst.com with esmtp; Sun, 22 Mar 2009 22:01:20 -0500 id 000D5188.49C6FB81.0000F34F Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Sun, 22 Mar 2009 21:01:20 -0600 id 0004AC17.49C6FB80.00006725 Received: from local69.local.net.mx (local69.local.net.mx [192.168.1.69]) by econet.encontacto.net (Horde Framework) with HTTP; Sun, 22 Mar 2009 22:01:20 -0500 Message-ID: <20090322220120.12371bwxwejma268@econet.encontacto.net> Date: Sun, 22 Mar 2009 22:01:20 -0500 From: eculp To: Joe Marcus Clarke References: <20090319210256.112653yvpxxtv7m8@econet.encontacto.net> <1237515309.31432.139.camel@shumai.marcuscom.com> In-Reply-To: <1237515309.31432.139.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.0.7) Gecko/2009031117 Firefox/3.0.4, Ant.com Toolbar 1.3 X-IMP-Server: 189.129.1.20 X-Originating-IP: 192.168.1.69 X-Originating-User: eculp@encontacto.net Cc: freebsd-current Subject: Re: I can't update to hal-0.5.11 probably because of a usb2 configuration problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 03:01:25 -0000 Quoting Joe Marcus Clarke : > On Thu, 2009-03-19 at 21:02 -0500, eculp wrote: >> I'm trying tu update hal to 0.5.11 on current for the last few days >> and now think that the problem isn't hal but me and related to my usb2 >> configuration. >> >> If anyone else has seen this or has any suggestions they would be very >> much appreciated. > > Make sure you are running the latest -CURRENT, your ports tree has hal > 0.5.11_21, you have run delete-old and delete-old-libs, and you do NOT > have devel/libusb installed. Hal will build then. Thanks, Joe. I had libusb installed and deinstalled, rebuilt hal and =20 all is well. Thanks a bunch. I don't know when I would have found it =20 without your help. Sorry it took me so much time to answer but I was traveling. thanks again, ed > > Joe > >> >> ed >> >> The port error follows: >> >> gmake[5]: Entering directory >> `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd/probing' >> cc -DHAVE_CONFIG_H -I. -I../../.. >> -DPACKAGE_SYSCONF_DIR=3D\""/usr/local/etc"\" >> -DPACKAGE_DATA_DIR=3D\""/usr/local/share"\" >> -DPACKAGE_BIN_DIR=3D\""/usr/local/bin"\" >> -DPACKAGE_LOCALE_DIR=3D\""/usr/local/share/locale"\" >> -DPACKAGE_LOCALSTATEDIR=3D\""/var"\" -I../../.. >> -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include >> -I/usr/local/include -DHAVE_CK_0_3 -O2 -pipe -fno-strict-aliasing >> -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs >> -Wpointer-arith -Wcast-align -Wsign-compare -MT probe-hiddev.o -MD -MP >> -MF .deps/probe-hiddev.Tpo -c -o probe-hiddev.o probe-hiddev.c >> probe-hiddev.c: In function 'main': >> probe-hiddev.c:81: error: 'USB_GET_REPORT_ID' undeclared (first use in >> this function) >> probe-hiddev.c:81: error: (Each undeclared identifier is reported only on= ce >> probe-hiddev.c:81: error: for each function it appears in.) >> gmake[5]: *** [probe-hiddev.o] Error 1 >> gmake[5]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd/probing' >> gmake[4]: *** [all-recursive] Error 1 >> gmake[4]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd' >> gmake[3]: *** [all-recursive] Error 1 >> gmake[3]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald= ' >> gmake[2]: *** [all] Error 2 >> gmake[2]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald= ' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11' >> gmake: *** [all] Error 2 >> *** Error code 2 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >> > -- > PGP Key : http://www.marcuscom.com/pgp.asc > From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 09:02:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11634106566B; Mon, 23 Mar 2009 09:02:18 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C4FBA8FC15; Mon, 23 Mar 2009 09:02:17 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2N90t9Q010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 05:00:56 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: wsk In-Reply-To: <49C6E5C6.60306@gddsn.org.cn> References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OVCYc2OkNPdv9TLOOPRY" Organization: FreeBSD Date: Mon, 23 Mar 2009 04:01:54 -0500 Message-Id: <1237798914.2110.24.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 09:02:18 -0000 --=-OVCYc2OkNPdv9TLOOPRY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > >Ok, this patch should work on NV50 chips also. >=20 > >What you get is EXA and Xv. >=20 > >You still need: >=20 > >A recent -CURRENT or -STABLE. >=20 > >git master of libdrm and xf86-video-nouveau. >=20 > >This patch. >=20 > >Things I've figured out since the last patch... >=20 > >On NV50 class hardware you need to have a compositing manager running > >for Xv to work. That means xcompmgr, metacity with composite enabled, > >xfce (rumored to work as well, haven't tried). If your running Gnome > >with metacity, open gconf-editor and go to apps->metacity->general and > >check the composite box. >=20 > >On NV40 class hardware, you don't need the composite manager. In fact > >(at least with Xserver 1.6 which I'm running now), if a composite > >manager is enabled, I'm seeing high cpu utilization from Xorg under some > >circumstances. I don't think this is a drm issue, but still an issue. > >For me, if I start a video using mplayer in an xterm, cpu is fine as > >long as that xterm is the foreground window. If it is not the > >foreground window, even if it isn't obscured I see the cpu utilization. > >Disabling the composite manager makes everything fine. >=20 > >http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >=20 > >robert. >=20 > get the following errors and exitThis is a pre-release version of the X s= erver from The X.Org Foundation. > It is not supported in any way. > Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > Select the "xorg" product for bugs you find in this release. > Before reporting bugs in pre-release versions please check the > latest version in the X.Org Foundation git repository. > See http://wiki.x.org/wiki/GitPage for git access instructions. >=20 > X.Org X Server 1.5.99.902 (1.6.0 RC 2) > Release Date: 2009-1-30 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.1-STABLE amd64 > Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD = 7.2-PRE > RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj= /usr/sr > c/sys/WSK amd64 > Build Date: 06 February 2009 04:22:44PM >=20 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009 > ing config file: "xorg.conf1" > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x2 > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x2 > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x2 > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x1 > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x1 > drm0: [ITHREAD] > info: [drm] Allocating FIFO number 1 > info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > info: [drm] PFIFO_DMA_PUSHER - Ch 1 > (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > (EE) Screen(s) found, but none have a usable configuration. >=20 > Fatal server error: > no screens found >=20 > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > Please also check the log file at "/var/log/Xorg.0.log" for additional in= formati > on. >=20 > info: [drm] nouveau_fifo_free: freeing fifo 1 > error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 = before > destroy.Prepare for strangeness.. > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0= x1 >=20 > what can i do ? >=20 >=20 >=20 >=20 > plain text document attachment (Xorg.0.log) > This is a pre-release version of the X server from The X.Org Foundation. > It is not supported in any way. > Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > Select the "xorg" product for bugs you find in this release. > Before reporting bugs in pre-release versions please check the > latest version in the X.Org Foundation git repository. > See http://wiki.x.org/wiki/GitPage for git access instructions. >=20 > X.Org X Server 1.5.99.902 (1.6.0 RC 2) > Release Date: 2009-1-30 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.1-STABLE amd64=20 > Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD = 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/us= r/obj/usr/src/sys/WSK amd64 > Build Date: 06 February 2009 04:22:44PM > =20 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009 > (++) Using config file: "xorg.conf1" > (=3D=3D) No Layout section. Using the first Screen section. > (=3D=3D) No screen section available. Using defaults. > (**) |-->Screen "Default Screen Section" (0) > (**) | |-->Monitor "" > (=3D=3D) No device specified for screen "Default Screen Section". > Using the first device section listed. > (**) | |-->Device "Card0" > (=3D=3D) No monitor specified for screen "Default Screen Section". > Using a default monitor configuration. > (=3D=3D) Automatically adding devices > (=3D=3D) Automatically enabling devices > (=3D=3D) No FontPath specified. Using compiled-in default. > (=3D=3D) FontPath set to: > built-ins > (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > (II) Cannot locate a core pointer device. > (II) Cannot locate a core keyboard device. > (II) The server relies on HAL to provide the list of input devices. > If no devices become available, reconfigure HAL or disable AllowEmptyInp= ut. > (II) Loader magic: 0xb20 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 5.0 > X.Org XInput driver : 4.0 > X.Org Server Extension : 2.0 > (II) Loader running on freebsd > (--) Using syscons driver with X support (version 2.0) > (--) using VT number 9 >=20 > (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xf= d000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df= 00/128, BIOS @ 0x????????/65536 Ok, thats a new one... > (II) System resource ranges: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XFree86-VidModeExtension > (II) Loading extension XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "dbe" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "glx" > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > (II) Module glx: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (=3D=3D) AIGLX disabled > (=3D=3D) Exporting typical set of GLX visuals > (II) Loading extension GLX > (II) LoadModule: "record" > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > (II) Module record: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.13.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension RECORD > (II) LoadModule: "dri" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > (II) Module dri: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "nouveau" > (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so > (II) Module nouveau: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 0.0.10 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 > (II) NOUVEAU driver for NVIDIA chipset families : > RIVA TNT (NV04) > RIVA TNT2 (NV05) > GeForce 256 (NV10) > GeForce 2 (NV11, NV15) > GeForce 4MX (NV17, NV18) > GeForce 3 (NV20) > GeForce 4Ti (NV25, NV28) > GeForce FX (NV3x) > GeForce 6 (NV4x) > GeForce 7 (G7x) > GeForce 8 (G8x) > (II) Primary Device is: PCI 01@00:00:0 > (II) resource ranges after probing: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (--) NOUVEAU(0): Chipset: "NVIDIA NV86" Hrm, NV86... I'll have to ask around about that. Meanwhile can you send me a pciconf -lvb which should at least show us the BAR configuration. Ok, my sources are telling me that this should work and that it is an NV50, or at least should work the same... Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'm not sure if it may be trashing the BARs somehow. robert. > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Loading /usr/local/lib/xorg/modules//libint10.so > (II) Module int10: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 1.0.0 > ABI class: X.Org Video Driver, version 5.0 > (II) NOUVEAU(0): Initializing int10 > (=3D=3D) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already = clear > (=3D=3D) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already = clear > (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 > (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] DRM open master succeeded. > (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 > (--) NOUVEAU(0): [drm] kernel modesetting not available > (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 > (II) NOUVEAU(0): Creating default Display subsection in Screen section > "Default Screen Section" for depth/fbbpp 24/32 > (=3D=3D) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 > (=3D=3D) NOUVEAU(0): RGB weight 888 > (=3D=3D) NOUVEAU(0): Default visual is TrueColor > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > (II) Module vgahw: vendor=3D"X.Org Foundation" > compiled for 1.5.99.902, module version =3D 0.1.0 > ABI class: X.Org Video Driver, version 5.0 > (=3D=3D) NOUVEAU(0): Randr1.2 support enabled > (=3D=3D) NOUVEAU(0): Using HW cursor > (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear > (II) UnloadModule: "nouveau" > (II) UnloadModule: "vgahw" > (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so > (II) UnloadModule: "int10" > (II) Unloading /usr/local/lib/xorg/modules//libint10.so > (EE) Screen(s) found, but none have a usable configuration. >=20 > Fatal server error: > no screens found >=20 > Please consult the The X.Org Foundation support=20 > at http://wiki.x.org > for help.=20 > Please also check the log file at "/var/log/Xorg.0.log" for additional in= formation. >=20 --=20 Robert Noland FreeBSD --=-OVCYc2OkNPdv9TLOOPRY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknHUAIACgkQM4TrQ4qfRON1qwCdHUuEDFHrZVXFoBZ6WOfn0cBu KX0An2ff+9ibGo3ATe/XevKpXVTVOgh0 =zyWo -----END PGP SIGNATURE----- --=-OVCYc2OkNPdv9TLOOPRY-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 10:36:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1614F1065670 for ; Mon, 23 Mar 2009 10:36:39 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D41C08FC27 for ; Mon, 23 Mar 2009 10:36:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2NAZHmZ011150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Mar 2009 06:35:17 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: freebsd-current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kBOfNYdCkCZsOikNN1bR" Organization: FreeBSD Date: Mon, 23 Mar 2009 05:36:15 -0500 Message-Id: <1237804575.1771.7.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Subject: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 10:36:39 -0000 --=-kBOfNYdCkCZsOikNN1bR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable So I have my i386 install on a usb hard disk, which I can only boot on one machine now. The one machine that I can make work has a bios option that reads "BIOS ehci handoff". This used to work with the old usb stack. The machines that it doesn't work on, boot the kernel, but fail to mount root, giving me the forbidding mountroot> prompt, which is immediately followed by the message saying that da0 is attached. da0 is however not listed in the available boot devices list. I tried playing around with the timeout in vfs_mount.c, but that didn't seem to have any impact. It has been suggested that this may be a "geom" timeout, but I don't know anything about the boot system really. robert. --=20 Robert Noland FreeBSD --=-kBOfNYdCkCZsOikNN1bR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknHZh8ACgkQM4TrQ4qfROOPLACfaCD4XONsoEsiwJhF4NSiNaQM 9j8AnAtymolrC5fam7eyRpdxc1653DO2 =4YbT -----END PGP SIGNATURE----- --=-kBOfNYdCkCZsOikNN1bR-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 14:19:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9297A1065670 for ; Mon, 23 Mar 2009 14:19:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 24C948FC0A for ; Mon, 23 Mar 2009 14:18:59 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by fg-out-1718.google.com with SMTP id 19so315136fgg.12 for ; Mon, 23 Mar 2009 07:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O2issZZWGoBsU5FGyQLSkfzqsoozbUTDnUgBSexO7Yk=; b=PeJvC1iDkCNkV8IH1BssxAvxJ5irvoLRQz48H3wP5DXiSjIhNI78mYmAhSPOVJFGz+ PWOUO6goMJaRU60UB+TV9lFjSdzuVMnAo97u4Q2CHi7Jdbe9XVqkLbRhMT0VjDirNnxj Zm0mzF4JiNbrPW3kaBg3u7lfK9uVHK5vMy9Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YNWPAOoGPeh3ey3VOdh9yXZvi+2DabJYiVIoGn3W87i2Lae1Xe2xldZgfKJ64ji4u5 IGFDmGcsqXI/V/ZJXjvdjt4xQsrLubyLqZxShWs312sKPB0OFj9/IAHBnK9es6e1ZxbJ ouzNFO1MCAXcPS+oQcyX570Lmf2Q4S9qR/RbE= MIME-Version: 1.0 Received: by 10.86.33.10 with SMTP id g10mr3711156fgg.44.1237817454115; Mon, 23 Mar 2009 07:10:54 -0700 (PDT) In-Reply-To: <1237804575.1771.7.camel@balrog.2hip.net> References: <1237804575.1771.7.camel@balrog.2hip.net> Date: Mon, 23 Mar 2009 10:10:54 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Robert Noland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:19:01 -0000 On Mon, Mar 23, 2009 at 6:36 AM, Robert Noland wrote: > So I have my i386 install on a usb hard disk, which I can only boot on > one machine now. ... > > robert. > > -- > Robert Noland > FreeBSD There is one more ( at least ) problem : During installation . FreeBSD 7.0 is recording number of hard disk into installed values ( for example : First disk , second disk , etc. ) . When order of disks are changed FreeBSD is NOT able to boot because of hard-coded disk numbers ( for example when second disk is made third , or first with boot ability ) . This means that always USB disks should have the SAME device number during booting . If order of attachment changes it is very likely that it will not boot successfully . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 14:30:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E7651065674 for ; Mon, 23 Mar 2009 14:30:20 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id AAB348FC24 for ; Mon, 23 Mar 2009 14:30:19 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by fg-out-1718.google.com with SMTP id 19so316624fgg.12 for ; Mon, 23 Mar 2009 07:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KxKClUCG1/8zzxopbfCsS6CYzT++3i7fpb5jcAEHkWw=; b=v+tfctHvEwTyrbDr+IzfcD5spf5nMicln9O58qBxWwzpwAF0C+McTd689x4yJj1W+1 JjnqOzt9qlgOvGOZBxZKaBWs0OSgJS4M9pkJZ3QSbK4+M2tC5t7z8WBuT2+7QYRKPDKl B3Qe/dIQSMbOmOZngVnG2pt6lImRHG9iJaKMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WDwI1g4/iWuI/fWr3lLynsvNQteBkcqtVyLPnAeLPT7cqXPxHaH8LWm4FjvhBeaXcd fNTRPK9QvO6hjESBn0gMRT7cqegTGjrsX+Qdj6S9RAROsGOEeOo1+geCLleycEPg0UpT Nv86ACAA/dDYJIMDsP4joKWL93/mp9nfDSAsQ= MIME-Version: 1.0 Received: by 10.86.100.16 with SMTP id x16mr3680969fgb.68.1237816903443; Mon, 23 Mar 2009 07:01:43 -0700 (PDT) In-Reply-To: <1237804575.1771.7.camel@balrog.2hip.net> References: <1237804575.1771.7.camel@balrog.2hip.net> Date: Mon, 23 Mar 2009 10:01:43 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Robert Noland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:30:21 -0000 On Mon, Mar 23, 2009 at 6:36 AM, Robert Noland wrote: > So I have my i386 install on a usb hard disk, which I can only boot on > one machine now. ... > > robert. > > -- > Robert Noland > FreeBSD My ideas is NOT related directly to the above message but based on my observation presented below . In a PC I have installed 7.0 . Then I have changed the PC ( or I have attached the hard disk to another PC ) . The mainboards were the same Intel DG965WH . but processors were different . In the new PC . FreeBSD could NOT be booted successfully . It locked during booting . Power disconnected and the PC re-powered could be booted in a new try but not in other tries . When I attached the hard disk to its original PC it continuously booted successfully . This means that during booting . FreeBSD is looking some values stored during installation ( for example : Signature of PC ) . When hard disk is attached to another PC and signature of new PC is different from the previous one , it is not booting successfully . Consequence of this is that when a USB hard disk is used then it will NOT be transportable to other PCs unless booting is made insensitive to such changes . I am also using Mandriva Linux Free 2008.0 . It is able to boot in different machines . During installation it is possible to make an install parameters diskette to store installation parameters and use this diskette for other installations to give installation parameters directly from diskette . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 14:55:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF1491065675; Mon, 23 Mar 2009 14:55:11 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id AD5128FC33; Mon, 23 Mar 2009 14:55:11 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 15A9971F1A5; Mon, 23 Mar 2009 10:39:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEqyb+RFbIVE; Mon, 23 Mar 2009 10:39:02 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id E778171F19B; Mon, 23 Mar 2009 10:39:02 -0400 (EDT) Message-ID: <49C79F06.4080908@egr.msu.edu> Date: Mon, 23 Mar 2009 10:39:02 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.19 (X11/20090307) MIME-Version: 1.0 To: Robert Noland References: <1237804575.1771.7.camel@balrog.2hip.net> In-Reply-To: <1237804575.1771.7.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:55:12 -0000 Robert Noland wrote: > So I have my i386 install on a usb hard disk, which I can only boot on > one machine now. The one machine that I can make work has a bios option > that reads "BIOS ehci handoff". This used to work with the old usb > stack. The machines that it doesn't work on, boot the kernel, but fail > to mount root, giving me the forbidding mountroot> prompt, which is > immediately followed by the message saying that da0 is attached. da0 is > however not listed in the available boot devices list. I tried playing > around with the timeout in vfs_mount.c, but that didn't seem to have any > impact. It has been suggested that this may be a "geom" timeout, but I > don't know anything about the boot system really. > > robert. > > Is this a recent build of -current from the last few weeks? I seem to recall some fixes went in to delay the root mount to address this issue. From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 14:56:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EA01065675 for ; Mon, 23 Mar 2009 14:56:37 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from zeeb.org (zeeb.org [88.198.32.244]) by mx1.freebsd.org (Postfix) with ESMTP id 206C38FC16 for ; Mon, 23 Mar 2009 14:56:36 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from mwest by zeeb.org with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlkpA-0009jX-VB for freebsd-current@freebsd.org; Mon, 23 Mar 2009 14:08:20 +0000 Date: Mon, 23 Mar 2009 14:08:20 +0000 From: Matthew West To: freebsd-current@freebsd.org Message-ID: <20090323140820.GA37093@zeeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Matthew West Subject: panic: Bad link elm, nfsd related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:56:38 -0000 FreeBSD 8-CURRENT, built from sources around 27/02/2009: FreeBSD foo.internal 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Feb 27 12:43:45 GMT 2009 mwest@foo.internal:/usr/obj/usr/src/sys/DEBUGLOCK amd64 The system is AMD64, with 16GB of RAM, serving a few clients via NFS (v2 and v3) and Samba, from a 800GB ZFS pool; using hardware RAID (aac controller), not RAID-Z. Running a GENERIC kernel, but with the standard deadlock debugging options enabled. After 1-2 weeks, the system will panic with the following: ---------- panic: Bad link elm 0xffffff0011febc00 next->prev != elm cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 xprt_unregister_locked() at xprt_unregister_locked+0xbe xprt_unregister() at xprt_unregister+0x2c svc_run_internal() at svc_run_internal+0x42f svc_thread_start() at svc_thread_start+0xb fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0xc, rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- KDB: enter: panic [thread pid 920 tid 100272 ] Stopped at kdb_enter+0x3d: movq $0,0x65ba38(%rip) db> bt Tracing pid 920 tid 100272 td 0xffffff000649a000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b xprt_unregister_locked() at xprt_unregister_locked+0xbe xprt_unregister() at xprt_unregister+0x2c svc_run_internal() at svc_run_internal+0x42f svc_thread_start() at svc_thread_start+0xb fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0xc, rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- db> ps pid ppid pgrp uid state wmesg wchan cmd [ ... ] 920 919 919 0 R (threaded) nfsd [ ... ] db> panic < machine hangs hard and needs to be power cycled > ---------- Unfortunately, whenever I attempt to get the system to do a kernel core dump, it simply hangs... Even if I panic the machine by sending a break it doesn't work: ---------- db> cont Uptime: 10m22s Physical memory: 3056 MB Dumping 252 MB: 237 221 205 189 173 157 141Error dumping block 0x0 ** DUMP FAILED (ERROR 5) ** aac0: shutting down controller...FAILED. ---------- I've done some searching through the archives, but can't find anything useful. Does anyone have any clues for me on: 1) How to get a kernel crash dump out of KDB in 8-CURRENT at the moment? 2) What the problem with nfsd is? Thanks, Matthew From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 15:23:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C1B106564A for ; Mon, 23 Mar 2009 15:23:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id B9EA28FC26 for ; Mon, 23 Mar 2009 15:23:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.213.128] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id n2NFNnVF057010; Mon, 23 Mar 2009 11:23:52 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Mon, 23 Mar 2009 11:23:48 -0400 User-Agent: KMail/1.9.10 References: <8CB78F29832919B-1574-3D1E@WEBMAIL-MY24.sysops.aol.com> <20090322155457.GB88917@cicely7.cicely.de> <20090322163140.GB78270@citylink.fud.org.nz> In-Reply-To: <20090322163140.GB78270@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903231123.48762.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: debardeleben@aol.com, ticso@cicely.de, Andrew Thompson , freebsd@cfdhome.com Subject: Re: Suggested fix for USB printer (ulpt.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 15:23:58 -0000 On Sunday 22 March 2009 12:31:40 pm Andrew Thompson wrote: > On Sun, Mar 22, 2009 at 04:54:57PM +0100, Bernd Walter wrote: > > Interesting - I have problems with ulpt as well: > > ulpt0: > 1.00/0.06, addr 3> on usbus2 ulpt0: using bi-directional mode > > ulpt1: > > on usbus1 ulpt1: using bi-directional mode > > ulpt1: out of paper > > ulpt2: > 1.00/2.02, addr 5> on usbus1 ulpt2: using bi-directional mode > > ulpt2: out of paper > > > > ulpt0 prints and the others are just plugged in cables. > > > > But none of them is listed with usbconfig: > > Does this fix the usbconfig printing? > > http://people.freebsd.org/~thompsa/usb_dev.diff The patch allows me to print again as well. (Previously printer would do nothing and jobs would stay 'processing' indefinitely.) JN From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 16:05:01 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152C91065674; Mon, 23 Mar 2009 16:05:01 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id BA72F8FC14; Mon, 23 Mar 2009 16:05:00 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.21.165] (helo=beastie.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlmdA-000F87-M6; Tue, 24 Mar 2009 00:04:04 +0800 Message-ID: <49C7B32A.202@micom.mng.net> Date: Tue, 24 Mar 2009 00:04:58 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.19 (X11/20090127) MIME-Version: 1.0 To: Weongyo Jeong References: <49C273C2.9000808@micom.mng.net> <20090320055944.GB22527@weongyo.cdnetworks.kr> In-Reply-To: <20090320055944.GB22527@weongyo.cdnetworks.kr> X-Enigmail-Version: 0.95.7 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: ndis related panic in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:05:01 -0000 Weongyo Jeong wrote: > On Fri, Mar 20, 2009 at 12:33:06AM +0800, Ganbold wrote: > >> Hi, >> >> When I tried to make wlan0 down (ndis driver for Intel 5100AGN) got >> panic: >> ... >> Slab at 0x8cdd7cb8, freei 86 = 0. >> panic: Duplicate free of item 0x8cdd7560 from zone 0x8148c380(16) >> >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(80a5d82b,84e06ba0,80729ff9,80a8d790,0,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(80a8d790,0,80a810e5,84e06bac,0,...) at kdb_backtrace+0x29 >> panic(80a810e5,8cdd7560,8148c380,80a2c3b6,8,...) at panic+0x119 >> uma_dbg_free(8148c380,8cdd7cb8,8cdd7560,9dc,8574286c,...) at >> uma_dbg_free+0x17b >> uma_zfree_arg(8148c380,8cdd7560,8cdd7cb8,24,85742800,...) at >> uma_zfree_arg+0x6e >> free(8cdd7560,80b2c4e0,88c3a1ec,cb3,854e8800,...) at free+0xca >> ndis_stop(84e06c80,80cc13d8,85176964,80cc13d8,80b2e344,...) at >> ndis_stop+0xe6 >> ndis_ioctl_80211(854e8800,80206910,0,84e06cd4,807623cb,...) at >> ndis_ioctl_80211+0x388 >> parent_updown(854e8800,1,80a5ef36,54,85247b9c,...) at parent_updown+0x22 >> taskqueue_run(85247b80,85247b9c,0,80a511b5,0,...) at taskqueue_run+0x10b >> taskqueue_thread_loop(80b94068,84e06d38,80a56585,32d,80b7f400,...) at >> taskqueue_thread_loop+0x68 >> fork_exit(807624c0,80b94068,84e06d38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0x84e06d70, ebp = 0 --- >> Uptime: 2h9m2s >> Physical memory: 1979 MB >> Dumping 400 MB: 385 369 353 337 321 305 289 273 257 241 225 209 193 177 >> 161 145 129 113 97 81 65 49 33 17 1 >> ... >> >> I'm running: >> beastie# uname -an >> FreeBSD beastie.micom.mng.net 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >> r190040M: Thu Mar 19 21:45:37 ULAT 2009 >> tsgan@beastie.micom.mng.net:/usr/obj/usr/src/sys/DEVIL_WITNESS i386 >> >> Please let me know if you need more info. >> >> thanks, >> > > Just for preventing a panic could you please try to test attached patch > though I'm not sure the patch is helpful? > Just tested the patch, no more panic. thanks, Ganbold > regards, > Weongyo Jeong > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- I always choose my friends for their good looks and my enemies for their good intellects. Man cannot be too careful in his choice of enemies. -- Oscar Wilde, "The Picture of Dorian Gray" From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 16:26:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC521065694; Mon, 23 Mar 2009 16:26:08 +0000 (UTC) (envelope-from doug@bitnix.ca) Received: from fep5.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD1A8FC0A; Mon, 23 Mar 2009 16:26:08 +0000 (UTC) (envelope-from doug@bitnix.ca) Received: from srv.cnd.dundas.on.ca (d39-186-104.home1.cgocable.net [72.39.186.104]) by fep5.cogeco.net (Postfix) with ESMTP id 4D79112FA; Mon, 23 Mar 2009 11:41:26 -0400 (EDT) Received: from monk.cnd.dundas.on.ca (monk.cnd.dundas.on.ca [10.87.0.20]) by srv.cnd.dundas.on.ca (8.14.3/8.14.3) with ESMTP id n2NFfPNm034332; Mon, 23 Mar 2009 11:41:26 -0400 (EDT) (envelope-from doug@bitnix.ca) Received: from monk.cnd.dundas.on.ca (localhost [127.0.0.1]) by monk.cnd.dundas.on.ca (8.14.3/8.14.3) with ESMTP id n2NFfP6f002755; Mon, 23 Mar 2009 11:41:25 -0400 (EDT) (envelope-from doug@monk.cnd.dundas.on.ca) Message-Id: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> To: freebsd-current In-reply-to: Your message of "Mon, 23 Mar 2009 05:36:15 CDT." <1237804575.1771.7.camel@balrog.2hip.net> From: "Douglas Berry" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Mar 2009 11:41:25 -0400 Sender: doug@bitnix.ca Cc: Robert Noland Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Douglas Berry List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:26:09 -0000 On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: > So I have my i386 install on a usb hard disk, which I can only boot > on one machine now. The one machine that I can make work has a bios > option that reads "BIOS ehci handoff". This used to work with the > old usb stack. The machines that it doesn't work on, boot the > kernel, but fail to mount root, giving me the forbidding mountroot> > prompt, which is immediately followed by the message saying that da0 > is attached. da0 is however not listed in the available boot > devices list. I tried playing around with the timeout in > vfs_mount.c, but that didn't seem to have any impact. It has been > suggested that this may be a "geom" timeout, but I don't know > anything about the boot system really. I have been using tunefs(8) labeled partitions on my usb hard disk under CURRENT. I changed the fstab entries to match the labels (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) It works well on most systems. On some systems, I see the symptom you show, but I am saved by the labels showing up just after the mountroot prompt. I am then able to type ufs:/dev/ufs/myroot and resume the boot. Maybe this helps you? cheers, doug From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 16:45:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9562A106564A for ; Mon, 23 Mar 2009 16:45:32 +0000 (UTC) (envelope-from emaste@jem.dhs.org) Received: from maste.org (emaste.tor.istop.com [66.11.182.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACC18FC19 for ; Mon, 23 Mar 2009 16:45:32 +0000 (UTC) (envelope-from emaste@jem.dhs.org) Received: by maste.org (Postfix, from userid 1001) id DA9BF21; Mon, 23 Mar 2009 16:38:40 +0000 (UTC) X-Original-To: ed@jem.dhs.org Delivered-To: emaste@maste.org Received: from gw2.sandvine.com (unknown [64.235.97.59]) by maste.org (Postfix) with ESMTP id 0CE5518 for ; Mon, 23 Mar 2009 15:39:16 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw2.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 11:25:50 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 6616D115D9; Mon, 23 Mar 2009 11:25:50 -0400 (EDT) Date: Mon, 23 Mar 2009 11:23:36 -0400 From: Ed Maste To: Barney Cordoba Message-ID: <20090323152336.GA74200@sandvine.com> Mail-Followup-To: Ed Maste , Barney Cordoba , Scott Long , current@freebsd.org References: <20090318150721.U22014@pooker.samsco.org> <976309.24341.qm@web63902.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <976309.24341.qm@web63902.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.1i Resent-From: emaste@phaedrus.sandvine.ca Resent-Date: Mon, 23 Mar 2009 11:25:50 -0400 Resent-To: ed@jem.dhs.org Resent-Message-Id: <20090323152550.6616D115D9@labgw2.phaedrus.sandvine.com> X-OriginalArrivalTime: 23 Mar 2009 15:25:50.0770 (UTC) FILETIME=[A5F3D120:01C9ABCB] Resent-From: emaste@jem.dhs.org Resent-Date: Mon, 23 Mar 2009 16:38:40 +0000 Resent-To: freebsd-current@freebsd.org Cc: current@freebsd.org Subject: Re: Interrupt routine usage not shown by top in 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:45:32 -0000 On Sun, Mar 22, 2009 at 03:06:52PM -0700, Barney Cordoba wrote: > I set up a little task that basically does: > > foo_task(){ > > while(1){ > foo_doreceive(); > pause("foo",1); > } > > } > > which wakes hz times per second in 7 and hz/2 times per second in > 8. The same accounting issue exists for this case, as I have it bridging > 400K pps and usage shows 0 most of the time. I've added some firewall > rules which should substantially increase the load, but still no usage. > If I really hammer it, like 600Kpps, it starts registering 30% usage, > with no ramp up in between. I suppose it could be just falling out of the > cache or something, but it doesn't seem realistic. > > Is there some hack I can implement to make sure a task is > accounted for, or some other way to monitor its usage? There are aliasing issues caused by driving the scheduler and the stat clock from the same source. It's particularly bad in our environment at work, so we reverted the clock sharing, and went back to using the i8254 for stats. If you're interested in giving this a try, I've posted the patch at . This is against 6.1 and might have some other minor changes, but the diff is small enough that you could easily apply it by hand as well. If you do try it out let me know what you find. -Ed From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 17:27:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED58D106564A for ; Mon, 23 Mar 2009 17:27:08 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 98AE08FC23 for ; Mon, 23 Mar 2009 17:27:08 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2NHPMdI013290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 13:25:22 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Adam McDougall In-Reply-To: <49C79F06.4080908@egr.msu.edu> References: <1237804575.1771.7.camel@balrog.2hip.net> <49C79F06.4080908@egr.msu.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1bDlXm/kMJ3ANZNoYXK5" Organization: FreeBSD Date: Mon, 23 Mar 2009 12:26:20 -0500 Message-Id: <1237829180.1771.11.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:27:09 -0000 --=-1bDlXm/kMJ3ANZNoYXK5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 10:39 -0400, Adam McDougall wrote: > Robert Noland wrote: > > So I have my i386 install on a usb hard disk, which I can only boot on > > one machine now. The one machine that I can make work has a bios optio= n > > that reads "BIOS ehci handoff". This used to work with the old usb > > stack. The machines that it doesn't work on, boot the kernel, but fail > > to mount root, giving me the forbidding mountroot> prompt, which is > > immediately followed by the message saying that da0 is attached. da0 i= s > > however not listed in the available boot devices list. I tried playing > > around with the timeout in vfs_mount.c, but that didn't seem to have an= y > > impact. It has been suggested that this may be a "geom" timeout, but I > > don't know anything about the boot system really. > > > > robert. > > > > =20 > Is this a recent build of -current from the last few weeks? I seem to=20 > recall some fixes went in to delay the root mount to address this issue. Yes, this is HEAD from last night. It does suggest that it is waiting for ushub4, (that is the code from vfs_mount.c), this appears to be another issue, possibly with geom identification. robert. --=20 Robert Noland FreeBSD --=-1bDlXm/kMJ3ANZNoYXK5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknHxjwACgkQM4TrQ4qfRONFEACfaWEDZ1cMCJteN91FTgqcLRLi 7RYAn0fTve75HDVSdXert75RXT3BSr2f =dc+T -----END PGP SIGNATURE----- --=-1bDlXm/kMJ3ANZNoYXK5-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 17:30:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D35BC1065672 for ; Mon, 23 Mar 2009 17:30:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8081C8FC2E for ; Mon, 23 Mar 2009 17:30:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2NHTBdu013303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 13:29:12 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Douglas Berry In-Reply-To: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-S69OQJyjpzcTUzjYALa/" Organization: FreeBSD Date: Mon, 23 Mar 2009 12:30:09 -0500 Message-Id: <1237829409.1771.13.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:30:35 -0000 --=-S69OQJyjpzcTUzjYALa/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: > On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: > > So I have my i386 install on a usb hard disk, which I can only boot > > on one machine now. The one machine that I can make work has a bios > > option that reads "BIOS ehci handoff". This used to work with the > > old usb stack. The machines that it doesn't work on, boot the > > kernel, but fail to mount root, giving me the forbidding mountroot> > > prompt, which is immediately followed by the message saying that da0 > > is attached. da0 is however not listed in the available boot > > devices list. I tried playing around with the timeout in > > vfs_mount.c, but that didn't seem to have any impact. It has been > > suggested that this may be a "geom" timeout, but I don't know > > anything about the boot system really. >=20 > I have been using tunefs(8) labeled partitions on my usb hard disk > under CURRENT. I changed the fstab entries to match the labels > (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) > It works well on most systems. On some systems, I see the symptom > you show, but I am saved by the labels showing up just after the > mountroot prompt. I am then able to type >=20 > ufs:/dev/ufs/myroot >=20 > and resume the boot. Maybe this helps you? Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a doesn't work from the rootmount> prompt. Even after da0 shows up. robert. >=20 > cheers, > doug >=20 --=20 Robert Noland FreeBSD --=-S69OQJyjpzcTUzjYALa/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknHxyEACgkQM4TrQ4qfROO97wCffYuPOomXPXSBZpUv/MPdxjGj QWgAoIkySfP/ePVAuxVvC8vbdChAKr1O =jFBe -----END PGP SIGNATURE----- --=-S69OQJyjpzcTUzjYALa/-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 17:52:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C40831065711 for ; Mon, 23 Mar 2009 17:52:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8675D8FC08 for ; Mon, 23 Mar 2009 17:52:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 1125146B43; Mon, 23 Mar 2009 13:52:16 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2NHq3kV054662; Mon, 23 Mar 2009 13:52:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Mars G Miro Date: Mon, 23 Mar 2009 11:58:27 -0400 User-Agent: KMail/1.9.7 References: <200903201242.09167.jhb@freebsd.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: <200903231158.28121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Mar 2009 13:52:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9153/Mon Mar 23 11:37:27 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:52:21 -0000 On Friday 20 March 2009 11:08:35 pm Mars G Miro wrote: > On Sat, Mar 21, 2009 at 12:42 AM, John Baldwin wrote: > > On Thursday 19 March 2009 11:24:24 pm Mars G Miro wrote: > >> On Thu, Mar 19, 2009 at 11:26 PM, John Baldwin wrote: > >> > On Monday 16 March 2009 12:10:21 am Mars G Miro wrote: > >> >> On Mon, Mar 16, 2009 at 11:31 AM, Pyun YongHyeon > > wrote: > >> >> > On Mon, Mar 16, 2009 at 10:22:40AM +0800, Mars G Miro wrote: > >> >> >> Hi guys, > >> >> >> > >> >> >> =A0 =A0I upgraded a box w/ sk and msk NICs running 7.1-RELEASE t= o=20 latest > >> >> >> -CURRENT =A0to try out the new USB2 stuff but my sk/msk NICs don= 't=20 work > >> >> >> anymore: > >> >> >> > >> >> >> =A0 =A0http://pastebin.com/m28a41b14 > >> >> >> > >> >> >> =A0 =A0Saw this first last Friday, March 13, and re-csup'd a few= hours=20 ago > >> >> >> and the problem is still there. > >> >> >> > >> >> >> =A0 =A0Any thoughts? Thanks. > >> >> >> > >> >> > > >> >> > I don't see sk(4)/msk(4) hardwares in your dmesg output. > >> >> > Does "pciconf -lcv" show your controller? > >> >> > >> >> That's the problem, the hardware disappears: > >> > > >> > What if you set 'hw.pci.mcfg=3D0' in loader? > >> > > >> > >> That did it! Even w/ ACPI enabled in the BIOS, the sk/msk NICs don't > >> get lost anymore. > >> > >> pciconf and verbose dmesg: http://pastebin.com/f31621191 > >> > >> btw, what does this knob actually do ? > > > > mcfg is a mechanism for doing faster PCI config access using a memory=20 mapped > > window. =A0Can you grab the output of 'acpidump -t'? > > >=20 > /* > MCFG: Length=3D60, Revision=3D1, Checksum=3D46, > OEMID=3DIntelR, OEM Table ID=3DAWRDACPI, OEM Revision=3D0x42302e3= 1, > Creator ID=3DAWRD, Creator Revision=3D0x0 >=20 > Base Address=3D 0x00000000e0000000 > Segment Group=3D 0x0000 > Start Bus=3D 0 > End Bus=3D 0 > */ Hmm, your BIOS is rather buggy and claims to only support MCFG for bus 0. = I=20 will work on a fix. I think I will make the code fall back to the old conf= ig=20 mechanism when an MCFG region doesn't include the requested bus. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 18:21:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37041065675 for ; Mon, 23 Mar 2009 18:21:20 +0000 (UTC) (envelope-from hayarms@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 7886F8FC24 for ; Mon, 23 Mar 2009 18:21:19 +0000 (UTC) (envelope-from hayarms@gmail.com) Received: by fxm11 with SMTP id 11so1809633fxm.43 for ; Mon, 23 Mar 2009 11:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Um0WKBXsFnJJwlfyW+Fp1WkGGm1TtD6cnX4Hx6fGF7s=; b=QpCA92AqrckFGdOPl1vSH5zpZ055RY4N3GIe6hUXpRF+eAG6V9E2qCpig5XzN75euy Kq4I8OXNGgM7Fllooow+KvozHeI9cXjgpU/Hfw0GBnXovNJGF4LSqhYqaR4irx5d5+QQ nwQRr7dvgJ5MVybq/3qTjqwBRIXvh3PUigniI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VsVYhJOGeCjVX5y+xAJYrEGKzVyMULZ5FO3ZNlSnapDAqwOe83ylPIMU1REiEvb8rL AkrR093C55xyVY04Q7RGpLrZEtJYPHYno6OPqVfI/CV1syvu4IFJKoC0Dri/4tlBgiZU umQLoDFbDRryr0YlZJulDFTZJG5Pkkjq1pss4= MIME-Version: 1.0 Received: by 10.103.131.18 with SMTP id i18mr3204525mun.74.1237832478471; Mon, 23 Mar 2009 11:21:18 -0700 (PDT) Date: Mon, 23 Mar 2009 18:21:18 +0000 Message-ID: <63f529680903231121i60c7205r5d373215fb7f38b9@mail.gmail.com> From: Marcello Maggioni To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001636416b432bb5b30465cd55fe X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Asus EEE PC 1000HE power states : only C1 available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 18:21:21 -0000 --001636416b432bb5b30465cd55fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I've just compiled FREEBSD-CURRENT on my new ASUS EEE PC 1000HE (Intel ATOM powered) and everything seems to work well as of now (wireless included), but I have a problem with CX power states. The Intel Atom processor should have a lot of CX power states, but only the C1 state is reported in oid "dev.cpu.0.cx_supported" . I sent, as an attachment my dmesg log , sysctl -a output and acpidump -t -d output. I have an SMP kernel and it find and use my logical (Hyperthreading) cpu. Is this a bug, a problem with SMP kernels (haven't tried UP kernel) or simply this CPU is not yet supported by FREEBSD acpi? Cheers, Maggioni Marcello --001636416b432bb5b30465cd55fe Content-Type: application/octet-stream; name="dmesg.log" Content-Disposition: attachment; filename="dmesg.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fsnjmk5j0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQ1VSUkVOVCAjMDogTW9uIE1hciAyMyAxNDoy MTo0NyBVVEMgMjAwOQogICAgaGFkZXNAdGViZTovdXNyL29iai91c3Ivc3JjL3N5cy9BVE9NClRp bWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50 ZWwoUikgQXRvbShUTSkgQ1BVIE4yODAgICBAIDEuNjZHSHogKDE2NjIuNTEtTUh6IDY4Ni1jbGFz cyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgxMDZjMiAgU3RlcHBpbmcg PSAyCiAgRmVhdHVyZXM9MHhiZmU5ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NDBjMzlkPFNTRTMsRFRF UzY0LE1PTixEU19DUEwsRVNULFRNMixTU1NFMyx4VFBSLFBEQ00sPGIyMj4+CiAgQU1EIEZlYXR1 cmVzPTB4MTAwMDAwPE5YPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRl IGludmFyaWFudAogIExvZ2ljYWwgQ1BVcyBwZXIgY29yZTogMgpyZWFsIG1lbW9yeSAgPSAxMDY0 OTYwMDAwICgxMDE1IE1CKQphdmFpbCBtZW1vcnkgPSAxMDMzMTE3Njk2ICg5ODUgTUIpCkFDUEkg QVBJQyBUYWJsZTogPEFfTV9JXyBPRU1BUElDID4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29y IFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAo QVAvSFQpOiBBUElDIElEOiAgMQppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDIKaW9hcGlj MCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAK YWNwaTA6IDxBX01fSV8gT0VNUlNEVD4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQph Y3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAw ICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgM2Y3MDAwMDAgKDMpIGZh aWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5 IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4 MDgtMHg4MGIgb24gYWNwaTAKYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgx Yz4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKYWNwaV9ocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2 ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGltZWNvdW50 ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMApwY2liMDogPEFDUEkg SG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4 ZGMwMC0weGRjMDcgbWVtIDB4ZjdmMDAwMDAtMHhmN2Y3ZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZm ZmYsMHhmN2VjMDAwMC0weGY3ZWZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdw MDogPEludGVsIDk0NUdNRSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAKYWdwMDogZGV0ZWN0 ZWQgNzkzMmsgc3RvbGVuIG1lbW9yeQphZ3AwOiBhcGVydHVyZSBzaXplIGlzIDI1Nk0KdmdhcGNp MTogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGY3ZjgwMDAwLTB4ZjdmZmZmZmYgYXQg ZGV2aWNlIDIuMSBvbiBwY2kwCmhkYWMwOiA8SW50ZWwgODI4MDFHIEhpZ2ggRGVmaW5pdGlvbiBB dWRpbyBDb250cm9sbGVyPiBtZW0gMHhmN2ViODAwMC0weGY3ZWJiZmZmIGlycSAxNiBhdCBkZXZp Y2UgMjcuMCBvbiBwY2kwCmhkYWMwOiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDA5MDMxNl8wMTMw CmhkYWMwOiBbSVRIUkVBRF0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQg ZGV2aWNlIDI4LjAgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaTM6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCmFsZTA6IDxBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4 MTE0IFBDSWUgRXRoZXJuZXQ+IHBvcnQgMHhlYzAwLTB4ZWM3ZiBtZW0gMHhmYmZjMDAwMC0weGZi ZmZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTMKYWxlMDogOTYwIFR4IEZJRk8sIDEw MjQgUnggRklGTwphbGUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcy4KbWlpYnVzMDogPE1JSSBidXM+ IG9uIGFsZTAKYXRwaHkwOiA8QXRoZXJvcyBGMSAxMC8xMDAvMTAwMCBQSFk+IFBIWSAwIG9uIG1p aWJ1czAKYXRwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgMTAwMGJhc2VULUZEWCwgYXV0bwphbGUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyNDo4 Yzo0Nzo4Njo1ZAphbGUwOiBbRklMVEVSXQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGly cSAxOSBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIz CmF0aDA6IDxBdGhlcm9zIDkyODA+IG1lbSAweGZiZWYwMDAwLTB4ZmJlZmZmZmYgaXJxIDE5IGF0 IGRldmljZSAwLjAgb24gcGNpMQphdGgwOiBbSVRIUkVBRF0KYXRoMDogQVI5MjgwIG1hYyAxMjgu MiBSRjUxMzMgcGh5IDEzLjAKdWhjaTA6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g cG9ydCAweGQ0MDAtMHhkNDFmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kwOiBb SVRIUkVBRF0KdWhjaTA6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czA6IDxVSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gb24gdWhjaTAKdWhjaTE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcj4gcG9ydCAweGQ0ODAtMHhkNDlmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVo Y2kxOiBbSVRIUkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czE6IDxVSENJIChnZW5l cmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTEKdWhjaTI6IDxVSENJIChnZW5lcmljKSBVU0Ig Y29udHJvbGxlcj4gcG9ydCAweGQ4MDAtMHhkODFmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBw Y2kwCnVoY2kyOiBbSVRIUkVBRF0KdWhjaTI6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czI6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTIKdWhjaTM6IDxVSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGQ4ODAtMHhkODlmIGlycSAxNiBhdCBkZXZpY2UgMjku MyBvbiBwY2kwCnVoY2kzOiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czM6 IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTMKZWhjaTA6IDxJbnRlbCA4 MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdlYjdjMDAtMHhmN2Vi N2ZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMDogW0lUSFJFQURdCnVzYnVz NDogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czQ6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAy LjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9u IGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0g3TSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHgx ZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2Ug MzEuMiBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTA6IFtJVEhS RUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGExOiBbSVRIUkVBRF0KYWNw aV9hc3VzMDogPEFTVVMgRWVlUEM+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9k IExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNw aTAKYWNwaV9idXR0b24xOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJt YWwgWm9uZT4gb24gYWNwaTAKYmF0dGVyeTA6IDxBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+ IG9uIGFjcGkwCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCBy ZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKYXRrYmRjMDogPEtl eWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAK YXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiA8UFMvMiBNb3VzZT4g aXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBz bTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMKY3B1MDogPEFDUEkgQ1BVPiBvbiBh Y3BpMAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUw CnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNwdTE6IDxB Q1BJIENQVT4gb24gYWNwaTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3Q6IENQVSBzdXBwb3J0cyBFbmhhbmNlZCBTcGVlZHN0ZXAsIGJ1dCBp cyBub3QgcmVjb2duaXplZC4KZXN0OiBjcHVfdmVuZG9yIEdlbnVpbmVJbnRlbCwgbXNyIDYxMzBh MjIwNjAwMGEyMgpkZXZpY2VfYXR0YWNoOiBlc3QxIGF0dGFjaCByZXR1cm5lZCA2CnA0dGNjMTog PENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCnBtdGltZXIwIG9uIGlzYTAK c2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3Vu dGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0Ig djEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogMTJNYnBzIEZ1 bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1 czQ6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAphZDA6IDE1MjYyN01CIDxTZWFnYXRlIFNU OTE2MDMxMEFTIDAzMDM+IGF0IGF0YTAtbWFzdGVyIFNBVEExNTAKaGRhYzA6IEhEQSBDb2RlYyAj MDogUmVhbHRlayBBTEMyNjkKcGNtMDogPEhEQSBSZWFsdGVrIEFMQzI2OSBQQ00gIzAgQW5hbG9n PiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20xOiA8SERBIFJlYWx0ZWsgQUxDMjY5IFBDTSAj MSBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNi dXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPElu dGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czEKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6 IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVz YnVzNAp1aHViNDogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2J1czQKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzNCB1c2J1czMgdXNidXMyIHVzYnVzMSB1c2J1czAKdWh1YjA6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBm b3I6IHVzYnVzNCB1c2J1czMgdXNidXMyIHVzYnVzMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0IHVzYnVz MyB1c2J1czIKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNCB1c2J1czMKdWh1YjM6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNApS b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNi dXM0ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNAp1aHViNDogOCBwb3J0cyB3aXRoIDgg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0CnVn ZW40LjI6IDxDaGljb255IEVsZWN0cm9uaWNzIENvLiwgTHRkLj4gYXQgdXNidXM0ClRyeWluZyB0 byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczFhCnVnZW4zLjI6IDxCcm9hZGNvbSBDb3Jw PiBhdCB1c2J1czMKV0FSTklORzogVE1QRlMgaXMgY29uc2lkZXJlZCB0byBiZSBhIGhpZ2hseSBl eHBlcmltZW50YWwgZmVhdHVyZSBpbiBGcmVlQlNELgp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczog MDA6MjI6NDM6NzE6ZDc6MGUKd2xhbjA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApkcm0wOiA8 SW50ZWwgaTk0NUdNRT4gb24gdmdhcGNpMAp2Z2FwY2kwOiBjaGlsZCBkcm0wIHJlcXVlc3RlZCBw Y2lfZW5hYmxlX2J1c21hc3RlcgppbmZvOiBbZHJtXSBBR1AgYXQgMHhkMDAwMDAwMCAyNTZNQgpp bmZvOiBbZHJtXSBJbml0aWFsaXplZCBpOTE1IDEuNi4wIDIwMDgwNzMwCmRybTA6IFtJVEhSRUFE XQphdGgwOiBiYiBoYW5nIGRldGVjdGVkICgweDgwKSwgcmVzZXRpbmcK --001636416b432bb5b30465cd55fe Content-Type: application/octet-stream; name="sysctl.log" Content-Disposition: attachment; filename="sysctl.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fsnjmqgz1 a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDguMC1DVVJSRU5UCmtlcm4ub3Ny ZXZpc2lvbjogMTk5NTA2Cmtlcm4udmVyc2lvbjogRnJlZUJTRCA4LjAtQ1VSUkVOVCAjMDogTW9u IE1hciAyMyAxNDoyMTo0NyBVVEMgMjAwOQogICAgaGFkZXNAdGViZTovdXNyL29iai91c3Ivc3Jj L3N5cy9BVE9NCgprZXJuLm1heHZub2RlczogNjk1MjAKa2Vybi5tYXhwcm9jOiA2MTY0Cmtlcm4u bWF4ZmlsZXM6IDEyMzI4Cmtlcm4uYXJnbWF4OiAyNjIxNDQKa2Vybi5zZWN1cmVsZXZlbDogLTEK a2Vybi5ob3N0bmFtZTogdGViZQprZXJuLmhvc3RpZDogMTE2MTQ2MTQ3OAprZXJuLmNsb2NrcmF0 ZTogeyBoeiA9IDEwMDAsIHRpY2sgPSAxMDAwLCBwcm9maHogPSAyMDAwLCBzdGF0aHogPSAxMzMg fQprZXJuLnBvc2l4MXZlcnNpb246IDIwMDExMgprZXJuLm5ncm91cHM6IDE2Cmtlcm4uam9iX2Nv bnRyb2w6IDEKa2Vybi5zYXZlZF9pZHM6IDAKa2Vybi5ib290dGltZTogeyBzZWMgPSAxMjM3ODI3 NTU2LCB1c2VjID0gNTg2MzE0IH0gTW9uIE1hciAyMyAxNjo1OToxNiAyMDA5Cmtlcm4uZG9tYWlu bmFtZTogCmtlcm4ub3NyZWxkYXRlOiA4MDAwNzMKa2Vybi5ib290ZmlsZTogL2Jvb3Qva2VybmVs L2tlcm5lbAprZXJuLm1heGZpbGVzcGVycHJvYzogMTEwOTUKa2Vybi5tYXhwcm9jcGVydWlkOiA1 NTQ3Cmtlcm4uaXBjLm1heHNvY2tidWY6IDI2MjE0NAprZXJuLmlwYy5zb2NrYnVmX3dhc3RlX2Zh Y3RvcjogOAprZXJuLmlwYy5zb21heGNvbm46IDEyOAprZXJuLmlwYy5tYXhfbGlua2hkcjogNDAK a2Vybi5pcGMubWF4X3Byb3RvaGRyOiA0MAprZXJuLmlwYy5tYXhfaGRyOiA4MAprZXJuLmlwYy5t YXhfZGF0YWxlbjogMTIwCmtlcm4uaXBjLm5tYmp1bWJvMTY6IDMyMDAKa2Vybi5pcGMubm1ianVt Ym85OiA2NDAwCmtlcm4uaXBjLm5tYmp1bWJvcDogMTI4MDAKa2Vybi5pcGMubm1iY2x1c3RlcnM6 IDI1NjAwCmtlcm4uaXBjLnBpcGVyZXNpemVhbGxvd2VkOiAxCmtlcm4uaXBjLnBpcGVyZXNpemVm YWlsOiAwCmtlcm4uaXBjLnBpcGVhbGxvY2ZhaWw6IDAKa2Vybi5pcGMucGlwZWZyYWdyZXRyeTog MAprZXJuLmlwYy5waXBla3ZhOiA0NzkyMzIKa2Vybi5pcGMubWF4cGlwZWt2YTogMTY3NzcyMTYK a2Vybi5pcGMubXNnc2VnOiAyMDQ4Cmtlcm4uaXBjLm1zZ3NzejogOAprZXJuLmlwYy5tc2d0cWw6 IDQwCmtlcm4uaXBjLm1zZ21uYjogMjA0OAprZXJuLmlwYy5tc2dtbmk6IDQwCmtlcm4uaXBjLm1z Z21heDogMTYzODQKa2Vybi5pcGMuc2VtYWVtOiAxNjM4NAprZXJuLmlwYy5zZW12bXg6IDMyNzY3 Cmtlcm4uaXBjLnNlbXVzejogMTM2Cmtlcm4uaXBjLnNlbXVtZTogMTAKa2Vybi5pcGMuc2Vtb3Bt OiAxMDAKa2Vybi5pcGMuc2VtbXNsOiA2MAprZXJuLmlwYy5zZW1tbnU6IDMwCmtlcm4uaXBjLnNl bW1uczogNjAKa2Vybi5pcGMuc2VtbW5pOiAxMAprZXJuLmlwYy5zZW1tYXA6IDMwCmtlcm4uaXBj LnNobV9hbGxvd19yZW1vdmVkOiAwCmtlcm4uaXBjLnNobV91c2VfcGh5czogMAprZXJuLmlwYy5z aG1hbGw6IDgxOTIKa2Vybi5pcGMuc2htc2VnOiAxMjgKa2Vybi5pcGMuc2htbW5pOiAxOTIKa2Vy bi5pcGMuc2htbWluOiAxCmtlcm4uaXBjLnNobW1heDogMzM1NTQ0MzIKa2Vybi5pcGMubWF4c29j a2V0czogMjU2MDAKa2Vybi5pcGMubnVtb3BlbnNvY2tldHM6IDE0NQprZXJuLmlwYy5uc2ZidWZz dXNlZDogMAprZXJuLmlwYy5uc2ZidWZzcGVhazogNgprZXJuLmlwYy5uc2ZidWZzOiA2NjU2Cmtl cm4uZHVtbXk6IDAKa2Vybi5wc19zdHJpbmdzOiAzMjE3MDMxMTUyCmtlcm4udXNyc3RhY2s6IDMy MTcwMzExNjgKa2Vybi5sb2dzaWdleGl0OiAxCmtlcm4uaW92X21heDogMTAyNAprZXJuLmhvc3R1 dWlkOiA0NDQ1NGM0Yy0zNzAwLTEwNTYtODA0My1iMmMwNGY1OTMyNGEKa2Vybi5jYW0uY2FtX3Ny Y2hfaGk6IDAKa2Vybi5jYW0uc2NzaV9kZWxheTogNTAwMAprZXJuLmNhbS5kYS5kYV9zZW5kX29y ZGVyZWQ6IDEKa2Vybi5jYW0uZGEuZGVmYXVsdF90aW1lb3V0OiA2MAprZXJuLmNhbS5kYS5yZXRy eV9jb3VudDogNAprZXJuLmRpc2tzOiBhZDAKa2Vybi5nZW9tLmNvbGxlY3RzdGF0czogMQprZXJu Lmdlb20uZGVidWdmbGFnczogMAprZXJuLmdlb20ubGFiZWwuZGVidWc6IDAKa2Vybi5lbGYzMi5m YWxsYmFja19icmFuZDogLTEKa2Vybi5pbml0X3NodXRkb3duX3RpbWVvdXQ6IDEyMAprZXJuLmlu aXRfcGF0aDogL3NiaW4vaW5pdDovc2Jpbi9vaW5pdDovc2Jpbi9pbml0LmJhazovcmVzY3VlL2lu aXQ6L3N0YW5kL3N5c2luc3RhbGwKa2Vybi5hY2N0X3N1c3BlbmRlZDogMAprZXJuLmFjY3RfY29u ZmlndXJlZDogMAprZXJuLmFjY3RfY2hrZnJlcTogMTUKa2Vybi5hY2N0X3Jlc3VtZTogNAprZXJu LmFjY3Rfc3VzcGVuZDogMgprZXJuLmNwX3RpbWVzOiAzOTEyMTAgMSAzNjg4MyAxNTA2IDI2MjI1 OCA0OTg2MjcgMCA0MjkxOSAxNTkgMTUwMTM3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCmtlcm4uY3BfdGltZTog ODg5ODQwIDEgNzk4MDIgMTY2NSA0MTIzOTUKa2Vybi5jb25zdHR5X3dha2V1cHNfcGVyX3NlY29u ZDogNQprZXJuLmNvbnNtc2didWZfc2l6ZTogODE5MgprZXJuLmNvbnNtdXRlOiAwCmtlcm4uY29u c29sZTogdHR5djAsL3R0eXYwLAprZXJuLm9wZW5maWxlczogNDQyCmtlcm4ua3FfY2FsbG91dG1h eDogNDA5NgprZXJuLnBzX2FyZ19jYWNoZV9saW1pdDogMjU2Cmtlcm4uc3RhY2twcm90OiA3Cmtl cm4ucmFuZG9tcGlkOiAwCmtlcm4ubGFzdHBpZDogNTg5MTYKa2Vybi5tb2R1bGVfcGF0aDogL2Jv b3Qva2VybmVsOy9ib290L21vZHVsZXMKa2Vybi5tYWxsb2NfY291bnQ6IDI1MgprZXJuLmZhbGxi YWNrX2VsZl9icmFuZDogLTEKa2Vybi5mZWF0dXJlcy5wb3NpeF9zaG06IDEKa2Vybi5tYXh1c2Vy czogMzg0Cmtlcm4uaWRlbnQ6IEFUT00Ka2Vybi5rc3RhY2tfcGFnZXM6IDIKa2Vybi5zaHV0ZG93 bi5rcHJvY19zaHV0ZG93bl93YWl0OiA2MAprZXJuLnNodXRkb3duLnBvd2Vyb2ZmX2RlbGF5OiA1 MDAwCmtlcm4uc3luY19vbl9wYW5pYzogMAprZXJuLmNvcmVmaWxlOiAlTi5jb3JlCmtlcm4ubm9k dW1wX2NvcmVkdW1wOiAwCmtlcm4uY29yZWR1bXA6IDEKa2Vybi5zdWdpZF9jb3JlZHVtcDogMApr ZXJuLnNpZ3F1ZXVlLmFsbG9jX2ZhaWw6IDAKa2Vybi5zaWdxdWV1ZS5vdmVyZmxvdzogMAprZXJu LnNpZ3F1ZXVlLnByZWFsbG9jYXRlOiAxMDI0Cmtlcm4uc2lncXVldWUubWF4X3BlbmRpbmdfcGVy X3Byb2M6IDEyOAprZXJuLmZvcmNlc2lnZXhpdDogMQprZXJuLmZzY2FsZTogMjA0OAprZXJuLnRp bWVjb3VudGVyLnRpY2s6IDEKa2Vybi50aW1lY291bnRlci5jaG9pY2U6IFRTQygtMTAwKSBIUEVU KDkwMCkgQUNQSS1mYXN0KDEwMDApIGk4MjU0KDApIGR1bW15KC0xMDAwMDAwKQprZXJuLnRpbWVj b3VudGVyLmhhcmR3YXJlOiBBQ1BJLWZhc3QKa2Vybi50aW1lY291bnRlci5zdGVwd2FybmluZ3M6 IDAKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5tYXNrOiA2NTUzNQprZXJuLnRpbWVjb3VudGVy LnRjLmk4MjU0LmNvdW50ZXI6IDQ0ODEKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5mcmVxdWVu Y3k6IDExOTMxODIKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5xdWFsaXR5OiAwCmtlcm4udGlt ZWNvdW50ZXIudGMuQUNQSS1mYXN0Lm1hc2s6IDE2Nzc3MjE1Cmtlcm4udGltZWNvdW50ZXIudGMu QUNQSS1mYXN0LmNvdW50ZXI6IDEzODY0ODkyCmtlcm4udGltZWNvdW50ZXIudGMuQUNQSS1mYXN0 LmZyZXF1ZW5jeTogMzU3OTU0NQprZXJuLnRpbWVjb3VudGVyLnRjLkFDUEktZmFzdC5xdWFsaXR5 OiAxMDAwCmtlcm4udGltZWNvdW50ZXIudGMuSFBFVC5tYXNrOiA0Mjk0OTY3Mjk1Cmtlcm4udGlt ZWNvdW50ZXIudGMuSFBFVC5jb3VudGVyOiAxNjQ1OTc0Njg5Cmtlcm4udGltZWNvdW50ZXIudGMu SFBFVC5mcmVxdWVuY3k6IDE0MzE4MTgwCmtlcm4udGltZWNvdW50ZXIudGMuSFBFVC5xdWFsaXR5 OiA5MDAKa2Vybi50aW1lY291bnRlci50Yy5UU0MubWFzazogNDI5NDk2NzI5NQprZXJuLnRpbWVj b3VudGVyLnRjLlRTQy5jb3VudGVyOiA2MTMzMTA4NjQKa2Vybi50aW1lY291bnRlci50Yy5UU0Mu ZnJlcXVlbmN5OiAxNjYyNTE0NjcwCmtlcm4udGltZWNvdW50ZXIudGMuVFNDLnF1YWxpdHk6IC0x MDAKa2Vybi50aW1lY291bnRlci5zbXBfdHNjOiAwCmtlcm4udGltZWNvdW50ZXIuaW52YXJpYW50 X3RzYzogMQprZXJuLnRocmVhZHMubWF4X3RocmVhZHNfaGl0czogMAprZXJuLnRocmVhZHMubWF4 X3RocmVhZHNfcGVyX3Byb2M6IDE1MDAKa2Vybi5jY3B1OiAwCmtlcm4uc2NoZWQucHJlZW1wdGlv bjogMQprZXJuLnNjaGVkLnRvcG9sb2d5X3NwZWM6IDxncm91cHM+CiA8Z3JvdXAgbGV2ZWw9IjEi IGNhY2hlLWxldmVsPSIwIj4KICA8Y3B1IGNvdW50PSIyIiBtYXNrPSIweDMiPjAsIDE8L2NwdT4K ICA8ZmxhZ3M+PC9mbGFncz4KICA8Y2hpbGRyZW4+CiAgIDxncm91cCBsZXZlbD0iMyIgY2FjaGUt bGV2ZWw9IjEiPgogICAgPGNwdSBjb3VudD0iMiIgbWFzaz0iMHgzIj4wLCAxPC9jcHU+CiAgICA8 ZmxhZ3M+PGZsYWcgbmFtZT0iSFRUIj5IVFQgZ3JvdXA8L2ZsYWc+CjwvZmxhZ3M+CiAgIDwvZ3Jv dXA+CiAgPC9jaGlsZHJlbj4KIDwvZ3JvdXA+CjwvZ3JvdXBzPgoKa2Vybi5zY2hlZC5zdGVhbF90 aHJlc2g6IDEKa2Vybi5zY2hlZC5zdGVhbF9pZGxlOiAxCmtlcm4uc2NoZWQuc3RlYWxfaHR0OiAx Cmtlcm4uc2NoZWQuYmFsYW5jZV9pbnRlcnZhbDogMTMzCmtlcm4uc2NoZWQuYmFsYW5jZTogMQpr ZXJuLnNjaGVkLmFmZmluaXR5OiAxCmtlcm4uc2NoZWQuaWRsZXNwaW50aHJlc2g6IDQKa2Vybi5z Y2hlZC5pZGxlc3BpbnM6IDEwMDAwCmtlcm4uc2NoZWQuc3RhdGljX2Jvb3N0OiAxNjAKa2Vybi5z Y2hlZC5wcmVlbXB0X3RocmVzaDogNjQKa2Vybi5zY2hlZC5pbnRlcmFjdDogMzAKa2Vybi5zY2hl ZC5zbGljZTogMTMKa2Vybi5zY2hlZC5uYW1lOiBVTEUKa2Vybi5kZXZzdGF0LnZlcnNpb246IDYK a2Vybi5kZXZzdGF0LmdlbmVyYXRpb246IDI3Cmtlcm4uZGV2c3RhdC5udW1kZXZzOiAxCmtlcm4u a29ial9tZXRob2Rjb3VudDogMTM5Cmtlcm4ubG9nX3dha2V1cHNfcGVyX3NlY29uZDogNQprZXJu LnZtX2d1ZXN0OiBub25lCmtlcm4uc2dyb3dzaXo6IDEzMTA3MgprZXJuLm1heHNzaXo6IDY3MTA4 ODY0Cmtlcm4uZGZsc3NpejogODM4ODYwOAprZXJuLm1heGRzaXo6IDUzNjg3MDkxMgprZXJuLmRm bGRzaXo6IDEzNDIxNzcyOAprZXJuLm1heHRzaXo6IDEzNDIxNzcyOAprZXJuLm1heGJjYWNoZTog MjA5NzE1MjAwCmtlcm4ubWF4c3d6b25lOiAzMzU1NDQzMgprZXJuLm5zd2J1ZjogMjU2Cmtlcm4u bmJ1ZjogNzEwOQprZXJuLm5jYWxsb3V0OiAxODUwOAprZXJuLmh6OiAxMDAwCmtlcm4ubXNnYnVm X2NsZWFyOiAwCmtlcm4ubXNnYnVmOiAKa2Vybi5hbHdheXNfY29uc29sZV9vdXRwdXQ6IDAKa2Vy bi5sb2dfY29uc29sZV9vdXRwdXQ6IDEKa2Vybi5zbXAuZm9yd2FyZF9yb3VuZHJvYmluX2VuYWJs ZWQ6IDEKa2Vybi5zbXAuZm9yd2FyZF9zaWduYWxfZW5hYmxlZDogMQprZXJuLnNtcC50b3BvbG9n eTogMAprZXJuLnNtcC5jcHVzOiAyCmtlcm4uc21wLmRpc2FibGVkOiAwCmtlcm4uc21wLmFjdGl2 ZTogMQprZXJuLnNtcC5tYXhjcHVzOiAzMgprZXJuLnNtcC5tYXhpZDogMzEKa2Vybi50dHlfaW5x X25zbG93OiA1MDczCmtlcm4udHR5X2lucV9uZmFzdDogMTcyMjQKa2Vybi50dHlfb3V0cV9uc2xv dzogMjI1Cmtlcm4udHR5X291dHFfbmZhc3Q6IDkxODI0Cmtlcm4udHR5X3B0eV93YXJuaW5nY250 OiAxMAprZXJuLnR0eV9ub3V0OiAxMDY4MDAyOAprZXJuLnR0eV9uaW46IDIyOTg5Cmtlcm4ubWlu dm5vZGVzOiAxNzM4MAprZXJuLm1ldGFkZWxheTogMjgKa2Vybi5kaXJkZWxheTogMjkKa2Vybi5m aWxlZGVsYXk6IDMwCmtlcm4uY2hyb290X2FsbG93X29wZW5fZGlyZWN0b3JpZXM6IDEKa2Vybi5y cGMuaW52YWxpZDogMAprZXJuLnJwYy51bmV4cGVjdGVkOiAwCmtlcm4ucnBjLnRpbWVvdXRzOiAw Cmtlcm4ucnBjLnJlcXVlc3Q6IDAKa2Vybi5ycGMucmV0cmllczogMAprZXJuLnJhbmRvbS55YXJy b3cuZ2VuZ2F0ZWludGVydmFsOiAxMAprZXJuLnJhbmRvbS55YXJyb3cuYmluczogMTAKa2Vybi5y YW5kb20ueWFycm93LmZhc3R0aHJlc2g6IDE5MgprZXJuLnJhbmRvbS55YXJyb3cuc2xvd3RocmVz aDogMjU2Cmtlcm4ucmFuZG9tLnlhcnJvdy5zbG93b3ZlcnRocmVzaDogMgprZXJuLnJhbmRvbS5z eXMuc2VlZGVkOiAxCmtlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0LmV0aGVybmV0OiAxCmtlcm4ucmFu ZG9tLnN5cy5oYXJ2ZXN0LnBvaW50X3RvX3BvaW50OiAxCmtlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0 LmludGVycnVwdDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5zd2k6IDAKdm0udm10b3RhbDog ClN5c3RlbSB3aWRlIHRvdGFscyBjb21wdXRlZCBldmVyeSBmaXZlIHNlY29uZHM6ICh2YWx1ZXMg aW4ga2lsb2J5dGVzKQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQpQcm9jZXNzZXM6CQkoUlVOUTogMSBEaXNrIFdhaXQ6IDAgUGFnZSBXYWl0OiAwIFNsZWVw OiA4MykKVmlydHVhbCBNZW1vcnk6CQkoVG90YWw6IDI3NTM4NDBLLCBBY3RpdmUgNTMxNzQwSykK UmVhbCBNZW1vcnk6CQkoVG90YWw6IDQwNTc2MEsgQWN0aXZlIDI0MjA4NEspClNoYXJlZCBWaXJ0 dWFsIE1lbW9yeToJKFRvdGFsOiA1NTM2OEsgQWN0aXZlOiAzMzMxMkspClNoYXJlZCBSZWFsIE1l bW9yeToJKFRvdGFsOiAzOTgzMksgQWN0aXZlOiAyMTAzMkspCkZyZWUgTWVtb3J5IFBhZ2VzOgky NTg5MTJLCgp2bS5sb2FkYXZnOiB7IDAuMTggMC4zNiAwLjkzIH0Kdm0udl9mcmVlX21pbjogMTY0 NQp2bS52X2ZyZWVfdGFyZ2V0OiA2OTU5CnZtLnZfZnJlZV9yZXNlcnZlZDogMzc5CnZtLnZfaW5h Y3RpdmVfdGFyZ2V0OiAxMDQzOAp2bS52X2NhY2hlX21pbjogNjk1OQp2bS52X2NhY2hlX21heDog MTM5MTgKdm0udl9wYWdlb3V0X2ZyZWVfbWluOiAzNAp2bS5wYWdlb3V0X2FsZ29yaXRobTogMAp2 bS5zd2FwX2VuYWJsZWQ6IDEKdm0ua21lbV9zaXplX3NjYWxlOiAzCnZtLmttZW1fc2l6ZV9tYXg6 IDMzNTU0NDMyMAp2bS5rbWVtX3NpemVfbWluOiAwCnZtLmttZW1fc2l6ZTogMzM1NTQ0MzIwCnZt Lm5zd2FwZGV2OiAwCnZtLmRtbWF4OiAzMgp2bS5zd2FwX2FzeW5jX21heDogNAp2bS56b25lX2Nv dW50OiA4OAp2bS5zd2FwX2lkbGVfdGhyZXNob2xkMjogMTAKdm0uc3dhcF9pZGxlX3RocmVzaG9s ZDE6IDIKdm0uZXhlY19tYXBfZW50cmllczogMTYKdm0uc3RhdHMubWlzYy56ZXJvX3BhZ2VfY291 bnQ6IDY1CnZtLnN0YXRzLm1pc2MuY250X3ByZXplcm86IDAKdm0uc3RhdHMudm0udl9rdGhyZWFk cGFnZXM6IDAKdm0uc3RhdHMudm0udl9yZm9ya3BhZ2VzOiAwCnZtLnN0YXRzLnZtLnZfdmZvcmtw YWdlczogNjI1MzcwMwp2bS5zdGF0cy52bS52X2ZvcmtwYWdlczogNDQ1MzQ0Mwp2bS5zdGF0cy52 bS52X2t0aHJlYWRzOiAzOQp2bS5zdGF0cy52bS52X3Jmb3JrczogMAp2bS5zdGF0cy52bS52X3Zm b3JrczogMzU3NTQKdm0uc3RhdHMudm0udl9mb3JrczogMjMxMjMKdm0uc3RhdHMudm0udl9pbnRl cnJ1cHRfZnJlZV9taW46IDIKdm0uc3RhdHMudm0udl9wYWdlb3V0X2ZyZWVfbWluOiAzNAp2bS5z dGF0cy52bS52X2NhY2hlX21heDogMTM5MTgKdm0uc3RhdHMudm0udl9jYWNoZV9taW46IDY5NTkK dm0uc3RhdHMudm0udl9jYWNoZV9jb3VudDogMTMyNAp2bS5zdGF0cy52bS52X2luYWN0aXZlX2Nv dW50OiA4ODI2Mgp2bS5zdGF0cy52bS52X2luYWN0aXZlX3RhcmdldDogMTA0MzgKdm0uc3RhdHMu dm0udl9hY3RpdmVfY291bnQ6IDQ4OTM0CnZtLnN0YXRzLnZtLnZfd2lyZV9jb3VudDogNTEzNjAK dm0uc3RhdHMudm0udl9mcmVlX2NvdW50OiA2MzQwMwp2bS5zdGF0cy52bS52X2ZyZWVfbWluOiAx NjQ1CnZtLnN0YXRzLnZtLnZfZnJlZV90YXJnZXQ6IDY5NTkKdm0uc3RhdHMudm0udl9mcmVlX3Jl c2VydmVkOiAzNzkKdm0uc3RhdHMudm0udl9wYWdlX2NvdW50OiAyNTM0MjUKdm0uc3RhdHMudm0u dl9wYWdlX3NpemU6IDQwOTYKdm0uc3RhdHMudm0udl90ZnJlZTogMjI0NTcyOTIKdm0uc3RhdHMu dm0udl9wZnJlZTogOTg1MTg3MAp2bS5zdGF0cy52bS52X2RmcmVlOiAwCnZtLnN0YXRzLnZtLnZf dGNhY2hlZDogMjcxNDMKdm0uc3RhdHMudm0udl9wZHBhZ2VzOiAyOTI0OAp2bS5zdGF0cy52bS52 X3Bkd2FrZXVwczogNAp2bS5zdGF0cy52bS52X3JlYWN0aXZhdGVkOiAyMDM2CnZtLnN0YXRzLnZt LnZfaW50cmFuczogNzYyCnZtLnN0YXRzLnZtLnZfdm5vZGVwZ3NvdXQ6IDAKdm0uc3RhdHMudm0u dl92bm9kZXBnc2luOiAxNTY0MAp2bS5zdGF0cy52bS52X3Zub2Rlb3V0OiAwCnZtLnN0YXRzLnZt LnZfdm5vZGVpbjogMTk5Nwp2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXQ6IDAKdm0uc3RhdHMudm0u dl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0udl9zd2Fwb3V0OiAwCnZtLnN0YXRzLnZtLnZfc3dh cGluOiAwCnZtLnN0YXRzLnZtLnZfb3pmb2Q6IDEwNDUzNwp2bS5zdGF0cy52bS52X3pmb2Q6IDEz OTc1OTE3CnZtLnN0YXRzLnZtLnZfY293X29wdGltOiAxODEzCnZtLnN0YXRzLnZtLnZfY293X2Zh dWx0czogNzM5NjM5OAp2bS5zdGF0cy52bS52X3ZtX2ZhdWx0czogMjIxMzc2ODAKdm0uc3RhdHMu c3lzLnZfc29mdDogMTAzNzI2Mgp2bS5zdGF0cy5zeXMudl9pbnRyOiAyNjI3NzAKdm0uc3RhdHMu c3lzLnZfc3lzY2FsbDogMTgxNzc5MTUKdm0uc3RhdHMuc3lzLnZfdHJhcDogMjMwMTcwNjkKdm0u c3RhdHMuc3lzLnZfc3d0Y2g6IDQ5ODY1NDMKdm0uc3RhdHMub2JqZWN0LmJ5cGFzc2VzOiA1OTM5 CnZtLnN0YXRzLm9iamVjdC5jb2xsYXBzZXM6IDk1ODg3CnZtLnZfZnJlZV9zZXZlcmU6IDEwMTIK dm0ubWF4X3Byb2NfbW1hcDogNDkzNDQKdm0ub2xkX21zeW5jOiAwCnZtLm1zeW5jX2ZsdXNoX2Zs YWdzOiAzCnZtLmJvb3RfcGFnZXM6IDQ4CnZtLm1heF93aXJlZDogODM1MjEKdm0ucGFnZW91dF9s b2NrX21pc3M6IDAKdm0uZGlzYWJsZV9zd2Fwc3BhY2VfcGFnZW91dHM6IDAKdm0uZGVmZXJfc3dh cHNwYWNlX3BhZ2VvdXRzOiAwCnZtLnN3YXBfaWRsZV9lbmFibGVkOiAwCnZtLnBhZ2VvdXRfc3Rh dHNfaW50ZXJ2YWw6IDUKdm0ucGFnZW91dF9mdWxsX3N0YXRzX2ludGVydmFsOiAyMAp2bS5wYWdl b3V0X3N0YXRzX21heDogNjk1OQp2bS5tYXhfbGF1bmRlcjogMzIKdm0ucGh5c19zZWdzOiAKU0VH TUVOVCAwOgoKc3RhcnQ6ICAgICAweDEwMDAKZW5kOiAgICAgICAweDlmMDAwCmZyZWUgbGlzdDog MHhjMDk2ZTFhOAoKU0VHTUVOVCAxOgoKc3RhcnQ6ICAgICAweDEwMDAwMAplbmQ6ICAgICAgIDB4 NDAwMDAwCmZyZWUgbGlzdDogMHhjMDk2ZTFhOAoKU0VHTUVOVCAyOgoKc3RhcnQ6ICAgICAweGMy NTAwMAplbmQ6ICAgICAgIDB4MTAwMDAwMApmcmVlIGxpc3Q6IDB4YzA5NmUxYTgKClNFR01FTlQg MzoKCnN0YXJ0OiAgICAgMHgxMDAwMDAwCmVuZDogICAgICAgMHgzZTY3ODAwMApmcmVlIGxpc3Q6 IDB4YzA5NmUwYTAKCnZtLnBoeXNfZnJlZTogCkZSRUUgTElTVCAwOgoKICBPUkRFUiAoU0laRSkg IHwgIE5VTUJFUgogICAgICAgICAgICAgICAgfCAgUE9PTCAwICB8ICBQT09MIDEKLS0gICAgICAg ICAgICAtLSAtLSAgICAgIC0tIC0tICAgICAgLS0KICAxMCAoICA0MDk2SykgIHwgICAgICAgMCAg fCAgICAgICAwCiAgIDkgKCAgMjA0OEspICB8ICAgICAgIDEgIHwgICAgICAgMAogICA4ICggIDEw MjRLKSAgfCAgICAgICAzICB8ICAgICAgIDAKICAgNyAoICAgNTEySykgIHwgICAgICAxOSAgfCAg ICAgICAwCiAgIDYgKCAgIDI1NkspICB8ICAgICAgOTUgIHwgICAgICAgMAogICA1ICggICAxMjhL KSAgfCAgICAgNDUxICB8ICAgICAgIDAKICAgNCAoICAgIDY0SykgIHwgICAgMTQ0MSAgfCAgICAg ICAwCiAgIDMgKCAgICAzMkspICB8ICAgIDExODYgIHwgICAgICAxMAogICAyICggICAgMTZLKSAg fCAgICAgICAxICB8ICAgICAxOTQKICAgMSAoICAgICA4SykgIHwgICAgICAgMiAgfCAgICAgMjU1 CiAgIDAgKCAgICAgNEspICB8ICAgICAgIDEgIHwgICAgIDI3NAoKRlJFRSBMSVNUIDE6CgogIE9S REVSIChTSVpFKSAgfCAgTlVNQkVSCiAgICAgICAgICAgICAgICB8ICBQT09MIDAgIHwgIFBPT0wg MQotLSAgICAgICAgICAgIC0tIC0tICAgICAgLS0gLS0gICAgICAtLQogIDEwICggIDQwOTZLKSAg fCAgICAgICAwICB8ICAgICAgIDAKICAgOSAoICAyMDQ4SykgIHwgICAgICAgMCAgfCAgICAgICAw CiAgIDggKCAgMTAyNEspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA3ICggICA1MTJLKSAgfCAg ICAgICAwICB8ICAgICAgIDIKICAgNiAoICAgMjU2SykgIHwgICAgICAgMSAgfCAgICAgICAyCiAg IDUgKCAgIDEyOEspICB8ICAgICAgIDIgIHwgICAgICAgMgogICA0ICggICAgNjRLKSAgfCAgICAg ICA0ICB8ICAgICAgIDYKICAgMyAoICAgIDMySykgIHwgICAgICAxMiAgfCAgICAgICA3CiAgIDIg KCAgICAxNkspICB8ICAgICAgMTYgIHwgICAgICAxMAogICAxICggICAgIDhLKSAgfCAgICAgIDIw ICB8ICAgICAgMTEKICAgMCAoICAgICA0SykgIHwgICAgICAzMiAgfCAgICAgIDEyCgp2bS5yZXNl cnYucmVjbGFpbWVkOiAxODYKdm0ucmVzZXJ2LnBhcnRwb3BxOiAKTEVWRUwgICAgIFNJWkUgIE5V TUJFUgoKICAgLTE6ICAyMDg0OEssICAgICAgOAoKdm0ucmVzZXJ2LmZyZWVkOiA4MzcKdm0ucmVz ZXJ2LmJyb2tlbjogMAp2bS5pZGxlemVyb19lbmFibGU6IDAKdm0ua3ZtX2ZyZWU6IDQyNzgxNDkx Mgp2bS5rdm1fc2l6ZTogMTA3MzczNzcyOAp2bS5wbWFwLnBtYXBfY29sbGVjdF9hY3RpdmU6IDAK dm0ucG1hcC5wbWFwX2NvbGxlY3RfaW5hY3RpdmU6IDAKdm0ucG1hcC5wdl9lbnRyeV9zcGFyZTog MjA5OTgKdm0ucG1hcC5wdl9lbnRyeV9hbGxvY3M6IDU1MTcwMTE1CnZtLnBtYXAucHZfZW50cnlf ZnJlZXM6IDU1MDc2ODczCnZtLnBtYXAucGNfY2h1bmtfdHJ5ZmFpbDogMAp2bS5wbWFwLnBjX2No dW5rX2ZyZWVzOiAxODUwMzMKdm0ucG1hcC5wY19jaHVua19hbGxvY3M6IDE4NTM3Mwp2bS5wbWFw LnBjX2NodW5rX2NvdW50OiAzNDAKdm0ucG1hcC5wdl9lbnRyeV9jb3VudDogOTMyNDIKdm0ucG1h cC5wZGUucHJvbW90aW9uczogMAp2bS5wbWFwLnBkZS5wX2ZhaWx1cmVzOiAwCnZtLnBtYXAucGRl Lm1hcHBpbmdzOiAwCnZtLnBtYXAucGRlLmRlbW90aW9uczogMAp2bS5wbWFwLnNocGdwZXJwcm9j OiAyMDAKdm0ucG1hcC5wdl9lbnRyeV9tYXg6IDE0ODY0NjQKdm0ucG1hcC5wZ19wc19lbmFibGVk OiAwCnZmcy5kZXZmcy5ydWxlX2RlcHRoOiAxCnZmcy5kZXZmcy5nZW5lcmF0aW9uOiAxMTUKdmZz Lm5mczQuYWNjZXNzX2NhY2hlX3RpbWVvdXQ6IDYwCnZmcy5uZnMuZG93bmRlbGF5aW5pdGlhbDog MTIKdmZzLm5mcy5kb3duZGVsYXlpbnRlcnZhbDogMzAKdmZzLm5mcy5za2lwX3djY19kYXRhX29u ZXJyOiAxCnZmcy5uZnMubmZzM19qdWtlYm94X2RlbGF5OiAxMAp2ZnMubmZzLnJlY29ubmVjdHM6 IDAKdmZzLm5mcy5idWZwYWNrZXRzOiA0CnZmcy5uZnMucmVhbGlnbl9jb3VudDogMAp2ZnMubmZz LnJlYWxpZ25fdGVzdDogMAp2ZnMubmZzLmRlZmVjdDogMAp2ZnMubmZzLmlvZG1heDogMjAKdmZz Lm5mcy5pb2RtaW46IDAKdmZzLm5mcy5pb2RtYXhpZGxlOiAxMjAKdmZzLm5mcy5kaXNrbGVzc19y b290cGF0aDogCnZmcy5uZnMuZGlza2xlc3NfdmFsaWQ6IDAKdmZzLm5mcy5uZnNfaXBfcGFyYW5v aWE6IDEKdmZzLm5mcy5uZnNfZGlyZWN0aW9fYWxsb3dfbW1hcDogMQp2ZnMubmZzLm5mc19kaXJl Y3Rpb19lbmFibGU6IDAKdmZzLm5mcy5jbGVhbl9wYWdlc19vbl9jbG9zZTogMQp2ZnMubmZzLm5m c3YzX2NvbW1pdF9vbl9jbG9zZTogMAp2ZnMubmZzLnByaW1lX2FjY2Vzc19jYWNoZTogMAp2ZnMu bmZzLmFjY2Vzc19jYWNoZV90aW1lb3V0OiA2MAp2ZnMudWZzLmRpcmhhc2hfZG9jaGVjazogMAp2 ZnMudWZzLmRpcmhhc2hfbWVtOiA3MjMzMTEKdmZzLnVmcy5kaXJoYXNoX21heG1lbTogMjA5NzE1 Mgp2ZnMudWZzLmRpcmhhc2hfbWluc2l6ZTogMjU2MAp2ZnMucGZzLnRyYWNlOiAwCnZmcy5wZnMu dm5jYWNoZS5taXNzZXM6IDQ2CnZmcy5wZnMudm5jYWNoZS5oaXRzOiA2MQp2ZnMucGZzLnZuY2Fj aGUubWF4ZW50cmllczogMjkKdmZzLnBmcy52bmNhY2hlLmVudHJpZXM6IDIwCnZmcy5mbHVzaHdp dGhkZXBzOiA2OTAKdmZzLmZsdXNoYnVmcXRhcmdldDogMTAwCnZmcy5nZXRuZXdidWZyZXN0YXJ0 czogMAp2ZnMuZ2V0bmV3YnVmY2FsbHM6IDE5ODk1NQp2ZnMuaGlmcmVlYnVmZmVyczogNzk4CnZm cy5sb2ZyZWVidWZmZXJzOiAzOTkKdmZzLm51bWZyZWVidWZmZXJzOiA3MDkzCnZmcy5kaXJ0eWJ1 ZnRocmVzaDogMTYxNwp2ZnMuaGlkaXJ0eWJ1ZmZlcnM6IDE3OTcKdmZzLmxvZGlydHlidWZmZXJz OiA4OTgKdmZzLm51bWRpcnR5YnVmZmVyczogMTUKdmZzLnJlY3Vyc2l2ZWZsdXNoZXM6IDQ1Nzk4 CnZmcy5hbHRidWZmZXJmbHVzaGVzOiAwCnZmcy5iZHdyaXRlc2tpcDogMAp2ZnMuZGlydHlidWZm ZXJmbHVzaGVzOiAwCnZmcy5oaXJ1bm5pbmdzcGFjZTogMTA0ODU3Ngp2ZnMubG9ydW5uaW5nc3Bh Y2U6IDUyNDI4OAp2ZnMuYnVmZGVmcmFnY250OiAwCnZmcy5idWZmcmVla3ZhY250OiAwCnZmcy5i dWZyZXVzZWNudDogNzA2NQp2ZnMuaGlidWZzcGFjZTogMTE1ODE4NDk2CnZmcy5sb2J1ZnNwYWNl OiAxMTU3NTI5NjAKdmZzLm1heG1hbGxvY2J1ZnNwYWNlOiA1NzkwOTI0CnZmcy5idWZtYWxsb2Nz cGFjZTogMTQzMzYKdmZzLm1heGJ1ZnNwYWNlOiAxMTY0NzM4NTYKdmZzLmJ1ZnNwYWNlOiAxMTU3 NTI5NjAKdmZzLnJ1bm5pbmdidWZzcGFjZTogMAp2ZnMudm1pb2RpcmVuYWJsZTogMQp2ZnMuY2Fj aGUubnVtZnVsbHBhdGhmb3VuZDogMjkyMjMKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDQ6IDAK dmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDI6IDgKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDE6 IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoY2FsbHM6IDI5MjMxCnZmcy5jYWNoZS5uY2hzdGF0czog MTk5NDEyMDIgMzY1MTUyOCA5ODkwNCAwIDgzMDExNSAwIDEzMzU3IDE2OTQxNQp2ZnMuY2FjaGUu bnVtdXBncmFkZXM6IDE2Njg0CnZmcy5jYWNoZS5udW1uZWdoaXRzOiAzNjUxNTI4CnZmcy5jYWNo ZS5udW1uZWd6YXBzOiA1NTU3MQp2ZnMuY2FjaGUubnVtcG9zaGl0czogMTk5NDEyMDIKdmZzLmNh Y2hlLm51bXBvc3phcHM6IDQzMzMzCnZmcy5jYWNoZS5udW1taXNzemFwOiAxNzAwOAp2ZnMuY2Fj aGUubnVtbWlzczogODEzMTA3CnZmcy5jYWNoZS5udW1jaGVja3M6IDI5NjY0NDkxCnZmcy5jYWNo ZS5kb3Rkb3RoaXRzOiAxMzQyMTA3Mwp2ZnMuY2FjaGUuZG90aGl0czogOTIwOTI4CnZmcy5jYWNo ZS5udW1jYWxsczogMzg4NjM2NzMKdmZzLmNhY2hlLm51bWNhY2hlOiA0NzUxNgp2ZnMuY2FjaGUu bnVtbmVnOiAyMzIzCnZmcy5yZWFkX21heDogOAp2ZnMud3JpdGVfYmVoaW5kOiAxCnZmcy5sb29r dXBfc2hhcmVkOiAxCnZmcy51c2VybW91bnQ6IDAKdmZzLndvcmtsaXN0X2xlbjogNwp2ZnMudGlt ZXN0YW1wX3ByZWNpc2lvbjogMAp2ZnMucmVhc3NpZ25idWZjYWxsczogMjY2MjY4CnZmcy5mcmVl dm5vZGVzOiA4MTE3CnZmcy53YW50ZnJlZXZub2RlczogMTczODAKdmZzLm51bXZub2RlczogNDUz MDkKdmZzLm5mc3J2Lm5mc19wcml2cG9ydDogMAp2ZnMubmZzcnYuZmhhLmJpbl9zaGlmdDogMTgK dmZzLm5mc3J2LmZoYS5tYXhfbmZzZHNfcGVyX2ZoOiA4CnZmcy5uZnNydi5maGEubWF4X3JlcXNf cGVyX25mc2Q6IDQKdmZzLm5mc3J2LmZoYS5maGVfc3RhdHM6IE5vIGZpbGUgaGFuZGxlIGVudHJp ZXMuCnZmcy5uZnNydi5jb21taXRfbWlzczogMAp2ZnMubmZzcnYuY29tbWl0X2Jsa3M6IDAKdmZz Lm5mc3J2LmFzeW5jOiAwCnZmcy5uZnNydi5yZWFsaWduX2NvdW50OiAwCnZmcy5uZnNydi5yZWFs aWduX3Rlc3Q6IDAKdmZzLm5mc3J2LmdhdGhlcmRlbGF5X3YzOiAwCnZmcy5uZnNydi5nYXRoZXJk ZWxheTogMTAwMDAKdmZzLm5mc3J2Lm1pbnRocmVhZHM6IDEKdmZzLm5mc3J2Lm1heHRocmVhZHM6 IDEKdmZzLm5mc3J2LnRocmVhZHM6IDAKdmZzLm5mc3J2LnJlcXVlc3Rfc3BhY2VfdXNlZDogMAp2 ZnMubmZzcnYucmVxdWVzdF9zcGFjZV91c2VkX2hpZ2hlc3Q6IDAKdmZzLm5mc3J2LnJlcXVlc3Rf c3BhY2VfaGlnaDogMTMxMDcyMDAKdmZzLm5mc3J2LnJlcXVlc3Rfc3BhY2VfbG93OiA4NzM4MTMz CnZmcy5uZnNydi5yZXF1ZXN0X3NwYWNlX3Rocm90dGxlZDogMAp2ZnMubmZzcnYucmVxdWVzdF9z cGFjZV90aHJvdHRsZV9jb3VudDogMAp2ZnMuZmZzLmRvcmVhbGxvY2Jsa3M6IDEKdmZzLmZmcy5k b2FzeW5jZnJlZTogMQp2ZnMuZmZzLmNvbXB1dGVfc3VtbWFyeV9hdF9tb3VudDogMApuZXQubG9j YWwuc3RyZWFtLnJlY3ZzcGFjZTogODE5MgpuZXQubG9jYWwuc3RyZWFtLnNlbmRzcGFjZTogODE5 MgpuZXQubG9jYWwuZGdyYW0ucmVjdnNwYWNlOiA0MDk2Cm5ldC5sb2NhbC5kZ3JhbS5tYXhkZ3Jh bTogMjA0OApuZXQubG9jYWwudGFza2NvdW50OiAwCm5ldC5sb2NhbC5yZWN5Y2xlZDogMApuZXQu bG9jYWwuaW5mbGlnaHQ6IDAKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbXRpbWU6IDQ1Cm5l dC5pbmV0LmlwLnBvcnRyYW5nZS5yYW5kb21jcHM6IDEwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5y YW5kb21pemVkOiAxCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5yZXNlcnZlZGxvdzogMApuZXQuaW5l dC5pcC5wb3J0cmFuZ2UucmVzZXJ2ZWRoaWdoOiAxMDIzCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5o aWxhc3Q6IDY1NTM1Cm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5oaWZpcnN0OiA0OTE1MgpuZXQuaW5l dC5pcC5wb3J0cmFuZ2UubGFzdDogNjU1MzUKbmV0LmluZXQuaXAucG9ydHJhbmdlLmZpcnN0OiAx MDAwMApuZXQuaW5ldC5pcC5wb3J0cmFuZ2UubG93bGFzdDogNjAwCm5ldC5pbmV0LmlwLnBvcnRy YW5nZS5sb3dmaXJzdDogMTAyMwpuZXQuaW5ldC5pcC5mb3J3YXJkaW5nOiAwCm5ldC5pbmV0Lmlw LnJlZGlyZWN0OiAxCm5ldC5pbmV0LmlwLnR0bDogNjQKbmV0LmluZXQuaXAucnRleHBpcmU6IDM2 MDAKbmV0LmluZXQuaXAucnRtaW5leHBpcmU6IDEwCm5ldC5pbmV0LmlwLnJ0bWF4Y2FjaGU6IDEy OApuZXQuaW5ldC5pcC5zb3VyY2Vyb3V0ZTogMApuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX21heGxl bjogNTAKbmV0LmluZXQuaXAuaW50cl9xdWV1ZV9kcm9wczogMApuZXQuaW5ldC5pcC5hY2NlcHRf c291cmNlcm91dGU6IDAKbmV0LmluZXQuaXAua2VlcGZhaXRoOiAwCm5ldC5pbmV0LmlwLmdpZnR0 bDogMzAKbmV0LmluZXQuaXAuc2FtZV9wcmVmaXhfY2FycF9vbmx5OiAwCm5ldC5pbmV0LmlwLnN1 Ym5ldHNfYXJlX2xvY2FsOiAwCm5ldC5pbmV0LmlwLnJhbmRvbV9pZF90b3RhbDogMApuZXQuaW5l dC5pcC5yYW5kb21faWRfY29sbGlzaW9uczogMApuZXQuaW5ldC5pcC5yYW5kb21faWRfcGVyaW9k OiA4MTkyCm5ldC5pbmV0LmlwLm1jYXN0Lmxvb3A6IDEKbmV0LmluZXQuaXAubWNhc3QubWF4c29j a3NyYzogMTI4Cm5ldC5pbmV0LmlwLm1jYXN0Lm1heGdycHNyYzogNTEyCm5ldC5pbmV0LmlwLmZh c3Rmb3J3YXJkaW5nOiAwCm5ldC5pbmV0LmlwLm1heGZyYWdwYWNrZXRzOiA4MDAKbmV0LmluZXQu aXAubWF4ZnJhZ3NwZXJwYWNrZXQ6IDE2Cm5ldC5pbmV0LmlwLmZyYWdwYWNrZXRzOiAwCm5ldC5p bmV0LmlwLmNoZWNrX2ludGVyZmFjZTogMApuZXQuaW5ldC5pcC5yYW5kb21faWQ6IDAKbmV0Lmlu ZXQuaXAuc2VuZHNvdXJjZXF1ZW5jaDogMApuZXQuaW5ldC5pcC5wcm9jZXNzX29wdGlvbnM6IDEK bmV0LmluZXQuaWNtcC5tYXNrcmVwbDogMApuZXQuaW5ldC5pY21wLmljbXBsaW06IDIwMApuZXQu aW5ldC5pY21wLmJtY2FzdGVjaG86IDAKbmV0LmluZXQuaWNtcC5xdW90ZWxlbjogOApuZXQuaW5l dC5pY21wLnJlcGx5X2Zyb21faW50ZXJmYWNlOiAwCm5ldC5pbmV0LmljbXAucmVwbHlfc3JjOiAK bmV0LmluZXQuaWNtcC5pY21wbGltX291dHB1dDogMQpuZXQuaW5ldC5pY21wLmxvZ19yZWRpcmVj dDogMApuZXQuaW5ldC5pY21wLmRyb3BfcmVkaXJlY3Q6IDAKbmV0LmluZXQuaWNtcC5tYXNrZmFr ZTogMApuZXQuaW5ldC5pZ21wLmdzcmRlbGF5OiAxMApuZXQuaW5ldC5pZ21wLmRlZmF1bHRfdmVy c2lvbjogMwpuZXQuaW5ldC5pZ21wLmxlZ2FjeXN1cHA6IDAKbmV0LmluZXQuaWdtcC52MmVuYWJs ZTogMQpuZXQuaW5ldC5pZ21wLnYxZW5hYmxlOiAxCm5ldC5pbmV0LmlnbXAuc2VuZGxvY2FsOiAx Cm5ldC5pbmV0LmlnbXAuc2VuZHJhOiAxCm5ldC5pbmV0LmlnbXAucmVjdmlma2x1ZGdlOiAxCm5l dC5pbmV0LnRjcC5yZmMxMzIzOiAxCm5ldC5pbmV0LnRjcC5tc3NkZmx0OiA1MTIKbmV0LmluZXQu dGNwLmtlZXBpZGxlOiA3MjAwMDAwCm5ldC5pbmV0LnRjcC5rZWVwaW50dmw6IDc1MDAwCm5ldC5p bmV0LnRjcC5zZW5kc3BhY2U6IDMyNzY4Cm5ldC5pbmV0LnRjcC5yZWN2c3BhY2U6IDY1NTM2Cm5l dC5pbmV0LnRjcC5rZWVwaW5pdDogNzUwMDAKbmV0LmluZXQudGNwLmRlbGFja3RpbWU6IDEwMApu ZXQuaW5ldC50Y3AuaG9zdGNhY2hlLnB1cmdlOiAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHJ1 bmU6IDMwMApuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmV4cGlyZTogMzYwMApuZXQuaW5ldC50Y3Au aG9zdGNhY2hlLmNvdW50OiAxMgpuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmJ1Y2tldGxpbWl0OiAz MApuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLmhvc3Rj YWNoZS5jYWNoZWxpbWl0OiAxNTM2MApuZXQuaW5ldC50Y3Aud2xvY2tfbG9vcGVkOiAwCm5ldC5p bmV0LnRjcC53bG9ja19yZWxvY2tlZDogMApuZXQuaW5ldC50Y3Aud2xvY2tfdXBncmFkZWQ6IDUx Cm5ldC5pbmV0LnRjcC50Y3Bfd2xvY2tfYXRmaXJzdDogMTgxCm5ldC5pbmV0LnRjcC5ybG9ja19h dGZpcnN0OiAxMzg4NgpuZXQuaW5ldC50Y3AucmVhZF9sb2NraW5nOiAxCm5ldC5pbmV0LnRjcC5y ZWN2YnVmX21heDogMjYyMTQ0Cm5ldC5pbmV0LnRjcC5yZWN2YnVmX2luYzogMTYzODQKbmV0Lmlu ZXQudGNwLnJlY3ZidWZfYXV0bzogMQpuZXQuaW5ldC50Y3AuaW5zZWN1cmVfcnN0OiAwCm5ldC5p bmV0LnRjcC5lY24ubWF4cmV0cmllczogMQpuZXQuaW5ldC50Y3AuZWNuLmVuYWJsZTogMApuZXQu aW5ldC50Y3AuYWJjX2xfdmFyOiAyCm5ldC5pbmV0LnRjcC5yZmMzNDY1OiAxCm5ldC5pbmV0LnRj cC5yZmMzMzkwOiAxCm5ldC5pbmV0LnRjcC5yZmMzMDQyOiAxCm5ldC5pbmV0LnRjcC5kcm9wX3N5 bmZpbjogMApuZXQuaW5ldC50Y3AuZGVsYXllZF9hY2s6IDEKbmV0LmluZXQudGNwLmJsYWNraG9s ZTogMApuZXQuaW5ldC50Y3AubG9nX2luX3ZhaW46IDAKbmV0LmluZXQudGNwLnNlbmRidWZfbWF4 OiAyNjIxNDQKbmV0LmluZXQudGNwLnNlbmRidWZfaW5jOiA4MTkyCm5ldC5pbmV0LnRjcC5zZW5k YnVmX2F1dG86IDEKbmV0LmluZXQudGNwLnRzbzogMQpuZXQuaW5ldC50Y3AubmV3cmVubzogMQpu ZXQuaW5ldC50Y3AubG9jYWxfc2xvd3N0YXJ0X2ZsaWdodHNpemU6IDQKbmV0LmluZXQudGNwLnNs b3dzdGFydF9mbGlnaHRzaXplOiAxCm5ldC5pbmV0LnRjcC5wYXRoX210dV9kaXNjb3Zlcnk6IDEK bmV0LmluZXQudGNwLnJlYXNzLm92ZXJmbG93czogMApuZXQuaW5ldC50Y3AucmVhc3MubWF4cWxl bjogNDgKbmV0LmluZXQudGNwLnJlYXNzLmN1cnNlZ21lbnRzOiAwCm5ldC5pbmV0LnRjcC5yZWFz cy5tYXhzZWdtZW50czogMTYwMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxob2xlczogMApuZXQu aW5ldC50Y3Auc2Fjay5nbG9iYWxtYXhob2xlczogNjU1MzYKbmV0LmluZXQudGNwLnNhY2subWF4 aG9sZXM6IDEyOApuZXQuaW5ldC50Y3Auc2Fjay5lbmFibGU6IDEKbmV0LmluZXQudGNwLmluZmxp Z2h0LnN0YWI6IDIwCm5ldC5pbmV0LnRjcC5pbmZsaWdodC5tYXg6IDEwNzM3MjU0NDAKbmV0Lmlu ZXQudGNwLmluZmxpZ2h0Lm1pbjogNjE0NApuZXQuaW5ldC50Y3AuaW5mbGlnaHQucnR0dGhyZXNo OiAxMApuZXQuaW5ldC50Y3AuaW5mbGlnaHQuZGVidWc6IDAKbmV0LmluZXQudGNwLmluZmxpZ2h0 LmVuYWJsZTogMQpuZXQuaW5ldC50Y3AuaXNuX3Jlc2VlZF9pbnRlcnZhbDogMApuZXQuaW5ldC50 Y3AuaWNtcF9tYXlfcnN0OiAxCm5ldC5pbmV0LnRjcC5wY2Jjb3VudDogOApuZXQuaW5ldC50Y3Au ZG9fdGNwZHJhaW46IDEKbmV0LmluZXQudGNwLnRjYmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNw LmxvZ19kZWJ1ZzogMApuZXQuaW5ldC50Y3AubWlubXNzOiAyMTYKbmV0LmluZXQudGNwLnN5bmNh Y2hlLnJzdF9vbl9zb2NrX2ZhaWw6IDEKbmV0LmluZXQudGNwLnN5bmNhY2hlLnJleG10bGltaXQ6 IDMKbmV0LmluZXQudGNwLnN5bmNhY2hlLmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLnN5bmNh Y2hlLmNvdW50OiAwCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5jYWNoZWxpbWl0OiAxNTM2MApuZXQu aW5ldC50Y3Auc3luY2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5pbmV0LnRjcC5zeW5jb29raWVz X29ubHk6IDAKbmV0LmluZXQudGNwLnN5bmNvb2tpZXM6IDEKbmV0LmluZXQudGNwLnRpbWVyX3Jh Y2U6IDAKbmV0LmluZXQudGNwLmZpbndhaXQyX3RpbWVvdXQ6IDYwMDAwCm5ldC5pbmV0LnRjcC5m YXN0X2ZpbndhaXQyX3JlY3ljbGU6IDAKbmV0LmluZXQudGNwLmFsd2F5c19rZWVwYWxpdmU6IDEK bmV0LmluZXQudGNwLnJleG1pdF9zbG9wOiAyMDAKbmV0LmluZXQudGNwLnJleG1pdF9taW46IDMw Cm5ldC5pbmV0LnRjcC5tc2w6IDMwMDAwCm5ldC5pbmV0LnRjcC5ub2xvY2FsdGltZXdhaXQ6IDAK bmV0LmluZXQudGNwLm1heHRjcHR3OiA1MTIwCm5ldC5pbmV0LnVkcC5jaGVja3N1bTogMQpuZXQu aW5ldC51ZHAubWF4ZGdyYW06IDkyMTYKbmV0LmluZXQudWRwLnJlY3ZzcGFjZTogNDE2MDAKbmV0 LmluZXQudWRwLmJsYWNraG9sZTogMApuZXQuaW5ldC51ZHAubG9nX2luX3ZhaW46IDAKbmV0Lmlu ZXQuc2N0cC5uYXRfZnJpZW5kbHlfaW5pdDogMQpuZXQuaW5ldC5zY3RwLmVuYWJsZV9zYWNrX2lt bWVkaWF0ZWx5OiAwCm5ldC5pbmV0LnNjdHAudWRwX3R1bm5lbGluZ19wb3J0OiAwCm5ldC5pbmV0 LnNjdHAudWRwX3R1bm5lbGluZ19mb3JfY2xpZW50X2VuYWJsZTogMApuZXQuaW5ldC5zY3RwLm1v YmlsaXR5X2Zhc3RoYW5kb2ZmOiAwCm5ldC5pbmV0LnNjdHAubW9iaWxpdHlfYmFzZTogMApuZXQu aW5ldC5zY3RwLmRlZmF1bHRfZnJhZ19pbnRlcmxlYXZlOiAxCm5ldC5pbmV0LnNjdHAuZGVmYXVs dF9jY19tb2R1bGU6IDAKbmV0LmluZXQuc2N0cC5sb2dfbGV2ZWw6IDAKbmV0LmluZXQuc2N0cC5t YXhfcmV0cmFuX2NodW5rOiAzMApuZXQuaW5ldC5zY3RwLm1pbl9yZXNpZHVhbDogMTQ1MgpuZXQu aW5ldC5zY3RwLnN0cmljdF9kYXRhX29yZGVyOiAwCm5ldC5pbmV0LnNjdHAuYWJvcnRfYXRfbGlt aXQ6IDAKbmV0LmluZXQuc2N0cC5oYl9tYXhfYnVyc3Q6IDQKbmV0LmluZXQuc2N0cC5kb19zY3Rw X2RyYWluOiAxCm5ldC5pbmV0LnNjdHAubWF4X2NoYWluZWRfbWJ1ZnM6IDUKbmV0LmluZXQuc2N0 cC5hYmNfbF92YXI6IDEKbmV0LmluZXQuc2N0cC5uYXRfZnJpZW5kbHk6IDEKbmV0LmluZXQuc2N0 cC5hdXRoX2Rpc2FibGU6IDAKbmV0LmluZXQuc2N0cC5hc2NvbmZfYXV0aF9ub2NoazogMApuZXQu aW5ldC5zY3RwLmVhcmx5X2Zhc3RfcmV0cmFuX21zZWM6IDI1MApuZXQuaW5ldC5zY3RwLmVhcmx5 X2Zhc3RfcmV0cmFuOiAwCm5ldC5pbmV0LnNjdHAuY3duZF9tYXhidXJzdDogMQpuZXQuaW5ldC5z Y3RwLmNtdF9wZjogMApuZXQuaW5ldC5zY3RwLmNtdF91c2VfZGFjOiAwCm5ldC5pbmV0LnNjdHAu bnJfc2Fja19vbl9vZmY6IDAKbmV0LmluZXQuc2N0cC5jbXRfb25fb2ZmOiAwCm5ldC5pbmV0LnNj dHAub3V0Z29pbmdfc3RyZWFtczogMTAKbmV0LmluZXQuc2N0cC5hZGRfbW9yZV9vbl9vdXRwdXQ6 IDE0NTIKbmV0LmluZXQuc2N0cC5wYXRoX3J0eF9tYXg6IDUKbmV0LmluZXQuc2N0cC5hc3NvY19y dHhfbWF4OiAxMApuZXQuaW5ldC5zY3RwLmluaXRfcnR4X21heDogOApuZXQuaW5ldC5zY3RwLnZh bGlkX2Nvb2tpZV9saWZlOiA2MDAwMApuZXQuaW5ldC5zY3RwLmluaXRfcnRvX21heDogNjAwMDAK bmV0LmluZXQuc2N0cC5ydG9faW5pdGlhbDogMzAwMApuZXQuaW5ldC5zY3RwLnJ0b19taW46IDEw MDAKbmV0LmluZXQuc2N0cC5ydG9fbWF4OiA2MDAwMApuZXQuaW5ldC5zY3RwLnNlY3JldF9saWZl dGltZTogMzYwMApuZXQuaW5ldC5zY3RwLnNodXRkb3duX2d1YXJkX3RpbWU6IDE4MApuZXQuaW5l dC5zY3RwLnBtdHVfcmFpc2VfdGltZTogNjAwCm5ldC5pbmV0LnNjdHAuaGVhcnRiZWF0X2ludGVy dmFsOiAzMDAwMApuZXQuaW5ldC5zY3RwLmFzb2NfcmVzb3VyY2U6IDEwCm5ldC5pbmV0LnNjdHAu c3lzX3Jlc291cmNlOiAxMDAwCm5ldC5pbmV0LnNjdHAuc2Fja19mcmVxOiAyCm5ldC5pbmV0LnNj dHAuZGVsYXllZF9zYWNrX3RpbWU6IDIwMApuZXQuaW5ldC5zY3RwLmNodW5rc2NhbGU6IDEwCm5l dC5pbmV0LnNjdHAubWluX3NwbGl0X3BvaW50OiAyOTA0Cm5ldC5pbmV0LnNjdHAucGNiaGFzaHNp emU6IDI1NgpuZXQuaW5ldC5zY3RwLnRjYmhhc2hzaXplOiAxMDI0Cm5ldC5pbmV0LnNjdHAubWF4 Y2h1bmtzOiAzMjAwCm5ldC5pbmV0LnNjdHAubWF4YnVyc3Q6IDQKbmV0LmluZXQuc2N0cC5wZWVy X2Noa29oOiAyNTYKbmV0LmluZXQuc2N0cC5zdHJpY3RfaW5pdDogMQpuZXQuaW5ldC5zY3RwLmxv b3BiYWNrX25vY3N1bTogMQpuZXQuaW5ldC5zY3RwLnN0cmljdF9zYWNrczogMQpuZXQuaW5ldC5z Y3RwLmVjbl9ub25jZTogMApuZXQuaW5ldC5zY3RwLmVjbl9lbmFibGU6IDEKbmV0LmluZXQuc2N0 cC5hdXRvX2FzY29uZjogMQpuZXQuaW5ldC5zY3RwLnJlY3ZzcGFjZTogMjMzMDE2Cm5ldC5pbmV0 LnNjdHAuc2VuZHNwYWNlOiAyMzMwMTYKbmV0LmluZXQucmF3LnJlY3ZzcGFjZTogOTIxNgpuZXQu aW5ldC5yYXcubWF4ZGdyYW06IDkyMTYKbmV0LmluZXQuYWNjZi51bmxvYWRhYmxlOiAwCm5ldC5s aW5rLmdlbmVyaWMuc3lzdGVtLmlmY291bnQ6IDQKbmV0LmxpbmsuZXRoZXIuaW5ldC5sb2dfYXJw X3Blcm1hbmVudF9tb2RpZnk6IDEKbmV0LmxpbmsuZXRoZXIuaW5ldC5sb2dfYXJwX21vdmVtZW50 czogMQpuZXQubGluay5ldGhlci5pbmV0LmxvZ19hcnBfd3JvbmdfaWZhY2U6IDEKbmV0Lmxpbmsu ZXRoZXIuaW5ldC5wcm94eWFsbDogMApuZXQubGluay5ldGhlci5pbmV0LnVzZWxvb3BiYWNrOiAx Cm5ldC5saW5rLmV0aGVyLmluZXQubWF4dHJpZXM6IDUKbmV0LmxpbmsuZXRoZXIuaW5ldC5tYXhf YWdlOiAxMjAwCm5ldC5saW5rLmV0aGVyLmlwZnc6IDAKbmV0LmxpbmsuZ2lmLnBhcmFsbGVsX3R1 bm5lbHM6IDAKbmV0LmxpbmsuZ2lmLm1heF9uZXN0aW5nOiAxCm5ldC5saW5rLmxvZ19saW5rX3N0 YXRlX2NoYW5nZTogMQpuZXQubGluay50dW4uZGV2ZnNfY2xvbmluZzogMQpuZXQuYnBmLnplcm9j b3B5X2VuYWJsZTogMApuZXQuYnBmLm1heGluc25zOiA1MTIKbmV0LmJwZi5tYXhidWZzaXplOiA1 MjQyODgKbmV0LmJwZi5idWZzaXplOiA0MDk2Cm5ldC5pc3Iuc3dpX2NvdW50OiAyNwpuZXQuaXNy LmRyb3A6IDAKbmV0Lmlzci5xdWV1ZWQ6IDI5Cm5ldC5pc3IuZGVmZXJyZWQ6IDAKbmV0Lmlzci5k aXJlY3RlZDogMTQxNTMKbmV0Lmlzci5jb3VudDogMTQxNTMKbmV0Lmlzci5kaXJlY3Q6IDEKbmV0 LnJhdy5yZWN2c3BhY2U6IDgxOTIKbmV0LnJhdy5zZW5kc3BhY2U6IDgxOTIKbmV0Lm15X2ZpYm51 bTogMApuZXQuYWRkX2FkZHJfYWxsZmliczogMQpuZXQuZmliczogMQpuZXQucm91dGUubmV0aXNy X21heHFsZW46IDI1NgpuZXQud2xhbi5hZGRiYV9tYXh0cmllczogMwpuZXQud2xhbi5hZGRiYV9i YWNrb2ZmOiAxMDAwMApuZXQud2xhbi5hZGRiYV90aW1lb3V0OiAyNTAKbmV0LndsYW4uYW1wZHVf YWdlOiA1MDAKbmV0LndsYW4uY2FjX3RpbWVvdXQ6IDYwCm5ldC53bGFuLm5vbF90aW1lb3V0OiAx ODAwCm5ldC53bGFuLnJlY3ZfYmFyOiAxCm5ldC53bGFuLjAuJXBhcmVudDogYXRoMApuZXQud2xh bi4wLmRyaXZlcl9jYXBzOiAxNzM2NDk5MjAxCm5ldC53bGFuLjAuYm1pc3NfbWF4OiAyCm5ldC53 bGFuLjAuaW5hY3RfcnVuOiAzMDAKbmV0LndsYW4uMC5pbmFjdF9wcm9iZTogMzAKbmV0LndsYW4u MC5pbmFjdF9hdXRoOiAxODAKbmV0LndsYW4uMC5pbmFjdF9pbml0OiAzMApkZWJ1Zy5hY3BpLnNl bWFwaG9yZV9kZWJ1ZzogMApkZWJ1Zy5hY3BpLnN1c3BlbmRfYm91bmNlOiAwCmRlYnVnLmFjcGku ZG9fcG93ZXJzdGF0ZTogMQpkZWJ1Zy5hY3BpLmFjcGlfY2FfdmVyc2lvbjogMjAwNzAzMjAKZGVi dWcuYWNwaS5lYy50aW1lb3V0OiA3NTAKZGVidWcuYWNwaS5lYy5wb2xsZWQ6IDAKZGVidWcuYWNw aS5lYy5idXJzdDogMApkZWJ1Zy5hY3BpLmJhdHQuYmF0dF9zbGVlcF9tczogMApkZWJ1Zy5hY3Bp LnJlc3VtZV9iZWVwOiAwCmRlYnVnLm1kZGVidWc6IDAKZGVidWcuZWxmMzJfbGVnYWN5X2NvcmVk dW1wOiAwCmRlYnVnLmJvb3R2ZXJib3NlOiAwCmRlYnVnLmJvb3Rob3d0bzogLTIxNDc0ODM2NDgK ZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwCmRlYnVnLmNwdWZyZXEubG93ZXN0OiAwCmRlYnVnLnNp emVvZi5jZGV2X3ByaXY6IDIzNgpkZWJ1Zy5zaXplb2YuY2RldjogMTg0CmRlYnVnLnNpemVvZi5n X2Jpb3E6IDMyCmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA2MApkZWJ1Zy5zaXplb2YuZ19wcm92 aWRlcjogODgKZGVidWcuc2l6ZW9mLmdfZ2VvbTogNjgKZGVidWcuc2l6ZW9mLmdfY2xhc3M6IDY4 CmRlYnVnLnNpemVvZi5raW5mb19wcm9jOiA3NjgKZGVidWcuc2l6ZW9mLmJ1ZjogMzM2CmRlYnVn LnNpemVvZi5iaW86IDEzMgpkZWJ1Zy5zaXplb2YucHJvYzogNjc2CmRlYnVnLnNpemVvZi52bm9k ZTogMjY4CmRlYnVnLnNpemVvZi5kZXZzdGF0OiAyNDAKZGVidWcuc2l6ZW9mLm5hbWVjYWNoZTog MzYKZGVidWcub3NkOiAwCmRlYnVnLnJ3bG9jay5sb29wczogMTAwMDAKZGVidWcucndsb2NrLnJl dHJ5OiAxMApkZWJ1Zy50b19hdmdfbXBjYWxsczogNzQ4CmRlYnVnLnRvX2F2Z19sb2NrY2FsbHM6 IDI3CmRlYnVnLnRvX2F2Z19nY2FsbHM6IDAKZGVidWcudG9fYXZnX2RlcHRoOiAxMDMyCmRlYnVn LnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDAKZGVidWcua2RiLnN0b3BfY3B1czogMQpkZWJ1Zy5r ZGIudHJhcF9jb2RlOiAwCmRlYnVnLmtkYi50cmFwOiAwCmRlYnVnLmtkYi5wYW5pYzogMApkZWJ1 Zy5rZGIuZW50ZXI6IDAKZGVidWcua2RiLmN1cnJlbnQ6IApkZWJ1Zy5rZGIuYXZhaWxhYmxlOiAK ZGVidWcucm1hbl9kZWJ1ZzogMApkZWJ1Zy50dHlkZWJ1ZzogMApkZWJ1Zy5kaXNhYmxlZnVsbHBh dGg6IDAKZGVidWcuZGlzYWJsZWN3ZDogMApkZWJ1Zy52ZnNjYWNoZTogMQpkZWJ1Zy5udW1jYWNo ZWh2OiA5MjAxCmRlYnVnLm51bWNhY2hlOiA0NzUxNgpkZWJ1Zy5udW1uZWc6IDIzMjMKZGVidWcu bmNuZWdmYWN0b3I6IDE2CmRlYnVnLm5jaGFzaDogMTMxMDcxCmRlYnVnLnZubHJ1X25vd2hlcmU6 IDAKZGVidWcucnVzaF9yZXF1ZXN0czogMApkZWJ1Zy5tcHNhZmV2ZnM6IDEKZGVidWcuaWZfdHVu X2RlYnVnOiAwCmRlYnVnLm1wc2FmZV9pZ21wOiAwCmRlYnVnLm5sbV9kZWJ1ZzogMApkZWJ1Zy5j b2xsZWN0c25hcHN0YXRzOiAwCmRlYnVnLnNuYXBkZWJ1ZzogMApkZWJ1Zy5kb3BlcnNpc3RlbmNl OiAwCmRlYnVnLmRpcl9lbnRyeTogMzAwMwpkZWJ1Zy5kaXJlY3RfYmxrX3B0cnM6IDY2MQpkZWJ1 Zy5pbm9kZV9iaXRtYXA6IDc3MwpkZWJ1Zy5pbmRpcl9ibGtfcHRyczogOApkZWJ1Zy5zeW5jX2xp bWl0X2hpdDogMApkZWJ1Zy5pbm9fbGltaXRfaGl0OiAwCmRlYnVnLmJsa19saW1pdF9oaXQ6IDAK ZGVidWcuaW5vX2xpbWl0X3B1c2g6IDAKZGVidWcuYmxrX2xpbWl0X3B1c2g6IDAKZGVidWcud29y a2xpc3RfcHVzaDogMApkZWJ1Zy5tYXhpbmRpcmRlcHM6IDUwCmRlYnVnLnRpY2tkZWxheTogMgpk ZWJ1Zy5tYXhfc29mdGRlcHM6IDI3ODA4MApkZWJ1Zy5kb2JrZ3Jkd3JpdGU6IDEKZGVidWcuYmln Y2dzOiAwCmRlYnVnLmRpcmNoZWNrOiAwCmRlYnVnLnBzbS5wa3RlcnJ0aHJlc2g6IDIKZGVidWcu cHNtLnVzZWNzOiA1MDAwMDAKZGVidWcucHNtLnNlY3M6IDAKZGVidWcucHNtLmVycnVzZWNzOiAw CmRlYnVnLnBzbS5lcnJzZWNzOiAyCmRlYnVnLnBzbS5oejogMjAKZGVidWcucHNtLmxvZ2xldmVs OiAwCmRlYnVnLm1pbmlkdW1wOiAxCmRlYnVnLlBNQVAxdW5jaGFuZ2VkOiAxMzEzMDcyNQpkZWJ1 Zy5QTUFQMWNoYW5nZWQ6IDExNzc5OApkZWJ1Zy5QTUFQMWNoYW5nZWRjcHU6IDczCmh3Lm1hY2hp bmU6IGkzODYKaHcubW9kZWw6IEludGVsKFIpIEF0b20oVE0pIENQVSBOMjgwICAgQCAxLjY2R0h6 Cmh3Lm5jcHU6IDIKaHcuYnl0ZW9yZGVyOiAxMjM0Cmh3LnBoeXNtZW06IDEwNTYwMTg0MzIKaHcu dXNlcm1lbTogODQ1NjQzNzc2Cmh3LnBhZ2VzaXplOiA0MDk2Cmh3LmZsb2F0aW5ncG9pbnQ6IDEK aHcubWFjaGluZV9hcmNoOiBpMzg2Cmh3LnJlYWxtZW06IDEwNjQ5NjAwMDAKaHcuYXRhLnNldG1h eDogMApody5hdGEud2M6IDEKaHcuYXRhLmF0YXBpX2RtYTogMQpody5hdGEuYXRhX2RtYV9jaGVj a184MHBpbjogMQpody5hdGEuYXRhX2RtYTogMQpody5hdGguYnN0dWNrOiA0Cmh3LmF0aC50eGJ1 ZjogMjAwCmh3LmF0aC5yeGJ1ZjogNDAKaHcuYXRoLnJlc2V0Y2FsOiAxMjAwCmh3LmF0aC5zaG9y dGNhbDogMTAwCmh3LmF0aC5sb25nY2FsOiAzMApody5hdGguaGFsLnN3YmFfYmFja29mZjogMApo dy5hdGguaGFsLnN3X2JydDogMTAKaHcuYXRoLmhhbC5kbWFfYnJ0OiAyCmh3LnBjaS5ob25vcl9t c2lfYmxhY2tsaXN0OiAxCmh3LnBjaS5lbmFibGVfbXNpeDogMQpody5wY2kuZW5hYmxlX21zaTog MQpody5wY2kuZG9fcG93ZXJfcmVzdW1lOiAxCmh3LnBjaS5kb19wb3dlcl9ub2RyaXZlcjogMQpo dy5wY2kuZW5hYmxlX2lvX21vZGVzOiAxCmh3LnBjaS5ob3N0X21lbV9zdGFydDogMjE0NzQ4MzY0 OApody5wY2kuaXJxX292ZXJyaWRlX21hc2s6IDU3MDgwCmh3LnN5c2NvbnMua2JkX2RlYnVnOiAx Cmh3LnN5c2NvbnMua2JkX3JlYm9vdDogMQpody5zeXNjb25zLmJlbGw6IDEKaHcuc3lzY29ucy5z YXZlci5rZXlib25seTogMQpody5zeXNjb25zLnNjX25vX3N1c3BlbmRfdnRzd2l0Y2g6IDAKaHcu dXNiMi5laGNpLm5vX2hzOiAwCmh3LnVzYjIuZWhjaS5kZWJ1ZzogMApody51c2IyLm9oY2kuZGVi dWc6IDAKaHcudXNiMi51aGNpLmxvb3A6IDAKaHcudXNiMi51aGNpLmRlYnVnOiAwCmh3LnVzYjIu Y3RybC5kZWJ1ZzogMApody51c2IyLnVtYXNzLmRlYnVnOiAwCmh3LnVzYjIudXJpby5kZWJ1Zzog MApody51c2IyLmRlYnVnOiAwCmh3LnVzYjIuZGV2LmRlYnVnOiAwCmh3LnVzYjIudGVtcGxhdGU6 IDAKaHcudXNiMi51Z2VuLmRlYnVnOiAwCmh3LnVzYjIucG93ZXJfdGltZW91dDogMzAKaHcudXNi Mi51aHViLmRlYnVnOiAwCmh3LnVzYjIucHJvYy5kZWJ1ZzogMApody51c2IyLnNzX2RlbGF5OiAw Cmh3LnVzYjIucHJfcmVjb3ZlcnlfZGVsYXk6IDI1MApody51c2IyLnByX3BvbGxfZGVsYXk6IDUw Cmh3LnVzYjIucnVtLmRlYnVnOiAwCmh3LnVzYjIudXJhbC5kZWJ1ZzogMApody51c2IyLnp5ZC5k ZWJ1ZzogMApody51c2IyLnVscHQuZGVidWc6IDAKaHcudXNiMi51Y29tLmRlYnVnOiAwCmh3LnVz YjIudWhpZC5kZWJ1ZzogMApody51c2IyLnVrYmQuZGVidWc6IDAKaHcudXNiMi51bXMuZGVidWc6 IDAKaHcuaW50cl9zdG9ybV90aHJlc2hvbGQ6IDEwMDAKaHcuYXZhaWxwYWdlczogMjU3ODE3Cmh3 LmJ1cy5kZXZjdGxfZGlzYWJsZTogMApody5wc20udGFwX3RpbWVvdXQ6IDEyNTAwMApody5wc20u dGFwX3RocmVzaG9sZDogMjUKaHcua2JkLmtleW1hcF9yZXN0cmljdF9jaGFuZ2U6IDAKaHcuYnVz ZG1hLnRvdGFsX2JwYWdlczogMjg1Cmh3LmJ1c2RtYS56b25lMC50b3RhbF9icGFnZXM6IDkzCmh3 LmJ1c2RtYS56b25lMC5mcmVlX2JwYWdlczogOTMKaHcuYnVzZG1hLnpvbmUwLnJlc2VydmVkX2Jw YWdlczogMApody5idXNkbWEuem9uZTAuYWN0aXZlX2JwYWdlczogMApody5idXNkbWEuem9uZTAu dG90YWxfYm91bmNlZDogMApody5idXNkbWEuem9uZTAudG90YWxfZGVmZXJyZWQ6IDAKaHcuYnVz ZG1hLnpvbmUwLmxvd2FkZHI6IDB4ZmZmZmZmZmYKaHcuYnVzZG1hLnpvbmUwLmFsaWdubWVudDog NDA5Ngpody5idXNkbWEuem9uZTAuYm91bmRhcnk6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2Jw YWdlczogMTkyCmh3LmJ1c2RtYS56b25lMS5mcmVlX2JwYWdlczogMTkyCmh3LmJ1c2RtYS56b25l MS5yZXNlcnZlZF9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLmFjdGl2ZV9icGFnZXM6IDAKaHcu YnVzZG1hLnpvbmUxLnRvdGFsX2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2RlZmVy cmVkOiAwCmh3LmJ1c2RtYS56b25lMS5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2RtYS56b25l MS5hbGlnbm1lbnQ6IDIKaHcuYnVzZG1hLnpvbmUxLmJvdW5kYXJ5OiA2NTUzNgpody5jbG9ja3Jh dGU6IDE2NjIKaHcudmlhX2ZlYXR1cmVfeGNyeXB0OiAwCmh3LnZpYV9mZWF0dXJlX3JuZzogMApo dy5pbnN0cnVjdGlvbl9zc2U6IDEKaHcuYXBpYy5lbmFibGVfZXh0aW50OiAwCmh3LnNuZC5sYXRl bmN5X3Byb2ZpbGU6IDEKaHcuc25kLmxhdGVuY3k6IDUKaHcuc25kLnJlcG9ydF9zb2Z0X2Zvcm1h dHM6IDEKaHcuc25kLmNvbXBhdF9saW51eF9tbWFwOiAwCmh3LnNuZC5mZWVkZXJfYnVmZmVyc2l6 ZTogMTYzODQKaHcuc25kLmZlZWRlcl9yYXRlX3JvdW5kOiAyNQpody5zbmQuZmVlZGVyX3JhdGVf bWF4OiAyMDE2MDAwCmh3LnNuZC5mZWVkZXJfcmF0ZV9taW46IDEKaHcuc25kLnZlcmJvc2U6IDEK aHcuc25kLm1heGF1dG92Y2hhbnM6IDE2Cmh3LnNuZC5kZWZhdWx0X3VuaXQ6IDAKaHcuc25kLnZl cnNpb246IDIwMDcwNjE2MDAvaTM4Ngpody5zbmQuZGVmYXVsdF9hdXRvOiAwCmh3Lm1pZGkuaW5z dHJvZmY6IDAKaHcubWlkaS5kdW1wcmF3OiAwCmh3Lm1pZGkuZGVidWc6IDAKaHcubWlkaS5zdGF0 LnZlcmJvc2U6IDAKaHcubWlkaS5zZXEuZGVidWc6IDAKaHcuYWNwaS5zdXBwb3J0ZWRfc2xlZXBf c3RhdGU6IFMxIFMzIFM0IFM1Cmh3LmFjcGkucG93ZXJfYnV0dG9uX3N0YXRlOiBTNQpody5hY3Bp LnNsZWVwX2J1dHRvbl9zdGF0ZTogUzEKaHcuYWNwaS5saWRfc3dpdGNoX3N0YXRlOiBOT05FCmh3 LmFjcGkuc3RhbmRieV9zdGF0ZTogUzEKaHcuYWNwaS5zdXNwZW5kX3N0YXRlOiBTMwpody5hY3Bp LnNsZWVwX2RlbGF5OiAxCmh3LmFjcGkuczRiaW9zOiAwCmh3LmFjcGkudmVyYm9zZTogMApody5h Y3BpLmRpc2FibGVfb25fcmVib290OiAwCmh3LmFjcGkuaGFuZGxlX3JlYm9vdDogMApody5hY3Bp LnJlc2V0X3ZpZGVvOiAwCmh3LmFjcGkuYXN1cy5sY2RfYnJpZ2h0bmVzczogMTUKaHcuYWNwaS5h c3VzLmNhbWVyYTogMQpody5hY3BpLmFzdXMuY2FyZHJlYWRlcjogMQpody5hY3BpLmFzdXMud2xh bjogMQpody5hY3BpLnRoZXJtYWwubWluX3J1bnRpbWU6IDAKaHcuYWNwaS50aGVybWFsLnBvbGxp bmdfcmF0ZTogMTAKaHcuYWNwaS50aGVybWFsLnVzZXJfb3ZlcnJpZGU6IDAKaHcuYWNwaS50aGVy bWFsLnR6MC50ZW1wZXJhdHVyZTogNTQuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5hY3RpdmU6IC0x Cmh3LmFjcGkudGhlcm1hbC50ejAucGFzc2l2ZV9jb29saW5nOiAxCmh3LmFjcGkudGhlcm1hbC50 ejAudGhlcm1hbF9mbGFnczogMApody5hY3BpLnRoZXJtYWwudHowLl9QU1Y6IDgyLjBDCmh3LmFj cGkudGhlcm1hbC50ejAuX0hPVDogLTEKaHcuYWNwaS50aGVybWFsLnR6MC5fQ1JUOiA4NS4wQwpo dy5hY3BpLnRoZXJtYWwudHowLl9BQ3g6IC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xCmh3 LmFjcGkudGhlcm1hbC50ejAuX1RDMTogMgpody5hY3BpLnRoZXJtYWwudHowLl9UQzI6IDEwCmh3 LmFjcGkudGhlcm1hbC50ejAuX1RTUDogMzAKaHcuYWNwaS5iYXR0ZXJ5LmxpZmU6IDEwMApody5h Y3BpLmJhdHRlcnkudGltZTogLTEKaHcuYWNwaS5iYXR0ZXJ5LnN0YXRlOiAwCmh3LmFjcGkuYmF0 dGVyeS51bml0czogMQpody5hY3BpLmJhdHRlcnkuaW5mb19leHBpcmU6IDUKaHcuYWNwaS5hY2xp bmU6IDEKaHcuYWNwaS5jcHUuY3hfbG93ZXN0OiBDMQpody5kcmkuMC5uYW1lOiBpOTE1IDB4NmIg cGNpOjAwMDA6MDA6MDIuMApody5kcmkuMC52bTogCnNsb3Qgb2Zmc2V0CSAgICAgICAgc2l6ZSAg ICAgICB0eXBlIGZsYWdzIGFkZHJlc3MgICAgICAgICAgICBtdHJyCiAgIDAgMHgwMDAwMDAwMGY3 ZjAwMDAwIDB4MDAwODAwMDAgIFJFRyAgMHg4OCAweDAwMDAwMDAwZTY0ZTEwMDAgbm8KICAgMSAw eDAwMDAwMDAwYzQ1MDgwMDAgMHgwMDAwMjAwMCAgU0hNICAweDIwIDB4MDAwMDAwMDBjNDUwODAw MCBubwogICAyIDB4MDAwMDAwMDBkMDAwMDAwMCAweDAwMDIwMDAwICBBR1AgIDB4MDAgMHgwMDAw MDAwMDAwMDAwMDAwIHllcwogICAzIDB4MDAwMDAwMDBkMDgwMDAwMCAweDAwNDAwMDAwICBBR1Ag IDB4MDAgMHgwMDAwMDAwMDAwMDAwMDAwIHllcwogICA0IDB4MDAwMDAwMDBkMTgwMDAwMCAweDAw NDAwMDAwICBBR1AgIDB4MDAgMHgwMDAwMDAwMDAwMDAwMDAwIHllcwogICA1IDB4MDAwMDAwMDBk MWMwMDAwMCAweDAwNDAwMDAwICBBR1AgIDB4MDAgMHgwMDAwMDAwMDAwMDAwMDAwIHllcwogICA2 IDB4MDAwMDAwMDBkMjAwMDAwMCAweDAyMDAwMDAwICBBR1AgIDB4MDAgMHgwMDAwMDAwMDAwMDAw MDAwIHllcwoKaHcuZHJpLjAuY2xpZW50czogCmEgZGV2CXBpZCAgICB1aWQJbWFnaWMJICBpb2N0 bHMKeSAgIDAgIDExMzUgICAgIDAgICAgICAgICAgMCAgICAgNDU3ODk1Cgpody5kcmkuMC5kZWJ1 ZzogMAptYWNoZGVwLmFjcGlfdGltZXJfZnJlcTogMzU3OTU0NQptYWNoZGVwLmVuYWJsZV9wYW5p Y19rZXk6IDAKbWFjaGRlcC5hZGprZXJudHo6IDAKbWFjaGRlcC53YWxsX2Ntb3NfY2xvY2s6IDAK bWFjaGRlcC5kaXNhYmxlX3J0Y19zZXQ6IDAKbWFjaGRlcC5hY3BpX3Jvb3Q6IDEwMzA2MDgKbWFj aGRlcC5kaXNhYmxlX210cnJzOiAwCm1hY2hkZXAuZ3Vlc3NlZF9ib290ZGV2OiAyNjg2NDUxNzEy Cm1hY2hkZXAuaWRsZTogYWNwaQptYWNoZGVwLmlkbGVfYXZhaWxhYmxlOiBzcGluLCBtd2FpdCwg bXdhaXRfaGx0LCBobHQsIGFjcGksIAptYWNoZGVwLmhsdF9jcHVzOiAwCm1hY2hkZXAucHJvdF9m YXVsdF90cmFuc2xhdGlvbjogMAptYWNoZGVwLnBhbmljX29uX25taTogMQptYWNoZGVwLnRzY19m cmVxOiAxNjYyNTE0NjcwCm1hY2hkZXAuaTgyNTRfZnJlcTogMTE5MzE4MgptYWNoZGVwLmhsdF9s b2dpY2FsX2NwdXM6IDAKbWFjaGRlcC5sb2dpY2FsX2NwdXNfbWFzazogMgptYWNoZGVwLmh5cGVy dGhyZWFkaW5nX2FsbG93ZWQ6IDEKdXNlci5jc19wYXRoOiAvdXNyL2JpbjovYmluOi91c3Ivc2Jp bjovc2JpbjoKdXNlci5iY19iYXNlX21heDogOTkKdXNlci5iY19kaW1fbWF4OiAyMDQ4CnVzZXIu YmNfc2NhbGVfbWF4OiA5OQp1c2VyLmJjX3N0cmluZ19tYXg6IDEwMDAKdXNlci5jb2xsX3dlaWdo dHNfbWF4OiAwCnVzZXIuZXhwcl9uZXN0X21heDogMzIKdXNlci5saW5lX21heDogMjA0OAp1c2Vy LnJlX2R1cF9tYXg6IDI1NQp1c2VyLnBvc2l4Ml92ZXJzaW9uOiAxOTkyMTIKdXNlci5wb3NpeDJf Y19iaW5kOiAwCnVzZXIucG9zaXgyX2NfZGV2OiAwCnVzZXIucG9zaXgyX2NoYXJfdGVybTogMAp1 c2VyLnBvc2l4Ml9mb3J0X2RldjogMAp1c2VyLnBvc2l4Ml9mb3J0X3J1bjogMAp1c2VyLnBvc2l4 Ml9sb2NhbGVkZWY6IDAKdXNlci5wb3NpeDJfc3dfZGV2OiAwCnVzZXIucG9zaXgyX3VwZTogMAp1 c2VyLnN0cmVhbV9tYXg6IDIwCnVzZXIudHpuYW1lX21heDogMjU1CnAxMDAzXzFiLmFzeW5jaHJv bm91c19pbzogMApwMTAwM18xYi5tYXBwZWRfZmlsZXM6IDEKcDEwMDNfMWIubWVtbG9jazogMApw MTAwM18xYi5tZW1sb2NrX3JhbmdlOiAwCnAxMDAzXzFiLm1lbW9yeV9wcm90ZWN0aW9uOiAwCnAx MDAzXzFiLm1lc3NhZ2VfcGFzc2luZzogMApwMTAwM18xYi5wcmlvcml0aXplZF9pbzogMApwMTAw M18xYi5wcmlvcml0eV9zY2hlZHVsaW5nOiAxCnAxMDAzXzFiLnJlYWx0aW1lX3NpZ25hbHM6IDIw MDExMgpwMTAwM18xYi5zZW1hcGhvcmVzOiAwCnAxMDAzXzFiLmZzeW5jOiAwCnAxMDAzXzFiLnNo YXJlZF9tZW1vcnlfb2JqZWN0czogMQpwMTAwM18xYi5zeW5jaHJvbml6ZWRfaW86IDAKcDEwMDNf MWIudGltZXJzOiAyMDAxMTIKcDEwMDNfMWIuYWlvX2xpc3Rpb19tYXg6IC0xCnAxMDAzXzFiLmFp b19tYXg6IC0xCnAxMDAzXzFiLmFpb19wcmlvX2RlbHRhX21heDogLTEKcDEwMDNfMWIuZGVsYXl0 aW1lcl9tYXg6IDIxNDc0ODM2NDcKcDEwMDNfMWIubXFfb3Blbl9tYXg6IDAKcDEwMDNfMWIucGFn ZXNpemU6IDQwOTYKcDEwMDNfMWIucnRzaWdfbWF4OiA2MgpwMTAwM18xYi5zZW1fbnNlbXNfbWF4 OiAwCnAxMDAzXzFiLnNlbV92YWx1ZV9tYXg6IDAKcDEwMDNfMWIuc2lncXVldWVfbWF4OiAxMjgK cDEwMDNfMWIudGltZXJfbWF4OiAzMgpzZWN1cml0eS5qYWlsLmphaWxlZDogMApzZWN1cml0eS5q YWlsLmphaWxfbWF4X2FmX2lwczogMjU1CnNlY3VyaXR5LmphaWwubW91bnRfYWxsb3dlZDogMApz ZWN1cml0eS5qYWlsLmNoZmxhZ3NfYWxsb3dlZDogMApzZWN1cml0eS5qYWlsLmFsbG93X3Jhd19z b2NrZXRzOiAwCnNlY3VyaXR5LmphaWwuZW5mb3JjZV9zdGF0ZnM6IDIKc2VjdXJpdHkuamFpbC5z eXN2aXBjX2FsbG93ZWQ6IDAKc2VjdXJpdHkuamFpbC5zb2NrZXRfdW5peGlwcm91dGVfb25seTog MQpzZWN1cml0eS5qYWlsLnNldF9ob3N0bmFtZV9hbGxvd2VkOiAxCnNlY3VyaXR5LmJzZC5zdXNl cl9lbmFibGVkOiAxCnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfcHJvY19kZWJ1ZzogMQpzZWN1 cml0eS5ic2QuY29uc2VydmF0aXZlX3NpZ25hbHM6IDEKc2VjdXJpdHkuYnNkLnNlZV9vdGhlcl9n aWRzOiAxCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkczogMQpzZWN1cml0eS5ic2QudW5wcml2 aWxlZ2VkX3JlYWRfbXNnYnVmOiAxCnNlY3VyaXR5LmJzZC5oYXJkbGlua19jaGVja19naWQ6IDAK c2VjdXJpdHkuYnNkLmhhcmRsaW5rX2NoZWNrX3VpZDogMApzZWN1cml0eS5ic2QudW5wcml2aWxl Z2VkX2dldF9xdW90YTogMApjb21wYXQubGludXgub3NzX3ZlcnNpb246IDE5ODE0NApjb21wYXQu bGludXgub3NyZWxlYXNlOiAyLjYuMTYKY29tcGF0LmxpbnV4Lm9zbmFtZTogTGludXgKZGV2Lm5l eHVzLjAuJWRyaXZlcjogbmV4dXMKZGV2Lm5leHVzLjAuJXBhcmVudDogcm9vdDAKZGV2LnJhbS4w LiVkZXNjOiBTeXN0ZW0gUkFNCmRldi5yYW0uMC4lZHJpdmVyOiByYW0KZGV2LnJhbS4wLiVwYXJl bnQ6IG5leHVzMApkZXYubnB4LjAuJWRlc2M6IG1hdGggcHJvY2Vzc29yCmRldi5ucHguMC4lZHJp dmVyOiBucHgKZGV2Lm5weC4wLiVwYXJlbnQ6IG5leHVzMApkZXYuYWNwaS4wLiVkZXNjOiBBX01f SV8gT0VNUlNEVApkZXYuYWNwaS4wLiVkcml2ZXI6IGFjcGkKZGV2LmFjcGkuMC4lcGFyZW50OiBu ZXh1czAKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMC4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5h Y3BpX3N5c3Jlc291cmNlLjAuJWRyaXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNy ZXNvdXJjZS4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTUNIXwpkZXYuYWNwaV9zeXNy ZXNvdXJjZS4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMDEgX1VJRD0xMApkZXYuYWNwaV9zeXNyZXNv dXJjZS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJWRlc2M6IFN5c3Rl bSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVkcml2ZXI6IGFjcGlfc3lzcmVzb3Vy Y2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNC UkcuUk1TQwpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVwbnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJ RD0xNgpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jl c291cmNlLjIuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4yLiVk cml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMi4lbG9jYXRpb246 IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuT01TQwpkZXYuYWNwaV9zeXNyZXNvdXJjZS4yLiVwbnBp bmZvOiBfSElEPVBOUDBDMDIgX1VJRD0wCmRldi5hY3BpX3N5c3Jlc291cmNlLjIuJXBhcmVudDog YWNwaTAKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMy4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5h Y3BpX3N5c3Jlc291cmNlLjMuJWRyaXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNy ZXNvdXJjZS4zLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuUENJRQpkZXYuYWNwaV9zeXNy ZXNvdXJjZS4zLiVwbnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJRD0xNwpkZXYuYWNwaV9zeXNyZXNv dXJjZS4zLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjQuJWRlc2M6IFN5c3Rl bSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS40LiVkcml2ZXI6IGFjcGlfc3lzcmVzb3Vy Y2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuNC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5STUVNCmRl di5hY3BpX3N5c3Jlc291cmNlLjQuJXBucGluZm86IF9ISUQ9UE5QMEMwMSBfVUlEPTEKZGV2LmFj cGlfc3lzcmVzb3VyY2UuNC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV90aW1lci4wLiVkZXNjOiAy NC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHoKZGV2LmFjcGlfdGltZXIuMC4lZHJpdmVyOiBhY3Bp X3RpbWVyCmRldi5hY3BpX3RpbWVyLjAuJWxvY2F0aW9uOiB1bmtub3duCmRldi5hY3BpX3RpbWVy LjAuJXBucGluZm86IHVua25vd24KZGV2LmFjcGlfdGltZXIuMC4lcGFyZW50OiBhY3BpMApkZXYu YWNwaV9lYy4wLiVkZXNjOiBFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxYwpkZXYuYWNwaV9l Yy4wLiVkcml2ZXI6IGFjcGlfZWMKZGV2LmFjcGlfZWMuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NC Xy5QQ0kwLlNCUkcuRUMwXwpkZXYuYWNwaV9lYy4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMDkgX1VJ RD0wCmRldi5hY3BpX2VjLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjAuJWRlc2M6IEFD UEkgUENJIExpbmsgTE5LQQpkZXYucGNpX2xpbmsuMC4lZHJpdmVyOiBwY2lfbGluawpkZXYucGNp X2xpbmsuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktBCmRldi5wY2lfbGluay4wLiVwbnBp bmZvOiBfSElEPVBOUDBDMEYgX1VJRD0xCmRldi5wY2lfbGluay4wLiVwYXJlbnQ6IGFjcGkwCmRl di5wY2lfbGluay4xLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0IKZGV2LnBjaV9saW5rLjEuJWRy aXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5L QgpkZXYucGNpX2xpbmsuMS4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9MgpkZXYucGNpX2xp bmsuMS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMi4lZGVzYzogQUNQSSBQQ0kgTGluayBM TktDCmRldi5wY2lfbGluay4yLiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay4yLiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLkxOS0MKZGV2LnBjaV9saW5rLjIuJXBucGluZm86IF9ISUQ9UE5Q MEMwRiBfVUlEPTMKZGV2LnBjaV9saW5rLjIuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjMu JWRlc2M6IEFDUEkgUENJIExpbmsgTE5LRApkZXYucGNpX2xpbmsuMy4lZHJpdmVyOiBwY2lfbGlu awpkZXYucGNpX2xpbmsuMy4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktECmRldi5wY2lfbGlu ay4zLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD00CmRldi5wY2lfbGluay4zLiVwYXJlbnQ6 IGFjcGkwCmRldi5wY2lfbGluay40LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0UKZGV2LnBjaV9s aW5rLjQuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjQuJWxvY2F0aW9uOiBoYW5kbGU9 XF9TQl8uTE5LRQpkZXYucGNpX2xpbmsuNC4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9NQpk ZXYucGNpX2xpbmsuNC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuNS4lZGVzYzogQUNQSSBQ Q0kgTGluayBMTktGCmRldi5wY2lfbGluay41LiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGlu ay41LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0YKZGV2LnBjaV9saW5rLjUuJXBucGluZm86 IF9ISUQ9UE5QMEMwRiBfVUlEPTYKZGV2LnBjaV9saW5rLjUuJXBhcmVudDogYWNwaTAKZGV2LnBj aV9saW5rLjYuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LRwpkZXYucGNpX2xpbmsuNi4lZHJpdmVy OiBwY2lfbGluawpkZXYucGNpX2xpbmsuNi4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktHCmRl di5wY2lfbGluay42LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD03CmRldi5wY2lfbGluay42 LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay43LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0gK ZGV2LnBjaV9saW5rLjcuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjcuJWxvY2F0aW9u OiBoYW5kbGU9XF9TQl8uTE5LSApkZXYucGNpX2xpbmsuNy4lcG5waW5mbzogX0hJRD1QTlAwQzBG IF9VSUQ9OApkZXYucGNpX2xpbmsuNy4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9ocGV0LjAuJWRl c2M6IEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyCmRldi5hY3BpX2hwZXQuMC4lZHJpdmVyOiBh Y3BpX2hwZXQKZGV2LmFjcGlfaHBldC4wLiVsb2NhdGlvbjogdW5rbm93bgpkZXYuYWNwaV9ocGV0 LjAuJXBucGluZm86IHVua25vd24KZGV2LmFjcGlfaHBldC4wLiVwYXJlbnQ6IGFjcGkwCmRldi5w Y2liLjAuJWRlc2M6IEFDUEkgSG9zdC1QQ0kgYnJpZGdlCmRldi5wY2liLjAuJWRyaXZlcjogcGNp YgpkZXYucGNpYi4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAKZGV2LnBjaWIuMC4lcG5w aW5mbzogX0hJRD1QTlAwQTA4IF9VSUQ9MApkZXYucGNpYi4wLiVwYXJlbnQ6IGFjcGkwCmRldi5w Y2liLjEuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlkZ2UKZGV2LnBjaWIuMS4lZHJpdmVyOiBwY2li CmRldi5wY2liLjEuJWxvY2F0aW9uOiBzbG90PTI4IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBD STAuUDBQNApkZXYucGNpYi4xLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI3ZDAg c3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHg4MzBmIGNsYXNzPTB4MDYwNDAwCmRldi5wY2li LjEuJXBhcmVudDogcGNpMApkZXYucGNpYi4xLmRvbWFpbjogMApkZXYucGNpYi4xLnByaWJ1czog MApkZXYucGNpYi4xLnNlY2J1czogNApkZXYucGNpYi4xLnN1YmJ1czogNApkZXYucGNpYi4xLndh a2U6IDAKZGV2LnBjaWIuMi4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi4yLiVk cml2ZXI6IHBjaWIKZGV2LnBjaWIuMi4lbG9jYXRpb246IHNsb3Q9MjggZnVuY3Rpb249MSBoYW5k bGU9XF9TQl8uUENJMC5QMFA1CmRldi5wY2liLjIuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4MjdkMiBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgzMGYgY2xhc3M9MHgwNjA0 MDAKZGV2LnBjaWIuMi4lcGFyZW50OiBwY2kwCmRldi5wY2liLjIuZG9tYWluOiAwCmRldi5wY2li LjIucHJpYnVzOiAwCmRldi5wY2liLjIuc2VjYnVzOiAzCmRldi5wY2liLjIuc3ViYnVzOiAzCmRl di5wY2liLjIud2FrZTogMApkZXYucGNpYi4zLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRl di5wY2liLjMuJWRyaXZlcjogcGNpYgpkZXYucGNpYi4zLiVsb2NhdGlvbjogc2xvdD0yOCBmdW5j dGlvbj0zIGhhbmRsZT1cX1NCXy5QQ0kwLlAwUDcKZGV2LnBjaWIuMy4lcG5waW5mbzogdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHgyN2Q2IHN1YnZlbmRvcj0weDEwNDMgc3ViZGV2aWNlPTB4ODMwZiBj bGFzcz0weDA2MDQwMApkZXYucGNpYi4zLiVwYXJlbnQ6IHBjaTAKZGV2LnBjaWIuMy5kb21haW46 IDAKZGV2LnBjaWIuMy5wcmlidXM6IDAKZGV2LnBjaWIuMy5zZWNidXM6IDEKZGV2LnBjaWIuMy5z dWJidXM6IDIKZGV2LnBjaWIuMy53YWtlOiAwCmRldi5wY2liLjQuJWRlc2M6IEFDUEkgUENJLVBD SSBicmlkZ2UKZGV2LnBjaWIuNC4lZHJpdmVyOiBwY2liCmRldi5wY2liLjQuJWxvY2F0aW9uOiBz bG90PTMwIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuUDBQMQpkZXYucGNpYi40LiVwbnBp bmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI0NDggc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZp Y2U9MHg4MzBmIGNsYXNzPTB4MDYwNDAxCmRldi5wY2liLjQuJXBhcmVudDogcGNpMApkZXYucGNp Yi40LmRvbWFpbjogMApkZXYucGNpYi40LnByaWJ1czogMApkZXYucGNpYi40LnNlY2J1czogNQpk ZXYucGNpYi40LnN1YmJ1czogNQpkZXYucGNpYi40Lndha2U6IDAKZGV2LnBjaS4wLiVkZXNjOiBB Q1BJIFBDSSBidXMKZGV2LnBjaS4wLiVkcml2ZXI6IHBjaQpkZXYucGNpLjAuJXBhcmVudDogcGNp YjAKZGV2LnBjaS40LiVkZXNjOiBBQ1BJIFBDSSBidXMKZGV2LnBjaS40LiVkcml2ZXI6IHBjaQpk ZXYucGNpLjQuJXBhcmVudDogcGNpYjEKZGV2LnBjaS40Lndha2U6IDAKZGV2LnBjaS4zLiVkZXNj OiBBQ1BJIFBDSSBidXMKZGV2LnBjaS4zLiVkcml2ZXI6IHBjaQpkZXYucGNpLjMuJXBhcmVudDog cGNpYjIKZGV2LnBjaS4zLndha2U6IDAKZGV2LnBjaS4xLiVkZXNjOiBBQ1BJIFBDSSBidXMKZGV2 LnBjaS4xLiVkcml2ZXI6IHBjaQpkZXYucGNpLjEuJXBhcmVudDogcGNpYjMKZGV2LnBjaS4xLndh a2U6IDAKZGV2LnBjaS41LiVkZXNjOiBBQ1BJIFBDSSBidXMKZGV2LnBjaS41LiVkcml2ZXI6IHBj aQpkZXYucGNpLjUuJXBhcmVudDogcGNpYjQKZGV2LnBjaS41Lndha2U6IDAKZGV2Lmhvc3RiLjAu JWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYuaG9zdGIuMC4lZHJpdmVyOiBob3N0YgpkZXYu aG9zdGIuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0wCmRldi5ob3N0Yi4wLiVwbnBpbmZv OiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI3YWMgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9 MHg4MzQwIGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0Yi4wLiVwYXJlbnQ6IHBjaTAKZGV2LnZnYXBj aS4wLiVkZXNjOiBWR0EtY29tcGF0aWJsZSBkaXNwbGF5CmRldi52Z2FwY2kuMC4lZHJpdmVyOiB2 Z2FwY2kKZGV2LnZnYXBjaS4wLiVsb2NhdGlvbjogc2xvdD0yIGZ1bmN0aW9uPTAgaGFuZGxlPVxf U0JfLlBDSTAuVkdBXwpkZXYudmdhcGNpLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNl PTB4MjdhZSBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgzNDAgY2xhc3M9MHgwMzAwMDAK ZGV2LnZnYXBjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2LnZnYXBjaS4xLiVkZXNjOiBWR0EtY29tcGF0 aWJsZSBkaXNwbGF5CmRldi52Z2FwY2kuMS4lZHJpdmVyOiB2Z2FwY2kKZGV2LnZnYXBjaS4xLiVs b2NhdGlvbjogc2xvdD0yIGZ1bmN0aW9uPTEKZGV2LnZnYXBjaS4xLiVwbnBpbmZvOiB2ZW5kb3I9 MHg4MDg2IGRldmljZT0weDI3YTYgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHg4MzQwIGNs YXNzPTB4MDM4MDAwCmRldi52Z2FwY2kuMS4lcGFyZW50OiBwY2kwCmRldi5hZ3AuMC4lZGVzYzog SW50ZWwgOTQ1R01FIFNWR0EgY29udHJvbGxlcgpkZXYuYWdwLjAuJWRyaXZlcjogYWdwCmRldi5h Z3AuMC4lcGFyZW50OiB2Z2FwY2kwCmRldi5oZGFjLjAuJWRlc2M6IEludGVsIDgyODAxRyBIaWdo IERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcgpkZXYuaGRhYy4wLiVkcml2ZXI6IGhkYWMKZGV2 LmhkYWMuMC4lbG9jYXRpb246IHNsb3Q9MjcgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5I REFDCmRldi5oZGFjLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjdkOCBzdWJ2 ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgzNGEgY2xhc3M9MHgwNDAzMDAKZGV2LmhkYWMuMC4l cGFyZW50OiBwY2kwCmRldi5oZGFjLjAud2FrZTogMApkZXYuaGRhYy4wLnBvbGxpbmc6IDAKZGV2 LmhkYWMuMC5wb2xsaW5nX2ludGVydmFsOiAyNTAKZGV2LmhkYWMuMC5waW5kdW1wOiAwCmRldi5h bGUuMC4lZGVzYzogQXRoZXJvcyBBUjgxMjEvQVI4MTEzL0FSODExNCBQQ0llIEV0aGVybmV0CmRl di5hbGUuMC4lZHJpdmVyOiBhbGUKZGV2LmFsZS4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAKZGV2LmFsZS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxOTY5IGRldmljZT0weDEwMjYgc3VidmVu ZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHg4MzI0IGNsYXNzPTB4MDIwMDAwCmRldi5hbGUuMC4lcGFy ZW50OiBwY2kzCmRldi5hbGUuMC5pbnRfcnhfbW9kOiAzMApkZXYuYWxlLjAuaW50X3R4X21vZDog MTAwMApkZXYuYWxlLjAucHJvY2Vzc19saW1pdDogNjQKZGV2LmFsZS4wLnJlc2V0X2Jya19zZXE6 IDAKZGV2LmFsZS4wLnN0YXRzLnJ4Lmdvb2RfZnJhbWVzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5n b29kX2JjYXN0X2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMucnguZ29vZF9tY2FzdF9mcmFtZXM6 IDAKZGV2LmFsZS4wLnN0YXRzLnJ4LnBhdXNlX2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMucngu Y29udHJvbF9mcmFtZXM6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4LmNyY19lcnJzOiAwCmRldi5hbGUu MC5zdGF0cy5yeC5sZW5fZXJyczogMApkZXYuYWxlLjAuc3RhdHMucnguZ29vZF9vY3RldHM6IDAK ZGV2LmFsZS4wLnN0YXRzLnJ4Lmdvb2RfYmNhc3Rfb2N0ZXRzOiAwCmRldi5hbGUuMC5zdGF0cy5y eC5nb29kX21jYXN0X29jdGV0czogMApkZXYuYWxlLjAuc3RhdHMucngucnVudHM6IDAKZGV2LmFs ZS4wLnN0YXRzLnJ4LmZyYWdtZW50czogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhbWVzXzY0OiAw CmRldi5hbGUuMC5zdGF0cy5yeC5mcmFtZXNfNjVfMTI3OiAwCmRldi5hbGUuMC5zdGF0cy5yeC5m cmFtZXNfMTI4XzI1NTogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhbWVzXzI1Nl81MTE6IDAKZGV2 LmFsZS4wLnN0YXRzLnJ4LmZyYW1lc181MTJfMTAyMzogMApkZXYuYWxlLjAuc3RhdHMucnguZnJh bWVzXzEwMjRfMTUxODogMApkZXYuYWxlLjAuc3RhdHMucnguZnJhbWVzXzE1MTlfbWF4OiAwCmRl di5hbGUuMC5zdGF0cy5yeC50cnVuY19lcnJzOiAwCmRldi5hbGUuMC5zdGF0cy5yeC5maWZvX29m bG93czogMApkZXYuYWxlLjAuc3RhdHMucngucnJzX2VycnM6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4 LmFsaWduX2VycnM6IDAKZGV2LmFsZS4wLnN0YXRzLnJ4LmZpbHRlcmVkOiAwCmRldi5hbGUuMC5z dGF0cy50eC5nb29kX2ZyYW1lczogMApkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9iY2FzdF9mcmFt ZXM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4Lmdvb2RfbWNhc3RfZnJhbWVzOiAwCmRldi5hbGUuMC5z dGF0cy50eC5wYXVzZV9mcmFtZXM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmNvbnRyb2xfZnJhbWVz OiAwCmRldi5hbGUuMC5zdGF0cy50eC5leGNlc3NfZGVmZXJzOiAwCmRldi5hbGUuMC5zdGF0cy50 eC5kZWZlcnM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4Lmdvb2Rfb2N0ZXRzOiAwCmRldi5hbGUuMC5z dGF0cy50eC5nb29kX2JjYXN0X29jdGV0czogMApkZXYuYWxlLjAuc3RhdHMudHguZ29vZF9tY2Fz dF9vY3RldHM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1lc182NDogMApkZXYuYWxlLjAuc3Rh dHMudHguZnJhbWVzXzY1XzEyNzogMApkZXYuYWxlLjAuc3RhdHMudHguZnJhbWVzXzEyOF8yNTU6 IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1lc18yNTZfNTExOiAwCmRldi5hbGUuMC5zdGF0cy50 eC5mcmFtZXNfNTEyXzEwMjM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1lc18xMDI0XzE1MTg6 IDAKZGV2LmFsZS4wLnN0YXRzLnR4LmZyYW1lc18xNTE5X21heDogMApkZXYuYWxlLjAuc3RhdHMu dHguc2luZ2xlX2NvbGxzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5tdWx0aV9jb2xsczogMApkZXYu YWxlLjAuc3RhdHMudHgubGF0ZV9jb2xsczogMApkZXYuYWxlLjAuc3RhdHMudHguZXhjZXNzX2Nv bGxzOiAwCmRldi5hbGUuMC5zdGF0cy50eC5hYm9ydDogMApkZXYuYWxlLjAuc3RhdHMudHgudW5k ZXJydW5zOiAwCmRldi5hbGUuMC5zdGF0cy50eC5kZXNjX3VuZGVycnVuczogMApkZXYuYWxlLjAu c3RhdHMudHgubGVuX2VycnM6IDAKZGV2LmFsZS4wLnN0YXRzLnR4LnRydW5jX2VycnM6IDAKZGV2 Lm1paWJ1cy4wLiVkZXNjOiBNSUkgYnVzCmRldi5taWlidXMuMC4lZHJpdmVyOiBtaWlidXMKZGV2 Lm1paWJ1cy4wLiVwYXJlbnQ6IGFsZTAKZGV2LmF0cGh5LjAuJWRlc2M6IEF0aGVyb3MgRjEgMTAv MTAwLzEwMDAgUEhZCmRldi5hdHBoeS4wLiVkcml2ZXI6IGF0cGh5CmRldi5hdHBoeS4wLiVsb2Nh dGlvbjogcGh5bm89MApkZXYuYXRwaHkuMC4lcG5waW5mbzogb3VpPTB4MTM3NCBtb2RlbD0weDEg cmV2PTB4OQpkZXYuYXRwaHkuMC4lcGFyZW50OiBtaWlidXMwCmRldi5hdGguMC4lZGVzYzogQXRo ZXJvcyA5MjgwCmRldi5hdGguMC4lZHJpdmVyOiBhdGgKZGV2LmF0aC4wLiVsb2NhdGlvbjogc2xv dD0wIGZ1bmN0aW9uPTAKZGV2LmF0aC4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxNjhjIGRldmljZT0w eDAwMmEgc3VidmVuZG9yPTB4MWEzYiBzdWJkZXZpY2U9MHgxMDY3IGNsYXNzPTB4MDI4MDAwCmRl di5hdGguMC4lcGFyZW50OiBwY2kxCmRldi5hdGguMC5zbW9vdGhpbmdfcmF0ZTogOTUKZGV2LmF0 aC4wLnNhbXBsZV9yYXRlOiAxMApkZXYuYXRoLjAuc2FtcGxlX3N0YXRzOiAwCmRldi5hdGguMC5j b3VudHJ5Y29kZTogMApkZXYuYXRoLjAucmVnZG9tYWluOiA5NgpkZXYuYXRoLjAuc2xvdHRpbWU6 IDkKZGV2LmF0aC4wLmFja3RpbWVvdXQ6IDY0CmRldi5hdGguMC5jdHN0aW1lb3V0OiA0OApkZXYu YXRoLjAuc29mdGxlZDogMApkZXYuYXRoLjAubGVkcGluOiAwCmRldi5hdGguMC5sZWRvbjogMApk ZXYuYXRoLjAubGVkaWRsZTogMjcwMApkZXYuYXRoLjAudHhhbnRlbm5hOiAwCmRldi5hdGguMC5y eGFudGVubmE6IDEKZGV2LmF0aC4wLmRpdmVyc2l0eTogMQpkZXYuYXRoLjAudHhpbnRycGVyaW9k OiA1CmRldi5hdGguMC5kaWFnOiAwCmRldi5hdGguMC50cHNjYWxlOiAwCmRldi5hdGguMC50cGM6 IDAKZGV2LmF0aC4wLnRwYWNrOiA2MwpkZXYuYXRoLjAudHBjdHM6IDYzCmRldi5hdGguMC5pbnRt aXQ6IDAKZGV2LmF0aC4wLm1vbnBhc3M6IDI0CmRldi51aGNpLjAuJWRlc2M6IFVIQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyCmRldi51aGNpLjAuJWRyaXZlcjogdWhjaQpkZXYudWhjaS4wLiVs b2NhdGlvbjogc2xvdD0yOSBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlVTQjAKZGV2LnVo Y2kuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyN2M4IHN1YnZlbmRvcj0weDEw NDMgc3ViZGV2aWNlPTB4ODMwZiBjbGFzcz0weDBjMDMwMApkZXYudWhjaS4wLiVwYXJlbnQ6IHBj aTAKZGV2LnVoY2kuMS4lZGVzYzogVUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXIKZGV2LnVo Y2kuMS4lZHJpdmVyOiB1aGNpCmRldi51aGNpLjEuJWxvY2F0aW9uOiBzbG90PTI5IGZ1bmN0aW9u PTEgaGFuZGxlPVxfU0JfLlBDSTAuVVNCMQpkZXYudWhjaS4xLiVwbnBpbmZvOiB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDI3Yzkgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHg4MzBmIGNsYXNz PTB4MGMwMzAwCmRldi51aGNpLjEuJXBhcmVudDogcGNpMApkZXYudWhjaS4yLiVkZXNjOiBVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4yLiVkcml2ZXI6IHVoY2kKZGV2LnVo Y2kuMi4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5VU0Iy CmRldi51aGNpLjIuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjdjYSBzdWJ2ZW5k b3I9MHgxMDQzIHN1YmRldmljZT0weDgzMGYgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuMi4lcGFy ZW50OiBwY2kwCmRldi51aGNpLjMuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy CmRldi51aGNpLjMuJWRyaXZlcjogdWhjaQpkZXYudWhjaS4zLiVsb2NhdGlvbjogc2xvdD0yOSBm dW5jdGlvbj0zIGhhbmRsZT1cX1NCXy5QQ0kwLlVTQjMKZGV2LnVoY2kuMy4lcG5waW5mbzogdmVu ZG9yPTB4ODA4NiBkZXZpY2U9MHgyN2NiIHN1YnZlbmRvcj0weDEwNDMgc3ViZGV2aWNlPTB4ODMw ZiBjbGFzcz0weDBjMDMwMApkZXYudWhjaS4zLiVwYXJlbnQ6IHBjaTAKZGV2LnVzYnVzLjAuJWRl c2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyCmRldi51c2J1cy4wLiVkcml2ZXI6IHVz YnVzCmRldi51c2J1cy4wLiVwYXJlbnQ6IHVoY2kwCmRldi51c2J1cy4xLiVkZXNjOiBVSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudXNidXMuMS4lZHJpdmVyOiB1c2J1cwpkZXYudXNi dXMuMS4lcGFyZW50OiB1aGNpMQpkZXYudXNidXMuMi4lZGVzYzogVUhDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXIKZGV2LnVzYnVzLjIuJWRyaXZlcjogdXNidXMKZGV2LnVzYnVzLjIuJXBhcmVu dDogdWhjaTIKZGV2LnVzYnVzLjMuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy CmRldi51c2J1cy4zLiVkcml2ZXI6IHVzYnVzCmRldi51c2J1cy4zLiVwYXJlbnQ6IHVoY2kzCmRl di51c2J1cy40LiVkZXNjOiBJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxl cgpkZXYudXNidXMuNC4lZHJpdmVyOiB1c2J1cwpkZXYudXNidXMuNC4lcGFyZW50OiBlaGNpMApk ZXYuZWhjaS4wLiVkZXNjOiBJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxl cgpkZXYuZWhjaS4wLiVkcml2ZXI6IGVoY2kKZGV2LmVoY2kuMC4lbG9jYXRpb246IHNsb3Q9Mjkg ZnVuY3Rpb249NyBoYW5kbGU9XF9TQl8uUENJMC5FVVNCCmRldi5laGNpLjAuJXBucGluZm86IHZl bmRvcj0weDgwODYgZGV2aWNlPTB4MjdjYyBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weDgz MGYgY2xhc3M9MHgwYzAzMjAKZGV2LmVoY2kuMC4lcGFyZW50OiBwY2kwCmRldi5pc2FiLjAuJWRl c2M6IFBDSS1JU0EgYnJpZGdlCmRldi5pc2FiLjAuJWRyaXZlcjogaXNhYgpkZXYuaXNhYi4wLiVs b2NhdGlvbjogc2xvdD0zMSBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcKZGV2Lmlz YWIuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyN2I5IHN1YnZlbmRvcj0weDEw NDMgc3ViZGV2aWNlPTB4ODMwZiBjbGFzcz0weDA2MDEwMApkZXYuaXNhYi4wLiVwYXJlbnQ6IHBj aTAKZGV2LmlzYS4wLiVkZXNjOiBJU0EgYnVzCmRldi5pc2EuMC4lZHJpdmVyOiBpc2EKZGV2Lmlz YS4wLiVwYXJlbnQ6IGlzYWIwCmRldi5hdGFwY2kuMC4lZGVzYzogSW50ZWwgSUNIN00gU0FUQTMw MCBjb250cm9sbGVyCmRldi5hdGFwY2kuMC4lZHJpdmVyOiBhdGFwY2kKZGV2LmF0YXBjaS4wLiVs b2NhdGlvbjogc2xvdD0zMSBmdW5jdGlvbj0yIGhhbmRsZT1cX1NCXy5QQ0kwLklERTAKZGV2LmF0 YXBjaS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI3YzQgc3VidmVuZG9yPTB4 MTA0MyBzdWJkZXZpY2U9MHg4MzBmIGNsYXNzPTB4MDEwMTgwCmRldi5hdGFwY2kuMC4lcGFyZW50 OiBwY2kwCmRldi5hdGEuMC4lZGVzYzogQVRBIGNoYW5uZWwgMApkZXYuYXRhLjAuJWRyaXZlcjog YXRhCmRldi5hdGEuMC4lcGFyZW50OiBhdGFwY2kwCmRldi5hdGEuMS4lZGVzYzogQVRBIGNoYW5u ZWwgMQpkZXYuYXRhLjEuJWRyaXZlcjogYXRhCmRldi5hdGEuMS4lcGFyZW50OiBhdGFwY2kwCmRl di5hY3BpX2FzdXMuMC4lZGVzYzogQVNVUyBFZWVQQwpkZXYuYWNwaV9hc3VzLjAuJWRyaXZlcjog YWNwaV9hc3VzCmRldi5hY3BpX2FzdXMuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5BVEtECmRl di5hY3BpX2FzdXMuMC4lcG5waW5mbzogX0hJRD1BU1VTMDEwIF9VSUQ9MTY4NDMwMDgKZGV2LmFj cGlfYXN1cy4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX2xpZC4wLiVkZXNjOiBDb250cm9sIE1l dGhvZCBMaWQgU3dpdGNoCmRldi5hY3BpX2xpZC4wLiVkcml2ZXI6IGFjcGlfbGlkCmRldi5hY3Bp X2xpZC4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxJRF8KZGV2LmFjcGlfbGlkLjAuJXBucGlu Zm86IF9ISUQ9UE5QMEMwRCBfVUlEPTAKZGV2LmFjcGlfbGlkLjAuJXBhcmVudDogYWNwaTAKZGV2 LmFjcGlfYnV0dG9uLjAuJWRlc2M6IFNsZWVwIEJ1dHRvbgpkZXYuYWNwaV9idXR0b24uMC4lZHJp dmVyOiBhY3BpX2J1dHRvbgpkZXYuYWNwaV9idXR0b24uMC4lbG9jYXRpb246IGhhbmRsZT1cX1NC Xy5TTFBCCmRldi5hY3BpX2J1dHRvbi4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMEUgX1VJRD0wCmRl di5hY3BpX2J1dHRvbi4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX2J1dHRvbi4xLiVkZXNjOiBQ b3dlciBCdXR0b24KZGV2LmFjcGlfYnV0dG9uLjEuJWRyaXZlcjogYWNwaV9idXR0b24KZGV2LmFj cGlfYnV0dG9uLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUFdSQgpkZXYuYWNwaV9idXR0b24u MS4lcG5waW5mbzogX0hJRD1QTlAwQzBDIF9VSUQ9MTcwCmRldi5hY3BpX2J1dHRvbi4xLiVwYXJl bnQ6IGFjcGkwCmRldi5hY3BpX3R6LjAuJWRlc2M6IFRoZXJtYWwgWm9uZQpkZXYuYWNwaV90ei4w LiVkcml2ZXI6IGFjcGlfdHoKZGV2LmFjcGlfdHouMC4lbG9jYXRpb246IGhhbmRsZT1cX1RaXy5U WjAwCmRldi5hY3BpX3R6LjAuJXBucGluZm86IF9ISUQ9bm9uZSBfVUlEPTAKZGV2LmFjcGlfdHou MC4lcGFyZW50OiBhY3BpMApkZXYuYmF0dGVyeS4wLiVkZXNjOiBBQ1BJIENvbnRyb2wgTWV0aG9k IEJhdHRlcnkKZGV2LmJhdHRlcnkuMC4lZHJpdmVyOiBiYXR0ZXJ5CmRldi5iYXR0ZXJ5LjAuJWxv Y2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5CQVQwCmRldi5iYXR0ZXJ5LjAuJXBucGluZm86IF9I SUQ9UE5QMEMwQSBfVUlEPTAKZGV2LmJhdHRlcnkuMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9h Y2FkLjAuJWRlc2M6IEFDIEFkYXB0ZXIKZGV2LmFjcGlfYWNhZC4wLiVkcml2ZXI6IGFjcGlfYWNh ZApkZXYuYWNwaV9hY2FkLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5BQzBfCmRldi5h Y3BpX2FjYWQuMC4lcG5waW5mbzogX0hJRD1BQ1BJMDAwMyBfVUlEPTAKZGV2LmFjcGlfYWNhZC4w LiVwYXJlbnQ6IGFjcGkwCmRldi5hdHBpYy4wLiVkZXNjOiBBVCBpbnRlcnJ1cHQgY29udHJvbGxl cgpkZXYuYXRwaWMuMC4lZHJpdmVyOiBhdHBpYwpkZXYuYXRwaWMuMC4lbG9jYXRpb246IGhhbmRs ZT1cX1NCXy5QQ0kwLlNCUkcuUElDXwpkZXYuYXRwaWMuMC4lcG5waW5mbzogX0hJRD1QTlAwMDAw IF9VSUQ9MApkZXYuYXRwaWMuMC4lcGFyZW50OiBhY3BpMApkZXYuYXRkbWEuMC4lZGVzYzogQVQg RE1BIGNvbnRyb2xsZXIKZGV2LmF0ZG1hLjAuJWRyaXZlcjogYXRkbWEKZGV2LmF0ZG1hLjAuJWxv Y2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLkRNQUQKZGV2LmF0ZG1hLjAuJXBucGluZm86 IF9ISUQ9UE5QMDIwMCBfVUlEPTAKZGV2LmF0ZG1hLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0dGlt ZXIuMC4lZGVzYzogQVQgdGltZXIKZGV2LmF0dGltZXIuMC4lZHJpdmVyOiBhdHRpbWVyCmRldi5h dHRpbWVyLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLlRNUl8KZGV2LmF0dGlt ZXIuMC4lcG5waW5mbzogX0hJRD1QTlAwMTAwIF9VSUQ9MApkZXYuYXR0aW1lci4wLiVwYXJlbnQ6 IGFjcGkwCmRldi5hdHJ0Yy4wLiVkZXNjOiBBVCByZWFsdGltZSBjbG9jawpkZXYuYXRydGMuMC4l ZHJpdmVyOiBhdHJ0YwpkZXYuYXRydGMuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNC UkcuUlRDMApkZXYuYXRydGMuMC4lcG5waW5mbzogX0hJRD1QTlAwQjAwIF9VSUQ9MApkZXYuYXRy dGMuMC4lcGFyZW50OiBhY3BpMApkZXYuYXRrYmRjLjAuJWRlc2M6IEtleWJvYXJkIGNvbnRyb2xs ZXIgKGk4MDQyKQpkZXYuYXRrYmRjLjAuJWRyaXZlcjogYXRrYmRjCmRldi5hdGtiZGMuMC4lbG9j YXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuUFMySwpkZXYuYXRrYmRjLjAuJXBucGluZm86 IF9ISUQ9UE5QMDMwMyBfVUlEPTAKZGV2LmF0a2JkYy4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hdGti ZC4wLiVkZXNjOiBBVCBLZXlib2FyZApkZXYuYXRrYmQuMC4lZHJpdmVyOiBhdGtiZApkZXYuYXRr YmQuMC4lcGFyZW50OiBhdGtiZGMwCmRldi5wc21jcG5wLjAuJWRlc2M6IFBTLzIgbW91c2UgcG9y dApkZXYucHNtY3BucC4wLiVkcml2ZXI6IHBzbWNwbnAKZGV2LnBzbWNwbnAuMC4lbG9jYXRpb246 IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuUFMyTQpkZXYucHNtY3BucC4wLiVwbnBpbmZvOiBfSElE PVNZTjBBMDQgX1VJRD0wCmRldi5wc21jcG5wLjAuJXBhcmVudDogYWNwaTAKZGV2LnBzbS4wLiVk ZXNjOiBQUy8yIE1vdXNlCmRldi5wc20uMC4lZHJpdmVyOiBwc20KZGV2LnBzbS4wLiVwYXJlbnQ6 IGF0a2JkYzAKZGV2Lm5weGlzYS4wLiVkZXNjOiBMZWdhY3kgSVNBIGNvcHJvY2Vzc29yIHN1cHBv cnQKZGV2Lm5weGlzYS4wLiVkcml2ZXI6IG5weGlzYQpkZXYubnB4aXNhLjAuJWxvY2F0aW9uOiBo YW5kbGU9XF9TQl8uUENJMC5TQlJHLkNPUFIKZGV2Lm5weGlzYS4wLiVwbnBpbmZvOiBfSElEPVBO UDBDMDQgX1VJRD0wCmRldi5ucHhpc2EuMC4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjAuJWRlc2M6 IEFDUEkgQ1BVCmRldi5jcHUuMC4lZHJpdmVyOiBjcHUKZGV2LmNwdS4wLiVsb2NhdGlvbjogaGFu ZGxlPVxfUFJfLlAwMDEKZGV2LmNwdS4wLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5j cHUuMC4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjAuZnJlcTogMTY2NwpkZXYuY3B1LjAuZnJlcV9s ZXZlbHM6IDE2NjcvMzUwMDAgMTQ1OC8zMDYyNSAxMzMzLzI1MDAwIDExNjYvMjE4NzUgMTAwMC8x NjAwMCA4NzUvMTQwMDAgNzUwLzEyMDAwIDYyNS8xMDAwMCA1MDAvODAwMCAzNzUvNjAwMCAyNTAv NDAwMCAxMjUvMjAwMApkZXYuY3B1LjAuY3hfc3VwcG9ydGVkOiBDMS8wCmRldi5jcHUuMC5jeF9s b3dlc3Q6IEMxCmRldi5jcHUuMC5jeF91c2FnZTogMTAwLjAwJQpkZXYuY3B1LjEuJWRlc2M6IEFD UEkgQ1BVCmRldi5jcHUuMS4lZHJpdmVyOiBjcHUKZGV2LmNwdS4xLiVsb2NhdGlvbjogaGFuZGxl PVxfUFJfLkNQVTEKZGV2LmNwdS4xLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5jcHUu MS4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjEuY3hfc3VwcG9ydGVkOiBDMS8wCmRldi5jcHUuMS5j eF9sb3dlc3Q6IEMxCmRldi5jcHUuMS5jeF91c2FnZTogMTAwLjAwJQpkZXYuYWNwaV9wZXJmLjAu JWRyaXZlcjogYWNwaV9wZXJmCmRldi5hY3BpX3BlcmYuMC4lcGFyZW50OiBjcHUwCmRldi5lc3Qu MC4lZGVzYzogRW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sCmRldi5lc3QuMC4l ZHJpdmVyOiBlc3QKZGV2LmVzdC4wLiVwYXJlbnQ6IGNwdTAKZGV2LmVzdC4wLmZyZXFfc2V0dGlu Z3M6IDE2NjcvMzUwMDAgMTMzMy8yNTAwMCAxMDAwLzE2MDAwCmRldi5jcHVmcmVxLjAuJWRyaXZl cjogY3B1ZnJlcQpkZXYuY3B1ZnJlcS4wLiVwYXJlbnQ6IGNwdTAKZGV2LmNwdWZyZXEuMS4lZHJp dmVyOiBjcHVmcmVxCmRldi5jcHVmcmVxLjEuJXBhcmVudDogY3B1MQpkZXYucDR0Y2MuMC4lZGVz YzogQ1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2wKZGV2LnA0dGNjLjAuJWRyaXZlcjogcDR0 Y2MKZGV2LnA0dGNjLjAuJXBhcmVudDogY3B1MApkZXYucDR0Y2MuMC5mcmVxX3NldHRpbmdzOiAx MDAwMC8tMSA4NzUwLy0xIDc1MDAvLTEgNjI1MC8tMSA1MDAwLy0xIDM3NTAvLTEgMjUwMC8tMSAx MjUwLy0xCmRldi5wNHRjYy4xLiVkZXNjOiBDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbApk ZXYucDR0Y2MuMS4lZHJpdmVyOiBwNHRjYwpkZXYucDR0Y2MuMS4lcGFyZW50OiBjcHUxCmRldi5w NHRjYy4xLmZyZXFfc2V0dGluZ3M6IDEwMDAwLy0xIDg3NTAvLTEgNzUwMC8tMSA2MjUwLy0xIDUw MDAvLTEgMzc1MC8tMSAyNTAwLy0xIDEyNTAvLTEKZGV2LmFwaWMuMC4lZGVzYzogQVBJQyByZXNv dXJjZXMKZGV2LmFwaWMuMC4lZHJpdmVyOiBhcGljCmRldi5hcGljLjAuJXBhcmVudDogbmV4dXMw CmRldi5wbXRpbWVyLjAuJWRyaXZlcjogcG10aW1lcgpkZXYucG10aW1lci4wLiVwYXJlbnQ6IGlz YTAKZGV2LnNjLjAuJWRlc2M6IFN5c3RlbSBjb25zb2xlCmRldi5zYy4wLiVkcml2ZXI6IHNjCmRl di5zYy4wLiVwYXJlbnQ6IGlzYTAKZGV2LnZnYS4wLiVkZXNjOiBHZW5lcmljIElTQSBWR0EKZGV2 LnZnYS4wLiVkcml2ZXI6IHZnYQpkZXYudmdhLjAuJXBhcmVudDogaXNhMApkZXYuYWQuMC4lZGVz YzogU1Q5MTYwMzEwQVMvMDMwMwpkZXYuYWQuMC4lZHJpdmVyOiBhZApkZXYuYWQuMC4lcGFyZW50 OiBhdGEwCmRldi5wY20uMC4lZGVzYzogSERBIFJlYWx0ZWsgQUxDMjY5IFBDTSAjMCBBbmFsb2cK ZGV2LnBjbS4wLiVkcml2ZXI6IHBjbQpkZXYucGNtLjAuJXBhcmVudDogaGRhYzAKZGV2LnBjbS4w LnBsYXkudmNoYW5zOiAxCmRldi5wY20uMC5wbGF5LnZjaGFucmF0ZTogNDgwMDAKZGV2LnBjbS4w LnBsYXkudmNoYW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMC5yZWMudmNoYW5zOiAxCmRldi5wY20u MC5yZWMudmNoYW5yYXRlOiA0ODAwMApkZXYucGNtLjAucmVjLnZjaGFuZm9ybWF0OiBzMTZsZQpk ZXYucGNtLjAuYnVmZmVyc2l6ZTogMTYzODQKZGV2LnBjbS4xLiVkZXNjOiBIREEgUmVhbHRlayBB TEMyNjkgUENNICMxIEFuYWxvZwpkZXYucGNtLjEuJWRyaXZlcjogcGNtCmRldi5wY20uMS4lcGFy ZW50OiBoZGFjMApkZXYucGNtLjEucmVjLnZjaGFuczogMQpkZXYucGNtLjEucmVjLnZjaGFucmF0 ZTogNDgwMDAKZGV2LnBjbS4xLnJlYy52Y2hhbmZvcm1hdDogczE2bGUKZGV2LnBjbS4xLmJ1ZmZl cnNpemU6IDE2Mzg0CmRldi51aHViLjAuJWRlc2M6IEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjAuJWRyaXZlcjogdWh1YgpkZXYu dWh1Yi4wLiVwYXJlbnQ6IHVzYnVzMApkZXYudWh1Yi4xLiVkZXNjOiBJbnRlbCBVSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4xLiVkcml2ZXI6 IHVodWIKZGV2LnVodWIuMS4lcGFyZW50OiB1c2J1czEKZGV2LnVodWIuMi4lZGVzYzogSW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKZGV2LnVodWIu Mi4lZHJpdmVyOiB1aHViCmRldi51aHViLjIuJXBhcmVudDogdXNidXMyCmRldi51aHViLjMuJWRl c2M6IEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CmRldi51aHViLjMuJWRyaXZlcjogdWh1YgpkZXYudWh1Yi4zLiVwYXJlbnQ6IHVzYnVzMwpkZXYu dWh1Yi40LiVkZXNjOiBJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEu MDAsIGFkZHIgMQpkZXYudWh1Yi40LiVkcml2ZXI6IHVodWIKZGV2LnVodWIuNC4lcGFyZW50OiB1 c2J1czQKZGV2LmRybS4wLiVkZXNjOiBJbnRlbCBpOTQ1R01FCmRldi5kcm0uMC4lZHJpdmVyOiBk cm0KZGV2LmRybS4wLiVwYXJlbnQ6IHZnYXBjaTAK --001636416b432bb5b30465cd55fe-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 20:13:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67BD1065676 for ; Mon, 23 Mar 2009 20:13:28 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6CBC68FC15 for ; Mon, 23 Mar 2009 20:13:28 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 6DF3123C4B3; Mon, 23 Mar 2009 21:13:27 +0100 (CET) Date: Mon, 23 Mar 2009 21:13:27 +0100 From: Peter Schuller To: freebsd-current@freebsd.org Message-ID: <20090323201326.GA78971@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: xorg on current: mouse "strangeness" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 20:13:29 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, since upping my kernel/userland from late 2008 to 2009-03-18, the mouse has been behaving very strangely in X. On the original upgrade I did not touch my ports; after re-building and installing all ports today on the new userland, the problem remains. In firefox, thunderbird and opera scrolling is broken. Pressing the button and trying to drag the scroll bar results in it jumping around a bit, and bogus mouse clicks happening on surrounding controls. In thunderbird, just clicking a message in a list or a folder in the folder list, results in the entry a few items above being selected as if the position of the mouse click were off. In urxvt, left-clicking causes the termianl to scroll up a few lines. After running Xorg -configure to get a clean and fresh configuration generated by the up-to-date xorg, the problem remains. Using Xorg with and without hald does not matter; same problem ensues. The mouse is connected through USB, and I figure the recent USB changes may be related. Does anyone have suggestions? I haven't seen anything mentioned on the lists. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknH7WYACgkQDNor2+l1i33eIwCg6t9l2tgI/75h8yjT8OFHUhkF QlgAniWg58As45X2ZYLMDln08N+QrvPh =SZ/M -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 20:21:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D98106564A for ; Mon, 23 Mar 2009 20:21:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 019D98FC20 for ; Mon, 23 Mar 2009 20:21:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n2NKLXTi043382; Mon, 23 Mar 2009 13:21:33 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n2NKLXKt043381; Mon, 23 Mar 2009 13:21:33 -0700 (PDT) (envelope-from sgk) Date: Mon, 23 Mar 2009 13:21:33 -0700 From: Steve Kargl To: Peter Schuller Message-ID: <20090323202133.GA43361@troutmask.apl.washington.edu> References: <20090323201326.GA78971@hyperion.scode.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090323201326.GA78971@hyperion.scode.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: xorg on current: mouse "strangeness" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 20:21:33 -0000 On Mon, Mar 23, 2009 at 09:13:27PM +0100, Peter Schuller wrote: > > The mouse is connected through USB, and I figure the recent USB > changes may be related. Does anyone have suggestions? I haven't seen > anything mentioned on the lists. > > Does the information about USB mice and Xorg in /usr/src/UPDATING fix your problem? -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 21:16:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69AC106568D; Mon, 23 Mar 2009 21:16:46 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id CF5558FC1F; Mon, 23 Mar 2009 21:16:45 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so1587784ewy.43 for ; Mon, 23 Mar 2009 14:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ipuz0Isx4uQ63xA4P4/Pgkwlxsb+DYBw0Hb7ihEKf3Y=; b=eRtxncirQCEwI/KYswpyIrBZG0+4hdsa5dB0Bqy+SC1eiqbtmN9B/J0892/aHjmvvS RcstTeTCRlxvob12eoAQcu1PXKt1YFqBowwiVUnCHv4pT7Di/9FM3U4cA9EitZzBt8AX NtR54M2YQ+QhOK7LZD5CPdPWaKMwW6WRVrPKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lCjLosxSEY6a9lw7FOcjTqj+16rmSLpSAH7BUlnGhwFpmTTWvsprrWeRPPf37UR5YG sNPQvFchmi7it1mAPrMy3T88VZGYLXuX6in+l8u2DTIL7Hx7OWoS3SsQJl8aIBt2G3vx 68E1r/8gSdTTd/Y7ehmle7evbNNHu0L0PoHr4= MIME-Version: 1.0 Received: by 10.210.46.14 with SMTP id t14mr5724052ebt.57.1237843004600; Mon, 23 Mar 2009 14:16:44 -0700 (PDT) In-Reply-To: <200903162053.28614.jkim@FreeBSD.org> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> Date: Mon, 23 Mar 2009 16:16:44 -0500 Message-ID: <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> From: Brandon Gooch To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:16:50 -0000 On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: > On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >> Jung-uk Kim wrote: >> > With popular demands, I will commit the following patch in next >> > few days unless a showstopper is found or "over-my-dead-body" >> > type of review is received. ;-) >> > >> > http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >> > >> > FYI, it was originally posted here: >> > >> > http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >> > >> > and here: >> > >> > http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >> > >> > Please read the original threads for more information about the >> > patch. >> >> Have just retested this with just updated 8-CURRENT. Still works >> fine as before with my Acer TM6292 >> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >> letter just after successful resume. >> >> There is still some DRI resume problems (will try one rnoland@ >> patch tomorrow) and my touch pad does not wakes up for some reason, >> but that is probably unrelated. > > I went ahead and committed slightly different version. =A0Please resync > the source if you tested the old version. > > Cheers, > > Jung-uk Kim > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > The committed version is working well, I am suspending and resuming on my Lenovo X300. Thanks for your work on this, it is one of the major things I needed to work so I could run FreeBSD primarily on my notebook. Is there some way to keep the OS date and time in updated (after resume), or am I missing something in my system configuration? Thanks again for this! Very Cool... -Brandon From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 21:24:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C2B106568E for ; Mon, 23 Mar 2009 21:24:26 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 36D3E8FC1C for ; Mon, 23 Mar 2009 21:24:25 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.149.198] (port=34189 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LlrdA-0006WU-Mn for freebsd-current@freebsd.org; Tue, 24 Mar 2009 00:24:24 +0300 Message-ID: <49C7FE13.90808@lissyara.su> Date: Tue, 24 Mar 2009 00:24:35 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:24:26 -0000 I have USB floppy. Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device descriptor at addr 3 failed! Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 Mar 24 00:11:26 HP kernel: umass0: on usbus0 Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Mar 24 00:11:27 HP kernel: umass0:2:0:-1: Attached to scbus2 Mar 24 00:11:27 HP kernel: xptioctl: pass driver is not in the kernel Mar 24 00:11:27 HP kernel: xptioctl: put "device pass" in your kernel config file but, HP$ grep "pass" /usr/src/sys/amd64/conf/GENERIC device pass # Passthrough device (direct SCSI access) device aacp # SCSI passthrough for aac (requires CAM) HP$ If I unplug and plug it to the same port: Mar 24 00:19:12 HP kernel: usb2_alloc_device:1516: getting device descriptor at addr 3 failed! Mar 24 00:19:12 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 24 00:19:14 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 24 00:19:14 HP kernel: ugen0.3: <> at usbus0 (disconnected) Mar 24 00:19:14 HP kernel: uhub_reattach_port:413: could not allocate new device! If I plug it to another port - it detect, but need "pass" driver =) ============ I have USB mouse. If I plug it first time - all OK. If second - to the some port: Mar 24 00:21:45 HP kernel: ugen0.3: at usbus0 Mar 24 00:21:45 HP kernel: ums0: on usbus0 Mar 24 00:21:45 HP kernel: ums0: error reading report description Mar 24 00:21:45 HP kernel: device_attach: ums0 attach returned 12 ======== HP$ uname -a FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 23 22:45:17 MSK 2009 lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 HP$ From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 21:29:04 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 12010106566C; Mon, 23 Mar 2009 21:29:02 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 23 Mar 2009 17:28:39 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> In-Reply-To: <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200903231728.46911.jkim@FreeBSD.org> Cc: Brandon Gooch , freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:29:04 -0000 On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > The committed version is working well, I am suspending and resuming > on my Lenovo X300. Thanks for your work on this, it is one of the > major things I needed to work so I could run FreeBSD primarily on > my notebook. Great. > Is there some way to keep the OS date and time in updated (after > resume), or am I missing something in my system configuration? In fact, I am working on it and I will commit the fix very soon. ;-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 21:39:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39A71065679 for ; Mon, 23 Mar 2009 21:39:11 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 877888FC15 for ; Mon, 23 Mar 2009 21:39:11 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 951FC7E818 for ; Mon, 23 Mar 2009 13:23:48 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Mon, 23 Mar 2009 22:23:47 +0100 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903232223.47295.mel.flynn+fbsd.current@mailing.thruhere.net> Subject: Panic in wpi, hard to reproduce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:39:12 -0000 Hi, I've been bit twice now by a panic in wpi(4). It's hard to reproduce but the panics are consistent, meaning the two panics are identical. I'm not using wpi at the moment, but may again in the relative near future. At the time of the crashes the card was used as wireless g connection to an FreeBSD hostap using ral(4), via WEP. % ident /boot/kernel/if_wpi.ko /boot/kernel/if_wpi.ko: $FreeBSD: src/sys/dev/wpi/if_wpi.c,v 1.19 2009/02/13 16:17:05 sam Exp $ Script started on Sat Mar 7 10:55:59 2009 # kgdb /boot/kernel/kernel /var/crash/vmcore.0 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x7d1667b8 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0688be1 stack pointer = 0x28:0xc4aabba0 frame pointer = 0x28:0xc4aabbb4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq16: vgapci0+++) trap number = 12 panic: page fault cpuid = 0 Uptime: 1d16h11m34s Physical memory: 1517 MB Dumping 287 MB: 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/smb.ko...Reading symbols from /boot/kernel/smb.ko.symbols...done. done. Loaded symbols for /boot/kernel/smb.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from /boot/kernel/blank_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/blank_saver.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0637bdc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc0637ea9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc08633cc in trap_fatal (frame=0xc4aabb60, eva=2098620344) at /usr/src/sys/i386/i386/trap.c:929 #4 0xc0863630 in trap_pfault (frame=0xc4aabb60, usermode=0, eva=2098620344) at /usr/src/sys/i386/i386/trap.c:842 #5 0xc0863fb2 in trap (frame=0xc4aabb60) at /usr/src/sys/i386/i386/trap.c:522 #6 0xc084932b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc0688be1 in mb_free_ext (m=0xc925d300) at /usr/src/sys/kern/uipc_mbuf.c:228 #8 0xc0689381 in m_freem (mb=0x0) at mbuf.h:524 #9 0xc083d981 in wpi_intr (arg=0xc4e2c800) at /usr/src/sys/dev/wpi/if_wpi.c:1589 #10 0xc061688b in intr_event_execute_handlers (p=0xc4d2e7ec, ie=0xc4d70380) at /usr/src/sys/kern/kern_intr.c:1134 #11 0xc0617cab in ithread_loop (arg=0xc4eda680) at /usr/src/sys/kern/kern_intr.c:1147 #12 0xc06145e3 in fork_exit (callout=0xc0617c40 , arg=0xc4eda680, frame=0xc4aabd38) at /usr/src/sys/kern/kern_fork.c:821 #13 0xc08493a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) frame 7 #7 0xc0688be1 in mb_free_ext (m=0xc925d300) at /usr/src/sys/kern/uipc_mbuf.c:228 228 if (*(m->m_ext.ref_cnt) == 1 || (kgdb) print m->M_dat.MH.MH_dat.MH_ext $1 = {ext_buf = 0x6ddc9134
, ext_free = 0x6e378c2e, ext_arg1 = 0xc25a829, ext_arg2 = 0x6070e28f, ext_size = 2799295368, ref_cnt = 0x7d1667b8, ext_type = 908986233} (kgdb) print *(m->M_dat.MH.MH_dat.MH_ext.ref_cnt) Cannot access memory at address 0x7d1667b8 (kgdb) frame 9 #9 0xc083d981 in wpi_intr (arg=0xc4e2c800) at /usr/src/sys/dev/wpi/if_wpi.c:1589 1589 m_freem(txdata->m); (kgdb) list 1584 ifp->if_opackets++; 1585 1586 bus_dmamap_sync(ring->data_dmat, txdata->map, BUS_DMASYNC_POSTWRITE); 1587 bus_dmamap_unload(ring->data_dmat, txdata->map); 1588 /* XXX handle M_TXCB? */ 1589 m_freem(txdata->m); 1590 txdata->m = NULL; 1591 ieee80211_free_node(txdata->ni); 1592 txdata->ni = NULL; 1593 -- Mel From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 21:41:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8621106567A for ; Mon, 23 Mar 2009 21:41:26 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFA68FC33 for ; Mon, 23 Mar 2009 21:41:26 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 76F9223C4D1; Mon, 23 Mar 2009 22:41:25 +0100 (CET) Date: Mon, 23 Mar 2009 22:41:25 +0100 From: Peter Schuller To: Steve Kargl Message-ID: <20090323214125.GA82327@hyperion.scode.org> References: <20090323201326.GA78971@hyperion.scode.org> <20090323202133.GA43361@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20090323202133.GA43361@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: xorg on current: mouse "strangeness" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:41:27 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > The mouse is connected through USB, and I figure the recent USB > > changes may be related. Does anyone have suggestions? I haven't seen > > anything mentioned on the lists. > >=20 > >=20 >=20 > Does the information about USB mice and Xorg in /usr/src/UPDATING > fix your problem? I assume you are referring to: 20090216: xorg 7.4 wants to configure its input devices via hald which does n= ot yet work with USB2. If the keyboard/mouse does not work in xorg then add Option "AllowEmptyInput" "off" to your ServerLayout section. This will cause X to use the configu= red kbd and mouse sections from your xorg.conf. When I tried without hald, that meant hald disabled, moused running and the above option in xorg.conf. It did not work. However, contrary to my interpretation of the above, running *with* hald and with moused disabled works equally "well" (but the problem remains). Running with the above option, moused enabled *and* hald enabled, yields the same effect. Just to be sure I took the freshly generated (Xorg -configure) conf, plus the above AllowEmptyInput option, did a fresh reboot of the system and started x - the problem remains. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknIAgQACgkQDNor2+l1i304cQCgkk4rVPU3hBC8W++r3xs1weJV PmoAnRbkLRkQ4CfYvhsCmpPfgqq8oFjZ =hbSQ -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 22:08:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81DBF106566B for ; Mon, 23 Mar 2009 22:08:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 528FD8FC1A for ; Mon, 23 Mar 2009 22:08:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id C2C1D46B58; Mon, 23 Mar 2009 18:08:08 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2NM82Yg056437; Mon, 23 Mar 2009 18:08:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Mar 2009 16:08:59 -0400 User-Agent: KMail/1.9.7 References: <200903231158.28121.jhb@freebsd.org> In-Reply-To: <200903231158.28121.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903231609.00039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Mar 2009 18:08:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 13:26:16 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mars G Miro , pyunyh@gmail.com Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 22:08:09 -0000 On Monday 23 March 2009 11:58:27 am John Baldwin wrote: > On Friday 20 March 2009 11:08:35 pm Mars G Miro wrote: > > On Sat, Mar 21, 2009 at 12:42 AM, John Baldwin wrote: > > > On Thursday 19 March 2009 11:24:24 pm Mars G Miro wrote: > > >> On Thu, Mar 19, 2009 at 11:26 PM, John Baldwin wro= te: > > >> > What if you set 'hw.pci.mcfg=3D0' in loader? > > >> > > > >> > > >> That did it! Even w/ ACPI enabled in the BIOS, the sk/msk NICs don't > > >> get lost anymore. > > >> > > >> pciconf and verbose dmesg: http://pastebin.com/f31621191 > > >> > > >> btw, what does this knob actually do ? > > > > > > mcfg is a mechanism for doing faster PCI config access using a memory= =20 > mapped > > > window. =A0Can you grab the output of 'acpidump -t'? > > > > >=20 > > /* > > MCFG: Length=3D60, Revision=3D1, Checksum=3D46, > > OEMID=3DIntelR, OEM Table ID=3DAWRDACPI, OEM Revision=3D0x42302= e31, > > Creator ID=3DAWRD, Creator Revision=3D0x0 > >=20 > > Base Address=3D 0x00000000e0000000 > > Segment Group=3D 0x0000 > > Start Bus=3D 0 > > End Bus=3D 0 > > */ >=20 > Hmm, your BIOS is rather buggy and claims to only support MCFG for bus 0.= I=20 > will work on a fix. I think I will make the code fall back to the old co= nfig=20 > mechanism when an MCFG region doesn't include the requested bus. Try the patch at http://www.FreeBSD.org/~jhb/patches/pci_mcfg.patch and let me know how it goes. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 22:41:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D47106566C for ; Mon, 23 Mar 2009 22:41:04 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFB88FC15 for ; Mon, 23 Mar 2009 22:41:03 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1104677qwb.7 for ; Mon, 23 Mar 2009 15:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=HoNP7O78lbFQN4jB9+ULu+DApocVq0M+gIovsDQI8tY=; b=uDl/+UEEA8s5NjI2Fe12Bgzr74wk6siq4GUonGSgVvdXduPz4Jq+1+fvSF3LVico1G C5gjNNwrhpgCm/C9ca0YD4egzBdtQqTBk+16y1XUT8n19hfat4fG2qKHCSN4OAM0lR6P nL1HIAGEWiXy4BWwIzxrrkPens+ee5Urno8os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=QNHyON0okwrOUTx06YsLKyax9deP31gY26eMOnUIx+KtDB5Rq17DBugexDkGhxWKVd xzjVkpGJSrYbJSVZCoYPjHs1Oqn29XbhSaIk/G8M5iCrBJQf+kLUW9lN1Zp6V9NCzWD6 nF/fdNzV5Nhj/6pGGVO42Ya70NMK8RkWoXvzM= Received: by 10.224.61.6 with SMTP id r6mr9772631qah.160.1237848063051; Mon, 23 Mar 2009 15:41:03 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.18.191]) by mx.google.com with ESMTPS id 34sm737517yxm.8.2009.03.23.15.41.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 15:41:02 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 55B77B8074; Mon, 23 Mar 2009 19:40:54 -0300 (BRT) Received: from 189.92.6.212 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Mon, 23 Mar 2009 19:40:54 -0300 (BRT) Message-ID: In-Reply-To: <1237804575.1771.7.camel@balrog.2hip.net> References: <1237804575.1771.7.camel@balrog.2hip.net> Date: Mon, 23 Mar 2009 19:40:54 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 22:41:04 -0000 On Mon, March 23, 2009 07:36, Robert Noland wrote: > So I have my i386 install on a usb hard disk, which I can only boot on > one machine now. The one machine that I can make work has a bios option > that reads "BIOS ehci handoff". This used to work with the old usb > stack. The machines that it doesn't work on, boot the kernel, but fail > to mount root, giving me the forbidding mountroot> prompt, which is > immediately followed by the message saying that da0 is attached. da0 is > however not listed in the available boot devices list. I tried playing > around with the timeout in vfs_mount.c, but that didn't seem to have any > impact. It has been suggested that this may be a "geom" timeout, but I > don't know anything about the boot system really. I had problem a while ago with via mini itx hardware, that was quite close. If I try boot from usb (installed in usb hdd), I get to the point of loader not finding my disk. I then used a small flash disk attached to the ata (44 pin ide) channel and formatted /boot in there. this way I get to the point of mount root you said, and da0 not being alive soon enough to mount root. list disks also couldn't find da0 though. I tried current from that time, and no good. if this is solved, I'll be happy to try whatever patch to current. (as long as I can install it from another box/or its ata channel, as it can't boot vanilla 7.1R) matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 23:42:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C5C0106568A for ; Mon, 23 Mar 2009 23:42:15 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from tritus.poildetroll.net (tritus.poildetroll.net [81.93.245.19]) by mx1.freebsd.org (Postfix) with ESMTP id C108A8FC13 for ; Mon, 23 Mar 2009 23:42:14 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from Korriban.poildetroll.net (kashyyyk.poildetroll.net [88.162.190.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tritus.poildetroll.net (Postfix) with ESMTPSA id 8BFD9F74 for ; Tue, 24 Mar 2009 00:22:43 +0100 (CET) Message-ID: <49C819BB.4090100@poildetroll.net> Date: Tue, 24 Mar 2009 00:22:35 +0100 From: Pierre Guinoiseau Organization: Poil de Troll User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig97415F92DE3B0AD13A0079FE" Subject: Kernel panic with IGMPv3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:42:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97415F92DE3B0AD13A0079FE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all ! My last running kernel is from 03/05/2009, I can't get a working kernel since then, because it panics soon after the boot process (or even while booting), whenever my laptop start networking. The panic seems to be related to IGMPv3 interrupts. The pointer given to m_freem() seems... abnormal ;) But I don't know how to debug this. Anyway, it may be related to the IGMPv3 merge on 03/09/2009 at rev r189592. Here is the kgdb output with a kernel compiled today from latest current, I hope this helps, and I'm at your disposition if more infos are required to solve this problem. :) Thanks ! [root@Korriban ~] # kgdb /boot/kernel.noop/kernel /usr/crash/vmcore.0 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 detail= s. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 0; apic id =3D 00 instruction pointer =3D 0x8:0xffffffff803ae495 stack pointer =3D 0x10:0xfffffffe40035ad0 frame pointer =3D 0x10:0xfffffffe40035af0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi1: net) panic: from debugger cpuid =3D 0 Uptime: 2m51s Physical memory: 2027 MB Dumping 146 MB: 131 115 99 83 67 51 35 19 3 #0 doadump () at pcpu.h:215 215 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:215 #1 0xffffffff803583f2 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff803588a0 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801dadc7 in db_panic (addr=3DVariable "addr" is not availab= le. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801db251 in db_command (last_cmdp=3D0xffffffff8080c6a0, cmd_table=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801db499 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801dd2f7 in db_trap (type=3DVariable "type" is not availabl= e. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff80384662 in kdb_trap (type=3D9, code=3D0, tf=3D0xfffffffe40035a20) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff805b0e0d in trap_fatal (frame=3D0xfffffffe40035a20, eva=3DVariable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:745 #9 0xffffffff805b1855 in trap (frame=3D0xfffffffe40035a20) at /usr/src/sys/amd64/amd64/trap.c:551 #10 0xffffffff8058f2be in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #11 0xffffffff803ae495 in m_freem (mb=3D0xdeadc0dedeadc0de) at /usr/src/sys/kern/uipc_mbuf.c:163 #10 0xffffffff8058f2be in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #11 0xffffffff803ae495 in m_freem (mb=3D0xdeadc0dedeadc0de) at /usr/src/sys/kern/uipc_mbuf.c:163 #12 0xffffffff80434e4c in igmp_intr (m=3DVariable "m" is not available. ) at /usr/src/sys/netinet/igmp.c:3454 #13 0xffffffff803fd942 in swi_net (dummy=3D0xffffff0004211400) at /usr/src/sys/net/netisr.c:145 #14 0xffffffff8033a195 in intr_event_execute_handlers (p=3DVariable "p" i= s not available. ) at /usr/src/sys/kern/kern_intr.c:1134 #15 0xffffffff8033ad89 in ithread_loop (arg=3D0xffffff0001319820) at /usr/src/sys/kern/kern_intr.c:1147 #16 0xffffffff8033819a in fork_exit (callout=3D0xffffffff8033acdb , arg=3D0xffffff0001319820, frame=3D0xfffffffe40035c80) at /usr/src/sys/kern/kern_fork.c:821 #17 0xffffffff8058f69e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:553 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000ba2000 in ?? () #43 0x0000000000000109 in ?? () #44 0xffffffff8082dcc0 in affinity () #45 0xffffffff8082dcc0 in affinity () #46 0x0000000000000000 in ?? () #47 0xfffffffe40035b80 in ?? () #48 0xfffffffe40035b38 in ?? () #49 0xffffff000132d000 in ?? () #50 0xffffffff80378a99 in sched_switch (td=3D0xffffff0001319820, newtd=3DVariable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1867 Previous frame inner to this frame (corrupt stack?) (kgdb) frame 11 #11 0xffffffff803ae495 in m_freem (mb=3D0xdeadc0dedeadc0de) at /usr/src/sys/kern/uipc_mbuf.c:163 163 while (mb !=3D NULL) (kgdb) list 158 */ 159 void 160 m_freem(struct mbuf *mb) 161 { 162 163 while (mb !=3D NULL) 164 mb =3D m_free(mb); 165 } 166 167 /*- (kgdb) frame 12 #12 0xffffffff80434e4c in igmp_intr (m=3DVariable "m" is not available. ) at /usr/src/sys/netinet/igmp.c:3454 3454 m_freem(m0); (kgdb) list 3449 mac_netinet_igmp_send(ifp, m0); 3450 #endif 3451 error =3D ip_output(m0, ipopts, NULL, 0, &imo, NULL); 3452 if (error) { 3453 CTR3(KTR_IGMPV3, "%s: ip_output(%p) =3D %d", __func__, m0, error); 3454 m_freem(m0); 3455 goto out; 3456 } 3457 3458 ++V_igmpstat.igps_snd_reports; (kgdb) frame 13 #13 0xffffffff803fd942 in swi_net (dummy=3D0xffffff0004211400) at /usr/src/sys/net/netisr.c:145 145 ni->ni_handler(m); (kgdb) list 140 141 for (;;) { 142 IF_DEQUEUE(ni->ni_queue, m); 143 if (m =3D=3D NULL) 144 break; 145 ni->ni_handler(m); 146 } 147 } 148 149 /* (kgdb) --------------enig97415F92DE3B0AD13A0079FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknIGcIACgkQJikNJSAyef8rOgCgt0fa4DRvkmJJ00mx5mDJXSIR hDsAoIypNKKHNhG5ylmkR53eGI7eFMPZ =tgV7 -----END PGP SIGNATURE----- --------------enig97415F92DE3B0AD13A0079FE-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 23 23:46:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C5C31065785; Mon, 23 Mar 2009 23:46:22 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5965F8FC1A; Mon, 23 Mar 2009 23:46:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1625770ewy.43 for ; Mon, 23 Mar 2009 16:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1MyKk2tw5usd2R12CpyTq6zjCTbs6kHDC7iXlObDnuc=; b=iOJoL345eBtylFiCjw9dWcfx6DW6dqdfxdxltXJL6BlriaiDdxIyHwVkmZ6ck8s5t3 sMPghp1N1gCHPlSqrterRxd4pk5OvY/QeJCaorc8xdzBrUVl10NDhQh/JC0E5zBWyYz/ Uc5FEStjMKEe28+7eMbLx922pxO5VKuXgm380= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qY7TdzBNu4qYF6tarrHqm+MK1sbpa9Hp77h+w38edLwEpbtcdWySlvcPGEOYgmZ+XU u4fOVBtGHAJNWBxcw6RBqdmphTd4nfH/CQUytNEBBonG/yoGgd5nMoxvccAcwheULZal follwTmsQYno/8fcMV0kvHCU6vkhQ/czI+iww= MIME-Version: 1.0 Received: by 10.210.21.6 with SMTP id 6mr2689724ebu.63.1237851980320; Mon, 23 Mar 2009 16:46:20 -0700 (PDT) In-Reply-To: <1237829409.1771.13.camel@balrog.2hip.net> References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> <1237829409.1771.13.camel@balrog.2hip.net> Date: Tue, 24 Mar 2009 00:46:20 +0100 Message-ID: <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> From: "Paul B. Mahol" To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Douglas Berry , freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:46:25 -0000 On 3/23/09, Robert Noland wrote: > On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: >> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: >> > So I have my i386 install on a usb hard disk, which I can only boot >> > on one machine now. The one machine that I can make work has a bios >> > option that reads "BIOS ehci handoff". This used to work with the >> > old usb stack. The machines that it doesn't work on, boot the >> > kernel, but fail to mount root, giving me the forbidding mountroot> >> > prompt, which is immediately followed by the message saying that da0 >> > is attached. da0 is however not listed in the available boot >> > devices list. I tried playing around with the timeout in >> > vfs_mount.c, but that didn't seem to have any impact. It has been >> > suggested that this may be a "geom" timeout, but I don't know >> > anything about the boot system really. >> >> I have been using tunefs(8) labeled partitions on my usb hard disk >> under CURRENT. I changed the fstab entries to match the labels >> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) >> It works well on most systems. On some systems, I see the symptom >> you show, but I am saved by the labels showing up just after the >> mountroot prompt. I am then able to type >> >> ufs:/dev/ufs/myroot >> >> and resume the boot. Maybe this helps you? > > Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a > doesn't work from the rootmount> prompt. Even after da0 shows up. That is strange, I just recently have used one of usb sticks (256MB) to fix stupid sysinstall error. In my case da0 appeared after some delay but usual da0s1a appeared after ? and I was able to mount root partition multiple times. I used usb via modules, on i386 revision r190297, with "boot -s" (I hacked fbsd installation on stick because I didnt have time for fine details ....) Could try just with uhci (but it will be too sloow) -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 00:12:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EE521065673 for ; Tue, 24 Mar 2009 00:12:13 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1303E8FC25 for ; Tue, 24 Mar 2009 00:12:12 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1118490qwb.7 for ; Mon, 23 Mar 2009 17:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=/t1FNkMoIk1bt6ry9mLcIxt6OrfE4ip3YBjheQ+UqdM=; b=Ak1+Eo1cBa+RsX08XFCKWEgJT9Vlndoj8mEZ2ImkERfDfDoDoYaTi/YjbdbAl5O2Y+ nW6Lv34n2UJnYr++eIwScT01w7LAV0thqVNlkQTGhJLkNCV1TvgCtwPlv0CnOVL11VHC kP1HiTU6Jt/jlb338gNrwMEIa4+u68dl0QNNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=BUJF4sdYE6Mg3nDb52AFNb+OPSwAVQhu+FCF6aDGWwBEnjURd0a+8HYzhip4U1lMAm m2uusG5vSBAdFKW9JVWUfxxPhsUXJ/042opQaU/Ux84VEXHvu0y2EwYbZB0G9JITobav aqPKXTyylNv0ksRRN1HwGcR+x2+CuxRyw3YlY= Received: by 10.224.45.77 with SMTP id d13mr9868147qaf.153.1237853532426; Mon, 23 Mar 2009 17:12:12 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.18.191]) by mx.google.com with ESMTPS id 33sm1079101yxr.37.2009.03.23.17.12.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 17:12:12 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 0A762B8074; Mon, 23 Mar 2009 21:12:06 -0300 (BRT) Received: from 189.92.17.177 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Mon, 23 Mar 2009 21:12:06 -0300 (BRT) Message-ID: <800e97aebad7e157c6b31466447501f7.squirrel@cygnus.homeunix.com> In-Reply-To: <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> <1237829409.1771.13.camel@balrog.2hip.net> <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> Date: Mon, 23 Mar 2009 21:12:06 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:12:13 -0000 On Mon, March 23, 2009 20:46, Paul B. Mahol wrote: > On 3/23/09, Robert Noland wrote: >> On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: >>> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: >>> > So I have my i386 install on a usb hard disk, which I can only boot >>> > on one machine now. The one machine that I can make work has a bios >>> > option that reads "BIOS ehci handoff". This used to work with the >>> > old usb stack. The machines that it doesn't work on, boot the >>> > kernel, but fail to mount root, giving me the forbidding mountroot> >>> > prompt, which is immediately followed by the message saying that da0 >>> > is attached. da0 is however not listed in the available boot >>> > devices list. I tried playing around with the timeout in >>> > vfs_mount.c, but that didn't seem to have any impact. It has been >>> > suggested that this may be a "geom" timeout, but I don't know >>> > anything about the boot system really. >>> >>> I have been using tunefs(8) labeled partitions on my usb hard disk >>> under CURRENT. I changed the fstab entries to match the labels >>> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) >>> It works well on most systems. On some systems, I see the symptom >>> you show, but I am saved by the labels showing up just after the >>> mountroot prompt. I am then able to type >>> >>> ufs:/dev/ufs/myroot >>> >>> and resume the boot. Maybe this helps you? >> >> Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a >> doesn't work from the rootmount> prompt. Even after da0 shows up. > > That is strange, I just recently have used one of usb sticks (256MB) to > fix > stupid sysinstall error. In my case da0 appeared after some delay but > usual da0s1a appeared after ? and I was able to mount root > partition multiple times. > I used usb via modules, on i386 revision r190297, with "boot -s" > (I hacked fbsd installation on stick because I didnt have time for fine > details ....) > > Could try just with uhci (but it will be too sloow) how can I make it use this module and not another ? (how to force) matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 01:01:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59BC8106564A for ; Tue, 24 Mar 2009 01:01:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3F58FC08 for ; Tue, 24 Mar 2009 01:01:02 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B491B2FBD23; Mon, 23 Mar 2009 20:45:39 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 23 Mar 2009 20:45:39 -0400 X-Sasl-enc: L0y8/EIOlXgpW0WRUg0lLCPjGz5B+jpXmbByN2fQExHP 1237855539 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1BF7332140; Mon, 23 Mar 2009 20:45:38 -0400 (EDT) Message-ID: <49C82D31.1030200@FreeBSD.org> Date: Tue, 24 Mar 2009 00:45:37 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Pierre Guinoiseau References: <49C819BB.4090100@poildetroll.net> In-Reply-To: <49C819BB.4090100@poildetroll.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic with IGMPv3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:01:03 -0000 Pierre Guinoiseau wrote: > Here is the kgdb output with a kernel compiled today from latest > current, I hope this helps, and I'm at your disposition if more infos > are required to solve this problem. :) > Full ifconfig and the value of 'error' returned by ip_output() in that stack frame please...! Some issues were found and fixed after the merge. It looks like for whatever reason, ip_output() fails at that point, and it is possible that the mbuf chain shouldn't be getting freed at that point. Are you running avahi or SMP? cheers, BMS P.S. I will be going on holiday tomorrow and will not be able to help out further for at least a week. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 01:24:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622E51065686 for ; Tue, 24 Mar 2009 01:24:40 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9C7208FC1E for ; Tue, 24 Mar 2009 01:24:39 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 24 Mar 2009 00:57:55 -0000 Received: from p54866262.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.98.98] by mail.gmx.net (mp029) with SMTP; 24 Mar 2009 01:57:55 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX18jpkcpThkjzqehSlEsSAyRlDVXMoSAihZq6RFRft +LdOIi0U1TyNoO Message-ID: <49C83038.40300@gmx.net> Date: Tue, 24 Mar 2009 01:58:32 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.44 Cc: sam@freebsd.org Subject: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:24:41 -0000 Hi, I have a problem with my wireless connection. I am running FreeBSD 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink based USB adapter (Linksys WUSB54GC-EU via rum(4)). At home using the Atheros card together with a FreeBSD (7.1) based access point (using rum(4) in hostap mode) and the wpa_supplicant.conf (attached at the end of this email) settings for SSID="home" I don't have any problems. With a Linksys WRT54GL-DE access point running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open wireless LAN also works flawlessly. At the university, however, (SSID="IDA" in the wpa_supplicant.conf at the end of this email) the wireless connection only works for about an hour. The vague term "wireless connection" in this case means, that the WPA connection is opened and associated, then I get an IP address via dhclient. There is a message about "OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 EAP method 'MSCHAPv2'" but the authentication seems to succeed: ----8<-------------------------------------------------------- Mar 23 13:27:31 impala wpa_supplicant[429]: Authentication with 00:1b:2f:ef:d3:c9 timed out. Mar 23 13:27:33 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:27:33 impala wpa_supplicant[429]: Trying to associate with 00:1b:2f:ef:d3:c9 (SSID='IDA' freq=2472 MHz) Mar 23 13:27:43 impala wpa_supplicant[429]: Authentication with 00:1b:2f:ef:d3:c9 timed out. Mar 23 13:27:43 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:27:43 impala wpa_supplicant[429]: Trying to associate with 00:1b:2f:ef:d3:b9 (SSID='IDA' freq=2442 MHz) Mar 23 13:27:53 impala wpa_supplicant[429]: Authentication with 00:1b:2f:ef:d3:b9 timed out. Mar 23 13:27:56 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:27:56 impala wpa_supplicant[429]: Trying to associate with 00:1b:2f:ef:d3:b9 (SSID='IDA' freq=2442 MHz) Mar 23 13:28:06 impala wpa_supplicant[429]: Authentication with 00:1b:2f:ef:d3:b9 timed out. Mar 23 13:28:08 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:28:08 impala wpa_supplicant[429]: Trying to associate with 00:1e:2a:f9:0a:64 (SSID='IDA' freq=2472 MHz) Mar 23 13:28:18 impala wpa_supplicant[429]: Authentication with 00:1e:2a:f9:0a:64 timed out. Mar 23 13:28:20 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:28:20 impala wpa_supplicant[429]: Trying to associate with 00:1e:2a:f9:0a:64 (SSID='IDA' freq=2472 MHz) Mar 23 13:28:30 impala wpa_supplicant[429]: Authentication with 00:1e:2a:f9:0a:64 timed out. Mar 23 13:28:32 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:28:32 impala wpa_supplicant[429]: Trying to associate with 00:1b:2f:ef:d3:c9 (SSID='IDA' freq=2472 MHz) Mar 23 13:28:32 impala wpa_supplicant[429]: Associated with 00:1b:2f:ef:d3:c9 Mar 23 13:28:32 impala kernel: wlan0: link state changed to UP Mar 23 13:28:32 impala wpa_supplicant[429]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 23 13:28:32 impala wpa_supplicant[429]: TLS: Unsupported Phase2 EAP method 'MSCHAPv2' Mar 23 13:28:32 impala wpa_supplicant[429]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 23 13:28:32 impala wpa_supplicant[429]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 23 13:28:32 impala wpa_supplicant[429]: EAP-MSCHAPV2: Authentication succeeded Mar 23 13:28:32 impala wpa_supplicant[429]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 23 13:28:32 impala wpa_supplicant[429]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 23 13:28:32 impala wpa_supplicant[429]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] Mar 23 13:28:32 impala wpa_supplicant[429]: CTRL-EVENT-CONNECTED - Connection to 00:1b:2f:ef:d3:c9 completed (auth) [id=3 id_str=] Mar 23 13:28:40 impala dhclient: New IP Address (wlan0): 192.168.100.54 Mar 23 13:28:40 impala dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 23 13:28:40 impala dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 23 13:28:40 impala dhclient: New Routers (wlan0): 192.168.100.1 Mar 23 13:28:46 impala su: dthiele to root on /dev/pts/1 Mar 23 13:29:08 impala kernel: ath0: bb hang detected (0x80), reseting [unrelated logs] Mar 23 13:33:34 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:35:27 impala kernel: ath0: bb hang detected (0x4), reseting Mar 23 13:38:36 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:41:48 impala kernel: ath0: mac hang detected (0x8000) Mar 23 13:43:38 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:48:41 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:53:43 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 13:57:23 impala kernel: ath0: bb hang detected (0x80), reseting Mar 23 13:58:45 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:03:47 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:08:50 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:13:55 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:23:59 impala last message repeated 2 times Mar 23 14:26:11 impala kernel: ath0: bb hang detected (0x80), reseting ----8<-------------------------------------------------------- After a while (in most cases this happened after roughly an hour) I get these messages: ----8<-------------------------------------------------------- Mar 23 14:28:45 impala wpa_supplicant[429]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 23 14:28:45 impala wpa_supplicant[429]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 23 14:28:45 impala wpa_supplicant[429]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-MSCHAPV2: Authentication succeeded Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 23 14:28:46 impala wpa_supplicant[429]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Failed to set PTK to the driver. Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] Mar 23 14:29:01 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:34:03 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS Mar 23 14:39:05 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS ----8<-------------------------------------------------------- ifconfig still lists the connection as "associated": ----8<-------------------------------------------------------- impala# ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:21:91:db:15:30 media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated ssid IDA channel 13 (2472 Mhz 11g) bssid 00:1b:2f:ef:d3:c9 regdomain ETSI indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL ----8<-------------------------------------------------------- But dhclient does not accept any new leases: ----8<-------------------------------------------------------- impala# dhclient wlan0 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPNAK from 192.168.100.1 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 No DHCPOFFERS received. Trying recorded lease 192.168.100.54 bound: renewal in 5900 seconds. ----8<-------------------------------------------------------- The site's wireless admin was so kind to provide me with the logs from their DHCP server, which seems to offer new leases that somehow don't make it through to my machine: ----8<-------------------------------------------------------- DHCPDISCOVER from 00:21:91:db:15:30 (impala) via 192.168.100.1 DHCPOFFER on 192.168.100.54 to 00:21:91:db:15:30 (impala) via 192.168.100.1 ----8<-------------------------------------------------------- If I audaciously assign myself an IP address (192.168.100.54) and set the default route to 192.168.100.1, the wireless connection sill won't work. I cannot even ping the router at 192.168.100.1. Next, I tried to rule out the wireless adapter. Both the Atheros ExpressCard and the Ralink USB Adapter show the above mentioned behavior. So the problem might perhaps be located in FreeBSD's wireless stack, wpa_supplicant or dhclient? But I'm not an expert in these areas, thus this email. What works in the case of the Ralink USB adapter is simply unplugging and replugging the device. Then I get another hour of working wireless before it breaks again. Since hot-plugging the ExpressCard currently does not seem to work I cannot confirm this for the Atheros adapter. I also tried ----8<-------------------------------------------------------- /etc/rc.d/netif restart ----8<-------------------------------------------------------- and ----8<-------------------------------------------------------- ifconfig wlan0 destroy ifconfig wlan0 create wlandev rum0 ----8<-------------------------------------------------------- followed by a restart of wpa_suppicant and dhclient, too, but without any success. So only re-plugging the device seems to solve or at least stall the problem. The output of wpa_supplicant -ddd after the wireless connection stopped working can be found at: http://www-public.tu-bs.de:8080/~y0023183/FreeBSD/Wireless/wpa_supplicant-ddd.txt On a FreeBSD 7.1-STABLE machine with wpa_supplicant v0.5.10 and the Ralink USB adapter I did not encounter the problem. Now, my question is has anyone else encountered this behavior (WPA-PSK working nicely and WPA-EAP only for a limited period of time) and knows how to fix this issue? Perhaps it is just a misconfiguration on my part. If not, how can I help to further investigate this issue. What can I do to provide additional debug information? Best regards, Daniel Thiele Additioinal information: impala# uname -a FreeBSD impala.vnws.lan 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sun Mar 22 00:34:38 CET 2009 dthiele@impala.vnws.lan:/usr/obj/usr/src/sys/kernel_8Xv0 i386 (Kernel and world are in sync) impala# kldstat -v | grep wlan 236 wlan 235 wlan_wep 234 wlan_tkip 233 wlan_ccmp 232 wlan_amrr 237 wlan_sta impala# wpa_supplicant -v wpa_supplicant v0.6.8 Copyright (c) 2003-2009, Jouni Malinen and contributors impala# cat /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel ap_scan=1 fast_reauth=1 # This is the working setup I am using at home. # The AP is a ThinkPad R40 running FreeBSD-7.1-STABLE with a rum(4) # wireless adapter in hostap mode. network={ ssid="SuperCollider" scan_ssid=1 mode=0 proto=WPA key_mgmt=WPA-PSK psk="[REMOVED]" pairwise=CCMP priority=10 } # This is the "partially-working" setup at the university network={ ssid="IDA" mode=0 proto=WPA2 key_mgmt=WPA-EAP eap=PEAP identity="[REMOVED]" anonymous_identity="[REMOVED]" password="[REMOVED]" ca_cert="[REMOVED]" phase2="autH=msCHAPv2" priority=2 } impala# cat /etc/dhclient.conf timeout 60; retry 60; interface "wlan0" { prepend domain-name-servers [REMOVED], 217.237.150.188; request subnet-mask, broadcast-address, time-offset, routers, domain-name; } impala# grep wlan /etc/rc.conf wlans_ath0=wlan0 ifconfig_wlan0="WPA DHCP" From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 01:26:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24026106564A for ; Tue, 24 Mar 2009 01:26:16 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8D39D8FC17 for ; Tue, 24 Mar 2009 01:26:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n2NMXOsj015718 for ; Mon, 23 Mar 2009 23:33:24 +0100 Received: from [192.168.100.184] ([88.11.103.61]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032323333163:169443 ; Mon, 23 Mar 2009 23:33:31 +0100 Message-ID: <49C80DBA.80407@entel.upc.edu> Date: Mon, 23 Mar 2009 23:31:22 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 23/03/2009 23:33:31, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 23/03/2009 23:33:32, Serialize complete at 23/03/2009 23:33:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 23 Mar 2009 23:33:24 +0100 (CET) Subject: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:26:16 -0000 Hi to the list, a few time ago I switched to current, right now I've it updated to yesterday. While compiling some ports (in fact, building x11/gnome2) I found that some of them (written in C) are using some inline functions (I guess it is because the compiler will replace the call to the function with the function itself). The problem is that gcc fails with the following message : error: nested function 'XXX' declared but never defined checking the code, the function is declared and then implemented in a header file which is included in the offending .c file. The function is declared as 'inline'. The only solution I found is to change the definition to static. Checking pontyhat shows me that many ports are failing because of this problem. What I can understand is why is this happening, because the same ports compiles fine in STABLE and the compilers's version in base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same in current) Can anyone help with this problem ? Greets, Gus From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 03:05:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B9EC106566B for ; Tue, 24 Mar 2009 03:05:55 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id D8AF38FC19 for ; Tue, 24 Mar 2009 03:05:54 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from [192.168.1.116] (static-70-108-250-162.res.east.verizon.net [70.108.250.162]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n2O35fOH033396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Mar 2009 03:05:47 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: Gustau Perez In-Reply-To: <49C80DBA.80407@entel.upc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 23:05:35 -0400 References: <49C80DBA.80407@entel.upc.edu> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 03:05:55 -0000 On Mar 23, 2009, at 6:31 PM, Gustau Perez wrote: > a few time ago I switched to current, right now I've it updated to > yesterday. While compiling some ports (in fact, building x11/ > gnome2) I found that some of them (written in C) are using some > inline functions (I guess it is because the compiler will replace > the call to the function with the function itself). The problem is > that gcc fails with the following message : > error: nested function 'XXX' declared but never defined > > checking the code, the function is declared and then implemented in > a header file which is included in the offending .c file. The > function is declared as 'inline'. The only solution I found is to > change the definition to static. > > Checking pontyhat shows me that many ports are failing because of > this problem. What I can understand is why is this happening, > because the same ports compiles fine in STABLE and the compilers's > version in base seems to be the same (gcc (GCC) 4.2.1 20070719 > [FreeBSD], the same in current) > Can anyone help with this problem ? Check out the arch@ discussion about "C99 Inlines" and this commit: http://svn.freebsd.org/viewvc/base?view=revision&revision=189824 It seems like they might be related. Hope that helps. - Ben From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 06:07:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF771065676; Tue, 24 Mar 2009 06:07:02 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9218FC12; Tue, 24 Mar 2009 06:07:01 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so375046eyf.7 for ; Mon, 23 Mar 2009 23:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tmicF/H4lY9OTObGL17tmXHvEyL9FpDKxTpq4pSIB6Y=; b=i45YzdYO6uXlTXQdZAumt+mTTywQeIhJjolLhLQIlRh+elWxIDKlrKZxcTEiz/rGs6 rQ+5nWJ1vQCbsJoB/K1eDmN4RS4DWb3FsBIqzSlYKax1KhRRccauix+VX/IcK5zOTOsz v5imRT0+DDRUIs6jCuHZt2CcIiiPiNox67+gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qK04xDroUhHqDYK9+WiXfOxP9gLAtcPqmle6dbJc7FMdz5wXoVdQlWi7xjgNQrSsH9 2DUbooApaKlNvUnQ2GknBXJhMSYBxxcnEhXoGyysRzB0BXwHLfoxB0qqo8YSmy2UA1RF OIODaZx+HT9osT0qHGSUkj9dZwnszPL8ze904= MIME-Version: 1.0 Received: by 10.210.42.20 with SMTP id p20mr6021345ebp.66.1237874819929; Mon, 23 Mar 2009 23:06:59 -0700 (PDT) In-Reply-To: <200903231728.46911.jkim@FreeBSD.org> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> Date: Tue, 24 Mar 2009 01:06:59 -0500 Message-ID: <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> From: Brandon Gooch To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 06:07:02 -0000 On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote: > On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> The committed version is working well, I am suspending and resuming >> on my Lenovo X300. Thanks for your work on this, it is one of the >> major things I needed to work so I could run FreeBSD primarily on >> my notebook. > > Great. > >> Is there some way to keep the OS date and time in updated (after >> resume), or am I missing something in my system configuration? > > In fact, I am working on it and I will commit the fix very soon. ;-) > > Jung-uk Kim > I just finished a kernel build and it seems as though your recent commits have fixed the clock (at least for me)! I feel sorry for all the i386 folks on ACPI notebooks... Thanks! -Brandon From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 07:32:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68C22106564A for ; Tue, 24 Mar 2009 07:32:40 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id C6D7C8FC1E for ; Tue, 24 Mar 2009 07:32:39 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1690720ewy.43 for ; Tue, 24 Mar 2009 00:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=90J2psyc3tE3Lrru5Gbb8x4qlx1pnHeIyP14NkiYvrs=; b=Ut35mFcTqtjjg5PdQZuaEArFWG44FUCJPd3FhP4BuVuMEH6FQdKFBane/VV9FUBEnY YkQ94cMhyEjD1/n0byZCqZNbrEOt0SNlxe9kNIk2leSg2Dc5u4b4IKepuzZ4UdETlSnO 3D9D21dD1IzLmoeNlCvyJdDJ8eULGUj8c5fF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mz0o529ib5Jl4Vy+80N84DUFfOMBdxBr18BM5cFa3Zmj20MikHLV1kFc95xkgAVAgF 7vP5eHVh1yuA1KIvNcgc9cZgUY0FY1lVXH6wGVx29cYM19m4snUNgz1IAAijS4mCLciG QK0w6bJa8Mk0ddgKabZfy/BG1eErtFS0cB8+g= MIME-Version: 1.0 Received: by 10.210.91.7 with SMTP id o7mr2960445ebb.39.1237879958867; Tue, 24 Mar 2009 00:32:38 -0700 (PDT) In-Reply-To: <800e97aebad7e157c6b31466447501f7.squirrel@cygnus.homeunix.com> References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> <1237829409.1771.13.camel@balrog.2hip.net> <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> <800e97aebad7e157c6b31466447501f7.squirrel@cygnus.homeunix.com> Date: Tue, 24 Mar 2009 08:32:38 +0100 Message-ID: <3a142e750903240032s3e3dbb72pd12e984886fef908@mail.gmail.com> From: "Paul B. Mahol" To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:32:40 -0000 On 3/24/09, Nenhum_de_Nos wrote: > > On Mon, March 23, 2009 20:46, Paul B. Mahol wrote: >> On 3/23/09, Robert Noland wrote: >>> On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: >>>> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: >>>> > So I have my i386 install on a usb hard disk, which I can only boot >>>> > on one machine now. The one machine that I can make work has a bios >>>> > option that reads "BIOS ehci handoff". This used to work with the >>>> > old usb stack. The machines that it doesn't work on, boot the >>>> > kernel, but fail to mount root, giving me the forbidding mountroot> >>>> > prompt, which is immediately followed by the message saying that da0 >>>> > is attached. da0 is however not listed in the available boot >>>> > devices list. I tried playing around with the timeout in >>>> > vfs_mount.c, but that didn't seem to have any impact. It has been >>>> > suggested that this may be a "geom" timeout, but I don't know >>>> > anything about the boot system really. >>>> >>>> I have been using tunefs(8) labeled partitions on my usb hard disk >>>> under CURRENT. I changed the fstab entries to match the labels >>>> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) >>>> It works well on most systems. On some systems, I see the symptom >>>> you show, but I am saved by the labels showing up just after the >>>> mountroot prompt. I am then able to type >>>> >>>> ufs:/dev/ufs/myroot >>>> >>>> and resume the boot. Maybe this helps you? >>> >>> Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a >>> doesn't work from the rootmount> prompt. Even after da0 shows up. >> >> That is strange, I just recently have used one of usb sticks (256MB) to >> fix >> stupid sysinstall error. In my case da0 appeared after some delay but >> usual da0s1a appeared after ? and I was able to mount root >> partition multiple times. >> I used usb via modules, on i386 revision r190297, with "boot -s" >> (I hacked fbsd installation on stick because I didnt have time for fine >> details ....) >> >> Could try just with uhci (but it will be too sloow) > > how can I make it use this module and not another ? (how to force) I doubt it will help but anyway ... Just ensure that you are using custom kernel without any of usb, ehci, uhci, etc lines. And forcing uhci is simple, just dont kldload ehci (or dont "load echi" from boot loader prompt) and load any other usb modules you need. -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 07:42:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D88FA1065673 for ; Tue, 24 Mar 2009 07:42:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3068FC13 for ; Tue, 24 Mar 2009 07:42:48 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=hzHASVDcAAAA:8 a=6I5d2MoRAAAA:8 a=Q8RHAWkl7CDnB8CKw8AA:9 a=Tfq0xeAGEqcHpN8_5kWXXS_WxgMA:4 a=LY0hPdMaydYA:10 a=vXa-fTo6yJYA:10 a=SV7veod9ZcQA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1213061847; Tue, 24 Mar 2009 08:42:47 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 24 Mar 2009 08:45:18 +0100 User-Agent: KMail/1.9.7 References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> <800e97aebad7e157c6b31466447501f7.squirrel@cygnus.homeunix.com> <3a142e750903240032s3e3dbb72pd12e984886fef908@mail.gmail.com> In-Reply-To: <3a142e750903240032s3e3dbb72pd12e984886fef908@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903240845.18610.hselasky@c2i.net> Cc: Nenhum_de_Nos Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:42:50 -0000 On Tuesday 24 March 2009, Paul B. Mahol wrote: > On 3/24/09, Nenhum_de_Nos wrote: > > On Mon, March 23, 2009 20:46, Paul B. Mahol wrote: > >> On 3/23/09, Robert Noland wrote: > >>> On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: > >>>> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: > >>>> > So I have my i386 install on a usb hard disk, which I can only boot > >>>> > on one machine now. The one machine that I can make work has a bios > >>>> > option that reads "BIOS ehci handoff". This used to work with the > >>>> > old usb stack. The machines that it doesn't work on, boot the > >>>> > kernel, but fail to mount root, giving me the forbidding mountroot> > >>>> > prompt, which is immediately followed by the message saying that da0 > >>>> > is attached. da0 is however not listed in the available boot > >>>> > devices list. I tried playing around with the timeout in > >>>> > vfs_mount.c, but that didn't seem to have any impact. It has been > >>>> > suggested that this may be a "geom" timeout, but I don't know > >>>> > anything about the boot system really. > >>>> > >>>> I have been using tunefs(8) labeled partitions on my usb hard disk > >>>> under CURRENT. I changed the fstab entries to match the labels > >>>> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) > >>>> It works well on most systems. On some systems, I see the symptom > >>>> you show, but I am saved by the labels showing up just after the > >>>> mountroot prompt. I am then able to type > >>>> > >>>> ufs:/dev/ufs/myroot > >>>> > >>>> and resume the boot. Maybe this helps you? > >>> > >>> Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a > >>> doesn't work from the rootmount> prompt. Even after da0 shows up. > >> > >> That is strange, I just recently have used one of usb sticks (256MB) to > >> fix > >> stupid sysinstall error. In my case da0 appeared after some delay but > >> usual da0s1a appeared after ? and I was able to mount root > >> partition multiple times. > >> I used usb via modules, on i386 revision r190297, with "boot -s" > >> (I hacked fbsd installation on stick because I didnt have time for fine > >> details ....) > >> > >> Could try just with uhci (but it will be too sloow) > > > > how can I make it use this module and not another ? (how to force) > > I doubt it will help but anyway ... > > Just ensure that you are using custom kernel without any of usb, ehci, > uhci, etc lines. And forcing uhci is simple, just dont kldload ehci > (or dont "load echi" from boot loader prompt) and load any other usb > modules you need. There is also a new sysctl to do this runtime: sysctl hw.usb2.ehci.no_hs=1 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 07:44:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BADE410656BA for ; Tue, 24 Mar 2009 07:44:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 21FB18FC1D for ; Tue, 24 Mar 2009 07:44:05 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=6I5d2MoRAAAA:8 a=2At8Q0IxsUAmnmmiMs8A:9 a=RbaUGAyy8uUO7zn8B1oA:7 a=WFT5vHUGYIhUJLRTbMtRzSjJhKEA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1112097469; Tue, 24 Mar 2009 08:44:04 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 24 Mar 2009 08:46:35 +0100 User-Agent: KMail/1.9.7 References: <49C7FE13.90808@lissyara.su> In-Reply-To: <49C7FE13.90808@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903240846.35938.hselasky@c2i.net> Cc: Alex Keda Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:44:07 -0000 On Monday 23 March 2009, Alex Keda wrote: > I have USB floppy. > > Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device > descriptor at addr 3 failed! > Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 > Mar 24 00:11:26 HP kernel: umass0: 0/0, rev 1.10/2.00, addr 3> on usbus0 > Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 ^^^^ Edit /sys/dev/usb/storage/umass.c And remove the quirk entry for your device. Maybe it is not correct. --HPS > Mar 24 00:11:27 HP kernel: umass0:2:0:-1: Attached to scbus2 > Mar 24 00:11:27 HP kernel: xptioctl: pass driver is not in the kernel > Mar 24 00:11:27 HP kernel: xptioctl: put "device pass" in your kernel > config file > > > but, > > HP$ grep "pass" /usr/src/sys/amd64/conf/GENERIC > device pass # Passthrough device (direct SCSI access) > device aacp # SCSI passthrough for aac (requires CAM) > HP$ > > If I unplug and plug it to the same port: > > Mar 24 00:19:12 HP kernel: usb2_alloc_device:1516: getting device > descriptor at addr 3 failed! > Mar 24 00:19:12 HP kernel: usb2_req_re_enumerate:1434: getting device > descriptor at addr 3 failed! > Mar 24 00:19:14 HP kernel: usb2_req_re_enumerate:1434: getting device > descriptor at addr 3 failed! > Mar 24 00:19:14 HP kernel: ugen0.3: <> at usbus0 (disconnected) > Mar 24 00:19:14 HP kernel: uhub_reattach_port:413: could not allocate > new device! > > If I plug it to another port - it detect, but need "pass" driver =) > > ============ > I have USB mouse. If I plug it first time - all OK. If second - to the > some port: > Mar 24 00:21:45 HP kernel: ugen0.3: at usbus0 > Mar 24 00:21:45 HP kernel: ums0: rev 2.00/3.40, addr 3> on usbus0 > Mar 24 00:21:45 HP kernel: ums0: error reading report description > Mar 24 00:21:45 HP kernel: device_attach: ums0 attach returned 12 > > ======== > HP$ uname -a > FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 23 > 22:45:17 MSK 2009 > lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > HP$ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 07:55:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05268106564A for ; Tue, 24 Mar 2009 07:55:49 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BF8198FC0C for ; Tue, 24 Mar 2009 07:55:48 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2O7sQcn018342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 03:54:26 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Paul B. Mahol" In-Reply-To: <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> References: <200903231541.n2NFfP6f002755@monk.cnd.dundas.on.ca> <1237829409.1771.13.camel@balrog.2hip.net> <3a142e750903231646x165d2bf2jcac4c6ca2c83702c@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-X3cEprJjEKoymoGIThb1" Organization: FreeBSD Date: Tue, 24 Mar 2009 02:55:23 -0500 Message-Id: <1237881323.1771.15.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Douglas Berry , freebsd-current Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:55:49 -0000 --=-X3cEprJjEKoymoGIThb1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 00:46 +0100, Paul B. Mahol wrote: > On 3/23/09, Robert Noland wrote: > > On Mon, 2009-03-23 at 11:41 -0400, Douglas Berry wrote: > >> On Mon, 23 Mar 2009 05:36:15 CDT, Robert Noland wrote: > >> > So I have my i386 install on a usb hard disk, which I can only boot > >> > on one machine now. The one machine that I can make work has a bios > >> > option that reads "BIOS ehci handoff". This used to work with the > >> > old usb stack. The machines that it doesn't work on, boot the > >> > kernel, but fail to mount root, giving me the forbidding mountroot> > >> > prompt, which is immediately followed by the message saying that da0 > >> > is attached. da0 is however not listed in the available boot > >> > devices list. I tried playing around with the timeout in > >> > vfs_mount.c, but that didn't seem to have any impact. It has been > >> > suggested that this may be a "geom" timeout, but I don't know > >> > anything about the boot system really. > >> > >> I have been using tunefs(8) labeled partitions on my usb hard disk > >> under CURRENT. I changed the fstab entries to match the labels > >> (eg. assume mylabel is myroot, /dev/da0s1a becomes /dev/ufs/myroot) > >> It works well on most systems. On some systems, I see the symptom > >> you show, but I am saved by the labels showing up just after the > >> mountroot prompt. I am then able to type > >> > >> ufs:/dev/ufs/myroot > >> > >> and resume the boot. Maybe this helps you? > > > > Well, I haven't tried labeling the partitions, but ufs:/dev/da0s1a > > doesn't work from the rootmount> prompt. Even after da0 shows up. >=20 > That is strange, I just recently have used one of usb sticks (256MB) to f= ix > stupid sysinstall error. In my case da0 appeared after some delay but > usual da0s1a appeared after ? and I was able to mount root > partition multiple times. > I used usb via modules, on i386 revision r190297, with "boot -s" > (I hacked fbsd installation on stick because I didnt have time for fine > details ....) >=20 > Could try just with uhci (but it will be too sloow) So, my final work around was to set the tuneable kern.cam.scsi_delay=3D10000. That is probably too long, but it worked and I haven't had any issues since. robert. >=20 --=20 Robert Noland FreeBSD --=-X3cEprJjEKoymoGIThb1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknIkesACgkQM4TrQ4qfROPInQCfdktWE2UliU8pkgZcTxvgTAl6 CYEAmwUttzr9lPeRGemVV/JMpua3iChl =9Al0 -----END PGP SIGNATURE----- --=-X3cEprJjEKoymoGIThb1-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 08:16:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647CB1065677; Tue, 24 Mar 2009 08:16:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id E88CE8FC22; Tue, 24 Mar 2009 08:16:56 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2O8FXYY018470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 04:15:34 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: wsk In-Reply-To: <49C85F4E.5050002@gddsn.org.cn> References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yQkGkYl0Vhm/OQbS9wLk" Organization: FreeBSD Date: Tue, 24 Mar 2009 03:16:31 -0500 Message-Id: <1237882591.1771.26.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 08:16:58 -0000 --=-yQkGkYl0Vhm/OQbS9wLk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: > Robert Noland wrote: > > On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > > =20 > >>> Ok, this patch should work on NV50 chips also. > >>> =20 > >>> What you get is EXA and Xv. > >>> =20 > >>> You still need: > >>> =20 > >>> A recent -CURRENT or -STABLE. > >>> =20 > >>> git master of libdrm and xf86-video-nouveau. > >>> =20 > >>> This patch. > >>> =20 > >>> Things I've figured out since the last patch... > >>> =20 > >>> On NV50 class hardware you need to have a compositing manager running > >>> for Xv to work. That means xcompmgr, metacity with composite enabled= , > >>> xfce (rumored to work as well, haven't tried). If your running Gnome > >>> with metacity, open gconf-editor and go to apps->metacity->general an= d > >>> check the composite box. > >>> =20 > >>> On NV40 class hardware, you don't need the composite manager. In fac= t > >>> (at least with Xserver 1.6 which I'm running now), if a composite > >>> manager is enabled, I'm seeing high cpu utilization from Xorg under s= ome > >>> circumstances. I don't think this is a drm issue, but still an issue= . > >>> For me, if I start a video using mplayer in an xterm, cpu is fine as > >>> long as that xterm is the foreground window. If it is not the > >>> foreground window, even if it isn't obscured I see the cpu utilizatio= n. > >>> Disabling the composite manager makes everything fine. > >>> =20 > >>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > >>> =20 > >>> robert. > >>> =20 > >> get the following errors and exitThis is a pre-release version of the = X server from The X.Org Foundation. > >> It is not supported in any way. > >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >> Select the "xorg" product for bugs you find in this release. > >> Before reporting bugs in pre-release versions please check the > >> latest version in the X.Org Foundation git repository. > >> See http://wiki.x.org/wiki/GitPage for git access instructions. > >> > >> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >> Release Date: 2009-1-30 > >> X Protocol Version 11, Revision 0 > >> Build Operating System: FreeBSD 7.1-STABLE amd64 > >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeB= SD 7.2-PRE > >> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/= obj/usr/sr > >> c/sys/WSK amd64 > >> Build Date: 06 February 2009 04:22:44PM > >> > >> Before reporting problems, check http://wiki.x.org > >> to make sure that you have the latest version. > >> Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > >> (++) from command line, (!!) notice, (II) informational, > >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 20= 09 > >> ing config file: "xorg.conf1" > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x2 > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x2 > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x2 > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x1 > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x1 > >> drm0: [ITHREAD] > >> info: [drm] Allocating FIFO number 1 > >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > >> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >> (EE) Screen(s) found, but none have a usable configuration. > >> > >> Fatal server error: > >> no screens found > >> > >> Please consult the The X.Org Foundation support > >> at http://wiki.x.org > >> for help. > >> Please also check the log file at "/var/log/Xorg.0.log" for additional= informati > >> on. > >> > >> info: [drm] nouveau_fifo_free: freeing fifo 1 > >> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel= 1 before > >> destroy.Prepare for strangeness.. > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resourc= e 0x1 > >> > >> what can i do ? > >> > >> > >> > >> > >> plain text document attachment (Xorg.0.log) > >> This is a pre-release version of the X server from The X.Org Foundatio= n. > >> It is not supported in any way. > >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >> Select the "xorg" product for bugs you find in this release. > >> Before reporting bugs in pre-release versions please check the > >> latest version in the X.Org Foundation git repository. > >> See http://wiki.x.org/wiki/GitPage for git access instructions. > >> > >> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >> Release Date: 2009-1-30 > >> X Protocol Version 11, Revision 0 > >> Build Operating System: FreeBSD 7.1-STABLE amd64=20 > >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeB= SD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:= /usr/obj/usr/src/sys/WSK amd64 > >> Build Date: 06 February 2009 04:22:44PM > >> =20 > >> Before reporting problems, check http://wiki.x.org > >> to make sure that you have the latest version. > >> Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > >> (++) from command line, (!!) notice, (II) informational, > >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 20= 09 > >> (++) Using config file: "xorg.conf1" > >> (=3D=3D) No Layout section. Using the first Screen section. > >> (=3D=3D) No screen section available. Using defaults. > >> (**) |-->Screen "Default Screen Section" (0) > >> (**) | |-->Monitor "" > >> (=3D=3D) No device specified for screen "Default Screen Section". > >> Using the first device section listed. > >> (**) | |-->Device "Card0" > >> (=3D=3D) No monitor specified for screen "Default Screen Section". > >> Using a default monitor configuration. > >> (=3D=3D) Automatically adding devices > >> (=3D=3D) Automatically enabling devices > >> (=3D=3D) No FontPath specified. Using compiled-in default. > >> (=3D=3D) FontPath set to: > >> built-ins > >> (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > >> (II) Cannot locate a core pointer device. > >> (II) Cannot locate a core keyboard device. > >> (II) The server relies on HAL to provide the list of input devices. > >> If no devices become available, reconfigure HAL or disable AllowEmpty= Input. > >> (II) Loader magic: 0xb20 > >> (II) Module ABI versions: > >> X.Org ANSI C Emulation: 0.4 > >> X.Org Video Driver: 5.0 > >> X.Org XInput driver : 4.0 > >> X.Org Server Extension : 2.0 > >> (II) Loader running on freebsd > >> (--) Using syscons driver with X support (version 2.0) > >> (--) using VT number 9 > >> > >> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ = 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x000= 0df00/128, BIOS @ 0x????????/65536 > >> =20 > > > > Ok, thats a new one... > > > > =20 > >> (II) System resource ranges: > >> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >> (II) LoadModule: "extmod" > >> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > >> (II) Module extmod: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.0.0 > >> Module class: X.Org Server Extension > >> ABI class: X.Org Server Extension, version 2.0 > >> (II) Loading extension MIT-SCREEN-SAVER > >> (II) Loading extension XFree86-VidModeExtension > >> (II) Loading extension XFree86-DGA > >> (II) Loading extension DPMS > >> (II) Loading extension XVideo > >> (II) Loading extension XVideo-MotionCompensation > >> (II) Loading extension X-Resource > >> (II) LoadModule: "dbe" > >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > >> (II) Module dbe: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.0.0 > >> Module class: X.Org Server Extension > >> ABI class: X.Org Server Extension, version 2.0 > >> (II) Loading extension DOUBLE-BUFFER > >> (II) LoadModule: "glx" > >> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > >> (II) Module glx: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.0.0 > >> ABI class: X.Org Server Extension, version 2.0 > >> (=3D=3D) AIGLX disabled > >> (=3D=3D) Exporting typical set of GLX visuals > >> (II) Loading extension GLX > >> (II) LoadModule: "record" > >> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > >> (II) Module record: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.13.0 > >> Module class: X.Org Server Extension > >> ABI class: X.Org Server Extension, version 2.0 > >> (II) Loading extension RECORD > >> (II) LoadModule: "dri" > >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > >> (II) Module dri: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.0.0 > >> ABI class: X.Org Server Extension, version 2.0 > >> (II) Loading extension XFree86-DRI > >> (II) LoadModule: "nouveau" > >> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so > >> (II) Module nouveau: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 0.0.10 > >> Module class: X.Org Video Driver > >> ABI class: X.Org Video Driver, version 5.0 > >> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 > >> (II) NOUVEAU driver for NVIDIA chipset families : > >> RIVA TNT (NV04) > >> RIVA TNT2 (NV05) > >> GeForce 256 (NV10) > >> GeForce 2 (NV11, NV15) > >> GeForce 4MX (NV17, NV18) > >> GeForce 3 (NV20) > >> GeForce 4Ti (NV25, NV28) > >> GeForce FX (NV3x) > >> GeForce 6 (NV4x) > >> GeForce 7 (G7x) > >> GeForce 8 (G8x) > >> (II) Primary Device is: PCI 01@00:00:0 > >> (II) resource ranges after probing: > >> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" > >> =20 > > > > Hrm, NV86... I'll have to ask around about that. Meanwhile can you sen= d > > me a pciconf -lvb which should at least show us the BAR configuration. > > > > Ok, my sources are telling me that this should work and that it is an > > NV50, or at least should work the same... > > > > Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'= m > > not sure if it may be trashing the BARs somehow. > > > > robert. > > =20 >=20 > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x01fe1028 chip=3D0x2a008086 > rev=3D0x0c hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller= ' > class =3D bridge > subclass =3D HOST-PCI > pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x01fe1028 chip=3D0x2a018086 > rev=3D0x0c hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'Mobile PM965/GM965/GL960 Express PCIe Root Port' > class =3D bridge > subclass =3D PCI-PCI > uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0x01fe1028 chip=3D0x28348086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB UHCI' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x6f20, size 32, enabled > uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0x01fe1028 chip=3D0x28358086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB UHCI' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x6f00, size 32, enabled > ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0x01fe1028 chip=3D0x283a8086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xfed1c400, size 1024, enabled > hdac0@pci0:0:27:0: class=3D0x040300 card=3D0x01fe1028 chip=3D0x284b8086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' > class =3D multimedia > subclass =3D HDA > bar [10] =3D type Memory, range 64, base 0xfebfc000, size 16384, enabled > pcib2@pci0:0:28:0: class=3D0x060400 card=3D0x01fe1028 chip=3D0x283f8086 > rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) PCIe Port 1' > class =3D bridge > subclass =3D PCI-PCI > pcib3@pci0:0:28:1: class=3D0x060400 card=3D0x01fe1028 chip=3D0x28418086 > rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) PCIe Port 2' > class =3D bridge > subclass =3D PCI-PCI > pcib4@pci0:0:28:3: class=3D0x060400 card=3D0x01fe1028 chip=3D0x28458086 > rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) PCIe Port 4' > class =3D bridge > subclass =3D PCI-PCI > pcib5@pci0:0:28:5: class=3D0x060400 card=3D0x01fe1028 chip=3D0x28498086 > rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) PCIe Port 6' > class =3D bridge > subclass =3D PCI-PCI > uhci2@pci0:0:29:0: class=3D0x0c0300 card=3D0x01fe1028 chip=3D0x28308086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB UHCI' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x6f80, size 32, enabled > uhci3@pci0:0:29:1: class=3D0x0c0300 card=3D0x01fe1028 chip=3D0x28318086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB UHCI' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x6f60, size 32, enabled > uhci4@pci0:0:29:2: class=3D0x0c0300 card=3D0x01fe1028 chip=3D0x28328086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB UHCI' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x6f40, size 32, enabled > ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0x01fe1028 chip=3D0x28368086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) USB2 EHCI' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xfed1c000, size 1024, enabled > pcib6@pci0:0:30:0: class=3D0x060401 card=3D0x01fe1028 chip=3D0x24488086 > rev=3D0xf2 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge= ' > class =3D bridge > subclass =3D PCI-PCI > isab0@pci0:0:31:0: class=3D0x060100 card=3D0x01fe1028 chip=3D0x28158086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'ICH8M-E (ICH8 Family) LPC Interface Controller' > class =3D bridge > subclass =3D PCI-ISA > atapci0@pci0:0:31:1: class=3D0x01018a card=3D0x01fe1028 chip=3D0x28508086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) Ultra ATA Storage Controllers' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x1f0, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x3f4, size 1, enabled > bar [18] =3D type I/O Port, range 32, base 0x170, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x374, size 1, enabled > bar [20] =3D type I/O Port, range 32, base 0x6fa0, size 16, enabled > atapci1@pci0:0:31:2: class=3D0x01018f card=3D0x01fe1028 chip=3D0x28288086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'ICH8M (ICH8 Family) 3 port SATA Controller' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x6eb0, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x6eb8, size 4, enabled > bar [18] =3D type I/O Port, range 32, base 0x6ec0, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x6ec8, size 4, enabled > bar [20] =3D type I/O Port, range 32, base 0x6ee0, size 16, enabled > bar [24] =3D type I/O Port, range 32, base 0xeff0, size 16, enabled > ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x01fe1028 chip=3D0x283e8086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801H (ICH8 Family) SMBus Controller' > class =3D serial bus > subclass =3D SMBus > bar [10] =3D type Memory, range 32, base 0xfebfbf00, size 256, enabled > bar [20] =3D type I/O Port, range 32, base 0x10c0, size 32, enabled > vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x01fe1028 chip=3D0x042910de > rev=3D0xa1 hdr=3D0x00 > vendor =3D 'Nvidia Corp' > device =3D 'Unknown nVidia Quadro FX 570M' > class =3D display > subclass =3D VGA > bar [10] =3D type Memory, range 32, base 0xfd000000, size 16777216, enabl= ed Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 should be your framebuffer and should be where most of your memory is. (This is the memory the tell you about when you buy the card, 256M, 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 isn't there. We are going to need more details on your card... > bar [1c] =3D type Memory, range 64, base 0xfa000000, size 33554432, enabl= ed This one is BAR 3, which is used when it doesn't find BAR 1. robert. > bar [24] =3D type I/O Port, range 32, base 0xdf00, size 128, enabled > ndis0@pci0:12:0:0: class=3D0x028000 card=3D0x000a1028 chip=3D0x432814e4 > rev=3D0x03 hdr=3D0x00 > vendor =3D 'Broadcom Corporation' > device =3D 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solut= ion' > class =3D network > bar [10] =3D type Memory, range 64, base 0xf9ffc000, size 16384, enabled > bar [18] =3D type Prefetchable Memory, range 64, base 0xf0000000, size > 1048576, enabled > bge0@pci0:9:0:0: class=3D0x020000 card=3D0x01fe1028 chip=3D0x167314e4 rev= =3D0x02 > hdr=3D0x00 > vendor =3D 'Broadcom Corporation' > device =3D 'B57xx Broadcom NetXtreme Gigabit Ethernet' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 64, base 0xf9bf0000, size 65536, enabled > cbb0@pci0:3:1:0: class=3D0x060700 card=3D0x01fe1028 chip=3D0x71351217 rev= =3D0x21 > hdr=3D0x02 > vendor =3D 'O2 Micro Inc' > device =3D 'OZ711EZ1 MemoryCardBus Controller' > class =3D bridge > subclass =3D PCI-CardBus > bar [10] =3D type Memory, range 32, base 0xf9a00000, size 4096, enabled > fwohci0@pci0:3:1:4: class=3D0x0c0010 card=3D0x01fe1028 chip=3D0x00f71217 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'O2 Micro Inc' > device =3D '0x00f71217 1394 Open Host Controller Interface' > class =3D serial bus > subclass =3D FireWire > bar [10] =3D type Memory, range 32, base 0xf9aff000, size 4096, enabled > bar [14] =3D type Memory, range 32, base 0xf9afe800, size 2048, enabled >=20 > and follow your intrudction.still pain me :( >=20 > (++) Using config file: "xorg.conf1" > drm0: on vgapci0 > info: [drm] Detected an NV50 generation card (0x086900a2) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized nouveau 0.0.12 20060213 > error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x= 2 > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x= 1 > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x= 1 > drm0: [ITHREAD] > info: [drm] Allocating FIFO number 1 > error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, > invalid/inactiv > e channel id 128 > info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: > [drm] , nSt > atus:info: [drm] > info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data > 0x00000000:0x00 > 000000 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x800000= 3f > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f= 0e > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff736= 7f > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x000018= 50 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff35= 87 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6f= ad > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd= 60 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000= d7 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x313976= 8d > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d697= 57 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x631616= 50 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x072200= 09 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x000000= 00 > error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x000000= 00 > info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > info: [drm] PFIFO_DMA_PUSHER - Ch 1 > (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > (EE) Screen(s) found, but none have a usable configuration. >=20 > Fatal server error: > no screens found >=20 > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > Please also check the log file at "/var/log/Xorg.0.log" for additional > informati > on. >=20 > info: [drm] nouveau_fifo_free: freeing fifo 1 > error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1 > before d > estroy.Prepare for strangeness.. > info: [drm] PFIFO_DMA_PUSHER - Ch 127 > vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff= ). > error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x= 1 >=20 > > =20 > >> (II) Loading sub module "int10" > >> (II) LoadModule: "int10" > >> (II) Loading /usr/local/lib/xorg/modules//libint10.so > >> (II) Module int10: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 1.0.0 > >> ABI class: X.Org Video Driver, version 5.0 > >> (II) NOUVEAU(0): Initializing int10 > >> (=3D=3D) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was alrea= dy clear > >> (=3D=3D) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was alrea= dy clear > >> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 > >> (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already cl= ear > >> drmOpenDevice: node name is /dev/dri/card0 > >> drmOpenDevice: open result is 10, (OK) > >> drmOpenDevice: node name is /dev/dri/card0 > >> drmOpenDevice: open result is 10, (OK) > >> drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > >> drmOpenDevice: node name is /dev/dri/card0 > >> drmOpenDevice: open result is 10, (OK) > >> drmOpenByBusid: drmOpenMinor returns 10 > >> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > >> (II) [drm] DRM interface version 1.2 > >> (II) [drm] DRM open master succeeded. > >> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 > >> (--) NOUVEAU(0): [drm] kernel modesetting not available > >> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 > >> (II) NOUVEAU(0): Creating default Display subsection in Screen section > >> "Default Screen Section" for depth/fbbpp 24/32 > >> (=3D=3D) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 > >> (=3D=3D) NOUVEAU(0): RGB weight 888 > >> (=3D=3D) NOUVEAU(0): Default visual is TrueColor > >> (II) Loading sub module "vgahw" > >> (II) LoadModule: "vgahw" > >> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > >> (II) Module vgahw: vendor=3D"X.Org Foundation" > >> compiled for 1.5.99.902, module version =3D 0.1.0 > >> ABI class: X.Org Video Driver, version 5.0 > >> (=3D=3D) NOUVEAU(0): Randr1.2 support enabled > >> (=3D=3D) NOUVEAU(0): Using HW cursor > >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >> (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already cl= ear > >> (II) UnloadModule: "nouveau" > >> (II) UnloadModule: "vgahw" > >> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so > >> (II) UnloadModule: "int10" > >> (II) Unloading /usr/local/lib/xorg/modules//libint10.so > >> (EE) Screen(s) found, but none have a usable configuration. > >> > >> Fatal server error: > >> no screens found > >> > >> Please consult the The X.Org Foundation support=20 > >> at http://wiki.x.org > >> for help.=20 > >> Please also check the log file at "/var/log/Xorg.0.log" for additional= information. > >> > >> =20 >=20 --=20 Robert Noland FreeBSD --=-yQkGkYl0Vhm/OQbS9wLk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknIlt8ACgkQM4TrQ4qfROMiRgCgiGibe4kxUxOEjpRIwC5jWsA6 UiQAnjbVWIPpknCyuFk8OC3jJVJerFV8 =z8ca -----END PGP SIGNATURE----- --=-yQkGkYl0Vhm/OQbS9wLk-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 08:50:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE814106564A for ; Tue, 24 Mar 2009 08:50:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9AACD8FC12 for ; Tue, 24 Mar 2009 08:50:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-207-58.bna.bellsouth.net [65.1.207.58]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2O8mZvD018607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 04:48:35 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Nenhum_de_Nos In-Reply-To: References: <1237804575.1771.7.camel@balrog.2hip.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ufgED6cs1kXmznRR0gSS" Organization: FreeBSD Date: Tue, 24 Mar 2009 03:49:32 -0500 Message-Id: <1237884572.1771.28.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 08:50:01 -0000 --=-ufgED6cs1kXmznRR0gSS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > On Mon, March 23, 2009 07:36, Robert Noland wrote: > > So I have my i386 install on a usb hard disk, which I can only boot on > > one machine now. The one machine that I can make work has a bios optio= n > > that reads "BIOS ehci handoff". This used to work with the old usb > > stack. The machines that it doesn't work on, boot the kernel, but fail > > to mount root, giving me the forbidding mountroot> prompt, which is > > immediately followed by the message saying that da0 is attached. da0 i= s > > however not listed in the available boot devices list. I tried playing > > around with the timeout in vfs_mount.c, but that didn't seem to have an= y > > impact. It has been suggested that this may be a "geom" timeout, but I > > don't know anything about the boot system really. >=20 > I had problem a while ago with via mini itx hardware, that was quite > close. If I try boot from usb (installed in usb hdd), I get to the point > of loader not finding my disk. >=20 > I then used a small flash disk attached to the ata (44 pin ide) channel > and formatted /boot in there. this way I get to the point of mount root > you said, and da0 not being alive soon enough to mount root. list disks > also couldn't find da0 though. >=20 > I tried current from that time, and no good. >=20 > if this is solved, I'll be happy to try whatever patch to current. (as > long as I can install it from another box/or its ata channel, as it can't > boot vanilla 7.1R) So, my solution was to set kern.cam.scsi_delay=3D10000 in /boot/loader.conf You can hit 6 from the boot menu and set it manually the first time. robert. > matheus >=20 --=20 Robert Noland FreeBSD --=-ufgED6cs1kXmznRR0gSS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknInpwACgkQM4TrQ4qfROML/ACcC2d45/zP1GSjJwSta3y0HuwV WrsAn18y4ApeNv5S/KZeyDw6s9yRKMWX =k5Ex -----END PGP SIGNATURE----- --=-ufgED6cs1kXmznRR0gSS-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 09:26:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28341106566C for ; Tue, 24 Mar 2009 09:26:16 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id BCD8D8FC30 for ; Tue, 24 Mar 2009 09:26:15 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 10:14:11 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2O9E8DP003472 for freebsd-current@freebsd.org; Tue, 24 Mar 2009 10:14:08 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Tue, 24 Mar 2009 10:14:08 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090324091408.GA3251@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 24 Mar 2009 09:14:11.0756 (UTC) FILETIME=[E51E0EC0:01C9AC60] Subject: updating 7.0-RELEASE to CURRENT changes interface from le0 to le1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 09:26:16 -0000 Hello, I've updated in a VMWare a 7.0-RELEASE to CURRENT exactly as described in the handbook, i.e. following the procedure in 24.7 Rebuilding "world"; after having up the VM again, network was not coming up and it took me some minutes to realize that the interface name changed from 'le0' to 'le1': Mar 23 14:28:40 vm-naranja kernel: le0: port 0x2000-0x207f irq 19 at device 1.0 on pci2 Mar 23 14:28:40 vm-naranja kernel: le0: 16 receive buffers, 4 transmit buffers Mar 23 14:28:40 vm-naranja kernel: le0: Ethernet address: 00:0c:29:78:48:c6 Mar 23 14:28:40 vm-naranja kernel: le0: [ITHREAD] Mar 24 09:13:39 vm-naranja kernel: le1: port 0x2000-0x207f irq 19 at device 1.0 on pci2 Mar 24 09:13:39 vm-naranja kernel: le1: 16 receive buffers, 4 transmit buffers Mar 24 09:13:39 vm-naranja kernel: le1: Ethernet address: 00:0c:29:78:48:c6 Mar 24 09:13:39 vm-naranja kernel: le1: [ITHREAD] I changed the name in rc.conf and all was fine again; but what could have caused this change? there is no le0 anymore, only le1 and the config of the VM was not changed, not even powered-off? matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 11:03:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F4061106564A for ; Tue, 24 Mar 2009 11:03:37 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 770128FC08 for ; Tue, 24 Mar 2009 11:03:37 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2OB3WRr050564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Mar 2009 12:03:35 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <49C8BE04.6030702@boland.org> Date: Tue, 24 Mar 2009 12:03:32 +0100 From: Michiel Boland User-Agent: Thunderbird 2.0.0.19 (X11/20090315) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: console pinned at 9600 bps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 11:03:38 -0000 Hi. After the latest update my serial console speed appears to be pinned at 9600. For the life of me, I can't figure out how this happend. Relevant lines from my loader.conf: comconsole_speed="115200" console="comconsole" This used to Just Work until a few days ago. Anyone else having problems with serial consoles at nonstandard speeds in recent -CURRENTs? Or is this pilot error somewhere? Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 11:08:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 578A4106564A for ; Tue, 24 Mar 2009 11:08:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E82428FC12 for ; Tue, 24 Mar 2009 11:08:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 99EC41CF09; Tue, 24 Mar 2009 12:08:02 +0100 (CET) Date: Tue, 24 Mar 2009 12:08:02 +0100 From: Ed Schouten To: Michiel Boland Message-ID: <20090324110802.GH87326@hoeg.nl> References: <49C8BE04.6030702@boland.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aF3LVLvitz/VQU3c" Content-Disposition: inline In-Reply-To: <49C8BE04.6030702@boland.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: console pinned at 9600 bps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 11:08:04 -0000 --aF3LVLvitz/VQU3c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michiel Boland wrote: > Hi. After the latest update my serial console speed appears to be pinned= =20 > at 9600. For the life of me, I can't figure out how this happend.=20 > Relevant lines from my loader.conf: > > comconsole_speed=3D"115200" > console=3D"comconsole" > > This used to Just Work until a few days ago. > > Anyone else having problems with serial consoles at nonstandard speeds in= =20 > recent -CURRENTs? Or is this pilot error somewhere? Does it still work in the boot loader itself? If it is, it's probably not a TTY bug. :-) --=20 Ed Schouten WWW: http://80386.nl/ --aF3LVLvitz/VQU3c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknIvxIACgkQ52SDGA2eCwWljwCfe7eCwSFCfPrTe10W2woSW/5d j9gAn2rC7uk77eh93R/hf67lqbBmvG4M =Je0l -----END PGP SIGNATURE----- --aF3LVLvitz/VQU3c-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 11:14:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8CB2106566C for ; Tue, 24 Mar 2009 11:14:30 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 745628FC1F for ; Tue, 24 Mar 2009 11:14:30 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 89E165D33 for ; Tue, 24 Mar 2009 11:56:23 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L32ZkOf0EVAj for ; Tue, 24 Mar 2009 11:56:21 +0100 (CET) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 0805A5D29 for ; Tue, 24 Mar 2009 11:56:21 +0100 (CET) Message-ID: <49C8BC54.7050504@bsdunix.ch> Date: Tue, 24 Mar 2009 11:56:20 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: /usr/include/wchar.h:216: error: invalid use of 'restrict' in /lib32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 11:14:31 -0000 Hello I tried to update my current 64bit intel system from late January to the latest current code from March 24. FreeBSD foo.ch 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Jan 24 13:20:12 UTC 2009 make.conf: WITH_LIB32=yes src.conf: WITHOUT_ATM = TRUE WITHOUT_PROFILE = TRUE WITHOUT_IPFILTER = TRUE WITHOUT_IPX = TRUE WITHOUT_BLUETOOTH = TRUE WITHOUT_HTML = TRUE WITHOUT_WIRELESS = TRUE WITHOUT_WPA_SUPPLICANT_EAPOL = TRU make buildworld ends here: cc -o make_hash -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/ob j/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw /../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses -I/usr/src/lib/ncurses/n cursesw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncursesw/../../. ./contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERM IOS -std=gnu99 -DMAIN_PROGRAM /usr/src/lib/ncurses/ncursesw/../../../contrib/ ncurses/ncurses/tinfo/comp_hash.c In file included from ./curses.h:336, from /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu rses/curses.priv.h:259, from /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu rses/tinfo/comp_hash.c:42: /usr/include/wchar.h:216: error: invalid use of 'restrict' /usr/include/wchar.h:217: error: invalid use of 'restrict' *** Error code 1 Stop in /usr/src/lib/ncurses/ncursesw. *** Error code 1 Stop in /usr/src. *** Error code 1 What did i wrong? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 11:15:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C2E1065677 for ; Tue, 24 Mar 2009 11:15:14 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id 30D7A8FC1B for ; Tue, 24 Mar 2009 11:15:13 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2OBEoRU014425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 12:14:52 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <49C8C0A9.9030500@boland.org> Date: Tue, 24 Mar 2009 12:14:49 +0100 From: Michiel Boland User-Agent: Thunderbird 2.0.0.19 (X11/20090315) MIME-Version: 1.0 To: Ed Schouten References: <49C8BE04.6030702@boland.org> <20090324110802.GH87326@hoeg.nl> In-Reply-To: <20090324110802.GH87326@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: FreeBSD Current Subject: Re: console pinned at 9600 bps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 11:15:15 -0000 Ed Schouten wrote: > * Michiel Boland wrote: >> Hi. After the latest update my serial console speed appears to be pinned >> at 9600. For the life of me, I can't figure out how this happend. >> Relevant lines from my loader.conf: >> >> comconsole_speed="115200" >> console="comconsole" >> >> This used to Just Work until a few days ago. >> >> Anyone else having problems with serial consoles at nonstandard speeds in >> recent -CURRENTs? Or is this pilot error somewhere? > > Does it still work in the boot loader itself? If it is, it's probably > not a TTY bug. :-) > Probably should have mentioned this. The loader prompt is also at 9600 baud. It looks like loader simply ignores the baud setting completely. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 04:12:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CAE71065670; Tue, 24 Mar 2009 04:12:22 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id EA3188FC0C; Tue, 24 Mar 2009 04:12:21 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: by wf-out-1314.google.com with SMTP id 24so2714663wfg.7 for ; Mon, 23 Mar 2009 21:12:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.234.16 with SMTP id g16mr3181340wfh.264.1237867941478; Mon, 23 Mar 2009 21:12:21 -0700 (PDT) In-Reply-To: <200903231609.00039.jhb@freebsd.org> References: <200903231158.28121.jhb@freebsd.org> <200903231609.00039.jhb@freebsd.org> Date: Tue, 24 Mar 2009 12:12:21 +0800 Message-ID: From: Mars G Miro To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Mar 2009 11:17:43 +0000 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 04:12:22 -0000 On Tue, Mar 24, 2009 at 4:08 AM, John Baldwin wrote: > On Monday 23 March 2009 11:58:27 am John Baldwin wrote: >> On Friday 20 March 2009 11:08:35 pm Mars G Miro wrote: >> > On Sat, Mar 21, 2009 at 12:42 AM, John Baldwin wrote= : >> > > On Thursday 19 March 2009 11:24:24 pm Mars G Miro wrote: >> > >> On Thu, Mar 19, 2009 at 11:26 PM, John Baldwin wr= ote: >> > >> > What if you set 'hw.pci.mcfg=3D0' in loader? >> > >> > >> > >> >> > >> That did it! Even w/ ACPI enabled in the BIOS, the sk/msk NICs don'= t >> > >> get lost anymore. >> > >> >> > >> pciconf and verbose dmesg: http://pastebin.com/f31621191 >> > >> >> > >> btw, what does this knob actually do ? >> > > >> > > mcfg is a mechanism for doing faster PCI config access using a memor= y >> mapped >> > > window. =A0Can you grab the output of 'acpidump -t'? >> > > >> > >> > /* >> > =A0 MCFG: Length=3D60, Revision=3D1, Checksum=3D46, >> > =A0 =A0 =A0 =A0 OEMID=3DIntelR, OEM Table ID=3DAWRDACPI, OEM Revision= =3D0x42302e31, >> > =A0 =A0 =A0 =A0 Creator ID=3DAWRD, Creator Revision=3D0x0 >> > >> > =A0 =A0 =A0 =A0 Base Address=3D 0x00000000e0000000 >> > =A0 =A0 =A0 =A0 Segment Group=3D 0x0000 >> > =A0 =A0 =A0 =A0 Start Bus=3D 0 >> > =A0 =A0 =A0 =A0 End Bus=3D 0 >> > =A0*/ >> >> Hmm, your BIOS is rather buggy and claims to only support MCFG for bus 0= . =A0I >> will work on a fix. =A0I think I will make the code fall back to the old= config >> mechanism when an MCFG region doesn't include the requested bus. > > Try the patch at http://www.FreeBSD.org/~jhb/patches/pci_mcfg.patch and l= et > me know how it goes. > Okay , I csup'd / built to recent -CURRENT again, then applied that patch. It works!!! ACPI enabled in the BIOS, and I took out the hw.pci.mcfg=3D0 knob in loader.conf, and the sk/msk are still there. Full verbose dmesg: http://pastebin.com/f2724e215 Thanks!!! > -- > John Baldwin > --=20 cheers mars ----- Robert Benchley - "I have tried to know absolutely nothing about a great many things, and I have succeeded fair... From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 11:18:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3AA106570E for ; Tue, 24 Mar 2009 11:18:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF8C8FC2B for ; Tue, 24 Mar 2009 11:18:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1761083ewy.43 for ; Tue, 24 Mar 2009 04:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8qDbOhJeaJi41rT1mjAARbKq3p4jth/Rpy+ejyzxHlk=; b=qvkYagjZL4ZwetAM3FbMUgMEYeThdfZEdREu+UH8OajDweKjgJ/ILRHFQcXq3AKkHk Br7gtcGiuJ9YssfT/vr3pZMDrDz7lWzxYPRb0iEQzErbrUDIlmlENthov7Rc3xWSYxhx jRF2VexZoMIEVlxOZRxFG2aEbfxOnCwXZEmbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wIPFnY+8zCtDBWhyFHtcyoUkR1hK6sKiswurqhODmjDwIQIzW+KWqWa91FHU4doFhW B1FPNFj3Bb90BXIJZOC9txopAZ7QQ+hgNJAz7txRxtjOlInvWA/cSJVPAQjp2u54P+FT v+45gd/MQx/oKuOEjSlQNvH3ioESav0BxZrLA= MIME-Version: 1.0 Received: by 10.210.13.9 with SMTP id 9mr6253058ebm.7.1237893532272; Tue, 24 Mar 2009 04:18:52 -0700 (PDT) In-Reply-To: <20090324091408.GA3251@rebelion.Sisis.de> References: <20090324091408.GA3251@rebelion.Sisis.de> Date: Tue, 24 Mar 2009 12:18:52 +0100 Message-ID: <3a142e750903240418y70ad177cib7e2a167bc3974a0@mail.gmail.com> From: "Paul B. Mahol" To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: updating 7.0-RELEASE to CURRENT changes interface from le0 to le1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 11:18:55 -0000 Google is your friend. http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000741.html -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 04:19:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E092C106564A; Tue, 24 Mar 2009 04:19:28 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 4B80D8FC18; Tue, 24 Mar 2009 04:19:26 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 7A6622E011; Tue, 24 Mar 2009 12:18:38 +0800 (CST) Message-ID: <49C85F4E.5050002@gddsn.org.cn> Date: Tue, 24 Mar 2009 12:19:26 +0800 From: wsk User-Agent: Thunderbird 2.0.0.19 (X11/20090204) MIME-Version: 1.0 To: Robert Noland References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> In-Reply-To: <1237798914.2110.24.camel@balrog.2hip.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Mar 2009 11:23:46 +0000 Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 04:19:29 -0000 Robert Noland wrote: > On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > >>> Ok, this patch should work on NV50 chips also. >>> >>> What you get is EXA and Xv. >>> >>> You still need: >>> >>> A recent -CURRENT or -STABLE. >>> >>> git master of libdrm and xf86-video-nouveau. >>> >>> This patch. >>> >>> Things I've figured out since the last patch... >>> >>> On NV50 class hardware you need to have a compositing manager running >>> for Xv to work. That means xcompmgr, metacity with composite enabled, >>> xfce (rumored to work as well, haven't tried). If your running Gnome >>> with metacity, open gconf-editor and go to apps->metacity->general and >>> check the composite box. >>> >>> On NV40 class hardware, you don't need the composite manager. In fact >>> (at least with Xserver 1.6 which I'm running now), if a composite >>> manager is enabled, I'm seeing high cpu utilization from Xorg under some >>> circumstances. I don't think this is a drm issue, but still an issue. >>> For me, if I start a video using mplayer in an xterm, cpu is fine as >>> long as that xterm is the foreground window. If it is not the >>> foreground window, even if it isn't obscured I see the cpu utilization. >>> Disabling the composite manager makes everything fine. >>> >>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >>> >>> robert. >>> >> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation. >> It is not supported in any way. >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >> Select the "xorg" product for bugs you find in this release. >> Before reporting bugs in pre-release versions please check the >> latest version in the X.Org Foundation git repository. >> See http://wiki.x.org/wiki/GitPage for git access instructions. >> >> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >> Release Date: 2009-1-30 >> X Protocol Version 11, Revision 0 >> Build Operating System: FreeBSD 7.1-STABLE amd64 >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE >> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/sr >> c/sys/WSK amd64 >> Build Date: 06 February 2009 04:22:44PM >> >> Before reporting problems, check http://wiki.x.org >> to make sure that you have the latest version. >> 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 Mar 23 09:14:03 2009 >> ing config file: "xorg.conf1" >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> drm0: [ITHREAD] >> info: [drm] Allocating FIFO number 1 >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >> (EE) Screen(s) found, but none have a usable configuration. >> >> Fatal server error: >> no screens found >> >> Please consult the The X.Org Foundation support >> at http://wiki.x.org >> for help. >> Please also check the log file at "/var/log/Xorg.0.log" for additional informati >> on. >> >> info: [drm] nouveau_fifo_free: freeing fifo 1 >> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before >> destroy.Prepare for strangeness.. >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> >> what can i do ? >> >> >> >> >> plain text document attachment (Xorg.0.log) >> This is a pre-release version of the X server from The X.Org Foundation. >> It is not supported in any way. >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >> Select the "xorg" product for bugs you find in this release. >> Before reporting bugs in pre-release versions please check the >> latest version in the X.Org Foundation git repository. >> See http://wiki.x.org/wiki/GitPage for git access instructions. >> >> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >> Release Date: 2009-1-30 >> X Protocol Version 11, Revision 0 >> Build Operating System: FreeBSD 7.1-STABLE amd64 >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64 >> Build Date: 06 February 2009 04:22:44PM >> >> Before reporting problems, check http://wiki.x.org >> to make sure that you have the latest version. >> 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 Mar 23 09:14:03 2009 >> (++) Using config file: "xorg.conf1" >> (==) No Layout section. Using the first Screen section. >> (==) No screen section available. Using defaults. >> (**) |-->Screen "Default Screen Section" (0) >> (**) | |-->Monitor "" >> (==) No device specified for screen "Default Screen Section". >> Using the first device section listed. >> (**) | |-->Device "Card0" >> (==) No monitor specified for screen "Default Screen Section". >> Using a default monitor configuration. >> (==) Automatically adding devices >> (==) Automatically enabling devices >> (==) No FontPath specified. Using compiled-in default. >> (==) FontPath set to: >> built-ins >> (==) ModulePath set to "/usr/local/lib/xorg/modules" >> (II) Cannot locate a core pointer device. >> (II) Cannot locate a core keyboard device. >> (II) The server relies on HAL to provide the list of input devices. >> If no devices become available, reconfigure HAL or disable AllowEmptyInput. >> (II) Loader magic: 0xb20 >> (II) Module ABI versions: >> X.Org ANSI C Emulation: 0.4 >> X.Org Video Driver: 5.0 >> X.Org XInput driver : 4.0 >> X.Org Server Extension : 2.0 >> (II) Loader running on freebsd >> (--) Using syscons driver with X support (version 2.0) >> (--) using VT number 9 >> >> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536 >> > > Ok, thats a new one... > > >> (II) System resource ranges: >> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >> (II) LoadModule: "extmod" >> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so >> (II) Module extmod: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.0.0 >> Module class: X.Org Server Extension >> ABI class: X.Org Server Extension, version 2.0 >> (II) Loading extension MIT-SCREEN-SAVER >> (II) Loading extension XFree86-VidModeExtension >> (II) Loading extension XFree86-DGA >> (II) Loading extension DPMS >> (II) Loading extension XVideo >> (II) Loading extension XVideo-MotionCompensation >> (II) Loading extension X-Resource >> (II) LoadModule: "dbe" >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so >> (II) Module dbe: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.0.0 >> Module class: X.Org Server Extension >> ABI class: X.Org Server Extension, version 2.0 >> (II) Loading extension DOUBLE-BUFFER >> (II) LoadModule: "glx" >> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so >> (II) Module glx: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.0.0 >> ABI class: X.Org Server Extension, version 2.0 >> (==) AIGLX disabled >> (==) Exporting typical set of GLX visuals >> (II) Loading extension GLX >> (II) LoadModule: "record" >> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so >> (II) Module record: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.13.0 >> Module class: X.Org Server Extension >> ABI class: X.Org Server Extension, version 2.0 >> (II) Loading extension RECORD >> (II) LoadModule: "dri" >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so >> (II) Module dri: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.0.0 >> ABI class: X.Org Server Extension, version 2.0 >> (II) Loading extension XFree86-DRI >> (II) LoadModule: "nouveau" >> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so >> (II) Module nouveau: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 0.0.10 >> Module class: X.Org Video Driver >> ABI class: X.Org Video Driver, version 5.0 >> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 >> (II) NOUVEAU driver for NVIDIA chipset families : >> RIVA TNT (NV04) >> RIVA TNT2 (NV05) >> GeForce 256 (NV10) >> GeForce 2 (NV11, NV15) >> GeForce 4MX (NV17, NV18) >> GeForce 3 (NV20) >> GeForce 4Ti (NV25, NV28) >> GeForce FX (NV3x) >> GeForce 6 (NV4x) >> GeForce 7 (G7x) >> GeForce 8 (G8x) >> (II) Primary Device is: PCI 01@00:00:0 >> (II) resource ranges after probing: >> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" >> > > Hrm, NV86... I'll have to ask around about that. Meanwhile can you send > me a pciconf -lvb which should at least show us the BAR configuration. > > Ok, my sources are telling me that this should work and that it is an > NV50, or at least should work the same... > > Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'm > not sure if it may be trashing the BARs somehow. > > robert. > hostb0@pci0:0:0:0: class=0x060000 card=0x01fe1028 chip=0x2a008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x01fe1028 chip=0x2a018086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'Mobile PM965/GM965/GL960 Express PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:26:0: class=0x0c0300 card=0x01fe1028 chip=0x28348086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f20, size 32, enabled uhci1@pci0:0:26:1: class=0x0c0300 card=0x01fe1028 chip=0x28358086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f00, size 32, enabled ehci0@pci0:0:26:7: class=0x0c0320 card=0x01fe1028 chip=0x283a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfed1c400, size 1024, enabled hdac0@pci0:0:27:0: class=0x040300 card=0x01fe1028 chip=0x284b8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xfebfc000, size 16384, enabled pcib2@pci0:0:28:0: class=0x060400 card=0x01fe1028 chip=0x283f8086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 1' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x01fe1028 chip=0x28418086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 2' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x01fe1028 chip=0x28458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 4' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:5: class=0x060400 card=0x01fe1028 chip=0x28498086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 6' class = bridge subclass = PCI-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x01fe1028 chip=0x28308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f80, size 32, enabled uhci3@pci0:0:29:1: class=0x0c0300 card=0x01fe1028 chip=0x28318086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f60, size 32, enabled uhci4@pci0:0:29:2: class=0x0c0300 card=0x01fe1028 chip=0x28328086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f40, size 32, enabled ehci1@pci0:0:29:7: class=0x0c0320 card=0x01fe1028 chip=0x28368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfed1c000, size 1024, enabled pcib6@pci0:0:30:0: class=0x060401 card=0x01fe1028 chip=0x24488086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x01fe1028 chip=0x28158086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M-E (ICH8 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x01fe1028 chip=0x28508086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0x6fa0, size 16, enabled atapci1@pci0:0:31:2: class=0x01018f card=0x01fe1028 chip=0x28288086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M (ICH8 Family) 3 port SATA Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x6eb0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x6eb8, size 4, enabled bar [18] = type I/O Port, range 32, base 0x6ec0, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x6ec8, size 4, enabled bar [20] = type I/O Port, range 32, base 0x6ee0, size 16, enabled bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'Unknown nVidia Quadro FX 570M' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution' class = network bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size 1048576, enabled bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'B57xx Broadcom NetXtreme Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ711EZ1 MemoryCardBus Controller' class = bridge subclass = PCI-CardBus bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217 rev=0x02 hdr=0x00 vendor = 'O2 Micro Inc' device = '0x00f71217 1394 Open Host Controller Interface' class = serial bus subclass = FireWire bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled and follow your intrudction.still pain me :( (++) Using config file: "xorg.conf1" drm0: on vgapci0 info: [drm] Detected an NV50 generation card (0x086900a2) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized nouveau 0.0.12 20060213 error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 drm0: [ITHREAD] info: [drm] Allocating FIFO number 1 error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, invalid/inactiv e channel id 128 info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: [drm] , nSt atus:info: [drm] info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data 0x00000000:0x00 000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000 error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000 info: [drm] nouveau_fifo_alloc: initialised FIFO 1 info: [drm] PFIFO_DMA_PUSHER - Ch 1 (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional informati on. info: [drm] nouveau_fifo_free: freeing fifo 1 error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before d estroy.Prepare for strangeness.. info: [drm] PFIFO_DMA_PUSHER - Ch 127 vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 > >> (II) Loading sub module "int10" >> (II) LoadModule: "int10" >> (II) Loading /usr/local/lib/xorg/modules//libint10.so >> (II) Module int10: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 1.0.0 >> ABI class: X.Org Video Driver, version 5.0 >> (II) NOUVEAU(0): Initializing int10 >> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear >> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear >> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 >> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear >> drmOpenDevice: node name is /dev/dri/card0 >> drmOpenDevice: open result is 10, (OK) >> drmOpenDevice: node name is /dev/dri/card0 >> drmOpenDevice: open result is 10, (OK) >> drmOpenByBusid: Searching for BusID pci:0000:01:00.0 >> drmOpenDevice: node name is /dev/dri/card0 >> drmOpenDevice: open result is 10, (OK) >> drmOpenByBusid: drmOpenMinor returns 10 >> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 >> (II) [drm] DRM interface version 1.2 >> (II) [drm] DRM open master succeeded. >> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 >> (--) NOUVEAU(0): [drm] kernel modesetting not available >> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 >> (II) NOUVEAU(0): Creating default Display subsection in Screen section >> "Default Screen Section" for depth/fbbpp 24/32 >> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 >> (==) NOUVEAU(0): RGB weight 888 >> (==) NOUVEAU(0): Default visual is TrueColor >> (II) Loading sub module "vgahw" >> (II) LoadModule: "vgahw" >> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so >> (II) Module vgahw: vendor="X.Org Foundation" >> compiled for 1.5.99.902, module version = 0.1.0 >> ABI class: X.Org Video Driver, version 5.0 >> (==) NOUVEAU(0): Randr1.2 support enabled >> (==) NOUVEAU(0): Using HW cursor >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear >> (II) UnloadModule: "nouveau" >> (II) UnloadModule: "vgahw" >> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so >> (II) UnloadModule: "int10" >> (II) Unloading /usr/local/lib/xorg/modules//libint10.so >> (EE) Screen(s) found, but none have a usable configuration. >> >> Fatal server error: >> no screens found >> >> Please consult the The X.Org Foundation support >> at http://wiki.x.org >> for help. >> Please also check the log file at "/var/log/Xorg.0.log" for additional information. >> >> From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 12:38:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33157106564A for ; Tue, 24 Mar 2009 12:38:07 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id C21E48FC16 for ; Tue, 24 Mar 2009 12:38:06 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1Lm5tN-00020o-4M; Tue, 24 Mar 2009 13:38:05 +0100 Received: from tb738.t.pppool.de ([89.55.183.56]:45357 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1Lm5tM-0004XZ-TM; Tue, 24 Mar 2009 13:38:05 +0100 Date: Tue, 24 Mar 2009 13:38:03 +0100 From: Gary Jennejohn To: Thomas Vogt Message-ID: <20090324133803.38d6cfd0@ernst.jennejohn.org> In-Reply-To: <49C8BC54.7050504@bsdunix.ch> References: <49C8BC54.7050504@bsdunix.ch> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: /usr/include/wchar.h:216: error: invalid use of 'restrict' in /lib32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 12:38:07 -0000 On Tue, 24 Mar 2009 11:56:20 +0100 Thomas Vogt wrote: > I tried to update my current 64bit intel system from late January to the > latest current code from March 24. > > FreeBSD foo.ch 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Jan 24 13:20:12 > UTC 2009 > > make.conf: > WITH_LIB32=yes > Note that it's MK_LIB32, which is only effective if set to 'no'. Otherwise 32-bit libraries always seem to be built. > make buildworld ends here: > > cc -o make_hash -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. > -I/usr/ob > j/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw > -I/usr/src/lib/ncurses/ncursesw > /../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses > -I/usr/src/lib/ncurses/n > cursesw/../../../contrib/ncurses/include > -I/usr/src/lib/ncurses/ncursesw/../../. > ./contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H > -DFREEBSD_NATIVE -DTERM > IOS -std=gnu99 -DMAIN_PROGRAM > /usr/src/lib/ncurses/ncursesw/../../../contrib/ > ncurses/ncurses/tinfo/comp_hash.c > In file included from ./curses.h:336, > from > /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu > rses/curses.priv.h:259, > from > /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu > rses/tinfo/comp_hash.c:42: > /usr/include/wchar.h:216: error: invalid use of 'restrict' > /usr/include/wchar.h:217: error: invalid use of 'restrict' > *** Error code 1 > > Stop in /usr/src/lib/ncurses/ncursesw. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > Works for me. You might have run csup when the tree was in an intermediate/broken state. Try it again. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 12:41:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02A31065672 for ; Tue, 24 Mar 2009 12:41:00 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 00EEB8FC14 for ; Tue, 24 Mar 2009 12:40:58 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n2OCaN05021642 for ; Tue, 24 Mar 2009 23:06:23 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 24 Mar 2009 23:10:57 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 23:10:57 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 21:40:56 +0900 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n2OBc596003428; Tue, 24 Mar 2009 20:38:05 +0900 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n2OBc4Iu003427; Tue, 24 Mar 2009 20:38:04 +0900 (WST) (envelope-from wilkinsa) Date: Tue, 24 Mar 2009 20:38:04 +0900 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, Mars G Miro Message-ID: <20090324113804.GA3329@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, Mars G Miro References: <20090316033113.GB33369@michelle.cdnetworks.co.kr> <200903191126.15390.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <200903191126.15390.jhb@freebsd.org> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 24 Mar 2009 12:40:56.0659 (UTC) FILETIME=[C7040A30:01C9AC7D] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.6.1016-16538.003 X-TM-AS-Result: No-1.350100-0.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 12:41:01 -0000 0n Thu, Mar 19, 2009 at 11:26:14AM -0400, John Baldwin wrote: >What if you set 'hw.pci.mcfg=0' in loader? John, What does the sysctl "hw.pci.mcfg" do ? #sysctl -d hw.pci.mcfg sysctl: unknown oid 'hw.pci.mcfg' -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 12:49:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE18F1065676 for ; Tue, 24 Mar 2009 12:49:42 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4405C8FC1B for ; Tue, 24 Mar 2009 12:49:42 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n2OCj6PR022318 for ; Tue, 24 Mar 2009 23:15:06 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 24 Mar 2009 23:19:41 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 23:19:40 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 21:49:40 +0900 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n2OBkm5A003522; Tue, 24 Mar 2009 20:46:48 +0900 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n2OBkmZ0003521; Tue, 24 Mar 2009 20:46:48 +0900 (WST) (envelope-from wilkinsa) Date: Tue, 24 Mar 2009 20:46:48 +0900 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, Mars G Miro Message-ID: <20090324114648.GC3329@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, Mars G Miro References: <200903191126.15390.jhb@freebsd.org> <200903201242.09167.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <200903201242.09167.jhb@freebsd.org> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 24 Mar 2009 12:49:40.0162 (UTC) FILETIME=[FF0C4220:01C9AC7E] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.6.1016-16538.003 X-TM-AS-Result: No--1.629400-0.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 12:49:44 -0000 0n Fri, Mar 20, 2009 at 12:42:08PM -0400, John Baldwin wrote: >mcfg is a mechanism for doing faster PCI config access using a memory mapped window. As opposed to what ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:07:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 253091065677 for ; Tue, 24 Mar 2009 15:07:51 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id EC8628FC08 for ; Tue, 24 Mar 2009 15:07:50 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 59E502FAA93; Tue, 24 Mar 2009 11:07:50 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 24 Mar 2009 11:07:50 -0400 X-Sasl-enc: BlUCePLKzMguj2xRelLzZVuYAJLt1wJNwc0zyGMJ15uD 1237907269 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id B9E8F2E1A5; Tue, 24 Mar 2009 11:07:49 -0400 (EDT) Message-ID: <49C8F744.4020405@FreeBSD.org> Date: Tue, 24 Mar 2009 15:07:48 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: freebsd-current@freebsd.org, Mars G Miro References: <200903191126.15390.jhb@freebsd.org> <200903201242.09167.jhb@freebsd.org> <20090324114648.GC3329@stlux503.dsto.defence.gov.au> In-Reply-To: <20090324114648.GC3329@stlux503.dsto.defence.gov.au> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: sk/msk no more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:07:51 -0000 Wilkinson, Alex wrote: > 0n Fri, Mar 20, 2009 at 12:42:08PM -0400, John Baldwin wrote: > > >mcfg is a mechanism for doing faster PCI config access using a memory mapped window. > > As opposed to what ? > As opposed to bit-banging all PCI configuration space accesses through a couple of low ISA I/O space ports (PCI Configuration Mechanism #1... in the PCI SIG specs.) :-) For years PCI was an x86/Intel only thing, architectures which don't have this notion of ISA I/O port space have used memory mapped windows like this for years. cheers, BMS From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:24:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DAD8106567C for ; Tue, 24 Mar 2009 15:24:08 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 867838FC13 for ; Tue, 24 Mar 2009 15:24:07 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2OFO5eW009217 for ; Tue, 24 Mar 2009 16:24:05 +0100 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032416240446:177234 ; Tue, 24 Mar 2009 16:24:04 +0100 Message-ID: <49C8FA92.7020104@entel.upc.edu> Date: Tue, 24 Mar 2009 16:21:54 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> In-Reply-To: <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 16:24:04, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 16:24:05, Serialize complete at 24/03/2009 16:24:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 24 Mar 2009 16:24:05 +0100 (CET) Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:24:09 -0000 Brandon Gooch wrote: > On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: > >> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >> >>> Jung-uk Kim wrote: >>> >>>> With popular demands, I will commit the following patch in next >>>> few days unless a showstopper is found or "over-my-dead-body" >>>> type of review is received. ;-) >>>> >>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >>>> >>>> FYI, it was originally posted here: >>>> >>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >>>> >>>> and here: >>>> >>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >>>> >>>> Please read the original threads for more information about the >>>> patch. >>>> >>> Have just retested this with just updated 8-CURRENT. Still works >>> fine as before with my Acer TM6292 >>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >>> letter just after successful resume. >>> >>> There is still some DRI resume problems (will try one rnoland@ >>> patch tomorrow) and my touch pad does not wakes up for some reason, >>> but that is probably unrelated. >>> >> I went ahead and committed slightly different version. Please resync >> the source if you tested the old version. >> >> Cheers, >> >> Jung-uk Kim >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> > > Hi there, in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it seems is trying to work. It has no xorg, just text console. First got to compile if_bge as a module, kldunloading it before acpiconf -s 3. With if_bge compiled in the kernel I started to see some bge0 : ... PHY read timeout, and then the machine freezed. Then, when resuming I got no video(but the keyboard was working, I was able to echo "Hi there" > /tmp/prova with success!). I tried hw.acpi.reset_video with no success. The other one I tried was debug.acpi.suspend_bounce. No luck. Do you have any alternatives I can try ? Greets, Gus PD : is there any plan to work it to i386 ? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:34:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21FB106566C for ; Tue, 24 Mar 2009 15:34:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from skerryvore.cs.uoguelph.ca (skerryvore.cs.uoguelph.ca [131.104.94.204]) by mx1.freebsd.org (Postfix) with ESMTP id 472508FC14 for ; Tue, 24 Mar 2009 15:34:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by skerryvore.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n2OFYZug021510; Tue, 24 Mar 2009 11:34:35 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n2OFeE006874; Tue, 24 Mar 2009 11:40:14 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 24 Mar 2009 11:40:14 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Matthew West In-Reply-To: <20090323140820.GA37093@zeeb.org> Message-ID: References: <20090323140820.GA37093@zeeb.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.204 Cc: freebsd-current@freebsd.org Subject: Re: panic: Bad link elm, nfsd related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:34:39 -0000 On Mon, 23 Mar 2009, Matthew West wrote: > > 2) What the problem with nfsd is? > Since the crash is inside the new krpc code, you might try building your kernel with "options NFS_LEGACYRPC" and see if the problem persists, then post the results. If the problem goes away, the bug is somewhere in the new krpc code and hopefully Doug Rabson will have some idea w.r.t. fixing it. If the problem persists with "options NFS_LEGACYRPC", then I have no idea what it might be. Good luck with it, rick From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:37:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3211065679 for ; Tue, 24 Mar 2009 15:37:00 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from zeeb.org (zeeb.org [88.198.32.244]) by mx1.freebsd.org (Postfix) with ESMTP id 503028FC17 for ; Tue, 24 Mar 2009 15:37:00 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from mwest by zeeb.org with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lm8fH-000Fjk-UX; Tue, 24 Mar 2009 15:35:43 +0000 Date: Tue, 24 Mar 2009 15:35:43 +0000 From: Matthew West To: TooMany Secrets Message-ID: <20090324153543.GA38824@zeeb.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Matthew West Cc: freebsd-current@freebsd.org Subject: Re: Messages about ffs. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:37:00 -0000 On Sun, Mar 22, 2009 at 12:26:22PM +0100, TooMany Secrets wrote: > Because is my first time running a CURRENT system with witness and > debug options enabled, I don't know if the tty/log obtained messages > are normal or not: Those are lock order reversals (LORs), and are to be expected if you're running a kernel with the WITNESS option enabled. You can read more about it here: http://sources.zabbadoz.net/freebsd/lor.html From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:43:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 520AA1065676 for ; Tue, 24 Mar 2009 15:43:03 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 09F8B8FC14 for ; Tue, 24 Mar 2009 15:43:02 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by gxk24 with SMTP id 24so8924473gxk.19 for ; Tue, 24 Mar 2009 08:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/PjxJqqFYSu8EIADAeMX/E9WxCL3o3HF8Fb60hpNGhE=; b=S0rIMfQM1EAMBqQ1OnvxSH37TSpbbvEXLQQcViifgyXCv4KjlOevYRs7BxkdHqwLj8 +ysbLzC5rnP+O1WLCrsS3FZcGDsYYE7CJq4kyFIJMmWwer4tKHFutbgiY2HfdS6S0X/1 /8AXxwUYS8liEUsSzy4+gIa/Ekg81+y4SGj/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j/pxE3+L/B812ZrQBXR2BjzVGxYhi52DmB8Y//G4PbZ/CO5FO9YxuH1cgZau1x5Gg3 hbcf0LB8B32Uv+Giwv3iWGcpYauXr8i7XufkjAjLbGs207YuKovwY3MuyeYXsQwErmwQ AcLWj35f24e3ABLjAeZ6TlC8cPIxLy9Yue3/c= MIME-Version: 1.0 Received: by 10.100.216.10 with SMTP id o10mr7618393ang.137.1237909372968; Tue, 24 Mar 2009 08:42:52 -0700 (PDT) In-Reply-To: References: <49C80DBA.80407@entel.upc.edu> Date: Tue, 24 Mar 2009 10:42:52 -0500 Message-ID: <790a9fff0903240842k6ab28ab5k1d1a46714fdfe804@mail.gmail.com> From: Scot Hetzel To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gustau Perez , freebsd-current@freebsd.org Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:43:04 -0000 On Mon, Mar 23, 2009 at 10:05 PM, Ben Kelly wrote: > On Mar 23, 2009, at 6:31 PM, Gustau Perez wrote: >> >> a few time ago I switched to current, right now I've it updated to >> yesterday. =A0While compiling some ports (in fact, building x11/gnome2) = I >> found that some of them (written in C) are using =A0some inline function= s (I >> guess it is because the compiler will replace the call to the function w= ith >> the function itself). The problem is that gcc fails with the following >> message : >> =A0 =A0 =A0 =A0 =A0 =A0 error: nested function 'XXX' declared but never = defined >> >> =A0checking the code, the function is declared and then implemented in a >> header file which is included in the offending .c file. The function is >> declared as 'inline'. The only solution I found is to change the definit= ion >> to static. >> >> =A0Checking pontyhat shows me that many ports are failing because of thi= s >> problem. What I can understand is why is this happening, because the sam= e >> ports compiles fine in STABLE and the compilers's version in base seems = to >> be the same (gcc (GCC) 4.2.1 20070719 =A0[FreeBSD], the same in current) >> =A0Can anyone help with this problem ? > > Check out the arch@ discussion about "C99 Inlines" and this commit: > > =A0http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D189824 > > It seems like they might be related. > > Hope that helps. > I can confirm that reverting this change allows the audio/faad port to buil= d. Scot From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 15:55:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2302D106564A for ; Tue, 24 Mar 2009 15:55:58 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw2.sandvine.com (ip59.sandvine.com [64.235.97.59]) by mx1.freebsd.org (Postfix) with ESMTP id ABE298FC19 for ; Tue, 24 Mar 2009 15:55:57 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw2.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 11:23:36 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 5FF5F115D9; Mon, 23 Mar 2009 11:23:36 -0400 (EDT) Date: Mon, 23 Mar 2009 11:23:36 -0400 From: Ed Maste To: Barney Cordoba Message-ID: <20090323152336.GA74200@sandvine.com> Mail-Followup-To: Ed Maste , Barney Cordoba , Scott Long , current@freebsd.org References: <20090318150721.U22014@pooker.samsco.org> <976309.24341.qm@web63902.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <976309.24341.qm@web63902.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 23 Mar 2009 15:23:36.0753 (UTC) FILETIME=[56127210:01C9ABCB] Cc: current@freebsd.org Subject: Re: Interrupt routine usage not shown by top in 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:55:58 -0000 On Sun, Mar 22, 2009 at 03:06:52PM -0700, Barney Cordoba wrote: > I set up a little task that basically does: > > foo_task(){ > > while(1){ > foo_doreceive(); > pause("foo",1); > } > > } > > which wakes hz times per second in 7 and hz/2 times per second in > 8. The same accounting issue exists for this case, as I have it bridging > 400K pps and usage shows 0 most of the time. I've added some firewall > rules which should substantially increase the load, but still no usage. > If I really hammer it, like 600Kpps, it starts registering 30% usage, > with no ramp up in between. I suppose it could be just falling out of the > cache or something, but it doesn't seem realistic. > > Is there some hack I can implement to make sure a task is > accounted for, or some other way to monitor its usage? There are aliasing issues caused by driving the scheduler and the stat clock from the same source. It's particularly bad in our environment at work, so we reverted the clock sharing, and went back to using the i8254 for stats. If you're interested in giving this a try, I've posted the patch at . This is against 6.1 and might have some other minor changes, but the diff is small enough that you could easily apply it by hand as well. If you do try it out let me know what you find. -Ed From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:06:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AF6A10657F2 for ; Tue, 24 Mar 2009 16:06:22 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6C88B8FC29 for ; Tue, 24 Mar 2009 16:06:19 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so1873562ewy.43 for ; Tue, 24 Mar 2009 09:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jmiUYyS96JB7euaGRZeBN2uTLa4SyxbmM/gLSY33LcM=; b=ldwsi+ndZKXSYuuPtHeQbvM5MV3/bFJZ57bMv4yRBI8qr0dXwxal3vuY05Gdhg5a/C Sh+KANIqNjmyHKF6mOOsz2rlc4iJVZ1UQ6ESiaj11Bo4kjrs7NWopjkyy1XJRT6sefLP Mh/DTJHahtqZmCULyZvHT4K4RNESAWak6CyNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qHs6NG7NT8aAKiz3K/jxWfaFDX13v2Jc1UJGOo1RCyKt/IEc7gu2iHKDQY69iOH/le j1xWOHkYiL1ea9/lbnkYPEnBZgmlbNNDaFtDuRHmTb0/YVOs+PFRZcu/kId0PT5F/s3X VFeDkS97lUQPOI5rxoH2AZ/ythWtd4FxOEXJY= MIME-Version: 1.0 Received: by 10.210.38.17 with SMTP id l17mr6424557ebl.51.1237910779304; Tue, 24 Mar 2009 09:06:19 -0700 (PDT) In-Reply-To: <49C8FA92.7020104@entel.upc.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> Date: Tue, 24 Mar 2009 11:06:19 -0500 Message-ID: <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> From: Brandon Gooch To: Gustau Perez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:06:47 -0000 On Tue, Mar 24, 2009 at 10:21 AM, Gustau Perez wrote= : > Brandon Gooch wrote: >> >> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: >> >>> >>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >>> >>>> >>>> Jung-uk Kim wrote: >>>> >>>>> >>>>> With popular demands, I will commit the following patch in next >>>>> few days unless a showstopper is found or "over-my-dead-body" >>>>> type of review is received. ;-) >>>>> >>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >>>>> >>>>> FYI, it was originally posted here: >>>>> >>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >>>>> >>>>> and here: >>>>> >>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >>>>> >>>>> Please read the original threads for more information about the >>>>> patch. >>>>> >>>> >>>> Have just retested this with just updated 8-CURRENT. Still works >>>> fine as before with my Acer TM6292 >>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >>>> letter just after successful resume. >>>> >>>> There is still some DRI resume problems (will try one rnoland@ >>>> patch tomorrow) and my touch pad does not wakes up for some reason, >>>> but that is probably unrelated. >>>> >>> >>> I went ahead and committed slightly different version. =A0Please resync >>> the source if you tested the old version. >>> >>> Cheers, >>> >>> Jung-uk Kim >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> >> >> > > =A0Hi there, > > =A0in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it = seems > is trying to work. It has no xorg, just text console. > > =A0First got to compile if_bge as a module, kldunloading it before acpico= nf -s > 3. With if_bge compiled in the kernel I started to see some bge0 : ... PH= Y > read timeout, and then the machine freezed. > > =A0Then, when resuming I got no video(but the keyboard was working, I was= able > to echo "Hi there" > /tmp/prova with success!). I tried hw.acpi.reset_vid= eo > with no success. The other one I tried was debug.acpi.suspend_bounce. No > luck. > > =A0 Do you have any alternatives I can try ? > > =A0Greets, > > =A0Gus > > =A0PD : is there any plan to work it to =A0i386 ? >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > For now, it seems X is required. The "switch-to-VTY-and-back-again" solution works for me: http://www.freebsd.org/doc/en/articles/laptop/power-management.html In my /etc/rc.suspend: ... /usr/sbin/vidcontrol -s 1 < /dev/console ... In my /etc/rc.resume: ... /usr/sbin/vidcontrol -s 9 < /dev/console ... I've also seen various posts in forums and on mailing lists about using the "vbetool" program (in ports), but I haven't messed with it myself. See here for more detail on this issue (under "Low Priority Tasks"): http://www.freebsd.org/projects/acpi/#todo-list -Brandon From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:08:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DD01065787 for ; Tue, 24 Mar 2009 16:08:42 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id E591C8FC13 for ; Tue, 24 Mar 2009 16:08:41 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n2OG8WHq022821 for ; Tue, 24 Mar 2009 17:08:32 +0100 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032417084036:177872 ; Tue, 24 Mar 2009 17:08:40 +0100 Message-ID: <49C90508.4030500@entel.upc.edu> Date: Tue, 24 Mar 2009 17:06:32 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <49C80DBA.80407@entel.upc.edu> <790a9fff0903240842k6ab28ab5k1d1a46714fdfe804@mail.gmail.com> In-Reply-To: <790a9fff0903240842k6ab28ab5k1d1a46714fdfe804@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 17:08:40, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 17:08:40, Serialize complete at 24/03/2009 17:08:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 24 Mar 2009 17:08:32 +0100 (CET) Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:08:50 -0000 >> >> It seems like they might be related. >> >> >> Hope that helps. >> >> Yes it did. > I can confirm that reverting this change allows the audio/faad port to build. > > Instead of reverting that change, it would be better to change the offeding inline function definition to something like : extern inline [return type|void] __attribute__((gnu_inline)) function_name(arg1,arg2,...) and the function implementation should be the same without the extern. That allowed me to compile compiz-fusion-plugins-main in current and run it. I'm found the problem you faced, but didn't know how to fix it, so I used an static inline definition (which is not the solution). I'm going to try this patch in stable branch (which doesn't need this change). If it works a PR can be send to fix both current and stable without tricks in the makefile. Greets, From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:12:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C63106590C for ; Tue, 24 Mar 2009 16:12:16 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id F1A228FC44 for ; Tue, 24 Mar 2009 16:12:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2OGCEQD025634 for ; Tue, 24 Mar 2009 17:12:14 +0100 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032417121439:177905 ; Tue, 24 Mar 2009 17:12:14 +0100 Message-ID: <49C905DE.1020402@entel.upc.edu> Date: Tue, 24 Mar 2009 17:10:06 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> In-Reply-To: <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 17:12:14, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 17:12:15, Serialize complete at 24/03/2009 17:12:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 24 Mar 2009 17:12:14 +0100 (CET) Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:12:29 -0000 > > For now, it seems X is required. The "switch-to-VTY-and-back-again" > solution works for me: > > http://www.freebsd.org/doc/en/articles/laptop/power-management.html > > In my /etc/rc.suspend: > > ... > /usr/sbin/vidcontrol -s 1 < /dev/console > ... > > In my /etc/rc.resume: > > ... > /usr/sbin/vidcontrol -s 9 < /dev/console > ... > > I've also seen various posts in forums and on mailing lists > about using the "vbetool" program (in ports), but I haven't messed > with it myself. > > See here for more detail on this issue (under "Low Priority Tasks"): > > http://www.freebsd.org/projects/acpi/#todo-list > > -Brandon > Thank you, I'll try it at home (leaving work in a few second ;)) However, what I cannot understand is why if_bge is giving me problems, while I've seen some successful reports of people with the same hard (at least supported by the same driver). Greets, Gus From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:13:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1371065AA1 for ; Tue, 24 Mar 2009 16:13:23 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id BF3BA8FC39 for ; Tue, 24 Mar 2009 16:13:14 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1606291ywh.13 for ; Tue, 24 Mar 2009 09:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GuGIZ5VSVrhiO7IhVmxu/JWlsyhGB8HdaCB0LNQYzF8=; b=LBR9zG7yrewDQCUgqGNnLToxwdi5uG5Lis5uYK4z61WLpb47qZskYHxZNtQJyixIbX bZ1+YnrJNET1ua5SDCq531RVBB9WtHh9E6dPY7viN+PocxlOm9KhyCZbxcaLEEZrhhob gECS4A5zzZJJlqHcjksqg2wLC3JWOS/xX38HM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ED+EUrufL0XJcV8XRXgu3mq3DjibuHmwP7af+G8mfbar/D2qwzBzki/Vl2ookN3csj Nmd8XPhOYtvEOEpu4kwAf7BpZYh4w3ItA/wA4bMvQd73iAoqOs5LRI7rIMjOSkAgTy9N TAmyAGEe6suI7U+OmOntoN4Ou4+rTjkRZ6JxE= MIME-Version: 1.0 Received: by 10.100.132.4 with SMTP id f4mr6776844and.109.1237911194219; Tue, 24 Mar 2009 09:13:14 -0700 (PDT) In-Reply-To: <20090324133803.38d6cfd0@ernst.jennejohn.org> References: <49C8BC54.7050504@bsdunix.ch> <20090324133803.38d6cfd0@ernst.jennejohn.org> Date: Tue, 24 Mar 2009 11:13:14 -0500 Message-ID: <790a9fff0903240913t1f1bc5e6q61fbe80caeb86e34@mail.gmail.com> From: Scot Hetzel To: gary.jennejohn@freenet.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Thomas Vogt Subject: Re: /usr/include/wchar.h:216: error: invalid use of 'restrict' in /lib32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:13:40 -0000 On Tue, Mar 24, 2009 at 7:38 AM, Gary Jennejohn wrote: > On Tue, 24 Mar 2009 11:56:20 +0100 > Thomas Vogt wrote: > >> I tried to update my current 64bit intel system from late January to the >> latest current code from March 24. >> >> FreeBSD foo.ch 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Jan 24 13:20:12 >> UTC 2009 >> >> make.conf: >> WITH_LIB32=yes >> > > Note that it's MK_LIB32, which is only effective if set to 'no'. > Otherwise 32-bit libraries always seem to be built. > The MK_* variables are internal variables for the FreeBSD sources. They are not to be set in /etc/make.conf. Instead you use WITH_* or WITHOUT_* to set the value of the MK_* variables. hp010# make -V MK_LIB32 -DWITHOUT_LIB32 -f Makefile.inc1 no hp010# make -V MK_LIB32 -DWITH_LIB32 -f Makefile.inc1 yes hp010# make -V MK_LIB32 WITH_LIB32=yes -f Makefile.inc1 yes hp010# make -V MK_LIB32 WITH_LIB32=no -f Makefile.inc1 yes Note: WITH_LIB32=no will still build the LIB32 libraries, use WITHOUT_LIB32 to not build LIB32. Scot From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:35:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BD871065ED5 for ; Tue, 24 Mar 2009 16:35:01 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id E48BA8FC1E for ; Tue, 24 Mar 2009 16:35:00 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so419868eyf.7 for ; Tue, 24 Mar 2009 09:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e0pHEDgjtzDWiUogLEv9OMjgwkYKUH/hucYYrk5ePu4=; b=JXjmErle2tvGIpNZ3kvC/IQ9VNduTLf5p9v0U5wG3RDORv6UHqZWUWPUju2YrfO/v3 MsmZJV2y3SNusmcNQrDixkd4MR9zHtaly/iZGedafma7yEoHni8WcnI/fn4SuBlobdak /EHl3v44f0Db40+S4ib6f95EAWZTaxvtXnz6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cUF6SUFHVKKwS6uL5tYXWll83iUPYxvEGjFGKkgHyGtovbt2CpX+0dUwyUYsgEu5WA C58fXKSRawmkaDho9qNMATrRWP9LMgnFK8L2DOZQVCP2HvTo1kf/SLdDpEZG23Z6olgc x99EPhhjEUnX9Ts5IBIfIEiysLCpdBQkiYeUY= MIME-Version: 1.0 Received: by 10.210.115.17 with SMTP id n17mr6437483ebc.43.1237912499868; Tue, 24 Mar 2009 09:34:59 -0700 (PDT) In-Reply-To: <49C905DE.1020402@entel.upc.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> <49C905DE.1020402@entel.upc.edu> Date: Tue, 24 Mar 2009 11:34:59 -0500 Message-ID: <179b97fb0903240934k762b010n4e51e1a28c9e8a82@mail.gmail.com> From: Brandon Gooch To: Gustau Perez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:35:10 -0000 On Tue, Mar 24, 2009 at 11:10 AM, Gustau Perez wrote= : > >> >> For now, it seems X is required. The "switch-to-VTY-and-back-again" >> solution works for me: >> >> http://www.freebsd.org/doc/en/articles/laptop/power-management.html >> >> In my /etc/rc.suspend: >> >> ... >> /usr/sbin/vidcontrol -s 1 < /dev/console >> ... >> >> In my /etc/rc.resume: >> >> ... >> /usr/sbin/vidcontrol -s 9 < /dev/console >> ... >> >> I've also seen various posts in forums and on mailing lists >> about using the "vbetool" program (in ports), but I haven't messed >> with it myself. >> >> See here for more detail on this issue (under "Low Priority Tasks"): >> >> http://www.freebsd.org/projects/acpi/#todo-list >> >> -Brandon >> > > =A0Thank you, =A0I'll try it at home (leaving work in a few second ;)) Ho= wever, > what I cannot understand is why if_bge is giving me problems, while I've > seen some successful reports of people with the same hard (at least > supported by the same driver). > > =A0Greets, > > =A0Gus > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > Well, I just went through a suspend/resume cycle on my notebook without the 'vidcontrol' statements in my /etc/rc.* (from Xorg) and my display lit right up! I guess I no longer require the VTY switch to save the video state as I once did... -Brandon From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:35:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10191066255 for ; Tue, 24 Mar 2009 16:35:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7388FC2E for ; Tue, 24 Mar 2009 16:35:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DD8052FC3DD; Tue, 24 Mar 2009 12:35:37 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 24 Mar 2009 12:35:37 -0400 X-Sasl-enc: /eRI2+9etBvfHppV+VJLoQBueCcpfQHZo5ntvSyI0xSL 1237912537 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 45AC64DDAF; Tue, 24 Mar 2009 12:35:37 -0400 (EDT) Message-ID: <49C90BD7.6010009@FreeBSD.org> Date: Tue, 24 Mar 2009 16:35:35 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Pierre Guinoiseau References: <49C819BB.4090100@poildetroll.net> In-Reply-To: <49C819BB.4090100@poildetroll.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic with IGMPv3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:35:46 -0000 Resolved in svn rev 190354, thanks for catching! From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 16:45:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8122F106579E; Tue, 24 Mar 2009 16:45:52 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from tritus.poildetroll.net (tritus.poildetroll.net [81.93.245.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3BEC88FC12; Tue, 24 Mar 2009 16:45:52 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from Korriban.poildetroll.net (par69-2-82-67-29-130.fbx.proxad.net [82.67.29.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tritus.poildetroll.net (Postfix) with ESMTPSA id 4268D391; Tue, 24 Mar 2009 17:46:34 +0100 (CET) Message-ID: <49C90E27.4050203@poildetroll.net> Date: Tue, 24 Mar 2009 17:45:27 +0100 From: Pierre Guinoiseau Organization: Poil de Troll User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <49C819BB.4090100@poildetroll.net> <49C90BD7.6010009@FreeBSD.org> In-Reply-To: <49C90BD7.6010009@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig149178CD06A24BD5FD32AA9D" Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic with IGMPv3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:45:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig149178CD06A24BD5FD32AA9D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you too! :) Bruce M. Simpson wrote: > Resolved in svn rev 190354, thanks for catching! >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --------------enig149178CD06A24BD5FD32AA9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJDjwACgkQJikNJSAyef+kMwCguH/0GNaKXDjXB0fXchMx4Age RQoAoIRDclu/uCqSutIm8OZYZTOuDfeQ =Fyk5 -----END PGP SIGNATURE----- --------------enig149178CD06A24BD5FD32AA9D-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 18:15:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD2E91065678 for ; Tue, 24 Mar 2009 18:15:07 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6E78FC16 for ; Tue, 24 Mar 2009 18:15:07 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 79F06151751; Tue, 24 Mar 2009 20:04:38 +0200 (EET) Date: Tue, 24 Mar 2009 20:04:38 +0200 From: Jaakko Heinonen To: Matthew West Message-ID: <20090324180437.GA952@a91-153-125-115.elisa-laajakaista.fi> References: <20090323140820.GA37093@zeeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090323140820.GA37093@zeeb.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 7ogcg7g02@sneakemail.com, freebsd-current@freebsd.org Subject: Re: panic: Bad link elm, nfsd related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:15:08 -0000 On 2009-03-23, Matthew West wrote: > After 1-2 weeks, the system will panic with the following: > > ---------- > panic: Bad link elm 0xffffff0011febc00 next->prev != elm It looks like an attempt to remove xprt twice from tail queue due to race. Does this patch make any difference? %%% Index: sys/rpc/svc.c =================================================================== --- sys/rpc/svc.c (revision 189918) +++ sys/rpc/svc.c (working copy) @@ -296,8 +296,10 @@ xprt_unregister_locked(SVCXPRT *xprt) TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); xprt->xp_active = FALSE; } - TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); - xprt->xp_registered = FALSE; + if (xprt->xp_registered) { + TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); + xprt->xp_registered = FALSE; + } } void %%% This was also reported by Edward Fisk (Cc'd) in PR 132068. -- Jaakko From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 18:55:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBCEA10656C6 for ; Tue, 24 Mar 2009 18:55:49 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6B48FC17 for ; Tue, 24 Mar 2009 18:55:49 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2OIsMVj021911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 14:54:22 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Gustau Perez In-Reply-To: <49C8FA92.7020104@entel.upc.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tAk6r09UtkRX7ls4bR2N" Organization: FreeBSD Date: Tue, 24 Mar 2009 13:55:18 -0500 Message-Id: <1237920918.1859.1.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:55:53 -0000 --=-tAk6r09UtkRX7ls4bR2N Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: > Brandon Gooch wrote: > > On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: > > =20 > >> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >> =20 > >>> Jung-uk Kim wrote: > >>> =20 > >>>> With popular demands, I will commit the following patch in next > >>>> few days unless a showstopper is found or "over-my-dead-body" > >>>> type of review is received. ;-) > >>>> > >>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >>>> > >>>> FYI, it was originally posted here: > >>>> > >>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >>>> > >>>> and here: > >>>> > >>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >>>> > >>>> Please read the original threads for more information about the > >>>> patch. > >>>> =20 > >>> Have just retested this with just updated 8-CURRENT. Still works > >>> fine as before with my Acer TM6292 > >>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >>> letter just after successful resume. > >>> > >>> There is still some DRI resume problems (will try one rnoland@ > >>> patch tomorrow) and my touch pad does not wakes up for some reason, > >>> but that is probably unrelated. > >>> =20 > >> I went ahead and committed slightly different version. Please resync > >> the source if you tested the old version. > >> > >> Cheers, > >> > >> Jung-uk Kim > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > >> > >> =20 > > > > =20 > Hi there, >=20 > in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it=20 > seems is trying to work. It has no xorg, just text console. The D630 should have an Intel 965GM in it with suspend/resume support in drm, so X *should* be good to go. robert. > First got to compile if_bge as a module, kldunloading it before=20 > acpiconf -s 3. With if_bge compiled in the kernel I started to see some=20 > bge0 : ... PHY read timeout, and then the machine freezed. >=20 > Then, when resuming I got no video(but the keyboard was working, I=20 > was able to echo "Hi there" > /tmp/prova with success!). I tried=20 > hw.acpi.reset_video with no success. The other one I tried was=20 > debug.acpi.suspend_bounce. No luck. >=20 > Do you have any alternatives I can try ? >=20 > Greets, >=20 > Gus >=20 > PD : is there any plan to work it to i386 ? > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > =20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-tAk6r09UtkRX7ls4bR2N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknJLJYACgkQM4TrQ4qfROOY+QCfTXY2tuz0RS2DknVWV7tySJup pLUAn0D9HLymK8HuUxuocKupQu/XjtjM =ImNO -----END PGP SIGNATURE----- --=-tAk6r09UtkRX7ls4bR2N-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:02:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FD910656C5 for ; Tue, 24 Mar 2009 19:02:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 919438FC14 for ; Tue, 24 Mar 2009 19:02:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2OJ1QFw021989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 15:01:26 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <179b97fb0903240906w19629407u36fb737348f2a41e@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-mNS+hGhHQH9zJXsdDkUo" Organization: FreeBSD Date: Tue, 24 Mar 2009 14:02:22 -0500 Message-Id: <1237921342.1859.4.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Gustau Perez , freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:02:54 -0000 --=-mNS+hGhHQH9zJXsdDkUo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 11:06 -0500, Brandon Gooch wrote: > On Tue, Mar 24, 2009 at 10:21 AM, Gustau Perez wro= te: > > Brandon Gooch wrote: > >> > >> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: > >> > >>> > >>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >>> > >>>> > >>>> Jung-uk Kim wrote: > >>>> > >>>>> > >>>>> With popular demands, I will commit the following patch in next > >>>>> few days unless a showstopper is found or "over-my-dead-body" > >>>>> type of review is received. ;-) > >>>>> > >>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >>>>> > >>>>> FYI, it was originally posted here: > >>>>> > >>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >>>>> > >>>>> and here: > >>>>> > >>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >>>>> > >>>>> Please read the original threads for more information about the > >>>>> patch. > >>>>> > >>>> > >>>> Have just retested this with just updated 8-CURRENT. Still works > >>>> fine as before with my Acer TM6292 > >>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >>>> letter just after successful resume. > >>>> > >>>> There is still some DRI resume problems (will try one rnoland@ > >>>> patch tomorrow) and my touch pad does not wakes up for some reason, > >>>> but that is probably unrelated. > >>>> > >>> > >>> I went ahead and committed slightly different version. Please resync > >>> the source if you tested the old version. > >>> > >>> Cheers, > >>> > >>> Jung-uk Kim > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to > >>> "freebsd-current-unsubscribe@freebsd.org" > >>> > >>> > >> > >> > > > > Hi there, > > > > in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it = seems > > is trying to worOn Tue, 2009-03-24 at 11:06 -0500, Brandon Gooch wrote: On Tue, Mar 24, 2009 at 10:21 AM, Gustau Perez wrote: > > Brandon Gooch wrote: > >> > >> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: > >> > >>> > >>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >>> > >>>> > >>>> Jung-uk Kim wrote: > >>>> > >>>>> > >>>>> With popular demands, I will commit the following patch in next > >>>>> few days unless a showstopper is found or "over-my-dead-body" > >>>>> type of review is received. ;-) > >>>>> > >>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >>>>> > >>>>> FYI, it was originally posted here: > >>>>> > >>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >>>>> > >>>>> and here: > >>>>> > >>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >>>>> > >>>>> Please read the original threads for more information about the > >>>>> patch. > >>>>> > >>>> > >>>> Have just retested this with just updated 8-CURRENT. Still works > >>>> fine as before with my Acer TM6292 > >>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >>>> letter just after successful resume. > >>>> > >>>> There is still some DRI resume problems (will try one rnoland@ > >>>> patch tomorrow) and my touch pad does not wakes up for some reason, > >>>> but that is probably unrelated. > >>>> > >>> > >>> I went ahead and committed slightly different version. Please resync > >>> the source if you tested the old version. > >>> > >>> Cheers, > >>> > >>> Jung-uk Kim > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to > >>> "freebsd-current-unsubscribe@freebsd.org" > >>> > >>> > >> > >> > > > > Hi there, > > > > in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it seems > > is trying to wor > k. It has no xorg, just text console. > > > > First got to compile if_bge as a module, kldunloading it before acpico= nf -s > > 3. With if_bge compiled in the kernel I started to see some bge0 : ... = PHY > > read timeout, and then the machine freezed. > > > > Then, when resuming I got no video(but the keyboard was working, I was= able > > to echo "Hi there" > /tmp/prova with success!). I tried hw.acpi.reset_v= ideo > > with no success. The other one I tried was debug.acpi.suspend_bounce. N= o > > luck. > > > > Do you have any alternatives I can try ? > > > > Greets, > > > > Gus > > > > PD : is there any plan to work it to i386 ? > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > >> > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > >=20 > For now, it seems X is required. The "switch-to-VTY-and-back-again" > solution works for me: Yes, drm has all the magic to save off the card state pre/post suspend. robert. > http://www.freebsd.org/doc/en/articles/laptop/power-management.html >=20 > In my /etc/rc.suspend: >=20 > ... > /usr/sbin/vidcontrol -s 1 < /dev/console > ... >=20 > In my /etc/rc.resume: >=20 > ... > /usr/sbin/vidcontrol -s 9 < /dev/console > ... >=20 > I've also seen various posts in forums and on mailing lists > about using the "vbetool" program (in ports), but I haven't messed > with it myself. >=20 > See here for more detail on this issue (under "Low Priority Tasks"): >=20 > http://www.freebsd.org/projects/acpi/#todo-list >=20 > -Brandon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-mNS+hGhHQH9zJXsdDkUo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknJLj4ACgkQM4TrQ4qfROOUawCbBAwbI8wU3nVOTtwnCbvy4l/F VUIAnAmVFgotyxjWp7zlLRRrCWqf56F9 =d6If -----END PGP SIGNATURE----- --=-mNS+hGhHQH9zJXsdDkUo-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:10:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 324241065673 for ; Tue, 24 Mar 2009 19:10:34 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id ACB578FC23 for ; Tue, 24 Mar 2009 19:10:33 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n2OJANGq006107 for ; Tue, 24 Mar 2009 20:10:24 +0100 Received: from [192.168.100.184] ([88.11.103.61]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032420103134:179555 ; Tue, 24 Mar 2009 20:10:31 +0100 Message-ID: <49C92FA6.20608@entel.upc.edu> Date: Tue, 24 Mar 2009 20:08:22 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> In-Reply-To: <1237920918.1859.1.camel@balrog.2hip.net> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 20:10:31, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 20:10:32, Serialize complete at 24/03/2009 20:10:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 24 Mar 2009 20:10:24 +0100 (CET) Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:10:34 -0000 Robert Noland wrote: > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: > >> Brandon Gooch wrote: >> >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: >>> >>> >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >>>> >>>> >>>>> Jung-uk Kim wrote: >>>>> >>>>> >>>>>> With popular demands, I will commit the following patch in next >>>>>> few days unless a showstopper is found or "over-my-dead-body" >>>>>> type of review is received. ;-) >>>>>> >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >>>>>> >>>>>> FYI, it was originally posted here: >>>>>> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >>>>>> >>>>>> and here: >>>>>> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >>>>>> >>>>>> Please read the original threads for more information about the >>>>>> patch. >>>>>> >>>>>> >>>>> Have just retested this with just updated 8-CURRENT. Still works >>>>> fine as before with my Acer TM6292 >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >>>>> letter just after successful resume. >>>>> >>>>> There is still some DRI resume problems (will try one rnoland@ >>>>> patch tomorrow) and my touch pad does not wakes up for some reason, >>>>> but that is probably unrelated. >>>>> >>>>> >>>> I went ahead and committed slightly different version. Please resync >>>> the source if you tested the old version. >>>> >>>> Cheers, >>>> >>>> Jung-uk Kim >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>>> >>>> >>> >>> >> Hi there, >> >> in my Latitude D630 with 8-0 current updated this morning (+1 UTC) it >> seems is trying to work. It has no xorg, just text console. >> > > The D630 should have an Intel 965GM in it with suspend/resume support in > drm, so X *should* be good to go. > > robert. > > Hi Roland, this one comes with an nvidia Quadro NVS 135M (I think they made two o three different models). It was possible to customize them via web. My mistake was to choose an nvidia (well, I've been able to play nice games with it, but now it's giving me a lot of headaches). With this model (without X's, just text console) suspending and resuming seems to work except the video. I can type thing and send them to a file (checked). After resuming, it throws a little of text (i can see some debug about suspending and resuming firewire and usb) and then video is lost. With if_bge within the kernel I don't get that semi-successful result. It starts complaining about PHY read/write timeout so I have it as a module. Offtopic : In the other hand right now I'm going to try the patch you sent to use nouveau in i386 mode (not amd64, I have a separate partition for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko before leaving to home (and I worked). Will let you now my results in the Take two thread :) Greets, Gus >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:13:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364B9106568E for ; Tue, 24 Mar 2009 19:13:21 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 168F98FC08 for ; Tue, 24 Mar 2009 19:13:20 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 1865A130C3C for ; Tue, 24 Mar 2009 19:55:31 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4flKKFQ7REZ for ; Tue, 24 Mar 2009 19:55:28 +0100 (CET) Received: from wedge.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP for ; Tue, 24 Mar 2009 19:55:28 +0100 (CET) Message-ID: <49C92C9F.4050000@madpilot.net> Date: Tue, 24 Mar 2009 19:55:27 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: wpa_supplicant can't associate with WPA2 AP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:13:21 -0000 Hello. I installed FreeBSD-current on my laptop recently, machine used to run 7.1 without problems, and worked flawlessly with my AP using WPA2+PSK. The PC is a Dell inspiron 8600 laptop with an intel 2100 wifi card (ipw driver). The AP I'm trying to connect to has ssid "LILLIPUT". After installing current I modified my configuration for the new wlan interface cloning order and tried to associate as usual, but am now getting errors in the preauth phase and wpa_supplicant just loops around the problem. This is the debugging output from WPA supplicant (it's a bit long, I know...) root@anakin:~ [0]# wpa_supplicant -dd -i wlan0 -c /etc/wpa_supplicant.conf Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'default' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ap_scan=1 Line: 3 - start of a new network block ssid - hexdump_ascii(len=8): 4c 49 4c 4c 49 50 55 54 LILLIPUT PSK (ASCII passphrase) - hexdump_ascii(len=22): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Priority group 0 id=0 ssid='LILLIPUT' Initializing interface (2) 'wlan0' Own MAC address: 00:0c:f1:37:58:b7 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) EAPOL: disable timer tick Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 selected based on RSN IE selected WPA AP 00:14:6c:e0:ee:e6 ssid='LILLIPUT' Trying to associate with 00:14:6c:e0:ee:e6 (SSID='LILLIPUT' freq=2422 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'LILLIPUT' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag Authentication with 00:14:6c:e0:ee:e6 timed out. Added BSSID 00:14:6c:e0:ee:e6 into blacklist No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - EAP success=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 selected based on RSN IE selected WPA AP 00:14:6c:e0:ee:e6 ssid='LILLIPUT' Trying to associate with 00:14:6c:e0:ee:e6 (SSID='LILLIPUT' freq=2422 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'LILLIPUT' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag Authentication with 00:14:6c:e0:ee:e6 timed out. BSSID 00:14:6c:e0:ee:e6 blacklist count incremented to 2 No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - EAP success=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 skip - blacklisted 1: 00:18:02:84:e4:81 ssid='Alice-91589054' wpa_ie_len=22 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:1c:a2:58:ff:7b ssid='Alice-57582990' wpa_ie_len=24 rsn_ie_len=0 caps=0x11 skip - SSID mismatch Try to find non-WPA AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 skip - blacklisted 1: 00:18:02:84:e4:81 ssid='Alice-91589054' wpa_ie_len=22 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:1c:a2:58:ff:7b ssid='Alice-57582990' wpa_ie_len=24 rsn_ie_len=0 caps=0x11 skip - SSID mismatch No APs found - clear blacklist and try again Removed BSSID 00:14:6c:e0:ee:e6 from blacklist (clear) Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 selected based on RSN IE selected WPA AP 00:14:6c:e0:ee:e6 ssid='LILLIPUT' Trying to associate with 00:14:6c:e0:ee:e6 (SSID='LILLIPUT' freq=2422 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'LILLIPUT' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag Authentication with 00:14:6c:e0:ee:e6 timed out. Added BSSID 00:14:6c:e0:ee:e6 into blacklist No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - EAP success=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 selected based on RSN IE selected WPA AP 00:14:6c:e0:ee:e6 ssid='LILLIPUT' Trying to associate with 00:14:6c:e0:ee:e6 (SSID='LILLIPUT' freq=2422 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'LILLIPUT' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag Authentication with 00:14:6c:e0:ee:e6 timed out. BSSID 00:14:6c:e0:ee:e6 blacklist count incremented to 2 No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - EAP success=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 skip - blacklisted 1: 00:18:02:84:e4:81 ssid='Alice-91589054' wpa_ie_len=22 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:1c:a2:58:ff:7b ssid='Alice-57582990' wpa_ie_len=24 rsn_ie_len=0 caps=0x11 skip - SSID mismatch Try to find non-WPA AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 skip - blacklisted 1: 00:18:02:84:e4:81 ssid='Alice-91589054' wpa_ie_len=22 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:1c:a2:58:ff:7b ssid='Alice-57582990' wpa_ie_len=24 rsn_ie_len=0 caps=0x11 skip - SSID mismatch No APs found - clear blacklist and try again Removed BSSID 00:14:6c:e0:ee:e6 from blacklist (clear) Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:e0:ee:e6 ssid='LILLIPUT' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 selected based on RSN IE selected WPA AP 00:14:6c:e0:ee:e6 ssid='LILLIPUT' Trying to associate with 00:14:6c:e0:ee:e6 (SSID='LILLIPUT' freq=2422 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'LILLIPUT' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag ^CCTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Failed to disable WPA in the driver. wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=2 privacy=0 ELOOP: remaining socket: sock=4 eloop_data=0x28406140 user_data=0x2840e040 handler=0x806a2a0 I indented the error messages. here are the relevant configurations, wpa_supplicant.conf: ap_scan=1 network={ ssid="LILLIPUT" psk="secret" } and excerpt from rc.conf: wlans_ipw0="wlan0" create_args_wlan0="wlanmode sta country IT" ifconfig_wlan0="WPA DHCP" I dug around the sources and tried modifying the file src/contrib/wpa/src/rsn_supp/preauth.c, in the function rsn_preauth_scan_results to return true for the last argument of pmksa_candidate_add, but it just gives me another error about not being in the correct state for pre-auth. I don't know much about the internals of wifi security or adapters, so I could not try much more, and google was of very little help. I don't really know what the problem is, but what looks strange to me is that this same PC was working fine with this same AP and same config with 7.1. Anyone has some pointers for what to look at? Does this need debugging? Thanks to anyone willing to help! -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:28:43 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6A1D61065675; Tue, 24 Mar 2009 19:28:42 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 24 Mar 2009 15:28:30 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> In-Reply-To: <49C92FA6.20608@entel.upc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_iRTyJQEFK+JQZPC" Message-Id: <200903241528.34902.jkim@FreeBSD.org> Cc: Gustau Perez Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:28:44 -0000 --Boundary-00=_iRTyJQEFK+JQZPC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 24 March 2009 03:08 pm, Gustau Perez wrote: > With this model (without X's, just text console) suspending and > resuming seems to work except the video. I can type thing and send > them to a file (checked). After resuming, it throws a little of > text (i can see some debug about suspending and resuming firewire > and usb) and then video is lost. Please try the attached patch, which just disables restoring VGA state while resuming. Jung-uk Kim --Boundary-00=_iRTyJQEFK+JQZPC Content-Type: text/plain; charset="iso-8859-1"; name="vga_isa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vga_isa.diff" --- sys/isa/vga_isa.c 29 Dec 2007 23:26:59 -0000 1.35 +++ sys/isa/vga_isa.c 24 Mar 2009 19:25:56 -0000 @@ -160,6 +160,7 @@ isavga_attach(device_t dev) return 0; } +#if 0 static int isavga_suspend(device_t dev) { @@ -209,6 +210,7 @@ isavga_resume(device_t dev) bus_generic_resume(dev); return 0; } +#endif #ifdef FB_INSTALL_CDEV @@ -254,8 +256,10 @@ static device_method_t isavga_methods[] DEVMETHOD(device_identify, isavga_identify), DEVMETHOD(device_probe, isavga_probe), DEVMETHOD(device_attach, isavga_attach), +#if 0 DEVMETHOD(device_suspend, isavga_suspend), DEVMETHOD(device_resume, isavga_resume), +#endif DEVMETHOD(bus_print_child, bus_generic_print_child), { 0, 0 } --Boundary-00=_iRTyJQEFK+JQZPC-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:33:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 836D7106588C for ; Tue, 24 Mar 2009 19:33:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9B97D8FC23 for ; Tue, 24 Mar 2009 19:33:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2OJXElE037165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 12:33:14 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49C9357A.8000609@freebsd.org> Date: Tue, 24 Mar 2009 12:33:14 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Guido Falsi References: <49C92C9F.4050000@madpilot.net> In-Reply-To: <49C92C9F.4050000@madpilot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant can't associate with WPA2 AP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:33:25 -0000 Guido Falsi wrote: > and excerpt from rc.conf: > > wlans_ipw0="wlan0" > create_args_wlan0="wlanmode sta country IT" > ifconfig_wlan0="WPA DHCP" Unfortunately the vap conversion of the ipw driver never was completed (it's the only driver in the tree that is known to be totally broken). It's on my todo list for 8.0 but would happily defer to someone else :). I'm actually surprised you got this far. Sam From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:36:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B74106576E for ; Tue, 24 Mar 2009 19:36:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id A2D418FC2B for ; Tue, 24 Mar 2009 19:36:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2OJZMZv022197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 15:35:22 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Gustau Perez In-Reply-To: <49C92FA6.20608@entel.upc.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1U8EJYjxfUn5zJfzTi+i" Organization: FreeBSD Date: Tue, 24 Mar 2009 14:36:18 -0500 Message-Id: <1237923378.1859.11.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:36:51 -0000 --=-1U8EJYjxfUn5zJfzTi+i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote: > Robert Noland wrote: > > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: > > =20 > >> Brandon Gooch wrote: > >> =20 > >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote= : > >>> =20 > >>> =20 > >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >>>> =20 > >>>> =20 > >>>>> Jung-uk Kim wrote: > >>>>> =20 > >>>>> =20 > >>>>>> With popular demands, I will commit the following patch in next > >>>>>> few days unless a showstopper is found or "over-my-dead-body" > >>>>>> type of review is received. ;-) > >>>>>> > >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >>>>>> > >>>>>> FYI, it was originally posted here: > >>>>>> > >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >>>>>> > >>>>>> and here: > >>>>>> > >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >>>>>> > >>>>>> Please read the original threads for more information about the > >>>>>> patch. > >>>>>> =20 > >>>>>> =20 > >>>>> Have just retested this with just updated 8-CURRENT. Still works > >>>>> fine as before with my Acer TM6292 > >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >>>>> letter just after successful resume. > >>>>> > >>>>> There is still some DRI resume problems (will try one rnoland@ > >>>>> patch tomorrow) and my touch pad does not wakes up for some reason, > >>>>> but that is probably unrelated. > >>>>> =20 > >>>>> =20 > >>>> I went ahead and committed slightly different version. Please resyn= c > >>>> the source if you tested the old version. > >>>> > >>>> Cheers, > >>>> > >>>> Jung-uk Kim > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" > >>>> > >>>> =20 > >>>> =20 > >>> =20 > >>> =20 > >> Hi there, > >> > >> in my Latitude D630 with 8-0 current updated this morning (+1 UTC) = it=20 > >> seems is trying to work. It has no xorg, just text console. > >> =20 > > > > The D630 should have an Intel 965GM in it with suspend/resume support i= n > > drm, so X *should* be good to go. > > > > robert. > > > > =20 > Hi Roland, >=20 > this one comes with an nvidia Quadro NVS 135M (I think they made two=20 > o three different models). It was possible to customize them via web. My=20 > mistake was to choose an nvidia (well, I've been able to play nice games=20 > with it, but now it's giving me a lot of headaches). Help is coming...=20 > With this model (without X's, just text console) suspending and=20 > resuming seems to work except the video. I can type thing and send them=20 > to a file (checked). After resuming, it throws a little of text (i can=20 > see some debug about suspending and resuming firewire and usb) and then=20 > video is lost. With if_bge within the kernel I don't get that=20 > semi-successful result. It starts complaining about PHY read/write=20 > timeout so I have it as a module. >=20 > Offtopic : In the other hand right now I'm going to try the patch you=20 > sent to use nouveau in i386 mode (not amd64, I have a separate partition=20 > for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko=20 > before leaving to home (and I worked). Will let you now my results in=20 > the Take two thread :) Cool, it should work fine on amd64 as well. That is what I'm running on now. Just make sure that you have libdrm and nouveau driver from git. Looking forward to success reports. robert. > Greets, >=20 > Gus > =20 > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > >> =20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-1U8EJYjxfUn5zJfzTi+i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknJNjIACgkQM4TrQ4qfRONGqACcCZkI65F2npMD9pHEzhaXatGs txoAoIBsLHqQcbvEfvb4hjt67EoUHesB =uifJ -----END PGP SIGNATURE----- --=-1U8EJYjxfUn5zJfzTi+i-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:52:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4B8710656C8 for ; Tue, 24 Mar 2009 19:52:16 +0000 (UTC) (envelope-from cenixxx@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 417D98FC1B for ; Tue, 24 Mar 2009 19:52:15 +0000 (UTC) (envelope-from cenixxx@gmail.com) Received: by bwz8 with SMTP id 8so2255667bwz.43 for ; Tue, 24 Mar 2009 12:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RoeEmC2P2sNbEgwK95OkiSC6qRZ38bYz0auCdiq7e7U=; b=N0GISR2/E/peLfBbFby71sETiYY41XxmO204raS8+RNfJNdva8KmSickzhLj8m2FLr eWBsSNAzvB5Qn1WAV68JE9XVmCs90vX8aLVd3uJlcOBamxrj8POnruYqrverPEKDjDnW xXY+7oEQVoggpZsBumY/mHHtAOLQU56XaSEwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=llvKZ0y3SmJ4Z+Oby0QSDFA4/6idQHRBOmDluag5IBqt7P+Kx477hC1g60a0qstuPX Mnk8812p1L6KqdTrCqXqCzXxk//2l/zGc6+e1B6LAJ8PgIRTr+yfP+Y5kJYLagmTghxH dH2eeZqv/r9YOojLS5IOHJFbSWiJ36e3Uo/Q0= MIME-Version: 1.0 Received: by 10.86.100.16 with SMTP id x16mr4919441fgb.68.1237923093255; Tue, 24 Mar 2009 12:31:33 -0700 (PDT) Date: Tue, 24 Mar 2009 21:31:33 +0200 Message-ID: <5d97c6ec0903241231x73998539x1f8b52dcb75e3826@mail.gmail.com> From: Nikolay Antsiferov To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dougb@freebsd.org Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:52:19 -0000 Hello. Yesterday i use mergemaster -F option after installworld. Worked good for me. All files that differ only by cvs tag were replaced. I update from 8.0-CURRENT-200902 to head sources. Thanks. -- best regards, cenix. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:56:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B9210657DB for ; Tue, 24 Mar 2009 19:56:21 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAF28FC19 for ; Tue, 24 Mar 2009 19:56:21 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 34B525D39; Tue, 24 Mar 2009 20:56:20 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ij5Y+4t8-xcq; Tue, 24 Mar 2009 20:56:18 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 1F5995D33; Tue, 24 Mar 2009 20:56:18 +0100 (CET) Message-Id: From: Thomas Vogt To: gary.jennejohn@freenet.de In-Reply-To: <20090324133803.38d6cfd0@ernst.jennejohn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 20:56:17 +0100 References: <49C8BC54.7050504@bsdunix.ch> <20090324133803.38d6cfd0@ernst.jennejohn.org> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: /usr/include/wchar.h:216: error: invalid use of 'restrict' in /lib32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:56:22 -0000 Hi Am 24.03.2009 um 13:38 schrieb Gary Jennejohn: > On Tue, 24 Mar 2009 11:56:20 +0100 > Thomas Vogt wrote: > >> I tried to update my current 64bit intel system from late January >> to the >> latest current code from March 24. >> >> FreeBSD foo.ch 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Jan 24 >> 13:20:12 >> UTC 2009 >> >> make.conf: >> WITH_LIB32=yes >> > > Note that it's MK_LIB32, which is only effective if set to 'no'. > Otherwise 32-bit libraries always seem to be built. Thanks. Didn't know that. > > >> make buildworld ends here: >> >> cc -o make_hash -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC - >> I. >> -I/usr/ob >> j/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw >> -I/usr/src/lib/ncurses/ncursesw >> /../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses >> -I/usr/src/lib/ncurses/n >> cursesw/../../../contrib/ncurses/include >> -I/usr/src/lib/ncurses/ncursesw/../../. >> ./contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H >> -DFREEBSD_NATIVE -DTERM >> IOS -std=gnu99 -DMAIN_PROGRAM >> /usr/src/lib/ncurses/ncursesw/../../../contrib/ >> ncurses/ncurses/tinfo/comp_hash.c >> In file included from ./curses.h:336, >> from >> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu >> rses/curses.priv.h:259, >> from >> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncu >> rses/tinfo/comp_hash.c:42: >> /usr/include/wchar.h:216: error: invalid use of 'restrict' >> /usr/include/wchar.h:217: error: invalid use of 'restrict' >> *** Error code 1 >> >> Stop in /usr/src/lib/ncurses/ncursesw. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> > > Works for me. You might have run csup when the tree was in an > intermediate/broken state. Try it again. I wiped my /src and /obj, fetched the src code again from cvsup.freebsd.org. Nothing changed. I still get the same error. I don't use any special compile option. Regards, Thomas Vogt From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:57:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 617A710656C9 for ; Tue, 24 Mar 2009 19:57:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 17C3C8FC1B for ; Tue, 24 Mar 2009 19:57:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 510795D39; Tue, 24 Mar 2009 20:57:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id noghBXKLhuwv; Tue, 24 Mar 2009 20:57:47 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id EFC895D33; Tue, 24 Mar 2009 20:57:46 +0100 (CET) Message-Id: <5EC932B8-C328-4CC1-BF33-BDFD1030C1B4@bsdunix.ch> From: Thomas Vogt To: Scot Hetzel In-Reply-To: <790a9fff0903240913t1f1bc5e6q61fbe80caeb86e34@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 20:57:46 +0100 References: <49C8BC54.7050504@bsdunix.ch> <20090324133803.38d6cfd0@ernst.jennejohn.org> <790a9fff0903240913t1f1bc5e6q61fbe80caeb86e34@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: /usr/include/wchar.h:216: error: invalid use of 'restrict' in /lib32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:57:50 -0000 Hello Scot Am 24.03.2009 um 17:13 schrieb Scot Hetzel: > On Tue, Mar 24, 2009 at 7:38 AM, Gary Jennejohn > wrote: >> On Tue, 24 Mar 2009 11:56:20 +0100 >> Thomas Vogt wrote: >> >>> I tried to update my current 64bit intel system from late January >>> to the >>> latest current code from March 24. >>> >>> FreeBSD foo.ch 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Jan 24 >>> 13:20:12 >>> UTC 2009 >>> >>> make.conf: >>> WITH_LIB32=yes >>> >> >> Note that it's MK_LIB32, which is only effective if set to 'no'. >> Otherwise 32-bit libraries always seem to be built. >> > The MK_* variables are internal variables for the FreeBSD sources. > They are not to be set in /etc/make.conf. > > Instead you use WITH_* or WITHOUT_* to set the value of the MK_* > variables. > > hp010# make -V MK_LIB32 -DWITHOUT_LIB32 -f Makefile.inc1 > no > hp010# make -V MK_LIB32 -DWITH_LIB32 -f Makefile.inc1 > yes > hp010# make -V MK_LIB32 WITH_LIB32=yes -f Makefile.inc1 > yes > hp010# make -V MK_LIB32 WITH_LIB32=no -f Makefile.inc1 > yes > > Note: WITH_LIB32=no will still build the LIB32 libraries, use > WITHOUT_LIB32 to not build LIB32. Ok. In my case i would like to build it with LIB32. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 19:59:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DAF610656C2 for ; Tue, 24 Mar 2009 19:59:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4654A8FC22 for ; Tue, 24 Mar 2009 19:59:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 7D152130C3C; Tue, 24 Mar 2009 20:59:11 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2GMt2hLidP6; Tue, 24 Mar 2009 20:59:05 +0100 (CET) Received: from wedge.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP; Tue, 24 Mar 2009 20:59:05 +0100 (CET) Message-ID: <49C93B89.1090201@madpilot.net> Date: Tue, 24 Mar 2009 20:59:05 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Sam Leffler References: <49C92C9F.4050000@madpilot.net> <49C9357A.8000609@freebsd.org> In-Reply-To: <49C9357A.8000609@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant can't associate with WPA2 AP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:59:13 -0000 Sam Leffler wrote: > Guido Falsi wrote: >> and excerpt from rc.conf: >> >> wlans_ipw0="wlan0" >> create_args_wlan0="wlanmode sta country IT" >> ifconfig_wlan0="WPA DHCP" > Thanks for the fast feedback! > Unfortunately the vap conversion of the ipw driver never was completed > (it's the only driver in the tree that is known to be totally broken). > It's on my todo list for 8.0 but would happily defer to someone else > :). I'm actually surprised you got this far. I'm an obstinate person :) Unluckily I don't even know from where to start to hack it. If I could anyway help you in some way, just ask. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:08:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9BF1065794 for ; Tue, 24 Mar 2009 20:08:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E136B8FC16 for ; Tue, 24 Mar 2009 20:08:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LmCuw-000AFD-Ey; Tue, 24 Mar 2009 22:08:10 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n2OK87pe081841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 22:08:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n2OK87lk015351; Tue, 24 Mar 2009 22:08:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n2OK87GL015350; Tue, 24 Mar 2009 22:08:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Mar 2009 22:08:07 +0200 From: Kostik Belousov To: Jaakko Heinonen Message-ID: <20090324200807.GK31897@deviant.kiev.zoral.com.ua> References: <20090323140820.GA37093@zeeb.org> <20090324180437.GA952@a91-153-125-115.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="utPK4TBebyzZxMrE" Content-Disposition: inline In-Reply-To: <20090324180437.GA952@a91-153-125-115.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LmCuw-000AFD-Ey f781d6d0106445496715d87398b40916 X-Terabit: YES Cc: 7ogcg7g02@sneakemail.com, freebsd-current@freebsd.org Subject: Re: panic: Bad link elm, nfsd related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:08:17 -0000 --utPK4TBebyzZxMrE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 24, 2009 at 08:04:38PM +0200, Jaakko Heinonen wrote: > On 2009-03-23, Matthew West wrote: > > After 1-2 weeks, the system will panic with the following: > >=20 > > ---------- > > panic: Bad link elm 0xffffff0011febc00 next->prev !=3D elm >=20 > It looks like an attempt to remove xprt twice from tail queue due to > race. Does this patch make any difference? >=20 > %%% > Index: sys/rpc/svc.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 > --- sys/rpc/svc.c (revision 189918) > +++ sys/rpc/svc.c (working copy) > @@ -296,8 +296,10 @@ xprt_unregister_locked(SVCXPRT *xprt) > TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); > xprt->xp_active =3D FALSE; > } > - TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); > - xprt->xp_registered =3D FALSE; > + if (xprt->xp_registered) { > + TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); > + xprt->xp_registered =3D FALSE; > + } > } > =20 > void > %%% >=20 > This was also reported by Edward Fisk (Cc'd) in PR 132068. Yes, I did it, and discussed exactly the same change with dfr@. The patch only fixes symptom, the real problem is double unreg. --utPK4TBebyzZxMrE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknJPaYACgkQC3+MBN1Mb4jaLwCeKPzeGt2Q5aHundbZFwl9W+21 QHgAoPSm7Tl7oetj1igMlUkGF8XvlHnW =D3Y1 -----END PGP SIGNATURE----- --utPK4TBebyzZxMrE-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:11:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D42C1065764 for ; Tue, 24 Mar 2009 20:11:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id CC8588FC20 for ; Tue, 24 Mar 2009 20:11:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 3512 invoked by uid 399); 24 Mar 2009 20:11:47 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Mar 2009 20:11:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49C93E81.9080308@FreeBSD.org> Date: Tue, 24 Mar 2009 13:11:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Nikolay Antsiferov References: <5d97c6ec0903241231x73998539x1f8b52dcb75e3826@mail.gmail.com> In-Reply-To: <5d97c6ec0903241231x73998539x1f8b52dcb75e3826@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:11:54 -0000 Nikolay Antsiferov wrote: > Hello. > Yesterday i use mergemaster -F option after installworld. Worked good > for me. All files that differ only by cvs tag were replaced. I update > from 8.0-CURRENT-200902 to head sources. Thanks. Glad to hear it worked for you, and thank you for the success report! :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:14:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712931065A4A for ; Tue, 24 Mar 2009 20:14:50 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 45F718FC0A for ; Tue, 24 Mar 2009 20:14:50 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2OKEnVX037553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 13:14:49 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49C93F39.7080804@freebsd.org> Date: Tue, 24 Mar 2009 13:14:49 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Daniel Thiele References: <49C83038.40300@gmx.net> In-Reply-To: <49C83038.40300@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:14:51 -0000 Daniel Thiele wrote: > Hi, > > I have a problem with my wireless connection. I am running FreeBSD > 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros > based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink > based USB adapter (Linksys WUSB54GC-EU via rum(4)). > > At home using the Atheros card together with a FreeBSD (7.1) based > access point (using rum(4) in hostap mode) and the wpa_supplicant.conf > (attached at the end of this email) settings for SSID="home" I don't > have any problems. With a Linksys WRT54GL-DE access point > running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open > wireless LAN also works flawlessly. > > At the university, however, (SSID="IDA" in the wpa_supplicant.conf at > the end of this email) the wireless connection only works for about an > hour. The vague term "wireless connection" in this case means, that the > WPA connection is opened and associated, then I get an IP address via > dhclient. There is a message about "OpenSSL: tls_connection_handshake - > Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 > EAP method 'MSCHAPv2'" but the authentication seems to succeed: > Do you know if this is a regression w/ the 0.6.8 supplicant I recently imported (i.e. relative to 0.5.11+HEAD)? Jouni just released a 0.6.9 version and it appeared to have a fix that might be appropriate. I need to digest your logs to understand but you can try importing 0.6.9 yourself. Sam From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:26:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB0B10657EA for ; Tue, 24 Mar 2009 20:26:20 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id 35CA48FC12 for ; Tue, 24 Mar 2009 20:26:20 +0000 (UTC) (envelope-from cokane@FreeBSD.org) X-CNFS-Analysis: v=1.0 c=1 a=gVCfA2_oDVMA:10 a=usMdJmQPcLUA:10 a=6I5d2MoRAAAA:8 a=q0BBq3YpxiyAdrm94nEA:9 a=Rvbp3Vec8n7qPsEZCkMA:7 a=fHlt5kbH1jD7hxi8bndDWuiLYF4A:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 a=qmyb_IjueFyVk05i:21 a=YMQF_jC1sP0KdICl:21 a=EdWRuRDXYWfu0VnASaUA:9 a=GgwLrNCzx1qU4Q_Juxgf7c6ZJAUA:4 a=rPt6xJ-oxjAA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout1 smtp.mail=cokane@FreeBSD.org; spf=softfail Received-SPF: softfail (gwout1: transitional domain FreeBSD.org does not designate 74.215.227.9 as permitted sender) Received: from [74.215.227.9] ([74.215.227.9:50708] helo=mail.cokane.org) by gwout1 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id FE/CC-27669-BE149C94; Tue, 24 Mar 2009 16:26:19 -0400 Received: from [172.20.0.76] (rrcs-96-11-231-210.central.biz.rr.com [96.11.231.210]) by mail.cokane.org (Postfix) with ESMTPSA id 03E2011436; Tue, 24 Mar 2009 17:30:42 -0400 (EDT) From: Coleman Kane To: Gustau Perez In-Reply-To: <49C92FA6.20608@entel.upc.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-naEFtvM812nMY9+oeuNz" Organization: FreeBSD Project Date: Tue, 24 Mar 2009 16:24:49 -0400 Message-Id: <1237926289.1735.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:26:24 -0000 --=-naEFtvM812nMY9+oeuNz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote: > Robert Noland wrote: > > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: > > =20 > >> Brandon Gooch wrote: > >> =20 > >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote= : > >>> =20 > >>> =20 > >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >>>> =20 > >>>> =20 > >>>>> Jung-uk Kim wrote: > >>>>> =20 > >>>>> =20 > >>>>>> With popular demands, I will commit the following patch in next > >>>>>> few days unless a showstopper is found or "over-my-dead-body" > >>>>>> type of review is received. ;-) > >>>>>> > >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >>>>>> > >>>>>> FYI, it was originally posted here: > >>>>>> > >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >>>>>> > >>>>>> and here: > >>>>>> > >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >>>>>> > >>>>>> Please read the original threads for more information about the > >>>>>> patch. > >>>>>> =20 > >>>>>> =20 > >>>>> Have just retested this with just updated 8-CURRENT. Still works > >>>>> fine as before with my Acer TM6292 > >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >>>>> letter just after successful resume. > >>>>> > >>>>> There is still some DRI resume problems (will try one rnoland@ > >>>>> patch tomorrow) and my touch pad does not wakes up for some reason, > >>>>> but that is probably unrelated. > >>>>> =20 > >>>>> =20 > >>>> I went ahead and committed slightly different version. Please resyn= c > >>>> the source if you tested the old version. > >>>> > >>>> Cheers, > >>>> > >>>> Jung-uk Kim > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" > >>>> > >>>> =20 > >>>> =20 > >>> =20 > >>> =20 > >> Hi there, > >> > >> in my Latitude D630 with 8-0 current updated this morning (+1 UTC) = it=20 > >> seems is trying to work. It has no xorg, just text console. > >> =20 > > > > The D630 should have an Intel 965GM in it with suspend/resume support i= n > > drm, so X *should* be good to go. > > > > robert. > > > > =20 > Hi Roland, >=20 > this one comes with an nvidia Quadro NVS 135M (I think they made two=20 > o three different models). It was possible to customize them via web. My=20 > mistake was to choose an nvidia (well, I've been able to play nice games=20 > with it, but now it's giving me a lot of headaches). >=20 > With this model (without X's, just text console) suspending and=20 > resuming seems to work except the video. I can type thing and send them=20 > to a file (checked). After resuming, it throws a little of text (i can=20 > see some debug about suspending and resuming firewire and usb) and then=20 > video is lost. With if_bge within the kernel I don't get that=20 > semi-successful result. It starts complaining about PHY read/write=20 > timeout so I have it as a module. >=20 > Offtopic : In the other hand right now I'm going to try the patch you=20 > sent to use nouveau in i386 mode (not amd64, I have a separate partition=20 > for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko=20 > before leaving to home (and I worked). Will let you now my results in=20 > the Take two thread :) >=20 > Greets, >=20 > Gus > =20 I've been seeing the exact same problem that you are with the if_bge driver (including jkim's earlier patches). Does it do this for anyone using i386? I have not been able to make this work for me no matter what I try. Have you managed to get if_bge working after a resume? Could I be CC'd on any patches that might solve this problem in the future? if_bge has a strange bootstrapping sequence which I think might be core to the problem. It seems that you are supposed to write a value to a register, then wait for that register to read something else before proceeding (yes, I've simplified the actual sequence of steps). This process complicates debugging the hardware, and I've been unsuccessful in trying to simply kldunload if_bge and then saving/restoring the PCI register space before/after suspend/resume... Any insight would be helpful. Maybe I should browse the Linux kernel commit logs for this one and see if it bit them too... I also see that there is some issue that breaks NDIS on resume as well, but I am not sure why at the moment. --=20 Coleman Kane --=-naEFtvM812nMY9+oeuNz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAknJQZEACgkQcMSxQcXat5eG0QCfUF3c042aPmkJm+gDjQKUpiY3 TbwAn2OtIb/ybOECktwYMiLomJK2Utl8 =F+/t -----END PGP SIGNATURE----- --=-naEFtvM812nMY9+oeuNz-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:42:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC45106564A for ; Tue, 24 Mar 2009 20:42:30 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8678FC1C for ; Tue, 24 Mar 2009 20:42:30 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id A344B7E818 for ; Tue, 24 Mar 2009 12:42:28 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Tue, 24 Mar 2009 21:42:27 +0100 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <200903232223.47295.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200903232223.47295.mel.flynn+fbsd.current@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903242142.27268.mel.flynn+fbsd.current@mailing.thruhere.net> Subject: Re: Panic in wpi, hard to reproduce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:42:31 -0000 On Monday 23 March 2009 22:23:47 Mel Flynn wrote: > Hi, > > I've been bit twice now by a panic in wpi(4). It's hard to reproduce but > the panics are consistent, meaning the two panics are identical. I'm not > using wpi at the moment, but may again in the relative near future. > > At the time of the crashes the card was used as wireless g connection to an > FreeBSD hostap using ral(4), via WEP. Some additional info about it: it seems to happen after a long period of non- activity but not always, since I've had the machine up for >5 days with good nights of sleep. I tend to think it's caused by coming from "sleep mode" and desktop widgets like RSS and weather panels, at the same time requesting stuff from the net, but it's a gut feeling. I haven't found a solid reproduction scenario, not for lack of trying. > % ident /boot/kernel/if_wpi.ko > /boot/kernel/if_wpi.ko: > $FreeBSD: src/sys/dev/wpi/if_wpi.c,v 1.19 2009/02/13 16:17:05 sam Exp > $ > > Script started on Sat Mar 7 10:55:59 2009 > # kgdb /boot/kernel/kernel /var/crash/vmcore.0 > 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 "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x7d1667b8 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0688be1 > stack pointer = 0x28:0xc4aabba0 > frame pointer = 0x28:0xc4aabbb4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq16: vgapci0+++) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1d16h11m34s > Physical memory: 1517 MB > Dumping 287 MB: 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 > 16 > > Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from > /boot/kernel/geom_journal.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_journal.ko > Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from > /boot/kernel/snd_hda.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_hda.ko > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /boot/kernel/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/smb.ko...Reading symbols from > /boot/kernel/smb.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/smb.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from > /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from > /boot/kernel/wpifw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/wpifw.ko > Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from > /boot/kernel/blank_saver.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/blank_saver.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc0637bdc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc0637ea9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc08633cc in trap_fatal (frame=0xc4aabb60, eva=2098620344) > at /usr/src/sys/i386/i386/trap.c:929 > #4 0xc0863630 in trap_pfault (frame=0xc4aabb60, usermode=0, > eva=2098620344) at /usr/src/sys/i386/i386/trap.c:842 > #5 0xc0863fb2 in trap (frame=0xc4aabb60) at > /usr/src/sys/i386/i386/trap.c:522 #6 0xc084932b in calltrap () at > /usr/src/sys/i386/i386/exception.s:165 #7 0xc0688be1 in mb_free_ext > (m=0xc925d300) at > /usr/src/sys/kern/uipc_mbuf.c:228 > #8 0xc0689381 in m_freem (mb=0x0) at mbuf.h:524 > #9 0xc083d981 in wpi_intr (arg=0xc4e2c800) at > /usr/src/sys/dev/wpi/if_wpi.c:1589 > #10 0xc061688b in intr_event_execute_handlers (p=0xc4d2e7ec, ie=0xc4d70380) > at /usr/src/sys/kern/kern_intr.c:1134 > #11 0xc0617cab in ithread_loop (arg=0xc4eda680) at > /usr/src/sys/kern/kern_intr.c:1147 > #12 0xc06145e3 in fork_exit (callout=0xc0617c40 , > arg=0xc4eda680, > frame=0xc4aabd38) at /usr/src/sys/kern/kern_fork.c:821 > #13 0xc08493a0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 (kgdb) frame 7 > #7 0xc0688be1 in mb_free_ext (m=0xc925d300) at > /usr/src/sys/kern/uipc_mbuf.c:228 > 228 if (*(m->m_ext.ref_cnt) == 1 || > (kgdb) print m->M_dat.MH.MH_dat.MH_ext > $1 = {ext_buf = 0x6ddc9134
, ext_free = > 0x6e378c2e, > ext_arg1 = 0xc25a829, ext_arg2 = 0x6070e28f, ext_size = 2799295368, > ref_cnt = 0x7d1667b8, ext_type = 908986233} > (kgdb) print *(m->M_dat.MH.MH_dat.MH_ext.ref_cnt) > Cannot access memory at address 0x7d1667b8 > (kgdb) frame 9 > #9 0xc083d981 in wpi_intr (arg=0xc4e2c800) at > /usr/src/sys/dev/wpi/if_wpi.c:1589 > 1589 m_freem(txdata->m); > (kgdb) list > 1584 ifp->if_opackets++; > 1585 > 1586 bus_dmamap_sync(ring->data_dmat, txdata->map, BUS_DMASYNC_POSTWRITE); > 1587 bus_dmamap_unload(ring->data_dmat, txdata->map); > 1588 /* XXX handle M_TXCB? */ > 1589 m_freem(txdata->m); > 1590 txdata->m = NULL; > 1591 ieee80211_free_node(txdata->ni); > 1592 txdata->ni = NULL; > 1593 -- Mel From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:56:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214151065697; Tue, 24 Mar 2009 20:56:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D4EA38FC22; Tue, 24 Mar 2009 20:56:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2OKu5XU040928; Tue, 24 Mar 2009 16:56:05 -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.14.3/8.14.3) with ESMTP id n2OKu5C3035919; Tue, 24 Mar 2009 16:56:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4F9327302F; Tue, 24 Mar 2009 15:56:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090324205605.4F9327302F@freebsd-current.sentex.ca> Date: Tue, 24 Mar 2009 15:56:05 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:56:09 -0000 TB --- 2009-03-24 19:55:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-24 19:55:53 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-03-24 19:55:53 - cleaning the object tree TB --- 2009-03-24 19:56:23 - cvsupping the source tree TB --- 2009-03-24 19:56:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-03-24 19:56:31 - building world TB --- 2009-03-24 19:56:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-24 19:56:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-24 19:56:31 - TARGET=sun4v TB --- 2009-03-24 19:56:31 - TARGET_ARCH=sparc64 TB --- 2009-03-24 19:56:31 - TZ=UTC TB --- 2009-03-24 19:56:31 - __MAKE_CONF=/dev/null TB --- 2009-03-24 19:56:31 - cd /src TB --- 2009-03-24 19:56:31 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 24 19:56:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmac.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c In file included from /src/sbin/ifconfig/ifieee80211.c:3024: /obj/sun4v/src/tmp/usr/include/net80211/ieee80211_freebsd.h:399: error: expected ')' before 'ieee80211_ioctl_getfunc' /obj/sun4v/src/tmp/usr/include/net80211/ieee80211_freebsd.h:404: error: expected ')' before 'ieee80211_ioctl_setfunc' *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-24 20:56:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-24 20:56:05 - ERROR: failed to build world TB --- 2009-03-24 20:56:05 - 3043.54 user 308.59 system 3611.81 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:13:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE7151065672 for ; Tue, 24 Mar 2009 21:13:07 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7CA8FC08 for ; Tue, 24 Mar 2009 21:13:06 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n2OLCvDB021639; Tue, 24 Mar 2009 22:12:57 +0100 Received: from [192.168.100.184] ([88.11.103.61]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032422130464:180008 ; Tue, 24 Mar 2009 22:13:04 +0100 Message-ID: <49C94C5C.3040500@entel.upc.edu> Date: Tue, 24 Mar 2009 22:10:52 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1236802980.00085518.1236789602@10.7.7.3> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <200903241528.34902.jkim@FreeBSD.org> In-Reply-To: <200903241528.34902.jkim@FreeBSD.org> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 22:13:04, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 24/03/2009 22:13:05, Serialize complete at 24/03/2009 22:13:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 24 Mar 2009 22:12:57 +0100 (CET) Cc: Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:13:07 -0000 > Please try the attached patch, which just disables restoring VGA state > while resuming. > > Hi Jung-uk, I've just recompiled the kernel with your patch. In this case after resume I don't get any display at all. Screens continues totally black. Without the patch, the screen resumes for a moment and then switches to black. Just tried with acpicof -s 3, will try with hw.acpi.reset_video (just to try). I've checked /var/log/messages, and I don't see anything strange. I can see acpi: suspend at 20090324 21:30:41 and then some logs about the resume process. Nothing related to vga, all about wlan, usb, firewire and such, Is there anything I can test ? Greets, From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:14:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DD010656CE; Tue, 24 Mar 2009 21:14:53 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id B70508FC14; Tue, 24 Mar 2009 21:14:53 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id DF1C471F0BE; Tue, 24 Mar 2009 17:14:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy4SFg2Bdhot; Tue, 24 Mar 2009 17:14:52 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id BC03671EF69; Tue, 24 Mar 2009 17:14:52 -0400 (EDT) Message-ID: <49C94D4C.5050104@egr.msu.edu> Date: Tue, 24 Mar 2009 17:14:52 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090324) MIME-Version: 1.0 References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> In-Reply-To: <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:14:56 -0000 Brandon Gooch wrote: > On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote: > >> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> >>> The committed version is working well, I am suspending and resuming >>> on my Lenovo X300. Thanks for your work on this, it is one of the >>> major things I needed to work so I could run FreeBSD primarily on >>> my notebook. >>> > I just finished a kernel build and it seems as though your > recent commits have fixed the clock (at least for me)! > > I feel sorry for all the i386 folks on ACPI notebooks... > > Thanks! > > -Brandon > Picking a semi-random message here.. Thanks for your work on this! In the past (months ago) I tried the patch set which didn't work, but the code in -current lets me suspend and resume successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think this is a first for me, of all the laptops I've had, none have ever been able to suspend and resume in a successful or useful way, and I've been jealous of the Thinkpad users that could claim otherwise. I could suspend and resume fine while in the console, then I ran startx and the suspend and resume worked while I was in X with intel graphics, however my system was slow after that resume. I didn't spend much time looking at it since I was at work, and I didn't see any obvious reasons for the slowness (cpu frequency was fine, cx states were C2 or lower (C1), top showed mostly idle, no evidence of an IRQ storm) yet processes ran fairly sluggish (not the mouse or typing though). I didn't go back to console, I just shut down without trying any other situations yet. A tip I want to note for any users who may not have success with their screen on resume: In the past it seemed to help me to have a power-on password set in my BIOS since the BIOS will turn on the screen on resume to ask me for my password. I don't know if it is still helping me, but I've seen in the past where it has. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:29:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2755810657A0 for ; Tue, 24 Mar 2009 21:29:40 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from zeeb.org (zeeb.org [88.198.32.244]) by mx1.freebsd.org (Postfix) with ESMTP id B75BB8FC7C for ; Tue, 24 Mar 2009 21:29:20 +0000 (UTC) (envelope-from mwest@zeeb.org) Received: from mwest by zeeb.org with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LmEBT-000Gpl-SS; Tue, 24 Mar 2009 21:29:19 +0000 Date: Tue, 24 Mar 2009 21:29:19 +0000 From: Matthew West To: Jaakko Heinonen Message-ID: <20090324212919.GA64083@zeeb.org> References: <20090323140820.GA37093@zeeb.org> <20090324180437.GA952@a91-153-125-115.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090324180437.GA952@a91-153-125-115.elisa-laajakaista.fi> User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Matthew West Cc: 7ogcg7g02@sneakemail.com, freebsd-current@freebsd.org Subject: Re: panic: Bad link elm, nfsd related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:29:49 -0000 Hi Jaakko, On Tue, Mar 24, 2009 at 08:04:38PM +0200, Jaakko Heinonen wrote: > On 2009-03-23, Matthew West wrote: > > panic: Bad link elm 0xffffff0011febc00 next->prev != elm > > It looks like an attempt to remove xprt twice from tail queue due to > race. Does this patch make any difference? > > %%% > Index: sys/rpc/svc.c > =================================================================== > --- sys/rpc/svc.c (revision 189918) > +++ sys/rpc/svc.c (working copy) > @@ -296,8 +296,10 @@ xprt_unregister_locked(SVCXPRT *xprt) > TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); > xprt->xp_active = FALSE; > } > - TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); > - xprt->xp_registered = FALSE; > + if (xprt->xp_registered) { > + TAILQ_REMOVE(&pool->sp_xlist, xprt, xp_link); > + xprt->xp_registered = FALSE; > + } > } > > void > %%% Thanks for the patch. I applied it, and after a couple of hours, the machine produced another panic: ---------- Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x8:0xffffffff80716808 stack pointer = 0x10:0xfffffffe9b979ae0 frame pointer = 0x10:0xfffffffe9b979af0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 920 (nfsd: service) [thread pid 920 tid 100283 ] Stopped at xprt_assignthread+0x8: movq 0x70(%rdx),%rax db> bt Tracing pid 920 tid 100283 td 0xffffff0001b62720 xprt_assignthread() at xprt_assignthread+0x8 svc_run_internal() at svc_run_internal+0x49e svc_thread_start() at svc_thread_start+0xb fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0xc, rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- ---------- I was unfortunately unable to generate a crash dump, and for now I have gone back to the previous kernel. Let me know if there's anything else you'd like to try. Thanks, Matthew From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 20:55:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88787106566C for ; Tue, 24 Mar 2009 20:55:15 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from mx.rcub.bg.ac.yu (mx.rcub.bg.ac.yu [147.91.1.122]) by mx1.freebsd.org (Postfix) with ESMTP id CE60B8FC19 for ; Tue, 24 Mar 2009 20:55:14 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: by mx.rcub.bg.ac.yu (Postfix, from userid 2055) id 64412191965C; Tue, 24 Mar 2009 21:26:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.rcub.bg.ac.yu (Postfix) with ESMTP id 52F70191964C for ; Tue, 24 Mar 2009 21:26:43 +0100 (CET) Date: Tue, 24 Mar 2009 21:26:43 +0100 (CET) From: Goran Gajic To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-RCUB-MailScanner-Information: Please contact the ISP for more information X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 7, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Mailman-Approved-At: Tue, 24 Mar 2009 21:34:54 +0000 Subject: panic in 8.0-CURRENT after svn from r189900 to r190389 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:55:17 -0000 Hi, Today I have svn up my FreeBSD-8.0-CURRENT to r190389 but it is no longer able to boot, it panics at boot. Here is message I'm getting (I had to write it down to paper :( since I don't have serial attached to this machine: Fatal trap 12: page fault while in kernel mode cpuid =0, apic id = 00 fault virtual address = 0x3c Fault code = supervisor write data, page not present Instruction ponter = 0x8: 0xffffffff8056db9f Stack ponter = 0x10: 0xffffffff813bac70 Code segment = 0x10: 0xffffffff813baca0 = base 0x0, limit 0xfffff, type 0x1b DPL 0, pres 1, long 1, def32 0, gran 1 Processor eflags = resume, iopl = 0 Current process = 0 (swapper) [thread pio 0 tid 10000] stopped at devclass_find_interna+0x10f: orl $0x1, 0x3c(%rax) db> where tracing pid 0 tid 10000 td 0xffffffff80bb5ce0 dev_class_find_internal() at devclass_find_internal+0x10f driver_module_handler() at driver_module_handler+0xb9 module_register_init() at module_register_init+0x7d mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> And here is dmesg from last working kernel I have: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r189900: Mon Mar 16 22:51:40 CET 2009 root@magarac:/usr/src/sys/amd64/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (2333.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Stepping = 7 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant Cores per package: 4 usable memory = 1056894976 (1007 MB) avail memory = 1018724352 (971 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xdfffffff,0xfbae0000-0xfbaeffff irq 16 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) uhci0: port 0x9800-0x981f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f30 usbus0: on uhci0 uhci1: port 0x9880-0x989f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: on uhci1 uhci2: port 0x9c00-0x9c1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: on uhci2 ehci0: mem 0xfb9ffc00-0xfb9fffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 17 at device 28.0 on pci0 pci5: on pcib2 pcib3: at device 0.0 on pci5 pci7: on pcib3 amr0: mem 0xfaff0000-0xfaffffff irq 18 at device 2.0 on pci7 amr0: Using 64-bit DMA amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 352D, BIOS 1.10, 64MB RAM pcib4: mem 0xfbeffc00-0xfbeffc7f irq 16 at device 0.1 on pci5 pci6: on pcib4 pcib5: irq 18 at device 28.2 on pci0 pci4: on pcib5 mskc0: port 0xd800-0xd8ff mem 0xfbdfc000-0xfbdfffff irq 18 at device 0.0 on pci4 msk0: on mskc0 can't re-use a leaf (jabbers)! msk0: Ethernet address: 00:1d:60:c9:1a:3e miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] pcib6: irq 19 at device 28.3 on pci0 pci3: on pcib6 mskc1: port 0xc800-0xc8ff mem 0xfbcfc000-0xfbcfffff irq 19 at device 0.0 on pci3 msk1: on mskc1 can't re-use a leaf (jabbers)! msk1: Ethernet address: 00:1d:60:c9:17:a3 miibus1: on msk1 e1000phy1: PHY 0 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc1: [FILTER] pcib7: irq 17 at device 28.4 on pci0 pci2: on pcib7 atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xfbbffc00-0xfbbfffff irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] uhci3: port 0x9080-0x909f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus4: on uhci3 uhci4: port 0x9400-0x941f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0f30 usbus5: on uhci4 uhci5: port 0x9480-0x949f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x0f30 usbus6: on uhci5 ehci1: mem 0xfb9ff800-0xfb9ffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib8: at device 30.0 on pci0 pci8: on pcib8 pci8: at device 0.0 (no driver attached) pci8: at device 0.2 (no driver attached) fwohci0: port 0xec00-0xec7f mem 0xfebff800-0xfebfffff irq 19 at device 3.0 on pci8 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:8a:3e:e5 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x3e210000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:8a:3e:e5 fwe0: Ethernet address: 02:11:d8:8a:3e:e5 fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:01:8a:3e:e5 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x8000-0x8007,0x7c00-0x7c03,0x7880-0x7887,0x7800-0x7803,0x7480-0x748f,0x7400-0x740f irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0x9000-0x9007,0x8c00-0x8c03,0x8880-0x8887,0x8800-0x8803,0x8480-0x848f,0x8400-0x840f irq 22 at device 31.5 on pci0 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - D, should be 4 [20070320] est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 acd0: DVDR at ata2-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 209640MB (429342720 sectors) RAID 0 (optimal) ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen6.2: at usbus6 ums0: on usbus6 ums0: 3 buttons and [XYZ] coordinates SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/amrd0s2a lock order reversal: 1st 0xfffffffe54a663d8 bufwait (bufwait) @ kern/vfs_bio.c:2549 2nd 0xffffff00019d0a00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_mkdir() at ufs_mkdir+0x633 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x2b2 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x80071e85c, rsp = 0x7fffffffed18, rbp = 0x7fffffffef7e --- KLD snd_hda.ko: depends on kernel - not available linker_load_file: Unsupported file type KLD linux.ko: depends on kernel - not available linker_load_file: Unsupported file type msk0: link state changed to UP Regards, gg. From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:40:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8AF10656FB for ; Tue, 24 Mar 2009 21:40:23 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 507108FC0C for ; Tue, 24 Mar 2009 21:40:23 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2OLdoIs038294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 14:39:51 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49C95326.7040504@freebsd.org> Date: Tue, 24 Mar 2009 14:39:50 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Goran Gajic References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: panic in 8.0-CURRENT after svn from r189900 to r190389 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:40:24 -0000 Goran Gajic wrote: > > Hi, > > Today I have svn up my FreeBSD-8.0-CURRENT to r190389 but it is no > longer able to boot, it panics at boot. Here is message I'm getting (I > had to write it down to paper :( since I don't have serial attached to > this machine: > > Fatal trap 12: page fault while in kernel mode > cpuid =0, apic id = 00 > fault virtual address = 0x3c > Fault code = supervisor write data, page not present > Instruction ponter = 0x8: 0xffffffff8056db9f > Stack ponter = 0x10: 0xffffffff813bac70 > Code segment = 0x10: 0xffffffff813baca0 > = base 0x0, limit 0xfffff, type 0x1b > DPL 0, pres 1, long 1, def32 0, gran 1 > Processor eflags = resume, iopl = 0 > Current process = 0 (swapper) > [thread pio 0 tid 10000] > stopped at devclass_find_interna+0x10f: orl $0x1, 0x3c(%rax) > db> where > tracing pid 0 tid 10000 td 0xffffffff80bb5ce0 > dev_class_find_internal() at devclass_find_internal+0x10f > driver_module_handler() at driver_module_handler+0xb9 > module_register_init() at module_register_init+0x7d > mi_startup() at mi_startup+0x59 > btext() at btext+0x2c > db> > I'm stuck on the same issue on a t61 (amd64/SMP). I don't have any modules. Sam From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:48:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8CC21065676 for ; Tue, 24 Mar 2009 21:48:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 666CD8FC20 for ; Tue, 24 Mar 2009 21:48:50 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 39093 invoked by uid 60001); 24 Mar 2009 21:48:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237931330; bh=HXoBWGB+rKUI+njRsxjj0RAfhKD8I3zFYtekQ8d8DIs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=mheZtL2ygrP+ZlRPRF9DeAZXOFW4L70PsgXgFKkf6BlhyC4cWfFwhrXYnCL4HftAKVSJjKHaYhDesqE8NuN32jVBBLudUNX3w4r00mT8vKeFlxsW5dFxkb8/fpRntFI25R6npTQNhIRgj/FGbu+iiyNMbgBwQT8519Lfjo0YmTs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wX5WUwemAISLmsJqNlrotFs5zdHAr4dG7NtqjjRqdCZqYo1EpkHGOnVwSXx6nkmmVWXaR1xnaPO5FfhQzSLqLl4daC6PqquCEZVV6EyumwXMxJYsosVm5RfZYxCpwuk9zwYlej7L5/PNBjFx/Q83egqNM19vPbbWmC1PGcf+K2A=; Message-ID: <285790.99650.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: tsQW1pEVM1m3XJARQwDvPLqGTTs0t4ILdmSaxsg1F0DocSLXKpMSMe_jxd.yo3WNQIV4vgbijPe96qOOmy09xGOqRoudtOg44dN9BTLW7NdA_R92HsEf7f.mTxAbzm3Umq.7UJvzbY4fVT3rV42TQdWMACMiTclbsOPPMj_IEAMQ4tlz8cgdngNg_LYWPx.hpCf_UMb7KgrhTOA- Received: from [98.242.222.229] by web63903.mail.re1.yahoo.com via HTTP; Tue, 24 Mar 2009 14:48:49 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 24 Mar 2009 14:48:49 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:48:52 -0000 How do you enable root telnet access in current? I remember having some issue with specifying pty/0 in ttys years ago in linux but the right way to do it excapes me. BC From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 21:55:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B326810656C5; Tue, 24 Mar 2009 21:55:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 71FC28FC14; Tue, 24 Mar 2009 21:55:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2OLtLLQ048481; Tue, 24 Mar 2009 17:55:21 -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.14.3/8.14.3) with ESMTP id n2OLtAcI023085; Tue, 24 Mar 2009 17:55:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 751B07302F; Tue, 24 Mar 2009 16:55:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090324215510.751B07302F@freebsd-current.sentex.ca> Date: Tue, 24 Mar 2009 16:55:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:55:26 -0000 TB --- 2009-03-24 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-24 21:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-03-24 21:00:00 - cleaning the object tree TB --- 2009-03-24 21:00:43 - cvsupping the source tree TB --- 2009-03-24 21:00:43 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-03-24 21:00:53 - building world TB --- 2009-03-24 21:00:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-24 21:00:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-24 21:00:53 - TARGET=arm TB --- 2009-03-24 21:00:53 - TARGET_ARCH=arm TB --- 2009-03-24 21:00:53 - TZ=UTC TB --- 2009-03-24 21:00:53 - __MAKE_CONF=/dev/null TB --- 2009-03-24 21:00:53 - cd /src TB --- 2009-03-24 21:00:53 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 24 21:00:55 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifmac.c cc -O -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c In file included from /src/sbin/ifconfig/ifieee80211.c:3024: /obj/arm/src/tmp/usr/include/net80211/ieee80211_freebsd.h:399: error: expected ')' before 'ieee80211_ioctl_getfunc' /obj/arm/src/tmp/usr/include/net80211/ieee80211_freebsd.h:404: error: expected ')' before 'ieee80211_ioctl_setfunc' *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-24 21:55:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-24 21:55:10 - ERROR: failed to build world TB --- 2009-03-24 21:55:10 - 2540.67 user 320.73 system 3309.98 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 22:10:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8B3106564A; Tue, 24 Mar 2009 22:10:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC1C8FC0C; Tue, 24 Mar 2009 22:10:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2OMAOIW050087; Tue, 24 Mar 2009 18:10:24 -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.14.3/8.14.3) with ESMTP id n2OMAOvS073012; Tue, 24 Mar 2009 18:10:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 620C47302F; Tue, 24 Mar 2009 17:10:24 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090324221024.620C47302F@freebsd-current.sentex.ca> Date: Tue, 24 Mar 2009 17:10:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 22:10:28 -0000 TB --- 2009-03-24 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-24 21:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-03-24 21:00:00 - cleaning the object tree TB --- 2009-03-24 21:01:08 - cvsupping the source tree TB --- 2009-03-24 21:01:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-03-24 21:01:16 - building world TB --- 2009-03-24 21:01:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-24 21:01:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-24 21:01:16 - TARGET=amd64 TB --- 2009-03-24 21:01:16 - TARGET_ARCH=amd64 TB --- 2009-03-24 21:01:16 - TZ=UTC TB --- 2009-03-24 21:01:16 - __MAKE_CONF=/dev/null TB --- 2009-03-24 21:01:16 - cd /src TB --- 2009-03-24 21:01:16 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 24 21:01:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmac.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c In file included from /src/sbin/ifconfig/ifieee80211.c:3024: /obj/amd64/src/tmp/usr/include/net80211/ieee80211_freebsd.h:399: error: expected ')' before 'ieee80211_ioctl_getfunc' /obj/amd64/src/tmp/usr/include/net80211/ieee80211_freebsd.h:404: error: expected ')' before 'ieee80211_ioctl_setfunc' *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-24 22:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-24 22:10:24 - ERROR: failed to build world TB --- 2009-03-24 22:10:24 - 3236.84 user 331.38 system 4224.02 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 24 23:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD6E1065675; Tue, 24 Mar 2009 23:31:19 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id CF65E8FC17; Tue, 24 Mar 2009 23:31:18 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so2028258ewy.43 for ; Tue, 24 Mar 2009 16:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7A99WeIpbT2PaDjeGX57DMbs4L/kfPlxAbF++L5zuis=; b=KGZMe1nwv7CdXbLUMP10D1XCKf+Q/M9d09PBaB1MeiiqwGaUiBJXWO/sX5jPCKH0ft Jv34OfwhmlNuoyUuuBVfiEEQswP7pcdk/Crdzw3AGYh926rc8l7S6jWPvJ/auan5GZGt 44is3z2ASRZp5odJMply8nOZu6YSns5BrJFDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FdDQnef43yYjSBpm93SKNaJZkR3gOXTJ+VvR76/S8XhLadv695X/NNirCVT0RSQzKO mLod1GIWPvN3KgE0JwhEyTy75nJPL9nZ+TBYFsgzFPoKSKgvYVV5ZE64xk0S60jwCDFu oJWzn6NOnffK/H0UUTQLgxtSQ+UPF39Z1nl/U= MIME-Version: 1.0 Received: by 10.210.56.9 with SMTP id e9mr695461eba.33.1237937477941; Tue, 24 Mar 2009 16:31:17 -0700 (PDT) In-Reply-To: <49C94D4C.5050104@egr.msu.edu> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> Date: Tue, 24 Mar 2009 18:31:17 -0500 Message-ID: <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> From: Brandon Gooch To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:31:20 -0000 On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall wrot= e: > Brandon Gooch wrote: >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote: >> >>> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >>> >>>> >>>> The committed version is working well, I am suspending and resuming >>>> on my Lenovo X300. Thanks for your work on this, it is one of the >>>> major things I needed to work so I could run FreeBSD primarily on >>>> my notebook. >>>> >> >> I just finished a kernel build and it seems as though your >> recent commits have fixed the clock (at least for me)! >> >> I feel sorry for all the i386 folks on ACPI notebooks... >> >> Thanks! >> >> -Brandon >> > > Picking a semi-random message here.. > > Thanks for your work on this! =A0In the past (months ago) I tried the pat= ch > set which didn't work, but the code in -current lets me suspend and resum= e > successfully on my Dell Latitude E6500 (acpiconf -s 3)! =A0I think this i= s a > first for me, of all the laptops I've had, none have ever been able to > suspend and resume in a successful or useful way, and I've been jealous o= f > the Thinkpad users that could claim otherwise. =A0I could suspend and res= ume > fine while in the console, then I ran startx and the suspend and resume > worked while I was in X with intel graphics, however my system was slow > after that resume. =A0I didn't spend much time looking at it since I was = at > work, and I didn't see any obvious reasons for the slowness (cpu frequenc= y > was fine, cx states were C2 or lower (C1), top showed mostly idle, no > evidence of an IRQ storm) yet processes ran fairly sluggish (not the mous= e > or typing though). =A0I didn't go back to console, I just shut down witho= ut > trying any other situations yet. > > A tip I want to note for any users who may not have success with their > screen on resume: =A0In the past it seemed to help me to have a power-on > password set in my BIOS since the BIOS will turn on the screen on resume = to > ask me for my password. =A0I don't know if it is still helping me, but I'= ve > seen in the past where it has. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > The sluggish response in X on Intel video has been an issue the past couple of days, triggered by suspend/resume or simply switching to VTY and back. See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.html Firefox is unusable, but xterms are still usable. I have to reboot to get back to "normal" -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 00:05:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B84106566C for ; Wed, 25 Mar 2009 00:05:31 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A47958FC16 for ; Wed, 25 Mar 2009 00:05:30 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 25 Mar 2009 00:05:28 -0000 Received: from p54866C1D.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.108.29] by mail.gmx.net (mp067) with SMTP; 25 Mar 2009 01:05:28 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX1+8aD4jx/O8CAoVEragWFBvuPFCI8cYIIDV7pyUb4 9fpfCbnl41Dobj Message-ID: <49C9756F.4010206@gmx.net> Date: Wed, 25 Mar 2009 01:06:07 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Sam Leffler References: <49C83038.40300@gmx.net> <49C93F39.7080804@freebsd.org> In-Reply-To: <49C93F39.7080804@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:05:31 -0000 Sam Leffler wrote: > Daniel Thiele wrote: >> Hi, >> >> I have a problem with my wireless connection. I am running FreeBSD >> 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros >> based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink >> based USB adapter (Linksys WUSB54GC-EU via rum(4)). >> >> At home using the Atheros card together with a FreeBSD (7.1) based >> access point (using rum(4) in hostap mode) and the wpa_supplicant.conf >> (attached at the end of this email) settings for SSID="home" I don't >> have any problems. With a Linksys WRT54GL-DE access point >> running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open >> wireless LAN also works flawlessly. >> >> At the university, however, (SSID="IDA" in the wpa_supplicant.conf at >> the end of this email) the wireless connection only works for about an >> hour. The vague term "wireless connection" in this case means, that the >> WPA connection is opened and associated, then I get an IP address via >> dhclient. There is a message about "OpenSSL: tls_connection_handshake - >> Failed to read possible Application Data >> error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 >> EAP method 'MSCHAPv2'" but the authentication seems to succeed: >> > > Do you know if this is a regression w/ the 0.6.8 supplicant I recently > imported (i.e. relative to 0.5.11+HEAD)? Unfortunately I cannot answer that, since I have not been running CURRENT for that long. Is there a way I can help to test that? I still have my old notebook (7.1-STABLE running wpa_supplicant 0.5.10 with ipw and rum wireless adapters). I can get the logs from that machine, too, if that would help. > Jouni just released a 0.6.9 > version and it appeared to have a fix that might be appropriate. I need > to digest your logs to understand but you can try importing 0.6.9 yourself. I will give it a try. Just now I merged the diffs between 0.6.8 and 0.6.9 to my /usr/src. Except for wpa_supplicant-0.6.8/src/common/nl80211_copy.h, wpa_supplicant-0.6.9/src/l2_packet/l2_packet_linux.c and, wpa_supplicant-0.6.9/wpa_supplicant/Makefile I was able to apply the diffs. I will try this at university on Thursday or Friday and report any success or failure here. Thanks for the help and hints so far. Daniel From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 00:28:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A86C106566B for ; Wed, 25 Mar 2009 00:28:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3F58FC1F for ; Wed, 25 Mar 2009 00:28:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2P0SYUV039262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 17:28:34 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49C97AB2.6080500@freebsd.org> Date: Tue, 24 Mar 2009 17:28:34 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Daniel Thiele References: <49C83038.40300@gmx.net> <49C93F39.7080804@freebsd.org> <49C9756F.4010206@gmx.net> In-Reply-To: <49C9756F.4010206@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:28:35 -0000 Daniel Thiele wrote: > Sam Leffler wrote: >> Daniel Thiele wrote: >>> Hi, >>> >>> I have a problem with my wireless connection. I am running FreeBSD >>> 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros >>> based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a >>> Ralink >>> based USB adapter (Linksys WUSB54GC-EU via rum(4)). >>> >>> At home using the Atheros card together with a FreeBSD (7.1) based >>> access point (using rum(4) in hostap mode) and the wpa_supplicant.conf >>> (attached at the end of this email) settings for SSID="home" I don't >>> have any problems. With a Linksys WRT54GL-DE access point >>> running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open >>> wireless LAN also works flawlessly. >>> >>> At the university, however, (SSID="IDA" in the wpa_supplicant.conf at >>> the end of this email) the wireless connection only works for about an >>> hour. The vague term "wireless connection" in this case means, that the >>> WPA connection is opened and associated, then I get an IP address via >>> dhclient. There is a message about "OpenSSL: tls_connection_handshake - >>> Failed to read possible Application Data >>> error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 >>> EAP method 'MSCHAPv2'" but the authentication seems to succeed: >>> >> >> Do you know if this is a regression w/ the 0.6.8 supplicant I recently >> imported (i.e. relative to 0.5.11+HEAD)? > > Unfortunately I cannot answer that, since I have not been running > CURRENT for that long. Is there a way I can help to test that? I still > have my old notebook (7.1-STABLE running wpa_supplicant 0.5.10 with ipw > and rum wireless adapters). I can get the logs from that machine, too, > if that would help. You could rollback wpa_supplicant using svn/cvs but it's a bit painful as the changes were extensive due to the switch from the 0.5 series releases to 0.6. Alternatively you could rollback your entire tree to r189262 (I think) and you'd have the previous code. > >> Jouni just released a 0.6.9 >> version and it appeared to have a fix that might be appropriate. I need >> to digest your logs to understand but you can try importing 0.6.9 >> yourself. > > I will give it a try. Just now I merged the diffs between 0.6.8 and > 0.6.9 to my /usr/src. Except for > wpa_supplicant-0.6.8/src/common/nl80211_copy.h, > wpa_supplicant-0.6.9/src/l2_packet/l2_packet_linux.c and, > wpa_supplicant-0.6.9/wpa_supplicant/Makefile > I was able to apply the diffs. We do not use any of these files. You might be better off looking at diff's between 0.6.8 and 0.6.9 and selectively applying changes to usr/src/contrib/wpa. Some of these may be ignored as Jouni took back some changes I provided him. Note that usr.sbin/wpa/wpa_supplicant has the driver for freebsd and a reach-over Makefile; we do not use Jouni's bsd driver or his build structure. > > I will try this at university on Thursday or Friday and report any > success or failure here. I'll try to look at merging 0.6.9 quickly. Sam From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 00:32:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B591065670 for ; Wed, 25 Mar 2009 00:32:15 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B745D8FC0A for ; Wed, 25 Mar 2009 00:32:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so2039209ewy.43 for ; Tue, 24 Mar 2009 17:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hYuZ1udLRr5nzh4Pk85FVUMF36haL73v28vfgTIR9nU=; b=HLeHk6yAqzriiGehJgWl32ZnSPt2rHE8k3uIWGsl4rDwFiHKbPY852r16SVnviB71T XyyxxpouR/nU83wzvCir4D4YoJxqM/EItF0APqOC49yFB2HRlPzRNGHe9eHYc3NwBQKb MAJaaZYg6vo6V7Z5EuIJNldqWG/Xnf1yar43A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jh8OAOsC6ULg+MYDtGFDLiGTNXkSyz68Uay1BZC3ODUn2huKKKc3Qbo+vYFHfMQ7z9 4izoCqfDu7jcSocnLaeUUCxULBz/RhQ0d1ZV2LToFMZHwwexo2O/Fp8a4vv4/hWWH1H/ JdkVts2XR5PAIae8x2XwpbAnaUuWTNABVnuOQ= MIME-Version: 1.0 Received: by 10.210.89.4 with SMTP id m4mr6110952ebb.82.1237941133818; Tue, 24 Mar 2009 17:32:13 -0700 (PDT) In-Reply-To: <1237926289.1735.17.camel@localhost> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <1237926289.1735.17.camel@localhost> Date: Wed, 25 Mar 2009 01:32:13 +0100 Message-ID: <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com> From: "Paul B. Mahol" To: Coleman Kane Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:32:15 -0000 On 3/24/09, Coleman Kane wrote: > On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote: >> Robert Noland wrote: >> > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: >> > >> >> Brandon Gooch wrote: >> >> >> >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wrote: >> >>> >> >>> >> >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >> >>>> >> >>>> >> >>>>> Jung-uk Kim wrote: >> >>>>> >> >>>>> >> >>>>>> With popular demands, I will commit the following patch in next >> >>>>>> few days unless a showstopper is found or "over-my-dead-body" >> >>>>>> type of review is received. ;-) >> >>>>>> >> >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >> >>>>>> >> >>>>>> FYI, it was originally posted here: >> >>>>>> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >> >>>>>> >> >>>>>> and here: >> >>>>>> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >> >>>>>> >> >>>>>> Please read the original threads for more information about the >> >>>>>> patch. >> >>>>>> >> >>>>>> >> >>>>> Have just retested this with just updated 8-CURRENT. Still works >> >>>>> fine as before with my Acer TM6292 >> >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >> >>>>> letter just after successful resume. >> >>>>> >> >>>>> There is still some DRI resume problems (will try one rnoland@ >> >>>>> patch tomorrow) and my touch pad does not wakes up for some reason, >> >>>>> but that is probably unrelated. >> >>>>> >> >>>>> >> >>>> I went ahead and committed slightly different version. Please resync >> >>>> the source if you tested the old version. >> >>>> >> >>>> Cheers, >> >>>> >> >>>> Jung-uk Kim >> >>>> _______________________________________________ >> >>>> freebsd-current@freebsd.org mailing list >> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >>>> To unsubscribe, send any mail to >> >>>> "freebsd-current-unsubscribe@freebsd.org" >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> Hi there, >> >> >> >> in my Latitude D630 with 8-0 current updated this morning (+1 UTC) >> >> it >> >> seems is trying to work. It has no xorg, just text console. >> >> >> > >> > The D630 should have an Intel 965GM in it with suspend/resume support in >> > drm, so X *should* be good to go. >> > >> > robert. >> > >> > >> Hi Roland, >> >> this one comes with an nvidia Quadro NVS 135M (I think they made two >> o three different models). It was possible to customize them via web. My >> mistake was to choose an nvidia (well, I've been able to play nice games >> with it, but now it's giving me a lot of headaches). >> >> With this model (without X's, just text console) suspending and >> resuming seems to work except the video. I can type thing and send them >> to a file (checked). After resuming, it throws a little of text (i can >> see some debug about suspending and resuming firewire and usb) and then >> video is lost. With if_bge within the kernel I don't get that >> semi-successful result. It starts complaining about PHY read/write >> timeout so I have it as a module. >> >> Offtopic : In the other hand right now I'm going to try the patch you >> sent to use nouveau in i386 mode (not amd64, I have a separate partition >> for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko >> before leaving to home (and I worked). Will let you now my results in >> the Take two thread :) >> >> Greets, >> >> Gus >> > > I've been seeing the exact same problem that you are with the if_bge > driver (including jkim's earlier patches). Does it do this for anyone > using i386? I have not been able to make this work for me no matter what > I try. Have you managed to get if_bge working after a resume? Could I be > CC'd on any patches that might solve this problem in the future? > > if_bge has a strange bootstrapping sequence which I think might be core > to the problem. It seems that you are supposed to write a value to a > register, then wait for that register to read something else before > proceeding (yes, I've simplified the actual sequence of steps). This > process complicates debugging the hardware, and I've been unsuccessful > in trying to simply kldunload if_bge and then saving/restoring the PCI > register space before/after suspend/resume... Any insight would be > helpful. Maybe I should browse the Linux kernel commit logs for this one > and see if it bit them too... > > I also see that there is some issue that breaks NDIS on resume as well, > but I am not sure why at the moment. I would say that there is no any real support for NDISulator after resume. It is NDISulator bug. Workarodund is to unload module before suspend and load it again after resume, and device must be in D3 state before suspending (hw.pci.do_power_nodriver=3) -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 01:05:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E8D1065678 for ; Wed, 25 Mar 2009 01:05:13 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id BAC2F8FC23 for ; Wed, 25 Mar 2009 01:05:12 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 25 Mar 2009 01:05:10 -0000 Received: from p54866C1D.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.108.29] by mail.gmx.net (mp067) with SMTP; 25 Mar 2009 02:05:10 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX18THAtvXWAT6AkqK35unaqHu+18qaRpU3sMMKQ/D8 y+eHE2YfaBiGfN Message-ID: <49C9836A.40508@gmx.net> Date: Wed, 25 Mar 2009 02:05:46 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Sam Leffler References: <49C83038.40300@gmx.net> <49C93F39.7080804@freebsd.org> <49C9756F.4010206@gmx.net> <49C97AB2.6080500@freebsd.org> In-Reply-To: <49C97AB2.6080500@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:05:13 -0000 Sam Leffler wrote: > Daniel Thiele wrote: >> Sam Leffler wrote: >>> Daniel Thiele wrote: >>>> Hi, >>>> >>>> I have a problem with my wireless connection. I am running FreeBSD >>>> 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros >>>> based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a >>>> Ralink >>>> based USB adapter (Linksys WUSB54GC-EU via rum(4)). >>>> >>>> At home using the Atheros card together with a FreeBSD (7.1) based >>>> access point (using rum(4) in hostap mode) and the wpa_supplicant.conf >>>> (attached at the end of this email) settings for SSID="home" I don't >>>> have any problems. With a Linksys WRT54GL-DE access point >>>> running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open >>>> wireless LAN also works flawlessly. >>>> >>>> At the university, however, (SSID="IDA" in the wpa_supplicant.conf at >>>> the end of this email) the wireless connection only works for about an >>>> hour. The vague term "wireless connection" in this case means, that the >>>> WPA connection is opened and associated, then I get an IP address via >>>> dhclient. There is a message about "OpenSSL: tls_connection_handshake - >>>> Failed to read possible Application Data >>>> error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 >>>> EAP method 'MSCHAPv2'" but the authentication seems to succeed: >>>> >>> >>> Do you know if this is a regression w/ the 0.6.8 supplicant I recently >>> imported (i.e. relative to 0.5.11+HEAD)? >> >> Unfortunately I cannot answer that, since I have not been running >> CURRENT for that long. Is there a way I can help to test that? I still >> have my old notebook (7.1-STABLE running wpa_supplicant 0.5.10 with ipw >> and rum wireless adapters). I can get the logs from that machine, too, >> if that would help. > > You could rollback wpa_supplicant using svn/cvs but it's a bit painful > as the changes were extensive due to the switch from the 0.5 series > releases to 0.6. Alternatively you could rollback your entire tree to > r189262 (I think) and you'd have the previous code. > >> >>> Jouni just released a 0.6.9 >>> version and it appeared to have a fix that might be appropriate. I need >>> to digest your logs to understand but you can try importing 0.6.9 >>> yourself. >> >> I will give it a try. Just now I merged the diffs between 0.6.8 and >> 0.6.9 to my /usr/src. Except for >> wpa_supplicant-0.6.8/src/common/nl80211_copy.h, >> wpa_supplicant-0.6.9/src/l2_packet/l2_packet_linux.c and, >> wpa_supplicant-0.6.9/wpa_supplicant/Makefile >> I was able to apply the diffs. > > We do not use any of these files. You might be better off looking at > diff's between 0.6.8 and 0.6.9 and selectively applying changes to > usr/src/contrib/wpa. Some of these may be ignored as Jouni took back > some changes I provided him. That's what I did. Sorry, if I was too vague about that in my reply above. One thing I also noticed was that OID_802_3_MULTICAST_LIST which is used in 0.6.9's src/drivers/driver_ndis.c by ndis_add_multicast() does not seem to be defined anywhere in the 0.6.9 sources, which caused make in usr.sbin/wpa to fail. Since I am not using the NDIS driver I made ndis_add_multicast() return -1 to make make work again. > Note that usr.sbin/wpa/wpa_supplicant has the driver for freebsd and a > reach-over Makefile; we do not use Jouni's bsd driver or his build > structure. > >> >> I will try this at university on Thursday or Friday and report any >> success or failure here. > > I'll try to look at merging 0.6.9 quickly. > I am using the patched wpa_supplicant right now from home, so at least didn't break anything obvious. I will try either this setup or (preferred) your merged version at university and see how far I can get. Thanks, Daniel From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 01:23:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70CBE106567B for ; Wed, 25 Mar 2009 01:23:11 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E08B8FC13 for ; Wed, 25 Mar 2009 01:23:11 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 32241 invoked from network); 25 Mar 2009 00:56:30 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Mar 2009 00:56:30 -0000 Message-ID: <49C9813C.3070404@telenix.org> Date: Tue, 24 Mar 2009 20:56:28 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: barney_cordoba@yahoo.com References: <285790.99650.qm@web63903.mail.re1.yahoo.com> In-Reply-To: <285790.99650.qm@web63903.mail.re1.yahoo.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:23:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barney Cordoba wrote: > How do you enable root telnet access in current? I remember having some > issue with specifying pty/0 in ttys years ago in linux but the right > way to do it excapes me. I really wouldn't do that. If you have to get external root access, use ssh, but if you haven't been broken into yourself, it's FAR more likely that you just haven't seen it, than it hasn't happened. You don't want to allow folks into your machine, there isn't any such thing as honor among those folks. > > BC > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJgTwACgkQz62J6PPcoOnC6wCfeH8BgYJmKnD8C9r15hM3pXcB ua0AoJ2NZeS5+VhhsxUYrWRyUAd2THL8 =6H2U -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 03:07:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDFD410656FA; Wed, 25 Mar 2009 03:07:08 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id A69BC8FC1F; Wed, 25 Mar 2009 03:07:08 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2P35MXJ024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 23:05:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-nE5sWenLLz+4ktNCqiY4" Organization: FreeBSD Date: Tue, 24 Mar 2009 22:06:18 -0500 Message-Id: <1237950378.1829.13.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Adam McDougall , freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 03:07:09 -0000 --=-nE5sWenLLz+4ktNCqiY4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: > On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall wr= ote: > > Brandon Gooch wrote: > >> > >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote: > >> > >>> > >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >>> > >>>> > >>>> The committed version is working well, I am suspending and resuming > >>>> on my Lenovo X300. Thanks for your work on this, it is one of the > >>>> major things I needed to work so I could run FreeBSD primarily on > >>>> my notebook. > >>>> > >> > >> I just finished a kernel build and it seems as though your > >> recent commits have fixed the clock (at least for me)! > >> > >> I feel sorry for all the i386 folks on ACPI notebooks... > >> > >> Thanks! > >> > >> -Brandon > >> > > > > Picking a semi-random message here.. > > > > Thanks for your work on this! In the past (months ago) I tried the pat= ch > > set which didn't work, but the code in -current lets me suspend and res= ume > > successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think this i= s a > > first for me, of all the laptops I've had, none have ever been able to > > suspend and resume in a successful or useful way, and I've been jealous= of > > the Thinkpad users that could claim otherwise. I could suspend and res= ume > > fine while in the console, then I ran startx and the suspend and resume > > worked while I was in X with intel graphics, however my system was slow > > after that resume. I didn't spend much time looking at it since I was = at > > work, and I didn't see any obvious reasons for the slowness (cpu freque= ncy > > was fine, cx states were C2 or lower (C1), top showed mostly idle, no > > evidence of an IRQ storm) yet processes ran fairly sluggish (not the mo= use > > or typing though). I didn't go back to console, I just shut down witho= ut > > trying any other situations yet. > > > > A tip I want to note for any users who may not have success with their > > screen on resume: In the past it seemed to help me to have a power-on > > password set in my BIOS since the BIOS will turn on the screen on resum= e to > > ask me for my password. I don't know if it is still helping me, but I'= ve > > seen in the past where it has. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > >=20 > The sluggish response in X on Intel video has been an issue the past > couple of days, triggered by suspend/resume or simply switching to VTY > and back. I just committed code that should fix this... robert. > See this thread: > http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.html >=20 > Firefox is unusable, but xterms are still usable. I have to reboot to > get back to "normal" >=20 > -Brandon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-nE5sWenLLz+4ktNCqiY4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknJn6oACgkQM4TrQ4qfROPZlgCcCpL8FvY35MuKv2k8PsCa8zLy 7kkAn2eGIVyDh8BMPS54z0Z+XGS4ZRr7 =kbgh -----END PGP SIGNATURE----- --=-nE5sWenLLz+4ktNCqiY4-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 03:32:32 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D7CC1065670 for ; Wed, 25 Mar 2009 03:32:32 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id D40288FC15 for ; Wed, 25 Mar 2009 03:32:31 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2P3Yqjv017553; Tue, 24 Mar 2009 23:34:52 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2P3YpdK017552; Tue, 24 Mar 2009 23:34:51 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 24 Mar 2009 23:34:51 -0400 From: David Schultz To: Gustau Perez Message-ID: <20090325033451.GA17442@zim.MIT.EDU> Mail-Followup-To: Gustau Perez , freebsd-current@FreeBSD.ORG References: <49C80DBA.80407@entel.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C80DBA.80407@entel.upc.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 03:32:32 -0000 On Mon, Mar 23, 2009, Gustau Perez wrote: > a few time ago I switched to current, right now I've it updated to > yesterday. While compiling some ports (in fact, building x11/gnome2) I > found that some of them (written in C) are using some inline functions > (I guess it is because the compiler will replace the call to the > function with the function itself). The problem is that gcc fails with > the following message : > > error: nested function 'XXX' declared but never defined > > checking the code, the function is declared and then implemented in a > header file which is included in the offending .c file. The function is > declared as 'inline'. The only solution I found is to change the > definition to static. > > Checking pontyhat shows me that many ports are failing because of > this problem. What I can understand is why is this happening, because > the same ports compiles fine in STABLE and the compilers's version in > base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same > in current) Which other ports were broken for this reason? From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 03:40:44 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D5D410656D5 for ; Wed, 25 Mar 2009 03:40:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id E01B88FC20 for ; Wed, 25 Mar 2009 03:40:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 17718 invoked by uid 399); 25 Mar 2009 03:40:38 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 03:40:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49C9A7B4.3080509@FreeBSD.org> Date: Tue, 24 Mar 2009 20:40:36 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Gustau Perez , freebsd-current@FreeBSD.ORG References: <49C80DBA.80407@entel.upc.edu> <20090325033451.GA17442@zim.MIT.EDU> In-Reply-To: <20090325033451.GA17442@zim.MIT.EDU> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 03:40:44 -0000 David Schultz wrote: > On Mon, Mar 23, 2009, Gustau Perez wrote: >> a few time ago I switched to current, right now I've it updated to >> yesterday. While compiling some ports (in fact, building x11/gnome2) I >> found that some of them (written in C) are using some inline functions >> (I guess it is because the compiler will replace the call to the >> function with the function itself). The problem is that gcc fails with >> the following message : >> >> error: nested function 'XXX' declared but never defined >> >> checking the code, the function is declared and then implemented in a >> header file which is included in the offending .c file. The function is >> declared as 'inline'. The only solution I found is to change the >> definition to static. >> >> Checking pontyhat shows me that many ports are failing because of >> this problem. What I can understand is why is this happening, because >> the same ports compiles fine in STABLE and the compilers's version in >> base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same >> in current) > > Which other ports were broken for this reason? I am trying to compile gimp on -current right now and x11/babl and graphics/gegl both have this problem. Take a look at http://pointyhat.freebsd.org/errorlogs/i386-8-failure.html for more examples (click on the link on the right under Package to see the logs). There are currently over 600 broken ports in -current, all the ones I clicked on in a completely bogus sample had this same problem. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 03:54:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295B61065670; Wed, 25 Mar 2009 03:54:02 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 339E18FC20; Wed, 25 Mar 2009 03:54:00 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so2067568ewy.43 for ; Tue, 24 Mar 2009 20:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tyi1LIamZrmUZAdMcxvDLS4CWxAK8ZoNHyESWgP+vm0=; b=u0sXtClCy3txn4PX47yr3rHlwh++PS8XUY2uAmoTk1akCMUKTN3mVW/RHGBRqW7nFy HUaWEJ9ggDkMnyOVfqjhVuAYYYcQaJj2/m4A3yJGKqDs24Tmoqol6MXExiTxk3FAB1/N nAmW0A66S9f4PF0aKNAbxabBkCdkn1QdOp4nE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r835N2/M9nf/lsDHLdtCuR8I5H1zgDtjmpNqtSu4FlD1Kp9ZDIbbs4IVDMWUMhcpsT aUkLOrixB7rCGPewE5bEygNKV3k9DCGUZf57BikvoEsD3XCbbCR24KZzovppZ3YCbe63 HeZWMo8WQUFEbkRajP46gc6xiEUsOp4UwPgEg= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr6899461ebs.15.1237953240095; Tue, 24 Mar 2009 20:54:00 -0700 (PDT) In-Reply-To: <1237950378.1829.13.camel@balrog.2hip.net> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> Date: Tue, 24 Mar 2009 22:54:00 -0500 Message-ID: <179b97fb0903242054v30769c93t7ee8cf6318cdb90d@mail.gmail.com> From: Brandon Gooch To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 03:54:02 -0000 On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland wrote= : > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall w= rote: >> > Brandon Gooch wrote: >> >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote= : >> >> >> >>> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> >>> >> >>>> >> >>>> The committed version is working well, I am suspending and resuming >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of the >> >>>> major things I needed to work so I could run FreeBSD primarily on >> >>>> my notebook. >> >>>> >> >> >> >> I just finished a kernel build and it seems as though your >> >> recent commits have fixed the clock (at least for me)! >> >> >> >> I feel sorry for all the i386 folks on ACPI notebooks... >> >> >> >> Thanks! >> >> >> >> -Brandon >> >> >> > >> > Picking a semi-random message here.. >> > >> > Thanks for your work on this! =A0In the past (months ago) I tried the = patch >> > set which didn't work, but the code in -current lets me suspend and re= sume >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! =A0I think thi= s is a >> > first for me, of all the laptops I've had, none have ever been able to >> > suspend and resume in a successful or useful way, and I've been jealou= s of >> > the Thinkpad users that could claim otherwise. =A0I could suspend and = resume >> > fine while in the console, then I ran startx and the suspend and resum= e >> > worked while I was in X with intel graphics, however my system was slo= w >> > after that resume. =A0I didn't spend much time looking at it since I w= as at >> > work, and I didn't see any obvious reasons for the slowness (cpu frequ= ency >> > was fine, cx states were C2 or lower (C1), top showed mostly idle, no >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not the m= ouse >> > or typing though). =A0I didn't go back to console, I just shut down wi= thout >> > trying any other situations yet. >> > >> > A tip I want to note for any users who may not have success with their >> > screen on resume: =A0In the past it seemed to help me to have a power-= on >> > password set in my BIOS since the BIOS will turn on the screen on resu= me to >> > ask me for my password. =A0I don't know if it is still helping me, but= I've >> > seen in the past where it has. >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> > >> >> The sluggish response in X on Intel video has been an issue the past >> couple of days, triggered by suspend/resume or simply switching to VTY >> and back. > > I just committed code that should fix this... > > robert. > >> See this thread: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.htm= l >> >> Firefox is unusable, but xterms are still usable. I have to reboot to >> get back to "normal" >> >> -Brandon >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > -- > Robert Noland > FreeBSD > I just updated source to rev. 190402 and I'm rebuilding my system; I'll give it a shot. Thanks! -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 04:41:45 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B0710656C4 for ; Wed, 25 Mar 2009 04:41:45 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 849408FC08 for ; Wed, 25 Mar 2009 04:41:45 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2P4i8er034084; Wed, 25 Mar 2009 00:44:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2P4i858034083; Wed, 25 Mar 2009 00:44:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 25 Mar 2009 00:44:08 -0400 From: David Schultz To: Doug Barton Message-ID: <20090325044408.GB17442@zim.MIT.EDU> Mail-Followup-To: Doug Barton , Gustau Perez , freebsd-current@FreeBSD.ORG, ports@freebsd.org References: <49C80DBA.80407@entel.upc.edu> <20090325033451.GA17442@zim.MIT.EDU> <49C9A7B4.3080509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C9A7B4.3080509@FreeBSD.org> Cc: ports@FreeBSD.ORG, Gustau Perez , freebsd-current@FreeBSD.ORG Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 04:41:46 -0000 On Tue, Mar 24, 2009, Doug Barton wrote: > David Schultz wrote: > > On Mon, Mar 23, 2009, Gustau Perez wrote: > >> a few time ago I switched to current, right now I've it updated to > >> yesterday. While compiling some ports (in fact, building x11/gnome2) I > >> found that some of them (written in C) are using some inline functions > >> (I guess it is because the compiler will replace the call to the > >> function with the function itself). The problem is that gcc fails with > >> the following message : > >> > >> error: nested function 'XXX' declared but never defined > >> > >> checking the code, the function is declared and then implemented in a > >> header file which is included in the offending .c file. The function is > >> declared as 'inline'. The only solution I found is to change the > >> definition to static. > >> > >> Checking pontyhat shows me that many ports are failing because of > >> this problem. What I can understand is why is this happening, because > >> the same ports compiles fine in STABLE and the compilers's version in > >> base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same > >> in current) > > > > Which other ports were broken for this reason? > > I am trying to compile gimp on -current right now and x11/babl and > graphics/gegl both have this problem. Take a look at > http://pointyhat.freebsd.org/errorlogs/i386-8-failure.html for more > examples (click on the link on the right under Package to see the > logs). There are currently over 600 broken ports in -current, all the > ones I clicked on in a completely bogus sample had this same problem. My bug; I missed an important line when merging from gcc trunk 122565. Instead of reporting: error: nested function 'foo' declared but never defined gcc should have been reporting: warning: inline function 'foo' declared but never defined I'll check in a fix as soon as I run a buildworld. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 03:40:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A28D310656D3 for ; Wed, 25 Mar 2009 03:40:43 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1508FC1E for ; Wed, 25 Mar 2009 03:40:43 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 05A1C33C62 for ; Tue, 24 Mar 2009 20:40:43 -0700 (PDT) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id A999C33C5B for ; Tue, 24 Mar 2009 20:40:42 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18889.42937.62693.729218@already.local> Date: Tue, 24 Mar 2009 20:40:41 -0700 To: freebsd-current@freebsd.org X-Mailer: VM 8.0.12 under 22.3.1 (i386-apple-darwin9.6.0) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 25 Mar 2009 05:23:05 +0000 Subject: kernel won't boot after installing from snapshot, csup, then build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 03:40:43 -0000 I'm having a problem building up a current system. I did a minimal install from the amd64 CURRENT snapshot for 200902, the csup'ed using the standard-supfile, then did a buildworld, buildkernel, installkernel and reboot. I've been trying this daily for 3-4 days, thinking that maybe their was a temporary problem. I only have one machine (Via VB8001) from which to do the install but have tried the build and boot on both the VB8001 and a Gigabyte GA-6KIEH-RH. The kernel detects two CPUs, reports the ioapic0, then enters the debugger with: kernel trap 12 with interrupts disabled. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3c fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8056db2f stack pointer = 0x10:0xffffffff80f81c70 frame pointer = 0x10:0xffffffff80f81ca0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at devclass_find_internal+0x10f: orl $0x1, 0x3c(%rax) There's a photo of the full dump at http://shrimp.alerce.com/crash.jpg Any ideas what I've done wrong? g. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 06:12:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE331065674; Wed, 25 Mar 2009 06:12:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 694DB8FC0C; Wed, 25 Mar 2009 06:12:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2P6AgE6025619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 02:10:42 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: wsk In-Reply-To: <49C97EEB.4090607@gddsn.org.cn> References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-64XsY4RyTk9YedL/Mcaz" Organization: FreeBSD Date: Wed, 25 Mar 2009 01:11:37 -0500 Message-Id: <1237961497.1828.2.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, URIBL_RED autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 06:12:06 -0000 --=-64XsY4RyTk9YedL/Mcaz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 08:46 +0800, wsk wrote: > Robert Noland wrote: > > On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: > > =20 > >> Robert Noland wrote: > >> =20 > >>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > >>> =20 > >>> =20 > >>>>> Ok, this patch should work on NV50 chips also. > >>>>> =20 > >>>>> What you get is EXA and Xv. > >>>>> =20 > >>>>> You still need: > >>>>> =20 > >>>>> A recent -CURRENT or -STABLE. > >>>>> =20 > >>>>> git master of libdrm and xf86-video-nouveau. > >>>>> =20 > >>>>> This patch. > >>>>> =20 > >>>>> Things I've figured out since the last patch... > >>>>> =20 > >>>>> On NV50 class hardware you need to have a compositing manager runni= ng > >>>>> for Xv to work. That means xcompmgr, metacity with composite enabl= ed, > >>>>> xfce (rumored to work as well, haven't tried). If your running Gno= me > >>>>> with metacity, open gconf-editor and go to apps->metacity->general = and > >>>>> check the composite box. > >>>>> =20 > >>>>> On NV40 class hardware, you don't need the composite manager. In f= act > >>>>> (at least with Xserver 1.6 which I'm running now), if a composite > >>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under= some > >>>>> circumstances. I don't think this is a drm issue, but still an iss= ue. > >>>>> For me, if I start a video using mplayer in an xterm, cpu is fine a= s > >>>>> long as that xterm is the foreground window. If it is not the > >>>>> foreground window, even if it isn't obscured I see the cpu utilizat= ion. > >>>>> Disabling the composite manager makes everything fine. > >>>>> =20 > >>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > >>>>> =20 > >>>>> robert. > >>>>> =20 > >>>>> =20 > >>>> get the following errors and exitThis is a pre-release version of th= e X server from The X.Org Foundation. > >>>> It is not supported in any way. > >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >>>> Select the "xorg" product for bugs you find in this release. > >>>> Before reporting bugs in pre-release versions please check the > >>>> latest version in the X.Org Foundation git repository. > >>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > >>>> > >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >>>> Release Date: 2009-1-30 > >>>> X Protocol Version 11, Revision 0 > >>>> Build Operating System: FreeBSD 7.1-STABLE amd64 > >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE Fre= eBSD 7.2-PRE > >>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/us= r/obj/usr/sr > >>>> c/sys/WSK amd64 > >>>> Build Date: 06 February 2009 04:22:44PM > >>>> > >>>> Before reporting problems, check http://wiki.x.org > >>>> to make sure that you have the latest version. > >>>> Markers: (--) probed, (**) from config file, (=3D=3D) default settin= g, > >>>> (++) from command line, (!!) notice, (II) informational, > >>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown= . > >>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 = 2009 > >>>> ing config file: "xorg.conf1" > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x2 > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x2 > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x2 > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x1 > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x1 > >>>> drm0: [ITHREAD] > >>>> info: [drm] Allocating FIFO number 1 > >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >>>> (EE) Screen(s) found, but none have a usable configuration. > >>>> > >>>> Fatal server error: > >>>> no screens found > >>>> > >>>> Please consult the The X.Org Foundation support > >>>> at http://wiki.x.org > >>>> for help. > >>>> Please also check the log file at "/var/log/Xorg.0.log" for addition= al informati > >>>> on. > >>>> > >>>> info: [drm] nouveau_fifo_free: freeing fifo 1 > >>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle chann= el 1 before > >>>> destroy.Prepare for strangeness.. > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resou= rce 0x1 > >>>> > >>>> what can i do ? > >>>> > >>>> > >>>> > >>>> > >>>> plain text document attachment (Xorg.0.log) > >>>> This is a pre-release version of the X server from The X.Org Foundat= ion. > >>>> It is not supported in any way. > >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >>>> Select the "xorg" product for bugs you find in this release. > >>>> Before reporting bugs in pre-release versions please check the > >>>> latest version in the X.Org Foundation git repository. > >>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > >>>> > >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >>>> Release Date: 2009-1-30 > >>>> X Protocol Version 11, Revision 0 > >>>> Build Operating System: FreeBSD 7.1-STABLE amd64=20 > >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE Fre= eBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.c= n:/usr/obj/usr/src/sys/WSK amd64 > >>>> Build Date: 06 February 2009 04:22:44PM > >>>> =20 > >>>> Before reporting problems, check http://wiki.x.org > >>>> to make sure that you have the latest version. > >>>> Markers: (--) probed, (**) from config file, (=3D=3D) default settin= g, > >>>> (++) from command line, (!!) notice, (II) informational, > >>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 = 2009 > >>>> (++) Using config file: "xorg.conf1" > >>>> (=3D=3D) No Layout section. Using the first Screen section. > >>>> (=3D=3D) No screen section available. Using defaults. > >>>> (**) |-->Screen "Default Screen Section" (0) > >>>> (**) | |-->Monitor "" > >>>> (=3D=3D) No device specified for screen "Default Screen Section". > >>>> Using the first device section listed. > >>>> (**) | |-->Device "Card0" > >>>> (=3D=3D) No monitor specified for screen "Default Screen Section". > >>>> Using a default monitor configuration. > >>>> (=3D=3D) Automatically adding devices > >>>> (=3D=3D) Automatically enabling devices > >>>> (=3D=3D) No FontPath specified. Using compiled-in default. > >>>> (=3D=3D) FontPath set to: > >>>> built-ins > >>>> (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > >>>> (II) Cannot locate a core pointer device. > >>>> (II) Cannot locate a core keyboard device. > >>>> (II) The server relies on HAL to provide the list of input devices. > >>>> If no devices become available, reconfigure HAL or disable AllowEmp= tyInput. > >>>> (II) Loader magic: 0xb20 > >>>> (II) Module ABI versions: > >>>> X.Org ANSI C Emulation: 0.4 > >>>> X.Org Video Driver: 5.0 > >>>> X.Org XInput driver : 4.0 > >>>> X.Org Server Extension : 2.0 > >>>> (II) Loader running on freebsd > >>>> (--) Using syscons driver with X support (version 2.0) > >>>> (--) using VT number 9 > >>>> > >>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem = @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0= 000df00/128, BIOS @ 0x????????/65536 > >>>> =20 > >>>> =20 > >>> Ok, thats a new one... > >>> > >>> =20 > >>> =20 > >>>> (II) System resource ranges: > >>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >>>> (II) LoadModule: "extmod" > >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > >>>> (II) Module extmod: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>> Module class: X.Org Server Extension > >>>> ABI class: X.Org Server Extension, version 2.0 > >>>> (II) Loading extension MIT-SCREEN-SAVER > >>>> (II) Loading extension XFree86-VidModeExtension > >>>> (II) Loading extension XFree86-DGA > >>>> (II) Loading extension DPMS > >>>> (II) Loading extension XVideo > >>>> (II) Loading extension XVideo-MotionCompensation > >>>> (II) Loading extension X-Resource > >>>> (II) LoadModule: "dbe" > >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > >>>> (II) Module dbe: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>> Module class: X.Org Server Extension > >>>> ABI class: X.Org Server Extension, version 2.0 > >>>> (II) Loading extension DOUBLE-BUFFER > >>>> (II) LoadModule: "glx" > >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > >>>> (II) Module glx: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>> ABI class: X.Org Server Extension, version 2.0 > >>>> (=3D=3D) AIGLX disabled > >>>> (=3D=3D) Exporting typical set of GLX visuals > >>>> (II) Loading extension GLX > >>>> (II) LoadModule: "record" > >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > >>>> (II) Module record: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.13.0 > >>>> Module class: X.Org Server Extension > >>>> ABI class: X.Org Server Extension, version 2.0 > >>>> (II) Loading extension RECORD > >>>> (II) LoadModule: "dri" > >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > >>>> (II) Module dri: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>> ABI class: X.Org Server Extension, version 2.0 > >>>> (II) Loading extension XFree86-DRI > >>>> (II) LoadModule: "nouveau" > >>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so > >>>> (II) Module nouveau: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 0.0.10 > >>>> Module class: X.Org Video Driver > >>>> ABI class: X.Org Video Driver, version 5.0 > >>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 > >>>> (II) NOUVEAU driver for NVIDIA chipset families : > >>>> RIVA TNT (NV04) > >>>> RIVA TNT2 (NV05) > >>>> GeForce 256 (NV10) > >>>> GeForce 2 (NV11, NV15) > >>>> GeForce 4MX (NV17, NV18) > >>>> GeForce 3 (NV20) > >>>> GeForce 4Ti (NV25, NV28) > >>>> GeForce FX (NV3x) > >>>> GeForce 6 (NV4x) > >>>> GeForce 7 (G7x) > >>>> GeForce 8 (G8x) > >>>> (II) Primary Device is: PCI 01@00:00:0 > >>>> (II) resource ranges after probing: > >>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" > >>>> =20 > >>>> =20 > >>> Hrm, NV86... I'll have to ask around about that. Meanwhile can you s= end > >>> me a pciconf -lvb which should at least show us the BAR configuration= . > >>> > >>> Ok, my sources are telling me that this should work and that it is an > >>> NV50, or at least should work the same... > >>> > >>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess. = I'm > >>> not sure if it may be trashing the BARs somehow. > >>> > >>> robert. > >>> =20 > >>> =20 > >> bar [24] =3D type I/O Port, range 32, base 0xeff0, size 16, enabled > >> ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x01fe1028 chip=3D0x283e8= 086 > >> rev=3D0x02 hdr=3D0x00 > >> vendor =3D 'Intel Corporation' > >> device =3D '82801H (ICH8 Family) SMBus Controller' > >> class =3D serial bus > >> subclass =3D SMBus > >> bar [10] =3D type Memory, range 32, base 0xfebfbf00, size 256, enabled > >> bar [20] =3D type I/O Port, range 32, base 0x10c0, size 32, enabled > >> vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x01fe1028 chip=3D0x042910= de > >> rev=3D0xa1 hdr=3D0x00 > >> vendor =3D 'Nvidia Corp' > >> device =3D 'Unknown nVidia Quadro FX 570M' > >> class =3D display > >> subclass =3D VGA > >> bar [10] =3D type Memory, range 32, base 0xfd000000, size 16777216, en= abled > >> =20 > > > > Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 > > should be your framebuffer and should be where most of your memory is. > > (This is the memory the tell you about when you buy the card, 256M, > > 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 isn'= t > > there. We are going to need more details on your card... > > =20 > indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory= . > but it recognized Quadro FX 570M with pciconfig. So, the nouveau folks want me to get you to either boot linux and see what lspci shows for this card, or at least install the lspci port and see what it says. I don't think it is going to reveal anything, but who knows... This is not a driver issue at this point, the BARs just don't appear to be present. robert. > > =20 > >> bar [1c] =3D type Memory, range 64, base 0xfa000000, size 33554432, en= abled > >> =20 > > > > This one is BAR 3, which is used when it doesn't find BAR 1. > > > > robert. > > > > =20 > >> bar [24] =3D type I/O Port, range 32, base 0xdf00, size 128, enabled > >> ndis0@pci0:12:0:0: class=3D0x028000 card=3D0x000a1028 chip=3D0x432814e= 4 > >> rev=3D0x03 hdr=3D0x00 > >> vendor =3D 'Broadcom Corporation' > >> device =3D 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi So= lution' > >> class =3D network > >> bar [10] =3D type Memory, range 64, base 0xf9ffc000, size 16384, enabl= ed > >> bar [18] =3D type Prefetchable Memory, range 64, base 0xf0000000, size > >> 1048576, enabled > >> bge0@pci0:9:0:0: class=3D0x020000 card=3D0x01fe1028 chip=3D0x167314e4 = rev=3D0x02 > >> hdr=3D0x00 > >> vendor =3D 'Broadcom Corporation' > >> device =3D 'B57xx Broadcom NetXtreme Gigabit Ethernet' > >> class =3D network > >> subclass =3D ethernet > >> bar [10] =3D type Memory, range 64, base 0xf9bf0000, size 65536, enabl= ed > >> cbb0@pci0:3:1:0: class=3D0x060700 card=3D0x01fe1028 chip=3D0x71351217 = rev=3D0x21 > >> hdr=3D0x02 > >> vendor =3D 'O2 Micro Inc' > >> device =3D 'OZ711EZ1 MemoryCardBus Controller' > >> class =3D bridge > >> subclass =3D PCI-CardBus > >> bar [10] =3D type Memory, range 32, base 0xf9a00000, size 4096, enable= d > >> fwohci0@pci0:3:1:4: class=3D0x0c0010 card=3D0x01fe1028 chip=3D0x00f712= 17 > >> rev=3D0x02 hdr=3D0x00 > >> vendor =3D 'O2 Micro Inc' > >> device =3D '0x00f71217 1394 Open Host Controller Interface' > >> class =3D serial bus > >> subclass =3D FireWire > >> bar [10] =3D type Memory, range 32, base 0xf9aff000, size 4096, enable= d > >> bar [14] =3D type Memory, range 32, base 0xf9afe800, size 2048, enable= d > >> > >> and follow your intrudction.still pain me :( > >> > >> (++) Using config file: "xorg.conf1" > >> drm0: on vgapci0 > >> info: [drm] Detected an NV50 generation card (0x086900a2) > >> vgapci0: child drm0 requested pci_enable_busmaster > >> info: [drm] Initialized nouveau 0.0.12 20060213 > >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource= 0x2 > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource= 0x1 > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource= 0x1 > >> drm0: [ITHREAD] > >> info: [drm] Allocating FIFO number 1 > >> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, > >> invalid/inactiv > >> e channel id 128 > >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: > >> [drm] , nSt > >> atus:info: [drm] > >> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data > >> 0x00000000:0x00 > >> 000000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x800= 0003f > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6= f7f0e > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff= 7367f > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x000= 01850 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xaff= f3587 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800= b6fad > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df= 4fd60 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000= 000d7 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x313= 9768d > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d= 69757 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x631= 61650 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x072= 20009 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x000= 00000 > >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x000= 00000 > >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > >> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >> (EE) Screen(s) found, but none have a usable configuration. > >> > >> Fatal server error: > >> no screens found > >> > >> Please consult the The X.Org Foundation support > >> at http://wiki.x.org > >> for help. > >> Please also check the log file at "/var/log/Xorg.0.log" for additional > >> informati > >> on. > >> > >> info: [drm] nouveau_fifo_free: freeing fifo 1 > >> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel = 1 > >> before d > >> estroy.Prepare for strangeness.. > >> info: [drm] PFIFO_DMA_PUSHER - Ch 127 > >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffffff= fff). > >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource= 0x1 > >> > >> =20 > >>> =20 > >>> =20 > >>>> (II) Loading sub module "int10" > >>>> (II) LoadModule: "int10" > >>>> (II) Loading /usr/local/lib/xorg/modules//libint10.so > >>>> (II) Module int10: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>> ABI class: X.Org Video Driver, version 5.0 > >>>> (II) NOUVEAU(0): Initializing int10 > >>>> (=3D=3D) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was alr= eady clear > >>>> (=3D=3D) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was alr= eady clear > >>>> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 > >>>> (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already = clear > >>>> drmOpenDevice: node name is /dev/dri/card0 > >>>> drmOpenDevice: open result is 10, (OK) > >>>> drmOpenDevice: node name is /dev/dri/card0 > >>>> drmOpenDevice: open result is 10, (OK) > >>>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > >>>> drmOpenDevice: node name is /dev/dri/card0 > >>>> drmOpenDevice: open result is 10, (OK) > >>>> drmOpenByBusid: drmOpenMinor returns 10 > >>>> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > >>>> (II) [drm] DRM interface version 1.2 > >>>> (II) [drm] DRM open master succeeded. > >>>> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 > >>>> (--) NOUVEAU(0): [drm] kernel modesetting not available > >>>> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 > >>>> (II) NOUVEAU(0): Creating default Display subsection in Screen secti= on > >>>> "Default Screen Section" for depth/fbbpp 24/32 > >>>> (=3D=3D) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 > >>>> (=3D=3D) NOUVEAU(0): RGB weight 888 > >>>> (=3D=3D) NOUVEAU(0): Default visual is TrueColor > >>>> (II) Loading sub module "vgahw" > >>>> (II) LoadModule: "vgahw" > >>>> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > >>>> (II) Module vgahw: vendor=3D"X.Org Foundation" > >>>> compiled for 1.5.99.902, module version =3D 0.1.0 > >>>> ABI class: X.Org Video Driver, version 5.0 > >>>> (=3D=3D) NOUVEAU(0): Randr1.2 support enabled > >>>> (=3D=3D) NOUVEAU(0): Using HW cursor > >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >>>> (=3D=3D) NOUVEAU(0): Write-combining range (0x0,0x1000) was already = clear > >>>> (II) UnloadModule: "nouveau" > >>>> (II) UnloadModule: "vgahw" > >>>> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so > >>>> (II) UnloadModule: "int10" > >>>> (II) Unloading /usr/local/lib/xorg/modules//libint10.so > >>>> (EE) Screen(s) found, but none have a usable configuration. > >>>> > >>>> Fatal server error: > >>>> no screens found > >>>> > >>>> Please consult the The X.Org Foundation support=20 > >>>> at http://wiki.x.org > >>>> for help.=20 > >>>> Please also check the log file at "/var/log/Xorg.0.log" for addition= al information. > >>>> > >>>> =20 > >>>> =20 >=20 --=20 Robert Noland FreeBSD --=-64XsY4RyTk9YedL/Mcaz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknJyxkACgkQM4TrQ4qfROM8HQCgh4noJcp8kfkLZrQskK9zPG+L 7HUAnjasu2yKxK1lBB7dcpd0V1l7ak6C =xIXH -----END PGP SIGNATURE----- --=-64XsY4RyTk9YedL/Mcaz-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 08:35:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A34A0106566C; Wed, 25 Mar 2009 08:35:20 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id 594BF8FC21; Wed, 25 Mar 2009 08:35:20 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id 10CAB13344CB; Wed, 25 Mar 2009 09:15:36 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id sh0F2chBUZ4M; Wed, 25 Mar 2009 09:15:35 +0100 (CET) Received: from mac.local (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id 487D51334427; Wed, 25 Mar 2009 09:15:35 +0100 (CET) Message-ID: <49C9E829.7050600@FreeBSD.org> Date: Wed, 25 Mar 2009 09:15:37 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Doug Barton References: <5d97c6ec0903241231x73998539x1f8b52dcb75e3826@mail.gmail.com> <49C93E81.9080308@FreeBSD.org> In-Reply-To: <49C93E81.9080308@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nikolay Antsiferov Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 08:35:21 -0000 Doug Barton wrote: > Nikolay Antsiferov wrote: >> Hello. >> Yesterday i use mergemaster -F option after installworld. Worked good >> for me. All files that differ only by cvs tag were replaced. I update >> from 8.0-CURRENT-200902 to head sources. Thanks. > > Glad to hear it worked for you, and thank you for the success report! > Maybe we could add it to src/Makefile, so that people know about it? -- Best regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:13:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D524F106564A for ; Wed, 25 Mar 2009 09:13:13 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 015088FC16 for ; Wed, 25 Mar 2009 09:13:12 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 1020 invoked by uid 98); 25 Mar 2009 09:13:11 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9164. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.054321 secs); 25 Mar 2009 09:13:11 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Wed, 25 Mar 2009 09:13:11 +0000 Received: (qmail 62836 invoked by uid 1002); 25 Mar 2009 09:13:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Mar 2009 09:13:09 -0000 Date: Wed, 25 Mar 2009 09:13:09 +0000 (GMT) From: "Mark Powell" To: kevin In-Reply-To: <49BE4EC1.90207@163.com> Message-ID: <20090325090456.G92412@rust.salford.ac.uk> References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: ZFS data error without reasons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:13:14 -0000 Kevin, Did you fix your ZFS CRC errors? I responded to your thread, but no-one got back to me. I'm gonna start another thread later. This time I re-made the zpool in 8 compatible with 7. Once the errors started showing up in 8 I moved back to 7, on the same hardware, to perform the scrub to prove the problem is with 8. The 1st scrub in 7 found some errors, but of course it would if 8 had messed up the data. Removed the few unimportant bad files (all were in snapshots). Just performing the 2nd scrub in 7 now. If this comes back with no errors, then we have stronger proof that there is some wrong, which seems quite intermittent, in 8 that randomly writes bad data. Cheers. On Mon, 16 Mar 2009, kevin wrote: > Daniel Eriksson wrote: >> kevin wrote: >> >> >>> Hi, >>> Will any changes cause zfs data error?I find my disk data error without >>> any reasons(shutdown or reboot normally).disk was bought >>> yesterday.sometimes it can be fixed with a zpool scrub.but mostly zpool >>> scrub will return more errors.Even i restore all zpool from my >>> backup,without 5 mins,zpool status shows data error and many checksum >>> errors. >>> >> >> Is the drive connected to an "nVidia nForce MCP55 SATA300 controller"? I >> have two machines with on-board MCP55 controllers. One of them works >> perfectly, the other causes silent data corruption (each time I run a >> zpool scrub it finds new checksum errors). >> >> If you also have an MCP55 controller then maybe this is related. >> >> > My laptop is T61. RAM is also tested by memtest86+ and return no error. > "zfs send tank/usr/home/kevin@2009-03-15-16:51:21|zfs receive backup/kevin" > hangs system and i have to power off the machine.when the system up,i find > file error in snapshot tank/usr/home/kevin@2009-03-15-16:51:21.when i destroy > tank/usr/home/kevin@2009-03-15-16:51:21,then reboot system, i find more > errors. > > #zpool status -v > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub in progress for 0h10m, 96.10% done, 0h0m to go > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 2 > ad4s1d ONLINE 0 0 4 > > errors: Permanent errors have been detected in the following files: > > /usr/bin/less > /usr/lib/libstdc++.so.6 > /usr/bin/tbl > /usr/share/misc/termcap.db > /usr/bin/ssh-agent > /usr/local/bin/sudo > /usr/local/lib/libX11.so.6 > /usr/home/kevin/memtest86+-2.11.iso > > when zpool scrub end. > #zpool status -v > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub completed after 0h10m with 2 errors on Mon Mar 16 21:01:12 2009 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 2 > ad4s1d ONLINE 0 0 4 > > errors: Permanent errors have been detected in the following files: > > /usr/home/kevin/memtest86+-2.11.iso > > Should i just delete memtest86+-2.11.iso ? > > dmesg: > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0: Sun Mar 15 21:11:36 CST 2009 > root@datastream-laptop.people.163.org:/usr/obj/usr/src/sys/G8laptop > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.02-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > Cores per package: 2 > usable memory = 4210061312 (4015 MB) > avail memory = 4039487488 (3852 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or > length: 0 102C/0 [20070320] > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi_ec0: port 0x62,0x66 on acpi0 > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x207f mem > 0xd2000000-0xd2ffffff,0xe0000000-0xefffffff,0xd0000000-0xd1ffffff irq 16 at > device 0.0 on pci1 > em0: port 0x1840-0x185f mem > 0xfe200000-0xfe21ffff,0xfe225000-0xfe225fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:1c:25:1c:fb:d0 > uhci0: port 0x1860-0x187f irq 20 > at device 26.0 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x0000 > usbus0: on uhci0 > uhci1: port 0x1880-0x189f irq 21 > at device 26.1 on pci0 > uhci1: [ITHREAD] > uhci1: LegSup = 0x0000 > usbus1: on uhci1 > ehci0: mem > 0xfe226c00-0xfe226fff irq 22 at device 26.7 on pci0 > ehci0: [ITHREAD] > usbus2: EHCI version 1.0 > usbus2: on ehci0 > hdac0: mem > 0xfe220000-0xfe223fff irq 17 at device 27.0 on pci0 > hdac0: HDA Driver Revision: 20090226_0129 > hdac0: [ITHREAD] > pcib2: irq 20 at device 28.0 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pcib3: irq 21 at device 28.1 on pci0 > pci3: on pcib3 > iwn0: mem 0xd7dfe000-0xd7dfffff irq 17 at > device 0.0 on pci3 > iwn0: Reg Domain: MoW1, address 00:1d:e0:48:13:2f > iwn0: [ITHREAD] > iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps > 36Mbps 48Mbps 54Mbps > iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps > 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps > 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > pcib4: irq 22 at device 28.2 on pci0 > pci4: on pcib4 > pcib5: irq 23 at device 28.3 on pci0 > pci5: on pcib5 > pcib6: irq 20 at device 28.4 on pci0 > pci13: on pcib6 > uhci2: port 0x18a0-0x18bf irq 16 > at device 29.0 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup = 0x0000 > usbus3: on uhci2 > uhci3: port 0x18c0-0x18df irq 17 > at device 29.1 on pci0 > uhci3: [ITHREAD] > uhci3: LegSup = 0x0000 > usbus4: on uhci3 > uhci4: port 0x18e0-0x18ff irq 18 > at device 29.2 on pci0 > uhci4: [ITHREAD] > uhci4: LegSup = 0x0000 > usbus5: on uhci4 > ehci1: mem > 0xfe227000-0xfe2273ff irq 19 at device 29.7 on pci0 > ehci1: [ITHREAD] > usbus6: EHCI version 1.0 > usbus6: on ehci1 > pcib7: at device 30.0 on pci0 > pci21: on pcib7 > cbb0: mem 0xf8100000-0xf8100fff irq 16 at device > 0.0 on pci21 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [FILTER] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1830-0x183f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > atapci1: port > 0x1c48-0x1c4f,0x1c1c-0x1c1f,0x1c40-0x1c47,0x1c18-0x1c1b,0x1c20-0x1c3f mem > 0xfe226000-0xfe2267ff irq 16 at device 31.2 on pci0 > atapci1: [ITHREAD] > atapci1: AHCI Version 01.10 controller with 3 ports PM not supported > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Synaptics Touchpad, device ID 0 > battery0: on acpi0 > acpi_acad0: on acpi0 > acpi_ibm0: on acpi0 > cpu0: on acpi0 > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > orm0: at iomem > 0xc0000-0xcefff,0xcf000-0xcffff,0xd0000-0xd0fff,0xe0000-0xeffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 480Mbps High Speed USB v2.0 > ZFS filesystem version 13 > ZFS storage pool version 13 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen6.1: at usbus6 > uhub6: on usbus6 > acd0: DVDR at ata0-master UDMA33 > ad4: 305245MB at ata2-master SATA150 > hdac0: HDA Codec #0: Analog Devices AD1984 > hdac0: HDA Codec #1: Conexant (Unknown) > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > SMP: AP CPU #1 Launched! > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). > Root mount waiting for: usbus6 usbus2 > Root mount waiting for: usbus6 usbus2 > uhub2: 4 ports with 4 removable, self powered > uhub6: 6 ports with 6 removable, self powered > Root mount waiting for: usbus2 > Trying to mount root from ufs:/dev/ad4s1a > ugen0.2: at usbus0 > ubt0: on usbus0 > ugen0.3: at usbus0 > wlan0: Ethernet address: 00:1d:e0:48:13:2f > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > wlan0: link state changed to UP > iwn0: need multicast update callback > iwn0: need multicast update callback > iwn0: need multicast update callback > > Thanks, > kevin > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:25:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56756106566C for ; Wed, 25 Mar 2009 09:25:17 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id D28CD8FC19 for ; Wed, 25 Mar 2009 09:25:16 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2P9PEBh009816 for ; Wed, 25 Mar 2009 10:25:15 +0100 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032510251404:182981 ; Wed, 25 Mar 2009 10:25:14 +0100 Message-ID: <49C9F7F6.2000908@entel.upc.edu> Date: Wed, 25 Mar 2009 10:23:02 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49C80DBA.80407@entel.upc.edu> <20090325033451.GA17442@zim.MIT.EDU> In-Reply-To: <20090325033451.GA17442@zim.MIT.EDU> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 25/03/2009 10:25:14, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 25/03/2009 10:25:15, Serialize complete at 25/03/2009 10:25:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 25 Mar 2009 10:25:15 +0100 (CET) Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:25:17 -0000 >> >> Checking pontyhat shows me that many ports are failing because of >> this problem. What I can understand is why is this happening, because >> the same ports compiles fine in STABLE and the compilers's version in >> base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same >> in current) >> > > Which other ports were broken for this reason? > Well, I remember compiling all gnome (and dependences) in a row. I remember failing audio/faad, net-im/telepathy-mission-control, but I think others failed. I've just tried changing inline declarations to extern inline [return type/void] __attribute__((gnu_inline)) with a port that was failing (compiz-fusion-plugins-main) as I suggested previously and is compiling fine both in STABLE and in CURRENT. In the other hand, audio/faad in CURRENT compiles fine changing "INLINE void cfftf1" to "extern INLINE void cfft1 __attribute__((gnu_inline)) in libfaad/cfft.c around line 60 (please check one of my previous posts for details). In the case of faad, the function is never implemented :) but the other packages affected they implement the offending function/procedure. So instead of hacking gcc reverting the changes made to it in current, I think it would be wise to change the affected ports, as them will compile in both worlds. I can send PR's requesting the change for audio/faad net-im/telepathy-mission-control and x11-wm/compiz-fusion-plugins-main Greets, Gus From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:28:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49003106568B for ; Wed, 25 Mar 2009 09:28:43 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id DB7428FC1A for ; Wed, 25 Mar 2009 09:28:42 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 10:28:41 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2P9Seeu004011; Wed, 25 Mar 2009 10:28:40 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Wed, 25 Mar 2009 10:28:40 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090325092840.GA3841@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 25 Mar 2009 09:28:41.0326 (UTC) FILETIME=[15D5A8E0:01C9AD2C] Cc: vd@FreeBSD.org Subject: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:28:45 -0000 # cd /usr/ports/devel/pth vm-naranja# cvs up cvs update: Updating . cvs update: Updating files # make install ===> Installing for pth-2.0.7 ===> Generating temporary packing list ===> Checking if devel/pth already installed ./libtool --mode=compile --quiet cc -c -I. -O2 -pipe -fno-strict-aliasing -funro ll-loops -fstrength-reduce -fomit-frame-pointer -ffast-math pthread.c In file included from pth_p.h.in:35, from pthread.c:43: /usr/include/signal.h:75: error: conflicting types for 'pthread_kill' pthread.h:357: error: previous declaration of 'pthread_kill' was here *** Error code 1 Stop in /usr/ports/devel/pth/work/pth-2.0.7. *** Error code 1 Stop in /usr/ports/devel/pth. *** Error code 1 Stop in /usr/ports/devel/pth. work/pth-2.0.7/pthread.h:357 extern int pthread_kill(pthread_t, int); /usr/include/signal.h:75 #if __POSIX_VISIBLE || __XSI_VISIBLE int kill(__pid_t, int); int pthread_kill(__pthread_t, int); int pthread_sigmask(int, const __sigset_t *, __sigset_t *); Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:41:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 283AF1065743 for ; Wed, 25 Mar 2009 09:41:40 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from m12-11.163.com (m12-11.163.com [220.181.12.11]) by mx1.freebsd.org (Postfix) with SMTP id 6F6CC8FC24 for ; Wed, 25 Mar 2009 09:41:39 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from [127.0.0.1] (unknown [60.191.86.3]) by smtp7 (Coremail) with SMTP id C8CowLDL0kdN_MlJvBkDLA--.62373S2; Wed, 25 Mar 2009 17:41:34 +0800 (CST) Message-ID: <49C9FC53.8070104@163.com> Date: Wed, 25 Mar 2009 17:41:39 +0800 From: kevin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Powell References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090325090456.G92412@rust.salford.ac.uk> In-Reply-To: <20090325090456.G92412@rust.salford.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: C8CowLDL0kdN_MlJvBkDLA--.62373S2 X-Coremail-Antispam: 1Uf129KBjvdXoW7Gw1xZr4DCF4DZF13XF13Arb_yoWkCFX_u3 yvva4xAw13JF9rKFWavrs0yFZrGrW7Ww1UuryYkFnrJ345Ga98ZFnrZasaqr1xXa4rKr9x urnaqr18Aw17GjkaLaAFLSUrUUUUUbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUU TCb7IF0VCF04k20xv_GFyrM7k042IE42xK82IY64kIx2x0424lb7IF0VCFI7km07C26c80 4VAKzcIF0wAYjsxI4VWUCwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1I0E4x80FVCIwcAKzI AtM7C26IkvcIIF6IxKo4kEV4yl1IIY67AEw4v_Jr0_Jr4l84ACjcxK6xIIjxv20xvE14v2 6w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26rxl6s0DM28EF7xvwVC2z280aVAFwI 0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2vj6xkI62vS6c8GOVWUtr1r JFyl5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87 Iv67AKxVWxJVW8Jr1lF7xvr2IY64vIr41lFVAaXTZC67ZELSn0mTvEwaV2v3VFvVW8Mx02 cVAKzwCY02Avz4vE14v_GFWlc2IjII80xcxEwVWxJVW3JwCF04k20xvY0x0EwIxGrwCF72 vE52k0Y41lx4CE17CEb7AF67AKxVWUXVWUAbIYCTnIWIevJa73UjIFyTuYvj4RmzuXDUUU U X-CM-SenderInfo: pnhyx0x0ol03r26rljoofrz/ Cc: freebsd-current@freebsd.org Subject: Re: ZFS data error without reasons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:41:42 -0000 Mark Powell wrote: > Kevin, > Did you fix your ZFS CRC errors? > I responded to your thread, but no-one got back to me. > I'm gonna start another thread later. > This time I re-made the zpool in 8 compatible with 7. Once the errors > started showing up in 8 I moved back to 7, on the same hardware, to > perform the scrub to prove the problem is with 8. The 1st scrub in 7 > found some errors, but of course it would if 8 had messed up the data. > Removed the few unimportant bad files (all were in snapshots). > Just performing the 2nd scrub in 7 now. If this comes back with no > errors, then we have stronger proof that there is some wrong, which > seems quite intermittent, in 8 that randomly writes bad data. > Cheers. > Yes，I can fix some ZFS CRC errors,and sometimes i can recover all error files.Before i run "zpool import backup" to mount the zpool on a usb hard disk, "zpool status" return no errors. When i copy files to the usb hard disk,soon I can get lots of file errors.After a reboot,if i run scrub,i can fix many errors. I just think copy files between two zpools, one is on local hard disk and the other one is on a usb hard disk, may easily reproduce the bug. Thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:53:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 872021065675 for ; Wed, 25 Mar 2009 09:53:30 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 15D4B8FC1F for ; Wed, 25 Mar 2009 09:53:29 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n2P9rPqt048595; Wed, 25 Mar 2009 10:53:26 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n2P9rOgk048594; Wed, 25 Mar 2009 10:53:24 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 25 Mar 2009 10:53:24 +0100 From: Ruben de Groot To: Chuck Robey Message-ID: <20090325095324.GB48145@ei.bzerk.org> References: <285790.99650.qm@web63903.mail.re1.yahoo.com> <49C9813C.3070404@telenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C9813C.3070404@telenix.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 25 Mar 2009 10:53:28 +0100 (CET) Cc: barney_cordoba@yahoo.com, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:53:31 -0000 On Tue, Mar 24, 2009 at 08:56:28PM -0400, Chuck Robey typed: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Barney Cordoba wrote: > > How do you enable root telnet access in current? I remember having some > > issue with specifying pty/0 in ttys years ago in linux but the right > > way to do it excapes me. > > I really wouldn't do that. If you have to get external root access, use ssh, > but if you haven't been broken into yourself, it's FAR more likely that you just > haven't seen it, than it hasn't happened. You don't want to allow folks into > your machine, there isn't any such thing as honor among those folks. Sound advice, but not an answer to his question. Barney, you have to make the network pseudo ttys secure, like: ttyp0 none network secure Ruben From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:56:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F5B10656BC for ; Wed, 25 Mar 2009 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5BA8FC0C for ; Wed, 25 Mar 2009 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D310.dip.t-dialin.net [217.226.211.16]) by redbull.bpaserver.net (Postfix) with ESMTP id 0C0292E0A5; Wed, 25 Mar 2009 10:56:25 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 942BC204088; Wed, 25 Mar 2009 10:56:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1237974977; bh=wkF49RwHPsvwwQ4kXovLH4n7Q/ywMRF9e 4AdQPe+6p8=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HM7Q0/xL1JZJ/6AFwOsBSPXBRM1lB7ha5BQR3RizbpQgCFPakBiLFQdwhoW/cFIsa al4QnqEBwGJQ55pM5zPV2fHEvJqy1RPB6T1umJpr/PMvgL5vb57T2/QZgT5gb5pJY4Z yNoMjznNm3VKMk5c9dMQ15VhwSnCUywVBtQZ5WxlpviajWhbByVt10fbz0X1f5Wq6v8 eaKOo2EKZECshgpku0fgKvmThzmigkfEN5SX6+J5Vd8yMAFuX490FLhMES6+d14r4tQ qccxTEqNV8Xano26B9FA7vdKQejpZEtsB/TGrPSQav79h9Z85WPJIXXcXRRJrn0KkTq Hdma+nN4A== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2P9uFUx029225; Wed, 25 Mar 2009 10:56:15 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 25 Mar 2009 10:56:13 +0100 Message-ID: <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 25 Mar 2009 10:56:13 +0100 From: Alexander Leidinger To: Mark Powell References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> In-Reply-To: <20090320152737.D641@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0C0292E0A5.1BAEC X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.223, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_37 0.60, RDNS_DYNAMIC 0.10, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:56:30 -0000 Quoting Mark Powell (from Fri, 20 Mar 2009 =20 15:30:11 +0000 (GMT)): > On Fri, 20 Mar 2009, Mark Powell wrote: > >> As this same hardware worked, well with 7 for a long time, and can =20 >> work perfectly with 8 for several days until the errors strike, =20 >> this seems like some curious 8 problem? > > Hmmm. Perhaps I'm not being fair on 8. Just had a look at my =20 > loader.conf for 7 and I can see that I used to run with every =20 > zfs*disable on. I've just rebooted 8 with: > > vfs.zfs.cache_flush_disable: 1 > vfs.zfs.mdcomp_disable: 1 > vfs.zfs.prefetch_disable: 1 > vfs.zfs.zil_disable: 1 > hw.ata.wc: 1 > > The current fs which produced errors on every scrub now reports no errors. > I now need to find which option fixed it. > I suspect hw.ata.wc. Is this still a known issue? I would expect that it is the combination of cache_flush_disable and =20 zil_disable with the wc enable. If you reenable the zil and the cache =20 flush, the wc should not cause the problems you see. You may want to =20 have a look at =20 http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide =20 for a more detailed description of what those options are doing (and =20 why you should not disable those features on normal disks). I also =20 suggest to not disable the meta-data compression, as it seems it only =20 affects a small amount of meta-data instead of all meta-data. If you want to get more out of zfs, maybe vfs.zfs.vdev.max_pending =20 could help if you are using SATA (as I read the zfs tuning guide, it =20 makes sense to have a high value when you have command queueing, which =20 we have with SCSI drives, but not yet with SATA drives and probably =20 not at all with PATA drives). Bye, Alexander. --=20 QOTD: =09"I am not sure what this is, but an 'F' would only dignify it." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 10:45:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C41A106566B for ; Wed, 25 Mar 2009 10:45:47 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id A481C8FC16 for ; Wed, 25 Mar 2009 10:45:46 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 35407 invoked by uid 98); 25 Mar 2009 10:45:45 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9164. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.053142 secs); 25 Mar 2009 10:45:45 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Wed, 25 Mar 2009 10:45:45 +0000 Received: (qmail 69109 invoked by uid 1002); 25 Mar 2009 10:45:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Mar 2009 10:45:43 -0000 Date: Wed, 25 Mar 2009 10:45:43 +0000 (GMT) From: "Mark Powell" To: Alexander Leidinger In-Reply-To: <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> Message-ID: <20090325103721.G67233@rust.salford.ac.uk> References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:45:47 -0000 On Wed, 25 Mar 2009, Alexander Leidinger wrote: > Quoting Mark Powell (from Fri, 20 Mar 2009 > 15:30:11 +0000 (GMT)): >> Hmmm. Perhaps I'm not being fair on 8. Just had a look at my loader.conf >> for 7 and I can see that I used to run with every zfs*disable on. I've just >> rebooted 8 with: >> >> vfs.zfs.cache_flush_disable: 1 >> vfs.zfs.mdcomp_disable: 1 >> vfs.zfs.prefetch_disable: 1 >> vfs.zfs.zil_disable: 1 >> hw.ata.wc: 1 >> >> The current fs which produced errors on every scrub now reports no errors. >> I now need to find which option fixed it. >> I suspect hw.ata.wc. Is this still a known issue? Alex, Thanks for the input, > I would expect that it is the combination of cache_flush_disable and > zil_disable with the wc enable. If you reenable the zil and the cache flush, > the wc should not cause the problems you see. You may want to have a look at > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide for a > more detailed description of what those options are doing (and why you should > not disable those features on normal disks). I also suggest to not disable > the meta-data compression, as it seems it only affects a small amount of > meta-data instead of all meta-data. I initially ran 8 with default options i.e. write caching on, all zfs options left enabled. I got the errors. Only then did I try changing options, by turning off wc and disabling zfs options. It's a little curious that I should reenable the wc, and all zfs options except prefetch_disable. That takes me back to how I originally started, but with the solution to the problem therefore being disabling the prefetch. Can prefetch really cause these problems? And if so why? > If you want to get more out of zfs, maybe vfs.zfs.vdev.max_pending could help > if you are using SATA (as I read the zfs tuning guide, it makes sense to have > a high value when you have command queueing, which we have with SCSI drives, > but not yet with SATA drives and probably not at all with PATA drives). I'm running completely SATA with NCQ supporting drives. However, and possibly as you say, NCQ is not really/properly supported in FBSD? Many thanks for your time. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 05:34:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DF44106564A; Wed, 25 Mar 2009 05:34:39 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5218FC14; Wed, 25 Mar 2009 05:33:58 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from lp.gddsn.org.cn (unknown [218.19.164.153]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 3AEA02E00E; Wed, 25 Mar 2009 08:45:43 +0800 (CST) Message-ID: <49C97EEB.4090607@gddsn.org.cn> Date: Wed, 25 Mar 2009 08:46:35 +0800 From: wsk User-Agent: Thunderbird 2.0.0.19 (X11/20090204) MIME-Version: 1.0 To: Robert Noland References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> In-Reply-To: <1237882591.1771.26.camel@balrog.2hip.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Mar 2009 11:22:37 +0000 Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:34:40 -0000 Robert Noland wrote: > On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: > >> Robert Noland wrote: >> >>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: >>> >>> >>>>> Ok, this patch should work on NV50 chips also. >>>>> >>>>> What you get is EXA and Xv. >>>>> >>>>> You still need: >>>>> >>>>> A recent -CURRENT or -STABLE. >>>>> >>>>> git master of libdrm and xf86-video-nouveau. >>>>> >>>>> This patch. >>>>> >>>>> Things I've figured out since the last patch... >>>>> >>>>> On NV50 class hardware you need to have a compositing manager running >>>>> for Xv to work. That means xcompmgr, metacity with composite enabled, >>>>> xfce (rumored to work as well, haven't tried). If your running Gnome >>>>> with metacity, open gconf-editor and go to apps->metacity->general and >>>>> check the composite box. >>>>> >>>>> On NV40 class hardware, you don't need the composite manager. In fact >>>>> (at least with Xserver 1.6 which I'm running now), if a composite >>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some >>>>> circumstances. I don't think this is a drm issue, but still an issue. >>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as >>>>> long as that xterm is the foreground window. If it is not the >>>>> foreground window, even if it isn't obscured I see the cpu utilization. >>>>> Disabling the composite manager makes everything fine. >>>>> >>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >>>>> >>>>> robert. >>>>> >>>>> >>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation. >>>> It is not supported in any way. >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>> Select the "xorg" product for bugs you find in this release. >>>> Before reporting bugs in pre-release versions please check the >>>> latest version in the X.Org Foundation git repository. >>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>> >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>> Release Date: 2009-1-30 >>>> X Protocol Version 11, Revision 0 >>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE >>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/sr >>>> c/sys/WSK amd64 >>>> Build Date: 06 February 2009 04:22:44PM >>>> >>>> Before reporting problems, check http://wiki.x.org >>>> to make sure that you have the latest version. >>>> 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 Mar 23 09:14:03 2009 >>>> ing config file: "xorg.conf1" >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> drm0: [ITHREAD] >>>> info: [drm] Allocating FIFO number 1 >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>> (EE) Screen(s) found, but none have a usable configuration. >>>> >>>> Fatal server error: >>>> no screens found >>>> >>>> Please consult the The X.Org Foundation support >>>> at http://wiki.x.org >>>> for help. >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati >>>> on. >>>> >>>> info: [drm] nouveau_fifo_free: freeing fifo 1 >>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before >>>> destroy.Prepare for strangeness.. >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> >>>> what can i do ? >>>> >>>> >>>> >>>> >>>> plain text document attachment (Xorg.0.log) >>>> This is a pre-release version of the X server from The X.Org Foundation. >>>> It is not supported in any way. >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>> Select the "xorg" product for bugs you find in this release. >>>> Before reporting bugs in pre-release versions please check the >>>> latest version in the X.Org Foundation git repository. >>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>> >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>> Release Date: 2009-1-30 >>>> X Protocol Version 11, Revision 0 >>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64 >>>> Build Date: 06 February 2009 04:22:44PM >>>> >>>> Before reporting problems, check http://wiki.x.org >>>> to make sure that you have the latest version. >>>> 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 Mar 23 09:14:03 2009 >>>> (++) Using config file: "xorg.conf1" >>>> (==) No Layout section. Using the first Screen section. >>>> (==) No screen section available. Using defaults. >>>> (**) |-->Screen "Default Screen Section" (0) >>>> (**) | |-->Monitor "" >>>> (==) No device specified for screen "Default Screen Section". >>>> Using the first device section listed. >>>> (**) | |-->Device "Card0" >>>> (==) No monitor specified for screen "Default Screen Section". >>>> Using a default monitor configuration. >>>> (==) Automatically adding devices >>>> (==) Automatically enabling devices >>>> (==) No FontPath specified. Using compiled-in default. >>>> (==) FontPath set to: >>>> built-ins >>>> (==) ModulePath set to "/usr/local/lib/xorg/modules" >>>> (II) Cannot locate a core pointer device. >>>> (II) Cannot locate a core keyboard device. >>>> (II) The server relies on HAL to provide the list of input devices. >>>> If no devices become available, reconfigure HAL or disable AllowEmptyInput. >>>> (II) Loader magic: 0xb20 >>>> (II) Module ABI versions: >>>> X.Org ANSI C Emulation: 0.4 >>>> X.Org Video Driver: 5.0 >>>> X.Org XInput driver : 4.0 >>>> X.Org Server Extension : 2.0 >>>> (II) Loader running on freebsd >>>> (--) Using syscons driver with X support (version 2.0) >>>> (--) using VT number 9 >>>> >>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536 >>>> >>>> >>> Ok, thats a new one... >>> >>> >>> >>>> (II) System resource ranges: >>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>> (II) LoadModule: "extmod" >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so >>>> (II) Module extmod: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.0.0 >>>> Module class: X.Org Server Extension >>>> ABI class: X.Org Server Extension, version 2.0 >>>> (II) Loading extension MIT-SCREEN-SAVER >>>> (II) Loading extension XFree86-VidModeExtension >>>> (II) Loading extension XFree86-DGA >>>> (II) Loading extension DPMS >>>> (II) Loading extension XVideo >>>> (II) Loading extension XVideo-MotionCompensation >>>> (II) Loading extension X-Resource >>>> (II) LoadModule: "dbe" >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so >>>> (II) Module dbe: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.0.0 >>>> Module class: X.Org Server Extension >>>> ABI class: X.Org Server Extension, version 2.0 >>>> (II) Loading extension DOUBLE-BUFFER >>>> (II) LoadModule: "glx" >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so >>>> (II) Module glx: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.0.0 >>>> ABI class: X.Org Server Extension, version 2.0 >>>> (==) AIGLX disabled >>>> (==) Exporting typical set of GLX visuals >>>> (II) Loading extension GLX >>>> (II) LoadModule: "record" >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so >>>> (II) Module record: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.13.0 >>>> Module class: X.Org Server Extension >>>> ABI class: X.Org Server Extension, version 2.0 >>>> (II) Loading extension RECORD >>>> (II) LoadModule: "dri" >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so >>>> (II) Module dri: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.0.0 >>>> ABI class: X.Org Server Extension, version 2.0 >>>> (II) Loading extension XFree86-DRI >>>> (II) LoadModule: "nouveau" >>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so >>>> (II) Module nouveau: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 0.0.10 >>>> Module class: X.Org Video Driver >>>> ABI class: X.Org Video Driver, version 5.0 >>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 >>>> (II) NOUVEAU driver for NVIDIA chipset families : >>>> RIVA TNT (NV04) >>>> RIVA TNT2 (NV05) >>>> GeForce 256 (NV10) >>>> GeForce 2 (NV11, NV15) >>>> GeForce 4MX (NV17, NV18) >>>> GeForce 3 (NV20) >>>> GeForce 4Ti (NV25, NV28) >>>> GeForce FX (NV3x) >>>> GeForce 6 (NV4x) >>>> GeForce 7 (G7x) >>>> GeForce 8 (G8x) >>>> (II) Primary Device is: PCI 01@00:00:0 >>>> (II) resource ranges after probing: >>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" >>>> >>>> >>> Hrm, NV86... I'll have to ask around about that. Meanwhile can you send >>> me a pciconf -lvb which should at least show us the BAR configuration. >>> >>> Ok, my sources are telling me that this should work and that it is an >>> NV50, or at least should work the same... >>> >>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'm >>> not sure if it may be trashing the BARs somehow. >>> >>> robert. >>> >>> >> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled >> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801H (ICH8 Family) SMBus Controller' >> class = serial bus >> subclass = SMBus >> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled >> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled >> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de >> rev=0xa1 hdr=0x00 >> vendor = 'Nvidia Corp' >> device = 'Unknown nVidia Quadro FX 570M' >> class = display >> subclass = VGA >> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled >> > > Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 > should be your framebuffer and should be where most of your memory is. > (This is the memory the tell you about when you buy the card, 256M, > 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 isn't > there. We are going to need more details on your card... > indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory. but it recognized Quadro FX 570M with pciconfig. > >> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled >> > > This one is BAR 3, which is used when it doesn't find BAR 1. > > robert. > > >> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled >> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4 >> rev=0x03 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution' >> class = network >> bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled >> bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size >> 1048576, enabled >> bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02 >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'B57xx Broadcom NetXtreme Gigabit Ethernet' >> class = network >> subclass = ethernet >> bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled >> cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21 >> hdr=0x02 >> vendor = 'O2 Micro Inc' >> device = 'OZ711EZ1 MemoryCardBus Controller' >> class = bridge >> subclass = PCI-CardBus >> bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled >> fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217 >> rev=0x02 hdr=0x00 >> vendor = 'O2 Micro Inc' >> device = '0x00f71217 1394 Open Host Controller Interface' >> class = serial bus >> subclass = FireWire >> bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled >> bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled >> >> and follow your intrudction.still pain me :( >> >> (++) Using config file: "xorg.conf1" >> drm0: on vgapci0 >> info: [drm] Detected an NV50 generation card (0x086900a2) >> vgapci0: child drm0 requested pci_enable_busmaster >> info: [drm] Initialized nouveau 0.0.12 20060213 >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> drm0: [ITHREAD] >> info: [drm] Allocating FIFO number 1 >> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, >> invalid/inactiv >> e channel id 128 >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: >> [drm] , nSt >> atus:info: [drm] >> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data >> 0x00000000:0x00 >> 000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000 >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000 >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >> (EE) Screen(s) found, but none have a usable configuration. >> >> Fatal server error: >> no screens found >> >> Please consult the The X.Org Foundation support >> at http://wiki.x.org >> for help. >> Please also check the log file at "/var/log/Xorg.0.log" for additional >> informati >> on. >> >> info: [drm] nouveau_fifo_free: freeing fifo 1 >> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1 >> before d >> estroy.Prepare for strangeness.. >> info: [drm] PFIFO_DMA_PUSHER - Ch 127 >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >> >> >>> >>> >>>> (II) Loading sub module "int10" >>>> (II) LoadModule: "int10" >>>> (II) Loading /usr/local/lib/xorg/modules//libint10.so >>>> (II) Module int10: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 1.0.0 >>>> ABI class: X.Org Video Driver, version 5.0 >>>> (II) NOUVEAU(0): Initializing int10 >>>> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear >>>> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear >>>> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000 >>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear >>>> drmOpenDevice: node name is /dev/dri/card0 >>>> drmOpenDevice: open result is 10, (OK) >>>> drmOpenDevice: node name is /dev/dri/card0 >>>> drmOpenDevice: open result is 10, (OK) >>>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0 >>>> drmOpenDevice: node name is /dev/dri/card0 >>>> drmOpenDevice: open result is 10, (OK) >>>> drmOpenByBusid: drmOpenMinor returns 10 >>>> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 >>>> (II) [drm] DRM interface version 1.2 >>>> (II) [drm] DRM open master succeeded. >>>> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12 >>>> (--) NOUVEAU(0): [drm] kernel modesetting not available >>>> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3 >>>> (II) NOUVEAU(0): Creating default Display subsection in Screen section >>>> "Default Screen Section" for depth/fbbpp 24/32 >>>> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 >>>> (==) NOUVEAU(0): RGB weight 888 >>>> (==) NOUVEAU(0): Default visual is TrueColor >>>> (II) Loading sub module "vgahw" >>>> (II) LoadModule: "vgahw" >>>> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so >>>> (II) Module vgahw: vendor="X.Org Foundation" >>>> compiled for 1.5.99.902, module version = 0.1.0 >>>> ABI class: X.Org Video Driver, version 5.0 >>>> (==) NOUVEAU(0): Randr1.2 support enabled >>>> (==) NOUVEAU(0): Using HW cursor >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear >>>> (II) UnloadModule: "nouveau" >>>> (II) UnloadModule: "vgahw" >>>> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so >>>> (II) UnloadModule: "int10" >>>> (II) Unloading /usr/local/lib/xorg/modules//libint10.so >>>> (EE) Screen(s) found, but none have a usable configuration. >>>> >>>> Fatal server error: >>>> no screens found >>>> >>>> Please consult the The X.Org Foundation support >>>> at http://wiki.x.org >>>> for help. >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional information. >>>> >>>> >>>> From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 11:25:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36469106566C for ; Wed, 25 Mar 2009 11:25:21 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63905.mail.re1.yahoo.com (web63905.mail.re1.yahoo.com [69.147.97.120]) by mx1.freebsd.org (Postfix) with SMTP id D0BFB8FC13 for ; Wed, 25 Mar 2009 11:25:20 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 12334 invoked by uid 60001); 25 Mar 2009 11:25:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237980320; bh=MIn/Msu7rDJugtfUqHxtpEV1Kpz7Vrs1vzk6xsUWf3o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PwejEB1W7MINXxETHQ6i71F6cJWPctY+8aEir1GX/wpuqoBoo/FMVGr4hbY3XbVBNvz27YmfJLd8wrkiRxISJfaxQnFvi1ElyGXIu8c67SyxlTPV9ikq+r2vUdcYAeTMuf7lLkbiB1qHKZp6NAaF+jlA9pCz0oY50GLJfKXgz6g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jxqX/fSY2nSs3JV74+xvkrf10LjX0oWoqat6Jp8KLHQNXQHMge/ucUvcrA8BLMYhS2f5UdGdYJHYXtP4WxZDWpRyI+rRouM6tUP4ZtsMZrLtl0iA4ydUzRWGt9s2pW+fV7JgRtJ43TP4/Hb+qZGhUA1EcPCMjeokWCKDzasEClo=; Message-ID: <995845.90009.qm@web63905.mail.re1.yahoo.com> X-YMail-OSG: D2VwsxwVM1nsHqqYfkgSlehD.Rq.7qFJlIscJ84akQCLbkGt7tS5woI.EX0YmN_h3B0_NzMmmEma2QZJ2T9QkFGSwmSlhXnUHsFHxixJQo7IrU0OzmAptt6nW5VaC6kq_6wanPK6TskFltJRP1VFxiyYs2hLSoUlJ9bVhDNcs2iXwkDC1NBDpQ7olNDJTQc_nsctZ3SJRvolAcCmql.RilBFGK0l4gIHTtI- Received: from [98.242.222.229] by web63905.mail.re1.yahoo.com via HTTP; Wed, 25 Mar 2009 04:25:19 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 25 Mar 2009 04:25:19 -0700 (PDT) From: Barney Cordoba To: Chuck Robey , Ruben de Groot In-Reply-To: <20090325095324.GB48145@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 11:25:21 -0000 --- On Wed, 3/25/09, Ruben de Groot wrote: > From: Ruben de Groot > Subject: Re: Telnet root login > To: "Chuck Robey" > Cc: barney_cordoba@yahoo.com, current@freebsd.org > Date: Wednesday, March 25, 2009, 5:53 AM > On Tue, Mar 24, 2009 at 08:56:28PM -0400, Chuck Robey typed: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Barney Cordoba wrote: > > > How do you enable root telnet access in current? > I remember having some > > > issue with specifying pty/0 in ttys years ago in > linux but the right > > > way to do it excapes me. > > > > I really wouldn't do that. If you have to get > external root access, use ssh, > > but if you haven't been broken into yourself, > it's FAR more likely that you just > > haven't seen it, than it hasn't happened. You > don't want to allow folks into > > your machine, there isn't any such thing as honor > among those folks. > > Sound advice, but not an answer to his question. > Barney, you have to make the network pseudo ttys secure, > like: > > ttyp0 none network secure > > Ruben Yes, the "its not a good idea" is dependent on whatever other security you have in place. Having to log in twice to a test machine on a secure internal network is an unnecessary annoyance. The concept that every FreeBSD box in existence is publically accessible is one of those ASSumptions that people should leave at the door. Ruben, the method you cite no longer works in -current as they've changed things once again (which happens way too often when your CEOs are a bunch of bearded academics :) I'm not sure if its the pty (the login terminal shows as pty/0 and no longer ttyp0), or if its some PAM thing. Its rather annoying. Such things as pty/0 none network secure pty0 none network secure equally don't work. And I see no mention in any document as to how it would be achieved with the current Barney From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 08:37:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90DE5106564A; Wed, 25 Mar 2009 08:37:54 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 624DE8FC13; Wed, 25 Mar 2009 08:37:12 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id DDBD92E011; Wed, 25 Mar 2009 16:36:04 +0800 (CST) Message-ID: <49C9ED34.20504@gddsn.org.cn> Date: Wed, 25 Mar 2009 16:37:08 +0800 From: wsk User-Agent: Thunderbird 2.0.0.19 (X11/20090204) MIME-Version: 1.0 To: Robert Noland References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> <1237961497.1828.2.camel@balrog.2hip.net> In-Reply-To: <1237961497.1828.2.camel@balrog.2hip.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Mar 2009 11:48:12 +0000 Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 08:37:55 -0000 Robert Noland wrote: > On Wed, 2009-03-25 at 08:46 +0800, wsk wrote: > >> Robert Noland wrote: >> >>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: >>> >>> >>>> Robert Noland wrote: >>>> >>>> >>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: >>>>> >>>>> >>>>> >>>>>>> Ok, this patch should work on NV50 chips also. >>>>>>> >>>>>>> What you get is EXA and Xv. >>>>>>> >>>>>>> You still need: >>>>>>> >>>>>>> A recent -CURRENT or -STABLE. >>>>>>> >>>>>>> git master of libdrm and xf86-video-nouveau. >>>>>>> >>>>>>> This patch. >>>>>>> >>>>>>> Things I've figured out since the last patch... >>>>>>> >>>>>>> On NV50 class hardware you need to have a compositing manager running >>>>>>> for Xv to work. That means xcompmgr, metacity with composite enabled, >>>>>>> xfce (rumored to work as well, haven't tried). If your running Gnome >>>>>>> with metacity, open gconf-editor and go to apps->metacity->general and >>>>>>> check the composite box. >>>>>>> >>>>>>> On NV40 class hardware, you don't need the composite manager. In fact >>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite >>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some >>>>>>> circumstances. I don't think this is a drm issue, but still an issue. >>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as >>>>>>> long as that xterm is the foreground window. If it is not the >>>>>>> foreground window, even if it isn't obscured I see the cpu utilization. >>>>>>> Disabling the composite manager makes everything fine. >>>>>>> >>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >>>>>>> >>>>>>> robert. >>>>>>> >>>>>>> >>>>>>> >>>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation. >>>>>> It is not supported in any way. >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>>>> Select the "xorg" product for bugs you find in this release. >>>>>> Before reporting bugs in pre-release versions please check the >>>>>> latest version in the X.Org Foundation git repository. >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>>>> >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>>>> Release Date: 2009-1-30 >>>>>> X Protocol Version 11, Revision 0 >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE >>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/sr >>>>>> c/sys/WSK amd64 >>>>>> Build Date: 06 February 2009 04:22:44PM >>>>>> >>>>>> Before reporting problems, check http://wiki.x.org >>>>>> to make sure that you have the latest version. >>>>>> 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 Mar 23 09:14:03 2009 >>>>>> ing config file: "xorg.conf1" >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>> drm0: [ITHREAD] >>>>>> info: [drm] Allocating FIFO number 1 >>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>>>> (EE) Screen(s) found, but none have a usable configuration. >>>>>> >>>>>> Fatal server error: >>>>>> no screens found >>>>>> >>>>>> Please consult the The X.Org Foundation support >>>>>> at http://wiki.x.org >>>>>> for help. >>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati >>>>>> on. >>>>>> >>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1 >>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before >>>>>> destroy.Prepare for strangeness.. >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>> >>>>>> what can i do ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> plain text document attachment (Xorg.0.log) >>>>>> This is a pre-release version of the X server from The X.Org Foundation. >>>>>> It is not supported in any way. >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>>>> Select the "xorg" product for bugs you find in this release. >>>>>> Before reporting bugs in pre-release versions please check the >>>>>> latest version in the X.Org Foundation git repository. >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>>>> >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>>>> Release Date: 2009-1-30 >>>>>> X Protocol Version 11, Revision 0 >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64 >>>>>> Build Date: 06 February 2009 04:22:44PM >>>>>> >>>>>> Before reporting problems, check http://wiki.x.org >>>>>> to make sure that you have the latest version. >>>>>> 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 Mar 23 09:14:03 2009 >>>>>> (++) Using config file: "xorg.conf1" >>>>>> (==) No Layout section. Using the first Screen section. >>>>>> (==) No screen section available. Using defaults. >>>>>> (**) |-->Screen "Default Screen Section" (0) >>>>>> (**) | |-->Monitor "" >>>>>> (==) No device specified for screen "Default Screen Section". >>>>>> Using the first device section listed. >>>>>> (**) | |-->Device "Card0" >>>>>> (==) No monitor specified for screen "Default Screen Section". >>>>>> Using a default monitor configuration. >>>>>> (==) Automatically adding devices >>>>>> (==) Automatically enabling devices >>>>>> (==) No FontPath specified. Using compiled-in default. >>>>>> (==) FontPath set to: >>>>>> built-ins >>>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules" >>>>>> (II) Cannot locate a core pointer device. >>>>>> (II) Cannot locate a core keyboard device. >>>>>> (II) The server relies on HAL to provide the list of input devices. >>>>>> If no devices become available, reconfigure HAL or disable AllowEmptyInput. >>>>>> (II) Loader magic: 0xb20 >>>>>> (II) Module ABI versions: >>>>>> X.Org ANSI C Emulation: 0.4 >>>>>> X.Org Video Driver: 5.0 >>>>>> X.Org XInput driver : 4.0 >>>>>> X.Org Server Extension : 2.0 >>>>>> (II) Loader running on freebsd >>>>>> (--) Using syscons driver with X support (version 2.0) >>>>>> (--) using VT number 9 >>>>>> >>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536 >>>>>> >>>>>> >>>>>> >>>>> Ok, thats a new one... >>>>> >>>>> >>>>> >>>>> >>>>>> (II) System resource ranges: >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>>>> (II) LoadModule: "extmod" >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so >>>>>> (II) Module extmod: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>> Module class: X.Org Server Extension >>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>> (II) Loading extension MIT-SCREEN-SAVER >>>>>> (II) Loading extension XFree86-VidModeExtension >>>>>> (II) Loading extension XFree86-DGA >>>>>> (II) Loading extension DPMS >>>>>> (II) Loading extension XVideo >>>>>> (II) Loading extension XVideo-MotionCompensation >>>>>> (II) Loading extension X-Resource >>>>>> (II) LoadModule: "dbe" >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so >>>>>> (II) Module dbe: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>> Module class: X.Org Server Extension >>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>> (II) Loading extension DOUBLE-BUFFER >>>>>> (II) LoadModule: "glx" >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so >>>>>> (II) Module glx: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>> (==) AIGLX disabled >>>>>> (==) Exporting typical set of GLX visuals >>>>>> (II) Loading extension GLX >>>>>> (II) LoadModule: "record" >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so >>>>>> (II) Module record: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 1.13.0 >>>>>> Module class: X.Org Server Extension >>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>> (II) Loading extension RECORD >>>>>> (II) LoadModule: "dri" >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so >>>>>> (II) Module dri: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>> (II) Loading extension XFree86-DRI >>>>>> (II) LoadModule: "nouveau" >>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so >>>>>> (II) Module nouveau: vendor="X.Org Foundation" >>>>>> compiled for 1.5.99.902, module version = 0.0.10 >>>>>> Module class: X.Org Video Driver >>>>>> ABI class: X.Org Video Driver, version 5.0 >>>>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 >>>>>> (II) NOUVEAU driver for NVIDIA chipset families : >>>>>> RIVA TNT (NV04) >>>>>> RIVA TNT2 (NV05) >>>>>> GeForce 256 (NV10) >>>>>> GeForce 2 (NV11, NV15) >>>>>> GeForce 4MX (NV17, NV18) >>>>>> GeForce 3 (NV20) >>>>>> GeForce 4Ti (NV25, NV28) >>>>>> GeForce FX (NV3x) >>>>>> GeForce 6 (NV4x) >>>>>> GeForce 7 (G7x) >>>>>> GeForce 8 (G8x) >>>>>> (II) Primary Device is: PCI 01@00:00:0 >>>>>> (II) resource ranges after probing: >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" >>>>>> >>>>>> >>>>>> >>>>> Hrm, NV86... I'll have to ask around about that. Meanwhile can you send >>>>> me a pciconf -lvb which should at least show us the BAR configuration. >>>>> >>>>> Ok, my sources are telling me that this should work and that it is an >>>>> NV50, or at least should work the same... >>>>> >>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'm >>>>> not sure if it may be trashing the BARs somehow. >>>>> >>>>> robert. >>>>> >>>>> >>>>> >>>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled >>>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801H (ICH8 Family) SMBus Controller' >>>> class = serial bus >>>> subclass = SMBus >>>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled >>>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled >>>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de >>>> rev=0xa1 hdr=0x00 >>>> vendor = 'Nvidia Corp' >>>> device = 'Unknown nVidia Quadro FX 570M' >>>> class = display >>>> subclass = VGA >>>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled >>>> >>>> >>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 >>> should be your framebuffer and should be where most of your memory is. >>> (This is the memory the tell you about when you buy the card, 256M, >>> 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 isn't >>> there. We are going to need more details on your card... >>> >>> >> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory. >> but it recognized Quadro FX 570M with pciconfig. >> > > So, the nouveau folks want me to get you to either boot linux and see > what lspci shows for this card, or at least install the lspci port and > see what it says. I don't think it is going to reveal anything, but who > knows... This is not a driver issue at this point, the BARs just don't > appear to be present. > > robert. > > ok,here's my lspci -v messags with linux Fedora live CD :-) and thanks your Re 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) (prog-if 00 [VGA controller]) Subsystem: Dell Device 01fe Flags: bus master, fast devsel, latency 0, IRQ 5 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at fa000000 (64-bit, non-prefetchable) [size=32M] I/O ports at df00 [size=128] [virtual] Expansion ROM at fc000000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting Capabilities: [600] Vendor Specific Information Kernel modules: nvidiafb 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03) Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K] Memory at f0000000 (64-bit, prefetchable) [size=1M] Capabilities: [40] Power Management version 2 Capabilities: [58] Vendor Specific Information Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0 Capabilities: [16c] Power Budgeting Kernel driver in use: b43-pci-bridge Kernel modules: ssb >>> >>> >>>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled >>>> >>>> >>> This one is BAR 3, which is used when it doesn't find BAR 1. >>> >>> robert. >>> >>> >>> >>>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled >>>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4 >>>> rev=0x03 hdr=0x00 >>>> >>>> and follow your intrudction.still pain me :( >>>> >>>> (++) Using config file: "xorg.conf1" >>>> drm0: on vgapci0 >>>> info: [drm] Detected an NV50 generation card (0x086900a2) >>>> vgapci0: child drm0 requested pci_enable_busmaster >>>> info: [drm] Initialized nouveau 0.0.12 20060213 >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> drm0: [ITHREAD] >>>> info: [drm] Allocating FIFO number 1 >>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, >>>> invalid/inactiv >>>> e channel id 128 >>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: >>>> [drm] , nSt >>>> atus:info: [drm] >>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data >>>> 0x00000000:0x00 >>>> 000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000 >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000 >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>> (EE) Screen(s) found, but none have a usable configuration. >>>> >>>> Fatal server error: >>>> no screens found >>>> >>>> Please consult the The X.Org Foundation support >>>> at http://wiki.x.org >>>> for help. >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional >>>> informati >>>> on. >>>> >>>> info: [drm] nouveau_fifo_free: freeing fifo 1 >>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1 >>>> before d >>>> estroy.Prepare for strangeness.. >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127 >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>> >>>> From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 10:06:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81297106566B for ; Wed, 25 Mar 2009 10:06:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6416A8FC15 for ; Wed, 25 Mar 2009 10:06:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id C5E458C06A; Wed, 25 Mar 2009 05:06:57 -0500 (CDT) Date: Wed, 25 Mar 2009 05:06:57 -0500 From: Mark Linimon To: Gustau Perez Message-ID: <20090325100657.GA31530@lonesome.com> References: <49C80DBA.80407@entel.upc.edu> <20090325033451.GA17442@zim.MIT.EDU> <49C9F7F6.2000908@entel.upc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C9F7F6.2000908@entel.upc.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 25 Mar 2009 11:48:41 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:06:59 -0000 On Wed, Mar 25, 2009 at 10:23:02AM +0100, Gustau Perez wrote: > So instead of hacking gcc reverting the changes made to it in current, > I think it would be wise to change the affected ports There are ~200 and counting. I am working on updating the package build machine's classification scripts to isolate them. > I can send PR's requesting the change for audio/faad > net-im/telepathy-mission-control already fixed. > and x11-wm/compiz-fusion-plugins-main There's not one for that one yet. mcl From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 12:49:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C238106566B for ; Wed, 25 Mar 2009 12:49:19 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 969E38FC17 for ; Wed, 25 Mar 2009 12:49:18 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LmSXj-0000rQ-43; Wed, 25 Mar 2009 14:49:15 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LmSXe-000IqH-QM; Wed, 25 Mar 2009 14:49:10 +0200 To: barney_cordoba@yahoo.com From: Ian FREISLICH In-Reply-To: <995845.90009.qm@web63905.mail.re1.yahoo.com> References: <995845.90009.qm@web63905.mail.re1.yahoo.com> X-Attribution: BOFH Date: Wed, 25 Mar 2009 14:49:10 +0200 Message-Id: Cc: Ruben de Groot , Chuck Robey , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 12:49:19 -0000 Barney Cordoba wrote: > > Barney, you have to make the network pseudo ttys secure, > > like: > > > > ttyp0 none network secure > > > > Ruben > > Yes, the "its not a good idea" is dependent on whatever other > security you have in place. Having to log in twice to a test > machine on a secure internal network is an unnecessary annoyance. > The concept that every FreeBSD box in existence is publically accessible > is one of those ASSumptions that people should leave at the door. > > Ruben, the method you cite no longer works in -current as they've > changed things once again (which happens way too often when your CEOs > are a bunch of bearded academics :) > > I'm not sure if its the pty (the login terminal shows as pty/0 and > no longer ttyp0), or if its some PAM thing. Its rather annoying. > Such things as > > pty/0 none network secure > pty0 none network secure > > equally don't work. And I see no mention in any document as to how it > would be achieved with the current Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 12:52:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B3410658A2 for ; Wed, 25 Mar 2009 12:52:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD398FC12 for ; Wed, 25 Mar 2009 12:52:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B582346B03; Wed, 25 Mar 2009 08:52:17 -0400 (EDT) Date: Wed, 25 Mar 2009 12:52:17 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <995845.90009.qm@web63905.mail.re1.yahoo.com> Message-ID: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ruben de Groot , Chuck Robey , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 12:52:22 -0000 On Wed, 25 Mar 2009, Barney Cordoba wrote: > I'm not sure if its the pty (the login terminal shows as pty/0 and no longer > ttyp0), or if its some PAM thing. Its rather annoying. Such things as Try "pts/0 none network secure"? I've not done this in ages, but I believe the principle should still apply. If it doesn't, it's probably a bug. Robert N M Watson Computer Laboratory University of Cambridge > > pty/0 none network secure > pty0 none network secure > > equally don't work. And I see no mention in any document as to how it > would be achieved with the current > > Barney > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 12:55:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5034B1065689 for ; Wed, 25 Mar 2009 12:55:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id A9E1E8FC16 for ; Wed, 25 Mar 2009 12:55:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D310.dip.t-dialin.net [217.226.211.16]) by redbull.bpaserver.net (Postfix) with ESMTP id CEEBD2E0A5; Wed, 25 Mar 2009 13:55:33 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 743692042E4; Wed, 25 Mar 2009 13:55:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1237985730; bh=Iy8p41orq8CiFH4VNqNNv1m0MrvWmRXHI iOa74pMUV8=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UkBpZOrFL51QyGwKHJ4rQZVCQ07waXBRTKDGwOPg94X2zbPoEQoF8GoSchqRiHjzf oTPAaXs0yPgmJtRxN13YrpZKddwkYxhc26exBq7PqdQfV/Iur6luESA8GeeBMvwxTBv vEm6yokX0prwZWTChfaS/j1Q1tKhzP7GAJBQio5qQ4pkZVxByNqUnDv5wRoVTeEdhMg EDK26C3wHyA3vEljM+bSc91Qf0W6lgnc65do8VE09+zdILY3mHmmMMr3XtBMb4b22Xw qpv77+4cfKzvLkeXLRuSjZHle/dMdDLNRmWyCTksMDdYhalsF1pnzxaKlcrJllspnYH ZibQkS2Yw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2PCtTaR050983; Wed, 25 Mar 2009 13:55:29 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 25 Mar 2009 13:55:28 +0100 Message-ID: <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 25 Mar 2009 13:55:28 +0100 From: Alexander Leidinger To: Mark Powell References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> In-Reply-To: <20090325103721.G67233@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: CEEBD2E0A5.B8BA6 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-12.827, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_37 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 12:55:42 -0000 Quoting Mark Powell (from Wed, 25 Mar 2009 =20 10:45:43 +0000 (GMT)): > On Wed, 25 Mar 2009, Alexander Leidinger wrote: > >> Quoting Mark Powell (from Fri, 20 Mar =20 >> 2009 15:30:11 +0000 (GMT)): >>> Hmmm. Perhaps I'm not being fair on 8. Just had a look at my =20 >>> loader.conf for 7 and I can see that I used to run with every =20 >>> zfs*disable on. I've just rebooted 8 with: >>> >>> vfs.zfs.cache_flush_disable: 1 >>> vfs.zfs.mdcomp_disable: 1 >>> vfs.zfs.prefetch_disable: 1 >>> vfs.zfs.zil_disable: 1 >>> hw.ata.wc: 1 >>> >>> The current fs which produced errors on every scrub now reports no error= s. >>> I now need to find which option fixed it. >>> I suspect hw.ata.wc. Is this still a known issue? > > Alex, > Thanks for the input, > >> I would expect that it is the combination of cache_flush_disable =20 >> and zil_disable with the wc enable. If you reenable the zil and the =20 >> cache flush, the wc should not cause the problems you see. You may =20 >> want to have a look at =20 >> http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide for = a =20 >> more detailed description of what those options are doing (and why =20 >> you should not disable those features on normal disks). I also =20 >> suggest to not disable the meta-data compression, as it seems it =20 >> only affects a small amount of meta-data instead of all meta-data. > > I initially ran 8 with default options i.e. write caching on, all =20 > zfs options left enabled. I got the errors. Only then did I try =20 > changing options, by turning off wc and disabling zfs options. > It's a little curious that I should reenable the wc, and all zfs =20 > options except prefetch_disable. That takes me back to how I =20 > originally started, but with the solution to the problem therefore =20 > being disabling the prefetch. > Can prefetch really cause these problems? And if so why? I don't think so. I missed the part where you explained this before. =20 In this case it's really the write cache. The interesting questions is =20 if this is because of the harddisks you use, or because of a bug in =20 the software. You run a very recent current? 1-2 weeks before there was a bug (not =20 in ZFS) which caused CRC errors, but it was fixed shortly after it was =20 noticed. If you haven't updated your system, it may be best to update =20 it and try again. Please report back. >> If you want to get more out of zfs, maybe vfs.zfs.vdev.max_pending =20 >> could help if you are using SATA (as I read the zfs tuning guide, =20 >> it makes sense to have a high value when you have command queueing, =20 >> which we have with SCSI drives, but not yet with SATA drives and =20 >> probably not at all with PATA drives). > > I'm running completely SATA with NCQ supporting drives. However, and =20 > possibly as you say, NCQ is not really/properly supported in FBSD? NCQ is not supported yet in FreeBSD. Alexander Motin said he is =20 interested in implementing it, but I don't know about the status of =20 this. Bye, Alexander. --=20 Your business will assume vast proportions. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 12:56:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A0A2106579D; Wed, 25 Mar 2009 12:56:57 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCB108FC1F; Wed, 25 Mar 2009 12:56:56 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n2PCuqcC049439; Wed, 25 Mar 2009 13:56:52 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n2PCuq6s049438; Wed, 25 Mar 2009 13:56:52 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 25 Mar 2009 13:56:51 +0100 From: Ruben de Groot To: Robert Watson Message-ID: <20090325125651.GA49416@ei.bzerk.org> References: <995845.90009.qm@web63905.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 25 Mar 2009 13:56:55 +0100 (CET) Cc: Barney Cordoba , Ruben de Groot , Chuck Robey , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 12:56:57 -0000 On Wed, Mar 25, 2009 at 12:52:17PM +0000, Robert Watson typed: > > On Wed, 25 Mar 2009, Barney Cordoba wrote: > > >I'm not sure if its the pty (the login terminal shows as pty/0 and no > >longer ttyp0), or if its some PAM thing. Its rather annoying. Such things > >as > > Try "pts/0 none network secure"? I've not done this in ages, but I believe > the principle should still apply. If it doesn't, it's probably a bug. works for me: morninglightmountain# grep secure /etc/ttys|grep pts pts/0 none network secure pts/1 none network secure pts/2 none network secure pts/3 none network secure pts/4 none network secure pts/5 none network secure morninglightmountain# uname -a FreeBSD morninglightmountain.hacktor.net 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri Feb 13 09:08:59 UTC 2009 root@morninglightmountain.hacktor.net:/usr/obj/usr/src/sys/MORNINGLIGHTMOUNTAIN sparc64 morninglightmountain# telnet localhost Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Trying SRA secure login: User (root): Password: [ SRA accepts you ] From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 13:49:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B895B1065677 for ; Wed, 25 Mar 2009 13:49:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9331C8FC22 for ; Wed, 25 Mar 2009 13:49:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LmTTJ-000OfH-KR; Wed, 25 Mar 2009 13:48:45 +0000 Received: from dhcp-17e8.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id 7733E416450; Wed, 25 Mar 2009 06:48:45 -0700 (PDT) Date: Wed, 25 Mar 2009 06:48:45 -0700 Message-ID: From: Randy Bush To: Ian FREISLICH In-Reply-To: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: barney_cordoba@yahoo.com, Ruben de Groot , Chuck Robey , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 13:49:03 -0000 > Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config i am fond of PermitRootLogin without-password randy From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 13:49:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF9BB1065709 for ; Wed, 25 Mar 2009 13:49:11 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 1A8D38FC18 for ; Wed, 25 Mar 2009 13:49:10 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 99031 invoked by uid 98); 25 Mar 2009 13:49:10 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9164. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.043189 secs); 25 Mar 2009 13:49:10 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Wed, 25 Mar 2009 13:49:09 +0000 Received: (qmail 81535 invoked by uid 1002); 25 Mar 2009 13:49:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Mar 2009 13:49:07 -0000 Date: Wed, 25 Mar 2009 13:49:07 +0000 (GMT) From: "Mark Powell" To: Alexander Leidinger In-Reply-To: <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> Message-ID: <20090325125930.U73916@rust.salford.ac.uk> References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 13:49:13 -0000 On Wed, 25 Mar 2009, Alexander Leidinger wrote: >> Can prefetch really cause these problems? And if so why? > > I don't think so. I missed the part where you explained this before. In > this case it's really the write cache. The interesting questions is if > this is because of the harddisks you use, or because of a bug in the > software. > > You run a very recent current? 1-2 weeks before there was a bug (not in > ZFS) which caused CRC errors, but it was fixed shortly after it was > noticed. If you haven't updated your system, it may be best to update it > and try again. Please report back. I'm running recent current. I too saw that there were bugs causing CRC errors, and hoped that the relevant fixes would help me out. Unfortunately not. I most recently remade the whole array again with current from last Thursday 19th March. I tried it with WC disabled, but performance is awful. I expected, obviously a little worse, but not to be noticable without benchmarks? Well restoring my 1st LTO2 200GB tape (should take 1h45-2hrs), after 3h30 it was only about halfway through the tape, so I gave up. Hoping, possibly in vain, that it was a ZFS option causing the issue. The drives in question are: ad24 Device Model: WDC WD10EADS-00L5B1 ad22 Device Model: WDC WD10EADS-00L5B1 ad20 Device Model: WDC WD10EADS-00L5B1 ad18 Device Model: WDC WD10EADS-00L5B1 ad16 Device Model: WDC WD10EADS-00L5B1 ad14 Device Model: WDC WD10EADS-00L5B1 ad10 Device Model: WDC WD5000AAKS-22TMA0 ad8 Device Model: WDC WD5000AAKS-65TMA0 The WD5000AAKS were used for around 18 months in the previous 9x500GB RAIDZ2 on 7, so I would expect them to be ok. I've had the WD10EADS for about 2 months. However, I did replace the drives in the old 9x500GB RAIDZ2, with each of the new drives to check they were ok, resilvering them, one at a time, into the array i.e. eventually I was running 3x500GB+6X1TB in the still logically 9x500GB RAIDZ2. Yes, this would only check the lower 500GB of each 1TB drive, but surely that's enough of a test? AFAICT, I had WC off in 7 though. On my most recent failure I do see: ----- # zpool status -v pool: pool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub in progress, 40.02% done, 3h54m to go config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 42 raidz2 ONLINE 0 0 42 stripe/str0 ONLINE 0 0 0 ad14 ONLINE 0 0 4 ad16 ONLINE 0 0 2 ad18 ONLINE 0 0 3 ad20 ONLINE 0 0 7 ad22 ONLINE 0 0 4 ad24 ONLINE 0 0 5 ----- i.e. no errors on the 2x500GB stripe. That would seem to suggest firmware write caching bugs on the 1TB drives. However, my other error report had: ----- pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 0h51m with 0 errors on Fri Mar 20 10:57:18 2009 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 raidz2 ONLINE 0 0 23 stripe/str0 ONLINE 0 0 489 12.3M repaired ad14 ONLINE 0 0 786 19.7M repaired ad16 ONLINE 0 0 804 20.1M repaired ad18 ONLINE 0 0 754 18.8M repaired ad20 ONLINE 0 0 771 19.3M repaired ad22 ONLINE 0 0 808 20.2M repaired ad24 ONLINE 0 0 848 21.2M repaired errors: No known data errors ----- i.e. errors on the stripe, but the stripe error count seems to be just over half of that a 1TB drive. If the errors we spread evenly, one would expect 2x the amount of CRC errors on the stripe? >>> If you want to get more out of zfs, maybe vfs.zfs.vdev.max_pending could >>> help if you are using SATA (as I read the zfs tuning guide, it makes sense >>> to have a high value when you have command queueing, which we have with >>> SCSI drives, but not yet with SATA drives and probably not at all with >>> PATA drives). >> >> I'm running completely SATA with NCQ supporting drives. However, and >> possibly as you say, NCQ is not really/properly supported in FBSD? > > NCQ is not supported yet in FreeBSD. Alexander Motin said he is interested in > implementing it, but I don't know about the status of this. Ok. So vfs.zfs.vdev.max_pending is irrelevant for SATA currently? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 14:09:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 788DB1065679; Wed, 25 Mar 2009 14:09:10 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3854C8FC17; Wed, 25 Mar 2009 14:09:10 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: by muon.cran.org.uk (Postfix, from userid 1000) id 268911924A; Wed, 25 Mar 2009 14:09:09 +0000 (GMT) Date: Wed, 25 Mar 2009 14:09:09 +0000 From: Bruce Cran To: Matthias Apitz Message-ID: <20090325140908.GA14343@muon.cran.org.uk> References: <20090325092840.GA3841@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325092840.GA3841@rebelion.Sisis.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: vd@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:09:11 -0000 On Wed, Mar 25, 2009 at 10:28:40AM +0100, Matthias Apitz wrote: > > > # cd /usr/ports/devel/pth > vm-naranja# cvs up > cvs update: Updating . > cvs update: Updating files > > # make install > ===> Installing for pth-2.0.7 > ===> Generating temporary packing list > ===> Checking if devel/pth already installed > ./libtool --mode=compile --quiet cc -c -I. -O2 -pipe > -fno-strict-aliasing -funro > ll-loops -fstrength-reduce -fomit-frame-pointer -ffast-math pthread.c > In file included from pth_p.h.in:35, > from pthread.c:43: > /usr/include/signal.h:75: error: conflicting types for 'pthread_kill' > pthread.h:357: error: previous declaration of 'pthread_kill' was here > *** Error code 1 > > Stop in /usr/ports/devel/pth/work/pth-2.0.7. > *** Error code 1 > > Stop in /usr/ports/devel/pth. > *** Error code 1 > > Stop in /usr/ports/devel/pth. > > > work/pth-2.0.7/pthread.h:357 > extern int pthread_kill(pthread_t, int); > > > /usr/include/signal.h:75 > #if __POSIX_VISIBLE || __XSI_VISIBLE > int kill(__pid_t, int); > int pthread_kill(__pthread_t, int); > int pthread_sigmask(int, const __sigset_t *, __sigset_t *); > > See ports/132828 and http://lists.freebsd.org/pipermail/svn-src-head/2009-March/004946.html -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 14:20:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C91A21065690; Wed, 25 Mar 2009 14:20:07 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 640978FC24; Wed, 25 Mar 2009 14:20:07 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 15:20:05 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2PEK1Gc011960; Wed, 25 Mar 2009 15:20:01 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Wed, 25 Mar 2009 15:19:56 +0100 From: Matthias Apitz To: Bruce Cran Message-ID: <20090325141956.GA11761@rebelion.Sisis.de> References: <20090325092840.GA3841@rebelion.Sisis.de> <20090325140908.GA14343@muon.cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090325140908.GA14343@muon.cran.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 25 Mar 2009 14:20:05.0838 (UTC) FILETIME=[CB6A76E0:01C9AD54] Cc: vd@freebsd.org, freebsd-current@freebsd.org Subject: Re: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:20:08 -0000 El día Wednesday, March 25, 2009 a las 02:09:09PM +0000, Bruce Cran escribió: > On Wed, Mar 25, 2009 at 10:28:40AM +0100, Matthias Apitz wrote: > > > > > > # cd /usr/ports/devel/pth > > vm-naranja# cvs up > > cvs update: Updating . > > cvs update: Updating files > > ... > > > > See ports/132828 and > http://lists.freebsd.org/pipermail/svn-src-head/2009-March/004946.html Forgive me if this is a stupid questions (I'm new to CURRENT); I did a cvs checkout of src and ports on March 23 and a cvs update of the port today, why I don't have this fix? Is CVS not uptodate? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 14:21:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A712D106568E for ; Wed, 25 Mar 2009 14:21:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE7B8FC0A for ; Wed, 25 Mar 2009 14:21:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D310.dip.t-dialin.net [217.226.211.16]) by redbull.bpaserver.net (Postfix) with ESMTP id EC3C42E1F6; Wed, 25 Mar 2009 15:21:32 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 89CFA20468D; Wed, 25 Mar 2009 15:21:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1237990889; bh=TB1TLw8VziKZSYs+AVey+kYmd2FuuEkIv P6GFl8LKHg=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EDv+WA/ccwuU8us2wQfztSUv1kstMIaC1JRGtPZGbOi624Ubu2mcJ5X93r86wcLsO p2SXV69cDODlj+MtJMh7Dgyjo1Lli8Dxko4bMbpO6YwKLM8PVITkmHkspyZR6QtesfS jILjmsddLM5P037MNtXcTy0iExHcQD3YUtkJ9mL9zJO+SHVDjSg/qTTv0BPNu8XOOEL YmXGoSVuyW5qzR3a+noJFWOgmLe9LoPnFXy6m9HTapHSs+6+ohaj7A1khU1/iiInbqn GBG9N6f4RJ7VNjX3Clsf04QZ99QDZ0nwexBGjtwS1PEULyy/v7FC7i8TknmCA0Uyyyb 0C5Bib8Xw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2PELSQh082146; Wed, 25 Mar 2009 15:21:28 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 25 Mar 2009 15:21:28 +0100 Message-ID: <20090325152128.2389990h7v6a02co@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 25 Mar 2009 15:21:28 +0100 From: Alexander Leidinger To: Mark Powell References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> In-Reply-To: <20090325125930.U73916@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: EC3C42E1F6.E8A08 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:21:39 -0000 Quoting Mark Powell (from Wed, 25 Mar 2009 13:49:07 +0000 (GMT)): > On Wed, 25 Mar 2009, Alexander Leidinger wrote: >> NCQ is not supported yet in FreeBSD. Alexander Motin said he is >> interested in implementing it, but I don't know about the status of >> this. > > Ok. So vfs.zfs.vdev.max_pending is irrelevant for SATA currently? > Cheers. Either that or it needs to be lowered. I don't know. Bye, Alexander. -- PARTY: A gathering where you meet people who drink so much you can't even remember their names. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 15:08:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D04E81065820 for ; Wed, 25 Mar 2009 15:08:54 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4CB8FC25 for ; Wed, 25 Mar 2009 15:08:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so80158ewy.43 for ; Wed, 25 Mar 2009 08:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XmonVBxIAarD7u8qQ75hY3UUyfxPYpdX9jCFMiBl2hI=; b=belkMuPKQJFAjFLy18ROfUqx+zAyo15IMNfaTK2aQcJlo1+QAIK53laIDa1b7H6evw MzlCIv1B91DtA1zTcgXZsMIs/neN5xa7VKARhznstf++D5d82j62zEWAMdFCU3L25OnY xRUWOW/vUiTXZ9AHJyJGQ/SFhSAbGcnjVGBJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Stwp7dpFJX/0hHqNYlzU0HfdXHODe2QGiPzb2F3AWyHCZBF30kRNQRZP/aQ48MsZez k32mnfJdrvNgEkdS5XIzuom3dOMPGvhNhZSID2oDO9mwpRVFPTehhB3ovuSPkMGiVnMf vJb31qcbMrBTHrTwfOnuWiLV8vocL9zg0W1iI= MIME-Version: 1.0 Received: by 10.210.56.7 with SMTP id e7mr3260256eba.55.1237993732374; Wed, 25 Mar 2009 08:08:52 -0700 (PDT) In-Reply-To: <20090325141956.GA11761@rebelion.Sisis.de> References: <20090325092840.GA3841@rebelion.Sisis.de> <20090325140908.GA14343@muon.cran.org.uk> <20090325141956.GA11761@rebelion.Sisis.de> Date: Wed, 25 Mar 2009 16:08:52 +0100 Message-ID: <3a142e750903250808r1af1cc51g230faf60893f5cf1@mail.gmail.com> From: "Paul B. Mahol" To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:08:58 -0000 On 3/25/09, Matthias Apitz wrote: > El d=EDa Wednesday, March 25, 2009 a las 02:09:09PM +0000, Bruce Cran > escribi=F3: > >> On Wed, Mar 25, 2009 at 10:28:40AM +0100, Matthias Apitz wrote: >> > >> > >> > # cd /usr/ports/devel/pth >> > vm-naranja# cvs up >> > cvs update: Updating . >> > cvs update: Updating files >> > > ... >> > >> >> See ports/132828 and >> http://lists.freebsd.org/pipermail/svn-src-head/2009-March/004946.html > > Forgive me if this is a stupid questions (I'm new to CURRENT); I did a > cvs checkout of src and ports on March 23 and a cvs update of the port > today, why I don't have this fix? Is CVS not uptodate? Look into file revision number. In past I was hit with same issue multiple times and so I deceided to switch and now I'm using svn. --=20 Paul From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 15:21:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF3110656DE; Wed, 25 Mar 2009 15:21:23 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id B73048FC16; Wed, 25 Mar 2009 15:21:22 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so19621eyf.7 for ; Wed, 25 Mar 2009 08:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5iwJSLHflxLWESrgTg/gWVKIcPvhU7XT6dLal5al7ws=; b=piT/VECHWeBM/SJMKDsE9mkNrasXy5L+HkWgVVTdn6IpSBJP8wcx0SSXUZ+qEoWlQf lMJx6T3Wn7J3MRErWd6hT/9vX3WDGaYcKdHDeVzBydlQfzNdRiSV9m2bZWiQeB+3J23M O3Ys/fM/ksRpdeLhoI5d3SFQCJAO5aLUtGIjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dqcM5roopOFB+f3DJ98nm6vzKpIadPImAMpSO0AKJBbtfAcHHfprBsjkjcb+wMmFJk eQCMZylrv8xfXT9ATpqGQkSjdFHDfb+wlh3DiBB8dWmFpgCuVKmfKEAq0NcXwkjgXtYG pfH/LEjkNaXNvfxfRO/ywxZu5wo+42YF7PrW8= MIME-Version: 1.0 Received: by 10.210.12.13 with SMTP id 13mr4225893ebl.1.1237994481703; Wed, 25 Mar 2009 08:21:21 -0700 (PDT) In-Reply-To: <1237950378.1829.13.camel@balrog.2hip.net> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> Date: Wed, 25 Mar 2009 10:21:21 -0500 Message-ID: <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> From: Brandon Gooch To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:21:24 -0000 On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland wrote= : > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall w= rote: >> > Brandon Gooch wrote: >> >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wrote= : >> >> >> >>> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> >>> >> >>>> >> >>>> The committed version is working well, I am suspending and resuming >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of the >> >>>> major things I needed to work so I could run FreeBSD primarily on >> >>>> my notebook. >> >>>> >> >> >> >> I just finished a kernel build and it seems as though your >> >> recent commits have fixed the clock (at least for me)! >> >> >> >> I feel sorry for all the i386 folks on ACPI notebooks... >> >> >> >> Thanks! >> >> >> >> -Brandon >> >> >> > >> > Picking a semi-random message here.. >> > >> > Thanks for your work on this! =A0In the past (months ago) I tried the = patch >> > set which didn't work, but the code in -current lets me suspend and re= sume >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! =A0I think thi= s is a >> > first for me, of all the laptops I've had, none have ever been able to >> > suspend and resume in a successful or useful way, and I've been jealou= s of >> > the Thinkpad users that could claim otherwise. =A0I could suspend and = resume >> > fine while in the console, then I ran startx and the suspend and resum= e >> > worked while I was in X with intel graphics, however my system was slo= w >> > after that resume. =A0I didn't spend much time looking at it since I w= as at >> > work, and I didn't see any obvious reasons for the slowness (cpu frequ= ency >> > was fine, cx states were C2 or lower (C1), top showed mostly idle, no >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not the m= ouse >> > or typing though). =A0I didn't go back to console, I just shut down wi= thout >> > trying any other situations yet. >> > >> > A tip I want to note for any users who may not have success with their >> > screen on resume: =A0In the past it seemed to help me to have a power-= on >> > password set in my BIOS since the BIOS will turn on the screen on resu= me to >> > ask me for my password. =A0I don't know if it is still helping me, but= I've >> > seen in the past where it has. >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> > >> >> The sluggish response in X on Intel video has been an issue the past >> couple of days, triggered by suspend/resume or simply switching to VTY >> and back. > > I just committed code that should fix this... > > robert. > >> See this thread: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.htm= l >> >> Firefox is unusable, but xterms are still usable. I have to reboot to >> get back to "normal" >> >> -Brandon >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > -- > Robert Noland > FreeBSD > It seems to have helped -- slightly. Firefox is still too laggy when interacting with interface elements (scrollbar, toolbars, menus), and typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to use, perhaps because they're not as graphically intensive :) Also, it seems to have broken the suspend/resume. The machine does wake up, but X is no longer there (I'm at the VTY from which I started X) and I can't switch to another VTY. The machine still "works" for a period, but attempts to switch VTY or enter commands from the keyboard eventually lock it up, resulting in a continuous beep tone and requiring a hard power-off (holding down the power button). -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 15:30:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 085801065676 for ; Wed, 25 Mar 2009 15:30:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 619F48FC12 for ; Wed, 25 Mar 2009 15:30:00 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n2PFTjwa011173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2009 16:29:45 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n2PFTgRH077641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 16:29:42 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n2PFTfuO021033; Wed, 25 Mar 2009 16:29:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n2PFTefg021032; Wed, 25 Mar 2009 16:29:40 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Mar 2009 16:29:40 +0100 From: Bernd Walter To: Alexander Leidinger Message-ID: <20090325152940.GB16409@cicely7.cicely.de> References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325152128.2389990h7v6a02co@webmail.leidinger.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.030, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: kevin , FreeBSD Current , Mark Powell , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:30:02 -0000 On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: > Quoting Mark Powell (from Wed, 25 Mar 2009 > 13:49:07 +0000 (GMT)): > > >On Wed, 25 Mar 2009, Alexander Leidinger wrote: > > >>NCQ is not supported yet in FreeBSD. Alexander Motin said he is > >>interested in implementing it, but I don't know about the status of > >>this. > > > >Ok. So vfs.zfs.vdev.max_pending is irrelevant for SATA currently? > > Cheers. > > Either that or it needs to be lowered. I don't know. I wouldn't be surprised if the problem is in the drive firmware. Preread and wc both have the potential to put a lot load to the drives and can trigger bugs that otherwise wouldn't matter. I also have a system running WD drives and ECC RAM which show CRC errors from time to time, while all other systems have no CRC problem at all. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 15:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAC01065673 for ; Wed, 25 Mar 2009 15:31:19 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 466418FC2B for ; Wed, 25 Mar 2009 15:31:19 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 16:31:17 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2PFVGnA013860; Wed, 25 Mar 2009 16:31:16 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Wed, 25 Mar 2009 16:31:15 +0100 From: Matthias Apitz To: "Paul B. Mahol" Message-ID: <20090325153115.GA13609@rebelion.Sisis.de> References: <20090325092840.GA3841@rebelion.Sisis.de> <20090325140908.GA14343@muon.cran.org.uk> <20090325141956.GA11761@rebelion.Sisis.de> <3a142e750903250808r1af1cc51g230faf60893f5cf1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a142e750903250808r1af1cc51g230faf60893f5cf1@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 25 Mar 2009 15:31:18.0034 (UTC) FILETIME=[BDD7D720:01C9AD5E] Cc: freebsd-current@freebsd.org Subject: Re: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:31:21 -0000 El día Wednesday, March 25, 2009 a las 04:08:52PM +0100, Paul B. Mahol escribió: > On 3/25/09, Matthias Apitz wrote: > > El día Wednesday, March 25, 2009 a las 02:09:09PM +0000, Bruce Cran > > escribió: > > > >> On Wed, Mar 25, 2009 at 10:28:40AM +0100, Matthias Apitz wrote: > >> > > >> > > >> > # cd /usr/ports/devel/pth > >> > vm-naranja# cvs up > >> > cvs update: Updating . > >> > cvs update: Updating files > >> > > > ... > >> > > >> > >> See ports/132828 and > >> http://lists.freebsd.org/pipermail/svn-src-head/2009-March/004946.html > > > > Forgive me if this is a stupid questions (I'm new to CURRENT); I did a > > cvs checkout of src and ports on March 23 and a cvs update of the port > > today, why I don't have this fix? Is CVS not uptodate? > > Look into file revision number. it seems that /usr/include/signal.h has the fix in CVS, its Id is: $FreeBSD: src/include/signal.h,v 1.28 2009/03/14 20:10:14 das Exp $ > In past I was hit with same issue > multiple times and so I deceided to switch and now I'm using svn. please be so kind and point me to a doc about using SVN with FreeBSD; the handbook only talks about the existance and about how to use CVS; thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 16:25:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB398106566C for ; Wed, 25 Mar 2009 16:25:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id 8C5B28FC16 for ; Wed, 25 Mar 2009 16:25:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 13027 invoked by uid 60001); 25 Mar 2009 16:25:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237998353; bh=AQ+4L1hi2r//mB6NlUU2i7o+zrAZU71/AAto1p5rAy4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eJg5i0HpymXrUHPzrL3gf0ZKEitRhKPBhOJIYIvO9R3TtLmiBwvMGgROlsBCEkm8q2apnyIGUQfwh8E4bhETBStYWkw26MhTRtBBTuykfYa5XHnGnG+RogEKOvno+dgIfmJY2kKPj1gCYYxq3Pr5JDdoiwJN6uplcHy59HObksQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6gnwTamKrGYux3mjxcSzb0hrRsxqQZzQCQX/rsRLBXRncdJkA28zpJ51DKloGX+USFdpjgawD9MYPgZrZhe4WoxMlsssB/KiH3vtHOUOFo5JqgZR8P3Vu3eSvgxRGS32MDmVnpKJCPhoSKKkcjYYjUcNyjw9PL3xsdI5lYe1tW8=; Message-ID: <983452.12250.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: tLl0XKIVM1mtG0JmYwDPSga47oDbQvtK84QKvKWnLjIq7Srrqxfs..a41t0eytqY8jnpY6SI1.uZ1u7zbF_8FcSjAolTSVuiTCtIq1N5oB5irZW8hLChWDwu67cZw_txGPB__zlNrjUK0NBR0pxnvegLxZNa0BaS.DNPMCiSFsAhdDrpXYnaQ91tk_eDulVX91FHTxAdXVt28zPTCPFI4p4QsciBQpnmBaxYXSjAD6_QTDmw8r3q1GenBfMWdAqIqQmWgFw- Received: from [98.242.222.229] by web63904.mail.re1.yahoo.com via HTTP; Wed, 25 Mar 2009 09:25:53 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 25 Mar 2009 09:25:53 -0700 (PDT) From: Barney Cordoba To: mail25@bzerk.org In-Reply-To: <20090325125651.GA49416@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:25:55 -0000 --- On Wed, 3/25/09, Ruben de Groot wrote: > From: Ruben de Groot > Subject: Re: Telnet root login > To: "Robert Watson" > Cc: "Barney Cordoba" , "Ruben de Groot" , "Chuck Robey" , current@freebsd.org > Date: Wednesday, March 25, 2009, 8:56 AM > On Wed, Mar 25, 2009 at 12:52:17PM +0000, Robert Watson > typed: > > > > On Wed, 25 Mar 2009, Barney Cordoba wrote: > > > > >I'm not sure if its the pty (the login > terminal shows as pty/0 and no > > >longer ttyp0), or if its some PAM thing. Its > rather annoying. Such things > > >as > > > > Try "pts/0 none network secure"? I've > not done this in ages, but I believe > > the principle should still apply. If it doesn't, > it's probably a bug. > > works for me: > > morninglightmountain# grep secure /etc/ttys|grep pts > pts/0 none network secure > pts/1 none network secure > pts/2 none network secure > pts/3 none network secure > pts/4 none network secure > pts/5 none network secure > morninglightmountain# uname -a > FreeBSD morninglightmountain.hacktor.net 8.0-CURRENT > FreeBSD 8.0-CURRENT #1: Fri Feb 13 09:08:59 UTC 2009 > root@morninglightmountain.hacktor.net:/usr/obj/usr/src/sys/MORNINGLIGHTMOUNTAIN > sparc64 > morninglightmountain# telnet localhost > Trying ::1... > telnet: connect to address ::1: Connection refused > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Trying SRA secure login: > User (root): > Password: > [ SRA accepts you ] What tty does it say you are on? You may have the older stuff. That setup does not work for me. It was the first thing I tried. I'm running 800070 Barney From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 16:36:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D5C2106566B; Wed, 25 Mar 2009 16:36:01 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A18D8FC25; Wed, 25 Mar 2009 16:36:01 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3C20B19017; Wed, 25 Mar 2009 16:35:59 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 25 Mar 2009 16:35:59 +0000 (GMT) Date: Wed, 25 Mar 2009 16:35:33 +0000 From: Bruce Cran To: Matthias Apitz Message-ID: <20090325163533.776f1b68@gluon.draftnet> In-Reply-To: <20090325141956.GA11761@rebelion.Sisis.de> References: <20090325092840.GA3841@rebelion.Sisis.de> <20090325140908.GA14343@muon.cran.org.uk> <20090325141956.GA11761@rebelion.Sisis.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vd@freebsd.org, freebsd-current@freebsd.org Subject: Re: ports/devel/pth failes to compile (conflict with /usr/include/signal.h) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:36:01 -0000 On Wed, 25 Mar 2009 15:19:56 +0100 Matthias Apitz wrote: > El d=EDa Wednesday, March 25, 2009 a las 02:09:09PM +0000, Bruce Cran > escribi=F3: >=20 > > On Wed, Mar 25, 2009 at 10:28:40AM +0100, Matthias Apitz wrote: > > >=20 > > >=20 > > > # cd /usr/ports/devel/pth > > > vm-naranja# cvs up > > > cvs update: Updating . > > > cvs update: Updating files > > >=20 > ... > > > > >=20 > > See ports/132828 and > > http://lists.freebsd.org/pipermail/svn-src-head/2009-March/004946.html >=20 > Forgive me if this is a stupid questions (I'm new to CURRENT); I did a > cvs checkout of src and ports on March 23 and a cvs update of the port > today, why I don't have this fix? Is CVS not uptodate? >=20 The thread on svn-src-head is about the original change to signal.h which broke pth. --=20 Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 16:36:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFA81065674; Wed, 25 Mar 2009 16:36:43 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D9FBD8FC1A; Wed, 25 Mar 2009 16:36:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2PGZH1q029414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 12:35:18 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: wsk In-Reply-To: <49C9ED34.20504@gddsn.org.cn> References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> <1237961497.1828.2.camel@balrog.2hip.net> <49C9ED34.20504@gddsn.org.cn> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CuvRlaF6JXOCnxZ4Hqh5" Organization: FreeBSD Date: Wed, 25 Mar 2009 11:36:12 -0500 Message-Id: <1237998972.1828.4.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, URIBL_RED autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:36:44 -0000 --=-CuvRlaF6JXOCnxZ4Hqh5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 16:37 +0800, wsk wrote: > Robert Noland wrote: > > On Wed, 2009-03-25 at 08:46 +0800, wsk wrote: > > =20 > >> Robert Noland wrote: > >> =20 > >>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: > >>> =20 > >>> =20 > >>>> Robert Noland wrote: > >>>> =20 > >>>> =20 > >>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>>>>> Ok, this patch should work on NV50 chips also. > >>>>>>> =20 > >>>>>>> What you get is EXA and Xv. > >>>>>>> =20 > >>>>>>> You still need: > >>>>>>> =20 > >>>>>>> A recent -CURRENT or -STABLE. > >>>>>>> =20 > >>>>>>> git master of libdrm and xf86-video-nouveau. > >>>>>>> =20 > >>>>>>> This patch. > >>>>>>> =20 > >>>>>>> Things I've figured out since the last patch... > >>>>>>> =20 > >>>>>>> On NV50 class hardware you need to have a compositing manager run= ning > >>>>>>> for Xv to work. That means xcompmgr, metacity with composite ena= bled, > >>>>>>> xfce (rumored to work as well, haven't tried). If your running G= nome > >>>>>>> with metacity, open gconf-editor and go to apps->metacity->genera= l and > >>>>>>> check the composite box. > >>>>>>> =20 > >>>>>>> On NV40 class hardware, you don't need the composite manager. In= fact > >>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite > >>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg und= er some > >>>>>>> circumstances. I don't think this is a drm issue, but still an i= ssue. > >>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine= as > >>>>>>> long as that xterm is the foreground window. If it is not the > >>>>>>> foreground window, even if it isn't obscured I see the cpu utiliz= ation. > >>>>>>> Disabling the composite manager makes everything fine. > >>>>>>> =20 > >>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > >>>>>>> =20 > >>>>>>> robert. > >>>>>>> =20 > >>>>>>> =20 > >>>>>>> =20 > >>>>>> get the following errors and exitThis is a pre-release version of = the X server from The X.Org Foundation. > >>>>>> It is not supported in any way. > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >>>>>> Select the "xorg" product for bugs you find in this release. > >>>>>> Before reporting bugs in pre-release versions please check the > >>>>>> latest version in the X.Org Foundation git repository. > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > >>>>>> > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >>>>>> Release Date: 2009-1-30 > >>>>>> X Protocol Version 11, Revision 0 > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE F= reeBSD 7.2-PRE > >>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/= usr/obj/usr/sr > >>>>>> c/sys/WSK amd64 > >>>>>> Build Date: 06 February 2009 04:22:44PM > >>>>>> > >>>>>> Before reporting problems, check http://wiki.x.org > >>>>>> to make sure that you have the latest version. > >>>>>> Markers: (--) probed, (**) from config file, (=3D=3D) default sett= ing, > >>>>>> (++) from command line, (!!) notice, (II) informational, > >>>>>> (WW) warning, (EE) error, (NI) not implemented, (??) unkno= wn. > >>>>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:0= 3 2009 > >>>>>> ing config file: "xorg.conf1" > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x2 > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x2 > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x2 > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x1 > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x1 > >>>>>> drm0: [ITHREAD] > >>>>>> info: [drm] Allocating FIFO number 1 > >>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > >>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > >>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >>>>>> (EE) Screen(s) found, but none have a usable configuration. > >>>>>> > >>>>>> Fatal server error: > >>>>>> no screens found > >>>>>> > >>>>>> Please consult the The X.Org Foundation support > >>>>>> at http://wiki.x.org > >>>>>> for help. > >>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additi= onal informati > >>>>>> on. > >>>>>> > >>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1 > >>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle cha= nnel 1 before > >>>>>> destroy.Prepare for strangeness.. > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find res= ource 0x1 > >>>>>> > >>>>>> what can i do ? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> plain text document attachment (Xorg.0.log) > >>>>>> This is a pre-release version of the X server from The X.Org Found= ation. > >>>>>> It is not supported in any way. > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. > >>>>>> Select the "xorg" product for bugs you find in this release. > >>>>>> Before reporting bugs in pre-release versions please check the > >>>>>> latest version in the X.Org Foundation git repository. > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > >>>>>> > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > >>>>>> Release Date: 2009-1-30 > >>>>>> X Protocol Version 11, Revision 0 > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64=20 > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE F= reeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org= .cn:/usr/obj/usr/src/sys/WSK amd64 > >>>>>> Build Date: 06 February 2009 04:22:44PM > >>>>>> =20 > >>>>>> Before reporting problems, check http://wiki.x.org > >>>>>> to make sure that you have the latest version. > >>>>>> Markers: (--) probed, (**) from config file, (=3D=3D) default sett= ing, > >>>>>> (++) from command line, (!!) notice, (II) informational, > >>>>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >>>>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:0= 3 2009 > >>>>>> (++) Using config file: "xorg.conf1" > >>>>>> (=3D=3D) No Layout section. Using the first Screen section. > >>>>>> (=3D=3D) No screen section available. Using defaults. > >>>>>> (**) |-->Screen "Default Screen Section" (0) > >>>>>> (**) | |-->Monitor "" > >>>>>> (=3D=3D) No device specified for screen "Default Screen Section". > >>>>>> Using the first device section listed. > >>>>>> (**) | |-->Device "Card0" > >>>>>> (=3D=3D) No monitor specified for screen "Default Screen Section". > >>>>>> Using a default monitor configuration. > >>>>>> (=3D=3D) Automatically adding devices > >>>>>> (=3D=3D) Automatically enabling devices > >>>>>> (=3D=3D) No FontPath specified. Using compiled-in default. > >>>>>> (=3D=3D) FontPath set to: > >>>>>> built-ins > >>>>>> (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > >>>>>> (II) Cannot locate a core pointer device. > >>>>>> (II) Cannot locate a core keyboard device. > >>>>>> (II) The server relies on HAL to provide the list of input devices= . > >>>>>> If no devices become available, reconfigure HAL or disable AllowE= mptyInput. > >>>>>> (II) Loader magic: 0xb20 > >>>>>> (II) Module ABI versions: > >>>>>> X.Org ANSI C Emulation: 0.4 > >>>>>> X.Org Video Driver: 5.0 > >>>>>> X.Org XInput driver : 4.0 > >>>>>> X.Org Server Extension : 2.0 > >>>>>> (II) Loader running on freebsd > >>>>>> (--) Using syscons driver with X support (version 2.0) > >>>>>> (--) using VT number 9 > >>>>>> > >>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Me= m @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0= x0000df00/128, BIOS @ 0x????????/65536 > >>>>>> =20 > >>>>>> =20 > >>>>>> =20 > >>>>> Ok, thats a new one... > >>>>> > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>>>> (II) System resource ranges: > >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >>>>>> (II) LoadModule: "extmod" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > >>>>>> (II) Module extmod: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>>>> Module class: X.Org Server Extension > >>>>>> ABI class: X.Org Server Extension, version 2.0 > >>>>>> (II) Loading extension MIT-SCREEN-SAVER > >>>>>> (II) Loading extension XFree86-VidModeExtension > >>>>>> (II) Loading extension XFree86-DGA > >>>>>> (II) Loading extension DPMS > >>>>>> (II) Loading extension XVideo > >>>>>> (II) Loading extension XVideo-MotionCompensation > >>>>>> (II) Loading extension X-Resource > >>>>>> (II) LoadModule: "dbe" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > >>>>>> (II) Module dbe: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>>>> Module class: X.Org Server Extension > >>>>>> ABI class: X.Org Server Extension, version 2.0 > >>>>>> (II) Loading extension DOUBLE-BUFFER > >>>>>> (II) LoadModule: "glx" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > >>>>>> (II) Module glx: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>>>> ABI class: X.Org Server Extension, version 2.0 > >>>>>> (=3D=3D) AIGLX disabled > >>>>>> (=3D=3D) Exporting typical set of GLX visuals > >>>>>> (II) Loading extension GLX > >>>>>> (II) LoadModule: "record" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > >>>>>> (II) Module record: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 1.13.0 > >>>>>> Module class: X.Org Server Extension > >>>>>> ABI class: X.Org Server Extension, version 2.0 > >>>>>> (II) Loading extension RECORD > >>>>>> (II) LoadModule: "dri" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > >>>>>> (II) Module dri: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > >>>>>> ABI class: X.Org Server Extension, version 2.0 > >>>>>> (II) Loading extension XFree86-DRI > >>>>>> (II) LoadModule: "nouveau" > >>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so > >>>>>> (II) Module nouveau: vendor=3D"X.Org Foundation" > >>>>>> compiled for 1.5.99.902, module version =3D 0.0.10 > >>>>>> Module class: X.Org Video Driver > >>>>>> ABI class: X.Org Video Driver, version 5.0 > >>>>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 > >>>>>> (II) NOUVEAU driver for NVIDIA chipset families : > >>>>>> RIVA TNT (NV04) > >>>>>> RIVA TNT2 (NV05) > >>>>>> GeForce 256 (NV10) > >>>>>> GeForce 2 (NV11, NV15) > >>>>>> GeForce 4MX (NV17, NV18) > >>>>>> GeForce 3 (NV20) > >>>>>> GeForce 4Ti (NV25, NV28) > >>>>>> GeForce FX (NV3x) > >>>>>> GeForce 6 (NV4x) > >>>>>> GeForce 7 (G7x) > >>>>>> GeForce 8 (G8x) > >>>>>> (II) Primary Device is: PCI 01@00:00:0 > >>>>>> (II) resource ranges after probing: > >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > >>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" > >>>>>> =20 > >>>>>> =20 > >>>>>> =20 > >>>>> Hrm, NV86... I'll have to ask around about that. Meanwhile can you= send > >>>>> me a pciconf -lvb which should at least show us the BAR configurati= on. > >>>>> > >>>>> Ok, my sources are telling me that this should work and that it is = an > >>>>> NV50, or at least should work the same... > >>>>> > >>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.= I'm > >>>>> not sure if it may be trashing the BARs somehow. > >>>>> > >>>>> robert. > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>> bar [24] =3D type I/O Port, range 32, base 0xeff0, size 16, enabled > >>>> ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x01fe1028 chip=3D0x283= e8086 > >>>> rev=3D0x02 hdr=3D0x00 > >>>> vendor =3D 'Intel Corporation' > >>>> device =3D '82801H (ICH8 Family) SMBus Controller' > >>>> class =3D serial bus > >>>> subclass =3D SMBus > >>>> bar [10] =3D type Memory, range 32, base 0xfebfbf00, size 256, enabl= ed > >>>> bar [20] =3D type I/O Port, range 32, base 0x10c0, size 32, enabled > >>>> vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x01fe1028 chip=3D0x0429= 10de > >>>> rev=3D0xa1 hdr=3D0x00 > >>>> vendor =3D 'Nvidia Corp' > >>>> device =3D 'Unknown nVidia Quadro FX 570M' > >>>> class =3D display > >>>> subclass =3D VGA > >>>> bar [10] =3D type Memory, range 32, base 0xfd000000, size 16777216, = enabled > >>>> =20 > >>>> =20 > >>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 > >>> should be your framebuffer and should be where most of your memory is= . > >>> (This is the memory the tell you about when you buy the card, 256M, > >>> 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 is= n't > >>> there. We are going to need more details on your card... > >>> =20 > >>> =20 > >> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M mem= ory. > >> but it recognized Quadro FX 570M with pciconfig. > >> =20 > > > > So, the nouveau folks want me to get you to either boot linux and see > > what lspci shows for this card, or at least install the lspci port and > > see what it says. I don't think it is going to reveal anything, but wh= o > > knows... This is not a driver issue at this point, the BARs just don't > > appear to be present. > > > > robert. > > > > =20 > ok,here's my lspci -v messags with linux Fedora live CD :-) > and thanks your Re >=20 >=20 > 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M > (rev a1) (prog-if 00 [VGA controller]) > Subsystem: Dell Device 01fe > Flags: bus master, fast devsel, latency 0, IRQ 5 > Memory at fd000000 (32-bit, non-prefetchable) [size=3D16M] > Memory at e0000000 (64-bit, prefetchable) [size=3D256M] > Memory at fa000000 (64-bit, non-prefetchable) [size=3D32M] > I/O ports at df00 [size=3D128] > [virtual] Expansion ROM at fc000000 [disabled] [size=3D128K] > Capabilities: [60] Power Management version 2 > Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=3D1/1 > Enable- > Capabilities: [78] Express Endpoint, MSI 00 > Capabilities: [100] Virtual Channel > Capabilities: [128] Power Budgeting > Capabilities: [600] Vendor Specific Information > Kernel modules: nvidiafb Ok, we need a little help on this one then... I don't know why we wouldn't see BAR 1. Time to rope jhb@ in. robert. > 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n > (rev 03) > Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at f9ffc000 (64-bit, non-prefetchable) [size=3D16K] > Memory at f0000000 (64-bit, prefetchable) [size=3D1M] > Capabilities: [40] Power Management version 2 > Capabilities: [58] Vendor Specific Information > Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=3D1/1 > Enable- > Capabilities: [d0] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- > ECRC- UnsupReq- ACSVoil- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- > ECRC- UnsupReq- ACSVoil- > UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ > MalfTLP+ ECRC- UnsupReq- ACSVoil- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- > Capabilities: [13c] Virtual Channel > Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0 > Capabilities: [16c] Power Budgeting > Kernel driver in use: b43-pci-bridge > Kernel modules: ssb >=20 > >>> =20 > >>> =20 > >>>> bar [1c] =3D type Memory, range 64, base 0xfa000000, size 33554432, = enabled > >>>> =20 > >>>> =20 > >>> This one is BAR 3, which is used when it doesn't find BAR 1. > >>> > >>> robert. > >>> > >>> =20 > >>> =20 > >>>> bar [24] =3D type I/O Port, range 32, base 0xdf00, size 128, enabled > >>>> ndis0@pci0:12:0:0: class=3D0x028000 card=3D0x000a1028 chip=3D0x43281= 4e4 > >>>> rev=3D0x03 hdr=3D0x00 > >>>> > >>>> and follow your intrudction.still pain me :( > >>>> > >>>> (++) Using config file: "xorg.conf1" > >>>> drm0: on vgapci0 > >>>> info: [drm] Detected an NV50 generation card (0x086900a2) > >>>> vgapci0: child drm0 requested pci_enable_busmaster > >>>> info: [drm] Initialized nouveau 0.0.12 20060213 > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resour= ce 0x2 > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resour= ce 0x1 > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resour= ce 0x1 > >>>> drm0: [ITHREAD] > >>>> info: [drm] Allocating FIFO number 1 > >>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, > >>>> invalid/inactiv > >>>> e channel id 128 > >>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: > >>>> [drm] , nSt > >>>> atus:info: [drm] > >>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data > >>>> 0x00000000:0x00 > >>>> 000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8= 000003f > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xc= f6f7f0e > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xf= ff7367f > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x0= 0001850 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xa= fff3587 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x8= 00b6fad > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4= df4fd60 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x0= 00000d7 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3= 139768d > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf= 6d69757 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x6= 3161650 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x0= 7220009 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x0= 0000000 > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x0= 0000000 > >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > >>>> (EE) Screen(s) found, but none have a usable configuration. > >>>> > >>>> Fatal server error: > >>>> no screens found > >>>> > >>>> Please consult the The X.Org Foundation support > >>>> at http://wiki.x.org > >>>> for help. > >>>> Please also check the log file at "/var/log/Xorg.0.log" for addition= al > >>>> informati > >>>> on. > >>>> > >>>> info: [drm] nouveau_fifo_free: freeing fifo 1 > >>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channe= l 1 > >>>> before d > >>>> estroy.Prepare for strangeness.. > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127 > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffffff= fffff). > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resour= ce 0x1 > >>>> > >>>> =20 >=20 --=20 Robert Noland FreeBSD --=-CuvRlaF6JXOCnxZ4Hqh5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknKXXwACgkQM4TrQ4qfROOK3ACfUdi0lYyotbn0X6NH3oXftwPE aBYAnjqnTHCaYgHZEPVOgOnbbH1aOOG8 =FjRc -----END PGP SIGNATURE----- --=-CuvRlaF6JXOCnxZ4Hqh5-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 17:07:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D72F10658F0; Wed, 25 Mar 2009 17:07:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id DFB0C8FC1C; Wed, 25 Mar 2009 17:07:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2PH6aV5029670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 13:06:36 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Oely1UlHgY4mdTM98LvR" Organization: FreeBSD Date: Wed, 25 Mar 2009 12:07:30 -0500 Message-Id: <1238000850.1828.12.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:08:01 -0000 --=-Oely1UlHgY4mdTM98LvR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote: > On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland wro= te: > > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: > >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall = wrote: > >> > Brandon Gooch wrote: > >> >> > >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wro= te: > >> >> > >> >>> > >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >> >>> > >> >>>> > >> >>>> The committed version is working well, I am suspending and resumi= ng > >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of the > >> >>>> major things I needed to work so I could run FreeBSD primarily on > >> >>>> my notebook. > >> >>>> > >> >> > >> >> I just finished a kernel build and it seems as though your > >> >> recent commits have fixed the clock (at least for me)! > >> >> > >> >> I feel sorry for all the i386 folks on ACPI notebooks... > >> >> > >> >> Thanks! > >> >> > >> >> -Brandon > >> >> > >> > > >> > Picking a semi-random message here.. > >> > > >> > Thanks for your work on this! In the past (months ago) I tried the = patch > >> > set which didn't work, but the code in -current lets me suspend and = resume > >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think thi= s is a > >> > first for me, of all the laptops I've had, none have ever been able = to > >> > suspend and resume in a successful or useful way, and I've been jeal= ous of > >> > the Thinkpad users that could claim otherwise. I could suspend and = resume > >> > fine while in the console, then I ran startx and the suspend and res= ume > >> > worked while I was in X with intel graphics, however my system was s= low > >> > after that resume. I didn't spend much time looking at it since I w= as at > >> > work, and I didn't see any obvious reasons for the slowness (cpu fre= quency > >> > was fine, cx states were C2 or lower (C1), top showed mostly idle, n= o > >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not the= mouse > >> > or typing though). I didn't go back to console, I just shut down wi= thout > >> > trying any other situations yet. > >> > > >> > A tip I want to note for any users who may not have success with the= ir > >> > screen on resume: In the past it seemed to help me to have a power-= on > >> > password set in my BIOS since the BIOS will turn on the screen on re= sume to > >> > ask me for my password. I don't know if it is still helping me, but= I've > >> > seen in the past where it has. > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" > >> > > >> > >> The sluggish response in X on Intel video has been an issue the past > >> couple of days, triggered by suspend/resume or simply switching to VTY > >> and back. > > > > I just committed code that should fix this... > > > > robert. > > > >> See this thread: > >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.h= tml > >> > >> Firefox is unusable, but xterms are still usable. I have to reboot to > >> get back to "normal" > >> > >> -Brandon > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > > -- > > Robert Noland > > FreeBSD > > >=20 > It seems to have helped -- slightly. Firefox is still too laggy when > interacting with interface elements (scrollbar, toolbars, menus), and > typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to > use, perhaps because they're not as graphically intensive :) >=20 > Also, it seems to have broken the suspend/resume. The machine does > wake up, but X is no longer there (I'm at the VTY from which I started > X) and I can't switch to another VTY. The machine still "works" for a > period, but attempts to switch VTY or enter commands from the keyboard > eventually lock it up, resulting in a continuous beep tone and > requiring a hard power-off (holding down the power button). Ok, let me see if I can get this i915 to suspend with / on a usb disk.... ;( robert. > -Brandon --=20 Robert Noland FreeBSD --=-Oely1UlHgY4mdTM98LvR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEABECAAYFAknKZNIACgkQM4TrQ4qfROOHQwCXT/pxMSzo5vJ3Q/zj7xACYjmQ SQCfXiR8hMvMYQvvlvmuKyjzAq5HVaU= =4BTF -----END PGP SIGNATURE----- --=-Oely1UlHgY4mdTM98LvR-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 17:11:29 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB901065920 for ; Wed, 25 Mar 2009 17:11:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id B893F8FC2D for ; Wed, 25 Mar 2009 17:11:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 21890 invoked by uid 399); 25 Mar 2009 17:11:26 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 17:11:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49CA65BC.7060704@FreeBSD.org> Date: Wed, 25 Mar 2009 10:11:24 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Gustau Perez , freebsd-current@FreeBSD.ORG, ports@freebsd.org, das@FreeBSD.ORG References: <49C80DBA.80407@entel.upc.edu> <20090325033451.GA17442@zim.MIT.EDU> <49C9A7B4.3080509@FreeBSD.org> <20090325044408.GB17442@zim.MIT.EDU> In-Reply-To: <20090325044408.GB17442@zim.MIT.EDU> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Inline definition problem in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:11:34 -0000 David Schultz wrote: > On Tue, Mar 24, 2009, Doug Barton wrote: >> I am trying to compile gimp on -current right now and x11/babl and >> graphics/gegl both have this problem. Take a look at >> http://pointyhat.freebsd.org/errorlogs/i386-8-failure.html for more >> examples (click on the link on the right under Package to see the >> logs). There are currently over 600 broken ports in -current, all the >> ones I clicked on in a completely bogus sample had this same problem. > > My bug; I missed an important line when merging from gcc trunk 122565. > Instead of reporting: > > error: nested function 'foo' declared but never defined > > gcc should have been reporting: > > warning: inline function 'foo' declared but never defined > > I'll check in a fix as soon as I run a buildworld. Thanks for jumping on this. With your latest version the two ports I mentioned above compile just fine with no modifications to the source. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 17:17:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB29210656C4 for ; Wed, 25 Mar 2009 17:17:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id AEDC68FC19 for ; Wed, 25 Mar 2009 17:17:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 5F0AC60462; Wed, 25 Mar 2009 10:18:18 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BAC912D6010; Wed, 25 Mar 2009 10:17:56 -0700 (PDT) Message-ID: <49CA6754.4030302@elischer.org> Date: Wed, 25 Mar 2009 10:18:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ian FREISLICH References: <995845.90009.qm@web63905.mail.re1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ruben de Groot , Chuck Robey , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:18:02 -0000 Ian FREISLICH wrote: > Barney Cordoba wrote: >>> Barney, you have to make the network pseudo ttys secure, >>> like: >>> >>> ttyp0 none network secure >>> >>> Ruben >> Yes, the "its not a good idea" is dependent on whatever other >> security you have in place. Having to log in twice to a test >> machine on a secure internal network is an unnecessary annoyance. >> The concept that every FreeBSD box in existence is publically accessible >> is one of those ASSumptions that people should leave at the door. >> >> Ruben, the method you cite no longer works in -current as they've >> changed things once again (which happens way too often when your CEOs >> are a bunch of bearded academics :) >> >> I'm not sure if its the pty (the login terminal shows as pty/0 and >> no longer ttyp0), or if its some PAM thing. Its rather annoying. >> Such things as >> >> pty/0 none network secure >> pty0 none network secure >> >> equally don't work. And I see no mention in any document as to how it >> would be achieved with the current > > Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config this doesn't work if you are usinf a set of machines run from a central machine using nc (netcat) to do scripted i/o through a telnet session on the other machines (for example). The advantage of telnet is you can pipe nc straight into it. > > Ian > > -- > Ian Freislich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 17:23:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720AE1065898; Wed, 25 Mar 2009 17:23:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 277C98FC1F; Wed, 25 Mar 2009 17:23:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2PHM3mN029792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 13:22:03 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: wsk In-Reply-To: <1237998972.1828.4.camel@balrog.2hip.net> References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> <1237961497.1828.2.camel@balrog.2hip.net> <49C9ED34.20504@gddsn.org.cn> <1237998972.1828.4.camel@balrog.2hip.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-usmBgkqy+4mpv+R9GDoy" Organization: FreeBSD Date: Wed, 25 Mar 2009 12:22:57 -0500 Message-Id: <1238001777.1828.17.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, URIBL_RED autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:23:33 -0000 --=-usmBgkqy+4mpv+R9GDoy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 11:36 -0500, Robert Noland wrote: > On Wed, 2009-03-25 at 16:37 +0800, wsk wrote: > > Robert Noland wrote: > > > On Wed, 2009-03-25 at 08:46 +0800, wsk wrote: > > > =20 > > >> Robert Noland wrote: > > >> =20 > > >>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: > > >>> =20 > > >>> =20 > > >>>> Robert Noland wrote: > > >>>> =20 > > >>>> =20 > > >>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: > > >>>>> =20 > > >>>>> =20 > > >>>>> =20 > > >>>>>>> Ok, this patch should work on NV50 chips also. > > >>>>>>> =20 > > >>>>>>> What you get is EXA and Xv. > > >>>>>>> =20 > > >>>>>>> You still need: > > >>>>>>> =20 > > >>>>>>> A recent -CURRENT or -STABLE. > > >>>>>>> =20 > > >>>>>>> git master of libdrm and xf86-video-nouveau. > > >>>>>>> =20 > > >>>>>>> This patch. > > >>>>>>> =20 > > >>>>>>> Things I've figured out since the last patch... > > >>>>>>> =20 > > >>>>>>> On NV50 class hardware you need to have a compositing manager r= unning > > >>>>>>> for Xv to work. That means xcompmgr, metacity with composite e= nabled, > > >>>>>>> xfce (rumored to work as well, haven't tried). If your running= Gnome > > >>>>>>> with metacity, open gconf-editor and go to apps->metacity->gene= ral and > > >>>>>>> check the composite box. > > >>>>>>> =20 > > >>>>>>> On NV40 class hardware, you don't need the composite manager. = In fact > > >>>>>>> (at least with Xserver 1.6 which I'm running now), if a composi= te > > >>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg u= nder some > > >>>>>>> circumstances. I don't think this is a drm issue, but still an= issue. > > >>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fi= ne as > > >>>>>>> long as that xterm is the foreground window. If it is not the > > >>>>>>> foreground window, even if it isn't obscured I see the cpu util= ization. > > >>>>>>> Disabling the composite manager makes everything fine. > > >>>>>>> =20 > > >>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch > > >>>>>>> =20 > > >>>>>>> robert. > > >>>>>>> =20 > > >>>>>>> =20 > > >>>>>>> =20 > > >>>>>> get the following errors and exitThis is a pre-release version o= f the X server from The X.Org Foundation. > > >>>>>> It is not supported in any way. > > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org= /. > > >>>>>> Select the "xorg" product for bugs you find in this release. > > >>>>>> Before reporting bugs in pre-release versions please check the > > >>>>>> latest version in the X.Org Foundation git repository. > > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > > >>>>>> > > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > > >>>>>> Release Date: 2009-1-30 > > >>>>>> X Protocol Version 11, Revision 0 > > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 > > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE= FreeBSD 7.2-PRE > > >>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn= :/usr/obj/usr/sr > > >>>>>> c/sys/WSK amd64 > > >>>>>> Build Date: 06 February 2009 04:22:44PM > > >>>>>> > > >>>>>> Before reporting problems, check http://wiki.x.org > > >>>>>> to make sure that you have the latest version. > > >>>>>> Markers: (--) probed, (**) from config file, (=3D=3D) default se= tting, > > >>>>>> (++) from command line, (!!) notice, (II) informational, > > >>>>>> (WW) warning, (EE) error, (NI) not implemented, (??) unk= nown. > > >>>>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14= :03 2009 > > >>>>>> ing config file: "xorg.conf1" > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x2 > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x2 > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x2 > > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffff= fffffffff). > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x1 > > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffff= fffffffff). > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x1 > > >>>>>> drm0: [ITHREAD] > > >>>>>> info: [drm] Allocating FIFO number 1 > > >>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > > >>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > > >>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > > >>>>>> (EE) Screen(s) found, but none have a usable configuration. > > >>>>>> > > >>>>>> Fatal server error: > > >>>>>> no screens found > > >>>>>> > > >>>>>> Please consult the The X.Org Foundation support > > >>>>>> at http://wiki.x.org > > >>>>>> for help. > > >>>>>> Please also check the log file at "/var/log/Xorg.0.log" for addi= tional informati > > >>>>>> on. > > >>>>>> > > >>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1 > > >>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle c= hannel 1 before > > >>>>>> destroy.Prepare for strangeness.. > > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffff= fffffffff). > > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find r= esource 0x1 > > >>>>>> > > >>>>>> what can i do ? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> plain text document attachment (Xorg.0.log) > > >>>>>> This is a pre-release version of the X server from The X.Org Fou= ndation. > > >>>>>> It is not supported in any way. > > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org= /. > > >>>>>> Select the "xorg" product for bugs you find in this release. > > >>>>>> Before reporting bugs in pre-release versions please check the > > >>>>>> latest version in the X.Org Foundation git repository. > > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. > > >>>>>> > > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) > > >>>>>> Release Date: 2009-1-30 > > >>>>>> X Protocol Version 11, Revision 0 > > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64=20 > > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE= FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.o= rg.cn:/usr/obj/usr/src/sys/WSK amd64 > > >>>>>> Build Date: 06 February 2009 04:22:44PM > > >>>>>> =20 > > >>>>>> Before reporting problems, check http://wiki.x.org > > >>>>>> to make sure that you have the latest version. > > >>>>>> Markers: (--) probed, (**) from config file, (=3D=3D) default se= tting, > > >>>>>> (++) from command line, (!!) notice, (II) informational, > > >>>>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > >>>>>> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14= :03 2009 > > >>>>>> (++) Using config file: "xorg.conf1" > > >>>>>> (=3D=3D) No Layout section. Using the first Screen section. > > >>>>>> (=3D=3D) No screen section available. Using defaults. > > >>>>>> (**) |-->Screen "Default Screen Section" (0) > > >>>>>> (**) | |-->Monitor "" > > >>>>>> (=3D=3D) No device specified for screen "Default Screen Section"= . > > >>>>>> Using the first device section listed. > > >>>>>> (**) | |-->Device "Card0" > > >>>>>> (=3D=3D) No monitor specified for screen "Default Screen Section= ". > > >>>>>> Using a default monitor configuration. > > >>>>>> (=3D=3D) Automatically adding devices > > >>>>>> (=3D=3D) Automatically enabling devices > > >>>>>> (=3D=3D) No FontPath specified. Using compiled-in default. > > >>>>>> (=3D=3D) FontPath set to: > > >>>>>> built-ins > > >>>>>> (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > > >>>>>> (II) Cannot locate a core pointer device. > > >>>>>> (II) Cannot locate a core keyboard device. > > >>>>>> (II) The server relies on HAL to provide the list of input devic= es. > > >>>>>> If no devices become available, reconfigure HAL or disable Allo= wEmptyInput. > > >>>>>> (II) Loader magic: 0xb20 > > >>>>>> (II) Module ABI versions: > > >>>>>> X.Org ANSI C Emulation: 0.4 > > >>>>>> X.Org Video Driver: 5.0 > > >>>>>> X.Org XInput driver : 4.0 > > >>>>>> X.Org Server Extension : 2.0 > > >>>>>> (II) Loader running on freebsd > > >>>>>> (--) Using syscons driver with X support (version 2.0) > > >>>>>> (--) using VT number 9 > > >>>>>> > > >>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, = Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @= 0x0000df00/128, BIOS @ 0x????????/65536 > > >>>>>> =20 > > >>>>>> =20 > > >>>>>> =20 > > >>>>> Ok, thats a new one... > > >>>>> > > >>>>> =20 > > >>>>> =20 > > >>>>> =20 > > >>>>>> (II) System resource ranges: > > >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > > >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > > >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > > >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > > >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > > >>>>>> (II) LoadModule: "extmod" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.s= o > > >>>>>> (II) Module extmod: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > > >>>>>> Module class: X.Org Server Extension > > >>>>>> ABI class: X.Org Server Extension, version 2.0 > > >>>>>> (II) Loading extension MIT-SCREEN-SAVER > > >>>>>> (II) Loading extension XFree86-VidModeExtension > > >>>>>> (II) Loading extension XFree86-DGA > > >>>>>> (II) Loading extension DPMS > > >>>>>> (II) Loading extension XVideo > > >>>>>> (II) Loading extension XVideo-MotionCompensation > > >>>>>> (II) Loading extension X-Resource > > >>>>>> (II) LoadModule: "dbe" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > > >>>>>> (II) Module dbe: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > > >>>>>> Module class: X.Org Server Extension > > >>>>>> ABI class: X.Org Server Extension, version 2.0 > > >>>>>> (II) Loading extension DOUBLE-BUFFER > > >>>>>> (II) LoadModule: "glx" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > > >>>>>> (II) Module glx: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > > >>>>>> ABI class: X.Org Server Extension, version 2.0 > > >>>>>> (=3D=3D) AIGLX disabled > > >>>>>> (=3D=3D) Exporting typical set of GLX visuals > > >>>>>> (II) Loading extension GLX > > >>>>>> (II) LoadModule: "record" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.s= o > > >>>>>> (II) Module record: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 1.13.0 > > >>>>>> Module class: X.Org Server Extension > > >>>>>> ABI class: X.Org Server Extension, version 2.0 > > >>>>>> (II) Loading extension RECORD > > >>>>>> (II) LoadModule: "dri" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > > >>>>>> (II) Module dri: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 1.0.0 > > >>>>>> ABI class: X.Org Server Extension, version 2.0 > > >>>>>> (II) Loading extension XFree86-DRI > > >>>>>> (II) LoadModule: "nouveau" > > >>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so > > >>>>>> (II) Module nouveau: vendor=3D"X.Org Foundation" > > >>>>>> compiled for 1.5.99.902, module version =3D 0.0.10 > > >>>>>> Module class: X.Org Video Driver > > >>>>>> ABI class: X.Org Video Driver, version 5.0 > > >>>>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 > > >>>>>> (II) NOUVEAU driver for NVIDIA chipset families : > > >>>>>> RIVA TNT (NV04) > > >>>>>> RIVA TNT2 (NV05) > > >>>>>> GeForce 256 (NV10) > > >>>>>> GeForce 2 (NV11, NV15) > > >>>>>> GeForce 4MX (NV17, NV18) > > >>>>>> GeForce 3 (NV20) > > >>>>>> GeForce 4Ti (NV25, NV28) > > >>>>>> GeForce FX (NV3x) > > >>>>>> GeForce 6 (NV4x) > > >>>>>> GeForce 7 (G7x) > > >>>>>> GeForce 8 (G8x) > > >>>>>> (II) Primary Device is: PCI 01@00:00:0 > > >>>>>> (II) resource ranges after probing: > > >>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > > >>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > > >>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > > >>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > > >>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > > >>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" > > >>>>>> =20 > > >>>>>> =20 > > >>>>>> =20 > > >>>>> Hrm, NV86... I'll have to ask around about that. Meanwhile can y= ou send > > >>>>> me a pciconf -lvb which should at least show us the BAR configura= tion. > > >>>>> > > >>>>> Ok, my sources are telling me that this should work and that it i= s an > > >>>>> NV50, or at least should work the same... > > >>>>> > > >>>>> Also, just to be safe, please rebuild/reinstall devel/libpciacces= s. I'm > > >>>>> not sure if it may be trashing the BARs somehow. > > >>>>> > > >>>>> robert. > > >>>>> =20 > > >>>>> =20 > > >>>>> =20 > > >>>> bar [24] =3D type I/O Port, range 32, base 0xeff0, size 16, enable= d > > >>>> ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x01fe1028 chip=3D0x2= 83e8086 > > >>>> rev=3D0x02 hdr=3D0x00 > > >>>> vendor =3D 'Intel Corporation' > > >>>> device =3D '82801H (ICH8 Family) SMBus Controller' > > >>>> class =3D serial bus > > >>>> subclass =3D SMBus > > >>>> bar [10] =3D type Memory, range 32, base 0xfebfbf00, size 256, ena= bled > > >>>> bar [20] =3D type I/O Port, range 32, base 0x10c0, size 32, enable= d > > >>>> vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x01fe1028 chip=3D0x04= 2910de > > >>>> rev=3D0xa1 hdr=3D0x00 > > >>>> vendor =3D 'Nvidia Corp' > > >>>> device =3D 'Unknown nVidia Quadro FX 570M' > > >>>> class =3D display > > >>>> subclass =3D VGA > > >>>> bar [10] =3D type Memory, range 32, base 0xfd000000, size 16777216= , enabled > > >>>> =20 > > >>>> =20 > > >>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR= 1 > > >>> should be your framebuffer and should be where most of your memory = is. > > >>> (This is the memory the tell you about when you buy the card, 256M, > > >>> 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 = isn't > > >>> there. We are going to need more details on your card... > > >>> =20 > > >>> =20 > > >> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M m= emory. > > >> but it recognized Quadro FX 570M with pciconfig. > > >> =20 > > > > > > So, the nouveau folks want me to get you to either boot linux and see > > > what lspci shows for this card, or at least install the lspci port an= d > > > see what it says. I don't think it is going to reveal anything, but = who > > > knows... This is not a driver issue at this point, the BARs just don= 't > > > appear to be present. > > > > > > robert. > > > > > > =20 > > ok,here's my lspci -v messags with linux Fedora live CD :-) > > and thanks your Re > >=20 > >=20 > > 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M > > (rev a1) (prog-if 00 [VGA controller]) > > Subsystem: Dell Device 01fe > > Flags: bus master, fast devsel, latency 0, IRQ 5 > > Memory at fd000000 (32-bit, non-prefetchable) [size=3D16M] > > Memory at e0000000 (64-bit, prefetchable) [size=3D256M] > > Memory at fa000000 (64-bit, non-prefetchable) [size=3D32M] > > I/O ports at df00 [size=3D128] > > [virtual] Expansion ROM at fc000000 [disabled] [size=3D128K] > > Capabilities: [60] Power Management version 2 > > Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=3D1= /1 > > Enable- > > Capabilities: [78] Express Endpoint, MSI 00 > > Capabilities: [100] Virtual Channel > > Capabilities: [128] Power Budgeting > > Capabilities: [600] Vendor Specific Information > > Kernel modules: nvidiafb >=20 > Ok, we need a little help on this one then... I don't know why we > wouldn't see BAR 1. Time to rope jhb@ in. Can you send a verbose boot log. robert. > robert. >=20 > > 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n > > (rev 03) > > Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card > > Flags: bus master, fast devsel, latency 0, IRQ 17 > > Memory at f9ffc000 (64-bit, non-prefetchable) [size=3D16K] > > Memory at f0000000 (64-bit, prefetchable) [size=3D1M] > > Capabilities: [40] Power Management version 2 > > Capabilities: [58] Vendor Specific Information > > Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=3D1= /1 > > Enable- > > Capabilities: [d0] Express Endpoint, MSI 00 > > Capabilities: [100] Advanced Error Reporting > > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP= - > > ECRC- UnsupReq- ACSVoil- > > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP= - > > ECRC- UnsupReq- ACSVoil- > > UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ > > MalfTLP+ ECRC- UnsupReq- ACSVoil- > > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- > > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- > > Capabilities: [13c] Virtual Channel > > Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0 > > Capabilities: [16c] Power Budgeting > > Kernel driver in use: b43-pci-bridge > > Kernel modules: ssb > >=20 > > >>> =20 > > >>> =20 > > >>>> bar [1c] =3D type Memory, range 64, base 0xfa000000, size 33554432= , enabled > > >>>> =20 > > >>>> =20 > > >>> This one is BAR 3, which is used when it doesn't find BAR 1. > > >>> > > >>> robert. > > >>> > > >>> =20 > > >>> =20 > > >>>> bar [24] =3D type I/O Port, range 32, base 0xdf00, size 128, enabl= ed > > >>>> ndis0@pci0:12:0:0: class=3D0x028000 card=3D0x000a1028 chip=3D0x432= 814e4 > > >>>> rev=3D0x03 hdr=3D0x00 > > >>>> > > >>>> and follow your intrudction.still pain me :( > > >>>> > > >>>> (++) Using config file: "xorg.conf1" > > >>>> drm0: on vgapci0 > > >>>> info: [drm] Detected an NV50 generation card (0x086900a2) > > >>>> vgapci0: child drm0 requested pci_enable_busmaster > > >>>> info: [drm] Initialized nouveau 0.0.12 20060213 > > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find reso= urce 0x2 > > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find reso= urce 0x1 > > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find reso= urce 0x1 > > >>>> drm0: [ITHREAD] > > >>>> info: [drm] Allocating FIFO number 1 > > >>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, > > >>>> invalid/inactiv > > >>>> e channel id 128 > > >>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinf= o: > > >>>> [drm] , nSt > > >>>> atus:info: [drm] > > >>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data > > >>>> 0x00000000:0x00 > > >>>> 000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0= x8000003f > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0= xcf6f7f0e > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0= xfff7367f > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0= x00001850 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0= xafff3587 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0= x800b6fad > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0= x4df4fd60 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0= x000000d7 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0= x3139768d > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0= xf6d69757 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0= x63161650 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0= x07220009 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0= x00000000 > > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0= x00000000 > > >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 > > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 > > >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space > > >>>> (EE) Screen(s) found, but none have a usable configuration. > > >>>> > > >>>> Fatal server error: > > >>>> no screens found > > >>>> > > >>>> Please consult the The X.Org Foundation support > > >>>> at http://wiki.x.org > > >>>> for help. > > >>>> Please also check the log file at "/var/log/Xorg.0.log" for additi= onal > > >>>> informati > > >>>> on. > > >>>> > > >>>> info: [drm] nouveau_fifo_free: freeing fifo 1 > > >>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle chan= nel 1 > > >>>> before d > > >>>> estroy.Prepare for strangeness.. > > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127 > > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xfffffffff= fffffff). > > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find reso= urce 0x1 > > >>>> > > >>>> =20 > >=20 --=20 Robert Noland FreeBSD --=-usmBgkqy+4mpv+R9GDoy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknKaHEACgkQM4TrQ4qfROMmVwCeMhJYYRLyvcUxfGMPZlhbtdZ+ 28gAn1QVjsqX6lRnQHT1f2MU+YV789WJ =SfXP -----END PGP SIGNATURE----- --=-usmBgkqy+4mpv+R9GDoy-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 18:04:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715891065670 for ; Wed, 25 Mar 2009 18:04:12 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id D4B248FC15 for ; Wed, 25 Mar 2009 18:04:11 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 82475 invoked by uid 98); 25 Mar 2009 18:04:10 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9165. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.093305 secs); 25 Mar 2009 18:04:10 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Wed, 25 Mar 2009 18:04:10 +0000 Received: (qmail 99109 invoked by uid 1002); 25 Mar 2009 18:04:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Mar 2009 18:04:08 -0000 Date: Wed, 25 Mar 2009 18:04:08 +0000 (GMT) From: "Mark Powell" To: ticso@cicely.de In-Reply-To: <20090325152940.GB16409@cicely7.cicely.de> Message-ID: <20090325180054.L87213@rust.salford.ac.uk> References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , FreeBSD Current , Daniel Eriksson , Mark Powell , kevin Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:04:12 -0000 On Wed, 25 Mar 2009, Bernd Walter wrote: > On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: > I wouldn't be surprised if the problem is in the drive firmware. > Preread and wc both have the potential to put a lot load to the drives > and can trigger bugs that otherwise wouldn't matter. I've emailed WD support for more info. Not expecting much though. >From reading other threads on these Green Power drives them seem rather crap. This is my model and firmware: http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 There's some head park problem too, but with 5s ZFS sync I don't think it applies in this case: http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 > I also have a system running WD drives and ECC RAM which show CRC errors > from time to time, while all other systems have no CRC problem at all. Interesting. Are those CRC problems with WC on or off? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 18:15:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D74106566B for ; Wed, 25 Mar 2009 18:15:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id E194F8FC13 for ; Wed, 25 Mar 2009 18:15:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 32090 invoked by uid 399); 25 Mar 2009 18:14:58 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 18:14:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49CA74A0.6030201@FreeBSD.org> Date: Wed, 25 Mar 2009 11:14:56 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Robert Noland References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> <1237961497.1828.2.camel@balrog.2hip.net> <49C9ED34.20504@gddsn.org.cn> <1237998972.1828.4.camel@balrog.2hip.net> In-Reply-To: <1237998972.1828.4.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org, wsk Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:15:03 -0000 Can you guys please stop quoting hundreds of lines of text to add 2 lines of new material? :) Thanks, Doug From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 18:38:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E8AD106571C for ; Wed, 25 Mar 2009 18:38:44 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4E78FC16 for ; Wed, 25 Mar 2009 18:38:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n2PIcamm021221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2009 19:38:36 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n2PIcXlr082871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 19:38:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n2PIcX7r021472; Wed, 25 Mar 2009 19:38:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n2PIcWvi021471; Wed, 25 Mar 2009 19:38:32 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Mar 2009 19:38:32 +0100 From: Bernd Walter To: Mark Powell Message-ID: <20090325183831.GD16409@cicely7.cicely.de> References: <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325180054.L87213@rust.salford.ac.uk> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.029, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Alexander Leidinger , FreeBSD Current , Daniel Eriksson , ticso@cicely.de, kevin Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:38:46 -0000 On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: > On Wed, 25 Mar 2009, Bernd Walter wrote: > > >On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: > >I wouldn't be surprised if the problem is in the drive firmware. > >Preread and wc both have the potential to put a lot load to the drives > >and can trigger bugs that otherwise wouldn't matter. > > I've emailed WD support for more info. Not expecting much though. > From reading other threads on these Green Power drives them seem rather > crap. This is my model and firmware: > > http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 > > There's some head park problem too, but with 5s ZFS sync I don't think it > applies in this case: > > http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 > http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 > > >I also have a system running WD drives and ECC RAM which show CRC errors > >from time to time, while all other systems have no CRC problem at all. > > Interesting. Are those CRC problems with WC on or off? WC is on, prefetch is off, but only because it had bad performance with MySQL. Drives are Serial ATA II I don't know if it is with the drives, but other reasons are less likely in my opinion. The system is located in a data center and since I only get a few errors I decided to live with it and not to debug it further. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:14:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE311065676 for ; Wed, 25 Mar 2009 20:14:54 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 36F088FC15 for ; Wed, 25 Mar 2009 20:14:53 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2PKEo3C086949; Wed, 25 Mar 2009 21:14:51 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CA90BA.5090004@fgznet.ch> Date: Wed, 25 Mar 2009 21:14:50 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Doug Barton References: <49C16ECD.1040901@FreeBSD.org> In-Reply-To: <49C16ECD.1040901@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:14:55 -0000 Doug Barton wrote: > This was already discussed on -stable recently, so I've committed the > change in order to get it MFCed prior to the 7.2 code freeze. > > Would those of you who were concerned about this issue during the last > round of discussions please test this new option and report back? An understanding question here, should this also work when upgrading from cvs based install to an svn based install? Or does this only work when the cvs version differs? I'm updating right now a 7.1 install on ppc to a current, svn based build, from today. This is what I get here: ---- *** Displaying differences between ./etc/pam.d/ftpd and installed version: --- /etc/pam.d/ftpd 2009-01-03 23:32:10.000000000 +0100 +++ ./etc/pam.d/ftpd 2009-03-25 22:00:53.000000000 +0100 @@ -1,5 +1,5 @@ # -# $FreeBSD: src/etc/pam.d/ftpd,v 1.19.6.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD$ # # PAM configuration for the "ftpd" service # Use 'd' to delete the temporary ./etc/pam.d/ftpd Use 'i' to install the temporary ./etc/pam.d/ftpd Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again ---- TIA, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:22:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9389B1065673 for ; Wed, 25 Mar 2009 20:22:04 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id 39E9C8FC19 for ; Wed, 25 Mar 2009 20:22:03 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 5987 invoked by uid 1002); 25 Mar 2009 20:22:01 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.96.45.94) by s217.sureserver.com with ESMTPA; 25 Mar 2009 20:22:01 -0000 Date: Thu, 26 Mar 2009 01:55:42 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FreeBSD can't see OpenBSD slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:22:04 -0000 Hi: I installed OpenBSD 3.5 in a 25GB slice on a 160GB SATA HDD. Now when i power up the system and boot into a FreeBSD instalation CD (8.x 200902 snapshot), the Fdisk partition editor shows the entire disk as unused. Are slices created with OpenBSD tools not seen in FreeBSD ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:28:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3279B1065674 for ; Wed, 25 Mar 2009 20:28:38 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id CD6798FC12 for ; Wed, 25 Mar 2009 20:28:37 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 12730 invoked by uid 1002); 25 Mar 2009 20:28:36 -0000 Received: from unknown (HELO ?10.10.10.8?) (saifi.khan@twincling.org@59.96.45.94) by s217.sureserver.com with ESMTPA; 25 Mar 2009 20:28:36 -0000 Date: Thu, 26 Mar 2009 02:02:08 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FreeBSD 8.x 200902 snapshot Unable to find device node X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:28:38 -0000 Hi: Trying to install FreeBSD 6.x 200902 snapshot from a DVD media on a i386 box and i encounter this error dialog after selecting distribution set. "Unable to find device node for /dev/ad4/s2b in /dev! The creation of filesystems will be aborted" Any suggestions on a possible workaround ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:36:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B74106566C for ; Wed, 25 Mar 2009 20:36:01 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id EB4CD8FC16 for ; Wed, 25 Mar 2009 20:36:00 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A7FBDA079E; Wed, 25 Mar 2009 21:35:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 99EE4A079D; Wed, 25 Mar 2009 21:35:59 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 83E72A0794; Wed, 25 Mar 2009 21:35:59 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009032521355846-32448 ; Wed, 25 Mar 2009 21:35:58 +0100 Received: by wep4035 (sSMTP sendmail emulation); Wed, 25 Mar 2009 21:35:58 +0100 From: "Alexey Shuvaev" Date: Wed, 25 Mar 2009 21:35:58 +0100 To: ticso@cicely.de Message-ID: <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> References: <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> MIME-Version: 1.0 In-Reply-To: <20090325183831.GD16409@cicely7.cicely.de> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 03/25/2009 09:35:58 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 03/25/2009 09:35:59 PM, Serialize complete at 03/25/2009 09:35:59 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: FreeBSD Current , Mark Powell Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:36:01 -0000 On Wed, Mar 25, 2009 at 07:38:32PM +0100, Bernd Walter wrote: > On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: > > On Wed, 25 Mar 2009, Bernd Walter wrote: > > > > >On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: > > >I wouldn't be surprised if the problem is in the drive firmware. > > >Preread and wc both have the potential to put a lot load to the drives > > >and can trigger bugs that otherwise wouldn't matter. > > > > I've emailed WD support for more info. Not expecting much though. > > From reading other threads on these Green Power drives them seem rather > > crap. This is my model and firmware: > > > > http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 > > > > There's some head park problem too, but with 5s ZFS sync I don't think it > > applies in this case: > > > > http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 > > http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 > > > > >I also have a system running WD drives and ECC RAM which show CRC errors > > >from time to time, while all other systems have no CRC problem at all. > > > > Interesting. Are those CRC problems with WC on or off? > > WC is on, prefetch is off, but only because it had bad performance with > MySQL. > Drives are Serial ATA II > I don't know if it is with the drives, but other reasons are less > likely in my opinion. > The system is located in a data center and since I only get a few errors > I decided to live with it and not to debug it further. > Hello! Me too... I don't use zfs, just ufs2 + soft updates, but I see sometimes rather heavy data corruption (most often on / filesystem). No kernel messages, I can shut down the system successfully just to find the remnants of filesystems on the next boot. It doesn't happen often, I think compiling ports in a jail + some activity in the host increase the probability of a failure. The drive is: ATA channel 3: Master: ad6 SATA revision 2.x hw.ata.wc=1 (default) FWIW, Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:39:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C30210656C5 for ; Wed, 25 Mar 2009 20:39:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id C2FA08FC19 for ; Wed, 25 Mar 2009 20:39:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10443 invoked by uid 399); 25 Mar 2009 20:39:40 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 20:39:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49CA968A.5070403@FreeBSD.org> Date: Wed, 25 Mar 2009 13:39:38 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Andreas Tobler References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> In-Reply-To: <49CA90BA.5090004@fgznet.ch> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:39:45 -0000 Andreas Tobler wrote: > Doug Barton wrote: >> This was already discussed on -stable recently, so I've committed the >> change in order to get it MFCed prior to the 7.2 code freeze. >> >> Would those of you who were concerned about this issue during the last >> round of discussions please test this new option and report back? > > An understanding question here, should this also work when upgrading > from cvs based install to an svn based install? Yes, assuming that you've checked out the sources properly and actually have the svn Id string. I'm not sure how you got what you got there, but when I check out the sources with svn I get something like this: # $FreeBSD: head/etc/pam.d/ftpd 170510 2007-06-10 18:57:20Z yar $ Assuming you've run mergemaster on this installation previously you could use the -U option to install new files that you haven't modified. hth, Doug > This is what I get here: > > ---- > *** Displaying differences between ./etc/pam.d/ftpd and installed version: > > --- /etc/pam.d/ftpd 2009-01-03 23:32:10.000000000 +0100 > +++ ./etc/pam.d/ftpd 2009-03-25 22:00:53.000000000 +0100 > @@ -1,5 +1,5 @@ > # > -# $FreeBSD: src/etc/pam.d/ftpd,v 1.19.6.1 2008/11/25 02:59:29 kensmith > Exp $ > +# $FreeBSD$ > # > # PAM configuration for the "ftpd" service > # > > Use 'd' to delete the temporary ./etc/pam.d/ftpd > Use 'i' to install the temporary ./etc/pam.d/ftpd > Use 'm' to merge the temporary and installed versions > Use 'v' to view the diff results again > ---- > > > TIA, > Andreas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:41:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1C10106567D for ; Wed, 25 Mar 2009 20:41:56 +0000 (UTC) (envelope-from prvs=1335d0247d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5983D8FC16 for ; Wed, 25 Mar 2009 20:41:56 +0000 (UTC) (envelope-from prvs=1335d0247d=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1238013111; x=1238617911; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=xhkA48V0IT3A4hCdklShF /k4WxkDzMPWf5uOYCtcGdk=; b=KAiOeyY78FsJ12rRMH9f1Do2nt7FAGVu4rnit ZIF257wr7YLTVy7KU7u6mDUctv2JqP/xbC2OrOABAQe9+yIUUZKwykfFKFXfyB1Y n4fxu5ycJ6rKr6Nvlag9luj0qORfKZVqhOWHBScpvF7sZE7O2LtO8jKFEaeO2r7Z GeIXgo= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 25 Mar 2009 20:31:51 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50007208302.msg for ; Wed, 25 Mar 2009 20:31:50 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 25 Mar 2009 20:31:50 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 85.236.106.102 X-Return-Path: prvs=1335d0247d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <8B62DA55AA354DC48B1BB5ADD7838470@multiplay.co.uk> From: "Steven Hartland" To: "Saifi Khan" , References: Date: Wed, 25 Mar 2009 20:31:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: FreeBSD 8.x 200902 snapshot Unable to find device node X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:41:57 -0000 Try a 7.x? Regards Steve ----- Original Message ----- From: "Saifi Khan" > Hi: > > Trying to install FreeBSD 6.x 200902 snapshot from a DVD media > on a i386 box and i encounter this error dialog after selecting > distribution set. > > "Unable to find device node for /dev/ad4/s2b in /dev! > The creation of filesystems will be aborted" > > Any suggestions on a possible workaround ? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:46:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3DC106566C for ; Wed, 25 Mar 2009 20:46:30 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 1F63B8FC12 for ; Wed, 25 Mar 2009 20:46:29 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 19so685999fgg.12 for ; Wed, 25 Mar 2009 13:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GqfrM04LpWyk0HEV2Mb8o2jrgbwQBFCZ+RnJSYHQO5Y=; b=hwckpRXOyAOfBAiZV5VN0HP83SMFV7AKLcmtHVZc9/iBrsetbNmfsitepiCdTzwNNE 0TApm+c0rwmz2btOLeDWtEsMfMfNNEl427orwHOwUa/3Xd2QE/82L3Wf4QdTa47qlUqH /nYy5l0NgsIxuqRLSkOQvrtGKHdPFejwdMwNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=pPnAbp7Tictw3uap85kkiItp7z8u7+571kCGWSCpVyFze25oQJ/hSQWaH0V8l/5BsE Y4bnIV4C2dO7CobrFfKEDq6aqUZXrh2xMJs7SXnZV3mR1p7HWiNVqevD5qKNafzP7/rK 43w9l5n+v1mPW2RwsWhco4GeIHKqCn0f2LQzY= Received: by 10.86.76.16 with SMTP id y16mr381926fga.18.1238013989223; Wed, 25 Mar 2009 13:46:29 -0700 (PDT) Received: from ?192.168.2.24? (p5486C8AF.dip.t-dialin.net [84.134.200.175]) by mx.google.com with ESMTPS id d6sm3237394fga.7.2009.03.25.13.46.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 13:46:28 -0700 (PDT) Message-ID: <49CA9823.9050605@googlemail.com> Date: Wed, 25 Mar 2009 21:46:27 +0100 From: "army.of.root" User-Agent: Thunderbird 2.0.0.17 (X11/20081028) MIME-Version: 1.0 To: FreeBSD Current References: <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:46:31 -0000 Alexey Shuvaev wrote: > On Wed, Mar 25, 2009 at 07:38:32PM +0100, Bernd Walter wrote: >> On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: >>> On Wed, 25 Mar 2009, Bernd Walter wrote: >>> >>>> On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: >>>> I wouldn't be surprised if the problem is in the drive firmware. >>>> Preread and wc both have the potential to put a lot load to the drives >>>> and can trigger bugs that otherwise wouldn't matter. >>> I've emailed WD support for more info. Not expecting much though. >>> From reading other threads on these Green Power drives them seem rather >>> crap. This is my model and firmware: >>> >>> http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 >>> >>> There's some head park problem too, but with 5s ZFS sync I don't think it >>> applies in this case: >>> >>> http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 >>> http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 >>> >>>> I also have a system running WD drives and ECC RAM which show CRC errors >>> >from time to time, while all other systems have no CRC problem at all. >>> >>> Interesting. Are those CRC problems with WC on or off? >> WC is on, prefetch is off, but only because it had bad performance with >> MySQL. >> Drives are Serial ATA II >> I don't know if it is with the drives, but other reasons are less >> likely in my opinion. >> The system is located in a data center and since I only get a few errors >> I decided to live with it and not to debug it further. >> > Hello! > > Me too... > > I don't use zfs, just ufs2 + soft updates, but I see sometimes rather > heavy data corruption (most often on / filesystem). > No kernel messages, I can shut down the system successfully just > to find the remnants of filesystems on the next boot. > It doesn't happen often, I think compiling ports in a jail + some > activity in the host increase the probability of a failure. > > The drive is: > ATA channel 3: > Master: ad6 SATA revision 2.x > > hw.ata.wc=1 (default) > > FWIW, > Alexey. Hi :) Damn f**k ! - I just bought WD harddrives for my Workstation... is there any way to detect silent data corruption without ZFS ? best regards PS: Thanks for all your work, I'm looking soo forward to 8.0 I cant even tell you how much :) From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:53:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA73106566C; Wed, 25 Mar 2009 20:53:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 064338FC15; Wed, 25 Mar 2009 20:53:51 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2PKqTrd031082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 16:52:30 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-D8o92gBuUEIuqDLztgWV" Organization: FreeBSD Date: Wed, 25 Mar 2009 15:53:24 -0500 Message-Id: <1238014404.1828.27.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:53:52 -0000 --=-D8o92gBuUEIuqDLztgWV Content-Type: multipart/mixed; boundary="=-R4F87V/cUFXsZbQ+idcN" --=-R4F87V/cUFXsZbQ+idcN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote: > On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland wro= te: > > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: > >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall = wrote: > >> > Brandon Gooch wrote: > >> >> > >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wro= te: > >> >> > >> >>> > >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >> >>> > >> >>>> > >> >>>> The committed version is working well, I am suspending and resumi= ng > >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of the > >> >>>> major things I needed to work so I could run FreeBSD primarily on > >> >>>> my notebook. > >> >>>> > >> >> > >> >> I just finished a kernel build and it seems as though your > >> >> recent commits have fixed the clock (at least for me)! > >> >> > >> >> I feel sorry for all the i386 folks on ACPI notebooks... > >> >> > >> >> Thanks! > >> >> > >> >> -Brandon > >> >> > >> > > >> > Picking a semi-random message here.. > >> > > >> > Thanks for your work on this! In the past (months ago) I tried the = patch > >> > set which didn't work, but the code in -current lets me suspend and = resume > >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think thi= s is a > >> > first for me, of all the laptops I've had, none have ever been able = to > >> > suspend and resume in a successful or useful way, and I've been jeal= ous of > >> > the Thinkpad users that could claim otherwise. I could suspend and = resume > >> > fine while in the console, then I ran startx and the suspend and res= ume > >> > worked while I was in X with intel graphics, however my system was s= low > >> > after that resume. I didn't spend much time looking at it since I w= as at > >> > work, and I didn't see any obvious reasons for the slowness (cpu fre= quency > >> > was fine, cx states were C2 or lower (C1), top showed mostly idle, n= o > >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not the= mouse > >> > or typing though). I didn't go back to console, I just shut down wi= thout > >> > trying any other situations yet. > >> > > >> > A tip I want to note for any users who may not have success with the= ir > >> > screen on resume: In the past it seemed to help me to have a power-= on > >> > password set in my BIOS since the BIOS will turn on the screen on re= sume to > >> > ask me for my password. I don't know if it is still helping me, but= I've > >> > seen in the past where it has. > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" > >> > > >> > >> The sluggish response in X on Intel video has been an issue the past > >> couple of days, triggered by suspend/resume or simply switching to VTY > >> and back. > > > > I just committed code that should fix this... > > > > robert. > > > >> See this thread: > >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.h= tml > >> > >> Firefox is unusable, but xterms are still usable. I have to reboot to > >> get back to "normal" > >> > >> -Brandon > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > > -- > > Robert Noland > > FreeBSD > > >=20 > It seems to have helped -- slightly. Firefox is still too laggy when > interacting with interface elements (scrollbar, toolbars, menus), and > typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to > use, perhaps because they're not as graphically intensive :) >=20 > Also, it seems to have broken the suspend/resume. The machine does > wake up, but X is no longer there (I'm at the VTY from which I started > X) and I can't switch to another VTY. The machine still "works" for a > period, but attempts to switch VTY or enter commands from the keyboard > eventually lock it up, resulting in a continuous beep tone and > requiring a hard power-off (holding down the power button). Can you try the attached patch? This was a last minute change that I made and I don't know why it seems to be upsetting things so, but it looks like it causes things to not shutdown properly. It looks like it isn't safe to suspend with / on usb2, so I can't really test s/r still... robert. > -Brandon --=20 Robert Noland FreeBSD --=-R4F87V/cUFXsZbQ+idcN Content-Disposition: attachment; filename="drm_irq.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="drm_irq.patch"; charset="us-ascii" SW5kZXg6IGRldi9kcm0vZHJtX2lycS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gZGV2L2RybS9kcm1faXJx LmMJKHJldmlzaW9uIDE5MDQyMCkNCisrKyBkZXYvZHJtL2RybV9pcnEuYwkod29ya2luZyBjb3B5 KQ0KQEAgLTQ2MywxNiArNDYzLDE5IEBADQogCX0gZWxzZSB7DQogCQlEUk1fREVCVUcoIndhaXRp bmcgb24gdmJsYW5rIGNvdW50ICVkLCBjcnRjICVkXG4iLA0KIAkJICAgIHZibHdhaXQtPnJlcXVl c3Quc2VxdWVuY2UsIGNydGMpOw0KLQkJbXR4X2xvY2soJmRldi0+aXJxX2xvY2spOw0KIAkJZGV2 LT52YmxhbmtbY3J0Y10ubGFzdCA9IHZibHdhaXQtPnJlcXVlc3Quc2VxdWVuY2U7DQogCQlmb3Ig KCByZXQgPSAwIDsgIXJldCAmJiAhKCgoZHJtX3ZibGFua19jb3VudChkZXYsIGNydGMpIC0NCiAJ CSAgICB2Ymx3YWl0LT5yZXF1ZXN0LnNlcXVlbmNlKSA8PSAoMSA8PCAyMykpIHx8DQogCQkgICAg IWRldi0+aXJxX2VuYWJsZWQpIDsgKSB7DQotCQkJcmV0ID0gbXR4X3NsZWVwKCZkZXYtPnZibGFu a1tjcnRjXS5xdWV1ZSwNCi0JCQkgICAgJmRldi0+aXJxX2xvY2ssIFBDQVRDSCwgInZibHd0cSIs DQotCQkJICAgIDMgKiBEUk1fSFopOw0KKwkJCW10eF9sb2NrKCZkZXYtPmlycV9sb2NrKTsNCisJ CQlpZiAoISgoKGRybV92YmxhbmtfY291bnQoZGV2LCBjcnRjKSAtDQorCQkJICAgIHZibHdhaXQt PnJlcXVlc3Quc2VxdWVuY2UpIDw9ICgxIDw8IDIzKSkgfHwNCisJCQkgICAgIWRldi0+aXJxX2Vu YWJsZWQpKQ0KKwkJCQlyZXQgPSBtdHhfc2xlZXAoJmRldi0+dmJsYW5rW2NydGNdLnF1ZXVlLA0K KwkJCQkgICAgJmRldi0+aXJxX2xvY2ssIFBDQVRDSCwgInZibHd0cSIsDQorCQkJCSAgICAzICog RFJNX0haKTsNCisJCQltdHhfdW5sb2NrKCZkZXYtPmlycV9sb2NrKTsNCiAJCX0NCi0JCW10eF91 bmxvY2soJmRldi0+aXJxX2xvY2spOw0KIA0KIAkJaWYgKHJldCAhPSBFSU5UUiAmJiByZXQgIT0g RVJFU1RBUlQpIHsNCiAJCQlzdHJ1Y3QgdGltZXZhbCBub3c7DQo= --=-R4F87V/cUFXsZbQ+idcN-- --=-D8o92gBuUEIuqDLztgWV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknKmcQACgkQM4TrQ4qfRON6HACfUp9rkDNC1jBzgDkcCMbOymvQ iSoAnjS+LVK2L3t5yvDHDY50chZPIjxV =GZsb -----END PGP SIGNATURE----- --=-D8o92gBuUEIuqDLztgWV-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 20:55:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B151106566C; Wed, 25 Mar 2009 20:55:01 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 97EB58FC0C; Wed, 25 Mar 2009 20:54:59 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2PKsvEO049122; Wed, 25 Mar 2009 21:54:58 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CA9A21.3090302@fgznet.ch> Date: Wed, 25 Mar 2009 21:54:57 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Doug Barton References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> <49CA968A.5070403@FreeBSD.org> In-Reply-To: <49CA968A.5070403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:55:01 -0000 Doug Barton wrote: > Andreas Tobler wrote: >> Doug Barton wrote: >>> This was already discussed on -stable recently, so I've committed the >>> change in order to get it MFCed prior to the 7.2 code freeze. >>> >>> Would those of you who were concerned about this issue during the last >>> round of discussions please test this new option and report back? >> An understanding question here, should this also work when upgrading >> from cvs based install to an svn based install? > > Yes, assuming that you've checked out the sources properly and > actually have the svn Id string. I'm not sure how you got what you got > there, but when I check out the sources with svn I get something like > this: > > # $FreeBSD: head/etc/pam.d/ftpd 170510 2007-06-10 18:57:20Z yar $ Hm, then it seems to me that I did something 'wrong' when I co'ed the svn repository. I am an anonymous user, aka having no svn account. This how I co'ed the repo: svn checkout svn://svn.freebsd.org/base/head src Doing so gives me a $FreeBSD$ on top of each file w/o a rev id. Do I need something else to be passed to svn co? > Assuming you've run mergemaster on this installation previously you > could use the -U option to install new files that you haven't modified. Well, in my case I did type 'i' many times and now I am happy with a 2 hour install/upgrade cycle from 7.1 to current. Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:02:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD27106566B for ; Wed, 25 Mar 2009 21:02:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA2E8FC15 for ; Wed, 25 Mar 2009 21:02:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 11423 invoked by uid 399); 25 Mar 2009 21:02:10 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 21:02:10 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49CA9BD0.70205@FreeBSD.org> Date: Wed, 25 Mar 2009 14:02:08 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Andreas Tobler References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> <49CA968A.5070403@FreeBSD.org> <49CA9A21.3090302@fgznet.ch> In-Reply-To: <49CA9A21.3090302@fgznet.ch> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:02:13 -0000 Andreas Tobler wrote: > Hm, then it seems to me that I did something 'wrong' when I co'ed the > svn repository. I am an anonymous user, aka having no svn account. You're not using the devel/subversion-freebsd port. > This how I co'ed the repo: > > svn checkout svn://svn.freebsd.org/base/head src I just tested that with the subversion-freebsd version, and it worked just fine. > Well, in my case I did type 'i' many times and now I am happy with a 2 > hour install/upgrade cycle from 7.1 to current. I'm glad you're happy now, but you won't be when you do your next mergemaster run. :) Mergemaster counts on there being a real version number in the VCS Id string to compare against and learn about new versions of files. If the files in your base and the files in the src tree all have identical strings (i.e., they are all equal to $FreeBSD$) then mergemaster will never know that there is a new version available. hth, Doug From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:11:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5318106564A for ; Wed, 25 Mar 2009 21:11:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id A21C58FC08 for ; Wed, 25 Mar 2009 21:11:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n2PLBVBX024947; Wed, 25 Mar 2009 14:11:31 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id sxr455unr96gqfztkucjdz447e; Wed, 25 Mar 2009 14:11:30 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49CA9E02.5070706@freebsd.org> Date: Wed, 25 Mar 2009 14:11:30 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.19) Gecko/20090226 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Doug Barton References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> <49CA968A.5070403@FreeBSD.org> <49CA9A21.3090302@fgznet.ch> <49CA9BD0.70205@FreeBSD.org> In-Reply-To: <49CA9BD0.70205@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andreas Tobler , FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:11:48 -0000 Doug Barton wrote: > Andreas Tobler wrote: >> Hm, then it seems to me that I did something 'wrong' when I co'ed the >> svn repository. I am an anonymous user, aka having no svn account. > > You're not using the devel/subversion-freebsd port. > I'm glad you're happy now, but you won't be when you do your next > mergemaster run. :) > > Mergemaster counts on there being a real version number in the VCS Id > string to compare against and learn about new versions of files. If > the files in your base and the files in the src tree all have > identical strings (i.e., they are all equal to $FreeBSD$) then > mergemaster will never know that there is a new version available. This sounds like a problem. I'm not sure we can safely assume that non-committers will be using devel/subversion-freebsd. I've long wondered if there were some way to generically checksum every one of these files at install time (Maybe adding a final "#md5:XXXXXXXX" line? Does every file in /etc/ support "#" as a comment start?) Then these checksums could be used to definitively determine: * Files that had local edits (checksum mismatch) * Old files that were different from the system being installed all without relying on VCS IDs or other conventions. In particular, it would be really nice to be able to say "just update everything that doesn't have local edits and let me manually review the rest." Tim From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:12:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80721065673 for ; Wed, 25 Mar 2009 21:12:49 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4288FC2D for ; Wed, 25 Mar 2009 21:12:49 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6CE60A07A6; Wed, 25 Mar 2009 22:12:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6040BA07A4; Wed, 25 Mar 2009 22:12:48 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 42C12A07A0; Wed, 25 Mar 2009 22:12:48 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009032522124781-32549 ; Wed, 25 Mar 2009 22:12:47 +0100 Received: by wep4035 (sSMTP sendmail emulation); Wed, 25 Mar 2009 22:12:47 +0100 Date: Wed, 25 Mar 2009 22:12:47 +0100 From: Alexey Shuvaev To: "army.of.root" Message-ID: <20090325211247.GA4659@wep4035.physik.uni-wuerzburg.de> References: <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> <49CA9823.9050605@googlemail.com> MIME-Version: 1.0 In-Reply-To: <49CA9823.9050605@googlemail.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 03/25/2009 10:12:47 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 03/25/2009 10:12:48 PM, Serialize complete at 03/25/2009 10:12:48 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: FreeBSD Current Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:12:50 -0000 On Wed, Mar 25, 2009 at 09:46:27PM +0100, army.of.root wrote: > Alexey Shuvaev wrote: >> On Wed, Mar 25, 2009 at 07:38:32PM +0100, Bernd Walter wrote: >>> On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: >>>> On Wed, 25 Mar 2009, Bernd Walter wrote: >>>> >>>>> On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: >>>>> I wouldn't be surprised if the problem is in the drive firmware. >>>>> Preread and wc both have the potential to put a lot load to the drives >>>>> and can trigger bugs that otherwise wouldn't matter. >>>> I've emailed WD support for more info. Not expecting much though. >>>> From reading other threads on these Green Power drives them seem >>>> rather crap. This is my model and firmware: >>>> >>>> http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 >>>> >>>> There's some head park problem too, but with 5s ZFS sync I don't >>>> think it applies in this case: >>>> >>>> http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 >>>> http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 >>>> >>>>> I also have a system running WD drives and ECC RAM which show CRC errors >>>> >from time to time, while all other systems have no CRC problem at all. >>>> >>>> Interesting. Are those CRC problems with WC on or off? >>> WC is on, prefetch is off, but only because it had bad performance with >>> MySQL. >>> Drives are Serial ATA II >>> I don't know if it is with the drives, but other reasons are less >>> likely in my opinion. >>> The system is located in a data center and since I only get a few errors >>> I decided to live with it and not to debug it further. >>> >> Hello! >> >> Me too... >> >> I don't use zfs, just ufs2 + soft updates, but I see sometimes rather >> heavy data corruption (most often on / filesystem). >> No kernel messages, I can shut down the system successfully just >> to find the remnants of filesystems on the next boot. >> It doesn't happen often, I think compiling ports in a jail + some >> activity in the host increase the probability of a failure. >> >> The drive is: >> ATA channel 3: >> Master: ad6 SATA revision 2.x >> >> hw.ata.wc=1 (default) >> >> FWIW, >> Alexey. > > Hi :) > > Damn f**k ! - I just bought WD harddrives for my Workstation... > > is there any way to detect silent data corruption without ZFS ? > Not I'm aware of... I vaguely remember some Lock Order Reversal appearing before the system goes to the hell (something with kn_list???) but it may be unrelated. Anyway if you see it, it is too late... The first symptom is some applications are crashing with signal 11 and absolutely trashed backtraces. One time I have tried to break into debugger in such a state and do immediate reboot but it didn't help, disk seems to be already synced at that time... Sometimes the system survives for a few weeks, sometimes only for a few days. So, backup, backup, backup... Just my 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:22:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F9B5106564A for ; Wed, 25 Mar 2009 21:22:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B5FF98FC17 for ; Wed, 25 Mar 2009 21:22:41 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so256698ewy.43 for ; Wed, 25 Mar 2009 14:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=54HYGr6SRHQvBg7jOA/z4/NQFBcqYBniGz+UQoDskZs=; b=a9anqFuN1FpybCT0riH63WsVKfbesqmk6njBJUD0yptcPaRmVFqBpNbuTPLzf9VOLm zMozjdQ6gkOdzW2V0tpxbHmJX/qaIXEsxR3+Grcznrfec2/m5g43Zs8xgcFkeDzBHxPS TnE/WSJbnx4eIWbxoG+yDhu2uZmjBm9nb+W7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sN4QrHGJxmnmobZbLVgW+dYvYiImwruxmqoWN61DbkccVM4aA/Zvz9zoO47UmR5Ind eut+A//66f5Ww2nI5xtEeS2uhiAHSjjFO0QBRIu2nlQ4l1Qc6Klhe6zPJPMbviOCAV3G yTKMNI+RnTfBrvpDHSe1eDnE9Y3htNHnXbHt4= MIME-Version: 1.0 Received: by 10.210.115.15 with SMTP id n15mr4422901ebc.95.1238016159483; Wed, 25 Mar 2009 14:22:39 -0700 (PDT) In-Reply-To: <200903111233.14029.jkim@FreeBSD.org> References: <200903111233.14029.jkim@FreeBSD.org> Date: Wed, 25 Mar 2009 22:22:39 +0100 Message-ID: <3a142e750903251422x3c19207by5c817bfa9d872b85@mail.gmail.com> From: "Paul B. Mahol" To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:22:42 -0000 On 3/11/09, Jung-uk Kim wrote: > With popular demands, I will commit the following patch in next few > days unless a showstopper is found or "over-my-dead-body" type of > review is received. ;-) > > http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > > FYI, it was originally posted here: > > http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > > and here: > > http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > > Please read the original threads for more information about the patch. Looks some of your changes makes i386 without ACPI (acpi is disabled; not loaded and hint.acpi.0.disabled=1) fail to reboot. It this already known/documented behavior? -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:24:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29ED210656F3; Wed, 25 Mar 2009 21:24:17 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id B82EA8FC22; Wed, 25 Mar 2009 21:24:16 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2PLODFj094879; Wed, 25 Mar 2009 22:24:14 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CAA0FD.9000206@fgznet.ch> Date: Wed, 25 Mar 2009 22:24:13 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Doug Barton References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> <49CA968A.5070403@FreeBSD.org> <49CA9A21.3090302@fgznet.ch> <49CA9BD0.70205@FreeBSD.org> In-Reply-To: <49CA9BD0.70205@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:24:17 -0000 Doug Barton wrote: > Andreas Tobler wrote: >> Hm, then it seems to me that I did something 'wrong' when I co'ed the >> svn repository. I am an anonymous user, aka having no svn account. > > You're not using the devel/subversion-freebsd port. Aha! I was using plain svn 1.5.5.1. Thanks! Now I'm using it and I have what I need. # $FreeBSD: head/usr.bin/atm/Makefile 121666 2003-10-29 10:30:54Z harti $ >> This how I co'ed the repo: >> >> svn checkout svn://svn.freebsd.org/base/head src > > I just tested that with the subversion-freebsd version, and it worked > just fine. > >> Well, in my case I did type 'i' many times and now I am happy with a 2 >> hour install/upgrade cycle from 7.1 to current. > > I'm glad you're happy now, but you won't be when you do your next > mergemaster run. :) I'm happy in terms of build and install time, I did not reinstall world yet again. The platform where I install the current build takes ages to build itself. So I crossbuilt. I NFS exported the install/src dir and rsynced the root and mergemastered -F. > Mergemaster counts on there being a real version number in the VCS Id > string to compare against and learn about new versions of files. If > the files in your base and the files in the src tree all have > identical strings (i.e., they are all equal to $FreeBSD$) then > mergemaster will never know that there is a new version available. Ok. This would have hit me tomorrow, after a new install. Thanks again, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:30:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB20106568D; Wed, 25 Mar 2009 21:30:51 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFE48FC18; Wed, 25 Mar 2009 21:30:50 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2PLUmTk015883; Wed, 25 Mar 2009 22:30:49 +0100 Received: from [192.168.100.184] ([88.11.103.61]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032522304812:193807 ; Wed, 25 Mar 2009 22:30:48 +0100 Message-ID: <49CAA201.7000205@entel.upc.edu> Date: Wed, 25 Mar 2009 22:28:33 +0100 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Jung-uk Kim References: <1236802980.00085518.1236789602@10.7.7.3> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <200903241528.34902.jkim@FreeBSD.org> In-Reply-To: <200903241528.34902.jkim@FreeBSD.org> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 25/03/2009 22:30:48, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 25/03/2009 22:30:49, Serialize complete at 25/03/2009 22:30:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 25 Mar 2009 22:30:49 +0100 (CET) Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:30:53 -0000 > Please try the attached patch, which just disables restoring VGA state > while resuming. > > Tried your patch again, and this time using hw.acpi.reset_video, hw.acpi.suspend_bounce and friends. The same result, the screen remains completely black. Before appliying the patch, when resuming the screen showed messages about the resume of some hardware (usb, firewire, etc ...) and then it went black. Is there anything I can test ? Greets, > Jung-uk Kim > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:34:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1E71065672 for ; Wed, 25 Mar 2009 21:34:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9D88FC1C for ; Wed, 25 Mar 2009 21:34:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30633 invoked by uid 399); 25 Mar 2009 21:34:07 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Mar 2009 21:34:07 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49CAA34D.3080209@FreeBSD.org> Date: Wed, 25 Mar 2009 14:34:05 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Tim Kientzle References: <49C16ECD.1040901@FreeBSD.org> <49CA90BA.5090004@fgznet.ch> <49CA968A.5070403@FreeBSD.org> <49CA9A21.3090302@fgznet.ch> <49CA9BD0.70205@FreeBSD.org> <49CA9E02.5070706@freebsd.org> In-Reply-To: <49CA9E02.5070706@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andreas Tobler , FreeBSD Current Subject: Re: New mergemaster option to install files that differ only by $FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:34:09 -0000 Tim Kientzle wrote: > Doug Barton wrote: >> Andreas Tobler wrote: >>> Hm, then it seems to me that I did something 'wrong' when I co'ed the >>> svn repository. I am an anonymous user, aka having no svn account. >> >> You're not using the devel/subversion-freebsd port. > >> I'm glad you're happy now, but you won't be when you do your next >> mergemaster run. :) >> >> Mergemaster counts on there being a real version number in the VCS Id >> string to compare against and learn about new versions of files. If >> the files in your base and the files in the src tree all have >> identical strings (i.e., they are all equal to $FreeBSD$) then >> mergemaster will never know that there is a new version available. > > This sounds like a problem. This sounds like the way that mergemaster has worked for 11 years. That said, mergemaster has the option for doing a "strict" comparison that ignores the VCS Id already. If this issue becomes widespread before a better solution arises I can enable that option by default. > I'm not sure we can > safely assume that non-committers will be using > devel/subversion-freebsd. Then we need to make sure that the server side does the right thing in that case. (This will be a problem that goes way past a minor inconvenience for mergemaster if we don't get it right.) > I've long wondered if there were some way to generically > checksum every one of these files at install time > (Maybe adding a final "#md5:XXXXXXXX" line? Does every > file in /etc/ support "#" as a comment start?) Well that definitely won't work, and no, not every file supports that kind of comment. However, there is a -U option to mergemaster that works off the checksum of the unmodified files created in the temproot directory from your last run that allows you to automatically update the files in your base that you haven't modified. There is a boot-strapping problem with new installs that the -F option was designed to help work around. If I get the time I will work with re@ to see if we can't generate that mtree database as part of the release build, but I'm not making any promises. > Then these checksums could be used to definitively > determine: > * Files that had local edits (checksum mismatch) > * Old files that were different from the system being installed > all without relying on VCS IDs or other conventions. > In particular, it would be really nice to be able to > say "just update everything that doesn't have local edits > and let me manually review the rest." As I said, the -U option already does that. I really wish that people who had Bright IdeasTM for mergemaster would read the man page first. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 21:51:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22BB106564A for ; Wed, 25 Mar 2009 21:51:30 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 250EB8FC0C for ; Wed, 25 Mar 2009 21:51:29 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n2PLpMNG013556; Wed, 25 Mar 2009 22:51:22 +0100 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Wed, 25 Mar 2009 22:51:22 +0100 User-Agent: KMail/1.9.10 References: <20090320102824.W75873@rust.salford.ac.uk> <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> <49CA9823.9050605@googlemail.com> In-Reply-To: <49CA9823.9050605@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903252251.22791.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: "army.of.root" Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:51:30 -0000 On Wednesday 25 March 2009 21:46:27 army.of.root wrote: > Alexey Shuvaev wrote: > > On Wed, Mar 25, 2009 at 07:38:32PM +0100, Bernd Walter wrote: > >> On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: > >>> On Wed, 25 Mar 2009, Bernd Walter wrote: > >>>> On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: > >>>> I wouldn't be surprised if the problem is in the drive firmware. > >>>> Preread and wc both have the potential to put a lot load to the drives > >>>> and can trigger bugs that otherwise wouldn't matter. > >>> > >>> I've emailed WD support for more info. Not expecting much though. > >>> From reading other threads on these Green Power drives them seem rather > >>> crap. This is my model and firmware: > >>> > >>> http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B > >>>1 > >>> > >>> There's some head park problem too, but with 5s ZFS sync I don't think > >>> it applies in this case: > >>> > >>> http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&p > >>>ostorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 > >>> http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 > >>> > >>>> I also have a system running WD drives and ECC RAM which show CRC > >>>> errors > >>>> > >>> >from time to time, while all other systems have no CRC problem at all. > >>> > >>> Interesting. Are those CRC problems with WC on or off? > >> > >> WC is on, prefetch is off, but only because it had bad performance with > >> MySQL. > >> Drives are Serial ATA II > >> I don't know if it is with the drives, but other reasons are less > >> likely in my opinion. > >> The system is located in a data center and since I only get a few errors > >> I decided to live with it and not to debug it further. > > > > Hello! > > > > Me too... > > > > I don't use zfs, just ufs2 + soft updates, but I see sometimes rather > > heavy data corruption (most often on / filesystem). > > No kernel messages, I can shut down the system successfully just > > to find the remnants of filesystems on the next boot. > > It doesn't happen often, I think compiling ports in a jail + some > > activity in the host increase the probability of a failure. > > > > The drive is: > > ATA channel 3: > > Master: ad6 SATA revision 2.x > > > > hw.ata.wc=1 (default) > > > > FWIW, > > Alexey. > > Hi :) > > Damn f**k ! - I just bought WD harddrives for my Workstation... I find this all very odd because I have a pair of WDC WD6400AAKS-00A7B0 drives using UFS2 + SU on the latest -CURRENT (i386) and no corruption at all (as far as I can tell ofcourse). The drives are pretty fast btw. Just for fun I gstriped both of them and got speeds in excess of 200MB/sec. On another PC I've got a WDC WD10EACS-00ZJB0 1TB "Green Power" disk, also using UFS2+SU and no problems at all. That PC is running 7-STABLE however. > > is there any way to detect silent data corruption without ZFS ? Perhaps if you mirror a couple of drives you can manually verify that they have the same md5sum. > > best regards > > PS: Thanks for all your work, I'm looking soo forward to 8.0 I cant even > tell you how much :) Me too :-) -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 22:23:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9141C10656C1; Wed, 25 Mar 2009 22:23:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Paul B. Mahol" Date: Wed, 25 Mar 2009 18:23:30 -0400 User-Agent: KMail/1.6.2 References: <200903111233.14029.jkim@FreeBSD.org> <3a142e750903251422x3c19207by5c817bfa9d872b85@mail.gmail.com> In-Reply-To: <3a142e750903251422x3c19207by5c817bfa9d872b85@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903251823.40899.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:23:50 -0000 On Wednesday 25 March 2009 05:22 pm, Paul B. Mahol wrote: > On 3/11/09, Jung-uk Kim wrote: > > With popular demands, I will commit the following patch in next > > few days unless a showstopper is found or "over-my-dead-body" > > type of review is received. ;-) > > > > http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > > > > FYI, it was originally posted here: > > > > http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > > > > and here: > > > > http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > > > > Please read the original threads for more information about the > > patch. > > Looks some of your changes makes i386 without ACPI (acpi is > disabled; not loaded and hint.acpi.0.disabled=1) fail to reboot. > > It this already known/documented behavior? Huh? No, it is totally unexpected because I didn't touch non-ACPI path for i386. Can you back out r189903, r190339, r190340 and test again? Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 22:33:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 02BB71065672; Wed, 25 Mar 2009 22:33:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Gustau Perez Date: Wed, 25 Mar 2009 18:33:13 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> In-Reply-To: <49CAA201.7000205@entel.upc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903251833.14825.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:33:22 -0000 On Wednesday 25 March 2009 05:28 pm, Gustau Perez wrote: > > Please try the attached patch, which just disables restoring VGA > > state while resuming. > > Tried your patch again, and this time using hw.acpi.reset_video, > hw.acpi.suspend_bounce and friends. The same result, the screen > remains completely black. > > Before appliying the patch, when resuming the screen showed > messages about the resume of some hardware (usb, firewire, etc ...) > and then it went black. > > Is there anything I can test ? Then, it is something else, e.g., acpi_video(4). You can try setting debug.acpi.disabled="video" in /boot/loader.conf for example. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 22:55:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A11106570F; Wed, 25 Mar 2009 22:55:28 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id CA7EF8FC25; Wed, 25 Mar 2009 22:55:27 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so61179eyf.7 for ; Wed, 25 Mar 2009 15:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H5fl2Qiwe82i7cN5ULgDAffHyYj7aR/y7P4h6JDfY9g=; b=ZD0DR+vgnu1tEHzNL9O5AuV3uh0vuq4rpnPY+OsurFMBGz84V/F2GqgD1H8wf296rU 7C09YfV1Jyt5kiZ0Xxmdjr82KJT8ECY4Ftr3d9mPX2zeFi/qRKUNqiKBVQ01VcdSTVLJ YLRzvaM2tQrZTBGkbunK1P+i63oxhu7O5iGsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L5Q1OY+S/9xeFVIouqMLbiKop1m9r6chjyj6BNcI/nddI57TVlBQEVpqxpqlLsrUo8 URBbm8jX1+grr7bwAf8SkQy6TYYMSjZLmaGa2YrzHbPiHsLEIQYhQaqEY+7chL8WPXK6 Qcw+50B3BWDPIAlaGmC3GQMv6VPMCihUwFvJ0= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr79017ebs.74.1238021726905; Wed, 25 Mar 2009 15:55:26 -0700 (PDT) In-Reply-To: <200903251823.40899.jkim@FreeBSD.org> References: <200903111233.14029.jkim@FreeBSD.org> <3a142e750903251422x3c19207by5c817bfa9d872b85@mail.gmail.com> <200903251823.40899.jkim@FreeBSD.org> Date: Wed, 25 Mar 2009 23:55:26 +0100 Message-ID: <3a142e750903251555q77f3cab2nf95628f3bfbec842@mail.gmail.com> From: "Paul B. Mahol" To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:56:00 -0000 On 3/25/09, Jung-uk Kim wrote: > On Wednesday 25 March 2009 05:22 pm, Paul B. Mahol wrote: >> On 3/11/09, Jung-uk Kim wrote: >> > With popular demands, I will commit the following patch in next >> > few days unless a showstopper is found or "over-my-dead-body" >> > type of review is received. ;-) >> > >> > http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >> > >> > FYI, it was originally posted here: >> > >> > http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >> > >> > and here: >> > >> > http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >> > >> > Please read the original threads for more information about the >> > patch. >> >> Looks some of your changes makes i386 without ACPI (acpi is >> disabled; not loaded and hint.acpi.0.disabled=1) fail to reboot. >> >> It this already known/documented behavior? > > Huh? No, it is totally unexpected because I didn't touch non-ACPI > path for i386. Can you back out r189903, r190339, r190340 and test > again? I dont think/believe it is actually your change after all. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 23:22:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DFCC106566C; Wed, 25 Mar 2009 23:22:19 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 381FB8FC2D; Wed, 25 Mar 2009 23:22:17 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so295238ewy.43 for ; Wed, 25 Mar 2009 16:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O5y1oswNm69gJhkVHOYJ1kOkzEV3tj641yWEypP+tSw=; b=QiSBnPseQzc/VMIHNRCHb3quhfCH5p2OMvglRoUjsPsuaqWKGbCdwCFJ6HdA8vNL8K R0LQOWYdDkey5y6M/RVtPolgAXopxWc//+Nr/ZQEfS5FwB7NZQJYITydSA5wEkoHOCsj tsyPLIfuSo6I9kJ2XcKMtrMm/nOBfhed3EU7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xc2QwlI6fThqSf+LkGSSnOXUqTklSYzlk96LS6Rovq1qnwD4ky52pe14+IDPIiOqWg yuPYZ6K1qR5Fi5z7zSq+xW4Fa5mXvMVP33QcXucn/tv0IN/QWoRSJgA0lSDMOF6pAhoL LGu61Tj3LzFnF5lOfQ0DUdnQQ3r333I9EZhV8= MIME-Version: 1.0 Received: by 10.210.65.17 with SMTP id n17mr96162eba.73.1238023335628; Wed, 25 Mar 2009 16:22:15 -0700 (PDT) In-Reply-To: <1238014404.1828.27.camel@balrog.2hip.net> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> <1238014404.1828.27.camel@balrog.2hip.net> Date: Wed, 25 Mar 2009 18:22:15 -0500 Message-ID: <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> From: Brandon Gooch To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:22:19 -0000 On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland wrote: > On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote: >> On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland wr= ote: >> > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: >> >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall wrote: >> >> > Brandon Gooch wrote: >> >> >> >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim wr= ote: >> >> >> >> >> >>> >> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> >> >>> >> >> >>>> >> >> >>>> The committed version is working well, I am suspending and resum= ing >> >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of th= e >> >> >>>> major things I needed to work so I could run FreeBSD primarily o= n >> >> >>>> my notebook. >> >> >>>> >> >> >> >> >> >> I just finished a kernel build and it seems as though your >> >> >> recent commits have fixed the clock (at least for me)! >> >> >> >> >> >> I feel sorry for all the i386 folks on ACPI notebooks... >> >> >> >> >> >> Thanks! >> >> >> >> >> >> -Brandon >> >> >> >> >> > >> >> > Picking a semi-random message here.. >> >> > >> >> > Thanks for your work on this! =A0In the past (months ago) I tried t= he patch >> >> > set which didn't work, but the code in -current lets me suspend and= resume >> >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! =A0I think = this is a >> >> > first for me, of all the laptops I've had, none have ever been able= to >> >> > suspend and resume in a successful or useful way, and I've been jea= lous of >> >> > the Thinkpad users that could claim otherwise. =A0I could suspend a= nd resume >> >> > fine while in the console, then I ran startx and the suspend and re= sume >> >> > worked while I was in X with intel graphics, however my system was = slow >> >> > after that resume. =A0I didn't spend much time looking at it since = I was at >> >> > work, and I didn't see any obvious reasons for the slowness (cpu fr= equency >> >> > was fine, cx states were C2 or lower (C1), top showed mostly idle, = no >> >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not th= e mouse >> >> > or typing though). =A0I didn't go back to console, I just shut down= without >> >> > trying any other situations yet. >> >> > >> >> > A tip I want to note for any users who may not have success with th= eir >> >> > screen on resume: =A0In the past it seemed to help me to have a pow= er-on >> >> > password set in my BIOS since the BIOS will turn on the screen on r= esume to >> >> > ask me for my password. =A0I don't know if it is still helping me, = but I've >> >> > seen in the past where it has. >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" >> >> > >> >> >> >> The sluggish response in X on Intel video has been an issue the past >> >> couple of days, triggered by suspend/resume or simply switching to VT= Y >> >> and back. >> > >> > I just committed code that should fix this... >> > >> > robert. >> > >> >> See this thread: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.= html >> >> >> >> Firefox is unusable, but xterms are still usable. I have to reboot to >> >> get back to "normal" >> >> >> >> -Brandon >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" >> > -- >> > Robert Noland >> > FreeBSD >> > >> >> It seems to have helped -- slightly. Firefox is still too laggy when >> interacting with interface elements (scrollbar, toolbars, menus), and >> typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to >> use, perhaps because they're not as graphically intensive :) >> >> Also, it seems to have broken the suspend/resume. The machine does >> wake up, but X is no longer there (I'm at the VTY from which I started >> X) and I can't switch to another VTY. The machine still "works" for a >> period, but attempts to switch VTY or enter commands from the keyboard >> eventually lock it up, resulting in a continuous beep tone and >> requiring a hard power-off (holding down the power button). > > Can you try the attached patch? =A0This was a last minute change that I > made and I don't know why it seems to be upsetting things so, but it > looks like it causes things to not shutdown properly. > > It looks like it isn't safe to suspend with / on usb2, so I can't really > test s/r still... > > robert. > >> -Brandon > -- > Robert Noland > FreeBSD > Applying the patch and rebuilding does get me back to successful suspend/resume cycle, but the sluggish application weirdness still persists. It's odd, but for brief moment (about a second) after resume, the screen comes back on as if it has been issued a "DPMS on" (as in say, vbetool or something), and then it flashes off again, only to come back on another second later. I assume this has something to do with resetting or restoring bits some place, but I wondered if this is an expected behavior. BTW, what utility would provide a decent test with quantifiable results. I feel there may be a better way to help us understand what is actually causing the symptoms and to pinpoint it in the source for you. Describing a GTK app as "laggy" or "sluggish" is hardly good enough :) Your thoughts and instruction are welcome! -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 23:44:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0971106566C for ; Wed, 25 Mar 2009 23:44:01 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 817908FC1D for ; Wed, 25 Mar 2009 23:44:01 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2PNi0V6048096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 16:44:00 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CAC1C0.9030506@freebsd.org> Date: Wed, 25 Mar 2009 16:44:00 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Daniel Thiele References: <49C83038.40300@gmx.net> In-Reply-To: <49C83038.40300@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:44:02 -0000 Daniel Thiele wrote: > Hi, > > I have a problem with my wireless connection. I am running FreeBSD > 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros > based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink > based USB adapter (Linksys WUSB54GC-EU via rum(4)). > > At home using the Atheros card together with a FreeBSD (7.1) based > access point (using rum(4) in hostap mode) and the wpa_supplicant.conf > (attached at the end of this email) settings for SSID="home" I don't > have any problems. With a Linksys WRT54GL-DE access point > running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open > wireless LAN also works flawlessly. > > At the university, however, (SSID="IDA" in the wpa_supplicant.conf at > the end of this email) the wireless connection only works for about an > hour. The vague term "wireless connection" in this case means, that the > WPA connection is opened and associated, then I get an IP address via > dhclient. There is a message about "OpenSSL: tls_connection_handshake - > Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 > EAP method 'MSCHAPv2'" but the authentication seems to succeed: <...stuff deleted...> > > > Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-MSCHAPV2: Authentication > succeeded > Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Mar 23 14:28:46 impala wpa_supplicant[429]: CTRL-EVENT-EAP-SUCCESS EAP > authentication completed successfully > Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Failed to set PTK to > the driver. > Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Key negotiation > completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] This doesn't look good. For some reason the PTK key was not plumbed; this means the ioctl that made the request failed. Unfortunately there's no more information to explain why but typically this is because the station is no longer associated. But for some reason wpa_supplicant didn't seem to handle the error properly; it appears it thinks the key exchange was completed when it was not. A glance at the code looks like it's ignoring errors; e.g. in contrib/wpa/src/rsn_supp/wpa.c in wpa_supplicant_process_3_of_4: if (key_info & WPA_KEY_INFO_INSTALL) { wpa_supplicant_install_ptk(sm, key); } (the error return by wpa_supplicant_install_ptk is not checked). This might be handled some other way but it's not clear why it should proceed. > Mar 23 14:29:01 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS > Mar 23 14:34:03 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS > Mar 23 14:39:05 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS > ----8<-------------------------------------------------------- > > ifconfig still lists the connection as "associated": > > ----8<-------------------------------------------------------- > impala# ifconfig wlan0 > wlan0: flags=8843 metric 0 mtu > 1500 > ether 00:21:91:db:15:30 > media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g > status: associated > ssid IDA channel 13 (2472 Mhz 11g) bssid 00:1b:2f:ef:d3:c9 > regdomain ETSI indoor ecm authmode WPA2/802.11i privacy ON > deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 450 > bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 > protmode CTS > wme burst roaming MANUAL > ----8<-------------------------------------------------------- > > But dhclient does not accept any new leases: > > ----8<-------------------------------------------------------- > impala# dhclient wlan0 > DHCPREQUEST on wlan0 to 255.255.255.255 port 67 > DHCPNAK from 192.168.100.1 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 > No DHCPOFFERS received. > Trying recorded lease 192.168.100.54 > bound: renewal in 5900 seconds. > ----8<-------------------------------------------------------- > > The site's wireless admin was so kind to provide me with the logs from > their DHCP server, which seems to offer new leases that somehow don't > make it through to my machine: > > ----8<-------------------------------------------------------- > DHCPDISCOVER from 00:21:91:db:15:30 (impala) via 192.168.100.1 > DHCPOFFER on 192.168.100.54 to 00:21:91:db:15:30 (impala) via > 192.168.100.1 > ----8<-------------------------------------------------------- > > If I audaciously assign myself an IP address (192.168.100.54) and set > the default route to 192.168.100.1, the wireless connection sill won't > work. I cannot even ping the router at 192.168.100.1. > > > Next, I tried to rule out the wireless adapter. Both the Atheros > ExpressCard and the Ralink USB Adapter show the above mentioned > behavior. So the problem might perhaps be located in FreeBSD's wireless > stack, wpa_supplicant or dhclient? But I'm not an expert in these areas, > thus this email. It appears this is an issue in wpa_supplicant but it's hard to say. I'd need to know if the association was broken during the time the key plumb failed. That should've been reported to wpa_supplicant which should've logged a msg so I'm guessing no. So we're back to why the key wasn't plumbed as everything that follows makes sense (i.e. you can't get data packets through). If you turn on crypto debugging in net80211 you might get some info from the console msgs; e.g. wlandebug crypto You should also configure wpa_supplicant debugging so we get more info from the driver; add wpa_supplicant_flags="-sd" to your rc.conf file (or start wpa_supplicant by hand). > > > What works in the case of the Ralink USB adapter is simply unplugging > and replugging the device. Then I get another hour of working wireless > before it breaks again. Since hot-plugging the ExpressCard currently > does not seem to work I cannot confirm this for the Atheros adapter. This sounds like the supplicant is out of sync w/ the ap and you can't get packets through because you've got the old/wrong key plumbed on the station. > > I also tried > > ----8<-------------------------------------------------------- > /etc/rc.d/netif restart > ----8<-------------------------------------------------------- > > and > > ----8<-------------------------------------------------------- > ifconfig wlan0 destroy > ifconfig wlan0 create wlandev rum0 > ----8<-------------------------------------------------------- > > followed by a restart of wpa_suppicant and dhclient, too, but without > any success. So only re-plugging the device seems to solve or at least > stall the problem. That doesn't make sense. Destroying the vap should be equivalent to ejecting the device. There should no crypto state kept after a vap is destroyed. You can verify this for the ath device using athregs (tools/tools/ath/athregs); athregs -k will dump the contents of the h/w key cache if the ath driver is built with ATH_DIAGAPI). > > The output of wpa_supplicant -ddd after the wireless connection stopped > working can be found at: > http://www-public.tu-bs.de:8080/~y0023183/FreeBSD/Wireless/wpa_supplicant-ddd.txt > > > > On a FreeBSD 7.1-STABLE machine with wpa_supplicant v0.5.10 and the > Ralink USB adapter I did not encounter the problem. If I understand correctly the above is for FreeBSD HEAD+0.6.8 so a more useful comparison is HEAD+0.5.11/0.5.10 which would tell us definitely if this is a supplicant issue. > > > Now, my question is has anyone else encountered this behavior (WPA-PSK > working nicely and WPA-EAP only for a limited period of time) and knows > how to fix this issue? Perhaps it is just a misconfiguration on my > part. If not, how can I help to further investigate this issue. What can > I do to provide additional debug information? > I checked the 0.6.9 release that I suggested might have a fix but was wrong. The change that caught my attention was for hostapd, not wpa_supplicant. So we're back to isolating whether this is a regression in the supplicant. The best suggestion I have is to back-rev your HEAD tree to just before I imported wpa_supplicant 0.6.8. Talk to me off-line if you need help w/ that. Sam > > Additioinal information: > > impala# uname -a > FreeBSD impala.vnws.lan 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sun Mar 22 > 00:34:38 CET 2009 > dthiele@impala.vnws.lan:/usr/obj/usr/src/sys/kernel_8Xv0 i386 > (Kernel and world are in sync) > > > impala# kldstat -v | grep wlan > 236 wlan > 235 wlan_wep > 234 wlan_tkip > 233 wlan_ccmp > 232 wlan_amrr > 237 wlan_sta > > > impala# wpa_supplicant -v > wpa_supplicant v0.6.8 > Copyright (c) 2003-2009, Jouni Malinen and contributors > > > impala# cat /etc/wpa_supplicant.conf > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > > ap_scan=1 > fast_reauth=1 > > # This is the working setup I am using at home. > # The AP is a ThinkPad R40 running FreeBSD-7.1-STABLE with a rum(4) > # wireless adapter in hostap mode. > network={ > ssid="SuperCollider" > scan_ssid=1 > mode=0 > proto=WPA > key_mgmt=WPA-PSK > psk="[REMOVED]" > pairwise=CCMP > priority=10 > } > > # This is the "partially-working" setup at the university > network={ > ssid="IDA" > mode=0 > proto=WPA2 > key_mgmt=WPA-EAP > eap=PEAP > identity="[REMOVED]" > anonymous_identity="[REMOVED]" > password="[REMOVED]" > ca_cert="[REMOVED]" > phase2="autH=msCHAPv2" > priority=2 > } > > > impala# cat /etc/dhclient.conf > timeout 60; > retry 60; > interface "wlan0" { > prepend domain-name-servers [REMOVED], 217.237.150.188; > request subnet-mask, broadcast-address, time-offset, routers, > domain-name; > } > > > impala# grep wlan /etc/rc.conf > wlans_ath0=wlan0 > ifconfig_wlan0="WPA DHCP" > From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 23:45:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354401065675 for ; Wed, 25 Mar 2009 23:45:19 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9558FC26 for ; Wed, 25 Mar 2009 23:45:18 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 12390 invoked from network); 25 Mar 2009 23:45:18 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Mar 2009 23:45:18 -0000 Message-ID: <49CAC20E.3020602@telenix.org> Date: Wed, 25 Mar 2009 19:45:18 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: Julian Elischer References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> In-Reply-To: <49CA6754.4030302@elischer.org> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ruben de Groot , Ian FREISLICH , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:45:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: > Ian FREISLICH wrote: >> Barney Cordoba wrote: >>>> Barney, you have to make the network pseudo ttys secure, >>>> like: >>>> >>>> ttyp0 none network secure >>>> >>>> Ruben >>> Yes, the "its not a good idea" is dependent on whatever other >>> security you have in place. Having to log in twice to a test >>> machine on a secure internal network is an unnecessary annoyance. >>> The concept that every FreeBSD box in existence is publically accessible >>> is one of those ASSumptions that people should leave at the door. >>> >>> Ruben, the method you cite no longer works in -current as they've >>> changed things once again (which happens way too often when your CEOs >>> are a bunch of bearded academics :) >>> >>> I'm not sure if its the pty (the login terminal shows as pty/0 and no >>> longer ttyp0), or if its some PAM thing. Its rather annoying. >>> Such things as >>> pty/0 none network secure >>> pty0 none network secure >>> >>> equally don't work. And I see no mention in any document as to how it >>> would be achieved with the current >> >> Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config > > this doesn't work if you are usinf a set of machines run from a central > machine using nc (netcat) to do scripted i/o through a telnet session on > the other machines (for example). > > The advantage of telnet is you can pipe nc straight into it. Julian, I don't know nc, but can't you stick keys in your ~/.ssh, then use ssh the same way? Doing without passwords, but keeping your security, inside nc? I think, at minimum, you could use ssh forwarding, but doesn't nc allow this directly? I just hate the idea of killing all the security, and hadn't yet seen any (even wildly unlikely) scenario that needs you to do that. I begin to suspect that there might be a whole lot of folks who aren't aware of how to use ssh to eliminate passwords. Security writeups are always too complicated, that's a truism. > >> >> Ian >> >> -- >> Ian Freislich >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKwg4ACgkQz62J6PPcoOnHGwCfSoXjcZutte69n/m7kVOFea2X 6xYAn0z14igUW4pebFj8oSfsOWrW4Jbq =NWWf -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 23:51:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F4100106564A for ; Wed, 25 Mar 2009 23:51:24 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id B0E408FC16 for ; Wed, 25 Mar 2009 23:51:24 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 72344 invoked by uid 60001); 25 Mar 2009 23:51:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238025084; bh=wzMkStxIxqwCqI0negekfLfbEbcgDSnli7P6tQnS9g4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZY0RW2f+LPBogGFGdD4mRfk6us8BpM34086EbJ0nHS5Ptn9P+rYJ/VOvEMRyPQbQs/z9Fu+nW4wiVdPHkdIovlFpNhIAE/fmEg2bjxaXcBF10+t/THkSzM50dCn1+2KZkQnAaamNWPPvJcAFQXPyUtxLWpXK7HOsNPnqv04gE6w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QvoIZZ8zurA8d3leFN+LuriK4jhGLTKKRKgwZAsokz2sXUG8pOHQj9VNk5yCQ5ePqy86xxmArNvsUIaI2Iu10/mkCO3GCDPdj5KpYrU0VPr287Clr/uw3d54NvxKV2hh4yNJleyCtTzDs6h7xMJ5TC6BCovWYUP0IY4fLiQdyFI=; Message-ID: <50958.12083.qm@web63908.mail.re1.yahoo.com> X-YMail-OSG: DTnAq2QVM1lUZhTzrp0ds01nOQcq7CGvF22lGlqVmQWpJ9rnkaoq6l_a4CJOmsn0A3GlUjoGMu_LfbdZoZaGAOkLv2t4W2WR7CokGY5wGZ0tj.CWleth6VW_ct4f3eEge_Egha8vSpdgGcRWiX3zl0B5Ckzlfk0lSwM3613k2H3Hby4FSLDyj_tyWI2jqtZMFpdijAQ5SMeMwR4YfwdQP3V4GnM346j0vv0n_ciABY8vsj38CvHcnvQJ9T80laecu2vTdiU- Received: from [98.242.222.229] by web63908.mail.re1.yahoo.com via HTTP; Wed, 25 Mar 2009 16:51:23 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 25 Mar 2009 16:51:23 -0700 (PDT) From: Barney Cordoba To: Julian Elischer , Chuck Robey In-Reply-To: <49CAC20E.3020602@telenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ruben de Groot , Ian FREISLICH , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:51:25 -0000 --- On Wed, 3/25/09, Chuck Robey wrote: > From: Chuck Robey > Subject: Re: Telnet root login > To: "Julian Elischer" > Cc: barney_cordoba@yahoo.com, "Ruben de Groot" , "Ian FREISLICH" , current@freebsd.org > Date: Wednesday, March 25, 2009, 7:45 PM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julian Elischer wrote: > > Ian FREISLICH wrote: > >> Barney Cordoba wrote: > >>>> Barney, you have to make the network > pseudo ttys secure, > >>>> like: > >>>> > >>>> ttyp0 none network secure > >>>> > >>>> Ruben > >>> Yes, the "its not a good idea" is > dependent on whatever other > >>> security you have in place. Having to log in > twice to a test > >>> machine on a secure internal network is an > unnecessary annoyance. > >>> The concept that every FreeBSD box in > existence is publically accessible > >>> is one of those ASSumptions that people should > leave at the door. > >>> > >>> Ruben, the method you cite no longer works in > -current as they've > >>> changed things once again (which happens way > too often when your CEOs > >>> are a bunch of bearded academics :) > >>> > >>> I'm not sure if its the pty (the login > terminal shows as pty/0 and no > >>> longer ttyp0), or if its some PAM thing. Its > rather annoying. > >>> Such things as > >>> pty/0 none network secure > >>> pty0 none network secure > >>> > >>> equally don't work. And I see no mention > in any document as to how it > >>> would be achieved with the current > >> > >> Then use ssh and set "PermitRootLogin > yes" in /etc/ssh/sshd_config > > > > this doesn't work if you are usinf a set of > machines run from a central > > machine using nc (netcat) to do scripted i/o through a > telnet session on > > the other machines (for example). > > > > The advantage of telnet is you can pipe nc straight > into it. > > Julian, I don't know nc, but can't you stick keys > in your ~/.ssh, then use ssh > the same way? Doing without passwords, but keeping your > security, inside nc? I > think, at minimum, you could use ssh forwarding, but > doesn't nc allow this > directly? I just hate the idea of killing all the > security, and hadn't yet seen > any (even wildly unlikely) scenario that needs you to do > that. > > I begin to suspect that there might be a whole lot of folks > who aren't aware of > how to use ssh to eliminate passwords. Security writeups > are always too > complicated, that's a truism. Another Truism: there are a whole lot of folks who are way too anally retentive for their own good. Barney From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 00:05:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54BD1065670 for ; Thu, 26 Mar 2009 00:05:46 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 362998FC08 for ; Thu, 26 Mar 2009 00:05:45 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 26 Mar 2009 00:05:44 -0000 Received: from p54865167.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.81.103] by mail.gmx.net (mp006) with SMTP; 26 Mar 2009 01:05:44 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX1/hVMFvl17h1BsNjhxfXelBXH4f6jo9S4MEfuvdBP 9mRpTsc7HRSimS Message-ID: <49CAC6FB.5060503@gmx.net> Date: Thu, 26 Mar 2009 01:06:19 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Jung-uk Kim References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> <200903251833.14825.jkim@FreeBSD.org> In-Reply-To: <200903251833.14825.jkim@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: Gustau Perez , freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:05:47 -0000 Jung-uk Kim wrote: > On Wednesday 25 March 2009 05:28 pm, Gustau Perez wrote: >>> Please try the attached patch, which just disables restoring VGA >>> state while resuming. >> Tried your patch again, and this time using hw.acpi.reset_video, >> hw.acpi.suspend_bounce and friends. The same result, the screen >> remains completely black. >> >> Before appliying the patch, when resuming the screen showed >> messages about the resume of some hardware (usb, firewire, etc ...) >> and then it went black. >> >> Is there anything I can test ? > > Then, it is something else, e.g., acpi_video(4). You can try setting > debug.acpi.disabled="video" in /boot/loader.conf for example. > I have the same problem here with a ThinkPad T400. This is a model with the Switchable Graphics feature, but I set the corresponding BIOS option to use the integrated Intel GMA X4500 only. Suspend and resume seem to work except for video output. I am using a vanilla CURRENT from March 25 (so I have not tried the vga_isa.diff patch yet). As in Gustau's case, after resume the screen stays just black. The system, though, seems to be up and running, since I get console's audible bell when I expect it and I can edit files, blindly of course. Setting debug.acpi.disabled="video" in /boot/loader.conf produces the same result: A black screen right after resume. I also tried setting hw.acpi.reset_video to 1 but the the machine does not resume at all. When I, in this case, additionally turn on debug.acpi.resume_beep all I get is a long beep that only stops, if I power-cycle the machine. Also, at first I tried to use an USB flash drive to test suspend/resume on amd64, which results in a panic on suspend. Unfortunately, I don't have any dumps, but the "tracing pid" output from "where" at the debugger prompt reported PID 12, wich seems to be [intr]. Or at leas it seem to be intr whenever I look up PID 12. Right now I am (ab)using my swap partition, which works fine. So, if there are any other knobs to fiddle with or patches to try out to investigate this further (at least the black screen issue) just let me know. Best regards, Daniel From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 00:14:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9121065750 for ; Thu, 26 Mar 2009 00:14:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF568FC15 for ; Thu, 26 Mar 2009 00:14:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7EDD952A63; Wed, 25 Mar 2009 17:15:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 5CC302D600D; Wed, 25 Mar 2009 17:14:38 -0700 (PDT) Message-ID: <49CAC8FE.5050708@elischer.org> Date: Wed, 25 Mar 2009 17:14:54 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Chuck Robey References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> In-Reply-To: <49CAC20E.3020602@telenix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ruben de Groot , Ian FREISLICH , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:14:42 -0000 Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julian Elischer wrote: >> Ian FREISLICH wrote: >>> Barney Cordoba wrote: >>>>> Barney, you have to make the network pseudo ttys secure, >>>>> like: >>>>> >>>>> ttyp0 none network secure >>>>> >>>>> Ruben >>>> Yes, the "its not a good idea" is dependent on whatever other >>>> security you have in place. Having to log in twice to a test >>>> machine on a secure internal network is an unnecessary annoyance. >>>> The concept that every FreeBSD box in existence is publically accessible >>>> is one of those ASSumptions that people should leave at the door. >>>> >>>> Ruben, the method you cite no longer works in -current as they've >>>> changed things once again (which happens way too often when your CEOs >>>> are a bunch of bearded academics :) >>>> >>>> I'm not sure if its the pty (the login terminal shows as pty/0 and no >>>> longer ttyp0), or if its some PAM thing. Its rather annoying. >>>> Such things as >>>> pty/0 none network secure >>>> pty0 none network secure >>>> >>>> equally don't work. And I see no mention in any document as to how it >>>> would be achieved with the current >>> Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config >> this doesn't work if you are usinf a set of machines run from a central >> machine using nc (netcat) to do scripted i/o through a telnet session on >> the other machines (for example). >> >> The advantage of telnet is you can pipe nc straight into it. > > Julian, I don't know nc, but can't you stick keys in your ~/.ssh, then use ssh > the same way? Doing without passwords, but keeping your security, inside nc? I > think, at minimum, you could use ssh forwarding, but doesn't nc allow this > directly? I just hate the idea of killing all the security, and hadn't yet seen > any (even wildly unlikely) scenario that needs you to do that. > > I begin to suspect that there might be a whole lot of folks who aren't aware of > how to use ssh to eliminate passwords. Security writeups are always too > complicated, that's a truism. Oh I know about SSH and keys but teh ability to pipe data into s tcp socket and have it fed into another process is really useful in testing. and of course no encryption overhead. > >>> Ian >>> >>> -- >>> Ian Freislich >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknKwg4ACgkQz62J6PPcoOnHGwCfSoXjcZutte69n/m7kVOFea2X > 6xYAn0z14igUW4pebFj8oSfsOWrW4Jbq > =NWWf > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 00:15:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA891065715; Thu, 26 Mar 2009 00:15:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9323C8FC24; Thu, 26 Mar 2009 00:15:37 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so65596eyf.7 for ; Wed, 25 Mar 2009 17:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rLm8R+YliBjTZMN64IL32sUpXZT0++oSBTnEyAZAbHc=; b=CniqIqy8luKepo01oZnbUPPe+bTgPtZeWHu+ee1p5hKRI5LFw0SOghnYFaiMN6MlMf mTrYp2SN1nqtPHd76BN3Clfubiy89qx1dWdpb40rU3ILzjT8Gr4oxA17przWEdTBqeBC ZJGjsgzG6XsKVPVwQ3CLeYRBQ06OOivkU11ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DsuQ4ajfDDUgsT6jNEeL88R5I5yO6jrCHd+iKVvyMmiXeUrUgsJaSUSyfYPPUBkNCw N8r4kYz9xloK8ZGb6RQmOq1x7G6qVMxBJ1miufd8H6u9end+RKOoakEt1PiK62G4kQFT DNM9trOucslkDueabRA/KOWppxXHCiSRnirHE= MIME-Version: 1.0 Received: by 10.210.54.15 with SMTP id c15mr133610eba.68.1238026536536; Wed, 25 Mar 2009 17:15:36 -0700 (PDT) In-Reply-To: <49CAC6FB.5060503@gmx.net> References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> <200903251833.14825.jkim@FreeBSD.org> <49CAC6FB.5060503@gmx.net> Date: Thu, 26 Mar 2009 01:15:36 +0100 Message-ID: <3a142e750903251715t4088654euf3b2adcd0587d2cd@mail.gmail.com> From: "Paul B. Mahol" To: Daniel Thiele Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gustau Perez , Jung-uk Kim , freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:15:39 -0000 On 3/26/09, Daniel Thiele wrote: > Jung-uk Kim wrote: >> On Wednesday 25 March 2009 05:28 pm, Gustau Perez wrote: >>>> Please try the attached patch, which just disables restoring VGA >>>> state while resuming. >>> Tried your patch again, and this time using hw.acpi.reset_video, >>> hw.acpi.suspend_bounce and friends. The same result, the screen >>> remains completely black. >>> >>> Before appliying the patch, when resuming the screen showed >>> messages about the resume of some hardware (usb, firewire, etc ...) >>> and then it went black. >>> >>> Is there anything I can test ? >> >> Then, it is something else, e.g., acpi_video(4). You can try setting >> debug.acpi.disabled="video" in /boot/loader.conf for example. >> > > I have the same problem here with a ThinkPad T400. This is a model with > the Switchable Graphics feature, but I set the corresponding BIOS option > to use the integrated Intel GMA X4500 only. Suspend and resume seem to > work except for video output. I am using a vanilla CURRENT from March 25 > (so I have not tried the vga_isa.diff patch yet). > > As in Gustau's case, after resume the screen stays just black. The > system, though, seems to be up and running, since I get console's > audible bell when I expect it and I can edit files, blindly of course. > Setting debug.acpi.disabled="video" in /boot/loader.conf produces the > same result: A black screen right after resume. > > I also tried setting hw.acpi.reset_video to 1 but the the machine does > not resume at all. When I, in this case, additionally turn on > debug.acpi.resume_beep all I get is a long beep that only stops, if I > power-cycle the machine. > > Also, at first I tried to use an USB flash drive to test suspend/resume > on amd64, which results in a panic on suspend. Unfortunately, I don't > have any dumps, but the "tracing pid" output from "where" at the > debugger prompt reported PID 12, wich seems to be [intr]. Or at leas it > seem to be intr whenever I look up PID 12. Right now I am (ab)using my > swap partition, which works fine. > > So, if there are any other knobs to fiddle with or patches to try out > to investigate this further (at least the black screen issue) just let > me know. The only way I managed (without suspending while inside X11) my HP nx7300 on UP i386 to resume with video working is kldloading vesa before suspend. -- Paul From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 00:33:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94315106564A for ; Thu, 26 Mar 2009 00:33:30 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by mx1.freebsd.org (Postfix) with ESMTP id 56A0C8FC1C for ; Thu, 26 Mar 2009 00:33:30 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.44] (mm.wbb.net.cable.rogers.com [74.210.92.229] (may be forged)) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n2Q0KTJQ011682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Mar 2009 17:20:30 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 25 Mar 2009 17:20:23 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@peregrin.local To: current@freebsd.org In-Reply-To: <49CAC8FE.5050708@elischer.org> Message-ID: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on orthanc.ca Cc: Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:33:31 -0000 > Oh I know about SSH and keys but teh ability to pipe data into s tcp socket > and have it fed into another process is really useful in testing. and of > course no encryption overhead. ssh cannot touch rsh for things like 'tar cf - . | rsh hostb tar xf -'. On a private network this is a perfectly reasonable thing to do. Less dogma and more engineering, please. --lyndon The two most common elements in the universe are Hydrogen and stupidity. -- Harlan Ellison From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 01:04:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 453C3106566B for ; Thu, 26 Mar 2009 01:04:05 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBBF8FC13 for ; Thu, 26 Mar 2009 01:04:04 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 14111 invoked by uid 1002); 26 Mar 2009 01:04:02 -0000 Received: from unknown (HELO ?10.10.10.7?) (saifi.khan@twincling.org@59.92.142.191) by s217.sureserver.com with ESMTPA; 26 Mar 2009 01:04:02 -0000 Date: Thu, 26 Mar 2009 06:37:40 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: FreeBSD 8.x 200902 snapshot Unable to find device node X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:04:05 -0000 On Thu, 26 Mar 2009, Saifi Khan wrote: > Hi: > > Trying to install FreeBSD 8.x 200902 snapshot from a DVD media > on a i386 box and i encounter this error dialog after selecting > distribution set. > > "Unable to find device node for /dev/ad4s2b in /dev! > The creation of filesystems will be aborted" > > Any suggestions on a possible workaround ? > The disk is 160GB SATA disk with two slices slice1 : 35G : OpenBSD (166) slice2 : 45G : FreeBSD (165) (Weird) the above mentioned error is only encountered if FreeBSD is the second slice. What could be the reason ? All pointers are welcome. thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 01:10:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1561065672 for ; Thu, 26 Mar 2009 01:10:36 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4A4638FC1B for ; Thu, 26 Mar 2009 01:10:34 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 26 Mar 2009 01:10:28 -0000 Received: from p54865167.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.81.103] by mail.gmx.net (mp043) with SMTP; 26 Mar 2009 02:10:28 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX1+MUK06s2iMSA8+Y8Bm88ZxIldne1zE4l705xpHlM 5/04BUIgMzmvBO Message-ID: <49CAD620.2030106@gmx.net> Date: Thu, 26 Mar 2009 02:10:56 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Sam Leffler References: <49C83038.40300@gmx.net> <49CAC1C0.9030506@freebsd.org> In-Reply-To: <49CAC1C0.9030506@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:10:36 -0000 Sam Leffler wrote: > Daniel Thiele wrote: >> Hi, >> >> I have a problem with my wireless connection. I am running FreeBSD >> 8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros >> based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink >> based USB adapter (Linksys WUSB54GC-EU via rum(4)). >> >> At home using the Atheros card together with a FreeBSD (7.1) based >> access point (using rum(4) in hostap mode) and the wpa_supplicant.conf >> (attached at the end of this email) settings for SSID="home" I don't >> have any problems. With a Linksys WRT54GL-DE access point >> running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open >> wireless LAN also works flawlessly. >> >> At the university, however, (SSID="IDA" in the wpa_supplicant.conf at >> the end of this email) the wireless connection only works for about an >> hour. The vague term "wireless connection" in this case means, that the >> WPA connection is opened and associated, then I get an IP address via >> dhclient. There is a message about "OpenSSL: tls_connection_handshake - >> Failed to read possible Application Data >> error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2 >> EAP method 'MSCHAPv2'" but the authentication seems to succeed: > > <...stuff deleted...> >> >> >> Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-MSCHAPV2: Authentication >> succeeded >> Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-TLV: TLV Result - >> Success - EAP-TLV/Phase2 Completed >> Mar 23 14:28:46 impala wpa_supplicant[429]: CTRL-EVENT-EAP-SUCCESS EAP >> authentication completed successfully >> Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Failed to set PTK to >> the driver. >> Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Key negotiation >> completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] > > This doesn't look good. For some reason the PTK key was not plumbed; > this means the ioctl that made the request failed. Unfortunately > there's no more information to explain why but typically this is because > the station is no longer associated. But for some reason wpa_supplicant > didn't seem to handle the error properly; it appears it thinks the key > exchange was completed when it was not. A glance at the code looks like > it's ignoring errors; e.g. in contrib/wpa/src/rsn_supp/wpa.c in > wpa_supplicant_process_3_of_4: > > if (key_info & WPA_KEY_INFO_INSTALL) { > wpa_supplicant_install_ptk(sm, key); > } > > (the error return by wpa_supplicant_install_ptk is not checked). This > might be handled some other way but it's not clear why it should proceed. > > >> Mar 23 14:29:01 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS >> Mar 23 14:34:03 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS >> Mar 23 14:39:05 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS >> ----8<-------------------------------------------------------- >> >> ifconfig still lists the connection as "associated": >> >> ----8<-------------------------------------------------------- >> impala# ifconfig wlan0 >> wlan0: flags=8843 metric 0 mtu >> 1500 >> ether 00:21:91:db:15:30 >> media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g >> status: associated >> ssid IDA channel 13 (2472 Mhz 11g) bssid 00:1b:2f:ef:d3:c9 >> regdomain ETSI indoor ecm authmode WPA2/802.11i privacy ON >> deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 450 >> bgscan >> bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 >> protmode CTS >> wme burst roaming MANUAL >> ----8<-------------------------------------------------------- >> >> But dhclient does not accept any new leases: >> >> ----8<-------------------------------------------------------- >> impala# dhclient wlan0 >> DHCPREQUEST on wlan0 to 255.255.255.255 port 67 >> DHCPNAK from 192.168.100.1 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 >> No DHCPOFFERS received. >> Trying recorded lease 192.168.100.54 >> bound: renewal in 5900 seconds. >> ----8<-------------------------------------------------------- >> >> The site's wireless admin was so kind to provide me with the logs from >> their DHCP server, which seems to offer new leases that somehow don't >> make it through to my machine: >> >> ----8<-------------------------------------------------------- >> DHCPDISCOVER from 00:21:91:db:15:30 (impala) via 192.168.100.1 >> DHCPOFFER on 192.168.100.54 to 00:21:91:db:15:30 (impala) via >> 192.168.100.1 >> ----8<-------------------------------------------------------- >> >> If I audaciously assign myself an IP address (192.168.100.54) and set >> the default route to 192.168.100.1, the wireless connection sill won't >> work. I cannot even ping the router at 192.168.100.1. >> >> >> Next, I tried to rule out the wireless adapter. Both the Atheros >> ExpressCard and the Ralink USB Adapter show the above mentioned >> behavior. So the problem might perhaps be located in FreeBSD's wireless >> stack, wpa_supplicant or dhclient? But I'm not an expert in these areas, >> thus this email. > > It appears this is an issue in wpa_supplicant but it's hard to say. I'd > need to know if the association was broken during the time the key plumb > failed. That should've been reported to wpa_supplicant which should've > logged a msg so I'm guessing no. So we're back to why the key wasn't > plumbed as everything that follows makes sense (i.e. you can't get data > packets through). If you turn on crypto debugging in net80211 you might > get some info from the console msgs; e.g. > > wlandebug crypto > > You should also configure wpa_supplicant debugging so we get more info > from the driver; add > > wpa_supplicant_flags="-sd" > > to your rc.conf file (or start wpa_supplicant by hand). > Thanks, I will try that. >> >> >> What works in the case of the Ralink USB adapter is simply unplugging >> and replugging the device. Then I get another hour of working wireless >> before it breaks again. Since hot-plugging the ExpressCard currently >> does not seem to work I cannot confirm this for the Atheros adapter. > > This sounds like the supplicant is out of sync w/ the ap and you can't > get packets through because you've got the old/wrong key plumbed on the > station. > >> >> I also tried >> >> ----8<-------------------------------------------------------- >> /etc/rc.d/netif restart >> ----8<-------------------------------------------------------- >> >> and >> >> ----8<-------------------------------------------------------- >> ifconfig wlan0 destroy >> ifconfig wlan0 create wlandev rum0 >> ----8<-------------------------------------------------------- >> >> followed by a restart of wpa_suppicant and dhclient, too, but without >> any success. So only re-plugging the device seems to solve or at least >> stall the problem. > > That doesn't make sense. Destroying the vap should be equivalent to > ejecting the device. There should no crypto state kept after a vap is > destroyed. You can verify this for the ath device using athregs > (tools/tools/ath/athregs); athregs -k will dump the contents of the h/w > key cache if the ath driver is built with ATH_DIAGAPI). This is enabled by adding "options ATH_DIAGAPI" to my kernel configuration file, right? > >> >> The output of wpa_supplicant -ddd after the wireless connection stopped >> working can be found at: >> http://www-public.tu-bs.de:8080/~y0023183/FreeBSD/Wireless/wpa_supplicant-ddd.txt >> >> >> >> On a FreeBSD 7.1-STABLE machine with wpa_supplicant v0.5.10 and the >> Ralink USB adapter I did not encounter the problem. > > If I understand correctly the above is for FreeBSD HEAD+0.6.8 so a more > useful comparison is HEAD+0.5.11/0.5.10 which would tell us definitely > if this is a supplicant issue. > Yes, the machine with the borken wireless is a HEAD+0.6.8. I have not tried HEAD+0.5.11, yet. But I will do that on Friday. >> >> >> Now, my question is has anyone else encountered this behavior (WPA-PSK >> working nicely and WPA-EAP only for a limited period of time) and knows >> how to fix this issue? Perhaps it is just a misconfiguration on my >> part. If not, how can I help to further investigate this issue. What can >> I do to provide additional debug information? >> > > I checked the 0.6.9 release that I suggested might have a fix but was > wrong. The change that caught my attention was for hostapd, not > wpa_supplicant. So we're back to isolating whether this is a regression > in the supplicant. The best suggestion I have is to back-rev your HEAD > tree to just before I imported wpa_supplicant 0.6.8. Talk to me > off-line if you need help w/ that. > I already prepared a USB flash drive with a CURRENT from March 3 20:00h. At least i hope that this is what *default release=cvs tag=. date=2009.03.01.20.00.00 in my supfile gave me. A first boot confirmed that I got wpa_supplicant 0.5.11, so I think it worked. BTW. is there a way for normal users to easily check-out a specific SVN revision? The procedure described in the FreeBSD wiki http://wiki.freebsd.org/SubversionPrimer seems to require a valid FreeBSD login name. And I can understand that to efficiently use resources and bandwidth CVSup is used to serve normal users. Maybe I'm just missing something, but it is a little cumbersome to manually look up the SVN revisions at svn-src-head@ to get the corresponding date for the supfile. Anyway, on Friday I will turn on debug output on my HEAD+0.6.8 (or 0.6.9 as of yesterday) machine and also investigate the issue with the prepared USB flash drive and a back-rev'ed HEAD+0.5.11. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 01:19:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BD2F1065670 for ; Thu, 26 Mar 2009 01:19:36 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0F58F8FC18 for ; Thu, 26 Mar 2009 01:19:35 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 26 Mar 2009 01:19:34 -0000 Received: from p54865167.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.81.103] by mail.gmx.net (mp069) with SMTP; 26 Mar 2009 02:19:34 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX1+4hNhJveK4VCpc4KuJPb+OfCubGVton7NpcqWdEU 59dNvSu2+/cOtE Message-ID: <49CAD846.9090703@gmx.net> Date: Thu, 26 Mar 2009 02:20:06 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: "Paul B. Mahol" References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> <200903251833.14825.jkim@FreeBSD.org> <49CAC6FB.5060503@gmx.net> <3a142e750903251715t4088654euf3b2adcd0587d2cd@mail.gmail.com> In-Reply-To: <3a142e750903251715t4088654euf3b2adcd0587d2cd@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: Gustau Perez , Jung-uk Kim , freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:19:36 -0000 Paul B. Mahol wrote: > On 3/26/09, Daniel Thiele wrote: >> Jung-uk Kim wrote: >>> On Wednesday 25 March 2009 05:28 pm, Gustau Perez wrote: >>>>> Please try the attached patch, which just disables restoring VGA >>>>> state while resuming. >>>> Tried your patch again, and this time using hw.acpi.reset_video, >>>> hw.acpi.suspend_bounce and friends. The same result, the screen >>>> remains completely black. >>>> >>>> Before appliying the patch, when resuming the screen showed >>>> messages about the resume of some hardware (usb, firewire, etc ...) >>>> and then it went black. >>>> >>>> Is there anything I can test ? >>> Then, it is something else, e.g., acpi_video(4). You can try setting >>> debug.acpi.disabled="video" in /boot/loader.conf for example. >>> >> I have the same problem here with a ThinkPad T400. This is a model with >> the Switchable Graphics feature, but I set the corresponding BIOS option >> to use the integrated Intel GMA X4500 only. Suspend and resume seem to >> work except for video output. I am using a vanilla CURRENT from March 25 >> (so I have not tried the vga_isa.diff patch yet). >> >> As in Gustau's case, after resume the screen stays just black. The >> system, though, seems to be up and running, since I get console's >> audible bell when I expect it and I can edit files, blindly of course. >> Setting debug.acpi.disabled="video" in /boot/loader.conf produces the >> same result: A black screen right after resume. >> >> I also tried setting hw.acpi.reset_video to 1 but the the machine does >> not resume at all. When I, in this case, additionally turn on >> debug.acpi.resume_beep all I get is a long beep that only stops, if I >> power-cycle the machine. >> >> Also, at first I tried to use an USB flash drive to test suspend/resume >> on amd64, which results in a panic on suspend. Unfortunately, I don't >> have any dumps, but the "tracing pid" output from "where" at the >> debugger prompt reported PID 12, wich seems to be [intr]. Or at leas it >> seem to be intr whenever I look up PID 12. Right now I am (ab)using my >> swap partition, which works fine. >> >> So, if there are any other knobs to fiddle with or patches to try out >> to investigate this further (at least the black screen issue) just let >> me know. > > The only way I managed (without suspending while inside X11) my HP > nx7300 on UP i386 to > resume with video working is kldloading vesa before suspend. > Cool, thanks a lot for that hint! That helped. I did not find the vesa module in the amd64's /boot/kernel directory nor the man-page, but loading the i915 module seems to do the trick. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 00:54:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 417011065670; Thu, 26 Mar 2009 00:54:13 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 30D658FC1F; Thu, 26 Mar 2009 00:54:11 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 8F7B92E00E; Thu, 26 Mar 2009 08:53:01 +0800 (CST) Message-ID: <49CAD237.9020301@gddsn.org.cn> Date: Thu, 26 Mar 2009 08:54:15 +0800 From: wsk User-Agent: Thunderbird 2.0.0.19 (X11/20090204) MIME-Version: 1.0 To: Robert Noland References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn> <49C6E5C6.60306@gddsn.org.cn> <1237798914.2110.24.camel@balrog.2hip.net> <49C85F4E.5050002@gddsn.org.cn> <1237882591.1771.26.camel@balrog.2hip.net> <49C97EEB.4090607@gddsn.org.cn> <1237961497.1828.2.camel@balrog.2hip.net> <49C9ED34.20504@gddsn.org.cn> <1237998972.1828.4.camel@balrog.2hip.net> <1238001777.1828.17.camel@balrog.2hip.net> In-Reply-To: <1238001777.1828.17.camel@balrog.2hip.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Mar 2009 01:21:19 +0000 Cc: stable@freebsd.org, x11@freebsd.org, current@freebsd.org Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:54:14 -0000 Robert Noland wrote: > On Wed, 2009-03-25 at 11:36 -0500, Robert Noland wrote: > >> On Wed, 2009-03-25 at 16:37 +0800, wsk wrote: >> >>> Robert Noland wrote: >>> >>>> On Wed, 2009-03-25 at 08:46 +0800, wsk wrote: >>>> >>>> >>>>> Robert Noland wrote: >>>>> >>>>> >>>>>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Robert Noland wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> Ok, this patch should work on NV50 chips also. >>>>>>>>>> >>>>>>>>>> What you get is EXA and Xv. >>>>>>>>>> >>>>>>>>>> You still need: >>>>>>>>>> >>>>>>>>>> A recent -CURRENT or -STABLE. >>>>>>>>>> >>>>>>>>>> git master of libdrm and xf86-video-nouveau. >>>>>>>>>> >>>>>>>>>> This patch. >>>>>>>>>> >>>>>>>>>> Things I've figured out since the last patch... >>>>>>>>>> >>>>>>>>>> On NV50 class hardware you need to have a compositing manager running >>>>>>>>>> for Xv to work. That means xcompmgr, metacity with composite enabled, >>>>>>>>>> xfce (rumored to work as well, haven't tried). If your running Gnome >>>>>>>>>> with metacity, open gconf-editor and go to apps->metacity->general and >>>>>>>>>> check the composite box. >>>>>>>>>> >>>>>>>>>> On NV40 class hardware, you don't need the composite manager. In fact >>>>>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite >>>>>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some >>>>>>>>>> circumstances. I don't think this is a drm issue, but still an issue. >>>>>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as >>>>>>>>>> long as that xterm is the foreground window. If it is not the >>>>>>>>>> foreground window, even if it isn't obscured I see the cpu utilization. >>>>>>>>>> Disabling the composite manager makes everything fine. >>>>>>>>>> >>>>>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch >>>>>>>>>> >>>>>>>>>> robert. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation. >>>>>>>>> It is not supported in any way. >>>>>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>>>>>>> Select the "xorg" product for bugs you find in this release. >>>>>>>>> Before reporting bugs in pre-release versions please check the >>>>>>>>> latest version in the X.Org Foundation git repository. >>>>>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>>>>>>> >>>>>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>>>>>>> Release Date: 2009-1-30 >>>>>>>>> X Protocol Version 11, Revision 0 >>>>>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>>>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE >>>>>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/sr >>>>>>>>> c/sys/WSK amd64 >>>>>>>>> Build Date: 06 February 2009 04:22:44PM >>>>>>>>> >>>>>>>>> Before reporting problems, check http://wiki.x.org >>>>>>>>> to make sure that you have the latest version. >>>>>>>>> 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 Mar 23 09:14:03 2009 >>>>>>>>> ing config file: "xorg.conf1" >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>>>> drm0: [ITHREAD] >>>>>>>>> info: [drm] Allocating FIFO number 1 >>>>>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >>>>>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >>>>>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>>>>>>> (EE) Screen(s) found, but none have a usable configuration. >>>>>>>>> >>>>>>>>> Fatal server error: >>>>>>>>> no screens found >>>>>>>>> >>>>>>>>> Please consult the The X.Org Foundation support >>>>>>>>> at http://wiki.x.org >>>>>>>>> for help. >>>>>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati >>>>>>>>> on. >>>>>>>>> >>>>>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1 >>>>>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before >>>>>>>>> destroy.Prepare for strangeness.. >>>>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>>>> >>>>>>>>> what can i do ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> plain text document attachment (Xorg.0.log) >>>>>>>>> This is a pre-release version of the X server from The X.Org Foundation. >>>>>>>>> It is not supported in any way. >>>>>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. >>>>>>>>> Select the "xorg" product for bugs you find in this release. >>>>>>>>> Before reporting bugs in pre-release versions please check the >>>>>>>>> latest version in the X.Org Foundation git repository. >>>>>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions. >>>>>>>>> >>>>>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2) >>>>>>>>> Release Date: 2009-1-30 >>>>>>>>> X Protocol Version 11, Revision 0 >>>>>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 >>>>>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64 >>>>>>>>> Build Date: 06 February 2009 04:22:44PM >>>>>>>>> >>>>>>>>> Before reporting problems, check http://wiki.x.org >>>>>>>>> to make sure that you have the latest version. >>>>>>>>> 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 Mar 23 09:14:03 2009 >>>>>>>>> (++) Using config file: "xorg.conf1" >>>>>>>>> (==) No Layout section. Using the first Screen section. >>>>>>>>> (==) No screen section available. Using defaults. >>>>>>>>> (**) |-->Screen "Default Screen Section" (0) >>>>>>>>> (**) | |-->Monitor "" >>>>>>>>> (==) No device specified for screen "Default Screen Section". >>>>>>>>> Using the first device section listed. >>>>>>>>> (**) | |-->Device "Card0" >>>>>>>>> (==) No monitor specified for screen "Default Screen Section". >>>>>>>>> Using a default monitor configuration. >>>>>>>>> (==) Automatically adding devices >>>>>>>>> (==) Automatically enabling devices >>>>>>>>> (==) No FontPath specified. Using compiled-in default. >>>>>>>>> (==) FontPath set to: >>>>>>>>> built-ins >>>>>>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules" >>>>>>>>> (II) Cannot locate a core pointer device. >>>>>>>>> (II) Cannot locate a core keyboard device. >>>>>>>>> (II) The server relies on HAL to provide the list of input devices. >>>>>>>>> If no devices become available, reconfigure HAL or disable AllowEmptyInput. >>>>>>>>> (II) Loader magic: 0xb20 >>>>>>>>> (II) Module ABI versions: >>>>>>>>> X.Org ANSI C Emulation: 0.4 >>>>>>>>> X.Org Video Driver: 5.0 >>>>>>>>> X.Org XInput driver : 4.0 >>>>>>>>> X.Org Server Extension : 2.0 >>>>>>>>> (II) Loader running on freebsd >>>>>>>>> (--) Using syscons driver with X support (version 2.0) >>>>>>>>> (--) using VT number 9 >>>>>>>>> >>>>>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Ok, thats a new one... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> (II) System resource ranges: >>>>>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>>>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>>>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>>>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>>>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>>>>>>> (II) LoadModule: "extmod" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so >>>>>>>>> (II) Module extmod: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>>>>> Module class: X.Org Server Extension >>>>>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>>>>> (II) Loading extension MIT-SCREEN-SAVER >>>>>>>>> (II) Loading extension XFree86-VidModeExtension >>>>>>>>> (II) Loading extension XFree86-DGA >>>>>>>>> (II) Loading extension DPMS >>>>>>>>> (II) Loading extension XVideo >>>>>>>>> (II) Loading extension XVideo-MotionCompensation >>>>>>>>> (II) Loading extension X-Resource >>>>>>>>> (II) LoadModule: "dbe" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so >>>>>>>>> (II) Module dbe: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>>>>> Module class: X.Org Server Extension >>>>>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>>>>> (II) Loading extension DOUBLE-BUFFER >>>>>>>>> (II) LoadModule: "glx" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so >>>>>>>>> (II) Module glx: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>>>>> (==) AIGLX disabled >>>>>>>>> (==) Exporting typical set of GLX visuals >>>>>>>>> (II) Loading extension GLX >>>>>>>>> (II) LoadModule: "record" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so >>>>>>>>> (II) Module record: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 1.13.0 >>>>>>>>> Module class: X.Org Server Extension >>>>>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>>>>> (II) Loading extension RECORD >>>>>>>>> (II) LoadModule: "dri" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so >>>>>>>>> (II) Module dri: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 1.0.0 >>>>>>>>> ABI class: X.Org Server Extension, version 2.0 >>>>>>>>> (II) Loading extension XFree86-DRI >>>>>>>>> (II) LoadModule: "nouveau" >>>>>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so >>>>>>>>> (II) Module nouveau: vendor="X.Org Foundation" >>>>>>>>> compiled for 1.5.99.902, module version = 0.0.10 >>>>>>>>> Module class: X.Org Video Driver >>>>>>>>> ABI class: X.Org Video Driver, version 5.0 >>>>>>>>> (II) NOUVEAU driver Date: Wed Mar 18 09:36:33 2009 +1000 >>>>>>>>> (II) NOUVEAU driver for NVIDIA chipset families : >>>>>>>>> RIVA TNT (NV04) >>>>>>>>> RIVA TNT2 (NV05) >>>>>>>>> GeForce 256 (NV10) >>>>>>>>> GeForce 2 (NV11, NV15) >>>>>>>>> GeForce 4MX (NV17, NV18) >>>>>>>>> GeForce 3 (NV20) >>>>>>>>> GeForce 4Ti (NV25, NV28) >>>>>>>>> GeForce FX (NV3x) >>>>>>>>> GeForce 6 (NV4x) >>>>>>>>> GeForce 7 (G7x) >>>>>>>>> GeForce 8 (G8x) >>>>>>>>> (II) Primary Device is: PCI 01@00:00:0 >>>>>>>>> (II) resource ranges after probing: >>>>>>>>> [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] >>>>>>>>> [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] >>>>>>>>> [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] >>>>>>>>> [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] >>>>>>>>> [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] >>>>>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hrm, NV86... I'll have to ask around about that. Meanwhile can you send >>>>>>>> me a pciconf -lvb which should at least show us the BAR configuration. >>>>>>>> >>>>>>>> Ok, my sources are telling me that this should work and that it is an >>>>>>>> NV50, or at least should work the same... >>>>>>>> >>>>>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess. I'm >>>>>>>> not sure if it may be trashing the BARs somehow. >>>>>>>> >>>>>>>> robert. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled >>>>>>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086 >>>>>>> rev=0x02 hdr=0x00 >>>>>>> vendor = 'Intel Corporation' >>>>>>> device = '82801H (ICH8 Family) SMBus Controller' >>>>>>> class = serial bus >>>>>>> subclass = SMBus >>>>>>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled >>>>>>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled >>>>>>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de >>>>>>> rev=0xa1 hdr=0x00 >>>>>>> vendor = 'Nvidia Corp' >>>>>>> device = 'Unknown nVidia Quadro FX 570M' >>>>>>> class = display >>>>>>> subclass = VGA >>>>>>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled >>>>>>> >>>>>>> >>>>>>> >>>>>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up. BAR 1 >>>>>> should be your framebuffer and should be where most of your memory is. >>>>>> (This is the memory the tell you about when you buy the card, 256M, >>>>>> 512M, etc.) It should probably be a 64bit BAR, which is why BAR 2 isn't >>>>>> there. We are going to need more details on your card... >>>>>> >>>>>> >>>>>> >>>>> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory. >>>>> but it recognized Quadro FX 570M with pciconfig. >>>>> >>>>> >>>> So, the nouveau folks want me to get you to either boot linux and see >>>> what lspci shows for this card, or at least install the lspci port and >>>> see what it says. I don't think it is going to reveal anything, but who >>>> knows... This is not a driver issue at this point, the BARs just don't >>>> appear to be present. >>>> >>>> robert. >>>> >>>> >>>> >>> ok,here's my lspci -v messags with linux Fedora live CD :-) >>> and thanks your Re >>> >>> >>> 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M >>> (rev a1) (prog-if 00 [VGA controller]) >>> Subsystem: Dell Device 01fe >>> Flags: bus master, fast devsel, latency 0, IRQ 5 >>> Memory at fd000000 (32-bit, non-prefetchable) [size=16M] >>> Memory at e0000000 (64-bit, prefetchable) [size=256M] >>> Memory at fa000000 (64-bit, non-prefetchable) [size=32M] >>> I/O ports at df00 [size=128] >>> [virtual] Expansion ROM at fc000000 [disabled] [size=128K] >>> Capabilities: [60] Power Management version 2 >>> Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 >>> Enable- >>> Capabilities: [78] Express Endpoint, MSI 00 >>> Capabilities: [100] Virtual Channel >>> Capabilities: [128] Power Budgeting >>> Capabilities: [600] Vendor Specific Information >>> Kernel modules: nvidiafb >>> >> Ok, we need a little help on this one then... I don't know why we >> wouldn't see BAR 1. Time to rope jhb@ in. >> > > Can you send a verbose boot log. > > robert. > > your meant is on BSD or on Linux ? i guess on BSD so Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009 wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80e5f000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80e5f210. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80e5f878. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff80e5fe68. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff80e60450. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80e60ab8. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80e60b18. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80e61040. Preloaded elf obj module "/boot/kernel/atapicam.ko" at 0xffffffff80e614a8. Preloaded elf obj module "/boot/kernel/ng_ubt.ko" at 0xffffffff80e61a98. Preloaded elf obj module "/boot/kernel/netgraph.ko" at 0xffffffff80e62000. Calibrating clock(s) ... i8254 clock: 1193158 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394013896 Hz CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fa Stepping = 10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4278595584 (4080 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000e90000 - 0x00000000d76e2fff, 3599052800 bytes (878675 pages) 0x0000000100002000 - 0x000000011ffeffff, 536797184 bytes (131054 pages) avail memory = 4113477632 (3922 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP @ 0x0xfbb00/0x0024 (v 2 DELL ) ACPI: XSDT @ 0x0xdfe5d200/0x0064 (v 1 DELL M08 0x27D8021C ASL 0x00000061) ACPI: FACP @ 0x0xdfe5d09c/0x00F4 (v 4 DELL M08 0x27D8021C ASL 0x00000061) ACPI: DSDT @ 0x0xdfe5d800/0x63F7 (v 2 INT430 SYSFexxx 0x00001001 INTL 0x20050624) ACPI: FACS @ 0x0xdfe6c000/0x0040 ACPI: HPET @ 0x0xdfe5d300/0x0038 (v 1 DELL M08 0x00000001 ASL 0x00000061) ACPI: APIC @ 0x0xdfe5d400/0x0068 (v 1 DELL M08 0x27D8021C ASL 0x00000047) ACPI: ASF! @ 0x0xdfe5d000/0x007E (v 32 DELL M08 0x27D8021C ASL 0x00000061) ACPI: MCFG @ 0x0xdfe5d3c0/0x003E (v 16 DELL M08 0x27D8021C ASL 0x00000061) ACPI: SLIC @ 0x0xdfe5d49c/0x0176 (v 1 DELL M08 0x27D8021C ASL 0x00000061) ACPI: TCPA @ 0x0xdfe5d700/0x0032 (v 1 0x00000000 ASL 0x00000000) ACPI: SSDT @ 0x0xdfe5b97e/0x04CC (v 1 PmRef CpuPm 0x00003000 INTL 0x20050624) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> wlan_amrr: snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 io: mem: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Mar 22 2009 19:44:13) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.VID_.IGDP -> bus 0 dev 2 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.MCHP -> bus 0 dev 0 func 0 ACPI: SSDT @ 0x0xdfe6c080/0x0043 (v 1 LMPWR DELLLOM 0x00001001 INTL 0x20050624) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.PIR1 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.PIR2 -> bus 0 dev 31 func 0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, dfd5b800 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 9 10 11 Validation 0 255 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 Validation 0 255 N 0 5 7 After Disable 0 255 N 0 5 7 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 9 10 11 Validation 0 255 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 5 7 9 10 11 Validation 0 255 N 0 5 7 9 10 11 After Disable 0 255 N 0 5 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x0c domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a01, revid=0x0c domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2834, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x6f20, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2835, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x6f00, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c400, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x284b, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfebfc000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283f, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2841, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2845, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2849, revid=0x02 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2830, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x6f80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2831, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x6f60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2832, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type I/O Port, range 32, base 0x6f40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2836, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2448, revid=0xf2 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2850, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x6fa0, size 4, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2828, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x6eb0, size 3, enabled map[14]: type I/O Port, range 32, base 0x6eb8, size 2, enabled map[18]: type I/O Port, range 32, base 0x6ec0, size 3, enabled map[1c]: type I/O Port, range 32, base 0x6ec8, size 2, enabled map[20]: type I/O Port, range 32, base 0x6ee0, size 4, enabled map[24]: type I/O Port, range 32, base 0xeff0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x283e, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type Memory, range 32, base 0xfebfbf00, size 8, enabled map[20]: type I/O Port, range 32, base 0x10c0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfa000000-0xfeafffff pcib1: prefetched decode 0xe0000000-0xefffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0429, revid=0xa1 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib1: requested memory range 0xe0000000-0xefffffff: good map[1c]: type Memory, range 64, base 0xfa000000, size 25, enabled pcib1: requested memory range 0xfa000000-0xfbffffff: good map[24]: type I/O Port, range 32, base 0xdf00, size 7, enabled pcib1: requested I/O range 0xdf00-0xdf7f: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0xdf00-0xdf7f mem 0xfd000000-0xfdffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci1 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f20 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f00 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfed1c400 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 51 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered hdac0: mem 0xfebfc000-0xfebfffff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090316_0130 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfebfc000 hdac0: [MPSAFE] hdac0: [ITHREAD] pcib2: at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 11 pcib2: subordinate bus 11 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci11: on pcib2 pci11: domain=0, physical bus=11 pcib3: at device 28.1 on pci0 pcib3: domain 0 pcib3: secondary bus 12 pcib3: subordinate bus 12 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xf9f00000-0xf9ffffff pcib3: prefetched decode 0xf0000000-0xf00fffff pci12: on pcib3 pci12: domain=0, physical bus=12 found-> vendor=0x14e4, dev=0x4328, revid=0x03 domain=0, bus=12, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf9ffc000, size 14, enabled pcib3: requested memory range 0xf9ffc000-0xf9ffffff: good map[18]: type Prefetchable Memory, range 64, base 0xf0000000, size 20, enabled pcib3: requested memory range 0xf0000000-0xf00fffff: good pcib3: matched entry for 12.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 pci12: at device 0.0 (no driver attached) pcib4: at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 14 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xf9c00000-0xf9efffff pcib4: prefetched decode 0xf0100000-0xf03fffff pci13: on pcib4 pci13: domain=0, physical bus=13 pcib5: at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 9 pcib5: subordinate bus 9 pcib5: I/O decode 0xf000-0xfff pcib5: memory decode 0xf9b00000-0xf9bfffff pcib5: no prefetched decode pci9: on pcib5 pci9: domain=0, physical bus=9 found-> vendor=0x14e4, dev=0x1673, revid=0x02 domain=0, bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf9bf0000, size 16, enabled pcib5: requested memory range 0xf9bf0000-0xf9bfffff: good pcib5: matched entry for 9.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 bge0: mem 0xf9bf0000-0xf9bfffff irq 17 at device 0.0 on pci9 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf9bf0000 bge0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 52 bge0: using IRQ 256 for MSI bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x0050ef, model 0x000c, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:1c:23:97:bd:de bge0: [MPSAFE] bge0: [ITHREAD] uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f80 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f60 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f40 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfed1c000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 3 pcib6: subordinate bus 4 pcib6: I/O decode 0xf000-0xfff pcib6: memory decode 0xf9a00000-0xf9afffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci3: on pcib6 pci3: domain=0, physical bus=3 found-> vendor=0x1217, dev=0x7135, revid=0x21 domain=0, bus=3, slot=1, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=0x1217, dev=0x00f7, revid=0x02 domain=0, bus=3, slot=1, func=4 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf9aff000, size 12, enabled pcib6: requested memory range 0xf9aff000-0xf9afffff: good map[14]: type Memory, range 32, base 0xf9afe800, size 11, enabled pcib6: requested memory range 0xf9afe800-0xf9afefff: good pcib6: matched entry for 3.1.INTA pcib6: slot 1 INTA hardwired to IRQ 19 cbb0: at device 1.0 on pci3 pcib6: cbb0 requested memory range 0xf9a00000-0xf9afffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf9a00000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib6: matched entry for 3.1.INTA pcib6: slot 1 INTA hardwired to IRQ 19 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x71351217 0x04100007 0x06070021 0x00824000 0x10: 0xf9a00000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffd 0x30: 0x00000001 0x0000fffd 0x00000001 0x04400113 0x40: 0x01fe1028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x00000000 0x90: 0x00052404 0x00000000 0x00000000 0x00000000 0xa0: 0xfe020001 0x00c04000 0x00000015 0x0000000a 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x09004100 0x80e203ea 0x00000000 0x00400118 0xe0: 0x00820000 0x00000000 0x83000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=1217, dev=f7 fwohci0: vendor=1217, dev=f7 fwohci0: <1394 Open Host Controller Interface> mem 0xf9aff000-0xf9afffff,0xf9afe800-0xf9afefff irq 19 at device 1.4 on pci3 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf9aff000 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 42:4f:c0:00:11:0a:1c:5c fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 42:4f:c0:0a:1c:5c fwe0: bpf attached fwe0: Ethernet address: 42:4f:c0:0a:1c:5c fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 42:4f:c0:00:11:0a:1c:5c @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xd76c0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x6fa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eef,0xeff0-0xefff irq 17 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x6ee0 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 55 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xeff0 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x6eb0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x6eb8 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x6ec0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x6ec8 ata3: reset tp1 mask=00 ostat0=ff ostat1=ff ata3: [MPSAFE] ata3: [ITHREAD] ichsmb0: port 0x10c0-0x10df mem 0xfebfbf00-0xfebfbfff irq 17 at device 31.3 on pci0 ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x10c0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] cpu0: on acpi0 ACPI: SSDT @ 0x0xdfe5c4b4/0x02C8 (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0xdfe5be4a/0x05E5 (v 1 PmRef Cpu0Cst 0x00003001 INTL 0x20050624) est0: on cpu0 est0: Invalid id16 (set, cur) = (3375, 3110) est0: Invalid freq 2401, ignored. est0: Invalid id16 (set, cur) = (34827, 1554) est0: Invalid freq 800, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0xdfe5c77c/0x00C4 (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0xdfe5c42f/0x0085 (v 1 PmRef Cpu1Cst 0x00003000 INTL 0x20050624) est1: on cpu1 est1: Invalid id16 (set, cur) = (3375, 3110) est1: Invalid freq 2401, ignored. est1: Invalid id16 (set, cur) = (34827, 1554) est1: Invalid freq 800, ignored. p4tcc1: on cpu1 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcd7ff,0xcd800-0xcffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ums0: on uhub3 ums0: 3 buttons and Z dir. uhub7: on uhub5 uhub7: 4 ports with 3 removable, self powered ugen0: on uhub7 Device configuration finished. Reducing kern.maxvnodes 258634 -> 100000 procfs registered WARNING: ZFS is considered to be an experimental feature in FreeBSD. lapic: Divisor 2, Frequency 99750584 hz Timecounter "TSC" frequency 2394013896 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acpi_acad0: acline initialization start acpi_acad0: Onata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire Line acpi_acad0: acline initialization done, tried 1 times battery0: baacd0: setting PIO4 on ICH8M chip ttery initialization start acd0: setting UDMA33 on ICH8M chip battery0: battery initialization done, tried 1 times battery1: battery initialization start ZFS filesystem version 6 ZFS storage pool version 6 acd0: DVDR drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 152627MB at ata2-master SATA300 ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed hdac0: Probing codec #0... hdac0: HDA Codec #0: Sigmatel STAC9205X hdac0: HDA Codec ID: 0x838476a0 hdac0: Vendor: 0x8384 hdac0: Device: 0x76a0 hdac0: Revision: 0x02 hdac0: Stepping: 0x04 hdac0: PCI Subvendor: 0x01fe1028 hdac0: Found audio FG nid=1 startnode=10 endnode=38 total=28 hdac0: Probing codec #1... hdac0: HDA Codec #1: Conexant (Unknown) hdac0: HDA Codec ID: 0x14f12c06 hdac0: Vendor: 0x14f1 hdac0: Device: 0x2c06 hdac0: Revision: 0x00 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x01fe1028 hdac0: Found modem FG nid=2 startnode=112 endnode=116 total=4 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0xc0000005 NumGPIO=5 NumGPO=0 NumGPI=0 GPIWake=1 GPIUnsol=1 hdac0: nid 10 0x0321101f as 1 seq 15 Headphones Jack jack 1 loc 3 color Black misc 0 hdac0: nid 11 0x0381102e as 2 seq 14 Line-in Jack jack 1 loc 3 color Black misc 0 hdac0: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 14 0x40f000f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 15 0x40f000f1 as 15 seq 1 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 20 0x40f000f2 as 15 seq 2 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 22 0x40f000f3 as 15 seq 3 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 23 0x40f000f4 as 15 seq 4 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 24 0x40f000f5 as 15 seq 5 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 33 0x40f000f6 as 15 seq 6 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 34 0x40f000f7 as 15 seq 7 Other None jack 0 loc 0 color Unknown misc 0 hdac0: Patched pins configuration: hdac0: nid 10 0x0321101f as 1 seq 15 Headphones Jack jack 1 loc 3 color Black misc 0 hdac0: nid 11 0x0381102e as 2 seq 14 Line-in Jack jack 1 loc 3 color Black misc 0 hdac0: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 14 0x40f000f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 15 0x40f000f1 as 15 seq 1 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 20 0x40f000f2 as 15 seq 2 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 22 0x40f000f3 as 15 seq 3 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 23 0x40f000f4 as 15 seq 4 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 24 0x40f000f5 as 15 seq 5 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 33 0x40f000f6 as 15 seq 6 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 34 0x40f000f7 as 15 seq 7 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: 2 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=13 seq=0 hdac0: Pin nid=10 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=12 seq=0 hdac0: Pin nid=11 seq=14 hdac0: Tracing association 0 (1) hdac0: Pin 13 traced to DAC 16 hdac0: Pin 10 traced to DAC 16 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 12 traced to ADC 18 hdac0: Pin 11 traced to ADC 18 hdac0: Association 1 (2) trace succeeded hdac0: Tracing input monitor hdac0: Tracing beeper hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=10 [UNSOL] hdac0: Pin sense: nid=10 res=0x7fffffff hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: IN amp: 0x00050f00 hdac0: OUT amp: 0x80027f7f hdac0: hdac0: nid: 10 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000173f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0321101f hdac0: Pin control: 0x00000080 HP hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 11 hdac0: Name: pin: Line-in (Black Jack) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0381102e hdac0: Pin control: 0x00000024 IN VREFs hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x90a70120 hdac0: Pin control: 0x00000024 IN VREFs hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 13 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x90170110 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x40f000f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x40f000f1 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x000d0c05 hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: Output amp: 0x80027f7f hdac0: mute=1 step=127 size=2 offset=127 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x000d0c05 hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: Output amp: 0x80027f7f hdac0: mute=1 step=127 size=2 offset=127 hdac0: hdac0: nid: 18 hdac0: Name: audio input hdac0: Widget cap: 0x001d0541 hdac0: PWR PROC STEREO hdac0: Association: 1 (0x00004001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=29 [audio selector] hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x001d0541 hdac0: PWR PROC STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=30 [audio selector] [DISABLED] hdac0: hdac0: nid: 20 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040010c hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f000f2 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80051f1f hdac0: mute=1 step=31 size=5 offset=31 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=21 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200100 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f3 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f4 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 24 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f5 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 25 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=14 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Other (None)] [DISABLED] hdac0: + <- nid=11 [pin: Line-in (Black Jack)] hdac0: + <- nid=12 [pin: Mic (Fixed)] (selected) hdac0: + [DISABLED] <- nid=13 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=10 [pin: Headphones (Black Jack)] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=14 [pin: Other (None)] [DISABLED] (selected) hdac0: + [DISABLED] <- nid=22 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Other (None)] [DISABLED] hdac0: + <- nid=11 [pin: Line-in (Black Jack)] hdac0: + <- nid=12 [pin: Mic (Fixed)] hdac0: + <- nid=13 [pin: Speaker (Fixed)] hdac0: + <- nid=10 [pin: Headphones (Black Jack)] hdac0: hdac0: nid: 27 hdac0: Name: audio selector hdac0: Widget cap: 0x00300103 hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Input amp: 0x00050f00 hdac0: mute=0 step=15 size=5 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=25 [audio selector] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300103 hdac0: STEREO hdac0: Input amp: 0x00050f00 hdac0: mute=0 step=15 size=5 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=26 [audio selector] [DISABLED] hdac0: hdac0: nid: 29 hdac0: Name: audio selector hdac0: Widget cap: 0x0030090d hdac0: LRSWAP STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=27 [audio selector] (selected) hdac0: + [DISABLED] <- nid=23 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=24 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030090d hdac0: LRSWAP STEREO hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=28 [audio selector] [DISABLED] (selected) hdac0: + [DISABLED] <- nid=23 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=24 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00040211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00140311 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=34 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400301 hdac0: DIGITAL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f000f6 hdac0: Pin control: 0x00000000 hdac0: connections: 3 hdac0: | hdac0: + <- nid=31 [audio output] [DISABLED] (selected) hdac0: + <- nid=29 [audio selector] hdac0: + <- nid=30 [audio selector] [DISABLED] hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00430681 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00010024 hdac0: PDC IN EAPD hdac0: Pin config: 0x40f000f7 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: hdac0: nid: 35 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x00170303 hdac0: mute=0 step=3 size=23 offset=3 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: volume widget hdac0: Widget cap: 0x00600000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00001 hdac0: STEREO hdac0: hdac0: Processing modem FG cad=1 nid=2... hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e07e0 pcm0: 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e07e0 pcm0: 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: ADC: 18 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=10 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: nid=13 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=18 [audio input] pcm0: | pcm0: + <- nid=29 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=27 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=25 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=11 [pin: Line-in (Black Jack)] [src: line] pcm0: + <- nid=12 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 10 (nid 35 out): -18/0dB (4 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 25 out): 0/40dB (5 steps) pcm0: +- ctl 6 (nid 27 in 0): 0/22dB (16 steps) pcm0: +- ctl 8 (nid 29 out): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 39b0000, 4000; 0xffffffff02108000 -> 39b0000 pcm0: sndbuf_setmap 39c0000, 4000; 0xffffffff02118000 -> 39c0000 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present Unretryable error (probe0:ata0:0:0:0): error 6 (probe0:ata0:0:0:0): Unretryable Error (probe0:ata0:0:0:0): error 6 (probe0:ata0:0:0:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error pass0 at ata0 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ( c d 0 : aItDa:0: 00:x00:1000)0:0 0e0r r o rV E6R: (0cxd000:0a5t0a001:40 :L0D:R0:) :0 xU0n0r0e0t0r0y0a0b lDeF RE:r r0oxrf ffcfdf0f faft a t al0i nbtu0s: 00 xta0r0g0e1t0 700 0 lluinn t01: c0dx00:0 0<0H0L4-0D0T -TSPTR :D V0Dx+0-0R0W0 0G0S0A0- TS1V1RN: A01x0030>0 0R0e1mfofva b l et iCmDe-rR:O M0 xS0C0S0I2-000 edfe vtihceer m : c0dx00:0 03130.000000 MeBr/rs: t0rxa0n0s0f1e0r0s0 0 cpdc0m:: A0txt0e0m0p1t0 0t0o0 q uery idoeavpiicce0 :s iAzssei gfnaiinlge d:I SNAO TI RRQE A1D Yt,o lMoecdailu mA PnIoCt 0pre sieonatpi c0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 msi: Ass(icgdn0i:nga taM0S:I0 :IR0Q: 0)2:5 6e tror olro c6a l( cAdP0I:C a0ta 0:0:0:0): Unretryable Error (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error scsi_cd.c::ioctl cmd=4400648b error=25 (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error Trying to mount root from zfs:tank start_init: trying /sbin/init bge0: Disabling fastboot bge0: Disabling fastboot WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() bge0: link UP Linux ELF exec handler installed >> robert. >> >> >>> 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n >>> (rev 03) >>> Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card >>> Flags: bus master, fast devsel, latency 0, IRQ 17 >>> Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K] >>> Memory at f0000000 (64-bit, prefetchable) [size=1M] >>> Capabilities: [40] Power Management version 2 >>> Capabilities: [58] Vendor Specific Information >>> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 >>> Enable- >>> Capabilities: [d0] Express Endpoint, MSI 00 >>> Capabilities: [100] Advanced Error Reporting >>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- >>> ECRC- UnsupReq- ACSVoil- >>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- >>> ECRC- UnsupReq- ACSVoil- >>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ >>> MalfTLP+ ECRC- UnsupReq- ACSVoil- >>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- >>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >>> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- >>> Capabilities: [13c] Virtual Channel >>> Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0 >>> Capabilities: [16c] Power Budgeting >>> Kernel driver in use: b43-pci-bridge >>> Kernel modules: ssb >>> >>> >>>>>> >>>>>> >>>>>> >>>>>>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled >>>>>>> >>>>>>> >>>>>>> >>>>>> This one is BAR 3, which is used when it doesn't find BAR 1. >>>>>> >>>>>> robert. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled >>>>>>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4 >>>>>>> rev=0x03 hdr=0x00 >>>>>>> >>>>>>> and follow your intrudction.still pain me :( >>>>>>> >>>>>>> (++) Using config file: "xorg.conf1" >>>>>>> drm0: on vgapci0 >>>>>>> info: [drm] Detected an NV50 generation card (0x086900a2) >>>>>>> vgapci0: child drm0 requested pci_enable_busmaster >>>>>>> info: [drm] Initialized nouveau 0.0.12 20060213 >>>>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 >>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>> drm0: [ITHREAD] >>>>>>> info: [drm] Allocating FIFO number 1 >>>>>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII, >>>>>>> invalid/inactiv >>>>>>> e channel id 128 >>>>>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: >>>>>>> [drm] , nSt >>>>>>> atus:info: [drm] >>>>>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data >>>>>>> 0x00000000:0x00 >>>>>>> 000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1: >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2: >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000 >>>>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000 >>>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1 >>>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1 >>>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space >>>>>>> (EE) Screen(s) found, but none have a usable configuration. >>>>>>> >>>>>>> Fatal server error: >>>>>>> no screens found >>>>>>> >>>>>>> Please consult the The X.Org Foundation support >>>>>>> at http://wiki.x.org >>>>>>> for help. >>>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional >>>>>>> informati >>>>>>> on. >>>>>>> >>>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1 >>>>>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1 >>>>>>> before d >>>>>>> estroy.Prepare for strangeness.. >>>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127 >>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). >>>>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1 >>>>>>> >>>>>>> >>>>>>> From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 01:23:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1096E106573D for ; Thu, 26 Mar 2009 01:23:46 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 57B3B8FC17 for ; Thu, 26 Mar 2009 01:23:45 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 26 Mar 2009 01:23:43 -0000 Received: from p54865167.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.81.103] by mail.gmx.net (mp044) with SMTP; 26 Mar 2009 02:23:43 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX18FJwloym4FT2J5zSyR5Y63wBC4NGXJ7hkaQ2zMOH 93KIvsno5dTJZG Message-ID: <49CAD942.7050304@gmx.net> Date: Thu, 26 Mar 2009 02:24:18 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Sam Leffler References: <49C83038.40300@gmx.net> <49CAC1C0.9030506@freebsd.org> <49CAD620.2030106@gmx.net> In-Reply-To: <49CAD620.2030106@gmx.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:23:46 -0000 Daniel Thiele wrote: > > I already prepared a USB flash drive with a CURRENT from March 3 20:00h. > At least i hope that this is what That should have said March 1, sorry. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 01:40:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775951065673; Thu, 26 Mar 2009 01:40:48 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 402638FC12; Thu, 26 Mar 2009 01:40:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2Q1dQ77032874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 21:39:26 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> <1238014404.1828.27.camel@balrog.2hip.net> <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MK+hdDrbCt2cW4WlI6S1" Organization: FreeBSD Date: Wed, 25 Mar 2009 20:40:20 -0500 Message-Id: <1238031620.1828.92.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:40:48 -0000 --=-MK+hdDrbCt2cW4WlI6S1 Content-Type: multipart/mixed; boundary="=-fjex/E/gB+ZQeXe+Vu6l" --=-fjex/E/gB+ZQeXe+Vu6l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 18:22 -0500, Brandon Gooch wrote: > On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland wrot= e: > > On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote: > >> On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland = wrote: > >> > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: > >> >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall wrote: > >> >> > Brandon Gooch wrote: > >> >> >> > >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim = wrote: > >> >> >> > >> >> >>> > >> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >> >> >>> > >> >> >>>> > >> >> >>>> The committed version is working well, I am suspending and res= uming > >> >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of = the > >> >> >>>> major things I needed to work so I could run FreeBSD primarily= on > >> >> >>>> my notebook. > >> >> >>>> > >> >> >> > >> >> >> I just finished a kernel build and it seems as though your > >> >> >> recent commits have fixed the clock (at least for me)! > >> >> >> > >> >> >> I feel sorry for all the i386 folks on ACPI notebooks... > >> >> >> > >> >> >> Thanks! > >> >> >> > >> >> >> -Brandon > >> >> >> > >> >> > > >> >> > Picking a semi-random message here.. > >> >> > > >> >> > Thanks for your work on this! In the past (months ago) I tried t= he patch > >> >> > set which didn't work, but the code in -current lets me suspend a= nd resume > >> >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think = this is a > >> >> > first for me, of all the laptops I've had, none have ever been ab= le to > >> >> > suspend and resume in a successful or useful way, and I've been j= ealous of > >> >> > the Thinkpad users that could claim otherwise. I could suspend a= nd resume > >> >> > fine while in the console, then I ran startx and the suspend and = resume > >> >> > worked while I was in X with intel graphics, however my system wa= s slow > >> >> > after that resume. I didn't spend much time looking at it since = I was at > >> >> > work, and I didn't see any obvious reasons for the slowness (cpu = frequency > >> >> > was fine, cx states were C2 or lower (C1), top showed mostly idle= , no > >> >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not = the mouse > >> >> > or typing though). I didn't go back to console, I just shut down= without > >> >> > trying any other situations yet. > >> >> > > >> >> > A tip I want to note for any users who may not have success with = their > >> >> > screen on resume: In the past it seemed to help me to have a pow= er-on > >> >> > password set in my BIOS since the BIOS will turn on the screen on= resume to > >> >> > ask me for my password. I don't know if it is still helping me, = but I've > >> >> > seen in the past where it has. > >> >> > _______________________________________________ > >> >> > freebsd-current@freebsd.org mailing list > >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > >> >> > > >> >> > >> >> The sluggish response in X on Intel video has been an issue the pas= t > >> >> couple of days, triggered by suspend/resume or simply switching to = VTY > >> >> and back. > >> > > >> > I just committed code that should fix this... > >> > > >> > robert. > >> > > >> >> See this thread: > >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/00496= 8.html > >> >> > >> >> Firefox is unusable, but xterms are still usable. I have to reboot = to > >> >> get back to "normal" > >> >> > >> >> -Brandon > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > >> > -- > >> > Robert Noland > >> > FreeBSD > >> > > >> > >> It seems to have helped -- slightly. Firefox is still too laggy when > >> interacting with interface elements (scrollbar, toolbars, menus), and > >> typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to > >> use, perhaps because they're not as graphically intensive :) > >> > >> Also, it seems to have broken the suspend/resume. The machine does > >> wake up, but X is no longer there (I'm at the VTY from which I started > >> X) and I can't switch to another VTY. The machine still "works" for a > >> period, but attempts to switch VTY or enter commands from the keyboard > >> eventually lock it up, resulting in a continuous beep tone and > >> requiring a hard power-off (holding down the power button). > > > > Can you try the attached patch? This was a last minute change that I > > made and I don't know why it seems to be upsetting things so, but it > > looks like it causes things to not shutdown properly. > > > > It looks like it isn't safe to suspend with / on usb2, so I can't reall= y > > test s/r still... > > > > robert. > > > >> -Brandon > > -- > > Robert Noland > > FreeBSD > > >=20 > Applying the patch and rebuilding does get me back to successful > suspend/resume cycle, but the sluggish application weirdness still > persists. Ok, I'll commit this for the time being then... > It's odd, but for brief moment (about a second) after resume, the > screen comes back on as if it has been issued a "DPMS on" (as in say, > vbetool or something), and then it flashes off again, only to come > back on another second later. I assume this has something to do with > resetting or restoring bits some place, but I wondered if this is an > expected behavior. I would need to see a drm debug across suspend resume to get an idea of what is going on for sure. If the interrupt handler is being uninstalled and reinstalled, it should work right... What I am doing now, probably due to the intel 2d driver being buggy, is when we reinstall the irq handler, I force vblank interrupts on and schedule them to be turned off 5 seconds later if nothing has asked for them. If the interrupt handler isn't being uninstalled, then I probably need to look at the suspend/resume bit of the intel drm driver and make sure that all of the interrupt foo is being saved/restored. Try the attached patch in addition to what you have now. Let's see if restoring the interrupt registers helps things. > BTW, what utility would provide a decent test with quantifiable > results. I feel there may be a better way to help us understand what > is actually causing the symptoms and to pinpoint it in the source for > you. Describing a GTK app as "laggy" or "sluggish" is hardly good > enough :) You are correct, laggy is very useful... What seems to be happening is that we either lose interrupts, or they are getting disabled and not re-enabled... Running "vblank_mode=3D3 glxgears" should behave badly if it is vblank interrupts that are borked. User interrupts will disrupt the entire pipeline as they are used to mark what commands have been sent and processed. But, I don't have a clear method for determining exactly what is broken right now... That is what makes this so frustrating... robert. =20 > Your thoughts and instruction are welcome! >=20 > -Brandon --=20 Robert Noland FreeBSD --=-fjex/E/gB+ZQeXe+Vu6l Content-Disposition: attachment; filename="i915_suspend.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="i915_suspend.patch"; charset="us-ascii" SW5kZXg6IGk5MTVfc3VzcGVuZC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gaTkxNV9zdXNwZW5kLmMJKHJl dmlzaW9uIDE5MDQwMikNCisrKyBpOTE1X3N1c3BlbmQuYwkod29ya2luZyBjb3B5KQ0KQEAgLTUy Miw2ICs1MjIsMTIgQEANCiANCiAJaTkxNV9yZXN0b3JlX3ZnYShkZXYpOw0KIA0KKwkvKiBJbnRl cnJ1cHQgc3RhdGUgKi8NCisJSTkxNV9XUklURShQSVBFQVNUQVQsIGRldl9wcml2LT5zYXZlUElQ RUFTVEFUKTsNCisJSTkxNV9XUklURShQSVBFQlNUQVQsIGRldl9wcml2LT5zYXZlUElQRUJTVEFU KTsNCisJSTkxNV9XUklURShJRVIsIGRldl9wcml2LT5zYXZlSUVSKTsNCisJSTkxNV9XUklURShJ TVIsIGRldl9wcml2LT5zYXZlSU1SKTsNCisNCiAJcmV0dXJuIDA7DQogfQ0KIA0K --=-fjex/E/gB+ZQeXe+Vu6l-- --=-MK+hdDrbCt2cW4WlI6S1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknK3QQACgkQM4TrQ4qfROOuigCfQ+PQDXjmx+zHViqfJCciQ1WC jrYAnjcCdDz11C5OhGF41dfGOLA4CDM7 =kgjc -----END PGP SIGNATURE----- --=-MK+hdDrbCt2cW4WlI6S1-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 02:01:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2BA3106564A for ; Thu, 26 Mar 2009 02:01:18 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by mx1.freebsd.org (Postfix) with ESMTP id 72E4A8FC1B for ; Thu, 26 Mar 2009 02:01:18 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from [192.168.42.44] (mm.wbb.net.cable.rogers.com [74.210.92.229] (may be forged)) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n2Q21E2l012152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 19:01:16 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 25 Mar 2009 19:01:08 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@peregrin.local To: Scot Hetzel In-Reply-To: <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> Message-ID: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on orthanc.ca Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:01:19 -0000 > You can do the same thing with ssh to transfer files to a remote host: > > tar cjf - . | ssh user@hostb "(cd /desired/path; tar xjf -)" But I can't get full wire speed with ssh; with rsh I can. --lyndon The longest UNIX error code is ENAMETOOLONG. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 02:17:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EE5E1065676 for ; Thu, 26 Mar 2009 02:17:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2B82D8FC1C for ; Thu, 26 Mar 2009 02:17:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id AA65346B09; Wed, 25 Mar 2009 22:17:33 -0400 (EDT) Date: Thu, 26 Mar 2009 02:17:33 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <983452.12250.qm@web63904.mail.re1.yahoo.com> Message-ID: References: <983452.12250.qm@web63904.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:17:34 -0000 On Wed, 25 Mar 2009, Barney Cordoba wrote: >> morninglightmountain# grep secure /etc/ttys|grep pts >> pts/0 none network secure > > What tty does it say you are on? You may have the older stuff. > > That setup does not work for me. It was the first thing I tried. > > I'm running 800070 On my easily on-hand 800060 box, the secure flag on pts/0.../10 appeared to work as expected: with 'secure', I was able to log in as root using telnet from localhost; with it removed, I wasn't. I'll upgrade userspace tonight/overnight and see if it works with a more recent userspace. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 02:29:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80DC4106566B for ; Thu, 26 Mar 2009 02:29:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 38A228FC0A for ; Thu, 26 Mar 2009 02:29:57 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by qyk40 with SMTP id 40so716544qyk.3 for ; Wed, 25 Mar 2009 19:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W7jgRZOl1HnNE3B+p31ns5gzJ31dv+Z6FetB5j4Bp9Y=; b=mqF/bKulJxyOElRmxruVZmMRWtq6MqN54QMGxGNoFJvm7FabY4TW4SVW6JmPiqVUQE nRRL2DSZ1FcdinDORYm0lTOREaW1DgqeFflfTRCAhThFIExG4lMnwoA5P/jm0YWxdS0Q HzQ9WY3bwWrGtH5JAoqGkhbtYp85bTXE+OpGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ch3qbLuYH4KxHpg1R+wi2SiMMCM2MbaXo7/kYEgVVuWW0hAH3WZXdGnjq4XkfuXBMk MeXKLt6Fe6e/9ehwzqoqrIRCAZEt6O1B48ma6Cl0Il97pVO+f7wPAJuCAEePsYdQK08L tVcIZvhpju4tDy2mVhUMT6UQROyBOhgxxQCF0= MIME-Version: 1.0 Received: by 10.220.99.149 with SMTP id u21mr40527vcn.94.1238032685211; Wed, 25 Mar 2009 18:58:05 -0700 (PDT) In-Reply-To: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> Date: Wed, 25 Mar 2009 20:58:05 -0500 Message-ID: <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> From: Scot Hetzel To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:29:58 -0000 On Wed, Mar 25, 2009 at 7:20 PM, Lyndon Nerenberg wrote: >> Oh I know about SSH and keys but teh ability to pipe data into s tcp >> socket and have it fed into another process is really useful in testing. and >> of course no encryption overhead. > > ssh cannot touch rsh for things like 'tar cf - . | rsh hostb tar xf -'. > You can do the same thing with ssh to transfer files to a remote host: tar cjf - . | ssh user@hostb "(cd /desired/path; tar xjf -)" Scot From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 03:42:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8414F1065700 for ; Thu, 26 Mar 2009 03:42:13 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from m12-11.163.com (m12-11.163.com [220.181.12.11]) by mx1.freebsd.org (Postfix) with SMTP id C53228FC14 for ; Thu, 26 Mar 2009 03:42:12 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from [127.0.0.1] (unknown [60.191.86.3]) by smtp7 (Coremail) with SMTP id C8CowLA7_1KC+cpJn5QsLQ--.1621S2; Thu, 26 Mar 2009 11:41:55 +0800 (CST) Message-ID: <49CAF98C.8000209@163.com> Date: Thu, 26 Mar 2009 11:42:04 +0800 From: kevin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ticso@cicely.de References: <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> In-Reply-To: <20090325183831.GD16409@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: C8CowLA7_1KC+cpJn5QsLQ--.1621S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxJr1fJFWkZrWfZF1ruw13XFb_yoW8CrW7pF WftF4vkF4kJFW3AFZFkw10kay7tr4ftFy0g3sY9ryUuw1Y9F9aq343Kay5CrWj9F48Kw1r AFZrAa48Ga4qv3DanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU UeW7k042IE42xK82IY6r43WwAYjxAI6xAIw28IcVAK0I8IjxAxM7k042IE4IxYO2xFxVAq jxCEw4Av424lb7Iv0xC_JF4lb4IE77IF4wAFF20E14v26r1j6r4UM7C26xCjj4IEI4klw4 CSwwAFxVCaYxvI4VCIwcAKzIAtM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2IY67AK xVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIE14 v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAawVAYYI1S6c8GOVWUur45 Jryln4vEF7Iv6F18KVAqrcv_XVWUtr1rJF1lnx0Ec2IEnICE548m6r1DJrWUZwAqx4xG64 xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r4j 6F4UM4x0Y48IcVAKI48JM4IEnf9ElVAFpTB2q-sK649IAas0WaI_GwCjxxvEw4Wlc2xSY4 AK67AK6r48MxkI7II2jI8vz4v_Cr0_Zr1l42xK82IYc2Ij64vIr41l4x8a6c8ajcxJMI8E 67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7xRR9NV7 UUUUU== X-CM-SenderInfo: pnhyx0x0ol03r26rljoofrz/ Cc: Alexander Leidinger , FreeBSD Current , Mark Powell , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 03:42:13 -0000 Bernd Walter wrote: > On Wed, Mar 25, 2009 at 06:04:08PM +0000, Mark Powell wrote: > >> On Wed, 25 Mar 2009, Bernd Walter wrote: >> >> >>> On Wed, Mar 25, 2009 at 03:21:28PM +0100, Alexander Leidinger wrote: >>> I wouldn't be surprised if the problem is in the drive firmware. >>> Preread and wc both have the potential to put a lot load to the drives >>> and can trigger bugs that otherwise wouldn't matter. >>> >> I've emailed WD support for more info. Not expecting much though. >> From reading other threads on these Green Power drives them seem rather >> crap. This is my model and firmware: >> >> http://www.datacent.com/datarecovery/hdd/western_digital/WD10EADS-00L5B1 >> >> There's some head park problem too, but with 5s ZFS sync I don't think it >> applies in this case: >> >> http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=120&sid=a1caf68d80ef8fecc5d9e86defde4c19 >> http://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386304 >> >> >>> I also have a system running WD drives and ECC RAM which show CRC errors >>> >> >from time to time, while all other systems have no CRC problem at all. >> >> Interesting. Are those CRC problems with WC on or off? >> > > WC is on, prefetch is off, but only because it had bad performance with > MySQL. > Drives are Serial ATA II > I don't know if it is with the drives, but other reasons are less > likely in my opinion. > The system is located in a data center and since I only get a few errors > I decided to live with it and not to debug it further. > > I don't think it is drivers related.I tested on both ata2-master SATA150 and ata2-master SATA150. loader.conf zfs_load="YES" vm.kmem_size_max="2048M" vm.kmem_size="2048M" Thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 04:26:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A53191065672 for ; Thu, 26 Mar 2009 04:26:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4848FC14 for ; Thu, 26 Mar 2009 04:26:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 25 Mar 2009 20:59:34 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.1) with ESMTP id n2Q3whGa004014 for ; Wed, 25 Mar 2009 20:58:43 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id n2Q3whYg004013 for freebsd-current@freebsd.org; Wed, 25 Mar 2009 20:58:43 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200903260358.n2Q3whYg004013@ambrisko.com> In-Reply-To: <1237926289.1735.17.camel@localhost> To: freebsd-current@freebsd.org Date: Wed, 25 Mar 2009 20:58:43 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 04:26:51 -0000 FWIW, I have it working on a ThinkPad Z61p. Things I had to do was hack the isa vga driver to not attach since both the isa and pci drivers attached to the vga and that caused issues. I had to remove usb from my kernel since it causes a panic. My bge NIC seems to work fine. Previously, I disabled pccard from suspending since it used to cause an interrupt storm with USB sharing the same interrupt. The latest ATA code works great, before I had to use a slightly hacked FreeBSD 7.0 version. I do the suspend/resume thing vidcontrol -s 1 < /dev/ttyv0 and vidcontrol -s 9 < /dev/ttyv0 since that seems to help X. It's been a long time, that I've waited to have suspend and resume work on amd64/smp! Till now, I've been stuck with i386/up :-( I have 2 boot partitions so I can boot 32bit or 64bit. I mount my 32bit stuff as /32bit.. then add /32bit/usr/local/bin to my path and ldconfig -32 -m /32bit/usr/local/lib for some app's that aren't available for amd64 like vnc. After another patch to rtld and fixing an absolute sym-link versus relative my 32bit stuff runs great on amd64. Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 05:12:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2932106566C for ; Thu, 26 Mar 2009 05:12:29 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by mx1.freebsd.org (Postfix) with ESMTP id 761B98FC0A for ; Thu, 26 Mar 2009 05:12:29 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KH300HT2ICG8A@mailgw1.fnal.gov> for freebsd-current@freebsd.org; Wed, 25 Mar 2009 23:12:28 -0500 (CDT) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032523122813927 for ; Wed, 25 Mar 2009 23:12:28 -0500 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KH300601HPYMS@mailgw2.fnal.gov> (original mail from wenji@fnal.gov) for freebsd-current@freebsd.org; Wed, 25 Mar 2009 23:12:28 -0500 (CDT) Received: from fnal.gov (imap2.fnal.gov [131.225.111.7]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KH300A5IICSQX@mailgw2.fnal.gov> for freebsd-current@freebsd.org; Wed, 25 Mar 2009 23:12:28 -0500 (CDT) Received: from [67.184.226.114] by imap2.fnal.gov (mshttpd); Wed, 25 Mar 2009 23:12:28 -0500 Date: Wed, 25 Mar 2009 23:12:28 -0500 From: Wenji Wu To: freebsd-current@freebsd.org Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-type: text/plain; charset=windows-1252 Content-language: en Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline X-Accept-Language: en Priority: normal Subject: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:12:29 -0000 I, Could anybody help me out? Thanks in advance.=20 LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT. I loaded FreeBSD= 8.0-Current on my system, and try to run LOCK PROFILING. I have adde= d the =93options LOCK_PROFILING=94 to the configure file and rebui= ld the kernel. Then I reboot the system, and run =93sysctl =96a|grep = lock=94 to check if the lock debugging has been enabled. But NO lock = debugging related parameters show up. LOCK_PROFILING does not work on= FreeBSD 8.0-CURRENT! I have repeated the same operations on FreeBSD 7.1, =93sysctl =96a|gr= ep lock=94 shows =93LOCK PROFILING=94 works. So what happens to FreeB= SD 8.0-CURRENT? Thanks, wenji From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 05:40:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1334F106566C for ; Thu, 26 Mar 2009 05:40:21 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC408FC08 for ; Thu, 26 Mar 2009 05:40:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n2Q5eIQh026887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 16:10:18 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 26 Mar 2009 16:10:15 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5080707.qNPf97Wasm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903261610.16690.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Saifi Khan Subject: Re: FreeBSD can't see OpenBSD slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:40:21 -0000 --nextPart5080707.qNPf97Wasm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 26 March 2009 12:25:42 Saifi Khan wrote: > Hi: > > I installed OpenBSD 3.5 in a 25GB slice on a 160GB SATA HDD. > > Now when i power up the system and boot into a FreeBSD > instalation CD (8.x 200902 snapshot), the Fdisk partition editor > shows the entire disk as unused. > > Are slices created with OpenBSD tools not seen in FreeBSD ? I would say it depends how you made the slices.. If they aren't valid DOS partitions then I guess OpenBSD didn't do the righ= t=20 thing. Or FreeBSD is rejecting valid partitions, is there anything in dmesg about = it? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5080707.qNPf97Wasm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJyxVA5ZPcIHs/zowRAjcmAKCcJr19YxDu7NZ2Z6qpsH2OdvvtrQCgjxic gdQdIHKKZa0yZEViXTyD2so= =YS1Z -----END PGP SIGNATURE----- --nextPart5080707.qNPf97Wasm-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 06:17:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE8A106566B for ; Thu, 26 Mar 2009 06:17:15 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 70AD88FC0C for ; Thu, 26 Mar 2009 06:17:15 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so685521rvb.43 for ; Wed, 25 Mar 2009 23:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=OA3NjvQEP1kisW7PyQlTzDnnamD2G7jYrF92J8Ah4ik=; b=dTukaaWyNINb1XUIfdxEgW5g2fVFLf+e61yeJwDhluwv/5uCJ4FIP7FWj/gUc7VmIX EAfRkXDtJnAxmrVy5W7GGcqWZEFTYc/zQ1C6hIB11qg7bSp0lY7l2G7pKr6jHHErZBxS 6kBDtPOAcMmv7cpD86SBTQzQdiN+1oHYo5ubQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JurfHcOzhlH0cN+UmDgNOo3JtlBsPv+BWYVDXqrx5MRV5APync6jYZ+E/cHVVp8S+A bcM5CIYkaCDcZTXqe5PPe9oLQ5q91+oSOPrFjifbK1ieA+AY9sV4J/wwmKlcXLAXGiAP xQxW/Q1/rwa/ykYomIHU7czYjQNXqK3qv6BwA= MIME-Version: 1.0 Received: by 10.141.177.2 with SMTP id e2mr241978rvp.266.1238046801369; Wed, 25 Mar 2009 22:53:21 -0700 (PDT) In-Reply-To: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> Date: Wed, 25 Mar 2009 22:53:21 -0700 Message-ID: From: Freddie Cash To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:17:15 -0000 On Wed, Mar 25, 2009 at 7:01 PM, Lyndon Nerenberg wrote: >> You can do the same thing with ssh to transfer files to a remote host: >> >> tar cjf - . | ssh user@hostb "(cd /desired/path; tar xjf -)" > > But I can't get full wire speed with ssh; with rsh I can. With openssh-portable from ports, with the HPN patches included, using the None cipher, you should be able to get the best of both worlds: encrypted authentication, cleartext data transfer. According to the info on the HPN website, they're able to get ~90% of wirespeed on a gigabit link. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 08:27:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13D1F106567C for ; Thu, 26 Mar 2009 08:27:54 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D88FE8FC29 for ; Thu, 26 Mar 2009 08:27:53 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-75-22.phlapa.east.verizon.net [141.151.75.22]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 008C768EE3; Thu, 26 Mar 2009 17:27:50 +0900 (JST) Date: Thu, 26 Mar 2009 04:27:45 -0400 From: Yoshihiro Ota To: Alex Keda , Hans Petter Selasky Message-Id: <20090326042745.1df176a0.ota@j.email.ne.jp> In-Reply-To: <200903240846.35938.hselasky@c2i.net> References: <49C7FE13.90808@lissyara.su> <200903240846.35938.hselasky@c2i.net> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 08:27:54 -0000 On Tue, 24 Mar 2009 08:46:35 +0100 Hans Petter Selasky wrote: > On Monday 23 March 2009, Alex Keda wrote: > > I have USB floppy. > > > > Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device > > descriptor at addr 3 failed! > > Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 > > Mar 24 00:11:26 HP kernel: umass0: > 0/0, rev 1.10/2.00, addr 3> on usbus0 > > Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Actually, that is the same FDD as mine. This is the latest so far. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1783351+0+archive/2009/freebsd-current/20090315.freebsd-current I haven't got much time to work in. Actually, this model stopped working since 7.0. Regards, Hiro From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 08:56:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD8A106564A for ; Thu, 26 Mar 2009 08:56:24 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 492188FC0C for ; Thu, 26 Mar 2009 08:56:24 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 2585 invoked by uid 98); 26 Mar 2009 08:56:22 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9169. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.114443 secs); 26 Mar 2009 08:56:22 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 26 Mar 2009 08:56:22 +0000 Received: (qmail 60330 invoked by uid 1002); 26 Mar 2009 08:56:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Mar 2009 08:56:20 -0000 Date: Thu, 26 Mar 2009 08:56:20 +0000 (GMT) From: "Mark Powell" To: ticso@cicely.de In-Reply-To: <20090325183831.GD16409@cicely7.cicely.de> Message-ID: <20090326084726.N87213@rust.salford.ac.uk> References: <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , kevin , FreeBSD Current , Mark Powell , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 08:56:25 -0000 On Wed, 25 Mar 2009, Bernd Walter wrote: > WC is on, prefetch is off, but only because it had bad performance with > MySQL. > Drives are Serial ATA II Hmmm. Strange. My previous array was primarily WD5000AAKS, but I didn't have these issues with those. I actually had 6xWD5000AAKS and 6 more old drives (200GB, 3x250GB, 320GB & 400GB) joined together with gstripe and gconcat to make 3x500GB, for a total 9x500GB RAIDZ2. With some pretty old PATA Maxtor 200GB and 250GB in there; spread across ICH9, JMB363 and Sil3132; I'd've expected CRC issues then. I scrubbed my pool every week for 18 months or so, with no errors to report. However, it's only since I got these 6xWD10EADS that problems have occurred. Perhaps the higher throughput of these drives is highlighting issues elsewhere? > I don't know if it is with the drives, but other reasons are less > likely in my opinion. > The system is located in a data center and since I only get a few errors > I decided to live with it and not to debug it further. I've decided to split my drives in two pools; 5x500GB RAIDZ1 of WD5000AAKS and the 6x1TB RAIDZ2 of WD10EADS. I'll see if they perform differently. I'm using the defaults of WC on, with all ZFS options enabled. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 09:02:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C27106566B for ; Thu, 26 Mar 2009 09:02:19 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id B21C88FC17 for ; Thu, 26 Mar 2009 09:02:18 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 48987 invoked by uid 98); 26 Mar 2009 09:02:17 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9169. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.053289 secs); 26 Mar 2009 09:02:17 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 26 Mar 2009 09:02:17 +0000 Received: (qmail 60758 invoked by uid 1002); 26 Mar 2009 09:02:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Mar 2009 09:02:15 -0000 Date: Thu, 26 Mar 2009 09:02:15 +0000 (GMT) From: "Mark Powell" To: Alexey Shuvaev In-Reply-To: <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> Message-ID: <20090326090147.D87213@rust.salford.ac.uk> References: <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090325180054.L87213@rust.salford.ac.uk> <20090325183831.GD16409@cicely7.cicely.de> <20090325203558.GA4533@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , ticso@cicely.de, Mark Powell Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:02:19 -0000 On Wed, 25 Mar 2009, Alexey Shuvaev wrote: > I don't use zfs, just ufs2 + soft updates, but I see sometimes rather > heavy data corruption (most often on / filesystem). > No kernel messages, I can shut down the system successfully just > to find the remnants of filesystems on the next boot. > It doesn't happen often, I think compiling ports in a jail + some > activity in the host increase the probability of a failure. > > The drive is: > ATA channel 3: > Master: ad6 SATA revision 2.x > > hw.ata.wc=1 (default) Have you tried turning WC off to see if it improves matters? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 09:12:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C1C106566B for ; Thu, 26 Mar 2009 09:12:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 895E08FC12 for ; Thu, 26 Mar 2009 09:12:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2Q8t6ti029427 for ; Thu, 26 Mar 2009 19:55:08 +1100 Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2Q8sqnJ025676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 19:54:53 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2Q8spWl056509; Thu, 26 Mar 2009 19:54:51 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2Q8snaf056508; Thu, 26 Mar 2009 19:54:49 +1100 (EST) (envelope-from peter) Date: Thu, 26 Mar 2009 19:54:49 +1100 From: Peter Jeremy To: Bruce Cran Message-ID: <20090326085449.GB56137@server.vk2pj.dyndns.org> References: <49BE7C5A.2080103@icyb.net.ua> <10611.1237233778@critter.freebsd.dk> <20090320074833.67d615e2@gluon> <49C37B75.5060905@andric.com> <20090320191938.25d85caa@gluon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: <20090320191938.25d85caa@gluon> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Dimitry Andric , freebsd-current@freebsd.org Subject: Re: ata: printf on every spinup/spindown? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:12:30 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-20 19:19:38 +0000, Bruce Cran wrote: >There's a reluctance to include code like this, I >think because it bypasses the ATA driver and talks directly to the >drive. Since the driver doesn't know what the drive's been told to do, >it can't know to adjust timers etc. to wait for the disk to spin back >up, for example. This code is no worse than installing sysutils/ataidle - which also bypasses the driver. As it stands, FreeBSD out-of-the-box behaves in a way that adversely impacts laptop HDD life - and correcting this requires that the end-user both be aware of the problem and then find, install and configure a port to work around this. I am very uncomfortable with this and would prefer to see the base system require less user knowledge/intervention. --=20 Peter Jeremy --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknLQtkACgkQ/opHv/APuIeKVgCfR28rM3fMkpKJ0OnXIOtr8Zpi eq4An0UwlhnHFRuof9KLA+FokxigwiYK =wYNo -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 10:13:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBC91065675 for ; Thu, 26 Mar 2009 10:13:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 473838FC17 for ; Thu, 26 Mar 2009 10:13:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2QAD4ro022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 21:13:05 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2QAD4Vg058092; Thu, 26 Mar 2009 21:13:04 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2QAD3Mh058091; Thu, 26 Mar 2009 21:13:03 +1100 (EST) (envelope-from peter) Date: Thu, 26 Mar 2009 21:13:03 +1100 From: Peter Jeremy To: ticso@cicely.de Message-ID: <20090326101303.GJ56137@server.vk2pj.dyndns.org> References: <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4IYkFBVPN84tP7K" Content-Disposition: inline In-Reply-To: <20090325152940.GB16409@cicely7.cicely.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:13:16 -0000 --T4IYkFBVPN84tP7K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-25 16:29:40 +0100, Bernd Walter wrote: >I wouldn't be surprised if the problem is in the drive firmware. >Preread and wc both have the potential to put a lot load to the drives >and can trigger bugs that otherwise wouldn't matter. I'll second this. Whilst stress-testing ZFS, I've managed to wedge a Samsung drive to the point where it needed a power-cycle to recover (HD103UJ 1AA01112 if anyone wants to know what to avoid). >I also have a system running WD drives and ECC RAM which show CRC errors >from time to time, while all other systems have no CRC problem at all. It may also be an interaction between the controller and drives due to slightly different interpretation of the ATA spec (or corner-cutting). --=20 Peter Jeremy --T4IYkFBVPN84tP7K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknLVS8ACgkQ/opHv/APuIc7SQCghfPZoz3IgMAVR0in2ArzxeGL +68AnREkJJQQN6gd1a64ea4zXeoER6Hy =rIxY -----END PGP SIGNATURE----- --T4IYkFBVPN84tP7K-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 10:43:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A46AA106566B for ; Thu, 26 Mar 2009 10:43:59 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 659A88FC0A for ; Thu, 26 Mar 2009 10:43:59 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 2596423C4D0; Thu, 26 Mar 2009 11:43:58 +0100 (CET) Date: Thu, 26 Mar 2009 11:43:58 +0100 From: Peter Schuller To: Lyndon Nerenberg Message-ID: <20090326104357.GA39637@hyperion.scode.org> References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:43:59 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > ssh cannot touch rsh for things like 'tar cf - . | rsh hostb tar xf -'. FWIW, ssh -c arcfour helps. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknLXG0ACgkQDNor2+l1i313pwCeO8SocFmb/M3QLTw04zKUl2Js zFYAoOWld6n3DQg9yosnHp1KMTmZN2HW =6nRM -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 12:10:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779CA1065AA8 for ; Thu, 26 Mar 2009 12:10:44 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id A486A8FC1E for ; Thu, 26 Mar 2009 12:10:41 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2QCAbeZ079948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Mar 2009 13:10:40 +0100 (CET) (envelope-from michiel@boland.org) Message-ID: <49CB70BD.3040607@boland.org> Date: Thu, 26 Mar 2009 13:10:37 +0100 From: Michiel Boland User-Agent: Thunderbird 2.0.0.19 (X11/20090315) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 12:10:54 -0000 Hi. I still have problems with a very slow display after logging out of an X session and/or switching VTYs. The problem goes away if I add hw.pci.enable_msi=0 to /boot/loader.conf. Last csupped Mar 26 09:49 CET. System is Dell optiplex 745. Has built-in Intel Graphics Media Accelerator 950 Anything I can do to help solve this problem? From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 12:53:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 545E3106566B for ; Thu, 26 Mar 2009 12:53:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 102638FC18 for ; Thu, 26 Mar 2009 12:53:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:34d0:c0e4:cf1a:3731] (unknown [IPv6:2001:7b8:3a7:0:34d0:c0e4:cf1a:3731]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E8D395C43; Thu, 26 Mar 2009 13:53:06 +0100 (CET) Message-ID: <49CB7AB1.6010704@andric.com> Date: Thu, 26 Mar 2009 13:53:05 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b4pre) Gecko/20090324 Shredder/3.0b3pre MIME-Version: 1.0 To: Peter Jeremy References: <49BE7C5A.2080103@icyb.net.ua> <10611.1237233778@critter.freebsd.dk> <20090320074833.67d615e2@gluon> <49C37B75.5060905@andric.com> <20090320191938.25d85caa@gluon> <20090326085449.GB56137@server.vk2pj.dyndns.org> In-Reply-To: <20090326085449.GB56137@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-current@freebsd.org Subject: Re: ata: printf on every spinup/spindown? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 12:53:08 -0000 On 2009-03-26 09:54, Peter Jeremy wrote: > On 2009-Mar-20 19:19:38 +0000, Bruce Cran wrote: >> There's a reluctance to include code like this, I >> think because it bypasses the ATA driver and talks directly to the >> drive. Since the driver doesn't know what the drive's been told to do, >> it can't know to adjust timers etc. to wait for the disk to spin back >> up, for example. > > This code is no worse than installing sysutils/ataidle - which also > bypasses the driver. In the case of this particular patch, it only enables adjusting the harddisk's APM and Acoustic Management settings. These should have no influence on the ATA driver. Most (notebook) disks will internally spin down and up anyway, if APM is enabled by default in the factory, and there's not much the ATA driver can do about it. Same for Acoustic Management, this apparently lets it make more or less noise, having nothing to do with the driver. Would it really be necessary to move this userspace piece of code into the kernel? I guess I could patch it so the whole ATA request stuff goes into the ATA driver itself, but what do you gain by doing this? More complexity in the ATA driver? :) From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 13:12:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20376106570A for ; Thu, 26 Mar 2009 13:12:06 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id E4D1C8FC0C for ; Thu, 26 Mar 2009 13:12:05 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so914613rvb.43 for ; Thu, 26 Mar 2009 06:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=uxIb+JYrq2e0g7mm3XXmU1yWp93gPzilid/JOzYCeXE=; b=PVlXV6MSHtrHX5wdthshkhypdgcZdbu4g0LVr7ikfstHMOO4Nkb0COiLA2k/qhlDpD 7A38HzhmjcyWvsvl5XjwulCwVOVdh7vOi1dJbpjCkbHcTkR8H8OF7kyXhQGOoRVQAffh nE6fVfFbcS4wv0FrQLkxBYIGE06+EIxHbLzBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=PRPwqPdvmQxPXPd4KPpFf/O4+RuV38MlJ1wmT0zz0elQgJJ4fJl34UOqN0gTQrDm89 RkqsEWyxy2NRTFJUOIaHZB/V4g3esTmD31+Xe8lYswHUmJytdVG0gObTnKXdm/IetcqV aIUaApzA2uGeKzxmQ/t3/jU8EbmdZLpGGubqE= MIME-Version: 1.0 Received: by 10.143.41.5 with SMTP id t5mr365560wfj.134.1238071914406; Thu, 26 Mar 2009 05:51:54 -0700 (PDT) Date: Thu, 26 Mar 2009 18:21:54 +0530 Message-ID: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> From: Prashant Vaibhav To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:12:06 -0000 Hi everyone, I'm a potential Google Summer of Code applicant, proposing to work on improving the timecounter performance in the FreeBSD kernel (suggestion from Timecounter Performance Improvements). My qualifications are mentioned at the end of this email, for those interested. After some initial discussion in #freebsd-soc, I'm posting this to the mailing lists (and CC'ing it to specific people) for further discussion before I finalize and submit my application. The primary idea is to improve the performance and resolution of gettimeofday() and friends by creating a efficient userspace implementation of these functions, along with some supporting modifications to the kernel. According to my understanding, currently the gettimeofday() function calls into the kernel to retrieve the timing information to pass on to user apps. I propose to improve it as follows: Export the relevant timing information to a shared page in memory, which will be mapped into every user app's address space. The gettimeofday() function's implementation will then be changed to read the timestamp counter (TSC) from the processor, and use the reading in conjunction with the timing info exported by the kernel to calculate and return the time info in proper format. The TSC can be read very efficiently from userspace (currently this is the fastest and highest resolution timer available, beating HPET, PIT, RTC etc.). This will allow applications to have a very fast and more importantly, a higher resolution timer available to them. This will also pave way for optionally making the FreeBSD kernel tickless, which would help with efficiency and power consumption (the processor will be able to sleep for longer durations without having to service timer interrupts several hundred times a second). Other operating systems (like OS X) already do this to varying extent. There are several issues with this approach however, and I plan to tackle each of them so that there is no loss of functionality or accuracy, and certainly no loss of performance. The project will be completed in stages, tackling each of these issues =E2=80=94 - Implement the exporting of shared system-wide pages to be mapped into each process. (There has been some work done in this area: Avoiding syscall overhead). This page will contain timing info. - Have the kernel read and export the information related to TSC during boot-up. This is heavily processor dependent and each processor (those f= rom Intel/AMD) has its own peculiarities. The kernel should provide at least= the TSC frequency by which the TSC read from userspace can be scaled to get nanosecond time. Wall time offset at boot-time should also be exported s= o TSC can be converted to wall time. - The TSC frequency might change on certain processors with non-constant TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only way= to combat this is that the kernel be notified every time the processor frequency changes. Every cpu frequency driver will need to be updated to notify the kernel before and after a cpu freq change. The tsc frequency = will then need to be adjusted in the exported info. This does not apply to mo= dern processors (Intel Core or higher and recent AMD processors, both of whic= h have a constant tsc rate). - On multiprocessor systems, threads might bounce between different processors. There are two problems here: The TSC of each core could have= an offset relative to each other, and the TSC of each core could have a drifting frequency. The first issue is found on most multicore CPUs, and will be solved by measuring the offset at boot-time and exporting this i= nfo so that the tsc read by the user app can be corrected based on the core = it's running on. The second issue only applies to AMD Athlon X2 during C1 sta= te. This is solved by following AMD's recommendation: disable c1 clock rampi= ng during bootup and suspend/resume by updating relevant info in the northbridge configuration. - In case we have some time left before completion of GSoC, one more thing can be added. Scaling the processor frequency up and down takes a finite amount of time (tens to hundreds of microseconds). During this ti= me, the tsc frequency is undefined. Since we will be notified both before an= d after such a change (by the cpufreq drivers), an alternate source (like = HPET or RTC) can be used to measure this duration and correct the tsc offset after the switch. Given all this is handled carefully, we will be able to use the TSC read-ou= t as either: (1) an offset from the last-updated timestamp (updated HZ times every second, on each timer interrupt). Or (2) use the TSC exclusively for timing and disable the timer interrupt. Currently the first approach will be used. This will avoid having to call into the kernel to get the timing info, as well as provide finer resolution timing. The second approach is an extension to allow for a tickless kernel (not part of my proposal, but do-able in the future). To summarize: The kernel exports a shared page mapped into each process and set as read-only. This page is updated on each clock tick to contain the time. Thi= s page also contains the tsc frequency and other information, which is potentially updated every time this info changes. The userspace implementation of gettimeofday() reads the timestamp counter from the processor, and the scale, offset etc. from the shared page to convert it to nanoseconds. This offset is then added to the last updated nano time (also present in the shared page) and returned to the application. The various peculiarities of each processor's tsc implementation will be accounted for. We will also need to make comprehensive benchmarks and tests to assert the validity and performance benefits. I am not well versed with rigorous benchmarking so this part of the project would need additional thought. My qualifications / personal details: I'm a 22 year old Indian male. I'm an undergrad in Electrical Engineering & Computer Science at Jacobs University Bremen, Germany. I have years of experience in C/C++ and varying job experiences ranging from web developmen= t to human-computer interaction devices. I've taken courses in computer architecture and operating systems. More details will be listed on my application, for now I'll mention the experience most relevant to the task at hand =E2=80=94 Since August 2008, I've started and completed a port of the Darwin XNU kernel (used by OS X), for generic x86 PCs. (Webpage: http://code.google.com/p/xnu-dev) Among other things, I added lots of rtc/tsc improvements to Apple's implementation that deals with exactly the same problems I have described above. All issues were solved, and the kerne= l is being used in production of thousands of computers worldwide (including the computer I'm typing this on!). Most of the code was written by me, with support from a few other people, so I have a fair idea of the challenge and their solutions. The tsc multicore synchronization was written independentl= y by two other people, so this is the part with which I'm least familiar. The code is already implemented for XNU and it works well: so most of the work would be porting it to BSD. Since I'm the author of most of it, and have good contact with the other 3-4 people who contributed other parts, there should be no licensing issues. I've also written a SpeedStep driver for OS = X (http://code.google.com/p/xnu-speedstep), which sends clock recalibration signals to the kernel (also made relevant modifications in the kernel for this to work). What I still need to learn/plan My experience with FreeBSD is somewhat limited. I have a dragonflyBSD based home server (because freebsd didn't have drivers for its cheap ethernet card). My kernel programming experience is also limited to the XNU kernel (since about July last year) and I've helped fix a minor bug (typo in ethernet driver PCI ID) in dfbsd kernel. But I'm a fast learner, and given the very well commented and clear code in the freebsd kernel, I should be u= p to speed pretty soon. Right now I've installed freebsd in a virtual machine and am playing around with it. Will shortly try building the kernel and maybe make small modifications, figure out exactly which parts of the kerne= l will need modifications. I've also been reading the freebsd handbook, the "arch" book and the dev handbook. Another big problem for me would be making the modifications to export the shared page and map it into each process =E2=80=94 my experience is mostly = in handling the tsc/rtc code, but not in memory management, so this is something I need to learn. Lastly, I'm not very well-versed in making rigorous benchmarks. I've done simple benchmarking during the xnu kernel development, but these were limited to measuring clock ticks. A more comprehensive test plan would include mysql benchmarks and similar. Thanks everyone for reading through this humongous email! :-) Discussion commenceth =E2=80=94 Best, Prashant Vaibhav PS: I am out of town with limited connectivity so responses could be somewhat slow. My aim however is to finalize and submit the application by the end of the month. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 13:23:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E05F10656F6 for ; Thu, 26 Mar 2009 13:23:46 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 98A4E8FC1D for ; Thu, 26 Mar 2009 13:23:45 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 43389 invoked by uid 98); 26 Mar 2009 13:23:44 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9169. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.051419 secs); 26 Mar 2009 13:23:44 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 26 Mar 2009 13:23:44 +0000 Received: (qmail 78405 invoked by uid 1002); 26 Mar 2009 13:23:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Mar 2009 13:23:42 -0000 Date: Thu, 26 Mar 2009 13:23:42 +0000 (GMT) From: "Mark Powell" To: Peter Jeremy In-Reply-To: <20090326101303.GJ56137@server.vk2pj.dyndns.org> Message-ID: <20090326132022.W64065@rust.salford.ac.uk> References: <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk> <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> <20090325125930.U73916@rust.salford.ac.uk> <20090325152128.2389990h7v6a02co@webmail.leidinger.net> <20090325152940.GB16409@cicely7.cicely.de> <20090326101303.GJ56137@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , ticso@cicely.de Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:23:46 -0000 On Thu, 26 Mar 2009, Peter Jeremy wrote: > On 2009-Mar-25 16:29:40 +0100, Bernd Walter wrote: >> I wouldn't be surprised if the problem is in the drive firmware. >> Preread and wc both have the potential to put a lot load to the drives >> and can trigger bugs that otherwise wouldn't matter. > > I'll second this. Whilst stress-testing ZFS, I've managed to wedge a > Samsung drive to the point where it needed a power-cycle to recover > (HD103UJ 1AA01112 if anyone wants to know what to avoid). Thanks for the info. I have one of those and was wondering about how it'd perform with zfs. As an aside, do you have any drive recommendations? Or is 'reliable zfs performance on consumer SATA drives' an oxymoron? :( Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 13:24:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BC611065673 for ; Thu, 26 Mar 2009 13:24:27 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id BCA5A8FC36 for ; Thu, 26 Mar 2009 13:24:26 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 80392 invoked from network); 26 Mar 2009 12:57:45 -0000 Received: from unknown (HELO Maya.local) (smtpsend@85.179.6.23) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Mar 2009 12:57:45 -0000 Message-ID: <49CB7BC8.1010905@h3q.com> Date: Thu, 26 Mar 2009 13:57:44 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:24:28 -0000 Hi, is anyone else having problems booting from exported zpools when using gptzfsboot? I have a script creating a GPT partition on a single fresh disk setting up zfs booting etc. http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/create-zfsboot-gpt.sh?format=txt If I export the zpool after the script is done with the setup and try to boot the disk, zfsboot tells me "No ZFS pools located, can't boot". If I just plug out the disk, e.g. USB, or shutdown the system without exporting the zpool on the new disk first, it finds the zpool and boots. My guess is a bug in sys/boot/i386/zfsboot/zfsboot.c somewhere in probe_drive(), not sure if its in the GPT part or somewhere else. greetings, philipp From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 13:32:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE8E10656CB for ; Thu, 26 Mar 2009 13:32:28 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id E82C88FC13 for ; Thu, 26 Mar 2009 13:32:27 +0000 (UTC) (envelope-from cokane@FreeBSD.org) X-CNFS-Analysis: v=1.0 c=1 a=gVCfA2_oDVMA:10 a=usMdJmQPcLUA:10 a=6I5d2MoRAAAA:8 a=ztjJG_qY8k-BGZy_kJcA:9 a=ASsR6DBKhTImce-mt0MA:7 a=lIQbZfy4J5vD2MgligFias7aGMAA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 a=TZC0Apc_AKTO75UW:21 a=UgCUWjxy84_I58sQ:21 a=O7oy8S560ddkV9GCrNAA:9 a=W9wWu0h4Fj9BoZLU7ZH3QYMe0bAA:4 a=2xjD8tdiEJAA:10 a=rwD_jwM4lERby66Dv8UA:9 a=wVdyF9ONcTZP2D4wnJsOpwOZ0jsA:4 a=rPt6xJ-oxjAA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout1 smtp.mail=cokane@FreeBSD.org; spf=softfail Received-SPF: softfail (gwout1: transitional domain FreeBSD.org does not designate 74.215.227.9 as permitted sender) Received: from [74.215.227.9] ([74.215.227.9:50249] helo=mail.cokane.org) by gwout1 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id 12/0D-27669-AE38BC94; Thu, 26 Mar 2009 09:32:27 -0400 Received: from [10.128.128.2] (unknown [10.128.128.2]) by mail.cokane.org (Postfix) with ESMTPSA id 14EB811436; Thu, 26 Mar 2009 10:36:58 -0400 (EDT) From: Coleman Kane To: "Paul B. Mahol" In-Reply-To: <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <1237926289.1735.17.camel@localhost> <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uTDqcNHk7nJPUzN6NM5r" Organization: FreeBSD Project Date: Thu, 26 Mar 2009 09:30:49 -0400 Message-Id: <1238074249.1834.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:32:28 -0000 --=-uTDqcNHk7nJPUzN6NM5r Content-Type: multipart/mixed; boundary="=-STKx1gEJh86K8kqzmQDH" --=-STKx1gEJh86K8kqzmQDH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 01:32 +0100, Paul B. Mahol wrote: > On 3/24/09, Coleman Kane wrote: > > On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote: > >> Robert Noland wrote: > >> > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: > >> > > >> >> Brandon Gooch wrote: > >> >> > >> >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim wr= ote: > >> >>> > >> >>> > >> >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: > >> >>>> > >> >>>> > >> >>>>> Jung-uk Kim wrote: > >> >>>>> > >> >>>>> > >> >>>>>> With popular demands, I will commit the following patch in next > >> >>>>>> few days unless a showstopper is found or "over-my-dead-body" > >> >>>>>> type of review is received. ;-) > >> >>>>>> > >> >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > >> >>>>>> > >> >>>>>> FYI, it was originally posted here: > >> >>>>>> > >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > >> >>>>>> > >> >>>>>> and here: > >> >>>>>> > >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > >> >>>>>> > >> >>>>>> Please read the original threads for more information about the > >> >>>>>> patch. > >> >>>>>> > >> >>>>>> > >> >>>>> Have just retested this with just updated 8-CURRENT. Still works > >> >>>>> fine as before with my Acer TM6292 > >> >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this > >> >>>>> letter just after successful resume. > >> >>>>> > >> >>>>> There is still some DRI resume problems (will try one rnoland@ > >> >>>>> patch tomorrow) and my touch pad does not wakes up for some reas= on, > >> >>>>> but that is probably unrelated. > >> >>>>> > >> >>>>> > >> >>>> I went ahead and committed slightly different version. Please re= sync > >> >>>> the source if you tested the old version. > >> >>>> > >> >>>> Cheers, > >> >>>> > >> >>>> Jung-uk Kim > >> >>>> _______________________________________________ > >> >>>> freebsd-current@freebsd.org mailing list > >> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >>>> To unsubscribe, send any mail to > >> >>>> "freebsd-current-unsubscribe@freebsd.org" > >> >>>> > >> >>>> > >> >>>> > >> >>> > >> >>> > >> >> Hi there, > >> >> > >> >> in my Latitude D630 with 8-0 current updated this morning (+1 UT= C) > >> >> it > >> >> seems is trying to work. It has no xorg, just text console. > >> >> > >> > > >> > The D630 should have an Intel 965GM in it with suspend/resume suppor= t in > >> > drm, so X *should* be good to go. > >> > > >> > robert. > >> > > >> > > >> Hi Roland, > >> > >> this one comes with an nvidia Quadro NVS 135M (I think they made tw= o > >> o three different models). It was possible to customize them via web. = My > >> mistake was to choose an nvidia (well, I've been able to play nice gam= es > >> with it, but now it's giving me a lot of headaches). > >> > >> With this model (without X's, just text console) suspending and > >> resuming seems to work except the video. I can type thing and send the= m > >> to a file (checked). After resuming, it throws a little of text (i can > >> see some debug about suspending and resuming firewire and usb) and the= n > >> video is lost. With if_bge within the kernel I don't get that > >> semi-successful result. It starts complaining about PHY read/write > >> timeout so I have it as a module. > >> > >> Offtopic : In the other hand right now I'm going to try the patch y= ou > >> sent to use nouveau in i386 mode (not amd64, I have a separate partiti= on > >> for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .k= o > >> before leaving to home (and I worked). Will let you now my results in > >> the Take two thread :) > >> > >> Greets, > >> > >> Gus > >> > > > > I've been seeing the exact same problem that you are with the if_bge > > driver (including jkim's earlier patches). Does it do this for anyone > > using i386? I have not been able to make this work for me no matter wha= t > > I try. Have you managed to get if_bge working after a resume? Could I b= e > > CC'd on any patches that might solve this problem in the future? > > > > if_bge has a strange bootstrapping sequence which I think might be core > > to the problem. It seems that you are supposed to write a value to a > > register, then wait for that register to read something else before > > proceeding (yes, I've simplified the actual sequence of steps). This > > process complicates debugging the hardware, and I've been unsuccessful > > in trying to simply kldunload if_bge and then saving/restoring the PCI > > register space before/after suspend/resume... Any insight would be > > helpful. Maybe I should browse the Linux kernel commit logs for this on= e > > and see if it bit them too... > > > > I also see that there is some issue that breaks NDIS on resume as well, > > but I am not sure why at the moment. >=20 > I would say that there is no any real support for NDISulator after > resume. It is NDISulator bug. > Workarodund is to unload module before suspend and load it again after > resume, and device must be in D3 state before suspending > (hw.pci.do_power_nodriver=3D3) >=20 I have this set in my /boot/loader.conf, and I verified that it is still set by running "sysctl hw.pci.do_power_nodriver" after boot. In rc.suspend, I've got (to unload the modules before suspend): kldunload if_bge kldunload ndis kldunload if_ndis I get the exact same behavior (not working) from bge and ndis no matter what I try. I manually re-load the modules after resume, and neither will work. Attached is the dmesg output of bge0 during the process. You can see where the system unloads the driver (detached), and then where I re-load the driver. Any ideas? --=20 Coleman Kane --=-STKx1gEJh86K8kqzmQDH Content-Disposition: attachment; filename="bge-dmesg.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="bge-dmesg.txt"; charset="UTF-8" YmdlMDogPEJyb2FkY29tIEJDTTU3NTQvNTc4NyBBMiwgQVNJQyByZXYuIDB4YjAwMj4gbWVtIDB4 ZDAwMDAwMDAtMHhkMDAwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxNg0KYmdlMDog RXRoZXJuZXQgYWRkcmVzczogMDA6MWE6NGI6NzQ6Mzk6OTYNCmJnZTA6IFtJVEhSRUFEXQ0KYmdl MDogZGV0YWNoZWQNCmJnZTA6IDxCcm9hZGNvbSBCQ001NzU0LzU3ODcgQTIsIEFTSUMgcmV2LiAw eGIwMDI+IG1lbSAweGQwMDAwMDAwLTB4ZDAwMGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24g cGNpMTYNCmJnZTA6IGZpcm13YXJlIGhhbmRzaGFrZSB0aW1lZCBvdXQsIGZvdW5kIDB4NGI2NTc2 NTQNCmJnZTA6IGZpcm13YXJlIGhhbmRzaGFrZSB0aW1lZCBvdXQsIGZvdW5kIDB4NGI2NTc2NTQN CmJnZTA6IFBIWSByZWFkIHRpbWVkIG91dCAocGh5IDEsIHJlZyAxLCB2YWwgMHhmZmZmZmZmZikN CmJnZTA6IFRyeSBhZ2Fpbg0KYmdlMDogUEhZIHdyaXRlIHRpbWVkIG91dCAocGh5IDEsIHJlZyAw LCB2YWwgMzI3NjgpDQpiZ2UwOiBQSFkgcmVhZCB0aW1lZCBvdXQgKHBoeSAxLCByZWcgMSwgdmFs IDB4ZmZmZmZmZmYpDQpiZ2UwOiBUcnkgYWdhaW4NCmJnZTA6IFBIWSB3cml0ZSB0aW1lZCBvdXQg KHBoeSAxLCByZWcgMCwgdmFsIDMyNzY4KQ0KYmdlMDogUEhZIHJlYWQgdGltZWQgb3V0IChwaHkg MSwgcmVnIDEsIHZhbCAweGZmZmZmZmZmKQ0KYmdlMDogVHJ5IGFnYWluDQpiZ2UwOiBQSFkgd3Jp dGUgdGltZWQgb3V0IChwaHkgMSwgcmVnIDAsIHZhbCAzMjc2OCkNCmJnZTA6IFBIWSByZWFkIHRp bWVkIG91dCAocGh5IDEsIHJlZyAxLCB2YWwgMHhmZmZmZmZmZikNCmJnZTA6IFRyeSBhZ2Fpbg0K YmdlMDogUEhZIHdyaXRlIHRpbWVkIG91dCAocGh5IDEsIHJlZyAwLCB2YWwgMzI3NjgpDQpiZ2Uw OiBQSFkgcmVhZCB0aW1lZCBvdXQgKHBoeSAxLCByZWcgMSwgdmFsIDB4ZmZmZmZmZmYpDQpiZ2Uw OiBNSUkgd2l0aG91dCBhbnkgUEhZIQ0K --=-STKx1gEJh86K8kqzmQDH-- --=-uTDqcNHk7nJPUzN6NM5r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAknLg4YACgkQcMSxQcXat5fM/ACfTKnkUWN8I0WcoWZHqmhzkhj1 9VwAniShyMIgZUe/6oXULANNV628ofHG =3jv+ -----END PGP SIGNATURE----- --=-uTDqcNHk7nJPUzN6NM5r-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 14:01:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6121F1065670; Thu, 26 Mar 2009 14:01:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 958218FC14; Thu, 26 Mar 2009 14:01:15 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so542348ewy.43 for ; Thu, 26 Mar 2009 07:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G5pNLR7+BUMbkl8zWHa/1uXSSPswJ1bwXjLVwXBJrfs=; b=b093rQ1TIJ+oMFoO+xO6vRYk7wtYDGvQp1wOciJIg9QEKaQ8fs2EYVQDP2Gf0uOsym yobVz6f+fH+GpzwvK6fvmgoEalGDOerYkB5cqgsAF7ySivIxMqke9yNpo2AQ5RBYckli nUbX3tbh2N3AqrBSb2Bofd+PHYmPgeHxQKGQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mBUUkPLgzHfubG0r7mv4ytsTiEbL0zo7SWrbLHmwLmt2gG4h7mgJPdLwRYEvbWZm7d 1JAplvihs859D5y4hdxpSsU48NKzlEUwLHT15VBJ9nhy/v19rrzyEH7T0pnDHB1qLqTK TNGGt9Alm8LM9CrWICKU3G3xGXkkuvmGR4QqI= MIME-Version: 1.0 Received: by 10.210.34.5 with SMTP id h5mr672498ebh.59.1238076074572; Thu, 26 Mar 2009 07:01:14 -0700 (PDT) In-Reply-To: <1238074249.1834.6.camel@localhost> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <1237926289.1735.17.camel@localhost> <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com> <1238074249.1834.6.camel@localhost> Date: Thu, 26 Mar 2009 15:01:14 +0100 Message-ID: <3a142e750903260701p6d72342bme841c2ff3f64ea95@mail.gmail.com> From: "Paul B. Mahol" To: Coleman Kane Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 14:01:16 -0000 On 3/26/09, Coleman Kane wrote: > On Wed, 2009-03-25 at 01:32 +0100, Paul B. Mahol wrote: >> On 3/24/09, Coleman Kane wrote: >> > On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote: >> >> Robert Noland wrote: >> >> > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote: >> >> > >> >> >> Brandon Gooch wrote: >> >> >> >> >> >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim >> >> >>> wrote: >> >> >>> >> >> >>> >> >> >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote: >> >> >>>> >> >> >>>> >> >> >>>>> Jung-uk Kim wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>>> With popular demands, I will commit the following patch in next >> >> >>>>>> few days unless a showstopper is found or "over-my-dead-body" >> >> >>>>>> type of review is received. ;-) >> >> >>>>>> >> >> >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff >> >> >>>>>> >> >> >>>>>> FYI, it was originally posted here: >> >> >>>>>> >> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim >> >> >>>>>> >> >> >>>>>> and here: >> >> >>>>>> >> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim >> >> >>>>>> >> >> >>>>>> Please read the original threads for more information about the >> >> >>>>>> patch. >> >> >>>>>> >> >> >>>>>> >> >> >>>>> Have just retested this with just updated 8-CURRENT. Still works >> >> >>>>> fine as before with my Acer TM6292 >> >> >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this >> >> >>>>> letter just after successful resume. >> >> >>>>> >> >> >>>>> There is still some DRI resume problems (will try one rnoland@ >> >> >>>>> patch tomorrow) and my touch pad does not wakes up for some >> >> >>>>> reason, >> >> >>>>> but that is probably unrelated. >> >> >>>>> >> >> >>>>> >> >> >>>> I went ahead and committed slightly different version. Please >> >> >>>> resync >> >> >>>> the source if you tested the old version. >> >> >>>> >> >> >>>> Cheers, >> >> >>>> >> >> >>>> Jung-uk Kim >> >> >>>> _______________________________________________ >> >> >>>> freebsd-current@freebsd.org mailing list >> >> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> >>>> To unsubscribe, send any mail to >> >> >>>> "freebsd-current-unsubscribe@freebsd.org" >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> >> >> >> Hi there, >> >> >> >> >> >> in my Latitude D630 with 8-0 current updated this morning (+1 >> >> >> UTC) >> >> >> it >> >> >> seems is trying to work. It has no xorg, just text console. >> >> >> >> >> > >> >> > The D630 should have an Intel 965GM in it with suspend/resume support >> >> > in >> >> > drm, so X *should* be good to go. >> >> > >> >> > robert. >> >> > >> >> > >> >> Hi Roland, >> >> >> >> this one comes with an nvidia Quadro NVS 135M (I think they made two >> >> o three different models). It was possible to customize them via web. >> >> My >> >> mistake was to choose an nvidia (well, I've been able to play nice >> >> games >> >> with it, but now it's giving me a lot of headaches). >> >> >> >> With this model (without X's, just text console) suspending and >> >> resuming seems to work except the video. I can type thing and send them >> >> to a file (checked). After resuming, it throws a little of text (i can >> >> see some debug about suspending and resuming firewire and usb) and then >> >> video is lost. With if_bge within the kernel I don't get that >> >> semi-successful result. It starts complaining about PHY read/write >> >> timeout so I have it as a module. >> >> >> >> Offtopic : In the other hand right now I'm going to try the patch >> >> you >> >> sent to use nouveau in i386 mode (not amd64, I have a separate >> >> partition >> >> for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko >> >> before leaving to home (and I worked). Will let you now my results in >> >> the Take two thread :) >> >> >> >> Greets, >> >> >> >> Gus >> >> >> > >> > I've been seeing the exact same problem that you are with the if_bge >> > driver (including jkim's earlier patches). Does it do this for anyone >> > using i386? I have not been able to make this work for me no matter what >> > I try. Have you managed to get if_bge working after a resume? Could I be >> > CC'd on any patches that might solve this problem in the future? >> > >> > if_bge has a strange bootstrapping sequence which I think might be core >> > to the problem. It seems that you are supposed to write a value to a >> > register, then wait for that register to read something else before >> > proceeding (yes, I've simplified the actual sequence of steps). This >> > process complicates debugging the hardware, and I've been unsuccessful >> > in trying to simply kldunload if_bge and then saving/restoring the PCI >> > register space before/after suspend/resume... Any insight would be >> > helpful. Maybe I should browse the Linux kernel commit logs for this one >> > and see if it bit them too... >> > >> > I also see that there is some issue that breaks NDIS on resume as well, >> > but I am not sure why at the moment. >> >> I would say that there is no any real support for NDISulator after >> resume. It is NDISulator bug. >> Workarodund is to unload module before suspend and load it again after >> resume, and device must be in D3 state before suspending >> (hw.pci.do_power_nodriver=3) >> > > I have this set in my /boot/loader.conf, and I verified that it is still > set by running "sysctl hw.pci.do_power_nodriver" after boot. > > In rc.suspend, I've got (to unload the modules before suspend): > kldunload if_bge > kldunload ndis > kldunload if_ndis > > I get the exact same behavior (not working) from bge and ndis no matter > what I try. I manually re-load the modules after resume, and neither > will work. > > Attached is the dmesg output of bge0 during the process. You can see > where the system unloads the driver (detached), and then where I re-load > the driver. > > Any ideas? In my case I need to load some another kernel device module(the one that resumes correctly ...) otherwise devices without driver attached would not be put back into D3 state. eg, in my case I unload snd_hda and load it again _before_ suspend. With "pciconf -lvc" you can inspect device power states. -- Paul From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 15:09:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5B410656CD for ; Thu, 26 Mar 2009 15:09:02 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 5DDA78FC20 for ; Thu, 26 Mar 2009 15:09:02 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 12479 invoked by uid 60001); 26 Mar 2009 15:09:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238080141; bh=tWHgrIgb6F3Cada6FSsKGpnMRH4keQCLJ+8D6Tg8COg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=dtdPtHbWucFwU3YlcfB55sGpq2etLobDg5n/l+9q6OeE72/2loQrTjKapDJk176bSdfUhhXmWi2j95aSkOaw02n0KsycfqK/eQyU1cFyTS6lr0dcc4VluxfxzIFr7kNawMVyU0cRXb00GCD48vBi5w6ri3lHqBtFGvuGPv9z1Z8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=p7BsIVEL7uhteMRuMtiU2kCgFfIaYODC4Ewc8cuTiRAAM5Kc8ZMtzbS6mAwr+BkwKInxvQleTsPZvAlFO+hsYjhpiwbUtWaxy7Aff/FQxQyuy/w7wJ/T2lsddIVlcbWeFILhLGFEyLKOKDtBe3M4g0kyFHXpyJttpi6QQZdst8I=; Message-ID: <715876.11941.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: PMdBX_QVM1lNCGlXjsb8VdhPGYZiWUAdWdK1xkzAfECR6EYinXWmZbEkZTSZQtSkYvsntMt2a9reRO4zJX.qMpRHaELneZ_i7qqEn7x6QIoqAignBXQHrz5uL5fdxBRJnE5Dtd0fuOMrpsWZGhw1FOIZm8cAItHntIQ8JkLzNvxoyvZmagZ4TrmLFTch5BdeRLVIfZLP1jkeJCM- Received: from [98.242.222.229] by web63902.mail.re1.yahoo.com via HTTP; Thu, 26 Mar 2009 08:09:01 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Thu, 26 Mar 2009 08:09:01 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Alternative to crashdump? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:09:03 -0000 I have a 7.0 server which crashes every now and then and it always seems to happen when its unattended. Also, crashdump doesn't work reliably on the MB, so thats not an option either without a lot of work I don't have time for. Is there a way to get ddb to save the crash trace and then reboot? I just really need to crashpoint and get the trace. Even just the crash point would be very useful. I can't have it drop into the keyboard for half the night, or to reboot and lose the info. Barney From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:08:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9880B106566B for ; Thu, 26 Mar 2009 16:08:11 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 713958FC18 for ; Thu, 26 Mar 2009 16:08:11 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lms7l-0002Rp-PT; Thu, 26 Mar 2009 16:08:09 +0000 Received: from dhcp-17e8.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id A47D949F447; Thu, 26 Mar 2009 09:08:09 -0700 (PDT) Date: Thu, 26 Mar 2009 09:08:09 -0700 Message-ID: From: Randy Bush To: Lyndon Nerenberg In-Reply-To: References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:08:11 -0000 >> tar cjf - . | ssh user@hostb "(cd /desired/path; tar xjf -)" > But I can't get full wire speed with ssh; with rsh I can. you want security? then it costs a bit. the times i want full wire speed are rare. the times i want security are not. randy From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:24:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E2E1065670; Thu, 26 Mar 2009 16:24:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E29178FC0C; Thu, 26 Mar 2009 16:24:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2QGOSDJ053792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 09:24:28 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CBAC3C.600@freebsd.org> Date: Thu, 26 Mar 2009 09:24:28 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Jung-uk Kim References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> <200903251833.14825.jkim@FreeBSD.org> In-Reply-To: <200903251833.14825.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted [more successes] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:24:29 -0000 FWIW I've tried this on 2 amd64 laptops w/ fairly good success. Both are running HEAD as of yesterday and have latest ports builds. Intel T61P (SMP) running gnome2 suspends+resumes with hw.acpi.reset_video=1. I had to restart moused on resume to get the touchpad back but usb did not come back (usbconfig shows the hubs but no devices and devices do not enumerate on re-attach). HP6125 (UP) running kde4 suspends+resumes w/o any tweaks. USB came back on this machine but the touchpad did not (haven't tried restarting moused yet). Some devices didn't restore; e.g. an ath card in the cardbus slot didn't reappear. Great work; this is a huge step forward! Sam From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:27:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C42E81065698 for ; Thu, 26 Mar 2009 16:27:00 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 836148FC1D for ; Thu, 26 Mar 2009 16:27:00 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id 124AE5DA9; Thu, 26 Mar 2009 17:11:08 +0100 (CET) Message-Id: From: Borja Marcos To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 17:10:21 +0100 References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> <790a9fff0903251858w713adf32n85761295e42524d3@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Lyndon Nerenberg , current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:27:01 -0000 On Mar 26, 2009, at 5:08 PM, Randy Bush wrote: >>> tar cjf - . | ssh user@hostb "(cd /desired/path; tar xjf -)" >> But I can't get full wire speed with ssh; with rsh I can. > > you want security? then it costs a bit. the times i want full wire > speed are rare. the times i want security are not. Anyway, I would suggest the original poster to try different encryption algorithms, trying to enable or disable compression... Borja. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:11:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F00106564A for ; Thu, 26 Mar 2009 16:11:56 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id CE7158FC14 for ; Thu, 26 Mar 2009 16:11:56 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 987FF33C62 for ; Thu, 26 Mar 2009 09:11:56 -0700 (PDT) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 3C3DB33C5B for ; Thu, 26 Mar 2009 09:11:56 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18891.43339.915835.806419@already.local> Date: Thu, 26 Mar 2009 09:11:55 -0700 To: freebsd-current@freebsd.org In-Reply-To: <18889.42937.62693.729218@already.local> References: <18889.42937.62693.729218@already.local> X-Mailer: VM 8.0.12 under 22.3.1 (i386-apple-darwin9.6.0) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 26 Mar 2009 16:31:35 +0000 Subject: Re: kernel won't boot after installing from snapshot, csup, then build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:11:57 -0000 George Hartzell writes: > I'm having a problem building up a current system. > > I did a minimal install from the amd64 CURRENT snapshot for 200902, > the csup'ed using the standard-supfile, then did a buildworld, > buildkernel, installkernel and reboot. > > I've been trying this daily for 3-4 days, thinking that maybe their > was a temporary problem. > > I only have one machine (Via VB8001) from which to do the install but > have tried the build and boot on both the VB8001 and a Gigabyte > GA-6KIEH-RH. > > The kernel detects two CPUs, reports the ioapic0, then enters the > debugger with: > > kernel trap 12 with interrupts disabled. > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x3c > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff8056db2f > stack pointer = 0x10:0xffffffff80f81c70 > frame pointer = 0x10:0xffffffff80f81ca0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at devclass_find_internal+0x10f: orl $0x1, 0x3c(%rax) > > There's a photo of the full dump at > > http://shrimp.alerce.com/crash.jpg > > Any ideas what I've done wrong? [following up for posterity] I was told in private mail that: r190417 should fix this. and indeed it did. g. From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:46:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF991065670 for ; Thu, 26 Mar 2009 16:46:20 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id D5AE48FC14 for ; Thu, 26 Mar 2009 16:46:19 +0000 (UTC) (envelope-from buganini@gmail.com) Received: by rv-out-0506.google.com with SMTP id g37so64460rvb.3 for ; Thu, 26 Mar 2009 09:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pZKZDKXhLV+BWv/Zodo1hchvXUJsn1Y89ZOV/LgxbCc=; b=nef3vyS+BziMCvCzX1gO1/BrSIe3mvrIi7i1EsDKUCRWL0hU7BzA0nmVwDS+ts1Af4 afpbNiRsGABCBwnNOI0AyuDt0b9d6W6FIpdyo9JDGRC+AGrtkQuLxQVlIEEKKuL2PW9i /HOQbbWI8aOaRPqpzwNeVti3tcYoOHt8smslE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x/aKun1nIyOLpk3j1504omo+s7wFV+7GaRm9aIFB6RCgsS1PfA+nTnIz+7gZKvy+TD Y6NIjZvoexevcqx27xqT1g/Yl6R23ODWarjPomCK0DEpm/K3mMxJS46ONsseq9+Z5Tux qzLtecqgHhqaxIQUb7qFd6BpJWB+mS6e9OaVA= MIME-Version: 1.0 Received: by 10.141.52.3 with SMTP id e3mr556884rvk.73.1238085979551; Thu, 26 Mar 2009 09:46:19 -0700 (PDT) In-Reply-To: <49CB7BC8.1010905@h3q.com> References: <49CB7BC8.1010905@h3q.com> Date: Thu, 26 Mar 2009 16:46:19 +0000 Message-ID: From: Buganini To: Philipp Wuensche Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:46:20 -0000 It need /boot/zfs/zpool.cache to locate zfs IIRC, and http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system/ export & import zpool to make /boot/zfs/zpool.cache up-to-date, so I guess exporting zpool delete the record in zpool.cache, then it can't locate your zpool. --Buganini From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 16:56:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C401065673 for ; Thu, 26 Mar 2009 16:56:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id CA1548FC1B for ; Thu, 26 Mar 2009 16:56:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2QGtP82037919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 12:55:25 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Michiel Boland In-Reply-To: <49CB70BD.3040607@boland.org> References: <49CB70BD.3040607@boland.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-wxUzqPjpIY/qzvWuR3Q7" Organization: FreeBSD Date: Thu, 26 Mar 2009 11:56:17 -0500 Message-Id: <1238086577.1792.30.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: FreeBSD Current Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:56:58 -0000 --=-wxUzqPjpIY/qzvWuR3Q7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > Hi. I still have problems with a very slow display after logging out of a= n X=20 > session and/or switching VTYs. The problem goes away if I add=20 > hw.pci.enable_msi=3D0 to /boot/loader.conf. >=20 > Last csupped Mar 26 09:49 CET. >=20 > System is Dell optiplex 745. Has built-in Intel Graphics Media Accelerato= r 950 >=20 > Anything I can do to help solve this problem? I'm going to try and work on getting better debugging info from the intel driver. I don't have access to any newer Intel hardware at the moment, so testing is tricky. There is a tuneable for just msi on drm hw.drm.msi. robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-wxUzqPjpIY/qzvWuR3Q7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknLs7EACgkQM4TrQ4qfRON8OgCeL8/L+XtVizLNlI+Ep3fGk6Li bMYAnjYArPLIygtdpk1Rfxa0iIWbiohv =OzxX -----END PGP SIGNATURE----- --=-wxUzqPjpIY/qzvWuR3Q7-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 17:01:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BB1106567C for ; Thu, 26 Mar 2009 17:01:59 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 555BB8FC26 for ; Thu, 26 Mar 2009 17:01:58 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 50062 invoked from network); 26 Mar 2009 17:01:57 -0000 Received: from unknown (HELO Maya.local) (smtpsend@85.179.6.23) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Mar 2009 17:01:57 -0000 Message-ID: <49CBB504.8000004@h3q.com> Date: Thu, 26 Mar 2009 18:01:56 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CB7BC8.1010905@h3q.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Buganini Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:01:59 -0000 Buganini wrote: > It need /boot/zfs/zpool.cache to locate zfs IIRC, > and http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system/ > export & import zpool to make /boot/zfs/zpool.cache up-to-date, > so I guess exporting zpool delete the record in zpool.cache, > then it can't locate your zpool. No, in this state of booting zpool.cache is not used in any way. This problem happens even before the kernel is loaded. An uptodate zpool.cache is not the problem here. greetings, philipp From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 17:04:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9E7C510656C3; Thu, 26 Mar 2009 17:04:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Sam Leffler Date: Thu, 26 Mar 2009 13:04:44 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <200903251833.14825.jkim@FreeBSD.org> <49CBAC3C.600@freebsd.org> In-Reply-To: <49CBAC3C.600@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903261304.47702.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted [more successes] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:04:57 -0000 On Thursday 26 March 2009 12:24 pm, Sam Leffler wrote: > FWIW I've tried this on 2 amd64 laptops w/ fairly good success. > Both are running HEAD as of yesterday and have latest ports builds. > > Intel T61P (SMP) running gnome2 suspends+resumes with > hw.acpi.reset_video=1. I had to restart moused on resume to get > the touchpad back but usb did not come back (usbconfig shows the > hubs but no devices and devices do not enumerate on re-attach). Some touchpads require reinitialization while resuming. See sys/dev/atkbdc/psm.c and look for PSM_CONFIG_HOOKRESUME and PSM_CONFIG_INITAFTERSUSPEND flags and some code arround PSM_RESETAFTERSUSPEND. usb2 stack seems to have resuming issues but I didn't care much about it because the stack itself is a moving target ATM. ;-) > HP6125 (UP) running kde4 suspends+resumes w/o any tweaks. USB came > back on this machine but the touchpad did not (haven't tried > restarting moused yet). Some devices didn't restore; e.g. an ath > card in the cardbus slot didn't reappear. You know who to prod, don't you? :-P > Great work; this is a huge step forward! Thanks for the report! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 17:08:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9B1106566C; Thu, 26 Mar 2009 17:08:26 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id A54278FC1C; Thu, 26 Mar 2009 17:08:26 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2QH8Qql054123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 10:08:26 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CBB689.7020400@freebsd.org> Date: Thu, 26 Mar 2009 10:08:25 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Jung-uk Kim References: <1236802980.00085518.1236789602@10.7.7.3> <200903251833.14825.jkim@FreeBSD.org> <49CBAC3C.600@freebsd.org> <200903261304.47702.jkim@FreeBSD.org> In-Reply-To: <200903261304.47702.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted [more successes] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:08:27 -0000 Jung-uk Kim wrote: > On Thursday 26 March 2009 12:24 pm, Sam Leffler wrote: > >> FWIW I've tried this on 2 amd64 laptops w/ fairly good success. >> Both are running HEAD as of yesterday and have latest ports builds. >> >> Intel T61P (SMP) running gnome2 suspends+resumes with >> hw.acpi.reset_video=1. I had to restart moused on resume to get >> the touchpad back but usb did not come back (usbconfig shows the >> hubs but no devices and devices do not enumerate on re-attach). >> > > Some touchpads require reinitialization while resuming. See > sys/dev/atkbdc/psm.c and look for PSM_CONFIG_HOOKRESUME and > PSM_CONFIG_INITAFTERSUSPEND flags and some code arround > PSM_RESETAFTERSUSPEND. usb2 stack seems to have resuming issues but > I didn't care much about it because the stack itself is a moving > target ATM. ;-) > Right, forgot about those tweaks. I just wish all these little knobs could be captured in some form so users could just say "I've got an xyz laptop" and have the right thing happen instead of having to google for everyone's experimental findings. > >> HP6125 (UP) running kde4 suspends+resumes w/o any tweaks. USB came >> back on this machine but the touchpad did not (haven't tried >> restarting moused yet). Some devices didn't restore; e.g. an ath >> card in the cardbus slot didn't reappear. >> > > You know who to prod, don't you? :-P > Actually ath resumes fine on T4x i386 UP systems for me so I think this more likely cardbus. > >> Great work; this is a huge step forward! >> > > Thanks for the report! > > Jung-uk Kim > > > From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 17:19:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35B95106568D for ; Thu, 26 Mar 2009 17:19:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id D5BF08FC1A for ; Thu, 26 Mar 2009 17:19:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 36349 invoked by uid 60001); 26 Mar 2009 17:19:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238087992; bh=ptxgqhMBcUqwLNKf54+j4YHfv++vZYDqyV0GSOXCSrQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YwmAKFNxFqysxNAivBuQfqyq8kJ3LmkCD1kHzEPlYt+rukvoG/JHjK/EUuqEMTOJdQl2i1Q9v3kGGU15qSDXsVb8cyz8EWPby3naI3Duz/SfWxFuVQy47ZUESMmxjgLC6GPIZ7n7yL3rkQi8/kTG/1u7EQPxIeiuLvhaIqtzIqE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V1jintI7wDZLUmI6ShXM5/t7bdy3tEJACX89qBBWWtmGzuDjNM9LP+9/1yNq9THj1PUrbr11JeI/q89xgB6UeDVFK+v2vuEW51+6NG2xdkmONk70r6dgT+KcLKm4QI/scez8HvbhXREIx3nx0jsSde2wpIeZjPoNwqnuBvnrvRE=; Message-ID: <370833.32038.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: BOFu.E8VM1loGRMFiMKjCJSGblhTIMtqoVT_RAxXORui8HvjG1S0sD3bEtbgPknNTsUwB8OH2e6iJISKZ5yfWEr5D_.12bkkAh..U0THr_e5oCdnpiAJwV634LiASOYlj7aJ20MV1ft62cm4v0_3Iw9pV.y13ovYdW9hzKp73H4G7YPvRU9twKoVJVLEwLn6QAh2g7wyLxApR_aS1ItK1iqnH8Nosw-- Received: from [98.242.222.229] by web63903.mail.re1.yahoo.com via HTTP; Thu, 26 Mar 2009 10:19:51 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Thu, 26 Mar 2009 10:19:51 -0700 (PDT) From: Barney Cordoba To: Robert Watson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:19:57 -0000 --- On Wed, 3/25/09, Robert Watson wrote: > From: Robert Watson > Subject: Re: Telnet root login > To: "Barney Cordoba" > Cc: mail25@bzerk.org, current@freebsd.org > Date: Wednesday, March 25, 2009, 10:17 PM > On Wed, 25 Mar 2009, Barney Cordoba wrote: > > >> morninglightmountain# grep secure /etc/ttys|grep > pts > >> pts/0 none network secure > > > > What tty does it say you are on? You may have the > older stuff. > > > > That setup does not work for me. It was the first > thing I tried. > > > > I'm running 800070 > > On my easily on-hand 800060 box, the secure flag on > pts/0.../10 appeared to > work as expected: with 'secure', I was able to log > in as root using telnet > from localhost; with it removed, I wasn't. I'll > upgrade userspace > tonight/overnight and see if it works with a more recent > userspace. > > Robert N M Watson Ok, I have some critical info here. When I set up ttys with the proper pts/0 setting, I can login are root using login localhost however when telnet in from my iMAC, it doesn't work. It also doesn't give me the "Trying SRA secure login" from the mac. So it seems its using a different authentication when I telnet from the MAC. Barney From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 17:39:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D15551065674; Thu, 26 Mar 2009 17:39:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Sam Leffler Date: Thu, 26 Mar 2009 13:39:28 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <200903261304.47702.jkim@FreeBSD.org> <49CBB689.7020400@freebsd.org> In-Reply-To: <49CBB689.7020400@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903261339.47425.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted [more successes] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:40:01 -0000 On Thursday 26 March 2009 01:08 pm, Sam Leffler wrote: > Jung-uk Kim wrote: > > On Thursday 26 March 2009 12:24 pm, Sam Leffler wrote: > >> FWIW I've tried this on 2 amd64 laptops w/ fairly good success. > >> Both are running HEAD as of yesterday and have latest ports > >> builds. > >> > >> Intel T61P (SMP) running gnome2 suspends+resumes with > >> hw.acpi.reset_video=1. I had to restart moused on resume to get > >> the touchpad back but usb did not come back (usbconfig shows the > >> hubs but no devices and devices do not enumerate on re-attach). > > > > Some touchpads require reinitialization while resuming. See > > sys/dev/atkbdc/psm.c and look for PSM_CONFIG_HOOKRESUME and > > PSM_CONFIG_INITAFTERSUSPEND flags and some code arround > > PSM_RESETAFTERSUSPEND. usb2 stack seems to have resuming issues > > but I didn't care much about it because the stack itself is a > > moving target ATM. ;-) > > Right, forgot about those tweaks. I just wish all these little > knobs could be captured in some form so users could just say "I've > got an xyz laptop" and have the right thing happen instead of > having to google for everyone's experimental findings. Yes, it would be nice. :-( > >> HP6125 (UP) running kde4 suspends+resumes w/o any tweaks. USB > >> came back on this machine but the touchpad did not (haven't > >> tried restarting moused yet). Some devices didn't restore; e.g. > >> an ath card in the cardbus slot didn't reappear. > > > > You know who to prod, don't you? :-P > > Actually ath resumes fine on T4x i386 UP systems for me so I think > this more likely cardbus. That's what I meant, actually. It could be generic PCI driver, too. Sorry for more little tweaks but you may try "hw.pci.do_power_nodriver" and "hw.pci.do_power_resume" tunables. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 18:51:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E555A1065730 for ; Thu, 26 Mar 2009 18:51:03 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC9A8FC14 for ; Thu, 26 Mar 2009 18:51:02 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 78675 invoked from network); 26 Mar 2009 18:51:01 -0000 Received: from unknown (HELO Maya.local) (smtpsend@85.179.6.23) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Mar 2009 18:51:01 -0000 Message-ID: <49CBCE95.4070107@h3q.com> Date: Thu, 26 Mar 2009 19:51:01 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CB7BC8.1010905@h3q.com> In-Reply-To: <49CB7BC8.1010905@h3q.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 18:51:04 -0000 Philipp Wuensche wrote: > Hi, > > is anyone else having problems booting from exported zpools when using > gptzfsboot? > > I have a script creating a GPT partition on a single fresh disk setting > up zfs booting etc. > http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/create-zfsboot-gpt.sh?format=txt > > If I export the zpool after the script is done with the setup and try to > boot the disk, zfsboot tells me "No ZFS pools located, can't boot". If I > just plug out the disk, e.g. USB, or shutdown the system without > exporting the zpool on the new disk first, it finds the zpool and boots. > > My guess is a bug in sys/boot/i386/zfsboot/zfsboot.c somewhere in > probe_drive(), not sure if its in the GPT part or somewhere else. Using gpart list to show the GPT settings on the device, one setting changes from exported to imported zpool, "Mode" changes from r0w0e0 to r1w1e1. Any clues on that? greetings, philipp From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 19:12:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB81106566C for ; Thu, 26 Mar 2009 19:12:08 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0FC8FC13 for ; Thu, 26 Mar 2009 19:12:08 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 15C0D38890; Thu, 26 Mar 2009 20:12:07 +0100 (CET) Date: Thu, 26 Mar 2009 20:12:07 +0100 From: Lars Engels To: Peter Jeremy Message-ID: <20090326191206.GA92358@e.0x20.net> Mail-Followup-To: Lars Engels , Peter Jeremy , Bruce Cran , Dimitry Andric , freebsd-current@freebsd.org References: <49BE7C5A.2080103@icyb.net.ua> <10611.1237233778@critter.freebsd.dk> <20090320074833.67d615e2@gluon> <49C37B75.5060905@andric.com> <20090320191938.25d85caa@gluon> <20090326085449.GB56137@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20090326085449.GB56137@server.vk2pj.dyndns.org> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Bruce Cran , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: ata: printf on every spinup/spindown? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:12:09 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2009 at 07:54:49PM +1100, Peter Jeremy wrote: > On 2009-Mar-20 19:19:38 +0000, Bruce Cran wrote: > >There's a reluctance to include code like this, I > >think because it bypasses the ATA driver and talks directly to the > >drive. Since the driver doesn't know what the drive's been told to do, > >it can't know to adjust timers etc. to wait for the disk to spin back > >up, for example. >=20 > This code is no worse than installing sysutils/ataidle - which also > bypasses the driver. >=20 > As it stands, FreeBSD out-of-the-box behaves in a way that adversely > impacts laptop HDD life - and correcting this requires that the > end-user both be aware of the problem and then find, install and > configure a port to work around this. I am very uncomfortable with > this and would prefer to see the base system require less user > knowledge/intervention. AFAIK ataidle is under the BSD license, so we could include it in the base system. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknL04YACgkQKc512sD3afir+gCfRDEAsm3JVHKxLgZuADAzPj5O UNIAn2tsdnrEvrzVgxv+Z43W5QWL05y4 =L+BM -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 19:29:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 841DF1065670 for ; Thu, 26 Mar 2009 19:29:11 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id BE3938FC18 for ; Thu, 26 Mar 2009 19:29:10 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 88775 invoked from network); 26 Mar 2009 19:29:09 -0000 Received: from unknown (HELO Maya.local) (smtpsend@85.179.6.23) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Mar 2009 19:29:09 -0000 Message-ID: <49CBD785.8050202@h3q.com> Date: Thu, 26 Mar 2009 20:29:09 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CB7BC8.1010905@h3q.com> In-Reply-To: <49CB7BC8.1010905@h3q.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:29:11 -0000 Philipp Wuensche wrote: > Hi, > > is anyone else having problems booting from exported zpools when using > gptzfsboot? > > I have a script creating a GPT partition on a single fresh disk setting > up zfs booting etc. > http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/create-zfsboot-gpt.sh?format=txt > > If I export the zpool after the script is done with the setup and try to > boot the disk, zfsboot tells me "No ZFS pools located, can't boot". If I > just plug out the disk, e.g. USB, or shutdown the system without > exporting the zpool on the new disk first, it finds the zpool and boots. > > My guess is a bug in sys/boot/i386/zfsboot/zfsboot.c somewhere in > probe_drive(), not sure if its in the GPT part or somewhere else. Okay, now I found it right in the zfsimpl.c if (val != POOL_STATE_ACTIVE) { /* * Don't print a message here. If we happen to reboot * while where is an exported pool around, we don't * need a cascade of confusing messages during boot. */ /*printf("ZFS: pool is not active\n");*/ return (EIO); } So it is wanted not to boot from an exported zpool? Why is that so? greetings, philipp From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 19:33:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A4B1065670 for ; Thu, 26 Mar 2009 19:33:00 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE9538FC12 for ; Thu, 26 Mar 2009 19:32:59 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 093EE19017; Thu, 26 Mar 2009 19:32:58 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 19:32:57 +0000 (GMT) Date: Thu, 26 Mar 2009 19:32:36 +0000 From: Bruce Cran To: Lars Engels Message-ID: <20090326193236.090334d1@gluon.draftnet> In-Reply-To: <20090326191206.GA92358@e.0x20.net> References: <49BE7C5A.2080103@icyb.net.ua> <10611.1237233778@critter.freebsd.dk> <20090320074833.67d615e2@gluon> <49C37B75.5060905@andric.com> <20090320191938.25d85caa@gluon> <20090326085449.GB56137@server.vk2pj.dyndns.org> <20090326191206.GA92358@e.0x20.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: ata: printf on every spinup/spindown? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:33:00 -0000 On Thu, 26 Mar 2009 20:12:07 +0100 Lars Engels wrote: > On Thu, Mar 26, 2009 at 07:54:49PM +1100, Peter Jeremy wrote: > > On 2009-Mar-20 19:19:38 +0000, Bruce Cran wrote: > > >There's a reluctance to include code like this, I > > >think because it bypasses the ATA driver and talks directly to the > > >drive. Since the driver doesn't know what the drive's been told to > > >do, it can't know to adjust timers etc. to wait for the disk to > > >spin back up, for example. > > > > This code is no worse than installing sysutils/ataidle - which also > > bypasses the driver. > > > > As it stands, FreeBSD out-of-the-box behaves in a way that adversely > > impacts laptop HDD life - and correcting this requires that the > > end-user both be aware of the problem and then find, install and > > configure a port to work around this. I am very uncomfortable with > > this and would prefer to see the base system require less user > > knowledge/intervention. > > AFAIK ataidle is under the BSD license, so we could include it in the > base system. As the author I can confirm that it is BSD licensed :) Either way - including ataidle or patching atacontrol, I'd like to see a utility to set APM and AAM features at a minimum in the base system because especially with the problems on recent laptops it's something we're missing. I mentioned the reluctance to include code like it because when I initially wrote ataidle I got a bit of resistance about including it, I think from the worry that it would cause problems. There are indeed a few PRs reporting panics when spinning drives back up, but I suspect the driver is more resiliant to those issues now. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 19:54:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 523FC106566B for ; Thu, 26 Mar 2009 19:54:07 +0000 (UTC) (envelope-from popdump@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B4CA88FC1F for ; Thu, 26 Mar 2009 19:54:06 +0000 (UTC) (envelope-from popdump@googlemail.com) Received: by ewy19 with SMTP id 19so713855ewy.43 for ; Thu, 26 Mar 2009 12:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+p+VJHlJ3/k2kK6Ft2M4q6HQxl7AjkCIv5alW2j4qFQ=; b=lHPiyTcVwFc55yodX8KwhLTMZFte5grFOytN/XZFOB+5vpMz6xPvv9RsxKu5KT/WaH 5XtS797i9Wd6FHlFQgm9b2Kzh7ziYewBBupzG8mN4gjanCDTIBK3eGFvYk6DQapB7toF pOergodrz1yk5rF7UfkUU+3YF4hBMC4rAfQew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HxNfttPk5vDpw3I+Z7QYDX0f5B9vHcn80eV2iOgPA34uolMXz3thAFV3cRTRVeAgXE FWtjUKfCjfEKOu40Cr4U4Rk1x26dUPeDRQmpXBxdmUaXu4ORfIJfxErPlQulrJFnqsoH MHFuRgVfyhkINXtWbKKOBceK6reuAP9rJNcsw= MIME-Version: 1.0 Received: by 10.210.41.14 with SMTP id o14mr167036ebo.8.1238097245783; Thu, 26 Mar 2009 12:54:05 -0700 (PDT) In-Reply-To: <6a3f63de0903261211m1a7ccec4m81dbb71e0977fa58@mail.gmail.com> References: <6a3f63de0903261211m1a7ccec4m81dbb71e0977fa58@mail.gmail.com> Date: Thu, 26 Mar 2009 19:54:05 +0000 Message-ID: <6a3f63de0903261254t5cf52343qcf7485e2f54c2ab7@mail.gmail.com> From: Robert Kent To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:54:07 -0000 Hi, I've tried this patch on an Acer Ferrari 1100 (ATI IXP600, AMD tl66, Radeon x1270, bge). =A0It partially works, I have to enable reset_video and be in text mode. =A0However, when it resumes from suspend I get a page fault ('kernel trap 12 with interrupts disabled'). =A0Also, after the error the laptop tries to reboot: the screen goes blank just after 'Stopping CPUs', but then it just reboots multiple times whilst keeping the screen blank until I remove the power and the battery. I've tried using the most minimal amount of modules possible but this doesn't help. =A0I'm currently in the process of recompiling the kernel with debugging turned on. =A0 =A0Is there anything useful that I can provide to help find the cause of this problem? thanks Rob From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 19:54:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65345106564A for ; Thu, 26 Mar 2009 19:54:48 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 076308FC2E for ; Thu, 26 Mar 2009 19:54:48 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 5F46B33CB8; Thu, 26 Mar 2009 21:54:45 +0200 (SAST) Date: Thu, 26 Mar 2009 21:54:45 +0200 From: John Hay To: current@freebsd.org Message-ID: <20090326195445.GA59608@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ath/wlan setting country on same line as other configs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:54:48 -0000 Hi, Should one in -current be able to set the country with the other ath commands? (channel for instance.) I had to split it, to get it to work. wlans_ath0="wlan0" create_args_wlan0="wlanmode adhoc" ifconfig_wlan3="country ZA" ifconfig_wlan3_alias0="ssid ptabb channel 140 bssid 02:01:ca:fe:12:34" John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 20:19:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F82106566B for ; Thu, 26 Mar 2009 20:19:49 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 83C5C8FC25 for ; Thu, 26 Mar 2009 20:19:49 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2QKJmca055668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 13:19:49 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CBE364.8080504@freebsd.org> Date: Thu, 26 Mar 2009 13:19:48 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: John Hay References: <20090326195445.GA59608@zibbi.meraka.csir.co.za> In-Reply-To: <20090326195445.GA59608@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: ath/wlan setting country on same line as other configs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:19:49 -0000 John Hay wrote: > Hi, > > Should one in -current be able to set the country with the other ath > commands? (channel for instance.) I had to split it, to get it to work. > > wlans_ath0="wlan0" > create_args_wlan0="wlanmode adhoc" > ifconfig_wlan3="country ZA" > ifconfig_wlan3_alias0="ssid ptabb channel 140 bssid 02:01:ca:fe:12:34" > It's a bug I haven't addressed. ifconfig needs re-read the channel list from the kernel to get the channel #'s. If you specify the frequency instead it should work. Should be an easy fix if you care to, otherwise filing a PR would help it not be lost. Sam From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 20:46:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D7D106564A for ; Thu, 26 Mar 2009 20:46:25 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from slow2-v.mail.gandi.net (slow2-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id 906118FC15 for ; Thu, 26 Mar 2009 20:46:24 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay3-v.mail.gandi.net (relay3-v.mail.gandi.net [217.70.178.77]) by slow2-v.mail.gandi.net (Postfix) with ESMTP id 81AB621EA83 for ; Thu, 26 Mar 2009 21:26:02 +0100 (CET) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id AD91ABA1B for ; Thu, 26 Mar 2009 21:26:00 +0100 (CET) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 72E1521C3; Thu, 26 Mar 2009 16:25:56 -0400 (EDT) Date: Thu, 26 Mar 2009 16:25:56 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090326202556.GB46908@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C95326.7040504@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: panic in 8.0-CURRENT after svn from r189900 to r190389 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:46:25 -0000 I'm running into a similar problem here, on a Lenovo X200. I've been able to narrow it down to r190100, which removed uscanner(4) from the tree: I've verified this by checking out sources from a few hours ago, reverting r190100 (and, by extension, 190102), and I can now boot with the resulting kernel. I'm not exactly sure how it is this change is causing a panic, though. For reference, here's a snippet of a boot -v on a panicing kernel: ----- ULE: setup cpu 0 ULE: setup cpu 1 ACPI: MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3c fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8056d9df stack pointer = 0x10:0xffffffff80f82c70 frame pointer = 0x10:0xffffffff80f82ca0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at devclass_find_internal+0x10f: orl $0x1,0x3c(%rax) db> bt Tracing pid 0 tid 100000 td 0xffffffff80bb6260 devclass_find_internal() at devclass_find_internal+0x10f driver_module_handler() at driver_module_handler+0xb9 module_register_init() at module_register_init+0x7d mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> ----- Feels more like this change is triggering a problem elsewhere in the kernel. - Damian From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 20:56:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ECB91065673 for ; Thu, 26 Mar 2009 20:56:02 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7E78FC12 for ; Thu, 26 Mar 2009 20:56:02 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 5930F388E2; Thu, 26 Mar 2009 21:56:01 +0100 (CET) Date: Thu, 26 Mar 2009 21:56:01 +0100 From: Lars Engels To: Bruce Cran Message-ID: <20090326205601.GA64269@e.0x20.net> Mail-Followup-To: Lars Engels , Bruce Cran , Peter Jeremy , Dimitry Andric , freebsd-current@freebsd.org References: <49BE7C5A.2080103@icyb.net.ua> <10611.1237233778@critter.freebsd.dk> <20090320074833.67d615e2@gluon> <49C37B75.5060905@andric.com> <20090320191938.25d85caa@gluon> <20090326085449.GB56137@server.vk2pj.dyndns.org> <20090326191206.GA92358@e.0x20.net> <20090326193236.090334d1@gluon.draftnet> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20090326193236.090334d1@gluon.draftnet> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Peter Jeremy , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: ata: printf on every spinup/spindown? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:56:03 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2009 at 07:32:36PM +0000, Bruce Cran wrote: > On Thu, 26 Mar 2009 20:12:07 +0100 > Lars Engels wrote: >=20 > > On Thu, Mar 26, 2009 at 07:54:49PM +1100, Peter Jeremy wrote: > > > On 2009-Mar-20 19:19:38 +0000, Bruce Cran wrote: > > > >There's a reluctance to include code like this, I > > > >think because it bypasses the ATA driver and talks directly to the > > > >drive. Since the driver doesn't know what the drive's been told to > > > >do, it can't know to adjust timers etc. to wait for the disk to > > > >spin back up, for example. > > >=20 > > > This code is no worse than installing sysutils/ataidle - which also > > > bypasses the driver. > > >=20 > > > As it stands, FreeBSD out-of-the-box behaves in a way that adversely > > > impacts laptop HDD life - and correcting this requires that the > > > end-user both be aware of the problem and then find, install and > > > configure a port to work around this. I am very uncomfortable with > > > this and would prefer to see the base system require less user > > > knowledge/intervention. > >=20 > > AFAIK ataidle is under the BSD license, so we could include it in the > > base system. >=20 > As the author I can confirm that it is BSD licensed :) > Either way - including ataidle or patching atacontrol, I'd like to see > a utility to set APM and AAM features at a minimum in the base system > because especially with the problems on recent laptops it's something > we're missing. =20 >=20 > I mentioned the reluctance to include code like it > because when I initially wrote ataidle I got a bit of resistance about > including it, I think from the worry that it would cause problems. > There are indeed a few PRs reporting panics when spinning drives back > up, but I suspect the driver is more resiliant to those issues now. +1 in including it in base and add the according entries to devd.conf (maybe commented, so people don't get any problems). --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknL6+EACgkQKc512sD3afiGtwCgyJGD7jwNonZwFAfhdnQ2sRtF dUIAoIJctFJ5+L0XGpjNXu5XV6jgPNDh =B+ZL -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 21:11:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56AB106568C for ; Thu, 26 Mar 2009 21:11:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A02C08FC27 for ; Thu, 26 Mar 2009 21:11:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4990346B45; Thu, 26 Mar 2009 17:11:07 -0400 (EDT) Date: Thu, 26 Mar 2009 21:11:07 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <715876.11941.qm@web63902.mail.re1.yahoo.com> Message-ID: References: <715876.11941.qm@web63902.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Alternative to crashdump? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:11:09 -0000 On Thu, 26 Mar 2009, Barney Cordoba wrote: > I have a 7.0 server which crashes every now and then and it always seems to > happen when its unattended. Also, crashdump doesn't work reliably on the MB, > so thats not an option either without a lot of work I don't have time for. > > Is there a way to get ddb to save the crash trace and then reboot? I just > really need to crashpoint and get the trace. Even just the crash point would > be very useful. I can't have it drop into the keyboard for half the night, > or to reboot and lose the info. DDB does support dumping only DDB output to disk, which might be more reliable a that writes less data, but I believe that was introduced in 7.1 (textudmp(4)). However, if it's simply a case of the disk controller not working in your crash environment, perhaps because it's involved in the crash, then the usual solution is to attach a serial console via another box and log output. You can use either KDB_UNATTENDED with KDB_TRACE to generate a trace automatically on panic and reboot , or you can use the ddb script environment (also 7.1, I think?) to run sets of DDB commands and automatically reboot. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 21:26:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF02106566C for ; Thu, 26 Mar 2009 21:26:06 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9988FC13 for ; Thu, 26 Mar 2009 21:26:06 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2QLQ3Xx056070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 14:26:03 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CBF2EB.40705@freebsd.org> Date: Thu, 26 Mar 2009 14:26:03 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Damian Gerow References: <20090326202556.GB46908@plebeian.afflictions.org> In-Reply-To: <20090326202556.GB46908@plebeian.afflictions.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: panic in 8.0-CURRENT after svn from r189900 to r190389 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:26:07 -0000 Damian Gerow wrote: > I'm running into a similar problem here, on a Lenovo X200. I've been able > to narrow it down to r190100, which removed uscanner(4) from the tree: > > > > I've verified this by checking out sources from a few hours ago, reverting > r190100 (and, by extension, 190102), and I can now boot with the resulting > kernel. > > I'm not exactly sure how it is this change is causing a panic, though. For > reference, here's a snippet of a boot -v on a panicing kernel: > > ----- > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: > MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 1 > ioapic0: Routing external 8259A's -> intpin0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > wlan: <802.11 Link Layer> > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x3c > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff8056d9df > stack pointer = 0x10:0xffffffff80f82c70 > frame pointer = 0x10:0xffffffff80f82ca0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at devclass_find_internal+0x10f: orl $0x1,0x3c(%rax) > db> bt > Tracing pid 0 tid 100000 td 0xffffffff80bb6260 > devclass_find_internal() at devclass_find_internal+0x10f > driver_module_handler() at driver_module_handler+0xb9 > module_register_init() at module_register_init+0x7d > mi_startup() at mi_startup+0x59 > btext() at btext+0x2c > db> > ----- > > Feels more like this change is triggering a problem elsewhere in the kernel. > Update; the problem has been fixed in r190417. Sam From owner-freebsd-current@FreeBSD.ORG Thu Mar 26 22:36:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE8331065672 for ; Thu, 26 Mar 2009 22:36:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 922BB8FC14 for ; Thu, 26 Mar 2009 22:36:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B699D78D28; Thu, 26 Mar 2009 22:36:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2QLUxv9001171; Thu, 26 Mar 2009 21:30:59 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Mar 2009 18:21:54 +0530." <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> Date: Thu, 26 Mar 2009 21:30:59 +0000 Message-ID: <1170.1238103059@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:36:43 -0000 In message <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com>, Prasha nt Vaibhav writes: >The gettimeofday() function's implementation will then be >changed to read the timestamp counter (TSC) from the processor, and use the >reading in conjunction with the timing info exported by the kernel to >calculate and return the time info in proper format. I take it as read, that you know that there are other relvant functions than gettimeofday() and that these must provide a monotonic timescale when queried interleaved ? Be aware that the TSC may not be, and may not stay synchronized across multiple cores. Further more, the TSC is not constant frequency and in particular not "known frequency" at all times. There are a lot of nasty cases to check, and a nasty interpolation required, which, in my tests some years back, totally negated any speedup from using the TSC in the first place. At the very minimum, you will have to add a quirk table where known good {CPU+MOBO+BIOS} combinations can be entered, as we find them. >This will also pave way for optionally making the >FreeBSD kernel tickless, Rubbish. Timecounters are not even closely associated with the tick or ticklessness of the kernel. [1] > - The TSC frequency might change on certain processors with non-constant > TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only way to > combat this is that the kernel be notified every time the processor > frequency changes. Every cpu frequency driver will need to be updated to > notify the kernel before and after a cpu freq change. That is not good enough, the bios may autonomously change the cpu speed and the skew from not knowing exactly _when_ and _how_ the cpu clock changed, is a significant number of microseconds, plenty of time to make strange things happen. You will want to study carefully Dave Mills work to tame the alpha chips wandering SAW clocks. Poul-Henning [1] In my mind, reworking the callout system in the kernel would be a much better more neded and much more worthwhile project. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 00:03:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D2D61065674; Fri, 27 Mar 2009 00:03:03 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 027348FC1C; Fri, 27 Mar 2009 00:03:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2R01fhH040244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 20:01:41 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> <1238014404.1828.27.camel@balrog.2hip.net> <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HvemGFtbauss/A9uML9B" Organization: FreeBSD Date: Thu, 26 Mar 2009 19:02:32 -0500 Message-Id: <1238112152.1777.6.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:03:04 -0000 --=-HvemGFtbauss/A9uML9B Content-Type: multipart/mixed; boundary="=-V02lBAxAJtiLQxV96XE9" --=-V02lBAxAJtiLQxV96XE9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 18:22 -0500, Brandon Gooch wrote: > On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland wrot= e: > > On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote: > >> On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland = wrote: > >> > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: > >> >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall wrote: > >> >> > Brandon Gooch wrote: > >> >> >> > >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim = wrote: > >> >> >> > >> >> >>> > >> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >> >> >>> > >> >> >>>> > >> >> >>>> The committed version is working well, I am suspending and res= uming > >> >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of = the > >> >> >>>> major things I needed to work so I could run FreeBSD primarily= on > >> >> >>>> my notebook. > >> >> >>>> > >> >> >> > >> >> >> I just finished a kernel build and it seems as though your > >> >> >> recent commits have fixed the clock (at least for me)! > >> >> >> > >> >> >> I feel sorry for all the i386 folks on ACPI notebooks... > >> >> >> > >> >> >> Thanks! > >> >> >> > >> >> >> -Brandon > >> >> >> > >> >> > > >> >> > Picking a semi-random message here.. > >> >> > > >> >> > Thanks for your work on this! In the past (months ago) I tried t= he patch > >> >> > set which didn't work, but the code in -current lets me suspend a= nd resume > >> >> > successfully on my Dell Latitude E6500 (acpiconf -s 3)! I think = this is a > >> >> > first for me, of all the laptops I've had, none have ever been ab= le to > >> >> > suspend and resume in a successful or useful way, and I've been j= ealous of > >> >> > the Thinkpad users that could claim otherwise. I could suspend a= nd resume > >> >> > fine while in the console, then I ran startx and the suspend and = resume > >> >> > worked while I was in X with intel graphics, however my system wa= s slow > >> >> > after that resume. I didn't spend much time looking at it since = I was at > >> >> > work, and I didn't see any obvious reasons for the slowness (cpu = frequency > >> >> > was fine, cx states were C2 or lower (C1), top showed mostly idle= , no > >> >> > evidence of an IRQ storm) yet processes ran fairly sluggish (not = the mouse > >> >> > or typing though). I didn't go back to console, I just shut down= without > >> >> > trying any other situations yet. > >> >> > > >> >> > A tip I want to note for any users who may not have success with = their > >> >> > screen on resume: In the past it seemed to help me to have a pow= er-on > >> >> > password set in my BIOS since the BIOS will turn on the screen on= resume to > >> >> > ask me for my password. I don't know if it is still helping me, = but I've > >> >> > seen in the past where it has. > >> >> > _______________________________________________ > >> >> > freebsd-current@freebsd.org mailing list > >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > >> >> > > >> >> > >> >> The sluggish response in X on Intel video has been an issue the pas= t > >> >> couple of days, triggered by suspend/resume or simply switching to = VTY > >> >> and back. > >> > > >> > I just committed code that should fix this... > >> > > >> > robert. > >> > > >> >> See this thread: > >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/00496= 8.html > >> >> > >> >> Firefox is unusable, but xterms are still usable. I have to reboot = to > >> >> get back to "normal" > >> >> > >> >> -Brandon > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > >> > -- > >> > Robert Noland > >> > FreeBSD > >> > > >> > >> It seems to have helped -- slightly. Firefox is still too laggy when > >> interacting with interface elements (scrollbar, toolbars, menus), and > >> typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to > >> use, perhaps because they're not as graphically intensive :) > >> > >> Also, it seems to have broken the suspend/resume. The machine does > >> wake up, but X is no longer there (I'm at the VTY from which I started > >> X) and I can't switch to another VTY. The machine still "works" for a > >> period, but attempts to switch VTY or enter commands from the keyboard > >> eventually lock it up, resulting in a continuous beep tone and > >> requiring a hard power-off (holding down the power button). > > > > Can you try the attached patch? This was a last minute change that I > > made and I don't know why it seems to be upsetting things so, but it > > looks like it causes things to not shutdown properly. > > > > It looks like it isn't safe to suspend with / on usb2, so I can't reall= y > > test s/r still... > > > > robert. > > > >> -Brandon > > -- > > Robert Noland > > FreeBSD > > >=20 > Applying the patch and rebuilding does get me back to successful > suspend/resume cycle, but the sluggish application weirdness still > persists. >=20 > It's odd, but for brief moment (about a second) after resume, the > screen comes back on as if it has been issued a "DPMS on" (as in say, > vbetool or something), and then it flashes off again, only to come > back on another second later. I assume this has something to do with > resetting or restoring bits some place, but I wondered if this is an > expected behavior. >=20 > BTW, what utility would provide a decent test with quantifiable > results. I feel there may be a better way to help us understand what > is actually causing the symptoms and to pinpoint it in the source for > you. Describing a GTK app as "laggy" or "sluggish" is hardly good > enough :) >=20 > Your thoughts and instruction are welcome! Ok, here is what I would like to do. Apply this patch. This adds some debugging info to sysctl hw.dri.0.vblank, I also added a couple of lines so that we should be able to see what interrupts are enabled and masked. There isn't really a good place to do this at the moment, but we should hit the paths to at least show it. So, apply the patch, before suspending capture hw.dri.0.vblank output, turn on hw.dri.0.debug and suspend. Once you resume, you can turn off hw.dri.0.debug and recapture hw.dri.0.vblank. robert. > -Brandon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-V02lBAxAJtiLQxV96XE9 Content-Disposition: attachment; filename="drm-vblank-intel-debug.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="drm-vblank-intel-debug.patch"; charset="us-ascii" SW5kZXg6IGRldi9kcm0vZHJtX3N5c2N0bC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gZGV2L2RybS9kcm1f c3lzY3RsLmMJKHJldmlzaW9uIDE5MDQwMikNCisrKyBkZXYvZHJtL2RybV9zeXNjdGwuYwkod29y a2luZyBjb3B5KQ0KQEAgLTM4LDYgKzM4LDcgQEANCiBzdGF0aWMgaW50CSAgIGRybV92bV9pbmZv IERSTV9TWVNDVExfSEFORExFUl9BUkdTOw0KIHN0YXRpYyBpbnQJICAgZHJtX2NsaWVudHNfaW5m byBEUk1fU1lTQ1RMX0hBTkRMRVJfQVJHUzsNCiBzdGF0aWMgaW50CSAgIGRybV9idWZzX2luZm8g RFJNX1NZU0NUTF9IQU5ETEVSX0FSR1M7DQorc3RhdGljIGludAkgICBkcm1fdmJsYW5rX2luZm8g RFJNX1NZU0NUTF9IQU5ETEVSX0FSR1M7DQogDQogc3RydWN0IGRybV9zeXNjdGxfbGlzdCB7DQog CWNvbnN0IGNoYXIgKm5hbWU7DQpAQCAtNDcsNiArNDgsNyBAQA0KIAl7InZtIiwJICAgIGRybV92 bV9pbmZvfSwNCiAJeyJjbGllbnRzIiwgZHJtX2NsaWVudHNfaW5mb30sDQogCXsiYnVmcyIsICAg IGRybV9idWZzX2luZm99LA0KKwl7InZibGFuayIsICAgIGRybV92YmxhbmtfaW5mb30sDQogfTsN CiAjZGVmaW5lIERSTV9TWVNDVExfRU5UUklFUyAoc2l6ZW9mKGRybV9zeXNjdGxfbGlzdCkvc2l6 ZW9mKGRybV9zeXNjdGxfbGlzdFswXSkpDQogDQpAQCAtMzEzLDMgKzMxNSwyNSBAQA0KIAlmcmVl KHRlbXBwcml2cywgRFJNX01FTV9EUklWRVIpOw0KIAlyZXR1cm4gcmV0Y29kZTsNCiB9DQorDQor c3RhdGljIGludCBkcm1fdmJsYW5rX2luZm8gRFJNX1NZU0NUTF9IQU5ETEVSX0FSR1MNCit7DQor CXN0cnVjdCBkcm1fZGV2aWNlICpkZXYgPSBhcmcxOw0KKwljaGFyIGJ1ZlsxMjhdOw0KKwlpbnQg cmV0Y29kZTsNCisJaW50IGk7DQorDQorCURSTV9TWVNDVExfUFJJTlQoIlxuY3J0YyByZWYgY291 bnQgICAgbGFzdCAgICAgZW5hYmxlZCBpbm1vZGVzZXRcbiIpOw0KKwlmb3IoaSA9IDAgOyBpIDwg ZGV2LT5udW1fY3J0Y3MgOyBpKyspIHsNCisJCURSTV9TWVNDVExfUFJJTlQoIiAgJTAyZCAgJTAy ZCAlMDhkICUwOGQgJTAyZCAgICAgICUwMmRcbiIsDQorCQkgICAgaSwgYXRvbWljX3JlYWQoJmRl di0+dmJsYW5rW2ldLnJlZmNvdW50KSwNCisJCSAgICBhdG9taWNfcmVhZCgmZGV2LT52Ymxhbmtb aV0uY291bnQpLA0KKwkJICAgIGF0b21pY19yZWFkKCZkZXYtPnZibGFua1tpXS5sYXN0KSwNCisJ CSAgICBhdG9taWNfcmVhZCgmZGV2LT52YmxhbmtbaV0uZW5hYmxlZCksDQorCQkgICAgYXRvbWlj X3JlYWQoJmRldi0+dmJsYW5rW2ldLmlubW9kZXNldCkpOw0KKwl9DQorDQorCVNZU0NUTF9PVVQo cmVxLCAiIiwgLTEpOw0KK2RvbmU6DQorCXJldHVybiByZXRjb2RlOw0KK30NCkluZGV4OiBkZXYv ZHJtL2RybV9pcnEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vZHJtX2lycS5jCShyZXZpc2lv biAxOTA0MzMpDQorKysgZGV2L2RybS9kcm1faXJxLmMJKHdvcmtpbmcgY29weSkNCkBAIC0zNDUs MTMgKzM0NSwxMSBAQA0KIAlzdHJ1Y3QgZHJtX21vZGVzZXRfY3RsICptb2Rlc2V0ID0gZGF0YTsN CiAJaW50IGNydGMsIHJldCA9IDA7DQogDQotCURSTV9ERUJVRygibnVtX2NydGNzPSVkXG4iLCBk ZXYtPm51bV9jcnRjcyk7DQogCS8qIElmIGRybV92YmxhbmtfaW5pdCgpIGhhc24ndCBiZWVuIGNh bGxlZCB5ZXQsIGp1c3Qgbm8tb3AgKi8NCiAJaWYgKCFkZXYtPm51bV9jcnRjcykNCiAJCWdvdG8g b3V0Ow0KIA0KIAljcnRjID0gbW9kZXNldC0+Y3J0YzsNCi0JRFJNX0RFQlVHKCJjcnRjPSVkXG4i LCBjcnRjKTsNCiAJaWYgKGNydGMgPj0gZGV2LT5udW1fY3J0Y3MpIHsNCiAJCXJldCA9IEVJTlZB TDsNCiAJCWdvdG8gb3V0Ow0KQEAgLTM2Niw3ICszNjQsNyBAQA0KIAkgKi8NCiAJc3dpdGNoICht b2Rlc2V0LT5jbWQpIHsNCiAJY2FzZSBfRFJNX1BSRV9NT0RFU0VUOg0KLQkJRFJNX0RFQlVHKCJw cmUtbW9kZXNldFxuIik7DQorCQlEUk1fREVCVUcoInByZS1tb2Rlc2V0LCBjcnRjICVkXG4iLCBj cnRjKTsNCiAJCWlmICghZGV2LT52YmxhbmtbY3J0Y10uaW5tb2Rlc2V0KSB7DQogCQkJZGV2LT52 YmxhbmtbY3J0Y10uaW5tb2Rlc2V0ID0gMHgxOw0KIAkJCWlmIChkcm1fdmJsYW5rX2dldChkZXYs IGNydGMpID09IDApDQpAQCAtMzc0LDcgKzM3Miw3IEBADQogCQl9DQogCQlicmVhazsNCiAJY2Fz ZSBfRFJNX1BPU1RfTU9ERVNFVDoNCi0JCURSTV9ERUJVRygicG9zdC1tb2Rlc2V0XG4iKTsNCisJ CURSTV9ERUJVRygicG9zdC1tb2Rlc2V0LCBjcnRjICVkXG4iLCBjcnRjKTsNCiAJCWlmIChkZXYt PnZibGFua1tjcnRjXS5pbm1vZGVzZXQpIHsNCiAJCQlEUk1fU1BJTkxPQ0soJmRldi0+dmJsX2xv Y2spOw0KIAkJCWRldi0+dmJsYW5rX2Rpc2FibGVfYWxsb3dlZCA9IDE7DQpAQCAtNDc3LDYgKzQ3 NSw5IEBADQogCQkJbXR4X3VubG9jaygmZGV2LT5pcnFfbG9jayk7DQogCQl9DQogDQorCQlpZiAo cmV0ID09IEVXT1VMREJMT0NLKQ0KKwkJCURSTV9FUlJPUigidGltZWQgb3V0IHdhaXRpbmcgb24g dmJsYW5rXG4iKTsNCisNCiAJCWlmIChyZXQgIT0gRUlOVFIgJiYgcmV0ICE9IEVSRVNUQVJUKSB7 DQogCQkJc3RydWN0IHRpbWV2YWwgbm93Ow0KIA0KSW5kZXg6IGRldi9kcm0vaTkxNV9pcnEuYw0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KLS0tIGRldi9kcm0vaTkxNV9pcnEuYwkocmV2aXNpb24gMTkwNDAyKQ0KKysr IGRldi9kcm0vaTkxNV9pcnEuYwkod29ya2luZyBjb3B5KQ0KQEAgLTIwNSw3ICsyMDUsNyBAQA0K IAlpaXIgPSBJOTE1X1JFQUQoSUlSKTsNCiANCiAJaWYgKElTX0k5NjVHKGRldikpIHsNCi0JCXZi bGFua19zdGF0dXMgPSBJOTE1X1NUQVJUX1ZCTEFOS19JTlRFUlJVUFRfU1RBVFVTOw0KKwkJdmJs YW5rX3N0YXR1cyA9IFBJUEVfU1RBUlRfVkJMQU5LX0lOVEVSUlVQVF9TVEFUVVM7DQogCQl2Ymxh bmtfZW5hYmxlID0gUElQRV9TVEFSVF9WQkxBTktfSU5URVJSVVBUX0VOQUJMRTsNCiAJfSBlbHNl IHsNCiAJCXZibGFua19zdGF0dXMgPSBJOTE1X1ZCTEFOS19JTlRFUlJVUFRfU1RBVFVTOw0KQEAg LTM0Myw2ICszNDMsNyBAQA0KIA0KIAlEUk1fREVCVUcoImlycV9ucj0lZCBicmVhZGNydW1iPSVk XG4iLCBpcnFfbnIsDQogCQkgIFJFQURfQlJFQURDUlVNQihkZXZfcHJpdikpOw0KKwlEUk1fREVC VUcoImllcjogJTA4eCwgaW1yOiAlMDh4XG4iLCBJOTE1X1JFQUQoSUVSKSwgSTkxNV9SRUFEKElF UikpOw0KIA0KIAlpOTE1X3VzZXJfaXJxX2dldChkZXYpOw0KIAlEUk1fV0FJVF9PTihyZXQsIGRl dl9wcml2LT5pcnFfcXVldWUsIDMgKiBEUk1fSFosDQo= --=-V02lBAxAJtiLQxV96XE9-- --=-HvemGFtbauss/A9uML9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknMF5gACgkQM4TrQ4qfROOAZACfTN8CukhonbkEpOgcWtb+uuEt dnUAni/P4hmUgZ6U2c01x1qokCfHK3sB =Knd0 -----END PGP SIGNATURE----- --=-HvemGFtbauss/A9uML9B-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 01:26:27 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9306F106564A for ; Fri, 27 Mar 2009 01:26:27 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 5B35A8FC14 for ; Fri, 27 Mar 2009 01:26:27 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2R1Pxoi017553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 18:26:00 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49CC2B14.10408@FreeBSD.org> Date: Thu, 26 Mar 2009 18:25:40 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julian Elischer References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> In-Reply-To: <49CA6754.4030302@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ruben de Groot , Ian FREISLICH , Chuck Robey , current@FreeBSD.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:26:27 -0000 Julian Elischer wrote: >> Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config > > this doesn't work if you are usinf a set of machines run from a central > machine using nc (netcat) to do scripted i/o through a telnet session on > the other machines (for example). > > The advantage of telnet is you can pipe nc straight into it. Dude, ssh with password-less master key on client and correct certificate on server in ~/authorized_keys2 is your friend. You can pipe right to ssh in scripts just fine and it's all nice and secure. You can also do other interesting things with port forwarding over ssl link. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 01:28:39 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B502F1065672 for ; Fri, 27 Mar 2009 01:28:39 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0DC8FC0A for ; Fri, 27 Mar 2009 01:28:39 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2R1SbRK017579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 18:28:38 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49CC2BB1.7080509@FreeBSD.org> Date: Thu, 26 Mar 2009 18:28:17 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lyndon Nerenberg References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CAC20E.3020602@telenix.org> <49CAC8FE.5050708@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:28:40 -0000 Lyndon Nerenberg wrote: >> Oh I know about SSH and keys but teh ability to pipe data into s tcp >> socket and have it fed into another process is really useful in >> testing. and of course no encryption overhead. > > ssh cannot touch rsh for things like 'tar cf - . | rsh hostb tar xf -'. > > On a private network this is a perfectly reasonable thing to do. > > Less dogma and more engineering, please. Wrong. You can do the same 'tar cf - . | ssh hostb tar xf -' just fine either over private network or over internets. With private key or client and public key on server it works just fine. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 01:34:09 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55ECA106564A for ; Fri, 27 Mar 2009 01:34:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 381058FC13 for ; Fri, 27 Mar 2009 01:34:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 46590B9911; Thu, 26 Mar 2009 18:34:10 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2517D2D6021; Thu, 26 Mar 2009 18:34:06 -0700 (PDT) Message-ID: <49CC2D23.5080000@elischer.org> Date: Thu, 26 Mar 2009 18:34:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Maxim Sobolev References: <995845.90009.qm@web63905.mail.re1.yahoo.com> <49CA6754.4030302@elischer.org> <49CC2B14.10408@FreeBSD.org> In-Reply-To: <49CC2B14.10408@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ruben de Groot , Ian FREISLICH , Chuck Robey , current@FreeBSD.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:34:09 -0000 Maxim Sobolev wrote: > Julian Elischer wrote: >>> Then use ssh and set "PermitRootLogin yes" in /etc/ssh/sshd_config >> >> this doesn't work if you are usinf a set of machines run from a >> central machine using nc (netcat) to do scripted i/o through a telnet >> session on the other machines (for example). >> >> The advantage of telnet is you can pipe nc straight into it. > > Dude, ssh with password-less master key on client and correct > certificate on server in ~/authorized_keys2 is your friend. You can pipe > right to ssh in scripts just fine and it's all nice and secure. You can > also do other interesting things with port forwarding over ssl link. I expressed myself poorly I want to pipe straight tcp into sessions for remote control I often use the method you describe above, but sometimes it's just too cumbersom. > > -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 03:11:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B89E106564A for ; Fri, 27 Mar 2009 03:11:18 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id 989938FC16 for ; Fri, 27 Mar 2009 03:11:17 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id n2R3B0HO015975; Fri, 27 Mar 2009 14:11:01 +1100 Message-ID: <49CC43C4.7030905@swin.edu.au> Date: Fri, 27 Mar 2009 14:11:00 +1100 From: Mattia Rossi User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: FreeBSD Current References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> In-Reply-To: <1238086577.1792.30.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michiel Boland , Robert Noland Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 03:11:18 -0000 Robert Noland wrote: > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > >> Hi. I still have problems with a very slow display after logging out of an X >> session and/or switching VTYs. The problem goes away if I add >> hw.pci.enable_msi=0 to /boot/loader.conf. >> >> Last csupped Mar 26 09:49 CET. >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media Accelerator 950 >> >> Anything I can do to help solve this problem? >> > > I'm going to try and work on getting better debugging info from the > intel driver. I don't have access to any newer Intel hardware at the > moment, so testing is tricky. > > There is a tuneable for just msi on drm hw.drm.msi. > > robert. > > Yep, correct - here it is again - just had to log out of KDE, and after logging in again, everything was slow as hell. I didn't fiddle with the msi settings, just rebooted the machine, and everything is fine again. So there must be something that works the first time X is started, but upon restart stuffs up. Like some lock or reference which is not freed. Mat >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 03:16:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC715106566C for ; Fri, 27 Mar 2009 03:16:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 75AB78FC1E for ; Fri, 27 Mar 2009 03:16:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qyk40 with SMTP id 40so1771596qyk.3 for ; Thu, 26 Mar 2009 20:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=7vfoxs1TCddPdryMS3RKUWat2fke5J6+IXu+XL5S4BI=; b=L9ld7815dqHUF0+2KtLMFaTBrfsbZl7HWCJzC5ckvFk3xsqUbH7I+19+eam9kDRIOU icl4/HZttFdxX3dOhxZs5qJrD76OM47zfymX8v8ltsyjtqBs2D1WF+4PhDEgPf+29onL mrYBe+Q7lZ8BUMKRyXz7SBNXjSeKgoGqaqXhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=EH2SyELOYd3W3DuaPDUAcGY9c6ZjN4/5BUk1OKtw+gflGbc7kGVL7FAjoOeU40FNLA ehr5cUmhZXp9LmcZ3GfyrnYZ5+jFgIm/X3YVMDkTG/EkktYPY7xFA7SObBMPQgcjor5e TAnDgta9JRGHg/jEfaiJOR0XdrDInpBRagYGE= Received: by 10.224.80.205 with SMTP id u13mr2177668qak.356.1238123798508; Thu, 26 Mar 2009 20:16:38 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.18.191]) by mx.google.com with ESMTPS id 5sm2813398yxt.14.2009.03.26.20.16.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 20:16:36 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 96641B8074; Fri, 27 Mar 2009 00:16:27 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Fri, 27 Mar 2009 00:16:27 -0300 (BRT) Message-ID: In-Reply-To: <1237884572.1771.28.camel@balrog.2hip.net> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> Date: Fri, 27 Mar 2009 00:16:27 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 03:16:45 -0000 On Tue, March 24, 2009 05:49, Robert Noland wrote: > On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> On Mon, March 23, 2009 07:36, Robert Noland wrote: >> > So I have my i386 install on a usb hard disk, which I can only boot on >> > one machine now. The one machine that I can make work has a bios >> option >> > that reads "BIOS ehci handoff". This used to work with the old usb >> > stack. The machines that it doesn't work on, boot the kernel, but >> fail >> > to mount root, giving me the forbidding mountroot> prompt, which is >> > immediately followed by the message saying that da0 is attached. da0 >> is >> > however not listed in the available boot devices list. I tried >> playing >> > around with the timeout in vfs_mount.c, but that didn't seem to have >> any >> > impact. It has been suggested that this may be a "geom" timeout, but >> I >> > don't know anything about the boot system really. >> >> I had problem a while ago with via mini itx hardware, that was quite >> close. If I try boot from usb (installed in usb hdd), I get to the point >> of loader not finding my disk. >> >> I then used a small flash disk attached to the ata (44 pin ide) channel >> and formatted /boot in there. this way I get to the point of mount root >> you said, and da0 not being alive soon enough to mount root. list disks >> also couldn't find da0 though. >> >> I tried current from that time, and no good. >> >> if this is solved, I'll be happy to try whatever patch to current. (as >> long as I can install it from another box/or its ata channel, as it >> can't >> boot vanilla 7.1R) > > So, my solution was to set kern.cam.scsi_delay=10000 > in /boot/loader.conf with this set, it doesn't even detects the usb disk, just the controller :( thanks, matheus > You can hit 6 from the boot menu and set it manually the first time. > > robert. > >> matheus >> > > -- > Robert Noland > FreeBSD > -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 03:39:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809E51065672; Fri, 27 Mar 2009 03:39:05 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id AB1CC8FC0A; Fri, 27 Mar 2009 03:39:04 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so826098ewy.43 for ; Thu, 26 Mar 2009 20:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n3V1dcASxIBIhP9E9Lu6PP6ybZ25bNcE2t3q9qr7FQA=; b=fKDo0K3rp/R+6YrixLgw+0v7K3hRnJAuNnxBIC3mrLGBj25dYY38Qjbnwxh1OqixF7 ceRTOkrg2hwfrNkBA91HuUncs8Viis0LqkOtbhay45ZeuD/SSE+KRWdcbKZLA1s5lbpq XcdiaCmoCA5zMUhoalLgktinBExKYBpnvJlck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J+aCBjKxp6jbmjHtJHy+3qiwFMKvtn3JC/sZ5Aos66FtqQDSQu1BvcdfLYqa3loCS3 +h0d8EonpbCMZvjLUmn69aNWK33xnkcLc/DQb4mseaxax3uc+0FZjlJG+XeDIKN/of44 IcHcXofzjoL4WjHOCQwVpym2JHWadyO69k0aE= MIME-Version: 1.0 Received: by 10.210.120.7 with SMTP id s7mr461931ebc.69.1238125143800; Thu, 26 Mar 2009 20:39:03 -0700 (PDT) In-Reply-To: <49CC43C4.7030905@swin.edu.au> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> Date: Thu, 26 Mar 2009 22:39:03 -0500 Message-ID: <179b97fb0903262039p4fadd5a1j11555b386d2847df@mail.gmail.com> From: Brandon Gooch To: Mattia Rossi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michiel Boland , FreeBSD Current , Robert Noland Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 03:39:05 -0000 On Thu, Mar 26, 2009 at 10:11 PM, Mattia Rossi wrote: > Robert Noland wrote: >> >> On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: >> >>> >>> Hi. I still have problems with a very slow display after logging out of >>> an X session and/or switching VTYs. The problem goes away if I add >>> hw.pci.enable_msi=3D0 to /boot/loader.conf. >>> >>> Last csupped Mar 26 09:49 CET. >>> >>> System is Dell optiplex 745. Has built-in Intel Graphics Media >>> Accelerator 950 >>> >>> Anything I can do to help solve this problem? >>> >> >> I'm going to try and work on getting better debugging info from the >> intel driver. =A0I don't have access to any newer Intel hardware at the >> moment, so testing is tricky. >> >> There is a tuneable for just msi on drm hw.drm.msi. >> >> robert. >> >> > > Yep, correct - here it is again - just had to log out of KDE, and after > logging in again, everything was slow as hell. > I didn't fiddle with the msi settings, just rebooted the machine, and > everything is fine again. > So there must be something that works the first time X is started, but up= on > restart stuffs up. Like some lock or reference which is not freed. > > Mat I'm working with my system right now with the tunable hw.pci.enable_msi=3D0 (set in /boot/loader.conf) and it's relieved me of this issue for the moment -- a real fix is being researched at the moment by Robert. I haven't had anything break in an obvious way by setting this tunable, but YMMV... -Brandon From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 03:58:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D092106566B for ; Fri, 27 Mar 2009 03:58:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BE8708FC0A for ; Fri, 27 Mar 2009 03:58:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2R3vEaL041310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 23:57:14 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Mattia Rossi In-Reply-To: <49CC43C4.7030905@swin.edu.au> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-POUQPErwlrntyJBebe19" Organization: FreeBSD Date: Thu, 26 Mar 2009 22:58:05 -0500 Message-Id: <1238126285.8491.2.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Michiel Boland , FreeBSD Current Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 03:58:47 -0000 --=-POUQPErwlrntyJBebe19 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: > Robert Noland wrote: > > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > > =20 > >> Hi. I still have problems with a very slow display after logging out o= f an X=20 > >> session and/or switching VTYs. The problem goes away if I add=20 > >> hw.pci.enable_msi=3D0 to /boot/loader.conf. > >> > >> Last csupped Mar 26 09:49 CET. > >> > >> System is Dell optiplex 745. Has built-in Intel Graphics Media Acceler= ator 950 > >> > >> Anything I can do to help solve this problem? > >> =20 > > > > I'm going to try and work on getting better debugging info from the > > intel driver. I don't have access to any newer Intel hardware at the > > moment, so testing is tricky. > > > > There is a tuneable for just msi on drm hw.drm.msi. > > > > robert. > > > > =20 > Yep, correct - here it is again - just had to log out of KDE, and after=20 > logging in again, everything was slow as hell. > I didn't fiddle with the msi settings, just rebooted the machine, and=20 > everything is fine again. > So there must be something that works the first time X is started, but=20 > upon restart stuffs up. Like some lock or reference which is not freed. There is a problem with restarting X on at least some Intel chips... This is a different issue, I was trying to look into that a little bit yesterday, but it kinda works on this 915 that I have, so I haven't isolated what is getting messed up. Again, vt switch, suspend/resume are in the same ballpark, restart is not. robert. > Mat > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > >> =20 >=20 --=20 Robert Noland FreeBSD --=-POUQPErwlrntyJBebe19 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknMTs0ACgkQM4TrQ4qfRONjHwCfQlDrQJy0a+QLmqtewoLjuJYl bygAoIQI42ciW7M7rbxL6Q3J5b11BCo+ =Nbom -----END PGP SIGNATURE----- --=-POUQPErwlrntyJBebe19-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 04:14:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA632106566B; Fri, 27 Mar 2009 04:14:18 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6D38FC14; Fri, 27 Mar 2009 04:14:17 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so175486eyf.7 for ; Thu, 26 Mar 2009 21:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=41te9G8YmlNuP/sPypeJDMaJ0J2zRsOsHPpZw+CmM54=; b=VFY8fTDWat5UIdfmrDNus3YLSOGrrBzNogSeIJyhd0Lbw98H9u35BGPX+cDpdmPEnW vXEsw66lMN5AzAMow99+KtQwq09YgLSCpf3JU+lJLyb35vPNrtfYJ/jvPZ2hqZ6Qv4Sh y/sp5A2zsCq966rH2mCNwCZY2+nGztp/1HqmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N0FxTU6PrLZnaoqiDBsDmf4Vz/rctPxBho/tYFJ821Hj6jv8EqlBkAlbpdKdYunad7 NgWQFHklc4QIUlVzSCJB7Zu9VIZ0Ko3NikLUzSKmFimdXLOG8P6AgRo2jHbwYLk2cGbK U5IBwSbVVlHP5nWV8anxDEH5PIXz7pxGqzPjE= MIME-Version: 1.0 Received: by 10.210.56.9 with SMTP id e9mr1273091eba.49.1238127257030; Thu, 26 Mar 2009 21:14:17 -0700 (PDT) In-Reply-To: <1238126285.8491.2.camel@balrog.2hip.net> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> Date: Thu, 26 Mar 2009 23:14:17 -0500 Message-ID: <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> From: Brandon Gooch To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:14:19 -0000 On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland wrote= : > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: >> Robert Noland wrote: >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: >> > >> >> Hi. I still have problems with a very slow display after logging out = of an X >> >> session and/or switching VTYs. The problem goes away if I add >> >> hw.pci.enable_msi=3D0 to /boot/loader.conf. >> >> >> >> Last csupped Mar 26 09:49 CET. >> >> >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media Accele= rator 950 >> >> >> >> Anything I can do to help solve this problem? >> >> >> > >> > I'm going to try and work on getting better debugging info from the >> > intel driver. =A0I don't have access to any newer Intel hardware at th= e >> > moment, so testing is tricky. >> > >> > There is a tuneable for just msi on drm hw.drm.msi. >> > >> > robert. >> > >> > >> Yep, correct - here it is again - just had to log out of KDE, and after >> logging in again, everything was slow as hell. >> I didn't fiddle with the msi settings, just rebooted the machine, and >> everything is fine again. >> So there must be something that works the first time X is started, but >> upon restart stuffs up. Like some lock or reference which is not freed. > > There is a problem with restarting X on at least some Intel chips... > This is a different issue, I was trying to look into that a little bit > yesterday, but it kinda works on this 915 that I have, so I haven't > isolated what is getting messed up. =A0Again, vt switch, suspend/resume > are in the same ballpark, restart is not. > > robert. > >> Mat >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" >> >> >> > -- > Robert Noland > FreeBSD > I have been switching to the vty at which I started X in order to terminate X. If I try to terminate X while I'm in it, it just "hangs" -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a reboot to get my system back up. IIRC, this started happening after I upgraded to Xorg 7.4. I thought that Mattia might be doing the same thing as a work-around for the freezing intel-driven display thing, thus the X-to-vty switch "fix" of disabling msi... -Brandon From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 04:57:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D61B106564A; Fri, 27 Mar 2009 04:57:53 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo5.cc.swin.edu.au (gpo5.cc.swin.edu.au [136.186.1.34]) by mx1.freebsd.org (Postfix) with ESMTP id 02BAB8FC14; Fri, 27 Mar 2009 04:57:52 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo5.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id n2R4vZ6m014141; Fri, 27 Mar 2009 15:57:37 +1100 Message-ID: <49CC5CBF.3000105@swin.edu.au> Date: Fri, 27 Mar 2009 15:57:35 +1100 From: Mattia Rossi User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: FreeBSD Current References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> In-Reply-To: <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brandon Gooch , Michiel Boland , Robert Noland Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:57:53 -0000 Brandon Gooch wrote: > On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland wrote: > >> On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: >> >>> Robert Noland wrote: >>> >>>> On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: >>>> >>>> >>>>> Hi. I still have problems with a very slow display after logging out of an X >>>>> session and/or switching VTYs. The problem goes away if I add >>>>> hw.pci.enable_msi=0 to /boot/loader.conf. >>>>> >>>>> Last csupped Mar 26 09:49 CET. >>>>> >>>>> System is Dell optiplex 745. Has built-in Intel Graphics Media Accelerator 950 >>>>> >>>>> Anything I can do to help solve this problem? >>>>> >>>>> >>>> I'm going to try and work on getting better debugging info from the >>>> intel driver. I don't have access to any newer Intel hardware at the >>>> moment, so testing is tricky. >>>> >>>> There is a tuneable for just msi on drm hw.drm.msi. >>>> >>>> robert. >>>> >>>> >>>> >>> Yep, correct - here it is again - just had to log out of KDE, and after >>> logging in again, everything was slow as hell. >>> I didn't fiddle with the msi settings, just rebooted the machine, and >>> everything is fine again. >>> So there must be something that works the first time X is started, but >>> upon restart stuffs up. Like some lock or reference which is not freed. >>> >> There is a problem with restarting X on at least some Intel chips... >> This is a different issue, I was trying to look into that a little bit >> yesterday, but it kinda works on this 915 that I have, so I haven't >> isolated what is getting messed up. Again, vt switch, suspend/resume >> are in the same ballpark, restart is not. >> >> robert. >> >> >>> Mat >>> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>> >>>>> >> -- >> Robert Noland >> FreeBSD >> >> > > I have been switching to the vty at which I started X in order to > terminate X. If I try to terminate X while I'm in it, it just "hangs" > -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a > reboot to get my system back up. IIRC, this started happening after I > upgraded to Xorg 7.4. > > I thought that Mattia might be doing the same thing as a work-around > for the freezing intel-driven display thing, thus the X-to-vty switch > "fix" of disabling msi... > > -Brandon Hmm, just tested whether it's vty switching or restarting X that is problematic, and it seems it's both :(. It is not as unusable as it was when I couldn't type anymore, but everything gets definitely very slow after a restart of X or after switching to a vty and back. Didn't try suspend/resume though. The controller says it's a: Intel Q35 SVGA controller. Maybe it's of interest that the machine is a HP Compaq dc7800 Convertible Minitower... Thanks for looking into the problem - tell me if/how i can help with debugging (there are a couple of FreeBSD users with this same canfiguration here which will be very happy about a well working FreeBSD 8 release :-)) Mat From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 06:57:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E3C106566C for ; Fri, 27 Mar 2009 06:57:09 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 48E978FC13 for ; Fri, 27 Mar 2009 06:57:09 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2R6taOd042150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 02:55:36 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-atBWlYA2WXu5JHSlsvNh" Organization: FreeBSD Date: Fri, 27 Mar 2009 01:56:27 -0500 Message-Id: <1238136987.8491.173.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 06:57:09 -0000 --=-atBWlYA2WXu5JHSlsvNh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-03-26 at 23:14 -0500, Brandon Gooch wrote: > On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland wro= te: > > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: > >> Robert Noland wrote: > >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > >> > > >> >> Hi. I still have problems with a very slow display after logging ou= t of an X > >> >> session and/or switching VTYs. The problem goes away if I add > >> >> hw.pci.enable_msi=3D0 to /boot/loader.conf. > >> >> > >> >> Last csupped Mar 26 09:49 CET. > >> >> > >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media Acce= lerator 950 > >> >> > >> >> Anything I can do to help solve this problem? > >> >> > >> > > >> > I'm going to try and work on getting better debugging info from the > >> > intel driver. I don't have access to any newer Intel hardware at th= e > >> > moment, so testing is tricky. > >> > > >> > There is a tuneable for just msi on drm hw.drm.msi. > >> > > >> > robert. > >> > > >> > > >> Yep, correct - here it is again - just had to log out of KDE, and afte= r > >> logging in again, everything was slow as hell. > >> I didn't fiddle with the msi settings, just rebooted the machine, and > >> everything is fine again. > >> So there must be something that works the first time X is started, but > >> upon restart stuffs up. Like some lock or reference which is not freed= . > > > > There is a problem with restarting X on at least some Intel chips... > > This is a different issue, I was trying to look into that a little bit > > yesterday, but it kinda works on this 915 that I have, so I haven't > > isolated what is getting messed up. Again, vt switch, suspend/resume > > are in the same ballpark, restart is not. > > > > robert. > > > >> Mat > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > >> >> > >> > > -- > > Robert Noland > > FreeBSD > > >=20 > I have been switching to the vty at which I started X in order to > terminate X. If I try to terminate X while I'm in it, it just "hangs" > -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a > reboot to get my system back up. IIRC, this started happening after I > upgraded to Xorg 7.4. >=20 > I thought that Mattia might be doing the same thing as a work-around > for the freezing intel-driven display thing, thus the X-to-vty switch > "fix" of disabling msi... Hrm, ok... So, vt switching on the I915 that I'm using to test(which doesn't support msi) works pretty much perfectly. Console is not corrupted, (unless I've restarted X at least once). Shutdown/reboot from gnome also works as expected. I did most of the msi development on an i965gm, which did support msi and vt switch also worked with msi at that time. Restart was problematic on the 965 then as well, which I believed to be an agp, or agp/drm interaction issue. So, unless some of the recent changes other than msi, have broken 965, they should be mostly working ok as long as you don't restart. The g31 and g45 are slightly different and all of my work for those has been based on what Intel has released for linux and the small amount of documentation that is available at this point. BTW, you debug output looks strange to me, did you also capture the drm debug log from hw.dri.0.debug=3D1? robert. > -Brandon --=20 Robert Noland FreeBSD --=-atBWlYA2WXu5JHSlsvNh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknMeJsACgkQM4TrQ4qfRON8RACfdIbtTDMyiaAoc34v6u+NIY/a Y7YAniEXM4GRQxJXQd6IBkITE2nJwbLw =7O3e -----END PGP SIGNATURE----- --=-atBWlYA2WXu5JHSlsvNh-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 07:14:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B011065674; Fri, 27 Mar 2009 07:14:06 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 13CAA8FC25; Fri, 27 Mar 2009 07:14:04 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by ewy19 with SMTP id 19so857867ewy.43 for ; Fri, 27 Mar 2009 00:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=v64FrxBnPr2qQpg8CpItvZlzGE033u/i/zsl88xvhgI=; b=DlcZyASUxADe5ietfgXkgl+hsVPNyYbV18mCL+axhruNAFCX9edhvw/w1UmDqEcoqT yquHR2cdmUozNmHEWIpiN1hvMoI9b+fo6mvcxuKV7MkFdrdG4B7D2smwddikCsBesvpi K8YNN6FDyv9HiELtbyfBOL3akXKjQl/HDH6X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=umLsSyOgVe+wazMG0q14pU/xlOP4NkCiIyiEMVoHA59lc82iHjnjPpsBUSQWRyvIQP fR3zEpTO9vwHrZzt/MCxsshuiqOnrbuhIZfhG9osQOFRmlvCibPzS6gooKvBN1/GmoI8 5bRrPpN4oYyWXw/jMJhWM+B46cEYV/1yZdVHc= MIME-Version: 1.0 Received: by 10.210.76.4 with SMTP id y4mr1406222eba.17.1238138044171; Fri, 27 Mar 2009 00:14:04 -0700 (PDT) In-Reply-To: <1238136987.8491.173.camel@balrog.2hip.net> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> <1238136987.8491.173.camel@balrog.2hip.net> Date: Fri, 27 Mar 2009 02:14:03 -0500 Message-ID: <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> From: Brandon Gooch To: Robert Noland Content-Type: multipart/mixed; boundary=0015174bdf284e47590466147a87 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:14:06 -0000 --0015174bdf284e47590466147a87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 27, 2009 at 1:56 AM, Robert Noland wrote: > On Thu, 2009-03-26 at 23:14 -0500, Brandon Gooch wrote: >> On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland wr= ote: >> > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: >> >> Robert Noland wrote: >> >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: >> >> > >> >> >> Hi. I still have problems with a very slow display after logging o= ut of an X >> >> >> session and/or switching VTYs. The problem goes away if I add >> >> >> hw.pci.enable_msi=3D0 to /boot/loader.conf. >> >> >> >> >> >> Last csupped Mar 26 09:49 CET. >> >> >> >> >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media Acc= elerator 950 >> >> >> >> >> >> Anything I can do to help solve this problem? >> >> >> >> >> > >> >> > I'm going to try and work on getting better debugging info from the >> >> > intel driver. =A0I don't have access to any newer Intel hardware at= the >> >> > moment, so testing is tricky. >> >> > >> >> > There is a tuneable for just msi on drm hw.drm.msi. >> >> > >> >> > robert. >> >> > >> >> > >> >> Yep, correct - here it is again - just had to log out of KDE, and aft= er >> >> logging in again, everything was slow as hell. >> >> I didn't fiddle with the msi settings, just rebooted the machine, and >> >> everything is fine again. >> >> So there must be something that works the first time X is started, bu= t >> >> upon restart stuffs up. Like some lock or reference which is not free= d. >> > >> > There is a problem with restarting X on at least some Intel chips... >> > This is a different issue, I was trying to look into that a little bit >> > yesterday, but it kinda works on this 915 that I have, so I haven't >> > isolated what is getting messed up. =A0Again, vt switch, suspend/resum= e >> > are in the same ballpark, restart is not. >> > >> > robert. >> > >> >> Mat >> >> >> _______________________________________________ >> >> >> freebsd-current@freebsd.org mailing list >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@free= bsd.org" >> >> >> >> >> >> > -- >> > Robert Noland >> > FreeBSD >> > >> >> I have been switching to the vty at which I started X in order to >> terminate X. If I try to terminate X while I'm in it, it just "hangs" >> -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a >> reboot to get my system back up. IIRC, this started happening after I >> upgraded to Xorg 7.4. >> >> I thought that Mattia might be doing the same thing as a work-around >> for the freezing intel-driven display thing, thus the X-to-vty switch >> "fix" of disabling msi... > > Hrm, ok... So, vt switching on the I915 that I'm using to test(which > doesn't support msi) works pretty much perfectly. =A0Console is not > corrupted, (unless I've restarted X at least once). =A0Shutdown/reboot > from gnome also works as expected. > > I did most of the msi development on an i965gm, which did support msi > and vt switch also worked with msi at that time. =A0Restart was > problematic on the 965 then as well, which I believed to be an agp, or > agp/drm interaction issue. =A0So, unless some of the recent changes other > than msi, have broken 965, they should be mostly working ok as long as > you don't restart. > > The g31 and g45 are slightly different and all of my work for those has > been based on what Intel has released for linux and the small amount of > documentation that is available at this point. > > BTW, you debug output looks strange to me, did you also capture the drm > debug log from hw.dri.0.debug=3D1? > > robert. > >> -Brandon > -- > Robert Noland > FreeBSD > I've attached a copy of my /var/log/messages file after enabling hw.dri.0.debug, suspending, and then resuming. I disable it shortly after resume is complete. -Brandon --0015174bdf284e47590466147a87-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 08:00:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F2A810656E2 for ; Fri, 27 Mar 2009 08:00:11 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 003AA8FC25 for ; Fri, 27 Mar 2009 08:00:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2R7wb6G042728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 03:58:38 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> <1238136987.8491.173.camel@balrog.2hip.net> <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CCQG4pzXVicppDRHYc/O" Organization: FreeBSD Date: Fri, 27 Mar 2009 02:59:28 -0500 Message-Id: <1238140768.8491.180.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 08:00:13 -0000 --=-CCQG4pzXVicppDRHYc/O Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-03-27 at 02:14 -0500, Brandon Gooch wrote: > On Fri, Mar 27, 2009 at 1:56 AM, Robert Noland wrot= e: > > On Thu, 2009-03-26 at 23:14 -0500, Brandon Gooch wrote: > >> On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland = wrote: > >> > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: > >> >> Robert Noland wrote: > >> >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > >> >> > > >> >> >> Hi. I still have problems with a very slow display after logging= out of an X > >> >> >> session and/or switching VTYs. The problem goes away if I add > >> >> >> hw.pci.enable_msi=3D0 to /boot/loader.conf. > >> >> >> > >> >> >> Last csupped Mar 26 09:49 CET. > >> >> >> > >> >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media A= ccelerator 950 > >> >> >> > >> >> >> Anything I can do to help solve this problem? > >> >> >> > >> >> > > >> >> > I'm going to try and work on getting better debugging info from t= he > >> >> > intel driver. I don't have access to any newer Intel hardware at= the > >> >> > moment, so testing is tricky. > >> >> > > >> >> > There is a tuneable for just msi on drm hw.drm.msi. > >> >> > > >> >> > robert. > >> >> > > >> >> > > >> >> Yep, correct - here it is again - just had to log out of KDE, and a= fter > >> >> logging in again, everything was slow as hell. > >> >> I didn't fiddle with the msi settings, just rebooted the machine, a= nd > >> >> everything is fine again. > >> >> So there must be something that works the first time X is started, = but > >> >> upon restart stuffs up. Like some lock or reference which is not fr= eed. > >> > > >> > There is a problem with restarting X on at least some Intel chips... > >> > This is a different issue, I was trying to look into that a little b= it > >> > yesterday, but it kinda works on this 915 that I have, so I haven't > >> > isolated what is getting messed up. Again, vt switch, suspend/resum= e > >> > are in the same ballpark, restart is not. > >> > > >> > robert. > >> > > >> >> Mat > >> >> >> _______________________________________________ > >> >> >> freebsd-current@freebsd.org mailing list > >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@fr= eebsd.org" > >> >> >> > >> >> > >> > -- > >> > Robert Noland > >> > FreeBSD > >> > > >> > >> I have been switching to the vty at which I started X in order to > >> terminate X. If I try to terminate X while I'm in it, it just "hangs" > >> -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a > >> reboot to get my system back up. IIRC, this started happening after I > >> upgraded to Xorg 7.4. > >> > >> I thought that Mattia might be doing the same thing as a work-around > >> for the freezing intel-driven display thing, thus the X-to-vty switch > >> "fix" of disabling msi... > > > > Hrm, ok... So, vt switching on the I915 that I'm using to test(which > > doesn't support msi) works pretty much perfectly. Console is not > > corrupted, (unless I've restarted X at least once). Shutdown/reboot > > from gnome also works as expected. > > > > I did most of the msi development on an i965gm, which did support msi > > and vt switch also worked with msi at that time. Restart was > > problematic on the 965 then as well, which I believed to be an agp, or > > agp/drm interaction issue. So, unless some of the recent changes other > > than msi, have broken 965, they should be mostly working ok as long as > > you don't restart. > > > > The g31 and g45 are slightly different and all of my work for those has > > been based on what Intel has released for linux and the small amount of > > documentation that is available at this point. > > > > BTW, you debug output looks strange to me, did you also capture the drm > > debug log from hw.dri.0.debug=3D1? > > > > robert. > > > >> -Brandon > > -- > > Robert Noland > > FreeBSD > > >=20 > I've attached a copy of my /var/log/messages file after enabling > hw.dri.0.debug, suspending, and then resuming. I disable it shortly > after resume is complete. Ok, this is somewhat enlightening... I'll have a closer look tomorrow, but it is most disturbing to see it continuing to render after the suspend call, especially after the interrupt handler is yanked out. robert. > -Brandon --=20 Robert Noland FreeBSD --=-CCQG4pzXVicppDRHYc/O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknMh2AACgkQM4TrQ4qfROOcUgCeJfkLrdviYg1KTDTzKIRYwfME Q7IAnj6LBqoZmkVq81Z6I29P1zIRrQqA =6tvK -----END PGP SIGNATURE----- --=-CCQG4pzXVicppDRHYc/O-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 08:10:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9311106564A for ; Fri, 27 Mar 2009 08:10:01 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 579248FC0A for ; Fri, 27 Mar 2009 08:10:00 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 4so184205eyf.7 for ; Fri, 27 Mar 2009 01:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Wj8MjY7dONGf1RLaSvzHe1AJWGT8a4pw7I/7AzH8P44=; b=Ixe0Le5u96t535sUj3bfD5scxJzABSXEdFx/ey2jMMBiLjFrv1qCCZrFsWbf0APEyO RiE7YDBhAkskQcGRdEYSJv2uqEU1KzPDkFaSRXkeFhA/ik1HgbFhyl3QPVkmdART6Nr5 1neVozHxRlH4043RQMAT5VQsM5NDU2LweTeRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=V/4GFYAW4m9AtCCPSlKfF1qOmD7Tdb1IpV26kdGGJTeiIAfuU/D5siIxHbWhiReHCq yB2Dp65CF+DvVRJ0gcmxmGm/ToYJJqq5HzTDiWqU2Hb9NnOIMbIj5QmE757WmnrnUh0e K/vdJlOzZxiBBcTHMpu4B+MeDyjRpbG0NUYx8= Received: by 10.216.36.79 with SMTP id v57mr696848wea.19.1238141400240; Fri, 27 Mar 2009 01:10:00 -0700 (PDT) Received: from ?131.234.65.166? ([131.234.65.166]) by mx.google.com with ESMTPS id 5sm1585907eyf.12.2009.03.27.01.09.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 01:09:59 -0700 (PDT) Message-ID: <49CC89D6.70408@gmail.com> Date: Fri, 27 Mar 2009 09:09:58 +0100 From: "army.of.root" User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: Marcello Maggioni References: <63f529680903231121i60c7205r5d373215fb7f38b9@mail.gmail.com> In-Reply-To: <63f529680903231121i60c7205r5d373215fb7f38b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Asus EEE PC 1000HE power states : only C1 available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 08:10:02 -0000 Marcello Maggioni wrote: > Hello, > > I've just compiled FREEBSD-CURRENT on my new ASUS EEE PC 1000HE (Intel > ATOM powered) and everything seems to work well as of now (wireless > included), but I have a problem with CX power states. > The Intel Atom processor should have a lot of CX power states, but > only the C1 state is reported in oid "dev.cpu.0.cx_supported" . > > I sent, as an attachment my dmesg log , sysctl -a output and acpidump > -t -d output. > > I have an SMP kernel and it find and use my logical (Hyperthreading) cpu. > > Is this a bug, a problem with SMP kernels (haven't tried UP kernel) or > simply this CPU is not yet supported by FREEBSD acpi? > > Cheers, > Maggioni Marcello Hi, have you tried with HT turned off? (just a guess) And by the way, I am interested in how far CX states higher than C1 are already supported, I know that there are Problems with the old USB Stack and it's polling. Is that solved already? My -STABLE PentiumM Notebook really behaves bad when I enable CX states above C1, but I assume that has changed with this -CURRENT. best regards From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 11:26:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FFC1065673 for ; Fri, 27 Mar 2009 11:26:55 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 130688FC1C for ; Fri, 27 Mar 2009 11:26:53 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id n2RAlOCL018889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 13:47:25 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ln9au-00017J-HN; Fri, 27 Mar 2009 13:47:24 +0300 From: Vladimir Grebenschikov To: freebsd-current Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Fri, 27 Mar 2009 13:47:24 +0300 Message-Id: <1238150844.1666.48.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-net Subject: Crash while disconnecting notebook from dock, network related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 11:26:55 -0000 Hi Recent 8-CURRENT kernel crashes on disconnection notebook from dock station. It happens sometimes. Most probably bug actually related to network stack, on dock disconnect following commands executed: /opt/bin/service netif stop em0; /opt/bin/service netif start ath0 (un-configure em0, configure ath0) all network devices are on board, so they are not disconnected for bus physically. # uname -a FreeBSD vbook 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Wed Mar 18 17:18:28 MSK 2009 root@vbook:/usr/obj/usr/src/sys/VBOOK i386 # kgdb /boot/kernel/kernel /var/crash/vmcore.2 ... Unread portion of the kernel message buffer: panic: sbflush_internal: cc 94 || mb 0 || mbcnt 0 KDB: enter: panic KDB: stack backtrace: Uptime: 3h5m31s Physical memory: 2038 MB Dumping 229 MB: 214 198 182 166 150 134 118 102 86 70 54 38 22 6 ... #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0550573 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05507ad in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc059f58e in sbflush_internal (sb=0xc5681b08) at /usr/src/sys/kern/uipc_sockbuf.c:817 #4 0xc059f661 in sbrelease_internal (sb=0xc5681b08, so=0xc5681ab8) at /usr/src/sys/kern/uipc_sockbuf.c:329 #5 0xc059f6c8 in sbdestroy (sb=0xc5681b08, so=0xc5681ab8) at /usr/src/sys/kern/uipc_sockbuf.c:357 #6 0xc05a0f7a in sofree (so=0xc5681ab8) at /usr/src/sys/kern/uipc_socket.c:623 #7 0xc05a1fe1 in soclose (so=0xc5681ab8) at /usr/src/sys/kern/uipc_socket.c:694 #8 0xc058d669 in soo_close (fp=0xc559a6c8, td=0xc5043880) at /usr/src/sys/kern/sys_socket.c:282 #9 0xc051db13 in _fdrop (fp=0xc559a6c8, td=0xc5043880) at file.h:293 #10 0xc051f008 in closef (fp=0xc559a6c8, td=0xc5043880) at /usr/src/sys/kern/kern_descrip.c:2006 #11 0xc051f4fd in kern_close (td=0xc5043880, fd=10) at /usr/src/sys/kern/kern_descrip.c:1105 #12 0xc051f5da in close (td=0xc5043880, uap=0xe783fcf8) at /usr/src/sys/kern/kern_descrip.c:1057 #13 0xc06bb747 in syscall (frame=0xe783fd38) at /usr/src/sys/i386/i386/trap.c:1066 #14 0xc06a2dd0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 3 #3 0xc059f58e in sbflush_internal (sb=0xc5681b08) at /usr/src/sys/kern/uipc_sockbuf.c:817 817 panic("sbflush_internal: cc %u || mb %p || mbcnt %u", (kgdb) l sbflush_internal 800 /* 801 * Free all mbufs in a sockbuf. Check that all resources are reclaimed. 802 */ 803 static void 804 sbflush_internal(struct sockbuf *sb) 805 { 806 807 while (sb->sb_mbcnt) { 808 /* 809 * Don't call sbdrop(sb, 0) if the leading mbuf is non-empty: (kgdb) 810 * we would loop forever. Panic instead. 811 */ 812 if (!sb->sb_cc && (sb->sb_mb == NULL || sb->sb_mb->m_len)) 813 break; 814 sbdrop_internal(sb, (int)sb->sb_cc); 815 } 816 if (sb->sb_cc || sb->sb_mb || sb->sb_mbcnt) 817 panic("sbflush_internal: cc %u || mb %p || mbcnt %u", 818 sb->sb_cc, (void *)sb->sb_mb, sb->sb_mbcnt); 819 } (kgdb) p sb->sb_cc $1 = 94 (kgdb) p sb->sb_mb $2 = (struct mbuf *) 0x0 (kgdb) p sb->sb_mbcnt $3 = 0 (kgdb) -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 12:09:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 668FD1065674 for ; Fri, 27 Mar 2009 12:09:31 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id B3F0A8FC1E for ; Fri, 27 Mar 2009 12:09:30 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 59855 invoked by uid 98); 27 Mar 2009 12:09:29 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9173. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.041219 secs); 27 Mar 2009 12:09:29 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 27 Mar 2009 12:09:29 +0000 Received: (qmail 71553 invoked by uid 1002); 27 Mar 2009 12:09:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Mar 2009 12:09:27 -0000 Date: Fri, 27 Mar 2009 12:09:27 +0000 (GMT) From: "Mark Powell" To: Rink Springer In-Reply-To: <20090304200007.GB22581@rink.nu> Message-ID: <20090327120620.W66387@rust.salford.ac.uk> References: <200903041834.n24IYrTo011126@cwsys.cwsent.com> <49AED351.4050909@delphij.net> <20090304200007.GB22581@rink.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: Sharing ZFS Zpools and Filesystems Between 7.1-STABLE and 8.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:09:31 -0000 On Wed, 4 Mar 2009, Rink Springer wrote: > One thing to note, if you intend to create zpools / zfs-es on CURRENT > which should be readable on STABLE, you must use the -o version= > parameter to create supported versions, i.e.: > > # zfs create -o version=1 ... > # pool create -o version=6 ... > > This only applies to CURRENT, STABLE doesn't understand the 'version' > parameter and will error out if you use it. I've noticed that 7-STABLE doesn't allow the space char in zfs names, whereas 8-CURRENT does allow spaces in zfs created as version 1. I've not yet had a chance to see if 7 will mount such filesystems. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 12:24:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60E21065689; Fri, 27 Mar 2009 12:24:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2C6C8FC25; Fri, 27 Mar 2009 12:24:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 417FD46B3C; Fri, 27 Mar 2009 08:24:53 -0400 (EDT) Date: Fri, 27 Mar 2009 12:24:53 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Barney Cordoba In-Reply-To: <370833.32038.qm@web63903.mail.re1.yahoo.com> Message-ID: References: <370833.32038.qm@web63903.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mail25@bzerk.org, ed@FreeBSD.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:24:54 -0000 On Thu, 26 Mar 2009, Barney Cordoba wrote: > Ok, I have some critical info here. When I set up ttys with the proper pts/0 > setting, I can login are root using > > login localhost > > however when telnet in from my iMAC, it doesn't work. It also doesn't give > me the "Trying SRA secure login" from the mac. So it seems its using a > different authentication when I telnet from the MAC. Hi Barney (and now also Ed!), This indeed appears to be the key. getttyent(3) appears to properly return the /etc/ttys entry for pts devices, and the TTY_SECURE flag is properly returned. However, pam_securetty isn't using a valid tty name string -- it turns out login, invoked by telnet in the non-SRA case, assumes it can run the following code to get back the tty name: /* * Get current TTY */ ttyn = ttyname(STDIN_FILENO); if (ttyn == NULL || *ttyn == '\0') { (void)snprintf(tname, sizeof(tname), "%s??", _PATH_TTY); ttyn = tname; } if ((tty = strrchr(ttyn, '/')) != NULL) ++tty; else tty = ttyn; The resulting string ("2" in my case) is passed on to PAM as the tty, and then pam_securetty looks that up without any success. Ed, is this something you could take a look at? It's not clear to me if the above logic just needs fixing, or if there are more subtle considerations. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 12:55:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FCA106566C; Fri, 27 Mar 2009 12:55:59 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 869D38FC12; Fri, 27 Mar 2009 12:55:59 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1156025wfg.7 for ; Fri, 27 Mar 2009 05:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NKU9ufi6oZGNDyWWMse+RnGFzJny4MHIj+vXHvP1PTU=; b=omQIkFPLazsAc93UbMtEoLj1KJf9WaTb1WmA3iFb09ObC7LzuI1cEGtACE07t+c7Ln yUjAu5Fr8u97Yd1e0Ljij4joTmLt1J3uFohqRDtJ1y7jiVR2tks2rcPpHcEqT/0AuxdK 4VD8wFcViAk4puZPw30qHHwj9//SqzwPOQ5rI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LV1VXktGNSkPEpAKRohrfhVbb0GHi/idtQKrR4qQnr6CGN/jjQCSajp8ajGVVqXljK StX38EGh1ArKhXrgKC7dNREEfwbN6+8S2ZSjFr5Xk9ynkRR8wX7epCk101JE3/s8sTpG ZebIVpHKiivY90aX96bgODghgXQJSA4PVzPMA= MIME-Version: 1.0 Received: by 10.143.156.12 with SMTP id i12mr880391wfo.320.1238158558726; Fri, 27 Mar 2009 05:55:58 -0700 (PDT) In-Reply-To: <1170.1238103059@critter.freebsd.dk> References: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> <1170.1238103059@critter.freebsd.dk> Date: Fri, 27 Mar 2009 18:25:58 +0530 Message-ID: <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> From: Prashant Vaibhav To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:56:00 -0000 Poul-Henning, Thanks for the feedback! >[...] these must provide a monotonic timescale when queried interleaved > ? Be aware that the TSC may not be, and may not stay synchronized across > multiple cores. The TSC is documented to be monotonically increasing across all x86 processors that implement it (that I'm aware of). I know that the TSC may not stay synchronized across multiple cores *in theory*. Practically, acros= s most processors the only real issue has been an offset in the tsc of cores relative to each other (which can be measured and accounted for), or one core losing some ticks wrt the other during specific sleep states (this can be disabled and is recommended by AMD and Red Hat Linux). >Further more, the TSC is not constant frequency and in particular not > "known frequency" at all times. The TSC is guaranteed to be constant frequency on relatively modern processors from Intel and AMD =E2=80=94 whether the processor we are runnin= g on supports constant TSC rate can be queried via a CPUID instruction. The frequency can be measured at boot time by using another timing source such as the PIT, or read directly off the CPU for some models. >There are a lot of nasty cases to check, I have implemented many such 'nasty checks' over the past several months during my work with the xnu kernel =E2=80=94 I might have missed some, howe= ver. They are all done once during system boot (and during resume from sleep on some AMD dual cores). They're not very involved in my opinion. >and a nasty interpolation required, Could you please elaborate or hint me on some terms I can google about the interpolations that are required? Are you referring to the interpolation needed during measuring the tsc frequency to account for the (weird) duration of PIT? This happens during bootup only. >which, in my tests some years back, totally negated any speedup from using > the TSC in the first place. This could be an issue: I have not made extensive benchmarks. The benefit o= f using TSC could still be: the availability of a higher resolution timer which can be accessed from userspace. >At the very minimum, you will have to add a quirk table where known good > {CPU+MOBO+BIOS} combinations can be entered, as we find them. Perhaps. Or alternatively, a quirk table for known *bad* combinations. In m= y experience, most current x86 processors are OK (tested on Intel Pentium 4 and above, and AMD Athlons and above, with a variety of motherboard/BIOSes)= . >Rubbish. Timecounters are not even closely associated with the tick or > ticklessness of the kernel. My understanding could be flawed here, but the reasoning was: for a tickles kernel, we need some sort of monotonically increasing, known-rate counter a= s a replacement for periodic timer interrupts. Using the TSC (or HPET) would allow us to do so. Unless the alternative is to read the RTC at each call o= f gettimeofday() et al, which itself is not foolproof (eg. the user updates the hardware clock on a running system). I'm not aware of other high-resolution counters on the x86 platform which can serve this purpose. The PIT could be read, but it has too little range (16 bits iirc?) to be useful unless proper wraparound is done. The TSC is 64bits wide and guaranteed not to wrap around for 10 years or more (cf. Intel manuals). >the bios may autonomously change the cpu speed True. This could be an issue. For XNU and the SpeedStep driver we made, we combat this by disabling such BIOS-initiated frequency changes (refer: VoodooPower www.superhai.com/darwin.html ) >not knowing exactly _when_ and _how_ the cpu clock changed, is a > significant number of microseconds, plenty of time to make strange things > happen. Yes, for BIOS-initiated cpu frequency changes. For cpufreq driver-initiated changes, as I mentioned, the kernel can be notified before and after each change, the duration can be timed using an external timer and accounted for= . >You will want to study carefully Dave Mills work to tame the alpha chips > wandering SAW clocks. Will do. I just started reading your paper on timecounters in FreeBSD which has been quite informative! Best, Prashant Vaibhav On Fri, Mar 27, 2009 at 3:00 AM, Poul-Henning Kamp wrot= e: > In message <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com>, > Prasha > nt Vaibhav writes: > > >The gettimeofday() function's implementation will then be > >changed to read the timestamp counter (TSC) from the processor, and use > the > >reading in conjunction with the timing info exported by the kernel to > >calculate and return the time info in proper format. > > I take it as read, that you know that there are other relvant > functions than gettimeofday() and that these must provide a > monotonic timescale when queried interleaved ? > > Be aware that the TSC may not be, and may not stay synchronized > across multiple cores. > > Further more, the TSC is not constant frequency and in particular > not "known frequency" at all times. > > There are a lot of nasty cases to check, and a nasty interpolation > required, which, in my tests some years back, totally negated any > speedup from using the TSC in the first place. > > At the very minimum, you will have to add a quirk table where > known good {CPU+MOBO+BIOS} combinations can be entered, as we > find them. > > >This will also pave way for optionally making the > >FreeBSD kernel tickless, > > Rubbish. Timecounters are not even closely associated with the > tick or ticklessness of the kernel. [1] > > > - The TSC frequency might change on certain processors with > non-constant > > TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only > way to > > combat this is that the kernel be notified every time the processor > > frequency changes. Every cpu frequency driver will need to be updated > to > > notify the kernel before and after a cpu freq change. > > That is not good enough, the bios may autonomously change the cpu speed > and the skew from not knowing exactly _when_ and _how_ the cpu clock > changed, is a significant number of microseconds, plenty of time > to make strange things happen. > > You will want to study carefully Dave Mills work to tame the alpha > chips wandering SAW clocks. > > Poul-Henning > > [1] In my mind, reworking the callout system in the kernel would > be a much better more neded and much more worthwhile project. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 13:02:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B6E106575B for ; Fri, 27 Mar 2009 13:02:17 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id B7D678FC15 for ; Fri, 27 Mar 2009 13:02:16 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 51331 invoked by uid 60001); 27 Mar 2009 13:02:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238158936; bh=gu0JD76wocpw14PMtuFLEDLBTwRB81R5hOpAvRiVetM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TPlYEervrUK1u2XdV/Vgk3xc00u2pg0njrFOaqkAgNo2jAN52kXoXfWYj0Mf9FNsaliAWRCE/H4d/1AtU8anqT4AUjTO6Tpz/e9Ssya2L5SsGsr+WrkQR4q9456fNZzzRB6IhuseA74qDO1QSujFP2z15Z0g4ld/vXR5VGg0QXQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FIEjBQW10/iua+w08RhKU1p1FWldJISnZqWWWUWSKO/+BlXzIQKhsi3XbqPYrB/fH75fTMIoSITGzp03KhK8SQ8fEAeEsjwNhwVpX2qK6Uw+gg5w+KG7ub6bxjj4ts1ludp/YP3AajlsiPNFui5vsaB6jSqRrsTmAV9OWxNY/yE=; Message-ID: <11381.51045.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: AmhcwnwVM1nhwjaV94xUrLe79Ig.fXcO8jba18fc6xTHccV8LWjXOFbmVpozri.bsGnZpUEikX.YyDtEqA11oaN9cY4aou_GRC9LCYbSOBuxTPbLX7g.1YWhogekTxZZrmEezGgp6jsvSc1p39qPaL6EFl.35MsNiJY1_zl28j0Yw3VbhmA5UJ2pQyaJ3iO6n17EdSdS9bv0r1A9VhMVZoeeTs7m37h_3_zjs6i2FVtqXCRAp.kuj4ldFcAc0Ot3WYKoRQk6K_gVvkNViUep Received: from [98.242.222.229] by web63907.mail.re1.yahoo.com via HTTP; Fri, 27 Mar 2009 06:02:15 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 06:02:15 -0700 (PDT) From: Barney Cordoba To: Robert Watson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mail25@bzerk.org, ed@FreeBSD.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:02:20 -0000 --- On Fri, 3/27/09, Robert Watson wrote: > From: Robert Watson > Subject: Re: Telnet root login > To: "Barney Cordoba" > Cc: mail25@bzerk.org, current@freebsd.org, ed@FreeBSD.org > Date: Friday, March 27, 2009, 8:24 AM > On Thu, 26 Mar 2009, Barney Cordoba wrote: > > > Ok, I have some critical info here. When I set up ttys > with the proper pts/0 setting, I can login are root using > > > > login localhost > > > > however when telnet in from my iMAC, it doesn't > work. It also doesn't give me the "Trying SRA > secure login" from the mac. So it seems its using a > different authentication when I telnet from the MAC. > > Hi Barney (and now also Ed!), > > This indeed appears to be the key. getttyent(3) appears to > properly return the /etc/ttys entry for pts devices, and the > TTY_SECURE flag is properly returned. However, > pam_securetty isn't using a valid tty name string -- it > turns out login, invoked by telnet in the non-SRA case, > assumes it can run the following code to get back the tty > name: > > /* > * Get current TTY > */ > ttyn = ttyname(STDIN_FILENO); > if (ttyn == NULL || *ttyn == '\0') { > (void)snprintf(tname, sizeof(tname), > "%s??", _PATH_TTY); > ttyn = tname; > } > if ((tty = strrchr(ttyn, '/')) != NULL) > ++tty; > else > tty = ttyn; > > The resulting string ("2" in my case) is passed > on to PAM as the tty, and then pam_securetty looks that up > without any success. > > Ed, is this something you could take a look at? It's > not clear to me if the above logic just needs fixing, or if > there are more subtle considerations. > > Thanks, aha! So putting 0 none network secure in /etc/ttys works. That also explains why when doing a 'ps -ax' it shows the tty as 0. I also notice that 'who' is empty when logging in via telnet. When logging in with ssh who correctly shows the entry. I don't know if that is related to the invalid terminal name, but its certainly something that needs to be repaired. Barney From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 13:46:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD641065679; Fri, 27 Mar 2009 13:46:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 10A738FC21; Fri, 27 Mar 2009 13:46:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C4A478CCB; Fri, 27 Mar 2009 13:46:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RDk7Lo004956; Fri, 27 Mar 2009 13:46:07 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 18:25:58 +0530." <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> Date: Fri, 27 Mar 2009 13:46:07 +0000 Message-ID: <4955.1238161567@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:46:10 -0000 In message <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com>, Prashant Vaibhav writes: >>[...] these must provide a monotonic timescale when queried interleaved >> ? Be aware that the TSC may not be, and may not stay synchronized across >> multiple cores. > >The TSC is documented to be monotonically increasing [...] Notice the absence of the word "regular" ? That it is "monotonically increasing" just means that it does not count backwards (except on the buggy cpu-revs where it does). It does not mean that it counts upwards at a stable or constant rate. >>Further more, the TSC is not constant frequency and in particular not >> "known frequency" at all times. > >The TSC is guaranteed to be constant frequency on relatively modern >processors from Intel and AMD [...] Which is why you will neeed a {CPU+MOBO+BIOS} table of known good combinations: the majority of systems out there does not guarantee and some of those that do lie. Or have bugs. Or both. >>There are a lot of nasty cases to check, > >They're not very involved in my opinion. Then you likely have not done enough :-) >>and a nasty interpolation required, > >Could you please elaborate or hint me on some terms I can google about the >interpolations that are required? Are you referring to the interpolation >needed during measuring the tsc frequency to account for the (weird) >duration of PIT? This happens during bootup only. I'm talking about the systems where SMM bios operations cause the different CPU's TSC to develop skew over time. >>which, in my tests some years back, totally negated any speedup from using >> the TSC in the first place. > >This could be an issue: I have not made extensive benchmarks. The benefit of >using TSC could still be: the availability of a higher resolution timer >which can be accessed from userspace. We have the same resolution today, if you dare to enable TSC in the kernel. In fact, we have even better resolution, because the "struct bintime" format is much more precise than both timespec and timeval. So far I doubt anybody but me have tried to measure that this makes a difference :-) >>At the very minimum, you will have to add a quirk table where known good >> {CPU+MOBO+BIOS} combinations can be entered, as we find them. > >Perhaps. >Or alternatively, a quirk table for known *bad* combinations. No, FreeBSD is shipped "working by default", not "possibly working" by default and particularly not in an area, where the signs of trouble are so subtle that most people don't recognize them at all and just blame it on "random buggy crap". >>Rubbish. Timecounters are not even closely associated with the tick or > >My understanding could be flawed here, but the reasoning was: for a tickles >kernel, we need some sort of monotonically increasing, known-rate counter as >a replacement for periodic timer interrupts. We already have that in FreeBSD for CPU time accounting. The crucial fact about a tickless kernel, is that it does not take an interrupt N times a second just to see if there is anything to do in the callout queue, but instead uses the hardware timer to aim an interrupt at the next time it needs to wake up. >>the bios may autonomously change the cpu speed > >True. This could be an issue. Your optimism is cute but misguided. On most laptops the bios WILL change the CPU speed without notice in reaction to temperature and battery power. Let me repeat: >> [1] In my mind, reworking the callout system in the kernel would >> be a much better more neded and much more worthwhile project. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 13:53:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60803106566B for ; Fri, 27 Mar 2009 13:53:36 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 2EF428FC16 for ; Fri, 27 Mar 2009 13:53:34 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 90443 invoked by uid 98); 27 Mar 2009 13:53:34 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9174. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.035289 secs); 27 Mar 2009 13:53:34 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 27 Mar 2009 13:53:34 +0000 Received: (qmail 78562 invoked by uid 1002); 27 Mar 2009 13:53:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Mar 2009 13:53:31 -0000 Date: Fri, 27 Mar 2009 13:53:31 +0000 (GMT) From: "Mark Powell" To: Philipp Wuensche In-Reply-To: <49CBD785.8050202@h3q.com> Message-ID: <20090327135218.S66387@rust.salford.ac.uk> References: <49CB7BC8.1010905@h3q.com> <49CBD785.8050202@h3q.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:53:36 -0000 On Thu, 26 Mar 2009, Philipp Wuensche wrote: > So it is wanted not to boot from an exported zpool? Why is that so? I'm not sure 'why'. However, it is in-line with the last line on this page: http://opensolaris.org/os/community/zfs/boot/zfsboot-manual/ Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:00:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33CA410656D3 for ; Fri, 27 Mar 2009 14:00:52 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 77EFF8FC14 for ; Fri, 27 Mar 2009 14:00:51 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 92410 invoked by uid 98); 27 Mar 2009 14:00:49 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9174. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.035207 secs); 27 Mar 2009 14:00:49 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 27 Mar 2009 14:00:49 +0000 Received: (qmail 79081 invoked by uid 1002); 27 Mar 2009 14:00:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Mar 2009 14:00:47 -0000 Date: Fri, 27 Mar 2009 14:00:47 +0000 (GMT) From: "Mark Powell" In-Reply-To: <20090327135218.S66387@rust.salford.ac.uk> Message-ID: <20090327135752.L66387@rust.salford.ac.uk> References: <49CB7BC8.1010905@h3q.com> <49CBD785.8050202@h3q.com> <20090327135218.S66387@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Philipp Wuensche , freebsd-current@freebsd.org Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 14:00:54 -0000 On Fri, 27 Mar 2009, Mark Powell wrote: > On Thu, 26 Mar 2009, Philipp Wuensche wrote: > >> So it is wanted not to boot from an exported zpool? Why is that so? > > I'm not sure 'why'. Perhaps, something to do with why the -f flag exists to zpool import. Actually, this is one of the reasons why I may well just stick with UFS for root. I was hit by this problem a few times whilst experimenting with zfsroot. I don't want to ever pull out that DVD again! :) Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:18:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D3C106566B for ; Fri, 27 Mar 2009 14:18:46 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 50C298FC13 for ; Fri, 27 Mar 2009 14:18:46 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so1562203rvb.43 for ; Fri, 27 Mar 2009 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zWHPPPiLafxNkJQmeYulLRcwtCz3bGoISbIYdKowdMc=; b=JOnyERQKkZ7Z9tZ1iNBzAUbSm21ajd8ovE5tdnHS4jv4oYOt1EQGDYwgziSolu1Zgq RGRRrofroCtv7mX8fvmi1libqUUkdfGqyKLtQA1BCZzlhyHd3tyl3EuJhM/9cHBjcmNq M6rWq2xOIl9oFK/nZw1PykEfcSG9wJv/+OJow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X2x426vLOso2ybXouPE9yTHez642sTATIZN65nZJnFi368wLCDWuiTpM16/3189iLF ZQnBsfAQTcYDTU4zqMqbbFE93HccqRuE2bjLWLz2lW7weR2jDlV3mfkkAw7XzipBMIAc 57EV125S72H45mITo7cMk3ts8U7VzXRFBb+I4= MIME-Version: 1.0 Received: by 10.142.14.18 with SMTP id 18mr911801wfn.304.1238163525979; Fri, 27 Mar 2009 07:18:45 -0700 (PDT) In-Reply-To: <4955.1238161567@critter.freebsd.dk> References: <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> <4955.1238161567@critter.freebsd.dk> Date: Fri, 27 Mar 2009 19:48:45 +0530 Message-ID: <17560ccf0903270718k3688d520y4e1aca30b6aeacdb@mail.gmail.com> From: Prashant Vaibhav To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 14:18:47 -0000 > > >It does not mean that it counts upwards at a stable or constant rate. Right, I see now. >They're not very involved in my opinion. >>Then you likely have not done enough :-) Likely. Most of my ideas are based on empirical evidence so when it worked well during (non rigorous) testing I assumed it's all good. >I'm talking about the systems where SMM bios operations cause the > different CPU's TSC to develop skew over time. Ah, SMM. Out of curiosity though: doesn't that affect regular timer interrupts too (ie. they cannot be delivered if SMM is active)? >We have the same resolution today, if you dare to enable TSC in the kernel. I've noticed, and that is probably why it's limited to uniprocessor systems. >No, FreeBSD is shipped "working by default" Fundamentally different from the xnu stuff! Our goal was 'probably working' on as many non-Apple systems as possible ;-) >The crucial fact about a tickless kernel, is that it [...] uses the > hardware timer to aim an interrupt at the next time it needs to wake up. Thanks. After writing the last email I read about tickless kernels and how Linux handles it and it's clear now. My incorrect idea could probably be termed: 'interruptless kernel' :P >Your optimism is cute but misguided. Of course, I'm a student with limited kernel hacking experience. Hence this email discussion before submitting a proposal. >Let me repeat: [1] In my mind, reworking the callout system in the kernel > would be a much better more neded and much more worthwhile project. Looking into it now. Let's see if I can understand/plan this well enough to draft a good proposal within the next couple of days. Thanks again for the suggestions! Best, Prashant Vaibhav On Fri, Mar 27, 2009 at 7:16 PM, Poul-Henning Kamp wrote: > In message <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com>, > Prashant Vaibhav writes: > > >>[...] these must provide a monotonic timescale when queried interleaved > >> ? Be aware that the TSC may not be, and may not stay synchronized across > >> multiple cores. > > > >The TSC is documented to be monotonically increasing [...] > > Notice the absence of the word "regular" ? > > That it is "monotonically increasing" just means that it does not > count backwards (except on the buggy cpu-revs where it does). It > does not mean that it counts upwards at a stable or constant rate. > > >>Further more, the TSC is not constant frequency and in particular not > >> "known frequency" at all times. > > > >The TSC is guaranteed to be constant frequency on relatively modern > >processors from Intel and AMD [...] > > Which is why you will neeed a {CPU+MOBO+BIOS} table of known good > combinations: the majority of systems out there does not guarantee > and some of those that do lie. Or have bugs. Or both. > > >>There are a lot of nasty cases to check, > > > >They're not very involved in my opinion. > > Then you likely have not done enough :-) > > >>and a nasty interpolation required, > > > >Could you please elaborate or hint me on some terms I can google about the > >interpolations that are required? Are you referring to the interpolation > >needed during measuring the tsc frequency to account for the (weird) > >duration of PIT? This happens during bootup only. > > I'm talking about the systems where SMM bios operations cause the different > CPU's TSC to develop skew over time. > > >>which, in my tests some years back, totally negated any speedup from > using > >> the TSC in the first place. > > > >This could be an issue: I have not made extensive benchmarks. The benefit > of > >using TSC could still be: the availability of a higher resolution timer > >which can be accessed from userspace. > > We have the same resolution today, if you dare to enable TSC in the kernel. > > In fact, we have even better resolution, because the "struct bintime" > format > is much more precise than both timespec and timeval. So far I doubt > anybody > but me have tried to measure that this makes a difference :-) > > >>At the very minimum, you will have to add a quirk table where known good > >> {CPU+MOBO+BIOS} combinations can be entered, as we find them. > > > >Perhaps. > >Or alternatively, a quirk table for known *bad* combinations. > > No, FreeBSD is shipped "working by default", not "possibly working" by > default and particularly not in an area, where the signs of trouble are > so subtle that most people don't recognize them at all and just blame > it on "random buggy crap". > > >>Rubbish. Timecounters are not even closely associated with the tick or > > > >My understanding could be flawed here, but the reasoning was: for a > tickles > >kernel, we need some sort of monotonically increasing, known-rate counter > as > >a replacement for periodic timer interrupts. > > We already have that in FreeBSD for CPU time accounting. > > The crucial fact about a tickless kernel, is that it does not take an > interrupt N times a second just to see if there is anything to do in the > callout queue, but instead uses the hardware timer to aim an interrupt > at the next time it needs to wake up. > > >>the bios may autonomously change the cpu speed > > > >True. This could be an issue. > > Your optimism is cute but misguided. > > On most laptops the bios WILL change the CPU speed without notice > in reaction to temperature and battery power. > > Let me repeat: > > >> [1] In my mind, reworking the callout system in the kernel would > >> be a much better more neded and much more worthwhile project. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:30:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752C0106566C for ; Fri, 27 Mar 2009 14:30:07 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id CF02C8FC17 for ; Fri, 27 Mar 2009 14:30:06 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by fxm11 with SMTP id 11so1009021fxm.43 for ; Fri, 27 Mar 2009 07:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=jpFRvcBOl7vZC0hDyOPH/EA4kPtOLrwm7s2nHkto6Yc=; b=qOmT2BvIAuNIC/wuitAfuRkpa3YWb9NJemrAjnkMDmROg++lsh13LRWVzh1HF+CHjU CEQfAcnJFG/0s9JrVEpvpypKyQPF7BhCihg55Gm90pwcsQsLlmCRmS0RKgQ0W+Cs/ezI 4kcuea3K5dvwBiJKUeUaV8wUULLBXO3Zih0TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=rJF60I22ubeitdu4cnobyaB+idpyPp/eAfQe9y4q3dbSkFfRTpS5WnfeY4Hf8AvkhG CPYNAhyXFzeqMOZ6sUNO+ZWtSKEFYwkCNim5aNS9CfdjzWh35uORppdrFIAZqSFMHFAk F79I5yUNZ2sn9d0qZxfYDDmWzzoVJrXpTfOpw= Received: by 10.103.226.20 with SMTP id d20mr451396mur.8.1238162685681; Fri, 27 Mar 2009 07:04:45 -0700 (PDT) Received: from ?10.30.1.163? (vpn-or.studi-planet.com [78.47.172.52]) by mx.google.com with ESMTPS id 12sm2981584muq.35.2009.03.27.07.04.44 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 07:04:45 -0700 (PDT) From: Mister Olli To: freebsd-xen@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain Date: Fri, 27 Mar 2009 15:03:22 +0100 Message-Id: <1238162602.24399.29.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Cc: Subject: Compiling CURRENT with XEN config fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 14:30:07 -0000 Hi, I just tried to compile CURRENT kernel with the XEN kernel config that is shipped with it, but it fails with the following error: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/xen/evtchn/evtchn.c /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) *** Error code 1 Stop in /usr/obj/usr/src/sys/XEN. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. template-8_CURRENT# svn info http://svn.freebsd.org/base/head /usr/src Path: head URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 190466 Node Kind: directory Last Changed Author: jamie Last Changed Rev: 190466 Last Changed Date: 2009-03-27 14:13:59 +0100 (Fri, 27 Mar 2009) Path: /usr/src URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 190464 Node Kind: directory Schedule: normal Last Changed Author: dds Last Changed Rev: 190464 Last Changed Date: 2009-03-27 12:03:02 +0100 (Fri, 27 Mar 2009) Anybody knows how to fix this??? ;-)) greetz Olli From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:32:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A63106564A for ; Fri, 27 Mar 2009 14:32:32 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id BBAD68FC15 for ; Fri, 27 Mar 2009 14:32:32 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1194227wfg.7 for ; Fri, 27 Mar 2009 07:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IooPuzI9uJ5jBfXDw2ZSnIg/vvBX9oAj9NBllEW9diE=; b=qAZhXsade+SzAja3pHgVLdgAj544BCcnAGAd1YRFZRIgriVYZOXG4ca1D73KLPIC8r AqFp0cXs4XSBX5jUjXWPKQWewHBC9xbs77NAtX3ScDWI5c+2zxvD5xZQ3OlcAuD0VDfq I4e7EusmOOhAXt8HkmhxqBy0IpWUbfn86rCjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O+SAfJaaMvJHPBhbjFLEUJEjTC34u7UTttzQ5V3Y3uMwt5TSljHW0GGIqmyG6A02Qh znubj6D5lmTU5xV5I0cMX1Uazct0Cpf2PZGYgr1QvAEqxJaS8YTkrR6h04JDbJfSZLt5 cFdcZ9uX1oUDFUE7aN74QHXNPOYFldB1qsbmA= MIME-Version: 1.0 Received: by 10.142.242.8 with SMTP id p8mr934097wfh.60.1238164352344; Fri, 27 Mar 2009 07:32:32 -0700 (PDT) In-Reply-To: <49CCDD7D.FA83BF14@kuzbass.ru> References: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> <49CCDD7D.FA83BF14@kuzbass.ru> Date: Fri, 27 Mar 2009 20:02:32 +0530 Message-ID: <17560ccf0903270732x23970ad4j42c81511a97a1ce8@mail.gmail.com> From: Prashant Vaibhav To: Eugene Grosbein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 14:32:33 -0000 Eugene, No I am not. Looking at it now. I'm not familiar with a lot of things specific to the freebsd kernel actually, but familiar with tsc/timing stuff in general and xnu in particular. After seeing this in the gsoc ideas list I decided to apply, assuming it would map well to freebsd too. Best, Prashant 2009/3/27 Eugene Grosbein > Prashant Vaibhav wrote: > > > The primary idea is to improve the performance and resolution of > > gettimeofday() and friends by creating a efficient userspace > implementation > > of these functions, along with some supporting modifications to the > kernel. > > Are you aware of CLOCK_*_FAST family of timecounters present > in FreeBSD 7.x? If not, you may want to take a look: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/time.h#rev1.71 > > Eugene Grosbein > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 15:04:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81AD81065676 for ; Fri, 27 Mar 2009 15:04:07 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id B72C58FC0A for ; Fri, 27 Mar 2009 15:04:06 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 98003 invoked from network); 27 Mar 2009 15:04:04 -0000 Received: from unknown (HELO Maya.local) (smtpsend@85.179.158.149) by mail.h3q.com with AES256-SHA encrypted SMTP; 27 Mar 2009 15:04:04 -0000 Message-ID: <49CCEAE3.5060804@h3q.com> Date: Fri, 27 Mar 2009 16:04:03 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CB7BC8.1010905@h3q.com> <49CBD785.8050202@h3q.com> <20090327135218.S66387@rust.salford.ac.uk> <20090327135752.L66387@rust.salford.ac.uk> In-Reply-To: <20090327135752.L66387@rust.salford.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Powell Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:04:08 -0000 Mark Powell wrote: > On Fri, 27 Mar 2009, Mark Powell wrote: > >> On Thu, 26 Mar 2009, Philipp Wuensche wrote: >> >>> So it is wanted not to boot from an exported zpool? Why is that so? >> >> I'm not sure 'why'. > > Perhaps, something to do with why the -f flag exists to zpool import. > Actually, this is one of the reasons why I may well just stick with > UFS for root. I was hit by this problem a few times whilst experimenting > with zfsroot. I don't want to ever pull out that DVD again! :) I tried booting from the exported zpool and it works with a patches zfsimpl.c as far as booting the kernel goes. Mounting the rootfs does not work, because the zpool.cache and the zpool think differently about what state they are in. The import -f command is for importing a pool which is currently imported by another system or active as they say. Importing an exported zpool should be no problem at all and I don't see a reason this shouldn't be possible when booting too. Maybe FreeBSD should try to import the zpool before trying to mount the rootfs? greetings, philipp From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 15:16:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04D77106564A for ; Fri, 27 Mar 2009 15:16:53 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 527168FC0C for ; Fri, 27 Mar 2009 15:16:52 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 19891 invoked by uid 98); 27 Mar 2009 15:16:51 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9174. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.035785 secs); 27 Mar 2009 15:16:51 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 27 Mar 2009 15:16:51 +0000 Received: (qmail 84206 invoked by uid 1002); 27 Mar 2009 15:16:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Mar 2009 15:16:49 -0000 Date: Fri, 27 Mar 2009 15:16:49 +0000 (GMT) From: "Mark Powell" To: Philipp Wuensche In-Reply-To: <49CCEAE3.5060804@h3q.com> Message-ID: <20090327151118.X82580@rust.salford.ac.uk> References: <49CB7BC8.1010905@h3q.com> <49CBD785.8050202@h3q.com> <20090327135218.S66387@rust.salford.ac.uk> <20090327135752.L66387@rust.salford.ac.uk> <49CCEAE3.5060804@h3q.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: unable to boot ZFS with gptzfsboot from an exported zpool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:16:53 -0000 On Fri, 27 Mar 2009, Philipp Wuensche wrote: > Maybe FreeBSD should try to import the zpool before trying to mount the > rootfs? I must admit that I too expected the behaviour that you request. To try an 'import' that is, not an 'import -f'. That would certainly make FreeBSD: 1. Easier to boot from ZFS. 2. Divergent from Opensolaris. 3. Possibly import the wrong pool. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:24:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D3E81065689; Fri, 27 Mar 2009 14:24:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0D68FC29; Fri, 27 Mar 2009 14:24:27 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n2RE6xsA084417; Fri, 27 Mar 2009 21:06:59 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <49CCDD7D.FA83BF14@kuzbass.ru> Date: Fri, 27 Mar 2009 21:06:53 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Prashant Vaibhav References: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Mar 2009 15:21:48 +0000 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 14:24:29 -0000 Prashant Vaibhav wrote: > The primary idea is to improve the performance and resolution of > gettimeofday() and friends by creating a efficient userspace implementation > of these functions, along with some supporting modifications to the kernel. Are you aware of CLOCK_*_FAST family of timecounters present in FreeBSD 7.x? If not, you may want to take a look: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/time.h#rev1.71 Eugene Grosbein From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 15:44:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B7E106566C; Fri, 27 Mar 2009 15:44:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id BEAEC8FC18; Fri, 27 Mar 2009 15:44:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C8DBF1CF09; Fri, 27 Mar 2009 16:44:10 +0100 (CET) Date: Fri, 27 Mar 2009 16:44:10 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20090327154410.GL73108@hoeg.nl> References: <370833.32038.qm@web63903.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QqzFzR/RUlLahzby" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Barney Cordoba , mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:44:12 -0000 --QqzFzR/RUlLahzby Content-Type: multipart/mixed; boundary="hdW7zL/qDS6RXdAL" Content-Disposition: inline --hdW7zL/qDS6RXdAL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Barney, * Robert Watson wrote: > if ((tty =3D strrchr(ttyn, '/')) !=3D NULL) > ++tty; > else > tty =3D ttyn; Does the attached patch for login(1) fix the issues you're seeing? If it does, I'll commit it to SVN. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --hdW7zL/qDS6RXdAL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="login.diff" Content-Transfer-Encoding: quoted-printable Index: login.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 --- login.c (revision 190463) +++ login.c (working copy) @@ -245,8 +245,8 @@ (void)snprintf(tname, sizeof(tname), "%s??", _PATH_TTY); ttyn =3D tname; } - if ((tty =3D strrchr(ttyn, '/')) !=3D NULL) - ++tty; + if (strncmp(ttyn, _PATH_DEV, sizeof _PATH_DEV - 1) =3D=3D 0) + tty =3D ttyn + sizeof _PATH_DEV - 1; else tty =3D ttyn; =20 --hdW7zL/qDS6RXdAL-- --QqzFzR/RUlLahzby Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknM9EoACgkQ52SDGA2eCwWIKQCfXqtCUvhbAjBwaDXLciI+VN2o WtcAn3W7WgzjuEhjrtV/bqfFUNMlQzT9 =N4v6 -----END PGP SIGNATURE----- --QqzFzR/RUlLahzby-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 16:27:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68931065680; Fri, 27 Mar 2009 16:27:29 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 935B48FC2C; Fri, 27 Mar 2009 16:27:29 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms070.mailsrvcs.net ([172.18.12.133]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KH600L0K88ULXSN@vms173019.mailsrvcs.net>; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms070.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Date: Fri, 27 Mar 2009 10:26:54 -0500 (CDT) From: Sergey Babkin To: phk@phk.freebsd.dk Message-id: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Fri, 27 Mar 2009 16:37:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:27:30 -0000 (Sorry for the top quoting). Probably the best implementation of gettimeofd= ay() is to have a page in the kernel mapped read-only to all the user pr= ocesses. Put the kernel's idea of time into this page. Then getting the = time becomes a simple read (OK, two reads, to make sure that no update = has happened in between). The TSC can then be used to add the precis= ion between the ticks of the kernel timer: i.e. remember the value of TS= C when the last tick happen, and the highest rate at which TSC may be ti= cking at this CPU, and export in the same page. This would guarantee thatthe time is not moving back. However there are more issues with TS= C. TSC is guaranteed to have the same value on all the processors that s= hare the same system bus. But if the machine is built of multiple buses = with bridges between them, all bets are off. Each bus may be stopped, resta= rted and clocked separately. There is no way to tell, on which CPU is th= e process currently runnning, and it may be rescheduled do a different C= PU right before or after the RDTSC instruction. -SB Ma= r 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: In message <[2]17560ccf0903260551v1f5cba9eu8= 7727c0bae7baa3@mail.gmail.com>, Prasha nt Vaibhav writes: = >The gettimeofday() function's implementation will then be >change= d to read the timestamp counter (TSC) from the processor, and use the &g= t;reading in conjunction with the timing info exported by the kernel to = >calculate and return the time info in proper format. I take it a= s read, that you know that there are other relvant functions than gettim= eofday() and that these must provide a monotonic timescale when queried = interleaved ? Be aware that the TSC may not be, and may not stay syn= chronized across multiple cores. Further more, the TSC is not con= stant frequency and in particular not "known frequency" at all times. There are a lot of nasty cases to check, and a nasty interpolation = required, which, in my tests some years back, totally negated any speedu= p from using the TSC in the first place. At the very minimum, you wi= ll have to add a quirk table where known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we find them. >This will also pave way f= or optionally making the >FreeBSD kernel tickless, Rubbish. T= imecounters are not even closely associated with the tick or ticklessnes= s of the kernel. [1] > - The TSC frequency might change on cert= ain processors with non-constant > TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The only way to > combat this is that t= he kernel be notified every time the processor > frequency changes.= Every cpu frequency driver will need to be updated to > notify the= kernel before and after a cpu freq change. That is not good enough= , the bios may autonomously change the cpu speed and the skew from not k= nowing exactly _when_ and _how_ the cpu clock changed, is a significant = number of microseconds, plenty of time to make strange things happen. You will want to study carefully Dave Mills work to tame the alpha = chips wandering SAW clocks. Poul-Henning [1] In my mind, rewo= rking the callout system in the kernel would be a much better more neded= and much more worthwhile project. -- Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20 [3]phk@FreeBSD.ORG | TCP= /IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe N= ever attribute to malice what can adequately be explained by incompetence.<= br>_______________________________________________ [4]freebsd-hackers@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo unsubscribe, send any mail to "[6]fre= ebsd-hackers-unsubscribe@freebsd.org" References 1. 3D"mailto:phk@phk.freebsd.dk" 2. file://localhost/tmp/3D= 3. 3D"mailto:phk@FreeBSD.ORG" 4. 3D"mailto:fre= 5. 3D"http://lists.=/ 6. 3D"mailto:freebsd-hackers-unsub= From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 16:51:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575BE106566B; Fri, 27 Mar 2009 16:51:39 +0000 (UTC) (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 147C58FC12; Fri, 27 Mar 2009 16:51:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2RGpHNQ060615; Fri, 27 Mar 2009 10:51:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CD0405.1060704@samsco.org> Date: Fri, 27 Mar 2009 10:51:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Sergey Babkin References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> In-Reply-To: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:51:40 -0000 I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: > (Sorry for the top quoting). Probably the best implementation of > gettimeofd=y() is to have > a page in the kernel mapped read-only to all the user pr=cesses. Put > the kernel's idea of time > into this page. Then getting the =ime becomes a simple read (OK, two > reads, to make sure that > no update =as happened in between). > The TSC can then be used to add the precis=on between the ticks of > the kernel timer: > i.e. remember the value of TS= when the last tick happen, and the > highest rate at which > TSC may be ti=king at this CPU, and export in the same page. This > would guarantee thatthe time is not moving back. > However there are more issues with TS=. TSC is guaranteed to have > the same value > on all the processors that s=are the same system bus. But if the > machine is built of multiple > buses =ith bridges between them, all bets are off. Each bus may be > stopped, resta=ted > and clocked separately. There is no way to tell, on which CPU is th= > process currently > runnning, and it may be rescheduled do a different C=U right before > or after the RDTSC > instruction. > -SB > Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: > > In message <[2]17560ccf0903260551v1f5cba9eu8 7727c0bae7baa3@mail.gmail.com>, Prasha > nt Vaibhav writes: > =The gettimeofday() function's implementation will then be > >change= to read the timestamp counter (TSC) from the processor, > and use the > &g=;reading in conjunction with the timing info exported by the > kernel to > =calculate and return the time info in proper format. > I take it a= read, that you know that there are other relvant > functions than gettim=ofday() and that these must provide a > monotonic timescale when queried =nterleaved ? > Be aware that the TSC may not be, and may not stay syn=hronized > across multiple cores. > Further more, the TSC is not con=tant frequency and in particular > not "known frequency" at all times. > There are a lot of nasty cases to check, and a nasty interpolation > =equired, which, in my tests some years back, totally negated any > speedu= from using the TSC in the first place. > At the very minimum, you wi=l have to add a quirk table where > known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we > find them. > >This will also pave way f=r optionally making the > >FreeBSD kernel tickless, > Rubbish. T=mecounters are not even closely associated with the > tick or ticklessnes= of the kernel. [1] > > - The TSC frequency might change on cert=in processors with > non-constant > > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The > only way to > > combat this is that t=e kernel be notified every time the > processor > > frequency changes.=very cpu frequency driver will need to be > updated to > > notify the=ernel before and after a cpu freq change. > That is not good enough= the bios may autonomously change the cpu > speed > and the skew from not k=owing exactly _when_ and _how_ the cpu > clock > changed, is a significant =umber of microseconds, plenty of time > to make strange things happen. > You will want to study carefully Dave Mills work to tame the alpha > =hips wandering SAW clocks. > Poul-Henning > [1] In my mind, rewo=king the callout system in the kernel would > be a much better more neded=nd much more worthwhile project. > -- > Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 > [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > N=ver attribute to malice what can adequately be explained by > incompetence.<=r>_______________________________________________ > [4]freebsd-hackers@freebsd.org mailing list > [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo > unsubscribe, send any mail to "[6]fre ebsd-hackers-unsubscribe@freebsd.org" > > > References > > 1. 3D"mailto:phk@phk.freebsd.dk" > 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" > 4. 3D"mailto:fre 5. 3D"http://lists.=/ > 6. 3D"mailto:freebsd-hackers-unsub_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 17:31:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A719106566B; Fri, 27 Mar 2009 17:31:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2418FC14; Fri, 27 Mar 2009 17:31:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2C7B578CD0; Fri, 27 Mar 2009 17:31:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RHVRVO005740; Fri, 27 Mar 2009 17:31:27 GMT (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 10:51:17 CST." <49CD0405.1060704@samsco.org> Date: Fri, 27 Mar 2009 17:31:27 +0000 Message-ID: <5739.1238175087@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, Sergey Babkin , prashant.vaibhav@gmail.com, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:31:30 -0000 In message <49CD0405.1060704@samsco.org>, Scott Long writes: >I've been talking about this for years. All I need is help with the VM >magic to create the page on fork. I also want two pages, one global >for gettimeofday (and any other global data we can think of) and one >per-process for static data like getpid/getgid. Agreed, that is a good place to start. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:20:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 359381065781 for ; Fri, 27 Mar 2009 18:20:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 78B6D8FC24 for ; Fri, 27 Mar 2009 18:20:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F2F0346B55; Fri, 27 Mar 2009 14:20:40 -0400 (EDT) Date: Fri, 27 Mar 2009 18:20:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Schouten In-Reply-To: <20090327154410.GL73108@hoeg.nl> Message-ID: References: <370833.32038.qm@web63903.mail.re1.yahoo.com> <20090327154410.GL73108@hoeg.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Barney Cordoba , mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:21:06 -0000 On Fri, 27 Mar 2009, Ed Schouten wrote: > * Robert Watson wrote: >> if ((tty = strrchr(ttyn, '/')) != NULL) >> ++tty; >> else >> tty = ttyn; > > Does the attached patch for login(1) fix the issues you're seeing? If it > does, I'll commit it to SVN. Thanks! This seems to fix the problem for me -- thanks Ed! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:23:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4591065692; Fri, 27 Mar 2009 18:23:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B31A8FC21; Fri, 27 Mar 2009 18:23:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 33D5546B09; Fri, 27 Mar 2009 14:23:57 -0400 (EDT) Date: Fri, 27 Mar 2009 18:23:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <49CD0405.1060704@samsco.org> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:24:00 -0000 On Fri, 27 Mar 2009, Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global for > gettimeofday (and any other global data we can think of) and one per-process > for static data like getpid/getgid. FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc. Robert N M Watson Computer Laboratory University of Cambridge > > Scott > > > Sergey Babkin wrote: >> (Sorry for the top quoting). Probably the best implementation of >> gettimeofd=y() is to have >> a page in the kernel mapped read-only to all the user pr=cesses. Put >> the kernel's idea of time >> into this page. Then getting the =ime becomes a simple read (OK, two >> reads, to make sure that >> no update =as happened in between). >> The TSC can then be used to add the precis=on between the ticks of >> the kernel timer: >> i.e. remember the value of TS= when the last tick happen, and the >> highest rate at which >> TSC may be ti=king at this CPU, and export in the same page. This >> would guarantee thatthe time is not moving back. >> However there are more issues with TS=. TSC is guaranteed to have >> the same value >> on all the processors that s=are the same system bus. But if the >> machine is built of multiple >> buses =ith bridges between them, all bets are off. Each bus may be >> stopped, resta=ted >> and clocked separately. There is no way to tell, on which CPU is th= >> process currently >> runnning, and it may be rescheduled do a different C=U right before >> or after the RDTSC >> instruction. >> -SB >> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >> In message <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3@mail.gmail.com>, Prasha >> nt Vaibhav writes: >> =The gettimeofday() function's implementation will then be >> >change= to read the timestamp counter (TSC) from the processor, >> and use the >> &g=;reading in conjunction with the timing info exported by the >> kernel to >> =calculate and return the time info in proper format. >> I take it a= read, that you know that there are other relvant >> functions than gettim=ofday() and that these must provide a >> monotonic timescale when queried =nterleaved ? >> Be aware that the TSC may not be, and may not stay syn=hronized >> across multiple cores. >> Further more, the TSC is not con=tant frequency and in particular >> not "known frequency" at all times. >> There are a lot of nasty cases to check, and a nasty interpolation >> =equired, which, in my tests some years back, totally negated any >> speedu= from using the TSC in the first place. >> At the very minimum, you wi=l have to add a quirk table where >> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >> find them. >> >This will also pave way f=r optionally making the >> >FreeBSD kernel tickless, >> Rubbish. T=mecounters are not even closely associated with the >> tick or ticklessnes= of the kernel. [1] >> > - The TSC frequency might change on cert=in processors with >> non-constant >> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >> only way to >> > combat this is that t=e kernel be notified every time the >> processor >> > frequency changes.=very cpu frequency driver will need to be >> updated to >> > notify the=ernel before and after a cpu freq change. >> That is not good enough= the bios may autonomously change the cpu >> speed >> and the skew from not k=owing exactly _when_ and _how_ the cpu >> clock >> changed, is a significant =umber of microseconds, plenty of time >> to make strange things happen. >> You will want to study carefully Dave Mills work to tame the alpha >> =hips wandering SAW clocks. >> Poul-Henning >> [1] In my mind, rewo=king the callout system in the kernel would >> be a much better more neded=nd much more worthwhile project. >> -- >> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> N=ver attribute to malice what can adequately be explained by >> incompetence.<=r>_______________________________________________ >> [4]freebsd-hackers@freebsd.org mailing list >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >> unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe@freebsd.org" >> >> References >> >> 1. 3D"mailto:phk@phk.freebsd.dk" >> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >> 6. >> 3D"mailto:freebsd-hackers-unsub_______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:25:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C548F1065722; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88E648FC08; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4220746B55; Fri, 27 Mar 2009 14:25:14 -0400 (EDT) Date: Fri, 27 Mar 2009 18:25:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <49CD0405.1060704@samsco.org> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:25:15 -0000 On Fri, 27 Mar 2009, Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global for > gettimeofday (and any other global data we can think of) and one per-process > for static data like getpid/getgid. One note though -- the time to do the global page is at execve()-time. Robert N M Watson Computer Laboratory University of Cambridge > > Scott > > > Sergey Babkin wrote: >> (Sorry for the top quoting). Probably the best implementation of >> gettimeofd=y() is to have >> a page in the kernel mapped read-only to all the user pr=cesses. Put >> the kernel's idea of time >> into this page. Then getting the =ime becomes a simple read (OK, two >> reads, to make sure that >> no update =as happened in between). >> The TSC can then be used to add the precis=on between the ticks of >> the kernel timer: >> i.e. remember the value of TS= when the last tick happen, and the >> highest rate at which >> TSC may be ti=king at this CPU, and export in the same page. This >> would guarantee thatthe time is not moving back. >> However there are more issues with TS=. TSC is guaranteed to have >> the same value >> on all the processors that s=are the same system bus. But if the >> machine is built of multiple >> buses =ith bridges between them, all bets are off. Each bus may be >> stopped, resta=ted >> and clocked separately. There is no way to tell, on which CPU is th= >> process currently >> runnning, and it may be rescheduled do a different C=U right before >> or after the RDTSC >> instruction. >> -SB >> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >> In message <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3@mail.gmail.com>, Prasha >> nt Vaibhav writes: >> =The gettimeofday() function's implementation will then be >> >change= to read the timestamp counter (TSC) from the processor, >> and use the >> &g=;reading in conjunction with the timing info exported by the >> kernel to >> =calculate and return the time info in proper format. >> I take it a= read, that you know that there are other relvant >> functions than gettim=ofday() and that these must provide a >> monotonic timescale when queried =nterleaved ? >> Be aware that the TSC may not be, and may not stay syn=hronized >> across multiple cores. >> Further more, the TSC is not con=tant frequency and in particular >> not "known frequency" at all times. >> There are a lot of nasty cases to check, and a nasty interpolation >> =equired, which, in my tests some years back, totally negated any >> speedu= from using the TSC in the first place. >> At the very minimum, you wi=l have to add a quirk table where >> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >> find them. >> >This will also pave way f=r optionally making the >> >FreeBSD kernel tickless, >> Rubbish. T=mecounters are not even closely associated with the >> tick or ticklessnes= of the kernel. [1] >> > - The TSC frequency might change on cert=in processors with >> non-constant >> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >> only way to >> > combat this is that t=e kernel be notified every time the >> processor >> > frequency changes.=very cpu frequency driver will need to be >> updated to >> > notify the=ernel before and after a cpu freq change. >> That is not good enough= the bios may autonomously change the cpu >> speed >> and the skew from not k=owing exactly _when_ and _how_ the cpu >> clock >> changed, is a significant =umber of microseconds, plenty of time >> to make strange things happen. >> You will want to study carefully Dave Mills work to tame the alpha >> =hips wandering SAW clocks. >> Poul-Henning >> [1] In my mind, rewo=king the callout system in the kernel would >> be a much better more neded=nd much more worthwhile project. >> -- >> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> N=ver attribute to malice what can adequately be explained by >> incompetence.<=r>_______________________________________________ >> [4]freebsd-hackers@freebsd.org mailing list >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >> unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe@freebsd.org" >> >> References >> >> 1. 3D"mailto:phk@phk.freebsd.dk" >> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >> 6. >> 3D"mailto:freebsd-hackers-unsub_______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:27:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 585F61065822; Fri, 27 Mar 2009 18:27:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id F06968FC1A; Fri, 27 Mar 2009 18:27:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 4F8EFFF37; Sat, 28 Mar 2009 07:27:45 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0cZ02VDkElO; Sat, 28 Mar 2009 07:27:40 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 28 Mar 2009 07:27:40 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 3432611432; Sat, 28 Mar 2009 07:27:40 +1300 (NZDT) Date: Fri, 27 Mar 2009 11:27:40 -0700 From: Andrew Thompson To: usb Message-ID: <20090327182740.GB26662@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Proposed USB data buffer changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:27:47 -0000 Hi, I want the USB peripheral driver API to be solid before 8.0 so things dont bite us down the line. I have discussed this privately with Hans already and want to put it out for public consumption. With the new USB code the buffer management has been merged into the xfer structure and this dictates the layout of the usb drivers and how locking is performed. This uses a state machine (my attempt to show below) |-< |-< XFER <-| <-| | | | | --------- callback_fn --------- | | | | | -> SETUP (copyin) >-| | | | -> COMPLETE (copyout) >-| It can take an external buffer instead of the copyin/out but it doesnt really simplify things at all. The problems I see with this approach are 1. It is in contrast to other major operating systems, making porting drivers harder. Windows, Linux and oldUSB all use a URB style of data handling. 2. It greatly complicates locking as the xfer lock can not be dropped until the xfer is resubmitted. This requirement to hold the lock creates a big problem for get/put of data to another layer (eg TTY), to avoid lock order reversals the drivers are generally written to share the lock with the lower/upper layer (eg TTY). 3. In the general case data can not be directly queued on the xfer (must be "picked" up by the state machine callback). This limits the options for designing a driver and may require the driver to implement a queue. I think its vital that we separate out the data buffers from the xfer (its actually a pipe in usb speak). It should draw from the Linux API which is simple and I believe works quite well. The data buffer is represented as a usb URB which is allocated either at attach or on the fly and then queued on the xfer (pipe) for processing. An arbitrary number of URB buffers can be on the queue. As the buffer would only have a single reference it would not need explicit locking, the callback would not need the xfer lock to be held at all and this would make it _much_ easier to handoff the data without LOR. This reduction in locking means that the driver and the xfer do not need to share a lock either, something that is mandatory now. The xfer can have a private lock for enqueue/start/stop. Example functions could be, usb_alloc_urb - Creates a URB representing data and housekeeping, the data section can be allocated or passed in from say a mbuf. This can also perform the DMA foo. usb_submit_urb - Queues the URB on the usb pipe. I dont think this would take much work. The xfer callbacks would be changed to take a URB and a few changes to queuing. It was mentioned the reason for this approach was to preallocate and do DMA setup on attach but this can still easily be done with the above. Comments? cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:30:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC5210656C1; Fri, 27 Mar 2009 18:30:26 +0000 (UTC) (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 9B5468FC0C; Fri, 27 Mar 2009 18:30:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2RIUL7v061016; Fri, 27 Mar 2009 12:30:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CD1B3D.3030103@samsco.org> Date: Fri, 27 Mar 2009 12:30:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Robert Watson References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:30:28 -0000 Robert Watson wrote: > > On Fri, 27 Mar 2009, Scott Long wrote: > >> I've been talking about this for years. All I need is help with the >> VM magic to create the page on fork. I also want two pages, one >> global for gettimeofday (and any other global data we can think of) >> and one per-process for static data like getpid/getgid. > > FWIW, there are some variations in schemes across OS's -- one extreme is > the Linux approach, which actually exports a mini shared library in ELF > format on the shared page, providing implementations of various services > (such as entering system calls), time stuff, etc. Less extreme are the > shared pages offered on Mac OS X, etc. > Yes, but I'd like to start somewhere, and considering that it's been impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB time to get the basic VM magic done, I'm keeping my expectations as modest as possible. Scott From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:46:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A2951065677 for ; Fri, 27 Mar 2009 18:46:47 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 506D38FC25 for ; Fri, 27 Mar 2009 18:46:47 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by an-out-0708.google.com with SMTP id d11so755105and.13 for ; Fri, 27 Mar 2009 11:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=072cPdOVo+jrqhu6xN2dVesAoBG6ikaFPu8DMD8VXcE=; b=NFDVoB1nHsH6GaSbmGgWlHoEmrgN46+9ZSQJna81iBGVKo6hXj5O2XF6PaC8Grtusj fLxgcUX3gwoa6QBP3jFzcJJ6zgq+jhd8ITqFSU8p7kEus6+xFpGaAaund4VVgIQMkRkI x7UgLAlV5Pb80skiv8Lmi6TM4KPMqz8S9v/cA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ngb6e3gvarjINEVcT+8t4pUnOR9TbWzF3VNcJEP8puWapfyYy0BBW55cRRF8gf1LlR 6UExbOIB1rKt9QAVQYyWs53V2gm9S0ZFc7dgIIqWiUflSfreyDBWGO4iuQoWSMIsTQl3 BUiDYybeFeLu26dZaRVME6up7W26x1UgzDCQg= MIME-Version: 1.0 Received: by 10.100.206.14 with SMTP id d14mr2020519ang.67.1238177956676; Fri, 27 Mar 2009 11:19:16 -0700 (PDT) In-Reply-To: <5739.1238175087@critter.freebsd.dk> References: <49CD0405.1060704@samsco.org> <5739.1238175087@critter.freebsd.dk> Date: Fri, 27 Mar 2009 14:19:16 -0400 Message-ID: <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> From: Alexander Sack To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, Sergey Babkin , prashant.vaibhav@gmail.com, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:46:47 -0000 On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wro= te: > In message <49CD0405.1060704@samsco.org>, Scott Long writes: > >>I've been talking about this for years. =A0All I need is help with the VM >>magic to create the page on fork. =A0I also want two pages, one global >>for gettimeofday (and any other global data we can think of) and one >>per-process for static data like getpid/getgid. > > Agreed, that is a good place to start. I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? Also I thought at least PHK's comment (Sergey mentioned it) was true regardless of bus, that the TSC is not consistent across multiple packages (and for that matter I suppose cores) due to I *think* its ISA lineage so how does this work again? Won't the rate in which you tick up be sporadic over the course of the process scheduled on different cores? (i.e. depending on what core RDTSC happened to land on) -aps From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 19:14:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CC27106566C; Fri, 27 Mar 2009 19:14:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C97488FC13; Fri, 27 Mar 2009 19:14:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DE0561CF12; Fri, 27 Mar 2009 20:14:23 +0100 (CET) Date: Fri, 27 Mar 2009 20:14:23 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20090327191423.GN73108@hoeg.nl> References: <370833.32038.qm@web63903.mail.re1.yahoo.com> <20090327154410.GL73108@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IoFIGPN1N3g1Ryqz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Barney Cordoba , mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:14:25 -0000 --IoFIGPN1N3g1Ryqz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Robert Watson wrote: > This seems to fix the problem for me -- thanks Ed! I've just committed the fix to SVN. Thanks for reporting the issue and debugging it for me. --=20 Ed Schouten WWW: http://80386.nl/ --IoFIGPN1N3g1Ryqz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknNJY8ACgkQ52SDGA2eCwXLBwCfVlT1ovk4w6iZSNMssFWyYs8o fUgAn15sWxL0yKpVjR00PJU7/9zHMO4V =5Y1z -----END PGP SIGNATURE----- --IoFIGPN1N3g1Ryqz-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 19:16:04 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EF2B10656C9 for ; Fri, 27 Mar 2009 19:16:04 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 13CFE8FC0A for ; Fri, 27 Mar 2009 19:16:03 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KH6000LGIUQFY00@asmtp020.mac.com>; Fri, 27 Mar 2009 12:16:03 -0700 (PDT) Message-id: <2C3C7185-CB37-4067-B2A9-A03B5B288606@mac.com> From: Chuck Swiger To: Scott Long In-reply-to: <49CD1B3D.3030103@samsco.org> Date: Fri, 27 Mar 2009 12:16:02 -0700 References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> X-Mailer: Apple Mail (2.930.3) Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, Robert Watson , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:16:04 -0000 Hi, Scott & all-- On Mar 27, 2009, at 11:30 AM, Scott Long wrote: > Robert Watson wrote: >> On Fri, 27 Mar 2009, Scott Long wrote: >>> I've been talking about this for years. All I need is help with >>> the VM magic to create the page on fork. I also want two pages, >>> one global for gettimeofday (and any other global data we can >>> think of) and one per-process for static data like getpid/getgid. >> FWIW, there are some variations in schemes across OS's -- one >> extreme is the Linux approach, which actually exports a mini shared >> library in ELF format on the shared page, providing implementations >> of various services (such as entering system calls), time stuff, >> etc. Less extreme are the shared pages offered on Mac OS X, etc. > > Yes, but I'd like to start somewhere, and considering that it's been > impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB > time to get the basic VM magic done, I'm keeping my expectations as > modest as possible. I'm not entirely sure how close the Mach/xnu and FreeBSD implementations of pmap_* stuff are, but the xnu code for commpage stuff is here: http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/pmap.c [pmap_commpage32_init(), pmap_commpage64_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/ [all :-)] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/commpage_gettimeofday.s [but this one in particular] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/vm/vm_shared_region.c [cf "COMM PAGE" comments, vm_commpage_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/bsd/kern/kern_fork.c [fork_create_child(), procdup(), uses of pmap_map_sharedpage()] [ ADC login might be needed, otherwise I think rwatson has been importing xnu periodically for TrustedBSD or other work, and might be able to provide similar pointers... ] Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 19:40:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9897106564A for ; Fri, 27 Mar 2009 19:40:43 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 53F8A8FC15 for ; Fri, 27 Mar 2009 19:40:42 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so549753fka.11 for ; Fri, 27 Mar 2009 12:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-pgp-agent:x-mailer; bh=ueIo99MSMxyWMqtiuISiV0kL3z2GSOf5yTfFxPZqyZM=; b=pvPBp6WrD0eDWLGnC3D+z1p4DEZcvd0A/bvPOeH7WeonUpd0UpidqAUaBeZ762p7Qs FQFl4mEshBrZIRTgOW4jTW59rWYVeUsOWNqCo4xOR4NsFEaVIDEs7AK4V2SbOMniIuwU TmMDuChj2cgBLa/9hW+Gy7rkj/o/ySikAi7Oc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-pgp-agent:x-mailer; b=eq1lkxIjRNQ0wyNcIYnSDVycqk3rCTabtsWiLtNAomL8kdH9UxsdawKpA6UjTo1FnO uPdcdfJcvzmnllLdfYSqL0FfEQ0fMZT+RFKSDPE+Xxx78dUJd0q7Rs3EP3kANF7OOVMp +DX+VhY6l4aUC63Mk+zbZD/BWEb4ytW+dpnCs= Received: by 10.223.126.66 with SMTP id b2mr1926063fas.67.1238181251813; Fri, 27 Mar 2009 12:14:11 -0700 (PDT) Received: from mbp-gige.totalterror.net ([93.152.151.19]) by mx.google.com with ESMTPS id 12sm1040157fks.5.2009.03.27.12.14.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 12:14:11 -0700 (PDT) Message-Id: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> From: Nikolay Denev To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Mar 2009 21:14:06 +0200 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Subject: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:40:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm running -current from 23.03.09 and I'm experiencing some axe(4) =20 problems. Basically the network connection works but when some more serious =20 traffic hits the interface (i.e. torrent download) it then dies, ifconfig down/up does not help, only replugging of the adapter. I've tried running with hw.usb2.axe.debug=3D15 and the output was many =20= lines of: axe_bulk_write_callback:853: transfer complete then a pause of several seconds and the kernel begins to print : axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT Another strange thing that I noticed is that, while the interface =20 seems to be connected and working, if I type many times ifconfig ue0 consecutively most of the time it would show different settings for the auto =20 negotiated link. I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. The switch does not seem to register link flaps. The kernel messages for the interface are : ugen2.5: at usbus2 axe0: on usbus2 axe0: PHYADDR 0xe0:0x01 miibus0: on axe0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =20 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:11:50:xx:xx:xx devinfo -vr | grep phy ukphy0 pnpinfo oui=3D0xa0bc model=3D0x1 rev=3D0x2 at phyno=3D1 - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAknNJX8ACgkQHNAJ/fLbfrmx9QCfYYKrUtXGy5V7k46mwc6Hgy/C m6sAni6ua4JNBBgiKSlS8kHBX4CTmYpQ =3D7TLQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:02:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418BC10656C5 for ; Fri, 27 Mar 2009 20:02:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 23D4F8FC24 for ; Fri, 27 Mar 2009 20:02:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0B09EAE06B; Fri, 27 Mar 2009 13:02:49 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 05BB42D603F; Fri, 27 Mar 2009 13:02:26 -0700 (PDT) Message-ID: <49CD30E9.7030501@elischer.org> Date: Fri, 27 Mar 2009 13:02:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Scott Long References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> In-Reply-To: <49CD0405.1060704@samsco.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:02:31 -0000 Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global > for gettimeofday (and any other global data we can think of) and one > per-process for static data like getpid/getgid. interestingly it is even feasible to have a per-thread page.. it requires that the scheduler change a page table entry tough. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:08:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC411065674 for ; Fri, 27 Mar 2009 20:08:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFC18FC25 for ; Fri, 27 Mar 2009 20:08:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 604FE961D8; Fri, 27 Mar 2009 13:08:50 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E4C092D6037; Fri, 27 Mar 2009 13:08:11 -0700 (PDT) Message-ID: <49CD3242.8050802@elischer.org> Date: Fri, 27 Mar 2009 13:08:34 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Scott Long References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> In-Reply-To: <49CD1B3D.3030103@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, Robert Watson , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:08:15 -0000 Scott Long wrote: > Robert Watson wrote: >> >> On Fri, 27 Mar 2009, Scott Long wrote: >> >>> I've been talking about this for years. All I need is help with the >>> VM magic to create the page on fork. I also want two pages, one >>> global for gettimeofday (and any other global data we can think of) >>> and one per-process for static data like getpid/getgid. >> >> FWIW, there are some variations in schemes across OS's -- one extreme >> is the Linux approach, which actually exports a mini shared library in >> ELF format on the shared page, providing implementations of various >> services (such as entering system calls), time stuff, etc. Less >> extreme are the shared pages offered on Mac OS X, etc. >> > > Yes, but I'd like to start somewhere, and considering that it's been > impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB > time to get the basic VM magic done, I'm keeping my expectations as > modest as possible. try alc.. :-) > > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:48:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0488C106566B for ; Fri, 27 Mar 2009 20:48:43 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id BF7AC8FC23 for ; Fri, 27 Mar 2009 20:48:42 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1350110wfg.7 for ; Fri, 27 Mar 2009 13:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fL9AxkY8S5tUPvYhzMMNqugYrdC9/MpDKZdk8VDTsuA=; b=l8gv7DO4FjObTIkXHFLeJ0wFeQ5GGEA2aiMK2g9tFJY4gHnizQVrlFil3m3tVEqF3g ikMm4OjTAGSfkBachHaGxmrJ500IAXetE6r7GWkv4FmGoJeiXhNf2cg+mTAbZ2KTTuTj M3MG7pAeoedN8bhylagwDJDkXQFhzgrqQrvVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m7oek8mIH8t+3Q4iLLLvXp6FQVXfQTmGykayXQnY6d3qTRaBhS0q9MOk8HAfJoSUqd Rra0CxS6c0SRU3TnM5cX3VvNlvozpz8OQbg8SFRtB7K2Tmft50uT1VPGl3FphoLKPLBA 2Tpk1eKVz+Ng/u0NV62pGwQr/+lBMAvkEvNUM= MIME-Version: 1.0 Received: by 10.142.79.17 with SMTP id c17mr1050527wfb.171.1238186922255; Fri, 27 Mar 2009 13:48:42 -0700 (PDT) In-Reply-To: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> Date: Sat, 28 Mar 2009 02:18:42 +0530 Message-ID: <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> From: Prashant Vaibhav To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:48:43 -0000 Actually OS X is more similar than that: the shared page also contains functions that can be called by user applications, though their entry points are fixed and they're not in any particular format like elf/mach-o. Userspace implementations of gettimeofday, bcopy etc. are provided in the kernel itself, which is a nice design imo as the specific version to load is chosen by the kernel at boot time depending on processor capabilities. On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson wrote: > > On Fri, 27 Mar 2009, Scott Long wrote: > > I've been talking about this for years. All I need is help with the VM >> magic to create the page on fork. I also want two pages, one global for >> gettimeofday (and any other global data we can think of) and one per-process >> for static data like getpid/getgid. >> > > FWIW, there are some variations in schemes across OS's -- one extreme is > the Linux approach, which actually exports a mini shared library in ELF > format on the shared page, providing implementations of various services > (such as entering system calls), time stuff, etc. Less extreme are the > shared pages offered on Mac OS X, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > >> Scott >> >> >> Sergey Babkin wrote: >> >>> (Sorry for the top quoting). Probably the best implementation of >>> gettimeofd=y() is to have >>> a page in the kernel mapped read-only to all the user pr=cesses. Put >>> the kernel's idea of time >>> into this page. Then getting the =ime becomes a simple read (OK, two >>> reads, to make sure that >>> no update =as happened in between). >>> The TSC can then be used to add the precis=on between the ticks of >>> the kernel timer: >>> i.e. remember the value of TS= when the last tick happen, and the >>> highest rate at which >>> TSC may be ti=king at this CPU, and export in the same page. This >>> would guarantee thatthe time is not moving back. >>> However there are more issues with TS=. TSC is guaranteed to have >>> the same value >>> on all the processors that s=are the same system bus. But if the >>> machine is built of multiple >>> buses =ith bridges between them, all bets are off. Each bus may be >>> stopped, resta=ted >>> and clocked separately. There is no way to tell, on which CPU is th= >>> process currently >>> runnning, and it may be rescheduled do a different C=U right before >>> or after the RDTSC >>> instruction. >>> -SB >>> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >>> In message <[2]17560ccf0903260551v1f5cba9eu8 >>> 7727c0bae7baa3@mail.gmail.com>, Prasha >>> nt Vaibhav writes: >>> =The gettimeofday() function's implementation will then be >>> >change= to read the timestamp counter (TSC) from the processor, >>> and use the >>> &g=;reading in conjunction with the timing info exported by the >>> kernel to >>> =calculate and return the time info in proper format. >>> I take it a= read, that you know that there are other relvant >>> functions than gettim=ofday() and that these must provide a >>> monotonic timescale when queried =nterleaved ? >>> Be aware that the TSC may not be, and may not stay syn=hronized >>> across multiple cores. >>> Further more, the TSC is not con=tant frequency and in particular >>> not "known frequency" at all times. >>> There are a lot of nasty cases to check, and a nasty interpolation >>> =equired, which, in my tests some years back, totally negated any >>> speedu= from using the TSC in the first place. >>> At the very minimum, you wi=l have to add a quirk table where >>> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >>> find them. >>> >This will also pave way f=r optionally making the >>> >FreeBSD kernel tickless, >>> Rubbish. T=mecounters are not even closely associated with the >>> tick or ticklessnes= of the kernel. [1] >>> > - The TSC frequency might change on cert=in processors with >>> non-constant >>> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >>> only way to >>> > combat this is that t=e kernel be notified every time the >>> processor >>> > frequency changes.=very cpu frequency driver will need to be >>> updated to >>> > notify the=ernel before and after a cpu freq change. >>> That is not good enough= the bios may autonomously change the cpu >>> speed >>> and the skew from not k=owing exactly _when_ and _how_ the cpu >>> clock >>> changed, is a significant =umber of microseconds, plenty of time >>> to make strange things happen. >>> You will want to study carefully Dave Mills work to tame the alpha >>> =hips wandering SAW clocks. >>> Poul-Henning >>> [1] In my mind, rewo=king the callout system in the kernel would >>> be a much better more neded=nd much more worthwhile project. >>> -- >>> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >>> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >>> FreeBSD committer | BSD since 4.3-tahoe >>> N=ver attribute to malice what can adequately be explained by >>> incompetence.<=r>_______________________________________________ >>> [4]freebsd-hackers@freebsd.org mailing list >>> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >>> unsubscribe, send any mail to "[6]fre >>> ebsd-hackers-unsubscribe@freebsd.org" >>> >>> References >>> >>> 1. 3D"mailto:phk@phk.freebsd.dk" >>> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >>> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >>> 6. 3D"mailto: >>> freebsd-hackers-unsub_______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >> From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:34:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF2F106566B for ; Fri, 27 Mar 2009 20:34:55 +0000 (UTC) (envelope-from knowtree@aloha.com) Received: from relay.pixi.com (relay.pixi.com [206.127.224.101]) by mx1.freebsd.org (Postfix) with ESMTP id DD9D28FC1B for ; Fri, 27 Mar 2009 20:34:54 +0000 (UTC) (envelope-from knowtree@aloha.com) Received: from yoda.pixi.com (yoda.pixi.com [206.127.224.41]) by relay.pixi.com (8.13.8+Sun/8.13.6) with ESMTP id n2RKGZnW018206; Fri, 27 Mar 2009 10:16:35 -1000 (HST) Received: from webmail.pixi.com (yoda.pixi.com [206.127.224.120] (may be forged)) by yoda.pixi.com (8.13.1/8.13.1) with SMTP id n2RKGZ1m001583; Fri, 27 Mar 2009 10:16:35 -1000 Message-Id: <200903272016.n2RKGZ1m001583@yoda.pixi.com> To: freebsd-mobile@freebsd.org, freebsd-current@freebsd.org From: knowtree@aloha.com Date: Fri, 27 Mar 2009 10:16:35 HST X-Posting-IP: 141.190.32.72 X-Mailer: Endymion MailMan Standard Edition v3.2.19 X-Mailman-Approved-At: Fri, 27 Mar 2009 20:50:02 +0000 Cc: Subject: Re: Intel 5100AGN ndis driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:34:55 -0000 On 3/21/09, Ganbold wrote: > Paul B. Mahol wrote: >> On 3/19/09, Ganbold wrote: >> >>> Hi, >>> >>> I'm trying to use ndis driver for Intel 5100AGN and got >>> following error: >>> >>> beastie# grep ndis /var/log/messages >>> Mar 19 23:41:21 beastie kernel: ndis0: mem >>> 0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3 >>> Mar 19 23:41:21 beastie kernel: ndis0: [ITHREAD] >>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS API version: 5.1 >>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown error) >>> >>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown error) >>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x08ff product >>> 0x2810 bus uhub1 >>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x0a5c product >>> 0x2145 bus uhub1 >>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x17ef product >>> 0x1004 bus uhub3 >>> Mar 19 23:41:53 beastie kernel: ugen1.3: at >>> usbus1 (disconnected) >>> Mar 19 23:41:57 beastie kernel: ugen1.3: at usbus1 >>> Mar 19 23:41:57 beastie root: Unknown USB device: vendor 0x0a5c product >>> 0x2145 bus uhub1 >>> Mar 19 23:45:36 beastie kernel: wlan0: Ethernet address: 00:21:6b:9a:23:8e >>> Mar 19 23:52:02 beastie kernel: pid 9861 (initial thread) is using >>> legacy pty devices >>> Mar 20 00:08:06 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown error) >>> ... >>> ndis0 at pci0:3:0:0: class=0x028000 card=0x12118086 chip=0x42378086 >>> rev=0x00 hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> >>> I'm running: >>> beastie# uname -an >>> FreeBSD beastie.micom.mng.net 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >>> r190040M: Thu Mar 19 21:45:37 ULAT 2009 >>> tsgan at beastie.micom.mng.net:/usr/obj/usr/src/sys/DEVIL_WITNESS i386 >>> >>> >>> Any idea how to fix this issue? >>> Please let me know if you need more info. >>> >> >> How you generate ndis module? >> Post whole output _after_ is module loaded >> _not_ just lines containing ndis. >> >> also enable debug.ndis sysctl. >> >I generated module issuing following command: > >ndisgen NETw5x32.inf NETw5x32.sys > >After module is generated, loading modules gives (debug.ndis=1): > > >Mar 21 16:18:33 beastie kernel: no match for KeBugCheck >Mar 21 16:18:33 beastie kernel: ndis0: mem >0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3 >Mar 21 16:18:33 beastie kernel: ndis0: [ITHREAD] >Mar 21 16:18:33 beastie kernel: ndis0: NDIS API version: 5.1 >Mar 21 16:18:33 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown error) >Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x08ff product >0x2810 bus uhub1 >Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x0a5c product >0x2145 bus uhub1 >Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x17ef product >0x1004 bus uhub3 >Mar 21 16:18:34 beastie kernel: attach done. >Mar 21 16:18:35 beastie kernel: halting done. > >Ganbold I am seeing the exact same thing on 7.1-RELEASE, minus the USB errors. I have the same Intel chipset in a Fujitsu T1010 laptop. I downloaded the XP driver from Intel, had the same file names as above. When I ran ndisgen it asked me for the names of the files even through I specified them on the command line. Other than that the build process seemed fine. When I used kldload to test it I got the unknown error message but the system seemed happy so I set it up to load from loader.conf and added an entry for it in /etc/rc.conf. When I rebooted the hardware probe hung at the ndis driver. After I managed to boot without the kernel module I tried again to load with kldload. After the NDIS ERROR line I see WARNING: using obsoleted if_watchdog interface Next comes the MAC address, then a page fault followed by a reboot. I tried it several times with same results. Is there anything I can do to help solve this? Again I am running 7.1 not HEAD. Gary Dunn Open Slate Project Honolulu From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:54:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A72106566C for ; Fri, 27 Mar 2009 20:54:51 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id A4DE48FC26 for ; Fri, 27 Mar 2009 20:54:51 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1352155wfg.7 for ; Fri, 27 Mar 2009 13:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ptLKZzyXuaNiwRhCLIsDgbWzgu9p8HZxTh245HYs60A=; b=vMTCvKapOrAZRXkb+Pkhebs8h3Tkop1hPBDXDKKJU1kiuirhV8egFE5ICiPlBMwmdn GmM3ZIMAVUcAO0SGxhWnnXJHHqRo9NOhMm8us+mE9Hn5xf44E87t7MjYvz192ke19Fym frJr6zeHRfdqWLj7xeqUFbu/1ycv2DazH6IsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jVBo+uStcz8JRMmQyZ/SpTv/3iZ1XYtrMLin44+7kVE4/Y5lvVNqxC9r8442fY34gN A7RQRfTDKAWgOCK0vp8HCRgL9KFlUwlHU/toXuUBO7vE3exG08rii7HF55lWa45rai5u 7iQt4Qt7sIdHQwNnYUjClMasGwSQ4zWDG1b3o= MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr1048913wfz.260.1238187291562; Fri, 27 Mar 2009 13:54:51 -0700 (PDT) In-Reply-To: <2C3C7185-CB37-4067-B2A9-A03B5B288606@mac.com> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> <2C3C7185-CB37-4067-B2A9-A03B5B288606@mac.com> Date: Sat, 28 Mar 2009 02:24:51 +0530 Message-ID: <17560ccf0903271354w167e42f8sc9f76e3f92486814@mail.gmail.com> From: Prashant Vaibhav To: Chuck Swiger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:54:52 -0000 For those interested, XNU sources are available on watson also: http://fxr.watson.org/fxr/source/?v=xnu-1228 which doesn't need ADC login and has good cross-referencing of symbols. Latest is from darwin 9.0 corresponding to osx 10.5.0; there were a lot of changes to the vm part in 10.5.6 update. On Sat, Mar 28, 2009 at 12:46 AM, Chuck Swiger wrote: > Hi, Scott & all-- > > > On Mar 27, 2009, at 11:30 AM, Scott Long wrote: > >> Robert Watson wrote: >> >>> On Fri, 27 Mar 2009, Scott Long wrote: >>> >>>> I've been talking about this for years. All I need is help with the VM >>>> magic to create the page on fork. I also want two pages, one global for >>>> gettimeofday (and any other global data we can think of) and one per-process >>>> for static data like getpid/getgid. >>>> >>> FWIW, there are some variations in schemes across OS's -- one extreme is >>> the Linux approach, which actually exports a mini shared library in ELF >>> format on the shared page, providing implementations of various services >>> (such as entering system calls), time stuff, etc. Less extreme are the >>> shared pages offered on Mac OS X, etc. >>> >> >> Yes, but I'd like to start somewhere, and considering that it's been >> impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB >> time to get the basic VM magic done, I'm keeping my expectations as >> modest as possible. >> > > I'm not entirely sure how close the Mach/xnu and FreeBSD implementations of > pmap_* stuff are, but the xnu code for commpage stuff is here: > > > http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/pmap.c [pmap_commpage32_init(), > pmap_commpage64_init()] > > http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/ [all > :-)] > > http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/commpage_gettimeofday.s [but > this one in particular] > > http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/vm/vm_shared_region.c [cf > "COMM PAGE" comments, vm_commpage_init()] > > http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/bsd/kern/kern_fork.c [fork_create_child(), > procdup(), uses of pmap_map_sharedpage()] > > [ ADC login might be needed, otherwise I think rwatson has been importing > xnu periodically for TrustedBSD or other work, and might be able to provide > similar pointers... ] > > Regards, > -- > -Chuck > > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:56:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D527106566C for ; Fri, 27 Mar 2009 20:56:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4933A8FC14 for ; Fri, 27 Mar 2009 20:56:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 25C8E78CD1; Fri, 27 Mar 2009 20:56:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RKuulE006713; Fri, 27 Mar 2009 20:56:56 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 28 Mar 2009 02:18:42 +0530." <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> Date: Fri, 27 Mar 2009 20:56:56 +0000 Message-ID: <6712.1238187416@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:56:58 -0000 In message <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com>, Prash ant Vaibhav writes: >Actually OS X is more similar than that: the shared page also contains >functions that can be called by user applications, though their entry points >are fixed and they're not in any particular format like elf/mach-o. >Userspace implementations of gettimeofday, bcopy etc. are provided in the >kernel itself, which is a nice design imo as the specific version to load is >chosen by the kernel at boot time depending on processor capabilities. That would get my vote. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 21:09:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 803AC106567B for ; Fri, 27 Mar 2009 21:09:13 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5FD8FC15 for ; Fri, 27 Mar 2009 21:09:13 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-31-142.bna.bellsouth.net [70.156.31.142]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2RL7dgt046913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 17:07:40 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brandon Gooch In-Reply-To: <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> <1238136987.8491.173.camel@balrog.2hip.net> <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bx4tddrYyiuGGcswbPut" Organization: FreeBSD Date: Fri, 27 Mar 2009 16:08:30 -0500 Message-Id: <1238188110.8491.194.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:09:14 -0000 --=-bx4tddrYyiuGGcswbPut Content-Type: multipart/mixed; boundary="=-y8fcTc4EOZiPJ55QduKo" --=-y8fcTc4EOZiPJ55QduKo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-03-27 at 02:14 -0500, Brandon Gooch wrote: > On Fri, Mar 27, 2009 at 1:56 AM, Robert Noland wrot= e: > > On Thu, 2009-03-26 at 23:14 -0500, Brandon Gooch wrote: > >> On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland = wrote: > >> > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote: > >> >> Robert Noland wrote: > >> >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote: > >> >> > > >> >> >> Hi. I still have problems with a very slow display after logging= out of an X > >> >> >> session and/or switching VTYs. The problem goes away if I add > >> >> >> hw.pci.enable_msi=3D0 to /boot/loader.conf. > >> >> >> > >> >> >> Last csupped Mar 26 09:49 CET. > >> >> >> > >> >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media A= ccelerator 950 > >> >> >> > >> >> >> Anything I can do to help solve this problem? > >> >> >> > >> >> > > >> >> > I'm going to try and work on getting better debugging info from t= he > >> >> > intel driver. I don't have access to any newer Intel hardware at= the > >> >> > moment, so testing is tricky. > >> >> > > >> >> > There is a tuneable for just msi on drm hw.drm.msi. > >> >> > > >> >> > robert. > >> >> > > >> >> > > >> >> Yep, correct - here it is again - just had to log out of KDE, and a= fter > >> >> logging in again, everything was slow as hell. > >> >> I didn't fiddle with the msi settings, just rebooted the machine, a= nd > >> >> everything is fine again. > >> >> So there must be something that works the first time X is started, = but > >> >> upon restart stuffs up. Like some lock or reference which is not fr= eed. > >> > > >> > There is a problem with restarting X on at least some Intel chips... > >> > This is a different issue, I was trying to look into that a little b= it > >> > yesterday, but it kinda works on this 915 that I have, so I haven't > >> > isolated what is getting messed up. Again, vt switch, suspend/resum= e > >> > are in the same ballpark, restart is not. > >> > > >> > robert. > >> > > >> >> Mat > >> >> >> _______________________________________________ > >> >> >> freebsd-current@freebsd.org mailing list > >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@fr= eebsd.org" > >> >> >> > >> >> > >> > -- > >> > Robert Noland > >> > FreeBSD > >> > > >> > >> I have been switching to the vty at which I started X in order to > >> terminate X. If I try to terminate X while I'm in it, it just "hangs" > >> -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a > >> reboot to get my system back up. IIRC, this started happening after I > >> upgraded to Xorg 7.4. > >> > >> I thought that Mattia might be doing the same thing as a work-around > >> for the freezing intel-driven display thing, thus the X-to-vty switch > >> "fix" of disabling msi... > > > > Hrm, ok... So, vt switching on the I915 that I'm using to test(which > > doesn't support msi) works pretty much perfectly. Console is not > > corrupted, (unless I've restarted X at least once). Shutdown/reboot > > from gnome also works as expected. > > > > I did most of the msi development on an i965gm, which did support msi > > and vt switch also worked with msi at that time. Restart was > > problematic on the 965 then as well, which I believed to be an agp, or > > agp/drm interaction issue. So, unless some of the recent changes other > > than msi, have broken 965, they should be mostly working ok as long as > > you don't restart. > > > > The g31 and g45 are slightly different and all of my work for those has > > been based on what Intel has released for linux and the small amount of > > documentation that is available at this point. > > > > BTW, you debug output looks strange to me, did you also capture the drm > > debug log from hw.dri.0.debug=3D1? > > > > robert. > > > >> -Brandon > > -- > > Robert Noland > > FreeBSD > > >=20 > I've attached a copy of my /var/log/messages file after enabling > hw.dri.0.debug, suspending, and then resuming. I disable it shortly > after resume is complete. Ok, this is a complete patch against HEAD. It has even more debugging around suspend/resume and also grabs the hardware lock when it starts to suspend or resume. I'm tempted to just grab the lock when we start suspend and not release it until resume is complete, but it looks like something is triggering a vt switch and we could deadlock on that if I don't drop the lock. I should be able to tell a little more from the drm debug output of this patch. robert. >=20 > -Brandon --=20 Robert Noland FreeBSD --=-y8fcTc4EOZiPJ55QduKo Content-Disposition: attachment; filename="drm-i915-interrupts.patch" Content-Type: text/x-patch; name="drm-i915-interrupts.patch"; charset="us-ascii" Content-Transfer-Encoding: base64 SW5kZXg6IGRldi9kcm0vaTkxNV9kbWEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vaTkxNV9k bWEuYwkocmV2aXNpb24gMTkwNDAyKQ0KKysrIGRldi9kcm0vaTkxNV9kbWEuYwkod29ya2luZyBj b3B5KQ0KQEAgLTQ0NCw2ICs0NDQsOCBAQA0KIAlpZiAoZGV2X3ByaXYtPnNhcmVhX3ByaXYpDQog CQlkZXZfcHJpdi0+c2FyZWFfcHJpdi0+bGFzdF9lbnF1ZXVlID0gZGV2X3ByaXYtPmNvdW50ZXI7 DQogDQorCURSTV9ERUJVRygiZW1pdHRpbmc6ICVkXG4iLCBkZXZfcHJpdi0+Y291bnRlcik7DQor DQogCUJFR0lOX0xQX1JJTkcoNCk7DQogCU9VVF9SSU5HKE1JX1NUT1JFX0RXT1JEX0lOREVYKTsN CiAJT1VUX1JJTkcoSTkxNV9CUkVBRENSVU1CX0lOREVYIDw8IE1JX1NUT1JFX0RXT1JEX0lOREVY X1NISUZUKTsNCkBAIC00ODEsNiArNDgzLDcgQEANCiAJfQ0KIA0KIAlpOTE1X2VtaXRfYnJlYWRj cnVtYihkZXYpOw0KKw0KIAlyZXR1cm4gMDsNCiB9DQogDQpJbmRleDogZGV2L2RybS9pOTE1X2Ry di5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQotLS0gZGV2L2RybS9pOTE1X2Rydi5jCShyZXZpc2lvbiAxOTA0MDIp DQorKysgZGV2L2RybS9pOTE1X2Rydi5jCSh3b3JraW5nIGNvcHkpDQpAQCAtNTIsNyArNTIsMTAg QEANCiAJCXJldHVybiAtRU5PREVWOw0KIAl9DQogDQorCURSTV9MT0NLKCk7DQorCURSTV9ERUJV Rygic3RhcnRpbmcgc3VzcGVuZFxuIik7DQogCWk5MTVfc2F2ZV9zdGF0ZShkZXYpOw0KKwlEUk1f VU5MT0NLKCk7DQogDQogCXJldHVybiAoYnVzX2dlbmVyaWNfc3VzcGVuZChrZGV2KSk7DQogfQ0K QEAgLTYxLDcgKzY0LDEwIEBADQogew0KIAlzdHJ1Y3QgZHJtX2RldmljZSAqZGV2ID0gZGV2aWNl X2dldF9zb2Z0YyhrZGV2KTsNCiANCisJRFJNX0xPQ0soKTsNCisJRFJNX0RFQlVHKCJzdGFydGlu ZyByZXN1bWVcbiIpOw0KIAlpOTE1X3Jlc3RvcmVfc3RhdGUoZGV2KTsNCisJRFJNX1VOTE9DSygp Ow0KIA0KIAlyZXR1cm4gKGJ1c19nZW5lcmljX3Jlc3VtZShrZGV2KSk7DQogfQ0KSW5kZXg6IGRl di9kcm0vaTkxNV9pcnEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vaTkxNV9pcnEuYwkocmV2 aXNpb24gMTkwNDAyKQ0KKysrIGRldi9kcm0vaTkxNV9pcnEuYwkod29ya2luZyBjb3B5KQ0KQEAg LTIwNSw3ICsyMDUsNyBAQA0KIAlpaXIgPSBJOTE1X1JFQUQoSUlSKTsNCiANCiAJaWYgKElTX0k5 NjVHKGRldikpIHsNCi0JCXZibGFua19zdGF0dXMgPSBJOTE1X1NUQVJUX1ZCTEFOS19JTlRFUlJV UFRfU1RBVFVTOw0KKwkJdmJsYW5rX3N0YXR1cyA9IFBJUEVfU1RBUlRfVkJMQU5LX0lOVEVSUlVQ VF9TVEFUVVM7DQogCQl2YmxhbmtfZW5hYmxlID0gUElQRV9TVEFSVF9WQkxBTktfSU5URVJSVVBU X0VOQUJMRTsNCiAJfSBlbHNlIHsNCiAJCXZibGFua19zdGF0dXMgPSBJOTE1X1ZCTEFOS19JTlRF UlJVUFRfU1RBVFVTOw0KQEAgLTM0Myw2ICszNDMsOSBAQA0KIA0KIAlEUk1fREVCVUcoImlycV9u cj0lZCBicmVhZGNydW1iPSVkXG4iLCBpcnFfbnIsDQogCQkgIFJFQURfQlJFQURDUlVNQihkZXZf cHJpdikpOw0KKwlEUk1fREVCVUcoImllcjogJTA4eCwgaW1yOiAlMDh4LCBwaXBlYXN0YXQ6ICUw OHgsIHBpcGVic3RhdDogJTA4eFxuIiwNCisJICAgIEk5MTVfUkVBRChJRVIpLCBJOTE1X1JFQUQo SUVSKSwNCisJICAgIEk5MTVfUkVBRChQSVBFQVNUQVQpLCBJOTE1X1JFQUQoUElQRUJTVEFUKSk7 DQogDQogCWk5MTVfdXNlcl9pcnFfZ2V0KGRldik7DQogCURSTV9XQUlUX09OKHJldCwgZGV2X3By aXYtPmlycV9xdWV1ZSwgMyAqIERSTV9IWiwNCkBAIC00MDgsMTEgKzQxMSw4IEBADQogaW50IGk5 MTVfZW5hYmxlX3ZibGFuayhzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LCBpbnQgcGlwZSkNCiB7DQog CWRybV9pOTE1X3ByaXZhdGVfdCAqZGV2X3ByaXYgPSAoZHJtX2k5MTVfcHJpdmF0ZV90ICopIGRl di0+ZGV2X3ByaXZhdGU7DQotCWludCBwaXBlY29uZl9yZWcgPSAocGlwZSA9PSAwKSA/IFBJUEVB Q09ORiA6IFBJUEVCQ09ORjsNCi0JdTMyIHBpcGVjb25mOw0KIA0KLQlwaXBlY29uZiA9IEk5MTVf UkVBRChwaXBlY29uZl9yZWcpOw0KLQlpZiAoIShwaXBlY29uZiAmIFBJUEVBQ09ORl9FTkFCTEUp KQ0KKwlpZiAoIWk5MTVfcGlwZV9lbmFibGVkKGRldiwgcGlwZSkpDQogCQlyZXR1cm4gLUVJTlZB TDsNCiANCiAJRFJNX1NQSU5MT0NLKCZkZXZfcHJpdi0+dXNlcl9pcnFfbG9jayk7DQpJbmRleDog ZGV2L2RybS9kcm1faXJxLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBkZXYvZHJtL2RybV9pcnEuYwkocmV2 aXNpb24gMTkwNDMzKQ0KKysrIGRldi9kcm0vZHJtX2lycS5jCSh3b3JraW5nIGNvcHkpDQpAQCAt MzQ1LDEzICszNDUsMTEgQEANCiAJc3RydWN0IGRybV9tb2Rlc2V0X2N0bCAqbW9kZXNldCA9IGRh dGE7DQogCWludCBjcnRjLCByZXQgPSAwOw0KIA0KLQlEUk1fREVCVUcoIm51bV9jcnRjcz0lZFxu IiwgZGV2LT5udW1fY3J0Y3MpOw0KIAkvKiBJZiBkcm1fdmJsYW5rX2luaXQoKSBoYXNuJ3QgYmVl biBjYWxsZWQgeWV0LCBqdXN0IG5vLW9wICovDQogCWlmICghZGV2LT5udW1fY3J0Y3MpDQogCQln b3RvIG91dDsNCiANCiAJY3J0YyA9IG1vZGVzZXQtPmNydGM7DQotCURSTV9ERUJVRygiY3J0Yz0l ZFxuIiwgY3J0Yyk7DQogCWlmIChjcnRjID49IGRldi0+bnVtX2NydGNzKSB7DQogCQlyZXQgPSBF SU5WQUw7DQogCQlnb3RvIG91dDsNCkBAIC0zNjYsNyArMzY0LDcgQEANCiAJICovDQogCXN3aXRj aCAobW9kZXNldC0+Y21kKSB7DQogCWNhc2UgX0RSTV9QUkVfTU9ERVNFVDoNCi0JCURSTV9ERUJV RygicHJlLW1vZGVzZXRcbiIpOw0KKwkJRFJNX0RFQlVHKCJwcmUtbW9kZXNldCwgY3J0YyAlZFxu IiwgY3J0Yyk7DQogCQlpZiAoIWRldi0+dmJsYW5rW2NydGNdLmlubW9kZXNldCkgew0KIAkJCWRl di0+dmJsYW5rW2NydGNdLmlubW9kZXNldCA9IDB4MTsNCiAJCQlpZiAoZHJtX3ZibGFua19nZXQo ZGV2LCBjcnRjKSA9PSAwKQ0KQEAgLTM3NCw3ICszNzIsNyBAQA0KIAkJfQ0KIAkJYnJlYWs7DQog CWNhc2UgX0RSTV9QT1NUX01PREVTRVQ6DQotCQlEUk1fREVCVUcoInBvc3QtbW9kZXNldFxuIik7 DQorCQlEUk1fREVCVUcoInBvc3QtbW9kZXNldCwgY3J0YyAlZFxuIiwgY3J0Yyk7DQogCQlpZiAo ZGV2LT52YmxhbmtbY3J0Y10uaW5tb2Rlc2V0KSB7DQogCQkJRFJNX1NQSU5MT0NLKCZkZXYtPnZi bF9sb2NrKTsNCiAJCQlkZXYtPnZibGFua19kaXNhYmxlX2FsbG93ZWQgPSAxOw0KQEAgLTQ3Nyw2 ICs0NzUsOSBAQA0KIAkJCW10eF91bmxvY2soJmRldi0+aXJxX2xvY2spOw0KIAkJfQ0KIA0KKwkJ aWYgKHJldCA9PSBFV09VTERCTE9DSykNCisJCQlEUk1fRVJST1IoInRpbWVkIG91dCB3YWl0aW5n IG9uIHZibGFua1xuIik7DQorDQogCQlpZiAocmV0ICE9IEVJTlRSICYmIHJldCAhPSBFUkVTVEFS VCkgew0KIAkJCXN0cnVjdCB0aW1ldmFsIG5vdzsNCiANCkluZGV4OiBkZXYvZHJtL2RybV9zeXNj dGwuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vZHJtX3N5c2N0bC5jCShyZXZpc2lvbiAxOTA0 MDIpDQorKysgZGV2L2RybS9kcm1fc3lzY3RsLmMJKHdvcmtpbmcgY29weSkNCkBAIC0zOCw2ICsz OCw3IEBADQogc3RhdGljIGludAkgICBkcm1fdm1faW5mbyBEUk1fU1lTQ1RMX0hBTkRMRVJfQVJH UzsNCiBzdGF0aWMgaW50CSAgIGRybV9jbGllbnRzX2luZm8gRFJNX1NZU0NUTF9IQU5ETEVSX0FS R1M7DQogc3RhdGljIGludAkgICBkcm1fYnVmc19pbmZvIERSTV9TWVNDVExfSEFORExFUl9BUkdT Ow0KK3N0YXRpYyBpbnQJICAgZHJtX3ZibGFua19pbmZvIERSTV9TWVNDVExfSEFORExFUl9BUkdT Ow0KIA0KIHN0cnVjdCBkcm1fc3lzY3RsX2xpc3Qgew0KIAljb25zdCBjaGFyICpuYW1lOw0KQEAg LTQ3LDYgKzQ4LDcgQEANCiAJeyJ2bSIsCSAgICBkcm1fdm1faW5mb30sDQogCXsiY2xpZW50cyIs IGRybV9jbGllbnRzX2luZm99LA0KIAl7ImJ1ZnMiLCAgICBkcm1fYnVmc19pbmZvfSwNCisJeyJ2 YmxhbmsiLCAgICBkcm1fdmJsYW5rX2luZm99LA0KIH07DQogI2RlZmluZSBEUk1fU1lTQ1RMX0VO VFJJRVMgKHNpemVvZihkcm1fc3lzY3RsX2xpc3QpL3NpemVvZihkcm1fc3lzY3RsX2xpc3RbMF0p KQ0KIA0KQEAgLTMxMywzICszMTUsMjUgQEANCiAJZnJlZSh0ZW1wcHJpdnMsIERSTV9NRU1fRFJJ VkVSKTsNCiAJcmV0dXJuIHJldGNvZGU7DQogfQ0KKw0KK3N0YXRpYyBpbnQgZHJtX3ZibGFua19p bmZvIERSTV9TWVNDVExfSEFORExFUl9BUkdTDQorew0KKwlzdHJ1Y3QgZHJtX2RldmljZSAqZGV2 ID0gYXJnMTsNCisJY2hhciBidWZbMTI4XTsNCisJaW50IHJldGNvZGU7DQorCWludCBpOw0KKw0K KwlEUk1fU1lTQ1RMX1BSSU5UKCJcbmNydGMgcmVmIGNvdW50ICAgIGxhc3QgICAgIGVuYWJsZWQg aW5tb2Rlc2V0XG4iKTsNCisJZm9yKGkgPSAwIDsgaSA8IGRldi0+bnVtX2NydGNzIDsgaSsrKSB7 DQorCQlEUk1fU1lTQ1RMX1BSSU5UKCIgICUwMmQgICUwMmQgJTA4ZCAlMDhkICUwMmQgICAgICAl MDJkXG4iLA0KKwkJICAgIGksIGF0b21pY19yZWFkKCZkZXYtPnZibGFua1tpXS5yZWZjb3VudCks DQorCQkgICAgYXRvbWljX3JlYWQoJmRldi0+dmJsYW5rW2ldLmNvdW50KSwNCisJCSAgICBhdG9t aWNfcmVhZCgmZGV2LT52YmxhbmtbaV0ubGFzdCksDQorCQkgICAgYXRvbWljX3JlYWQoJmRldi0+ dmJsYW5rW2ldLmVuYWJsZWQpLA0KKwkJICAgIGF0b21pY19yZWFkKCZkZXYtPnZibGFua1tpXS5p bm1vZGVzZXQpKTsNCisJfQ0KKw0KKwlTWVNDVExfT1VUKHJlcSwgIiIsIC0xKTsNCitkb25lOg0K KwlyZXR1cm4gcmV0Y29kZTsNCit9DQo= --=-y8fcTc4EOZiPJ55QduKo-- --=-bx4tddrYyiuGGcswbPut Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknNQE4ACgkQM4TrQ4qfROPfnQCaAyc3MyGkmD79keZ+vnN/X2DH OUAAmgOVV8PRKlbftTfInwM1SUvWsU4K =i1Ol -----END PGP SIGNATURE----- --=-bx4tddrYyiuGGcswbPut-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 21:22:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F24C10656BA; Fri, 27 Mar 2009 21:22:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 708B28FC17; Fri, 27 Mar 2009 21:22:35 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so243514eyf.7 for ; Fri, 27 Mar 2009 14:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bIBG5zVZ35HALnDPPn1n+LyEPeY6rFsY+HQn3/JxJA0=; b=mYnnrU9634nlurhiJqXkBRx+71xhqKuP8iVS8dtj08ZJWFBDjwDl/Z3v4NKQgiT1/S OcHef+PC1IhbC1J1F1NXA9YHZoiu5emyr9GuOdplyjOR+/vrI8+yb/l6EJEYdPu4TRKE eLint0/zdaKhtxJ5AX4M1ZZI2N9D68jKeU8pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=w9UBT0a3D+X2AiN56/gQuqoHt9W34Muya25A/5hSGUNov4TOB3Fw39mcX6tueyKowZ JvKoocMNezFwtAegSPMIopuvqG581/SXszIq7BhPMjY7OOOskAwn5ukKrpXSmXQ4ImU8 j66KcTQMM4uGGLAv1+oBSMOVkkDq0BeY8LGCU= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr1914074ebs.93.1238188953910; Fri, 27 Mar 2009 14:22:33 -0700 (PDT) In-Reply-To: <200903272016.n2RKGZ1m001583@yoda.pixi.com> References: <200903272016.n2RKGZ1m001583@yoda.pixi.com> Date: Fri, 27 Mar 2009 22:22:33 +0100 Message-ID: <3a142e750903271422x6917ff87p663411f27fe63484@mail.gmail.com> From: "Paul B. Mahol" To: knowtree@aloha.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Intel 5100AGN ndis driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:22:37 -0000 On 3/27/09, knowtree@aloha.com wrote: > On 3/21/09, Ganbold wrote: >> Paul B. Mahol wrote: >>> On 3/19/09, Ganbold wrote: >>> >>>> Hi, >>>> >>>> I'm trying to use ndis driver for Intel 5100AGN and got >>>> following error: >>>> >>>> beastie# grep ndis /var/log/messages >>>> Mar 19 23:41:21 beastie kernel: ndis0: mem >>>> 0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3 >>>> Mar 19 23:41:21 beastie kernel: ndis0: [ITHREAD] >>>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS API version: 5.1 >>>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown >>>> error) >>>> >>>> Mar 19 23:41:21 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown >>>> error) >>>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x08ff product >>>> 0x2810 bus uhub1 >>>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x0a5c product >>>> 0x2145 bus uhub1 >>>> Mar 19 23:41:21 beastie root: Unknown USB device: vendor 0x17ef product >>>> 0x1004 bus uhub3 >>>> Mar 19 23:41:53 beastie kernel: ugen1.3: at >>>> usbus1 (disconnected) >>>> Mar 19 23:41:57 beastie kernel: ugen1.3: at >>>> usbus1 >>>> Mar 19 23:41:57 beastie root: Unknown USB device: vendor 0x0a5c product >>>> 0x2145 bus uhub1 >>>> Mar 19 23:45:36 beastie kernel: wlan0: Ethernet address: >>>> 00:21:6b:9a:23:8e >>>> Mar 19 23:52:02 beastie kernel: pid 9861 (initial thread) is using >>>> legacy pty devices >>>> Mar 20 00:08:06 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown >>>> error) >>>> ... >>>> ndis0 at pci0:3:0:0: class=0x028000 card=0x12118086 chip=0x42378086 >>>> rev=0x00 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> class = network >>>> >>>> I'm running: >>>> beastie# uname -an >>>> FreeBSD beastie.micom.mng.net 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >>>> r190040M: Thu Mar 19 21:45:37 ULAT 2009 >>>> tsgan at beastie.micom.mng.net:/usr/obj/usr/src/sys/DEVIL_WITNESS i386 >>>> >>>> >>>> Any idea how to fix this issue? >>>> Please let me know if you need more info. >>>> >>> >>> How you generate ndis module? >>> Post whole output _after_ is module loaded >>> _not_ just lines containing ndis. >>> >>> also enable debug.ndis sysctl. >>> >>I generated module issuing following command: >> >>ndisgen NETw5x32.inf NETw5x32.sys >> >>After module is generated, loading modules gives (debug.ndis=1): >> >> >>Mar 21 16:18:33 beastie kernel: no match for KeBugCheck >>Mar 21 16:18:33 beastie kernel: ndis0: mem >>0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3 >>Mar 21 16:18:33 beastie kernel: ndis0: [ITHREAD] >>Mar 21 16:18:33 beastie kernel: ndis0: NDIS API version: 5.1 >>Mar 21 16:18:33 beastie kernel: ndis0: NDIS ERROR: 40001b7c (unknown error) >>Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x08ff product >>0x2810 bus uhub1 >>Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x0a5c product >>0x2145 bus uhub1 >>Mar 21 16:18:33 beastie root: Unknown USB device: vendor 0x17ef product >>0x1004 bus uhub3 >>Mar 21 16:18:34 beastie kernel: attach done. >>Mar 21 16:18:35 beastie kernel: halting done. >> >>Ganbold > > I am seeing the exact same thing on 7.1-RELEASE, minus the USB errors. I > have the same Intel chipset in a Fujitsu T1010 laptop. I downloaded the XP > driver from Intel, had the same file names as above. When I ran ndisgen it > asked me for the names of the files even through I specified them on the > command line. Other than that the build process seemed fine. When I used > kldload to test it I got the unknown error message but the system seemed > happy so I set it up to load from loader.conf and added an entry for it in > /etc/rc.conf. When I rebooted the hardware probe hung at the ndis driver. > > After I managed to boot without the kernel module I tried again to load > with kldload. After the NDIS ERROR line I see > > WARNING: using obsoleted if_watchdog interface > > Next comes the MAC address, then a page fault followed by a reboot. I tried > it several times with same results. That panic should be fixed in CURRENT, if not, post backtrace from textdump for the start. > Is there anything I can do to help solve this? Again I am running 7.1 not > HEAD. Something in NDISulator initialization code looks to be broken, but current showstopper are error codes that are not documented anywhere. -- Paul From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 21:14:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E7D106564A; Fri, 27 Mar 2009 21:14:17 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 964C28FC1C; Fri, 27 Mar 2009 21:14:17 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms074.mailsrvcs.net ([172.18.12.133]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KH600L1ROBILXXO@vms173019.mailsrvcs.net>; Fri, 27 Mar 2009 16:14:06 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms074.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Mar 2009 16:14:06 -0500 (CDT) Date: Fri, 27 Mar 2009 16:14:06 -0500 (CDT) From: Sergey Babkin To: scottl@samsco.org Message-id: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Fri, 27 Mar 2009 21:52:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: babkin@verizon.net, freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:14:18 -0000 Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d= evice and mmap it, either in the on-load handler or on the first call of= gettimeofday(). I think, that should be it, no special magic nece= ssary. The per-process is more difficult and would require the magic= :-) Or maybe no magic a s such: just mmap the file from the /proc files= ystem. Then on fork in the child unmap this page, open the new file, and= map it. vfork will still be tricky :-) It also means wasting an extra p= age per process. -SB Mar 27, 2009 12:51:56 PM, [1]scottl@samsc= o.org wrote: I've been talking about this for years. All I need is help with = the VM magic to create the page on fork. I also want two pages, one gl= obal for gettimeofday (and any other global data we can think of) and on= e per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: > (Sorry for the top quoting). Probably the= best implementation of > gettimeofd=3Dy() is to have > a= page in the kernel mapped read-only to all the user pr=3Dcesses. Put &g= t; the kernel's idea of time > into this page. Then getting the= =3Dime becomes a simple read (OK, two > reads, to make sure that<= br>> no update =3Das happened in between). References 1. file://localhost/tmp/3D"mai= From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 21:52:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA3971065674 for ; Fri, 27 Mar 2009 21:52:55 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 68E4E8FC22 for ; Fri, 27 Mar 2009 21:52:54 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2RLqqAk027649 for ; Fri, 27 Mar 2009 22:52:53 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CD4AB4.8080006@fgznet.ch> Date: Fri, 27 Mar 2009 22:52:52 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Subject: usb issue Macbook Pro VM Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:52:56 -0000 Hello, I run a fbsd current in a vm instance on my MacBook Pro. Today I did the upgrade to todays sources. Now I get some annoying warnings from the usb stack: ---- FreeBSD 8.0-CURRENT #0 r190475M: Fri Mar 27 22:07:10 CET 2009 andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/export/devel/src/sys/ANDREAST_amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (2496.15-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xfebfbff Features2=0x80082201> AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant usable memory = 2133323776 (2034 MB) avail memory = 2060926976 (1965 MB) ... uhci0: port 0x2080-0x209f irq 18 at device 0.0 on pci2 uhci0: [ITHREAD] usbus0: on uhci0 ... usbus0: 12Mbps Full Speed USB v1.0 ... ugen0.1: at usbus0 uhub0: on usbus0 ... uhub0: 2 ports with 2 removable, self powered ... Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub1: 6 ports with 6 removable, self powered Root mount waiting for: usbus0 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! Root mount waiting for: usbus0 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) ---- The last lines above are repeating on the console. There is no 'known' usb device attached to the port. Means, I have nothing attached to the usb ports externally. If you need the full log, let me know. What else can I provide to help debugging? TIA, Andreas From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:19:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9841065674 for ; Fri, 27 Mar 2009 22:19:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2449F8FC14 for ; Fri, 27 Mar 2009 22:19:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C0EE646B06; Fri, 27 Mar 2009 18:19:35 -0400 (EDT) Date: Fri, 27 Mar 2009 22:19:35 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Prashant Vaibhav In-Reply-To: <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-714087570-1238192375=:60642" Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:19:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-714087570-1238192375=:60642 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 28 Mar 2009, Prashant Vaibhav wrote: > Actually OS X is more similar than that: the shared page also contains > functions that can be called by user applications, though their entry points > are fixed and they're not in any particular format like elf/mach-o. > Userspace implementations of gettimeofday, bcopy etc. are provided in the > kernel itself, which is a nice design imo as the specific version to load is > chosen by the kernel at boot time depending on processor capabilities. One cute thing about Linux exporting the page as ELF is that the dynamic linker just finds and links libc against it for the system call path. ELF is a fairly straight-forward format, so it's not a bad approach, although it does make the kernel side more complex. One downside, of course, is that it means the kernel has to export 32-bit code to 32-bit processes, 64-bit code to 64-bit processes, etc, if you want the higher performance stuff for 32-bit processes on 64-bit kernels, you have to build the exposed code as non-native code. Robert N M Watson Computer Laboratory University of Cambridge > > > > On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson wrote: > > On Fri, 27 Mar 2009, Scott Long wrote: > > I've been talking about this for years.  All I need > is help with the VM magic to create the page on > fork.  I also want two pages, one global for > gettimeofday (and any other global data we can think > of) and one per-process for static data like > getpid/getgid. > > > FWIW, there are some variations in schemes across OS's -- one extreme > is the Linux approach, which actually exports a mini shared library in > ELF format on the shared page, providing implementations of various > services (such as entering system calls), time stuff, etc.  Less > extreme are the shared pages offered on Mac OS X, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > > Scott > > > Sergey Babkin wrote: >   (Sorry for the top quoting). Probably the > best implementation of >   gettimeofd=y() is to have >   a page in the kernel mapped read-only to all > the user pr=cesses. Put >   the kernel's idea of time >   into this page. Then getting the =ime > becomes a simple read (OK, two >   reads, to make sure that >   no update =as happened in between). >   The TSC can then be used to add the > precis=on between the ticks of >   the kernel timer: >   i.e. remember the value of TS= when the last > tick happen, and the >   highest rate at which >   TSC may be ti=king at this CPU, and export > in the same page. This >   would guarantee thatthe time is not moving > back. >   However there are more issues with TS=. TSC > is guaranteed to have >   the same value >   on all the processors that s=are the same > system bus. But if the >   machine is built of multiple >   buses =ith bridges between them, all bets > are off. Each bus may be >   stopped, resta=ted >   and clocked separately. There is no way to > tell, on which CPU is th= >   process currently >   runnning, and it may be rescheduled do a > different C=U right before >   or after the RDTSC >   instruction. >   -SB >   Ma= 26, 2009 06:55:04 PM, > [1]phk@phk.freebsd.dk wrote: >        In message > <[2]17560ccf0903260551v1f5cba9eu8 > 7727c0bae7baa3@mail.gmail.com>, Prasha >     nt Vaibhav writes: >     =The gettimeofday() function's > implementation will then be >     >change= to read the timestamp counter > (TSC) from the processor, >     and use the >     &g=;reading in conjunction with the timing > info exported by the >     kernel to >     =calculate and return the time info in > proper format. >     I take it a= read, that you know that > there are other relvant >     functions than gettim=ofday() and that > these must provide a >     monotonic timescale when queried > =nterleaved ? >     Be aware that the TSC may not be, and may > not stay syn=hronized >     across multiple cores. >     Further more, the TSC is not con=tant > frequency and in particular >     not "known frequency" at all times. >     There are a lot of nasty cases to check, > and a nasty interpolation >     =equired, which, in my tests some years > back, totally negated any >     speedu= from using the TSC in the first > place. >     At the very minimum, you wi=l have to add > a quirk table where >     known good {CPU+MOBO+BIOS} combinatio=s > can be entered, as we >     find them. >     >This will also pave way f=r optionally > making the >     >FreeBSD kernel tickless, >     Rubbish. T=mecounters are not even closely > associated with the >     tick or ticklessnes= of the kernel. [1] >     > - The TSC frequency might change on > cert=in processors with >     non-constant >     > TSC rate (because of SpeedStep, =ynamic > freq scaling etc.). The >     only way to >     > combat this is that t=e kernel be > notified every time the >     processor >     > frequency changes.=very cpu frequency > driver will need to be >     updated to >     > notify the=ernel before and after a cpu > freq change. >     That is not good enough= the bios may > autonomously change the cpu >     speed >     and the skew from not k=owing exactly > _when_ and _how_ the cpu >     clock >     changed, is a significant =umber of > microseconds, plenty of time >     to make strange things happen. >     You will want to study carefully Dave > Mills work to tame the alpha >     =hips wandering SAW clocks. >     Poul-Henning >     [1] In my mind, rewo=king the callout > system in the kernel would >     be a much better more neded=nd much more > worthwhile project. >     -- >     Poul-Henning Kamp | =NIX since Zilog Zeus > 3.20 >     [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >     FreeBSD committer | BSD since 4.3-tahoe >     N=ver attribute to malice what can > adequately be explained by >     > incompetence.<=r>_______________________________________________ >     [4]freebsd-hackers@freebsd.org mailing > list >     > [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >     unsubscribe, send any mail to "[6]fre > ebsd-hackers-unsubscribe@freebsd.org" > > References > >   1. 3D"mailto:phk@phk.freebsd.dk" >   2. file://localhost/tmp/3D   3. > 3D"mailto:phk@FreeBSD.ORG" >   4. 3D"mailto:fre   5. 3D"http://lists.=/ >   6.3D"mailto:freebsd-hackers-unsub____________________________________________ > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > > --621616949-714087570-1238192375=:60642-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:37:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9CEC1065670 for ; Fri, 27 Mar 2009 22:37:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3840C8FC14 for ; Fri, 27 Mar 2009 22:37:03 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=ERj7cZBQa3v3bfvKvZQA:9 a=kBMsYxOEac8_PifLK7UA:7 a=x5mgpbIrDNsL3FLWUpKANC0DwLQA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1044471653; Fri, 27 Mar 2009 23:37:02 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 27 Mar 2009 23:39:31 +0100 User-Agent: KMail/1.9.7 References: <49CD4AB4.8080006@fgznet.ch> In-Reply-To: <49CD4AB4.8080006@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903272339.33763.hselasky@c2i.net> Cc: Andreas Tobler Subject: Re: usb issue Macbook Pro VM Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:37:05 -0000 On Friday 27 March 2009, Andreas Tobler wrote: > Hello, > > I run a fbsd current in a vm instance on my MacBook Pro. > > Today I did the upgrade to todays sources. > > Now I get some annoying warnings from the usb stack: > > ---- > FreeBSD 8.0-CURRENT #0 r190475M: Fri Mar 27 22:07:10 CET 2009 > > andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/export/devel/src/sys >/ANDREAST_amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (2496.15-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xfebfbff,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS> > Features2=0x80082201> > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > usable memory = 2133323776 (2034 MB) > avail memory = 2060926976 (1965 MB) > > ... > uhci0: port 0x2080-0x209f irq > 18 at device 0.0 on pci2 > uhci0: [ITHREAD] > usbus0: on uhci0 > ... > usbus0: 12Mbps Full Speed USB v1.0 > ... > ugen0.1: at usbus0 > uhub0: on usbus0 > ... > uhub0: 2 ports with 2 removable, self powered > ... > Root mount waiting for: usbus1 usbus0 > Root mount waiting for: usbus1 usbus0 > uhub1: 6 ports with 6 removable, self powered > Root mount waiting for: usbus0 > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > Root mount waiting for: usbus0 > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > uhub_reattach_port:413: could not allocate new device! > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > uhub_reattach_port:413: could not allocate new device! > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > > ---- > > The last lines above are repeating on the console. > > There is no 'known' usb device attached to the port. Means, I have > nothing attached to the usb ports externally. > > If you need the full log, let me know. > > What else can I provide to help debugging? Maybe the VM-ware accidentially reported a USB device and then it removed it. I don't know. There are some sysctl under hw.usb2 which you can turn on. sysctl hw.usb2 | grep debug uhub, uhci, and ehci is probably most interesting. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:37:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0570106566C; Fri, 27 Mar 2009 22:37:25 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 406F28FC0A; Fri, 27 Mar 2009 22:37:25 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n2RMaAO9058121; Fri, 27 Mar 2009 17:36:10 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n2RMaAM9058120; Fri, 27 Mar 2009 17:36:10 -0500 (CDT) (envelope-from brooks) Date: Fri, 27 Mar 2009 17:36:10 -0500 From: Brooks Davis To: Robert Watson Message-ID: <20090327223610.GA58090@lor.one-eyed-alien.net> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 27 Mar 2009 17:36:10 -0500 (CDT) Cc: freebsd-current@freebsd.org, Prashant Vaibhav Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:37:26 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 27, 2009 at 10:19:35PM +0000, Robert Watson wrote: >=20 > On Sat, 28 Mar 2009, Prashant Vaibhav wrote: >=20 >> Actually OS X is more similar than that: the shared page also contains= =20 >> functions that can be called by user applications, though their entry=20 >> points are fixed and they're not in any particular format like elf/mach-= o.=20 >> Userspace implementations of gettimeofday, bcopy etc. are provided in th= e=20 >> kernel itself, which is a nice design imo as the specific version to loa= d=20 >> is chosen by the kernel at boot time depending on processor capabilities. >=20 > One cute thing about Linux exporting the page as ELF is that the dynamic= =20 > linker just finds and links libc against it for the system call path. EL= F=20 > is a fairly straight-forward format, so it's not a bad approach, although= =20 > it does make the kernel side more complex. One downside, of course, is= =20 > that it means the kernel has to export 32-bit code to 32-bit processes,= =20 > 64-bit code to 64-bit processes, etc, if you want the higher performance= =20 > stuff for 32-bit processes on 64-bit kernels, you have to build the expos= ed=20 > code as non-native code. Either way, I suspect we really want a function based interface because the= n we have a layer of insulation between the kernel and userspace. Without this, we're stuck providing any bits in the shared page forever to support old binaries. -- Brooks > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 >=20 >>=20 >>=20 >>=20 >> On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson wr= ote: >>=20 >> On Fri, 27 Mar 2009, Scott Long wrote: >>=20 >> I've been talking about this for years. ??All I need >> is help with the VM magic to create the page on >> fork. ??I also want two pages, one global for >> gettimeofday (and any other global data we can think >> of) and one per-process for static data like >> getpid/getgid. >>=20 >>=20 >> FWIW, there are some variations in schemes across OS's -- one extreme >> is the Linux approach, which actually exports a mini shared library in >> ELF format on the shared page, providing implementations of various >> services (such as entering system calls), time stuff, etc. ??Less >> extreme are the shared pages offered on Mac OS X, etc. >>=20 >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >>=20 >>=20 >>=20 >> Scott >>=20 >>=20 >> Sergey Babkin wrote: >> ?? (Sorry for the top quoting). Probably the >> best implementation of >> ?? gettimeofd=3Dy() is to have >> ?? a page in the kernel mapped read-only to all >> the user pr=3Dcesses. Put >> ?? the kernel's idea of time >> ?? into this page. Then getting the =3Dime >> becomes a simple read (OK, two >> ?? reads, to make sure that >> ?? no update =3Das happened in between). >> ?? The TSC can then be used to add the >> precis=3Don between the ticks of >> ?? the kernel timer: >> ?? i.e. remember the value of TS=3D when the last >> tick happen, and the >> ?? highest rate at which >> ?? TSC may be ti=3Dking at this CPU, and export >> in the same page. This >> ?? would guarantee thatthe time is not moving >> back. >> ?? However there are more issues with TS=3D. TSC >> is guaranteed to have >> ?? the same value >> ?? on all the processors that s=3Dare the same >> system bus. But if the >> ?? machine is built of multiple >> ?? buses =3Dith bridges between them, all bets >> are off. Each bus may be >> ?? stopped, resta=3Dted >> ?? and clocked separately. There is no way to >> tell, on which CPU is th=3D >> ?? process currently >> ?? runnning, and it may be rescheduled do a >> different C=3DU right before >> ?? or after the RDTSC >> ?? instruction. >> ?? -SB >> ?? Ma=3D 26, 2009 06:55:04 PM, >> [1]phk@phk.freebsd.dk wrote: >> ?? ?? ?? ??In message >> <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3@mail.gmail.com>, Prasha >> ?? ?? nt Vaibhav writes: >> ?? ?? =3DThe gettimeofday() function's >> implementation will then be >> ?? ?? >change=3D to read the timestamp counter >> (TSC) from the processor, >> ?? ?? and use the >> ?? ?? &g=3D;reading in conjunction with the timing >> info exported by the >> ?? ?? kernel to >> ?? ?? =3Dcalculate and return the time info in >> proper format. >> ?? ?? I take it a=3D read, that you know that >> there are other relvant >> ?? ?? functions than gettim=3Dofday() and that >> these must provide a >> ?? ?? monotonic timescale when queried >> =3Dnterleaved ? >> ?? ?? Be aware that the TSC may not be, and may >> not stay syn=3Dhronized >> ?? ?? across multiple cores. >> ?? ?? Further more, the TSC is not con=3Dtant >> frequency and in particular >> ?? ?? not "known frequency" at all times. >> ?? ?? There are a lot of nasty cases to check, >> and a nasty interpolation >> ?? ?? =3Dequired, which, in my tests some years >> back, totally negated any >> ?? ?? speedu=3D from using the TSC in the first >> place. >> ?? ?? At the very minimum, you wi=3Dl have to add >> a quirk table where >> ?? ?? known good {CPU+MOBO+BIOS} combinatio=3Ds >> can be entered, as we >> ?? ?? find them. >> ?? ?? >This will also pave way f=3Dr optionally >> making the >> ?? ?? >FreeBSD kernel tickless, >> ?? ?? Rubbish. T=3Dmecounters are not even closely >> associated with the >> ?? ?? tick or ticklessnes=3D of the kernel. [1] >> ?? ?? > - The TSC frequency might change on >> cert=3Din processors with >> ?? ?? non-constant >> ?? ?? > TSC rate (because of SpeedStep, =3Dynamic >> freq scaling etc.). The >> ?? ?? only way to >> ?? ?? > combat this is that t=3De kernel be >> notified every time the >> ?? ?? processor >> ?? ?? > frequency changes.=3Dvery cpu frequency >> driver will need to be >> ?? ?? updated to >> ?? ?? > notify the=3Dernel before and after a cpu >> freq change. >> ?? ?? That is not good enough=3D the bios may >> autonomously change the cpu >> ?? ?? speed >> ?? ?? and the skew from not k=3Dowing exactly >> _when_ and _how_ the cpu >> ?? ?? clock >> ?? ?? changed, is a significant =3Dumber of >> microseconds, plenty of time >> ?? ?? to make strange things happen. >> ?? ?? You will want to study carefully Dave >> Mills work to tame the alpha >> ?? ?? =3Dhips wandering SAW clocks. >> ?? ?? Poul-Henning >> ?? ?? [1] In my mind, rewo=3Dking the callout >> system in the kernel would >> ?? ?? be a much better more neded=3Dnd much more >> worthwhile project. >> ?? ?? -- >> ?? ?? Poul-Henning Kamp | =3DNIX since Zilog Zeus >> 3.20 >> ?? ?? [3]phk@FreeBSD.ORG | TCP=3DIP since RFC 956 >> ?? ?? FreeBSD committer | BSD since 4.3-tahoe >> ?? ?? N=3Dver attribute to malice what can >> adequately be explained by >> ?? ?? >> incompetence.<=3Dr>_________________________________________= ______ >> ?? ?? [4]freebsd-hackers@freebsd.org mailing >> list >> ?? ?? >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackers= To >> ?? ?? unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe@freebsd.org" >>=20 >> References >>=20 >> ?? 1. 3D"mailto:phk@phk.freebsd.dk" >> ?? 2. file://localhost/tmp/3D ?? 3. >> 3D"mailto:phk@FreeBSD.ORG" >> ?? 4. 3D"mailto:fre ?? 5. 3D"http://lists.=3D/ >> ?? 6.3D"mailto:freebsd-hackers-unsub________________________= ____________________ >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJzVTZXY6L6fI4GtQRAoh1AJ9mQRsh0uYKBYCYjRq4z2qdAe+oZQCfZaTy qqkeccekwxbFjWvg+wKGpqI= =dQO7 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:39:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163F01065675 for ; Fri, 27 Mar 2009 22:39:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id A1ED78FC1A for ; Fri, 27 Mar 2009 22:39:30 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=RXU8rH1-GXzFeLofioUA:9 a=Iq6T14F4KmCvT5u858oA:7 a=VtVivex77SmfUhW-XOd3pGFExhkA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1221249193; Fri, 27 Mar 2009 23:39:28 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 27 Mar 2009 23:41:58 +0100 User-Agent: KMail/1.9.7 References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> In-Reply-To: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903272341.58463.hselasky@c2i.net> Cc: Nikolay Denev Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:39:32 -0000 On Friday 27 March 2009, Nikolay Denev wrote: > Hello, > > I'm running -current from 23.03.09 and I'm experiencing some axe(4) > problems. > Basically the network connection works but when some more serious > traffic hits the > interface (i.e. torrent download) it then dies, ifconfig down/up > does not help, only replugging of the adapter. > > I've tried running with hw.usb2.axe.debug=15 and the output was many > lines of: > > axe_bulk_write_callback:853: transfer complete > > then a pause of several seconds and the kernel begins to print : > > axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT If you start seeing timeouts, then the device has probably died. What happens if you try: usbconfig -u XXX -a YYY reset where XXX and YYY matches the numbers after "ugen" for your device. NOTE: The if-net link will be reset. --HPS > > Another strange thing that I noticed is that, while the interface > seems to be > connected and working, if I type many times ifconfig ue0 consecutively > most of the time it would show different settings for the auto > negotiated link. > I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, > 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. > > The switch does not seem to register link flaps. > > The kernel messages for the interface are : > > ugen2.5: at usbus2 > axe0: on usbus2 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:11:50:xx:xx:xx > > devinfo -vr | grep phy > ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:41:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9C010656C7 for ; Fri, 27 Mar 2009 22:41:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 8B0118FC1E for ; Fri, 27 Mar 2009 22:41:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 47560 invoked by uid 60001); 27 Mar 2009 22:41:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238193712; bh=dwub4tQW6k8U0LzkbNNAiMbOiFqOX+DUBUmUmr5D1rY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=H+GGtaQq+kYbox6X2+7RuUFpwyDfSqzuJZDLHXyhlLTp/0uhHeaFDvoWF7pKK0Bb9c5aUL0JrCl4/CeqOfVxyjmuberldvfX7i02NoeJlLctIHQv2r/id8uK5nCzVhm5Zsr3Lm/p4+7KpNjqYk7JfXGKXm0eP8+Pv1MojLvfVuw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qU6QS9Su38o+LA8hgk4W3HDWofLw2lOWusB8DILiimc7eulJljsssLx2JjXKemg3UXT33nLL9IN4UGKR3mDbdxtKLseSa2rtJ/qVuHH/QJruO92eyRj3QGashaR+WI6T8Q3b+o4m7Y/sStHMf6O/KBCTzG3i/GjEOiMVo9TahDI=; Message-ID: <993085.47554.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: cDkAPcMVM1nFBt6hzZ7MvNVqFN2ijQg6wPPA3s0RH66_Yx9xyn7TRwZnVjB04jaBiVD_2KyVO2o_6l1IDeIwNnJrXULcDSZ3fsVJhWz84VeixcRFr6pgm31wZ8m4yZ5QLQVbkzmlQp5XYS2dVmjBhMw8I4JlPLwfD9S39eglMISPHFxx_Rojjme.JVC3F_zdxlZXkdpe9pp9rYz7bbsYKmZ4dne9YLsluPc_IsaCG_WdPVjy_kZ97vcGuvm_eqIG4F2JV_vc_3bbqakxkVk- Received: from [98.242.222.229] by web63903.mail.re1.yahoo.com via HTTP; Fri, 27 Mar 2009 15:41:51 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 15:41:51 -0700 (PDT) From: Barney Cordoba To: Robert Watson , Ed Schouten In-Reply-To: <20090327191423.GN73108@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mail25@bzerk.org, current@freebsd.org Subject: Re: Telnet root login X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:41:54 -0000 --- On Fri, 3/27/09, Ed Schouten wrote: > From: Ed Schouten > Subject: Re: Telnet root login > To: "Robert Watson" > Cc: "Barney Cordoba" , mail25@bzerk.org, current@freebsd.org > Date: Friday, March 27, 2009, 3:14 PM > * Robert Watson wrote: > > This seems to fix the problem for me -- thanks Ed! > > I've just committed the fix to SVN. Thanks for > reporting the issue and > debugging it for me. > I patched it into what I have and it works nicely. Thanks for the support. Barney From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 22:59:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675331065677; Fri, 27 Mar 2009 22:59:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 271F88FC08; Fri, 27 Mar 2009 22:59:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CDF7A46B53; Fri, 27 Mar 2009 18:59:39 -0400 (EDT) Date: Fri, 27 Mar 2009 22:59:39 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sergey Babkin In-Reply-To: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> Message-ID: References: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:59:40 -0000 On Fri, 27 Mar 2009, Sergey Babkin wrote: > Would not a normal mmap be duplicated on fork? I'd do it as a small > pseudo-= driver > that allows to mmap this page. Then libc would open this pseudo-d= > evice and mmap it, > either in the on-load handler or on the first call of= > gettimeofday(). I think, that should > be it, no special magic nece= ssary. > The per-process is more difficult and would require the magic= :-) Or > maybe > no magic a s such: just mmap the file from the /proc files= ystem. > Then on fork > in the child unmap this page, open the new file, and= map it. vfork > will still be tricky :-) > It also means wasting an extra p= age per process. Part of the point of mapping in the page at execve()-time, or fork()-time for per-process pages (which I'm not entirely convinced we need yet) is to avoid the cost of an extra device open, mmap, etc, for every execve(), which can be quite expensive. I stuck a prototype page mapped from a special device exporting time information here a year or two ago: http://www.watson.org/~robert/freebsd/20080203-evilmem.diff http://www.watson.org/~robert/freebsd/evilmem_test.c This doesn't do TSC-based adjustment, just drops a timestamp in from the callout wheel, but was intended to allow Kris to do a bit of comparative benchmarking and decide if it might be a viable approach to invest further work in. Obviously, the above code should never, ever, get near a production kernel, since it was a 2-hour hack for experimental purposes. I think the right way forward is to prototype: map the page in at execve()-time in the kernel and pass the address to rtld via elf auxiliary arguments, and have rtld link it (via some or another means), exposing symbols or code or whatever, to libc. If someone wants to make it a dynamic shared object in ELF-speak, then I'm all for that as it would minimize the work rtld had to do. I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page. Robert N M Watson Computer Laboratory University of Cambridge > -SB > Mar 27, 2009 12:51:56 PM, [1]scottl@samsc= o.org wrote: > > I've been talking about this for years. All I need is help with = > the VM > magic to create the page on fork. I also want two pages, one gl= > obal > for gettimeofday (and any other global data we can think of) and > on= e > per-process for static data like getpid/getgid. > Scott > Sergey Babkin wrote: > > (Sorry for the top quoting). Probably the= best implementation of > > gettimeofd=3Dy() is to have > > a= page in the kernel mapped read-only to all the user > pr=3Dcesses. Put > &g= t; the kernel's idea of time > > into this page. Then getting the= =3Dime becomes a simple read > (OK, two > > reads, to make sure that<= br>> no update =3Das happened in > between). > > > References > > 1. file://localhost/tmp/3D"mai= > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 23:02:05 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123891065686; Fri, 27 Mar 2009 23:02:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C3F448FC24; Fri, 27 Mar 2009 23:02:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 94FAD78CCD; Fri, 27 Mar 2009 23:02:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RN22tw007320; Fri, 27 Mar 2009 23:02:02 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 22:59:39 GMT." Date: Fri, 27 Mar 2009 23:02:02 +0000 Message-ID: <7319.1238194922@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 23:02:06 -0000 In message , Robert Wats on writes: >I guess interesting questions are whether (a) it would be desirable to have >per-page, per-cpu, or per-thread mappings. If there are non-synchronized >TSCs, then there might be some interesting advantages to a per-CPU page. Rule #3: The only thing worse than generalizing from one example is generalizing from no examples at all. We can add those mappings when we know why we would want them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 23:05:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18DA71065674 for ; Fri, 27 Mar 2009 23:05:04 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCAF8FC20 for ; Fri, 27 Mar 2009 23:05:03 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fxm11 with SMTP id 11so1172967fxm.43 for ; Fri, 27 Mar 2009 16:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2OnBFbQwFGUl2yHQNaEqvmd8FfzS7Eps7lHWwLlm24=; b=hj0TRraZdE4goSJj3+at46IBBdL6nL8FJjFqocuMgEtlKMIchYlO/yESpV+6i+C4se DS4hcWYBjUW4evmKfS+N9EhSrTXSmt9tRNTL0rSVSryVwML8Ap78il70WSzKzrCSU7I+ cXuEM2C3rcuMInNnwOL8+86szWJWrQUF1eVHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q6TLv1T/Kx/sJtwV+IsS5PjPF/mTQTWTSfl9+TaO2ieTTmBEph9MlGh06/jhupL3vV CVuA2NgGrlveVV37SjngdGfD1WRwJnh86PzjcXyUkbFVVwSaCo+N2TqvDuObTkXk4TvN Sm0AkechqkLBkIwrMpdQTzwcvH0iWxzovl4Q4= MIME-Version: 1.0 Received: by 10.223.119.198 with SMTP id a6mr2097016far.42.1238195102440; Fri, 27 Mar 2009 16:05:02 -0700 (PDT) In-Reply-To: <200903272341.58463.hselasky@c2i.net> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <200903272341.58463.hselasky@c2i.net> Date: Sat, 28 Mar 2009 01:05:02 +0200 Message-ID: <2e77fc10903271605m6a15e21el6ccd2af6e0da086a@mail.gmail.com> From: Niki Denev To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 23:05:05 -0000 On Sat, Mar 28, 2009 at 12:41 AM, Hans Petter Selasky wrote: > > If you start seeing timeouts, then the device has probably died. What happens > if you try: > > usbconfig -u XXX -a YYY reset > > where XXX and YYY matches the numbers after "ugen" for your device. > > NOTE: The if-net link will be reset. > > --HPS > When I did this the result was pretty much as with replugging the device. It detached/attached and then I was able to use it again. P.S.: Another thing i noticed is that i get about 20% packet loss. I don't think it's the device or the cable because I can use it without problems under OS X. -- Regards, Niki From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 23:05:35 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678081065679; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 414CB8FC1C; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EFE0646B53; Fri, 27 Mar 2009 19:05:34 -0400 (EDT) Date: Fri, 27 Mar 2009 23:05:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <7319.1238194922@critter.freebsd.dk> Message-ID: References: <7319.1238194922@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 23:05:37 -0000 On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: > In message , Robert Wats > on writes: > >> I guess interesting questions are whether (a) it would be desirable to have >> per-page, per-cpu, or per-thread mappings. If there are non-synchronized >> TSCs, then there might be some interesting advantages to a per-CPU page. > > Rule #3: > The only thing worse than generalizing from one example is > generalizing from no examples at all. > > We can add those mappings when we know why we would want them. If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. In which case user application threads will need to know their CPU in order to use the right conversion data (ideally without a system call, since that's part of what we're avoiding here), or use a per-CPU mapping and not know (in which case they'll need to detect and handle the very rare "preempted and migrated between read TSC and read conversion data" race). I'm not pushing a per-CPU page, but there would be some interesting advantages to supporting that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 23:10:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFB611065674; Fri, 27 Mar 2009 23:10:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1508FC12; Fri, 27 Mar 2009 23:10:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 99EFA78CC9; Fri, 27 Mar 2009 23:10:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RNAcxj007363; Fri, 27 Mar 2009 23:10:38 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 23:05:34 GMT." Date: Fri, 27 Mar 2009 23:10:38 +0000 Message-ID: <7362.1238195438@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 23:10:40 -0000 In message , Robert Wats on writes: >In which case user application threads will need to >know their CPU [...] Didn't jemalloc solve that problem once already ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 00:08:42 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF61E106564A; Sat, 28 Mar 2009 00:08:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A9CD78FC17; Sat, 28 Mar 2009 00:08:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 360CC46B45; Fri, 27 Mar 2009 20:08:42 -0400 (EDT) Date: Sat, 28 Mar 2009 00:08:42 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <7362.1238195438@critter.freebsd.dk> Message-ID: References: <7362.1238195438@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 00:08:43 -0000 On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: > In message , Robert > Wats on writes: > >> In which case user application threads will need to know their CPU [...] > > Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in the strict sense, but I may misread. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 00:45:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8850106566B; Sat, 28 Mar 2009 00:45:27 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id A583B8FC15; Sat, 28 Mar 2009 00:45:27 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTPA id 1299850819; Fri, 27 Mar 2009 17:31:16 -0700 (PDT) Message-ID: <49CD6E90.6050303@FreeBSD.org> Date: Fri, 27 Mar 2009 17:25:52 -0700 From: Jason Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Robert Watson References: <7362.1238195438@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, Poul-Henning Kamp , freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 00:45:28 -0000 Robert Watson wrote: > On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >> In message , >> Robert Wats on writes: >> >>> In which case user application threads will need to know their CPU [...] >> >> Didn't jemalloc solve that problem once already ? > > I think jemalloc implements thread-affinity for arenas rather than > CPU-affinity in the strict sense, but I may misread. CPU affinity is of limited use to malloc unless it can safely pin threads to CPUs. Unfortunately, malloc cannot muck with CPU affinity, since that's up to the application. Therefore, as you say, jemalloc implements (dynamically balanced) arena affinity. It might work okay in practice to use the current CPU ID to decide which arena to use, if the scheduler does not often migrate running processes. I haven't explored that possibility though, since the infrastructure for cheaply querying the CPU ID doesn't currently (to my knowledge) exist. Jason From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 01:20:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA96D106566B for ; Sat, 28 Mar 2009 01:20:48 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC7C8FC18 for ; Sat, 28 Mar 2009 01:20:47 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.38,435,1233529200"; d="scan'208";a="2203792" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 28 Mar 2009 02:20:46 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id D72391B07E2; Sat, 28 Mar 2009 02:20:46 +0100 (CET) Date: Sat, 28 Mar 2009 02:20:46 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <20090130224507.60650747@gluon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran Subject: Re: fdisk: Class not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 01:20:49 -0000 i've loaded geom_mbr, but now i get this message: fdisk: conflict with open slices fdisk: Failed to write sector zero Bruce Cran schrieb am 2009-01-30: > On Sun, 18 Jan 2009 15:07:24 +0100 (CET) > Alexander Best wrote: > > when i'm trying to do the following: > > fdisk -B adX > > i get the following error message: > > fdisk: Class not found > > fdisk: Failed to write sector zero > > i'm running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #0 > > r187392M: Sun Jan 18 14:42:30 UTC 2009 > > root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 and rebuild and > > reinstalled fdisk. > It seems that message is generated when geom_mbr isn't loaded. I was > running fdisk against an md(4) disk and after loading geom_mbr I got > a > new message saying it couldn't find geom "md0". The new partition > table showed up when I ran fdisk again, but after detaching and > reattaching using mdconfig the changes hadn't been saved. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 01:38:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688761065672 for ; Sat, 28 Mar 2009 01:38:30 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id F10B08FC1A for ; Sat, 28 Mar 2009 01:38:29 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.38,435,1233529200"; d="scan'208";a="212444604" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 28 Mar 2009 02:38:28 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id BC6831B07E2; Sat, 28 Mar 2009 02:38:28 +0100 (CET) Date: Sat, 28 Mar 2009 02:38:28 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <20090321200441.573995af@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: weird console output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 01:38:30 -0000 so. shouldn't this be in CURRENT? Gary Jennejohn schrieb am 2009-03-21: > On Sat, 21 Mar 2009 14:52:59 -0400 > Chuck Robey wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > Gary Jennejohn wrote: > > > On Fri, 20 Mar 2009 20:49:08 -0400 > > > Justin Hibbits wrote: > > >> On Sat, Mar 21, 2009 at 01:02:25AM +0100, Alexander Best wrote: > > >>> very often when i boot or shutdown my pc i see weird text being > > >>> output to the > > >>> console. to me it seems like 2 messages are being mixed into 1 > > >>> message. here's > > >>> an example: > > >>> "WcAdR0N IaNtG : aWtIaT1N EbSuSs o0p ttiaorng eetn a1b lleudn, > > >>> 0e > > >>> xcpde0c:t r > >>> H1W0ANR NJILN1G: DIAG2N>O SRTeImCo voapbtlieo nC De-nRaObMl > > >>> eSdC,S Ie-x0p > > >>> edcetv irceed uc > > >>> ecdd 0p:e r3f3o.r0m0a0nMcB/es. > > >>> transfers" > > >>> i'm running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT > > >>> #20 r190162M: > > >>> Fri Mar 20 19:10:47 UTC 2009 > > >>> root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL > > >>> i386, but i've also had this issue under CURRENT. maybe this > > >>> issue is smp > > >>> related? > > >>> cheers. > > >>> alex > > >> You are correct, it is smp related. Those are two messages > > >> interlaced. I see > > >> them often when shutting down my SMP system. > > > This quesion is asked and answered again and again. > > > Set "options PRINTF_BUFR_SIZE=128" in your kernel config. > > Gary, do you know why setting it to 128 fixes things? Is the > > default size 0? I > > could see that causing things, but it's hard to believe. I've been > > watching a > > long time to see a fix for this. > Looking at /sys/kern/subr_prf.c, there's apparently no buffering at > all > when PRINTF_BUFR_SIZE isn't defined. The value 128 has proved itself > to be adequate based on experience since most kernel output is > smaller > than that. Its' what I and others use. > --- > Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 03:00:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13EA7106564A for ; Sat, 28 Mar 2009 03:00:14 +0000 (UTC) (envelope-from rohit.trip@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id C6A108FC08 for ; Sat, 28 Mar 2009 03:00:13 +0000 (UTC) (envelope-from rohit.trip@gmail.com) Received: by gxk24 with SMTP id 24so3553530gxk.19 for ; Fri, 27 Mar 2009 20:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=UOz1dUDne4mCvIolUiahbZgl/1GDmbRBObjt1UPp9fk=; b=DxqYhUFfGh31Sp8jXeo2q0OouytpTTo18Xx5h9+bykwSUQDLZ9xiG56vHyU+SWho0w qFDBQXCMhvPawiIz71MDvkboP86gjx5wWXDliP47INUpdX0IiIhM2oLGX9CmZYb1lmSD Byc6QUZqDAqEs2M1EudI+asDi2TgFARcEwyDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=LgUNmd/QP1Y4zQ6fPzkdZcC7GyARNA8/YH4JfZzfsMth19aSDC9I3P3FTDAhDtwF39 rETQAHWvCBufWmdnS55DBtxcGNd0nr2GSkpOKza3QxozLEUm81G8ljZ/d31ZvPn71+WR z0AHB2W9QqlbP+i57+kKv0h0kt9giAXFphNJM= MIME-Version: 1.0 Received: by 10.90.63.6 with SMTP id l6mr1531431aga.46.1238207478676; Fri, 27 Mar 2009 19:31:18 -0700 (PDT) Date: Fri, 27 Mar 2009 22:31:18 -0400 Message-ID: <33615c8e0903271931i325d91ebw36d94da72a10b0e8@mail.gmail.com> From: Rohit Tripathi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: xvid port in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 03:00:14 -0000 Got a build error, not sure if this is the right group to report to: tp# make install ===> Installing for xvid-1.2.1,1 ===> Generating temporary packing list ===> Checking if multimedia/xvid already installed make: don't know how to make =build/libxvidcore.a. Stop *** Error code 2 Stop in /usr/ports/multimedia/xvid. *** Error code 1 Stop in /usr/ports/multimedia/xvid. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 07:09:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6A72106566C for ; Sat, 28 Mar 2009 07:09:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3B14F8FC13 for ; Sat, 28 Mar 2009 07:09:33 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=r2SycHtEuaZynCfv9BEA:9 a=FwXJzMVIyLZjkmiwZvoA:7 a=9O-p9g8B7KwPvq1tOOXL4Hn3WMIA:4 a=LY0hPdMaydYA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1047787816; Sat, 28 Mar 2009 08:09:32 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 08:12:03 +0100 User-Agent: KMail/1.9.7 References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <200903272341.58463.hselasky@c2i.net> <2e77fc10903271605m6a15e21el6ccd2af6e0da086a@mail.gmail.com> In-Reply-To: <2e77fc10903271605m6a15e21el6ccd2af6e0da086a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903280812.03675.hselasky@c2i.net> Cc: pyunyh@gmail.com, Niki Denev Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 07:09:35 -0000 On Saturday 28 March 2009, Niki Denev wrote: > On Sat, Mar 28, 2009 at 12:41 AM, Hans Petter Selasky wrote: > > If you start seeing timeouts, then the device has probably died. What > > happens if you try: > > > > usbconfig -u XXX -a YYY reset > > > > where XXX and YYY matches the numbers after "ugen" for your device. > > > > NOTE: The if-net link will be reset. > > > > --HPS > > When I did this the result was pretty much as with replugging the device. > It detached/attached and then I was able to use it again. > > P.S.: Another thing i noticed is that i get about 20% packet loss. I don't > think it's the device or the cable because I can use it without problems > under OS X. > Then it's probably something in the driver. You should discuss it with the author of the driver. See CC. --HPS > -- > Regards, > Niki > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 08:10:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A7AD106566C for ; Sat, 28 Mar 2009 08:10:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id A36728FC13 for ; Sat, 28 Mar 2009 08:10:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1017828tia.3 for ; Sat, 28 Mar 2009 01:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ahsVBpFADPD26fodtd36oFbamZHi3+3WckLhZYUECGY=; b=YCiseLET5ureSwtYV4SaVChBeHpUgoBVcVtsSk/YqdHjtuYXqiwBtNTomGgqtkVCEp QXx2x3uWSo8lbhIouG2JVMU10h2IlDMDOJx8yteT8L8MeUf4XVAN9TR2PP46fDSbcQ6x L5XzwGq2WEV71/QoqftSJucQI9lb42RuKWehA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=VYNcneUWeeJ6YCVsu1OFDm6BjKRXEHftcQ8myKgyG2nu2nDCNpvaI3YkkSmMLGUTtO 5+ROIirwRsIfV7lVYhQiE2lODEef9PULLhZFCj1gCCXmn58tIvdTAjbAehnDFShNqK+9 6KzvwfUvQTDgsCG+RuBYjVvZ4x3avQHiTedvU= Received: by 10.110.42.17 with SMTP id p17mr4317801tip.36.1238227850257; Sat, 28 Mar 2009 01:10:50 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id u8sm4047830tia.30.2009.03.28.01.10.48 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 01:10:49 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 28 Mar 2009 17:09:25 +0900 From: Pyun YongHyeon Date: Sat, 28 Mar 2009 17:09:24 +0900 To: Nikolay Denev Message-ID: <20090328080924.GD99923@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 08:10:52 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I'm running -current from 23.03.09 and I'm experiencing some axe(4) > problems. > Basically the network connection works but when some more serious > traffic hits the > interface (i.e. torrent download) it then dies, ifconfig down/up > does not help, only replugging of the adapter. > > I've tried running with hw.usb2.axe.debug=15 and the output was many > lines of: > > axe_bulk_write_callback:853: transfer complete > > then a pause of several seconds and the kernel begins to print : > > axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT > > Another strange thing that I noticed is that, while the interface > seems to be > connected and working, if I type many times ifconfig ue0 consecutively > most of the time it would show different settings for the auto > negotiated link. > I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, > 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. > > The switch does not seem to register link flaps. > axe(4) requires exact link state/speed information from mii(4) to reprogram controller to resolved speed/duplex. In this case ukphy(4) seems to report fake link state/speed to axe(4). > The kernel messages for the interface are : > > ugen2.5: at usbus2 > axe0: on usbus2 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:11:50:xx:xx:xx > > devinfo -vr | grep phy > ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 > This looks like Agere systems ET110C TruePHY. Would you try attached patch? Because truephy(4) pokes some undocumented PHY registers on PHY reset I'm not sure this model also requires that magic to make it work though. --cWoXeonUoKmBZSoM Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mii.ET110C.patch" Index: sys/dev/mii/truephy.c =================================================================== --- sys/dev/mii/truephy.c (revision 190500) +++ sys/dev/mii/truephy.c (working copy) @@ -76,6 +76,7 @@ }; static const struct mii_phydesc truephys[] = { + MII_PHY_DESC(AGERE, ET1011C_1), MII_PHY_DESC(AGERE, ET1011C), MII_PHY_END }; Index: sys/dev/mii/miidevs =================================================================== --- sys/dev/mii/miidevs (revision 190500) +++ sys/dev/mii/miidevs (working copy) @@ -108,6 +108,7 @@ */ /* Agere Systems PHYs */ +model AGERE ET1011C_1 0x0001 ET1011C 10/100/1000baseT PHY model AGERE ET1011C 0x0004 ET1011C 10/100/1000baseT PHY /* Altima Communications PHYs */ --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:44:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6575B1065673 for ; Sat, 28 Mar 2009 09:44:28 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id ED0678FC18 for ; Sat, 28 Mar 2009 09:44:27 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n2S9iPJf049429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 28 Mar 2009 10:44:26 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <4A766A21-7E01-46DF-98EB-A8BABC248AAD@lassitu.de> From: Stefan Bethke To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Mar 2009 10:44:25 +0100 X-Mailer: Apple Mail (2.930.3) Subject: enabling pf causes socket panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:44:28 -0000 With pf enabled, I get panics after only a few minutes of light traffic trought the machine. These two I could capture on the console (no dumps written because of mirrored swap): panic: sbsndptr: sockbuf 0xffffff0010005b60 and mbuf 0xffffff0004cdfe00 clashing cpuid = 1 KDB: enter: panic [thread pid 739 tid 100148 ] Stopped at kdb_enter+0x3d: movq $0,0x47ed48(%rip) db> panic: sbflush_internal: cc 60 || mb 0 || mbcnt 0 cpuid = 0 KDB: enter: panic [thread pid 1696 tid 100125 ] Stopped at kdb_enter+0x3d: movq $0,0x47ed48(%rip) db> bt Tracing pid 1696 tid 100125 td 0xffffff000499a000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b sbflush_internal() at sbflush_internal+0x64 sbrelease_internal() at sbrelease_internal+0x1c sofree() at sofree+0x107 soclose() at soclose+0x118 _fdrop() at _fdrop+0x23 closef() at closef+0x4c kern_close() at kern_close+0x110 syscall() at syscall+0x1a5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (6, FreeBSD ELF64, close), rip = 0x800d3c89c, rsp = 0x7fffffffcbc8, rbp = 0x1b --- Before enabling pf, the system ran fully stable for two weeks. Disabling pf again (pfctl -d) makes it stable again. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:50:32 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5FE106566B for ; Sat, 28 Mar 2009 09:50:31 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF6F8FC21 for ; Sat, 28 Mar 2009 09:50:31 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 6682238EB0; Sat, 28 Mar 2009 10:50:30 +0100 (CET) Date: Sat, 28 Mar 2009 10:50:30 +0100 From: Lars Engels To: current@FreeBSD.org Message-ID: <20090328095030.GD64269@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Problems with usb bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:50:32 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, yesterday I bought a shiny new hama usb bluetooth dongle but I am having some problems using it: before loading ng_ubt: usb2_alloc_device:1480: set address 2 failed (ignored) usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) after loading ng_ubt: uhub_reattach_port:413: could not allocate new device! ubt0: on usbus2 ^^^^^^^^^^ internal bluetooth device WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ugen0.2: at usbus0 ubt1: on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: interrupt transfer failed: USB_ERR_STAL= LED ubt1: at uhub0, port 1, addr 2 (disconnected) ugen0.2: at usbus0 (disconnected) device re-inserted: usb2_alloc_device:1480: set address 2 failed (ignored) usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! So the device is no longer recognized after I re-connect it. usbconfig does= not show it: ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen2.1: at usbus2, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen3.1: at usbus3, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DON ugen4.1: at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480= Mbps) pwr=3DON ugen2.2: at usbus2, cfg=3D0 = md=3DHOST spd=3DFULL (12Mbps = pwr=3DON It only lists the internal device... My CURRENT was compiled two days ago, so I should be up-to-date. Lars --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknN8uYACgkQKc512sD3afg1RACgnM1ZbAws8+eCY4sC5G2IHvHl ip0AoK41xYYdcq+uUd3pHmyRZ2FGWOri =y+mD -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:58:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B3E1065670; Sat, 28 Mar 2009 09:58:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7899B8FC13; Sat, 28 Mar 2009 09:58:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=YzV9F2SBnUsA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=M3u0mSUAQvXDMBrYJysA:9 a=bRha355O32NOxW_ZTU8A:7 a=FvJHxpOHjkXp_08be0YydoDBEwYA:4 a=LY0hPdMaydYA:10 a=aFaPMYQp8PMbobuw:21 a=kQ1_zI9j1OA0SKLK:21 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1220195322; Sat, 28 Mar 2009 10:58:03 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 11:00:32 +0100 User-Agent: KMail/1.9.7 References: <20090328095030.GD64269@e.0x20.net> In-Reply-To: <20090328095030.GD64269@e.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903281100.33957.hselasky@c2i.net> Cc: Lars Engels , current@freebsd.org Subject: Re: Problems with usb bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:58:05 -0000 On Saturday 28 March 2009, Lars Engels wrote: > Hi all, > > yesterday I bought a shiny new hama usb bluetooth dongle but I am having > some problems using it: > > before loading ng_ubt: > usb2_alloc_device:1480: set address 2 failed (ignored) > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > after loading ng_ubt: > uhub_reattach_port:413: could not allocate new device! > ubt0: 2.00/1.00, addr 2> on usbus2 ^^^^^^^^^^ > internal bluetooth device > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > ugen0.2: at usbus0 > ubt1: 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr 2 > (disconnected) > ugen0.2: at usbus0 (disconnected) > device re-inserted: > usb2_alloc_device:1480: set address 2 failed (ignored) > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > uhub_reattach_port:413: could not allocate new device! > > So the device is no longer recognized after I re-connect it. usbconfig does > not show it: ugen0.1: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 > md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at > usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: Intel> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2: Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=0 md=HOST spd=FULL > (12Mbps > pwr=ON > > It only lists the internal device... > > My CURRENT was compiled two days ago, so I should be up-to-date. Does it work when you use an external USB HUB? Does this device have some kind of autoinstall on it? You could try enabling uhci/ehci debugging. sysctl hw.usb2.uhci.debug = 15 Then we would know the exact cause of the error. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:58:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B3E1065670; Sat, 28 Mar 2009 09:58:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7899B8FC13; Sat, 28 Mar 2009 09:58:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=YzV9F2SBnUsA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=M3u0mSUAQvXDMBrYJysA:9 a=bRha355O32NOxW_ZTU8A:7 a=FvJHxpOHjkXp_08be0YydoDBEwYA:4 a=LY0hPdMaydYA:10 a=aFaPMYQp8PMbobuw:21 a=kQ1_zI9j1OA0SKLK:21 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1220195322; Sat, 28 Mar 2009 10:58:03 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 11:00:32 +0100 User-Agent: KMail/1.9.7 References: <20090328095030.GD64269@e.0x20.net> In-Reply-To: <20090328095030.GD64269@e.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903281100.33957.hselasky@c2i.net> Cc: Lars Engels , current@freebsd.org Subject: Re: Problems with usb bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:58:05 -0000 On Saturday 28 March 2009, Lars Engels wrote: > Hi all, > > yesterday I bought a shiny new hama usb bluetooth dongle but I am having > some problems using it: > > before loading ng_ubt: > usb2_alloc_device:1480: set address 2 failed (ignored) > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > after loading ng_ubt: > uhub_reattach_port:413: could not allocate new device! > ubt0: 2.00/1.00, addr 2> on usbus2 ^^^^^^^^^^ > internal bluetooth device > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > ugen0.2: at usbus0 > ubt1: 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr 2 > (disconnected) > ugen0.2: at usbus0 (disconnected) > device re-inserted: > usb2_alloc_device:1480: set address 2 failed (ignored) > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! > ugen0.2: <> at usbus0 (disconnected) > uhub_reattach_port:413: could not allocate new device! > > So the device is no longer recognized after I re-connect it. usbconfig does > not show it: ugen0.1: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 > md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at > usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: Intel> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2: Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=0 md=HOST spd=FULL > (12Mbps > pwr=ON > > It only lists the internal device... > > My CURRENT was compiled two days ago, so I should be up-to-date. Does it work when you use an external USB HUB? Does this device have some kind of autoinstall on it? You could try enabling uhci/ehci debugging. sysctl hw.usb2.uhci.debug = 15 Then we would know the exact cause of the error. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:59:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49D8B1065672 for ; Sat, 28 Mar 2009 09:59:15 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9D39A8FC13 for ; Sat, 28 Mar 2009 09:59:14 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by bwz8 with SMTP id 8so1234819bwz.43 for ; Sat, 28 Mar 2009 02:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tlKoY969T9SEfdA9wYoqbBuN9Sp+VZlhStClmkmh5Xs=; b=FAg/GH9gAeAENolTuSK0CCaWcqaJoZNhP6V1Z1eJDD7UH9/s7UHrySy4zUUir7yLgS 2cBGdBmDR6GR1z0p2onxN636MCo5n1O0BhJfkQvJbkLNQ9Yqw+XPyAYyh3IEIwqQyNYX QQXy7Jq8woyqUchPrYdGTFrAQ3gHPlE0asf6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZqAHaZEBMi7RJAGMMMSR2NpYcXr4ViBgkxK7venvBISe+mhT1U+oEozjceYzn3Y9wn mgh1Q8oNvUEz8HxVD9v9CfkQYk73je9vQP+7KSOFqSBYyR+8ZfYcyquPlkD5lEOdnhMn rtQHSE3j/7CeE5hI/K6HFw2c5X8DBsPj5/4CA= MIME-Version: 1.0 Received: by 10.223.108.196 with SMTP id g4mr2371905fap.36.1238234353302; Sat, 28 Mar 2009 02:59:13 -0700 (PDT) In-Reply-To: <20090328080924.GD99923@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> Date: Sat, 28 Mar 2009 11:59:13 +0200 Message-ID: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> From: Niki Denev To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:59:15 -0000 2009/3/28 Pyun YongHyeon : > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) >> problems. >> Basically the network connection works but when some more serious >> traffic hits the >> interface (i.e. torrent download) it then dies, ifconfig down/up >> does not help, only replugging of the adapter. >> >> I've tried running with hw.usb2.axe.debug=3D15 and the output was many >> lines of: >> >> =A0 =A0axe_bulk_write_callback:853: transfer complete >> >> then a pause of several seconds and the kernel begins to print : >> >> =A0 =A0axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT >> >> Another strange thing that I noticed is that, while the interface >> seems to be >> connected and working, if I type many times ifconfig ue0 consecutively >> most of the time it would show different settings for the auto >> negotiated link. >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. >> >> The switch does not seem to register link flaps. >> > > axe(4) requires exact link state/speed information from mii(4) to > reprogram controller to resolved speed/duplex. In this case > ukphy(4) seems to report fake link state/speed to axe(4). > >> The kernel messages for the interface are : >> >> =A0 =A0ugen2.5: at usbus2 >> =A0 =A0axe0: on usbus= 2 >> =A0 =A0axe0: PHYADDR 0xe0:0x01 >> =A0 =A0miibus0: on axe0 >> =A0 =A0ukphy0: PHY 1 on miibus0 >> =A0 =A0ukphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 1000baseT-FDX, auto >> =A0 =A0ue0: on axe0 >> =A0 =A0ue0: Ethernet address: 00:11:50:xx:xx:xx >> >> devinfo -vr | grep phy >> ukphy0 pnpinfo oui=3D0xa0bc model=3D0x1 rev=3D0x2 at phyno=3D1 >> > > This looks like Agere systems ET110C TruePHY. Would you try > attached patch? Because truephy(4) pokes some undocumented PHY > registers on PHY reset I'm not sure this model also requires that > magic to make it work though. > Hi Pyun, Thanks for the patch. With it the PHY is now detected as truephy. The only thing that i notice is that if the media status changes displayed = with ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX The packet loss is still there, and the interface again stops to work after some time. Regards, Niki Denev From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 10:08:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7141D1065670 for ; Sat, 28 Mar 2009 10:08:01 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 89D6E8FC16 for ; Sat, 28 Mar 2009 10:08:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n2SA7jDv053739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Mar 2009 11:07:46 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <200903272339.33763.hselasky@c2i.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Mar 2009 11:07:45 +0100 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> X-Mailer: Apple Mail (2.930.3) Cc: Andreas Tobler , freebsd-current@freebsd.org Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 10:08:01 -0000 I've run into the same issue a couple of days ago. Loading uhci as a module is sufficient to trigger the messages. No device was attached during the output below; in other tests I noticed that uhci appears to not see any device that VMware has attached. This was working just fine with the old stack. The controller appears as: none3@pci0:2:3:0: class=0x0c0320 card=0x077015ad chip=0x077015ad rev=0x00 hdr=0x00 vendor = 'VMware Inc.' class = serial bus subclass = USB Here's some debugging output: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2: Sun Mar 22 11:58:43 CET 2009 root@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/VMWARE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz (1259.05-MHz K8- class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features = 0xfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS> Features2=0x80082201> AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant usable memory = 2138005504 (2038 MB) avail memory = 2065743872 (1970 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-0x10cf at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 7.3 (no driver attached) pci0: at device 7.7 (no driver attached) vgapci0: port 0x10d0-0x10df mem 0xd0000000-0xd7ffffff,0xd8000000-0xd87fffff irq 16 at device 15.0 on pci0 mpt0: port 0x1400-0x14ff mem 0xd8820000-0xd883ffff,0xd8800000-0xd881ffff irq 17 at device 16.0 on pci0 mpt0: [ITHREAD] mpt0: MPI Version=1.2.0.0 pcib2: at device 17.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) em0: port 0x2000-0x203f mem 0xd8920000-0xd893ffff,0xd8900000-0xd890ffff irq 19 at device 1.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:23:27:3f pcm0: port 0x2040-0x207f irq 16 at device 2.0 on pci2 pcm0: pcm0: [ITHREAD] pcm0: pci2: at device 3.0 (no driver attached) pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: at device 21.1 on pci0 pci4: on pcib4 pcib5: at device 21.2 on pci0 pci5: on pcib5 pcib6: at device 21.3 on pci0 pci6: on pcib6 pcib7: at device 21.4 on pci0 pci7: on pcib7 pcib8: at device 21.5 on pci0 pci8: on pcib8 pcib9: at device 21.6 on pci0 pci9: on pcib9 pcib10: at device 21.7 on pci0 pci10: on pcib10 pcib11: at device 22.0 on pci0 pci11: on pcib11 pcib12: at device 22.1 on pci0 pci12: on pcib12 pcib13: at device 22.2 on pci0 pci13: on pcib13 pcib14: at device 22.3 on pci0 pci14: on pcib14 pcib15: at device 22.4 on pci0 pci15: on pcib15 pcib16: at device 22.5 on pci0 pci16: on pcib16 pcib17: at device 22.6 on pci0 pci17: on pcib17 pcib18: at device 22.7 on pci0 pci18: on pcib18 pcib19: at device 23.0 on pci0 pci19: on pcib19 pcib20: at device 23.1 on pci0 pci20: on pcib20 pcib21: at device 23.2 on pci0 pci21: on pcib21 pcib22: at device 23.3 on pci0 pci22: on pcib22 pcib23: at device 23.4 on pci0 pci23: on pcib23 pcib24: at device 23.5 on pci0 pci24: on pcib24 pcib25: at device 23.6 on pci0 pci25: on pcib25 pcib26: at device 23.7 on pci0 pci26: on pcib26 pcib27: at device 24.0 on pci0 pci27: on pcib27 pcib28: at device 24.1 on pci0 pci28: on pcib28 pcib29: at device 24.2 on pci0 pci29: on pcib29 pcib30: at device 24.3 on pci0 pci30: on pcib30 pcib31: at device 24.4 on pci0 pci31: on pcib31 pcib32: at device 24.5 on pci0 pci32: on pcib32 pcib33: at device 24.6 on pci0 pci33: on pcib33 pcib34: at device 24.7 on pci0 pci34: on pcib34 acpi_acad0: on acpi0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 orm0: at iomem 0xc0000-0xc7fff,0xca000-0xcafff, 0xdc000-0xdffff,0xe4000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 100.000 msec Waiting 5 seconds for SCSI devices to settle acd0: CDROM at ata1-master UDMA33 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da0: Command Queueing Enabled da0: 32768MB (67108864 512 byte sectors: 255H 63S/T 4177C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 VMware memory control driver initialized calcru: runtime went backwards from 85953 usec to 38748 usec for pid 602 (vmware-guestd) em0: link state changed to DOWN em0: link state changed to UP root@freebsd-current:~# kldload usb root@freebsd-current:~# kldload uhci uhci0: port 0x2080-0x209f irq 18 at device 0.0 on pci2 uhci0: [ITHREAD] usbus0: on uhci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) root@freebsd-current:~# sysctl hw.usb2.uhci.debug=1 hw.usb2.uhci.debug: 0 -> 1 uhub_reattach_port:413: could not allocate new device! usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_portreset:2424: Activating SOFs! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_root_ctrl_start:2524: uhci_timeout:1493: xfer=0xfffffffe40c03148 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: ugen0.1: at usbus0 (disconnected) usbus0: detached uhci_reset:261: resetting the HC uhci0: detached root@freebsd-current:~# kldunload uhci -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 10:25:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD41A1065672 for ; Sat, 28 Mar 2009 10:25:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA218FC0C for ; Sat, 28 Mar 2009 10:25:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 6A9BF1CF12; Sat, 28 Mar 2009 11:25:52 +0100 (CET) Date: Sat, 28 Mar 2009 11:25:52 +0100 From: Ed Schouten To: FreeBSD Current Message-ID: <20090328102552.GR73108@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o99acAvKqrTZeiCU" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: LD_PRELOAD broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 10:25:54 -0000 --o99acAvKqrTZeiCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Is it possible that the changes to rtld-elf the last couple of weeks cause LD_PRELOAD to crash applications on startup? Very simple way to reproduce: LD_PRELOAD=3D/lib/libc.so.7 ls This causes a segmentation fault on startup, at least on AMD64. --=20 Ed Schouten WWW: http://80386.nl/ --o99acAvKqrTZeiCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknN+zAACgkQ52SDGA2eCwWLtQCeIHt62Zz5sIQBGoIggDREKlWx kBMAn0nP0oKvpy/ye7p2qF++mvsJd1fj =/Igg -----END PGP SIGNATURE----- --o99acAvKqrTZeiCU-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 10:29:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 817831065678 for ; Sat, 28 Mar 2009 10:29:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id 129208FC20 for ; Sat, 28 Mar 2009 10:29:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1055273tia.3 for ; Sat, 28 Mar 2009 03:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=7qgi3H86z8a0WalQyuWWRzNzoj1H7FmIGWLPOWJCzxk=; b=UVZ1UoGoUhMSaGaRozejb6acEuk4gKTHI4UODYyfWwiveCRELYXe4tnT8OD1EvhMMV aLz8UTEyypa9lSCqaj57PD8G8JsytUeFJoZ2G8JUdw3/PaiVS0VxVJfhGDqb+mbsF6X4 Q8i+Z+hbrSqJbTwFskCUs/sUOc/egJOPCIaVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=QFfVcpb2Yh0cZMHsRtXNUopDhkcnk6X1xDtnf0j5FbkEtY1U+wfAK5Bo/ZSoC9QeuB kY7cyebSbDtIazo95Iua9G0uj38B6ndBNkZ5loanEsGvwKHNgI1yR1NUSd7bQEuqfusm +YW2V621q+m7IzLraXRUFVhrB50XcOwmpm4aI= Received: by 10.110.42.1 with SMTP id p1mr4514521tip.18.1238236139742; Sat, 28 Mar 2009 03:28:59 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id w12sm920771tib.0.2009.03.28.03.28.57 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 03:28:58 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 28 Mar 2009 19:27:35 +0900 From: Pyun YongHyeon Date: Sat, 28 Mar 2009 19:27:35 +0900 To: Niki Denev Message-ID: <20090328102735.GE99923@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 10:29:03 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: > 2009/3/28 Pyun YongHyeon : > > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hello, > >> > >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) > >> problems. > >> Basically the network connection works but when some more serious > >> traffic hits the > >> interface (i.e. torrent download) it then dies, ifconfig down/up > >> does not help, only replugging of the adapter. > >> > >> I've tried running with hw.usb2.axe.debug=15 and the output was many > >> lines of: > >> > >> ? ?axe_bulk_write_callback:853: transfer complete > >> > >> then a pause of several seconds and the kernel begins to print : > >> > >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT > >> > >> Another strange thing that I noticed is that, while the interface > >> seems to be > >> connected and working, if I type many times ifconfig ue0 consecutively > >> most of the time it would show different settings for the auto > >> negotiated link. > >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, > >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. > >> > >> The switch does not seem to register link flaps. > >> > > > > axe(4) requires exact link state/speed information from mii(4) to > > reprogram controller to resolved speed/duplex. In this case > > ukphy(4) seems to report fake link state/speed to axe(4). > > > >> The kernel messages for the interface are : > >> > >> ? ?ugen2.5: at usbus2 > >> ? ?axe0: on usbus2 > >> ? ?axe0: PHYADDR 0xe0:0x01 > >> ? ?miibus0: on axe0 > >> ? ?ukphy0: PHY 1 on miibus0 > >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> 1000baseT, 1000baseT-FDX, auto > >> ? ?ue0: on axe0 > >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx > >> > >> devinfo -vr | grep phy > >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 > >> > > > > This looks like Agere systems ET110C TruePHY. Would you try > > attached patch? Because truephy(4) pokes some undocumented PHY > > registers on PHY reset I'm not sure this model also requires that > > magic to make it work though. > > > > Hi Pyun, > > Thanks for the patch. > > With it the PHY is now detected as truephy. > The only thing that i notice is that if the media status changes displayed with > ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX > The packet loss is still there, and the interface again stops to work > after some time. > Ok, revert previous patch and try attached one. This one does not try to load ET1011C dsp codes. If this does not work next thing would be try to load dsp code for ET1011C revision 1 model. Not sure where I can find required dsp code. --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mii.ET1011C.patch2" Index: sys/dev/mii/truephy.c =================================================================== --- sys/dev/mii/truephy.c (revision 190500) +++ sys/dev/mii/truephy.c (working copy) @@ -66,6 +66,11 @@ static void truephy_reset(struct mii_softc *); static void truephy_status(struct mii_softc *); +struct truephy_softc { + struct mii_softc mii_sc; + int mii_model; +}; + static device_method_t truephy_methods[] = { /* device interface */ DEVMETHOD(device_probe, truephy_probe), @@ -76,6 +81,7 @@ }; static const struct mii_phydesc truephys[] = { + MII_PHY_DESC(AGERE, ET1011C_1), MII_PHY_DESC(AGERE, ET1011C), MII_PHY_END }; @@ -85,7 +91,7 @@ static driver_t truephy_driver = { "truephy", truephy_methods, - sizeof(struct mii_softc) + sizeof(struct truephy_softc) }; DRIVER_MODULE(truephy, miibus, truephy_driver, truephy_devclass, 0, 0); @@ -139,15 +145,15 @@ truephy_attach(device_t dev) { struct mii_softc *sc; + struct truephy_softc *tsc; struct mii_attach_args *ma; struct mii_data *mii; - sc = device_get_softc(dev); + tsc = device_get_softc(dev); + sc = &tsc->mii_sc; ma = device_get_ivars(dev); sc->mii_phy = ma->mii_phyno; - if (sc->mii_anegticks == 0) - sc->mii_anegticks = MII_ANEGTICKS; sc->mii_dev = device_get_parent(dev); mii = device_get_softc(sc->mii_dev); LIST_INSERT_HEAD(&mii->mii_phys, sc, mii_list); @@ -161,6 +167,8 @@ mii->mii_instance++; + tsc->mii_model = MII_MODEL(ma->mii_id2); + truephy_reset(sc); sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask; @@ -256,8 +264,14 @@ static void truephy_reset(struct mii_softc *sc) { + struct truephy_softc *tsc; int i; + tsc = (struct truephy_softc *)sc; + if (tsc->mii_model != MII_MODEL_AGERE_ET1011C) { + mii_phy_reset(sc); + return; + } for (i = 0; i < 2; ++i) { PHY_READ(sc, MII_PHYIDR1); PHY_READ(sc, MII_PHYIDR2); Index: sys/dev/mii/miidevs =================================================================== --- sys/dev/mii/miidevs (revision 190500) +++ sys/dev/mii/miidevs (working copy) @@ -108,6 +108,7 @@ */ /* Agere Systems PHYs */ +model AGERE ET1011C_1 0x0001 ET1011C 10/100/1000baseT PHY model AGERE ET1011C 0x0004 ET1011C 10/100/1000baseT PHY /* Altima Communications PHYs */ --xXmbgvnjoT4axfJE-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 11:04:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB3AE106566C; Sat, 28 Mar 2009 11:04:23 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 878AC8FC13; Sat, 28 Mar 2009 11:04:23 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 8F77B38EDA; Sat, 28 Mar 2009 12:04:22 +0100 (CET) Date: Sat, 28 Mar 2009 12:04:22 +0100 From: Lars Engels To: Hans Petter Selasky Message-ID: <20090328110421.GF64269@e.0x20.net> Mail-Followup-To: Lars Engels , Hans Petter Selasky , freebsd-current@freebsd.org, current@freebsd.org References: <20090328095030.GD64269@e.0x20.net> <200903281100.33957.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncSAzJYg3Aa9+CRW" Content-Disposition: inline In-Reply-To: <200903281100.33957.hselasky@c2i.net> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Problems with usb bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 11:04:24 -0000 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2009 at 11:00:32AM +0100, Hans Petter Selasky wrote: > On Saturday 28 March 2009, Lars Engels wrote: > > Hi all, > > > > yesterday I bought a shiny new hama usb bluetooth dongle but I am having > > some problems using it: > > > > before loading ng_ubt: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > after loading ng_ubt: > > uhub_reattach_port:413: could not allocate new device! > > ubt0: > 2.00/1.00, addr 2> on usbus2 ^^^^^^^^^^ > > internal bluetooth device > > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > ugen0.2: at usbus0 > > ubt1: > 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in > > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: > > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr= 2 > > (disconnected) > > ugen0.2: at usbus0 (disconnected) > > device re-inserted: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > uhub_reattach_port:413: could not allocate new device! > > > > So the device is no longer recognized after I re-connect it. usbconfig = does > > not show it: ugen0.1: at usbus0, cfg=3D0 md=3DHOST > > spd=3DFULL (12Mbps) pwr=3DON ugen1.1: at usbus1, = cfg=3D0 > > md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen2.1: a= t usbus2, > > cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen3.1: at > > usbus3, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen4.1: > Intel> at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON ugen2= =2E2: > Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=3D0 md=3DHOST spd= =3DFULL > > (12Mbps = =20 > > pwr=3DON > > > > It only lists the internal device... > > > > My CURRENT was compiled two days ago, so I should be up-to-date. >=20 > Does it work when you use an external USB HUB? Yes, it's working with a usb hub: Hub inserted: Mar 28 11:46:30 maggie kernel: ugen4.2: at usbus4 Mar 28 11:46:30 maggie kernel: uhub5: on usbus4 Mar 28 11:46:31 maggie kernel: uhub5: 4 ports with 4 removable, self powe= red Dongle inserted: Mar 28 11:46:41 maggie root: Unknown USB device: vendor 0x0a12 product 0x= 0001 bus uhub5 Mar 28 11:46:41 maggie kernel: ugen4.3: at usbu= s4 Mar 28 11:46:41 maggie kernel: ubt1: on usbus4 >=20 > Does this device have some kind of autoinstall on it? I don't think so. There was a windows driver cd included. > You could try enabling uhci/ehci debugging. > sysctl hw.usb2.uhci.debug =3D 15 Do you really want that? :) It produced hundreds of thousands of lines, so I trimmed it a bit: I inserted the dongle at 11:50:09 and copied you the next ~7 seconds to http://people.freebsd.org/~lme/messages.trimmed.bz2 > Then we would know the exact cause of the error. I hope you can see more in the messages than me ;-) --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknOBDUACgkQKc512sD3afjTSwCfZUTOEzfF134wS16pPiKo3HIB i+oAoIA59Z58LCVWVK2snJuaUXo8XKj+ =IXTf -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 11:04:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB3AE106566C; Sat, 28 Mar 2009 11:04:23 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (unknown [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 878AC8FC13; Sat, 28 Mar 2009 11:04:23 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 8F77B38EDA; Sat, 28 Mar 2009 12:04:22 +0100 (CET) Date: Sat, 28 Mar 2009 12:04:22 +0100 From: Lars Engels To: Hans Petter Selasky Message-ID: <20090328110421.GF64269@e.0x20.net> Mail-Followup-To: Lars Engels , Hans Petter Selasky , freebsd-current@freebsd.org, current@freebsd.org References: <20090328095030.GD64269@e.0x20.net> <200903281100.33957.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncSAzJYg3Aa9+CRW" Content-Disposition: inline In-Reply-To: <200903281100.33957.hselasky@c2i.net> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Problems with usb bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 11:04:24 -0000 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2009 at 11:00:32AM +0100, Hans Petter Selasky wrote: > On Saturday 28 March 2009, Lars Engels wrote: > > Hi all, > > > > yesterday I bought a shiny new hama usb bluetooth dongle but I am having > > some problems using it: > > > > before loading ng_ubt: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > after loading ng_ubt: > > uhub_reattach_port:413: could not allocate new device! > > ubt0: > 2.00/1.00, addr 2> on usbus2 ^^^^^^^^^^ > > internal bluetooth device > > WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > ugen0.2: at usbus0 > > ubt1: > 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in > > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: > > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr= 2 > > (disconnected) > > ugen0.2: at usbus0 (disconnected) > > device re-inserted: > > usb2_alloc_device:1480: set address 2 failed (ignored) > > usb2_alloc_device:1516: getting device descriptor at addr 2 failed! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > usb2_req_re_enumerate:1421: addr=3D2, set address failed! (ignored) > > usb2_req_re_enumerate:1434: getting device descriptor at addr 2 faile= d! > > ugen0.2: <> at usbus0 (disconnected) > > uhub_reattach_port:413: could not allocate new device! > > > > So the device is no longer recognized after I re-connect it. usbconfig = does > > not show it: ugen0.1: at usbus0, cfg=3D0 md=3DHOST > > spd=3DFULL (12Mbps) pwr=3DON ugen1.1: at usbus1, = cfg=3D0 > > md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen2.1: a= t usbus2, > > cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen3.1: at > > usbus3, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON ugen4.1: > Intel> at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON ugen2= =2E2: > Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=3D0 md=3DHOST spd= =3DFULL > > (12Mbps = =20 > > pwr=3DON > > > > It only lists the internal device... > > > > My CURRENT was compiled two days ago, so I should be up-to-date. >=20 > Does it work when you use an external USB HUB? Yes, it's working with a usb hub: Hub inserted: Mar 28 11:46:30 maggie kernel: ugen4.2: at usbus4 Mar 28 11:46:30 maggie kernel: uhub5: on usbus4 Mar 28 11:46:31 maggie kernel: uhub5: 4 ports with 4 removable, self powe= red Dongle inserted: Mar 28 11:46:41 maggie root: Unknown USB device: vendor 0x0a12 product 0x= 0001 bus uhub5 Mar 28 11:46:41 maggie kernel: ugen4.3: at usbu= s4 Mar 28 11:46:41 maggie kernel: ubt1: on usbus4 >=20 > Does this device have some kind of autoinstall on it? I don't think so. There was a windows driver cd included. > You could try enabling uhci/ehci debugging. > sysctl hw.usb2.uhci.debug =3D 15 Do you really want that? :) It produced hundreds of thousands of lines, so I trimmed it a bit: I inserted the dongle at 11:50:09 and copied you the next ~7 seconds to http://people.freebsd.org/~lme/messages.trimmed.bz2 > Then we would know the exact cause of the error. I hope you can see more in the messages than me ;-) --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknOBDUACgkQKc512sD3afjTSwCfZUTOEzfF134wS16pPiKo3HIB i+oAoIA59Z58LCVWVK2snJuaUXo8XKj+ =IXTf -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 11:35:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 247A9106564A for ; Sat, 28 Mar 2009 11:35:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id AEA828FC14 for ; Sat, 28 Mar 2009 11:35:51 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=96w21pq8z4AA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=e9GxxH9P372UvzlkC0gA:9 a=MzVNTzRYKRghxnyvMwwA:7 a=6Ky5vKfIylXSPeOKZlv0ct5G7vwA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1044459415; Sat, 28 Mar 2009 12:35:49 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 12:38:19 +0100 User-Agent: KMail/1.9.7 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> In-Reply-To: <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903281238.20633.hselasky@c2i.net> Cc: Andreas Tobler , Stefan Bethke Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 11:35:52 -0000 On Saturday 28 March 2009, Stefan Bethke wrote: > I've run into the same issue a couple of days ago. > > Loading uhci as a module is sufficient to trigger the messages. No > device was attached during the output below; in other tests I noticed > that uhci appears to not see any device that VMware has attached. > > This was working just fine with the old stack. Maybe it has got something to do with the new power save functionality, which maybe VMware does not support. Try: usbconfig power_on Then give a USB device to VM-ware. --HPS > > The controller appears as: > none3@pci0:2:3:0: class=0x0c0320 card=0x077015ad chip=0x077015ad > rev=0x00 hdr=0x00 > vendor = 'VMware Inc.' > class = serial bus > subclass = USB > > From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 09:53:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C82106564A for ; Sat, 28 Mar 2009 09:53:01 +0000 (UTC) (envelope-from sebastiaan@akiha.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 42EC58FC13 for ; Sat, 28 Mar 2009 09:53:00 +0000 (UTC) (envelope-from sebastiaan@akiha.nl) Received: from akiha.nl (boe.xs4all.nl [82.95.74.163]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2S9fJGM002046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Mar 2009 10:41:19 +0100 (CET) (envelope-from sebastiaan@akiha.nl) Received: from [192.168.178.3] (boe.xs4all.nl [82.95.74.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sebastiaan) by akiha.nl (Postfix) with ESMTP id 5596650B92 for ; Sat, 28 Mar 2009 10:41:18 +0100 (CET) Message-Id: <3DB40EE4-80C8-49D4-8094-27A6F424D601@akiha.nl> From: Sebastiaan van Doesselaar To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Mar 2009 10:41:17 +0100 X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Sat, 28 Mar 2009 11:39:11 +0000 Subject: Slow network problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 09:53:01 -0000 Dear all, At the moment I'm running a CURRENT snapshot from February, yet somehow my network speeds are quite low. I've tested this with iperf, SMB and SCP, yet all give me more or less the same speeds, which is about 50 - 60Mbps. The weird thing is that this is only the case when the FreeBSD machine receives data, sending data is all fine. At least, with a 100Mbps link iperf gives me quite decent speeds (>90Mbps) This is the case for gigabit as well as 100Mbps, depending on what cable I use to the switch. I've also tested this directly, with a cable to a machine, but this was to no avail. I've tried changing some variables with sysctl (net.inet.tcp.recvspace, sendspace, recvbuf_auto, kern.ipc.maxsockbuf), yet those did not do anything. dmesg has this to say about the network card: rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, aut I cannot say I've tested this with a STABLE release, but in Windows and Gentoo Linux this worked fine. I have found one person with a seemingly similar problem, but this person had the problem a couple of years ago and did not resolve it at the time, or so it seems. See http://kerneltrap.org/mailarchive/freebsd-hackers/2006/5/30/214298 for his thread. I hope someone can give me some tips that will solve this problem. If information is lacking, please do say so. With kind regards, Sebastiaan van Doesselaar From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 11:41:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E901065AE4 for ; Sat, 28 Mar 2009 11:41:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBC68FC20 for ; Sat, 28 Mar 2009 11:41:10 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=96w21pq8z4AA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=e9GxxH9P372UvzlkC0gA:9 a=S4JBSg5q6Lf3YvjhPAe8_mdeLxAA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 166822868; Sat, 28 Mar 2009 12:41:08 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 12:43:35 +0100 User-Agent: KMail/1.9.7 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> In-Reply-To: <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903281243.36540.hselasky@c2i.net> Cc: Andreas Tobler , Stefan Bethke Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 11:41:12 -0000 On Saturday 28 March 2009, Stefan Bethke wrote: > I've run into the same issue a couple of days ago. > > Loading uhci as a module is sufficient to trigger the messages. No > device was attached during the output below; in other tests I noticed > that uhci appears to not see any device that VMware has attached. Is it possible to get some debugging from the VM-ware? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 12:22:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5F751065676 for ; Sat, 28 Mar 2009 12:22:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5668FC14 for ; Sat, 28 Mar 2009 12:22:15 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n2SCLvWK045835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Mar 2009 13:21:58 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <85958908-38DF-423D-A919-EE5E8AD980B7@lassitu.de> From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <200903281238.20633.hselasky@c2i.net> Content-Type: multipart/mixed; boundary=Apple-Mail-1-90196528 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Mar 2009 13:21:57 +0100 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> <200903281238.20633.hselasky@c2i.net> X-Mailer: Apple Mail (2.930.3) Cc: Andreas Tobler , freebsd-current@freebsd.org Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 12:22:18 -0000 --Apple-Mail-1-90196528 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Am 28.03.2009 um 12:38 schrieb Hans Petter Selasky: > On Saturday 28 March 2009, Stefan Bethke wrote: >> I've run into the same issue a couple of days ago. >> >> Loading uhci as a module is sufficient to trigger the messages. No >> device was attached during the output below; in other tests I noticed >> that uhci appears to not see any device that VMware has attached. >> >> This was working just fine with the old stack. > > Maybe it has got something to do with the new power save > functionality, which > maybe VMware does not support. > > Try: > > usbconfig power_on > > Then give a USB device to VM-ware. First try, no device attached: kldload uhci sysctl hw.usb2.uhci.debug=15 sleep 5 kldunload uhci Second try, no device attached: kldload uhci sleep 2 usbconfig power_on sysctl hw.usb2.uhci.debug=15 sleep 5 usbconfig list kldunload uhci Third try, 1 GB USB stick attached: kldload uhci sleep 2 usbconfig power_on sysctl hw.usb2.uhci.debug=15 sleep 5 usbconfig list kldunload uhci On the third try, usbconfig did not list the device. I've attached the log output from the second and third tries. Stefan --Apple-Mail-1-90196528 Content-Disposition: attachment; filename=with_device.txt Content-Type: text/plain; x-unix-mode=0644; name="with_device.txt" Content-Transfer-Encoding: 7bit #!/bin/sh kldload uhci sleep 2 usbconfig power_on sysctl hw.usb2.uhci.debug=15 sleep 5 usbconfig list kldunload uhci # ./test.sh usbconfig: could not set power ON: Invalid argument hw.usb2.uhci.debug: 0 -> 15 ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON uhci0: port 0x2080-0x209f irq 18 at device 0.0 on pci2 uhci0: [ITHREAD] usbus0: on uhci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001ccb9d00) at 0x1ccb9d04 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff001ccb9d00) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aec500 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aec500 from 0xffffff0001aec500 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aec500 from 0xffffff001cc8fc80 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001cce0500) at 0x1cce0504 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x1fe03260 TD(0xffffff001cce0500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001bf6680 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff001cce0500) at 0x1cce0504 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x1fe03260 TD(0xffffff001cce0500) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001bf6680 from 0xffffff0001bf6680 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff000134f500) at 0x0134f504 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000134f500) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff0001aef380 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff000134f500) at 0x0134f504 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000134f500) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001aef380 from 0xffffff0001aef380 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aef380 from 0xffffff001cc8fc80 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff0001600d00) at 0x01600d04 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff0001600d00) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aeda80 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aeda80 from 0xffffff0001aeda80 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aeda80 from 0xffffff001cc8fc80 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00013dc500) at 0x013dc504 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x1fe03260 TD(0xffffff00013dc500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001cc8e280 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00013dc500) at 0x013dc504 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x1fe03260 TD(0xffffff00013dc500) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001cc8e280 from 0xffffff001cc8e280 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff00014d5900) at 0x014d5904 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff00014d5900) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001cc8e300 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00014d5900) at 0x014d5904 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff00014d5900) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001cc8e300 from 0xffffff001cc8e300 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8e300 from 0xffffff001cc8fc80 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00015a8900) at 0x015a8904 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff00015a8900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001cc8f400 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cc8f400 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cc8fc80 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0011 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=17 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=16 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2424: Activating SOFs! uhci_portreset:2439: uhci port 2 reset, status0 = 0x0281 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0081 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_pipe_init:3185: pipe=0xfffffffe40c013d0, addr=0, endpt=0, mode=0 (1) uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff0001bf2d00) at 0x01bf2d04 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x1fe03260 TD(0xffffff0001bf2d00) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001c7d200 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff0001bf2d00) at 0x01bf2d04 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x1fe03260 TD(0xffffff0001bf2d00) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001c7d200 from 0xffffff0001c7d200 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff0001bf1900) at 0x01bf1904 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001bf1900) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001cc8f400 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff0001bf1900) at 0x01bf1904 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001bf1900) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cc8f400 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cc8fc80 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff0001bf1900) at 0x01bf1904 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff0001bf1900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aec400 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aec400 from 0xffffff0001aec400 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aec400 from 0xffffff001cc8fc80 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00015a7900) at 0x015a7904 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x1fe03260 TD(0xffffff00015a7900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aed700 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00015a7900) at 0x015a7904 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x1fe03260 TD(0xffffff00015a7900) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001aed700 from 0xffffff0001aed700 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff001ccbb100) at 0x1ccbb104 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff001ccbb100) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001cc8e300 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff001ccbb100) at 0x1ccbb104 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff001ccbb100) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001cc8e300 from 0xffffff001cc8e300 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8e300 from 0xffffff001cc8fc80 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff000174f100) at 0x0174f104 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff000174f100) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aeea80 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aeea80 from 0xffffff0001aeea80 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aeea80 from 0xffffff001cc8fc80 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff000134fd00) at 0x0134fd04 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x1fe03260 TD(0xffffff000134fd00) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001ccef980 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff000134fd00) at 0x0134fd04 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x1fe03260 TD(0xffffff000134fd00) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001ccef980 from 0xffffff001ccef980 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff000174d500) at 0x0174d504 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d500) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001ccee680 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff000174d500) at 0x0174d504 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d500) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001ccee680 from 0xffffff001ccee680 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001ccee680 from 0xffffff001cc8fc80 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001cce0500) at 0x1cce0504 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x1fe03260 TD(0xffffff001cce0500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aec500 to 0xffffff001cc8fc80 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aec500 from 0xffffff0001aec500 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aec500 from 0xffffff001cc8fc80 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=0 uhci_device_done:1844: xfer=0xffffff001ce05948, pipe=0xfffffffe40bff420, error=5 ugen0.1: at usbus0 (disconnected) uhci_device_done:1844: xfer=0xffffff00016db148, pipe=0xfffffffe40bff3d0, error=5 usbus0: detached uhci_reset:261: resetting the HC uhci0: detached --Apple-Mail-1-90196528 Content-Disposition: attachment; filename=without_device.txt Content-Type: text/plain; x-unix-mode=0644; name="without_device.txt" Content-Transfer-Encoding: 7bit #!/bin/sh kldload uhci sleep 2 usbconfig power_on sysctl hw.usb2.uhci.debug=15 sleep 5 usbconfig list kldunload uhci root@freebsd-current:~# ./test.sh usbconfig: could not set power ON: Invalid argument hw.usb2.uhci.debug: 0 -> 15 ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON usbus0: on uhci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00013dc100) at 0x013dc104 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff00013dc100) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001afd680 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001afd680 from 0xffffff0001afd680 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001afd680 from 0xffffff001cce9080 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001ccba100) at 0x1ccba104 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x0b403260 TD(0xffffff001ccba100) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001c7f000 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff001ccba100) at 0x1ccba104 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x0b403260 TD(0xffffff001ccba100) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001c7f000 from 0xffffff0001c7f000 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff000174d100) at 0x0174d104 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d100) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff0001c7f100 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff000174d100) at 0x0174d104 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d100) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001c7f100 from 0xffffff0001c7f100 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001c7f100 from 0xffffff001cce9080 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff0001bf2100) at 0x01bf2104 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff0001bf2100) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001cc8d900 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff001cc8d900 from 0xffffff001cc8d900 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8d900 from 0xffffff001cce9080 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00014d4500) at 0x014d4504 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x0b403260 TD(0xffffff00014d4500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001cc8d900 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00014d4500) at 0x014d4504 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x0b403260 TD(0xffffff00014d4500) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001cc8d900 from 0xffffff001cc8d900 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff00014b1900) at 0x014b1904 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff00014b1900) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff0001aec800 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00014b1900) at 0x014b1904 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff00014b1900) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001aec800 from 0xffffff0001aec800 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aec800 from 0xffffff001cce9080 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001ccbb500) at 0x1ccbb504 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff001ccbb500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aed400 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aed400 from 0xffffff0001aed400 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aed400 from 0xffffff001cce9080 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_set_hw_power:3336: uhci_set_hw_power:3358: Power save on 0. uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0011 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=17 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0010 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=16 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2424: Activating SOFs! uhci_portreset:2439: uhci port 2 reset, status0 = 0x0281 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0081 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_pipe_init:3185: pipe=0xfffffffe40c013d0, addr=0, endpt=0, mode=0 (1) uhci_set_hw_power:3336: uhci_set_hw_power:3354: Some USB transfer is active on 0. uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff001ccb9900) at 0x1ccb9904 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x0b403260 TD(0xffffff001ccb9900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001c7f000 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff001ccb9900) at 0x1ccb9904 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x0b403260 TD(0xffffff001ccb9900) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001c7f000 from 0xffffff0001c7f000 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff0001659d00) at 0x01659d04 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001659d00) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff0001afd500 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff0001659d00) at 0x01659d04 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001659d00) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001afd500 from 0xffffff0001afd500 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001afd500 from 0xffffff001cce9080 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff000174d500) at 0x0174d504 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff000174d500) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001c7ee00 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001c7ee00 from 0xffffff0001c7ee00 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001c7ee00 from 0xffffff001cce9080 usb2_alloc_device:1516: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00015a7900) at 0x015a7904 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x0b403260 TD(0xffffff00015a7900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001afd680 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff00015a7900) at 0x015a7904 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x0b403260 TD(0xffffff00015a7900) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff0001afd680 from 0xffffff0001afd680 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff000174d500) at 0x0174d504 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d500) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001ccef980 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff000174d500) at 0x0174d504 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff000174d500) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001ccef980 from 0xffffff001ccef980 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001ccef980 from 0xffffff001cce9080 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff00014b1900) at 0x014b1904 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff00014b1900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff0001aa0700 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff0001aa0700 from 0xffffff0001aa0700 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff0001aa0700 from 0xffffff001cce9080 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x03 wLen=0x0000 wValue=0x0004 wIndex=0x0002 uhci_portreset:2439: uhci port 2 reset, status0 = 0x0285 uhci_portreset:2456: uhci port 2 reset, status1 = 0x0085 uhci_portreset:2469: uhci port 2 iteration 0, status = 0x0085 uhci_portreset:2507: uhci port 2 reset, status2 = 0x0085 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0014 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=20 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=8 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff0001601900) at 0x01601904 = link=0x00000001 status=0x198003ff token=0x00e0002d buffer=0x0b403260 TD(0xffffff0001601900) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=0,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001ccee380 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff0001601900) at 0x01601904 = link=0x00000001 status=0x19000007 token=0x00e0002d buffer=0x0b403260 TD(0xffffff0001601900) td_next=-T td_status=-IOC, errcnt=3, actlen=8 pid=2d,addr=0,endpt=0,D=0,maxlen=8 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001ccee380 from 0xffffff001ccee380 uhci_setup_standard_chain:1662: addr=0 endpt=0 sumlen=0 speed=2 uhci_setup_standard_chain:1823: nexttog=1; data before transfer: TD(0xffffff0001bf2100) at 0x01bf2104 = link=0x00000001 status=0x398003ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001bf2100) td_next=-T td_status=-ACTIVE-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 _uhci_append_qh:918: 0xffffff001ccef700 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_non_isoc_done:1185: xfer=0xfffffffe40c03148 pipe=0xfffffffe40c013d0 transfer done TD(0xffffff0001bf2100) at 0x01bf2104 = link=0x00000001 status=0x390007ff token=0xffe80069 buffer=0x00000000 TD(0xffffff0001bf2100) td_next=-T td_status=-IOC-SPD, errcnt=3, actlen=0 pid=69,addr=0,endpt=0,D=1,maxlen=0 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=0 _uhci_remove_qh:974: 0xffffff001ccef700 from 0xffffff001ccef700 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001ccef700 from 0xffffff001cce9080 uhci_setup_standard_chain:1662: addr=2 endpt=0 sumlen=16 speed=2 uhci_setup_standard_chain:1823: nexttog=0; data before transfer: TD(0xffffff000174d100) at 0x0174d104 = link=0x00000001 status=0x198003ff token=0x00e0022d buffer=0x0b403260 TD(0xffffff000174d100) td_next=-T td_status=-ACTIVE-IOC, errcnt=3, actlen=0 pid=2d,addr=2,endpt=0,D=0,maxlen=8 _uhci_append_qh:918: 0xffffff001cc8f400 to 0xffffff001cce9080 uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_check_transfer_sub:1287: xfer=0xfffffffe40c03148 following alt next uhci_check_transfer:1386: xfer=0xfffffffe40c03148 is still active uhci_timeout:1493: xfer=0xfffffffe40c03148 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=20 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cc8f400 uhci_device_done:1844: xfer=0xfffffffe40c03148, pipe=0xfffffffe40c013d0, error=5 _uhci_remove_qh:974: 0xffffff001cc8f400 from 0xffffff001cce9080 usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: <> at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! uhci_root_ctrl_start:2524: uhci_root_ctrl_done:2569: type=0x23 request=0x01 wLen=0x0000 wValue=0x0001 wIndex=0x0002 uhci_root_ctrl_done:2679: UR_CLEAR_PORT_FEATURE port=2 feature=1 uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=0 uhci_device_done:1844: xfer=0xffffff00016af948, pipe=0xfffffffe40bff420, error=5 ugen0.1: at usbus0 (disconnected) uhci_device_done:1844: xfer=0xffffff0001b92148, pipe=0xfffffffe40bff3d0, error=5 usbus0: detached uhci_reset:261: resetting the HC uhci0: detached --Apple-Mail-1-90196528 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail-1-90196528-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 12:22:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A2A81065670 for ; Sat, 28 Mar 2009 12:22:53 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id D26D18FC23 for ; Sat, 28 Mar 2009 12:22:52 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n2SCLvWL045835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Mar 2009 13:22:40 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <200903281243.36540.hselasky@c2i.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Mar 2009 13:22:40 +0100 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> <200903281243.36540.hselasky@c2i.net> X-Mailer: Apple Mail (2.930.3) Cc: Andreas Tobler , freebsd-current@freebsd.org Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 12:22:53 -0000 Am 28.03.2009 um 12:43 schrieb Hans Petter Selasky: > On Saturday 28 March 2009, Stefan Bethke wrote: >> I've run into the same issue a couple of days ago. >> >> Loading uhci as a module is sufficient to trigger the messages. No >> device was attached during the output below; in other tests I noticed >> that uhci appears to not see any device that VMware has attached. > > Is it possible to get some debugging from the VM-ware? Apparently some internal debugging can be activated, but I'm not sure what it will show. I can try and find out. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 12:29:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 369401065674 for ; Sat, 28 Mar 2009 12:29:42 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id C07FE8FC16 for ; Sat, 28 Mar 2009 12:29:41 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.38,437,1233529200"; d="scan'208";a="212453289" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 28 Mar 2009 13:29:33 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id DFDAE1B07E2; Sat, 28 Mar 2009 13:29:33 +0100 (CET) Date: Sat, 28 Mar 2009 13:29:33 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: linux 3d applications keep crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 12:29:42 -0000 I filed a problem report concerning this problem. here it is: http://www.freebsd.org/cgi/query-pr.cgi?pr=133144 cheers. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 12:46:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C672106566C for ; Sat, 28 Mar 2009 12:46:44 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3D08FC0C for ; Sat, 28 Mar 2009 12:46:43 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so998138yxm.13 for ; Sat, 28 Mar 2009 05:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jYB9S2FD7z+SPTvn/CysGdwwuu1tKiQH7zW96QFXBxY=; b=ZMvk25Mmf1RFRIvFx1r9/rFe3ygSwZQIBSM6oVEFmU+wDTxfwXYSdKRDxPnpHIjaV0 acUCJt4iNUy+NMmZ0sd57XUGsv1TNhPUdSuK7tgAQosFItIO+4nPGCTFjDdfsX5ZrH+0 JCUACmZEFdW6CGzs1/HP0IcMngKsj+/0Ucf/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KRqRpDPk+JvcyZm5vRBKlQ8yjmyEUfMoqMg/+LiD26VB1H2hK7vlMM1duzqs+756LP VO/f8pcuBSMGeo8BA+lCABBzACtpGrwmOLa+yFTLiZ24ucl0MKJtZqZ8MpC+jES6kQYt sFJjWy6/fUUem8aYYOr+VuZVxdPWAQHHiKSck= MIME-Version: 1.0 Received: by 10.150.212.14 with SMTP id k14mr6216738ybg.10.1238244403540; Sat, 28 Mar 2009 05:46:43 -0700 (PDT) In-Reply-To: <49CD6E90.6050303@FreeBSD.org> References: <7362.1238195438@critter.freebsd.dk> <49CD6E90.6050303@FreeBSD.org> Date: Sat, 28 Mar 2009 07:46:43 -0500 Message-ID: <2fd864e0903280546r5eb7ae8avc96fd2d21cac1a7e@mail.gmail.com> From: Astrodog To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 12:46:44 -0000 On Fri, Mar 27, 2009 at 7:25 PM, Jason Evans wrote: > Robert Watson wrote: >> >> On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >>> >>> In message , >>> Robert Wats on writes: >>> >>>> In which case user application threads will need to know their CPU [..= .] >>> >>> Didn't jemalloc solve that problem once already ? >> >> I think jemalloc implements thread-affinity for arenas rather than >> CPU-affinity in the strict sense, but I may misread. > > CPU affinity is of limited use to malloc unless it can safely pin threads= to > CPUs. =A0Unfortunately, malloc cannot muck with CPU affinity, since that'= s up > to the application. =A0Therefore, as you say, jemalloc implements (dynami= cally > balanced) arena affinity. > > It might work okay in practice to use the current CPU ID to decide which > arena to use, if the scheduler does not often migrate running processes. = =A0I > haven't explored that possibility though, since the infrastructure for > cheaply querying the CPU ID doesn't currently (to my knowledge) exist. > > Jason Hopefully, this is a more reasonable CC list, yet will still get to everyon= e... First, re: scottl's creating pages on fork, I might be able to do that. I'll give it a shot when I get back to my machine at home, and let you know if it either works, or just blows up in my face, and causes the usual brain melt I get when I poke at VM stuff. As far as thread CPU affinity goes, as I understand things, this is implemented in sched_ule, and one could certainly make a version of malloc that takes advantage of this... however, locking a thread to a CPU has some pretty significant side effects. Even if you only lock running/runnable threads to a CPU, you could end up with some horribly unbalanced scheduling, depending entirely on the load of the machine when the threads are started, and pinned, that the scheduler cannot balance, even on a system with moderate load, which would probably hurt performance more than most things one could do trying to get an accurate, fast timer. If nothing else, it'd be a nightmare on machines with intermittent high load, and it'd produce fairly inconsistent performance. For cheaply getting the current CPUID, if there's actual demand for this information in userland applications, it should be fairly easy to add to the scheduler, assuming it doesn't already exist. If JeffR, etc doesn't have time, let me know and I'll crank out a patch. --- Harrison Grundy From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 12:56:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 623CD1065670 for ; Sat, 28 Mar 2009 12:56:01 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 121E38FC1A for ; Sat, 28 Mar 2009 12:56:00 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id E358F79945; Sat, 28 Mar 2009 15:55:58 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1705276877; Sat, 28 Mar 2009 15:55:58 +0300 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n2SCtwRQ004898; Sat, 28 Mar 2009 15:55:58 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n2SCtriW004886; Sat, 28 Mar 2009 15:55:53 +0300 (MSK) (envelope-from dchagin) Date: Sat, 28 Mar 2009 15:55:53 +0300 From: Chagin Dmitry To: Alexander Best Message-ID: <20090328125553.GA4132@dchagin.static.corbina.ru> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: linux 3d applications keep crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 12:56:01 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2009 at 01:29:33PM +0100, Alexander Best wrote: > I filed a problem report concerning this problem. here it is: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D133144 >=20 thank you :) --=20 Have fun! chd --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknOHlYACgkQ0t2Tb3OO/O3yYQCdEFDVUTaIyn3YjFm1FptwvUTQ ODsAoLZbIllVc/Y/F1uhPeXSmxoPIV5O =AX/4 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 13:16:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0171065675 for ; Sat, 28 Mar 2009 13:16:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-214.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 81C538FC1F; Sat, 28 Mar 2009 13:16:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49CE231C.9080609@FreeBSD.org> Date: Sat, 28 Mar 2009 13:16:12 +0000 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Wenji Wu References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:16:14 -0000 Wenji Wu wrote: > I, Could anybody help me out? Thanks in advance. > > LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT. I loaded FreeBSD 8.0-Current on my system, and try to run LOCK PROFILING. I have added the “options LOCK_PROFILING” to the configure file and rebuild the kernel. Then I reboot the system, and run “sysctl –a|grep lock” to check if the lock debugging has been enabled. But NO lock debugging related parameters show up. LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT! > > I have repeated the same operations on FreeBSD 7.1, “sysctl –a|grep lock” shows “LOCK PROFILING” works. So what happens to FreeBSD 8.0-CURRENT? > > Thanks, It certainly does work in 8.0. Is it possible you forgot to install the rebuilt kernel? Kris From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 13:22:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0391065675 for ; Sat, 28 Mar 2009 13:22:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 1237C8FC1C for ; Sat, 28 Mar 2009 13:22:47 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 16098 invoked by uid 60001); 28 Mar 2009 13:22:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238246567; bh=q7u9pIihOcSORv4BFpbfvRV7XIc6oy3BpKyF5pPa/jA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=z1ir4nlpV6lsJbdaHKbAZFOQEz+yI8rnPv30iAuVUJORDO6es8IupU0GS2LX7wc6yau7jnkx7PL31+uKvB0F6VtlhAeaWKK2z9MUJ6WbpHyQV0qLSo6P7JtZWVPRsAAmK9/krPS3iXSZ8X5bNEG/TmzC0I7K+oCtB2mYNHbVrkU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=3kPHOAwaUA7hnI8rfTcb2vlOIRBQykB2n+ltF1A/IFC+QsXVO2yycSOpxFZoAEOr6t7y2C+w0RyEoJG6cDF6WMvAKnAeU+cTdC3fMJTOQEbT8GmPvDwbibO7g9Xy+mv1EvrR2UPoW5vX4xBaWdJnq36gd9KLjrg+BrAl2S33mUI=; Message-ID: <511792.14022.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: GYA56AEVM1nPkM9WWxb1CYW4.6P7DurnL4VPD_bkH993dkcwkiJqtTCUxwucsdT6ykw_UEtsdsC3g8rVDGBOnm6KdDqgSa4Uxvdoo27jt1WTlWhb3s2XE32ydRimoOdYu6OLkIva30kr2rBopY8aL.rnUhpmdIA3tPfFdDqTaYMKbqY0jD8YBKnEh9wdvOqtadqnFDJxcQnwOUCOZXYSJAuNMh7TCjG4_fnEZ_K31IxlFtA_BGULox6uvwqKiq.50w5WmA-- Received: from [98.242.222.229] by web63903.mail.re1.yahoo.com via HTTP; Sat, 28 Mar 2009 06:22:47 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sat, 28 Mar 2009 06:22:47 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: ACPI error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:22:49 -0000 I'm getting an APIC error: kernel: ACPI Error (tbxfroot-0308): A valid RSDP was not found [20070320] kernel: ACPI: Table initialisation failed: AE_NOT_FOUND kernel: ACPI: Try disabling either ACPI or apic support. Is there any hope for this? Unfortunately with ACPI off, the Hard Drive is found at ad6 where its found at ad8 on 7, so upgrading on this box will be more painful than usual. Its a relatively new (intel bigby) chipset. Barney From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 13:21:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13309106566B for ; Sat, 28 Mar 2009 13:21:59 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id ECD6D8FC1C for ; Sat, 28 Mar 2009 13:21:58 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: by rv-out-0506.google.com with SMTP id l9so2008011rvb.43 for ; Sat, 28 Mar 2009 06:21:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.230.7 with SMTP id c7mr1340729wfh.45.1238246518386; Sat, 28 Mar 2009 06:21:58 -0700 (PDT) Date: Sat, 28 Mar 2009 21:21:58 +0800 Message-ID: From: Mars G Miro To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 Mar 2009 13:45:30 +0000 Subject: booting from SATA DVD-RAM, no go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:21:59 -0000 Hi guys It just does: ... Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX ... Then the screen goes blank. I've tried setting AHCI and unsetting it (IDE mode), still no go. Tried the 7-STABLE / 8-CURRENT (amd64) snapshots from February. This is on an LG GH22LS40 on a Gigabyte MA78GM-S2H mobo w/ the latest BIOS from their website. Clues? I'll prolly plug an old CD-ROM just to install FreeBSD on it. Thanks. -- cheers mars ----- P. J. O'Rourke - "If government were a product, selling it would be illegal." From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 13:45:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECDC810656C7 for ; Sat, 28 Mar 2009 13:45:40 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: from hunter.Sisis.de (hunter.sisis.de [193.31.11.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4448FC1B for ; Sat, 28 Mar 2009 13:45:39 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id OAA01831 for ; Sat, 28 Mar 2009 14:08:17 +0100 (CET) (envelope-from matthias.apitz@oclc.org) Received: from ppp-93-104-36-218.dynamic.mnet-online.de(93.104.36.218) by hunter.Sisis.de via smap (V2.1) id xma001809; Sat, 28 Mar 09 14:07:47 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2SDHOjW011719 for freebsd-current@freebsd.org; Sat, 28 Mar 2009 14:17:24 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Sat, 28 Mar 2009 14:17:24 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090328131724.GA11667@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) Subject: missing lkm if_ppp in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:45:41 -0000 Hi, What is the correct way to get the module if_ppp build during "make buildkernel KERNCONF=GENERIC"? thx matthias # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ~/pppd.sh huawei pppd: This system lacks kernel support for PPP. To include PPP support in the kernel, please add "device ppp" to your kernel config or load the if_ppp module. # kldload if_ppp kldload: can't load if_ppp: No such file or directory # ls /boot/kernel/if_p* /boot/kernel/if_patm.ko /boot/kernel/if_pcn.ko -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 13:47:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8283110656DB for ; Sat, 28 Mar 2009 13:47:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 27BBF8FC13 for ; Sat, 28 Mar 2009 13:47:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LnYsy-000DCp-4c; Sat, 28 Mar 2009 15:47:44 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n2SDlf3J095198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Mar 2009 15:47:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n2SDlfh3043011; Sat, 28 Mar 2009 15:47:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n2SDlfSE043010; Sat, 28 Mar 2009 15:47:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Mar 2009 15:47:40 +0200 From: Kostik Belousov To: Ed Schouten Message-ID: <20090328134740.GI31897@deviant.kiev.zoral.com.ua> References: <20090328102552.GR73108@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OkEUgNLVrkMgtt3o" Content-Disposition: inline In-Reply-To: <20090328102552.GR73108@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LnYsy-000DCp-4c 161e94a6d6f4157ba41e96a2ed7f2e0f X-Terabit: YES Cc: FreeBSD Current Subject: Re: LD_PRELOAD broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:47:47 -0000 --OkEUgNLVrkMgtt3o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2009 at 11:25:52AM +0100, Ed Schouten wrote: > Hi all, >=20 > Is it possible that the changes to rtld-elf the last couple of weeks > cause LD_PRELOAD to crash applications on startup? Very simple way to > reproduce: >=20 > LD_PRELOAD=3D/lib/libc.so.7 ls >=20 > This causes a segmentation fault on startup, at least on AMD64. Yes. The following fixes the case for me. diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 823427a..d98ade7 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -1125,7 +1125,7 @@ find_library(const char *xname, const Obj_Entry *refo= bj) xname); return NULL; } - if (refobj->z_origin) + if (refobj !=3D NULL && refobj->z_origin) return origin_subst(xname, refobj->origin_path); else return xstrdup(xname); --OkEUgNLVrkMgtt3o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknOKnwACgkQC3+MBN1Mb4j8JQCg2jXJ6FVuBM/YnVBg3ghKdEbB aoAAoJiA1wJgIfXunExSEXi1UVA0kW5U =DqFT -----END PGP SIGNATURE----- --OkEUgNLVrkMgtt3o-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 14:24:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 617F61065672 for ; Sat, 28 Mar 2009 14:24:10 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [213.83.63.54]) by mx1.freebsd.org (Postfix) with ESMTP id 252CE8FC16 for ; Sat, 28 Mar 2009 14:24:10 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.50) id 1LnYrx-0000A6-PY; Sat, 28 Mar 2009 14:46:42 +0100 Date: Sat, 28 Mar 2009 14:46:41 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090328134641.GA32589@sh4-5.1blu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.9i Subject: missing lkm if_ppp in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 14:24:10 -0000 Hi, What is the correct way to get the module if_ppp build during "make buildkernel KERNCONF=GENERIC"? thx matthias # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ~/pppd.sh huawei pppd: This system lacks kernel support for PPP. To include PPP support in the kernel, please add "device ppp" to your kernel config or load the if_ppp module. # kldload if_ppp kldload: can't load if_ppp: No such file or directory # ls /boot/kernel/if_p* /boot/kernel/if_patm.ko /boot/kernel/if_pcn.ko -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 14:40:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2029106566B for ; Sat, 28 Mar 2009 14:40:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 580598FC15 for ; Sat, 28 Mar 2009 14:40:46 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id 4so283183eyf.7 for ; Sat, 28 Mar 2009 07:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tzKmUhdT7x6b4i+Ve2WkndrVLkjIBm2/Oa9IUjMd544=; b=D/Lsbd7sof6WAVVphx5hph9OLdXrjGbUYWq24L4qUD/CFpld4YCXgR/PPNatWucncN IrtNsdbpYbyoPhxzxNuXOjAvQLwBf0tGbYYyExYhaJubPfyxmhG2IPzGivWvGmCgXwqv Hajif51TtS2YovGN3mCeC3c538aE90CuxcK8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HT8yyEmste6lRopaxA9Z0V+wu9reqKCW1SSDiyA/ushz3RKBJdAqh0/opqVtKr5dwB gAubmfHHYF1RX7lEvg/Gciv1aoQbQ1+kCUdH057prKQbX+QozHBlKnEEkL1EOmfedpxC TUa0ICvVDs6UYH94tnQAIwKtvsfeOLDj4vczM= MIME-Version: 1.0 Received: by 10.210.42.20 with SMTP id p20mr2542928ebp.66.1238251246304; Sat, 28 Mar 2009 07:40:46 -0700 (PDT) In-Reply-To: <20090328131724.GA11667@rebelion.Sisis.de> References: <20090328131724.GA11667@rebelion.Sisis.de> Date: Sat, 28 Mar 2009 15:40:46 +0100 Message-ID: <3a142e750903280740j7120b896r40671c8c535922b4@mail.gmail.com> From: "Paul B. Mahol" To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: missing lkm if_ppp in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 14:40:48 -0000 On 3/28/09, Matthias Apitz wrote: > > Hi, > > What is the correct way to get the module if_ppp build during > "make buildkernel KERNCONF=GENERIC"? > thx None. Use userland ppp instead. More about why is available via mailing list archive .... -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 14:42:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C772106566C for ; Sat, 28 Mar 2009 14:42:04 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF0378FC20 for ; Sat, 28 Mar 2009 14:42:03 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:8576:ff3b:1e94:7ebc] (unknown [IPv6:2001:7b8:3a7:0:8576:ff3b:1e94:7ebc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CC21B5C43; Sat, 28 Mar 2009 15:42:02 +0100 (CET) Message-ID: <49CE373C.2050908@andric.com> Date: Sat, 28 Mar 2009 15:42:04 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b4pre) Gecko/20090324 Shredder/3.0b3pre MIME-Version: 1.0 To: Matthias Apitz References: <20090328134641.GA32589@sh4-5.1blu.de> In-Reply-To: <20090328134641.GA32589@sh4-5.1blu.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: missing lkm if_ppp in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 14:42:04 -0000 On 2009-03-28 14:46, Matthias Apitz wrote: > What is the correct way to get the module if_ppp build during > "make buildkernel KERNCONF=GENERIC"? The build of ppp has been disabled, as per Robert Watson's announcement on 2009-02-16: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0902161233440.5806 and this followup, on 2009-03-15: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0903151002310.92013 From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 14:45:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F9C1065688 for ; Sat, 28 Mar 2009 14:45:56 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id BAAF38FC17 for ; Sat, 28 Mar 2009 14:45:55 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.151.104] (port=24873 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LnZnF-000O2N-Ol; Sat, 28 Mar 2009 17:45:53 +0300 Message-ID: <49CE3832.5060203@lissyara.su> Date: Sat, 28 Mar 2009 17:46:10 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Hans Petter Selasky References: <49C7FE13.90808@lissyara.su> <200903240846.35938.hselasky@c2i.net> In-Reply-To: <200903240846.35938.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 14:45:57 -0000 Hans Petter Selasky пишет: > On Monday 23 March 2009, Alex Keda wrote: >> I have USB floppy. >> >> Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device >> descriptor at addr 3 failed! >> Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 >> Mar 24 00:11:26 HP kernel: umass0: > 0/0, rev 1.10/2.00, addr 3> on usbus0 >> Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 > ^^^^ > Edit /sys/dev/usb/storage/umass.c > > And remove the quirk entry for your device. Maybe it is not correct. I delete UMASS_PROTO_SCSI. But: Mar 28 17:44:01 HP kernel: usb2_alloc_device:1516: getting device descriptor at addr 3 failed! Mar 28 17:44:02 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 28 17:44:03 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 28 17:44:03 HP kernel: ugen0.3: <> at usbus0 (disconnected) Mar 28 17:44:03 HP kernel: uhub_reattach_port:413: could not allocate new device! > > --HPS > >> Mar 24 00:11:27 HP kernel: umass0:2:0:-1: Attached to scbus2 >> Mar 24 00:11:27 HP kernel: xptioctl: pass driver is not in the kernel >> Mar 24 00:11:27 HP kernel: xptioctl: put "device pass" in your kernel >> config file >> >> >> but, >> >> HP$ grep "pass" /usr/src/sys/amd64/conf/GENERIC >> device pass # Passthrough device (direct SCSI access) >> device aacp # SCSI passthrough for aac (requires CAM) >> HP$ >> >> If I unplug and plug it to the same port: >> >> Mar 24 00:19:12 HP kernel: usb2_alloc_device:1516: getting device >> descriptor at addr 3 failed! >> Mar 24 00:19:12 HP kernel: usb2_req_re_enumerate:1434: getting device >> descriptor at addr 3 failed! >> Mar 24 00:19:14 HP kernel: usb2_req_re_enumerate:1434: getting device >> descriptor at addr 3 failed! >> Mar 24 00:19:14 HP kernel: ugen0.3: <> at usbus0 (disconnected) >> Mar 24 00:19:14 HP kernel: uhub_reattach_port:413: could not allocate >> new device! >> >> If I plug it to another port - it detect, but need "pass" driver =) >> >> ============ >> I have USB mouse. If I plug it first time - all OK. If second - to the >> some port: >> Mar 24 00:21:45 HP kernel: ugen0.3: at usbus0 >> Mar 24 00:21:45 HP kernel: ums0: > rev 2.00/3.40, addr 3> on usbus0 >> Mar 24 00:21:45 HP kernel: ums0: error reading report description >> Mar 24 00:21:45 HP kernel: device_attach: ums0 attach returned 12 >> >> ======== >> HP$ uname -a >> FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 23 >> 22:45:17 MSK 2009 >> lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 >> HP$ >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 14:54:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD0C106566B for ; Sat, 28 Mar 2009 14:54:41 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4A98FC13 for ; Sat, 28 Mar 2009 14:54:41 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qyk40 with SMTP id 40so2830150qyk.3 for ; Sat, 28 Mar 2009 07:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=1UFqNOisXteVb6Uc866qTtILi/VyYfsn5HfeVfvgo74=; b=WBqPPpZx7lySjLsMdduG+6Cv/UCpZwIT15rM8SPDQdHYQJQ9cb8APXH5VuvsFg5nRG IvosoPww4M5Vb9u4MtkcsiiVNF4b/F6+BjOT+JedW9M2HOTIdj6zHFgz7qv2L+WICZqN g5Tg2e0JGQ4dvu4neHjT1y+8VSCVt3nVQ/yVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=e7+ImWlx8XYHK8sKVZmsHUm+uA64ZswG+L0cXFtMhdnuQ4Ed3OwyXVozRzXUcvXEBR 4UKR9cclPqTWjFJD0aS9itSZmIRtXzn+24IbWG4EEBm4MnSn17qPWh0l2ArpFNHHOq7G gUnw/5OP5QlaRnhgJpnuMIwgbOaQhM/6KXWQE= Received: by 10.224.2.138 with SMTP id 10mr4150411qaj.296.1238252078627; Sat, 28 Mar 2009 07:54:38 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.18.191]) by mx.google.com with ESMTPS id 9sm5955129yxs.16.2009.03.28.07.54.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 07:54:38 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id B30E0B8074; Sat, 28 Mar 2009 11:54:20 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Sat, 28 Mar 2009 11:54:20 -0300 (BRT) Message-ID: <4752992355368de13c4fad50f47c10ca.squirrel@10.1.1.10> Date: Sat, 28 Mar 2009 11:54:20 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: why booting from install media (8.0-200902) my usb disk is seen, and after installed it's not ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 14:54:42 -0000 is there a way I can reproduce boot cd enviroment ? I've already copied all I can think would matter from install media and no luck :( thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:02:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 351A7106566B for ; Sat, 28 Mar 2009 15:02:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id C1AD18FC1C for ; Sat, 28 Mar 2009 15:02:09 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=d6JgnbdtQLolSaSLcQMA:9 a=kdaF-5qNX4sAGMisFpNc9NR4E04A:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1047952449; Sat, 28 Mar 2009 16:02:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 16:04:38 +0100 User-Agent: KMail/1.9.7 References: <49C7FE13.90808@lissyara.su> <200903240846.35938.hselasky@c2i.net> <49CE3832.5060203@lissyara.su> In-Reply-To: <49CE3832.5060203@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903281604.38753.hselasky@c2i.net> Cc: Alex Keda Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:02:10 -0000 On Saturday 28 March 2009, Alex Keda wrote: > Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Monday 23 March 2009, Alex Keda wrote: > >> I have USB floppy. > >> > >> Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device > >> descriptor at addr 3 failed! > >> Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 > >> Mar 24 00:11:26 HP kernel: umass0: >> 0/0, rev 1.10/2.00, addr 3> on usbus0 > >> Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks =3D 0x= 0100 > > > > ^^= ^^ > > Edit /sys/dev/usb/storage/umass.c > > > > And remove the quirk entry for your device. Maybe it is not correct. > > I delete UMASS_PROTO_SCSI. > But: > Mar 28 17:44:01 HP kernel: usb2_alloc_device:1516: getting device > descriptor at addr 3 failed! > Mar 28 17:44:02 HP kernel: usb2_req_re_enumerate:1434: getting device > descriptor at addr 3 failed! > Mar 28 17:44:03 HP kernel: usb2_req_re_enumerate:1434: getting device > descriptor at addr 3 failed! > Mar 28 17:44:03 HP kernel: ugen0.3: <> at usbus0 (disconnected) > Mar 28 17:44:03 HP kernel: uhub_reattach_port:413: could not allocate > new device! > What happens if you use an external HUB to connect the device ? =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:04:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6851D1065807 for ; Sat, 28 Mar 2009 15:04:42 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6FBEF8FC88 for ; Sat, 28 Mar 2009 15:04:21 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2SF4HhU011569; Sat, 28 Mar 2009 16:04:18 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CE3C71.4060006@fgznet.ch> Date: Sat, 28 Mar 2009 16:04:17 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> <200903281243.36540.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Stefan Bethke , Hans Petter Selasky Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:05:05 -0000 Stefan Bethke wrote: > Am 28.03.2009 um 12:43 schrieb Hans Petter Selasky: > >> On Saturday 28 March 2009, Stefan Bethke wrote: >>> I've run into the same issue a couple of days ago. >>> >>> Loading uhci as a module is sufficient to trigger the messages. No >>> device was attached during the output below; in other tests I noticed >>> that uhci appears to not see any device that VMware has attached. >> >> Is it possible to get some debugging from the VM-ware? > > Apparently some internal debugging can be activated, but I'm not sure > what it will show. I can try and find out. I did activate this debugging but I could not see anything useful. At the same time I had to restart the guest to make this debugging active. But now I do not seem to be able to trigger the issue we have. Though, I do not have modules. I'll try harder. At the moment it seems to work here. Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:17:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 402C8106566B for ; Sat, 28 Mar 2009 15:17:47 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id F12898FC1A for ; Sat, 28 Mar 2009 15:17:46 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.151.104] (port=29760 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LnaI5-00057M-LV; Sat, 28 Mar 2009 18:17:45 +0300 Message-ID: <49CE3FAA.2020604@lissyara.su> Date: Sat, 28 Mar 2009 18:18:02 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Hans Petter Selasky References: <49C7FE13.90808@lissyara.su> <200903240846.35938.hselasky@c2i.net> <49CE3832.5060203@lissyara.su> <200903281604.38753.hselasky@c2i.net> In-Reply-To: <200903281604.38753.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:17:47 -0000 Hans Petter Selasky пишет: > On Saturday 28 March 2009, Alex Keda wrote: >> Hans Petter Selasky пишет: >>> On Monday 23 March 2009, Alex Keda wrote: >>>> I have USB floppy. >>>> >>>> Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device >>>> descriptor at addr 3 failed! >>>> Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 >>>> Mar 24 00:11:26 HP kernel: umass0: >>> 0/0, rev 1.10/2.00, addr 3> on usbus0 >>>> Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 >>> ^^^^ >>> Edit /sys/dev/usb/storage/umass.c >>> >>> And remove the quirk entry for your device. Maybe it is not correct. >> I delete UMASS_PROTO_SCSI. >> But: >> Mar 28 17:44:01 HP kernel: usb2_alloc_device:1516: getting device >> descriptor at addr 3 failed! >> Mar 28 17:44:02 HP kernel: usb2_req_re_enumerate:1434: getting device >> descriptor at addr 3 failed! >> Mar 28 17:44:03 HP kernel: usb2_req_re_enumerate:1434: getting device >> descriptor at addr 3 failed! >> Mar 28 17:44:03 HP kernel: ugen0.3: <> at usbus0 (disconnected) >> Mar 28 17:44:03 HP kernel: uhub_reattach_port:413: could not allocate >> new device! >> > > What happens if you use an external HUB to connect the device ? I do not have external hub =) I have two ports in laptop - that will be enough =) > > --HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:19:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0921065711 for ; Sat, 28 Mar 2009 15:19:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id DAA228FC08 for ; Sat, 28 Mar 2009 15:19:39 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=IwOLgU4Bi2eydhwbuUsA:9 a=D9i2aaj29YcLuecoJskA:7 a=YkLwnRjskbrxjAmMdRNUggW6RrwA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1114644226; Sat, 28 Mar 2009 16:19:37 +0100 From: Hans Petter Selasky To: Alex Keda Date: Sat, 28 Mar 2009 16:22:07 +0100 User-Agent: KMail/1.9.7 References: <49C7FE13.90808@lissyara.su> <200903281604.38753.hselasky@c2i.net> <49CE3FAA.2020604@lissyara.su> In-Reply-To: <49CE3FAA.2020604@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903281622.08116.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:19:40 -0000 On Saturday 28 March 2009, Alex Keda wrote: > Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Saturday 28 March 2009, Alex Keda wrote: > >> Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>> On Monday 23 March 2009, Alex Keda wrote: > >>>> I have USB floppy. > >>>> > >>>> Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device > >>>> descriptor at addr 3 failed! > >>>> Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 > >>>> Mar 24 00:11:26 HP kernel: umass0: >>>> class 0/0, rev 1.10/2.00, addr 3> on usbus0 > >>>> Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks =3D > >>>> 0x0100 > >>> > >>> =20 > >>> ^^^^ Edit /sys/dev/usb/storage/umass.c > >>> > >>> And remove the quirk entry for your device. Maybe it is not correct. > >> > >> I delete UMASS_PROTO_SCSI. > >> But: > >> Mar 28 17:44:01 HP kernel: usb2_alloc_device:1516: getting device > >> descriptor at addr 3 failed! > >> Mar 28 17:44:02 HP kernel: usb2_req_re_enumerate:1434: getting device > >> descriptor at addr 3 failed! > >> Mar 28 17:44:03 HP kernel: usb2_req_re_enumerate:1434: getting device > >> descriptor at addr 3 failed! > >> Mar 28 17:44:03 HP kernel: ugen0.3: <> at usbus0 (disconnected) > >> Mar 28 17:44:03 HP kernel: uhub_reattach_port:413: could not allocate > >> new device! > > > > What happens if you use an external HUB to connect the device ? > > I do not have external hub =3D) > I have two ports in laptop - that will be enough =3D) Before your device attached in one of the ports, and now after you removed = =20 the quirk? =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:24:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 629B0106564A for ; Sat, 28 Mar 2009 15:24:38 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF048FC15 for ; Sat, 28 Mar 2009 15:24:37 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.151.104] (port=19467 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LnaOi-0006Sx-UA; Sat, 28 Mar 2009 18:24:37 +0300 Message-ID: <49CE4145.7020504@lissyara.su> Date: Sat, 28 Mar 2009 18:24:53 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Hans Petter Selasky References: <49C7FE13.90808@lissyara.su> <200903281604.38753.hselasky@c2i.net> <49CE3FAA.2020604@lissyara.su> <200903281622.08116.hselasky@c2i.net> In-Reply-To: <200903281622.08116.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:24:38 -0000 Hans Petter Selasky пишет: > On Saturday 28 March 2009, Alex Keda wrote: >> Hans Petter Selasky пишет: >>> On Saturday 28 March 2009, Alex Keda wrote: >>>> Hans Petter Selasky пишет: >>>>> On Monday 23 March 2009, Alex Keda wrote: >>>>>> I have USB floppy. >>>>>> >>>>>> Mar 24 00:11:25 HP kernel: usb2_alloc_device:1516: getting device >>>>>> descriptor at addr 3 failed! >>>>>> Mar 24 00:11:26 HP kernel: ugen0.3: at usbus0 >>>>>> Mar 24 00:11:26 HP kernel: umass0: >>>>> class 0/0, rev 1.10/2.00, addr 3> on usbus0 >>>>>> Mar 24 00:11:26 HP kernel: umass0: SCSI over Bulk-Only; quirks = >>>>>> 0x0100 >>>>> >>>>> ^^^^ Edit /sys/dev/usb/storage/umass.c >>>>> >>>>> And remove the quirk entry for your device. Maybe it is not correct. >>>> I delete UMASS_PROTO_SCSI. >>>> But: >>>> Mar 28 17:44:01 HP kernel: usb2_alloc_device:1516: getting device >>>> descriptor at addr 3 failed! >>>> Mar 28 17:44:02 HP kernel: usb2_req_re_enumerate:1434: getting device >>>> descriptor at addr 3 failed! >>>> Mar 28 17:44:03 HP kernel: usb2_req_re_enumerate:1434: getting device >>>> descriptor at addr 3 failed! >>>> Mar 28 17:44:03 HP kernel: ugen0.3: <> at usbus0 (disconnected) >>>> Mar 28 17:44:03 HP kernel: uhub_reattach_port:413: could not allocate >>>> new device! >>> What happens if you use an external HUB to connect the device ? >> I do not have external hub =) >> I have two ports in laptop - that will be enough =) > > Before your device attached in one of the ports, and now after you removed > the quirk? Very strange. I swap mouse and floppy: Mar 28 18:22:24 HP kernel: ums0: at uhub1, port 1, addr 2 (disconnected) Mar 28 18:22:24 HP kernel: ugen1.2: at usbus1 (disconnected) Mar 28 18:22:33 HP kernel: ugen1.2: at usbus1 Mar 28 18:22:33 HP kernel: umass0: on usbus1 Mar 28 18:22:33 HP kernel: umass0: (unknown 0x00) over Bulk-Only; quirks = 0x0100 Mar 28 18:22:34 HP kernel: umass0:2:0:-1: Attached to scbus2 Mar 28 18:22:52 HP kernel: usb2_alloc_device:1516: getting device descriptor at addr 3 failed! Mar 28 18:22:53 HP kernel: ugen0.3: at usbus0 Mar 28 18:22:53 HP kernel: ums0: on usbus0 Mar 28 18:22:53 HP kernel: ums0: error reading report description Mar 28 18:22:53 HP kernel: device_attach: ums0 attach returned 12 Mar 28 18:22:53 HP kernel: ums0: on usbus0 Mar 28 18:22:53 HP kernel: ums0: 3 buttons and [XYZ] coordinates Then, swap again: Mar 28 18:23:34 HP kernel: ums0: at uhub0, port 1, addr 3 (disconnected) Mar 28 18:23:34 HP kernel: ugen0.3: at usbus0 (disconnected) Mar 28 18:23:36 HP kernel: umass0: at uhub1, port 1, addr 2 (disconnected) Mar 28 18:23:36 HP kernel: ugen1.2: at usbus1 (disconnected) Mar 28 18:23:39 HP kernel: ugen1.2: at usbus1 Mar 28 18:23:39 HP kernel: ums0: on usbus1 Mar 28 18:23:39 HP kernel: ums0: 3 buttons and [XYZ] coordinates Mar 28 18:23:42 HP kernel: usb2_alloc_device:1516: getting device descriptor at addr 3 failed! Mar 28 18:23:44 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 28 18:23:45 HP kernel: usb2_req_re_enumerate:1434: getting device descriptor at addr 3 failed! Mar 28 18:23:45 HP kernel: usb2_alloc_device:1667: Failure selecting configuration index 0: USB_ERR_IOERROR, port 1, addr 3 (ignored) Mar 28 18:23:45 HP kernel: ugen0.3: at usbus0 Mar 28 18:23:45 HP kernel: pid 5873 (hald-probe-usb2-dev), uid 0: exited on signal 11 (core dumped) Mouse works well in first, and second port... From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:37:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CBE710656C9 for ; Sat, 28 Mar 2009 15:37:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 3161C8FC18 for ; Sat, 28 Mar 2009 15:37:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=LowDZw6Rjmady3YE8k4A:9 a=VWfQ5PWUdajkz1b7SnYA:7 a=rL2N905F4hwTatfnD_umSN_-bkwA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 473289590; Sat, 28 Mar 2009 16:37:27 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Mar 2009 16:39:54 +0100 User-Agent: KMail/1.9.7 References: <49C7FE13.90808@lissyara.su> <200903281622.08116.hselasky@c2i.net> <49CE4145.7020504@lissyara.su> In-Reply-To: <49CE4145.7020504@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903281639.55044.hselasky@c2i.net> Cc: Alex Keda Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:37:29 -0000 On Saturday 28 March 2009, Alex Keda wrote: > Mar 28 18:23:45 HP kernel: pid 5873 (hald-probe-usb2-dev), uid 0: exited > on signal 11 (core dumped) Looks like a problem in hald. Could you debug that? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:39:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D899E1065672 for ; Sat, 28 Mar 2009 15:39:23 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 954728FC23 for ; Sat, 28 Mar 2009 15:39:23 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.151.104] (port=14231 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lnad0-0009R8-9V; Sat, 28 Mar 2009 18:39:22 +0300 Message-ID: <49CE44BB.8000001@lissyara.su> Date: Sat, 28 Mar 2009 18:39:39 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Hans Petter Selasky References: <49C7FE13.90808@lissyara.su> <200903281622.08116.hselasky@c2i.net> <49CE4145.7020504@lissyara.su> <200903281639.55044.hselasky@c2i.net> In-Reply-To: <200903281639.55044.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:39:24 -0000 Hans Petter Selasky пишет: > On Saturday 28 March 2009, Alex Keda wrote: >> Mar 28 18:23:45 HP kernel: pid 5873 (hald-probe-usb2-dev), uid 0: exited >> on signal 11 (core dumped) > > Looks like a problem in hald. Could you debug that? What I can do? From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:41:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 521121065676 for ; Sat, 28 Mar 2009 15:41:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E26848FC1C for ; Sat, 28 Mar 2009 15:41:20 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id BFD921CF09; Sat, 28 Mar 2009 16:41:19 +0100 (CET) Date: Sat, 28 Mar 2009 16:41:19 +0100 From: Ed Schouten To: Kostik Belousov Message-ID: <20090328154119.GS73108@hoeg.nl> References: <20090328102552.GR73108@hoeg.nl> <20090328134740.GI31897@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QRtLtq+kfJNLc57H" Content-Disposition: inline In-Reply-To: <20090328134740.GI31897@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: LD_PRELOAD broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:41:21 -0000 --QRtLtq+kfJNLc57H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kostik, * Kostik Belousov wrote: > On Sat, Mar 28, 2009 at 11:25:52AM +0100, Ed Schouten wrote: > > Hi all, > >=20 > > Is it possible that the changes to rtld-elf the last couple of weeks > > cause LD_PRELOAD to crash applications on startup? Very simple way to > > reproduce: > >=20 > > LD_PRELOAD=3D/lib/libc.so.7 ls > >=20 > > This causes a segmentation fault on startup, at least on AMD64. >=20 > Yes. The following fixes the case for me. >=20 > This seems to make LD_PRELOAD work again. I tested the patch using sysutils/hidesvn, which uses LD_PRELOAD. Thanks a lot! --=20 Ed Schouten WWW: http://80386.nl/ --QRtLtq+kfJNLc57H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknORR8ACgkQ52SDGA2eCwU88wCeOPbmhfNx3ZNicPoJkKSNVym4 wxUAnRJAwlZnX2Cq/H6iP+GcitfOI4N2 =6UF+ -----END PGP SIGNATURE----- --QRtLtq+kfJNLc57H-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:52:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF25B106564A for ; Sat, 28 Mar 2009 15:52:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 72B658FC13 for ; Sat, 28 Mar 2009 15:52:20 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=QVpDKpNSdgQptwjU3MgA:9 a=FWJfoQhrllO8U6zqsHsA:7 a=ufGHPhrSzcU6XC4aksitOod_UiYA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 473293808; Sat, 28 Mar 2009 16:52:19 +0100 From: Hans Petter Selasky To: Alex Keda Date: Sat, 28 Mar 2009 16:54:46 +0100 User-Agent: KMail/1.9.7 References: <49C7FE13.90808@lissyara.su> <200903281639.55044.hselasky@c2i.net> <49CE44BB.8000001@lissyara.su> In-Reply-To: <49CE44BB.8000001@lissyara.su> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903281654.47735.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:52:21 -0000 On Saturday 28 March 2009, Alex Keda wrote: > Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Saturday 28 March 2009, Alex Keda wrote: > >> Mar 28 18:23:45 HP kernel: pid 5873 (hald-probe-usb2-dev), uid 0: exit= ed > >> on signal 11 (core dumped) > > > > Looks like a problem in hald. Could you debug that? > > What I can do? Run gdb on the core dump. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 16:42:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B60106564A for ; Sat, 28 Mar 2009 16:42:07 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 572888FC22 for ; Sat, 28 Mar 2009 16:42:06 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by bwz8 with SMTP id 8so1314533bwz.43 for ; Sat, 28 Mar 2009 09:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iWaMu9qxFbuweKXD/RMe+vRNkve2DGt1sojaRr5Qkkc=; b=KFYnTf0aaUEAoI1SdHMesIvJXE3rfnkRHeQVgnyl2rtcAJl7tKHlcrMro665rtYaOU oeW4aVwAF4PgMHMLAuhcjVB5BYkw+PE6QCEMXf6tsijdA8FwWmjTDLdXfzn4+ZSZ0AuV nf5uIoFLSqIdblq3zqgEGxR3owe/OdVhseTYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e4Ucv1Tmz7KxpQgKDD2DbNyqxBfXn1wwWzD23Llvn+mm95UIojoINIw2C6oeeQqSuZ b0jHctylmRKTfU1E8gSli5gh+rnzSYH0CS2qAm9TS9yx8YmIcPat6NbEN1K3E72Xp8y5 mt0K5weL44Aqa8xgYdR2BhjARfEZLeLmpt7W4= MIME-Version: 1.0 Received: by 10.223.127.4 with SMTP id e4mr2543411fas.100.1238258525185; Sat, 28 Mar 2009 09:42:05 -0700 (PDT) In-Reply-To: <20090328102735.GE99923@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> Date: Sat, 28 Mar 2009 18:42:05 +0200 Message-ID: <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> From: Niki Denev To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 16:42:07 -0000 On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: > On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: >> 2009/3/28 Pyun YongHyeon : >> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> Hello, >> >> >> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) >> >> problems. >> >> Basically the network connection works but when some more serious >> >> traffic hits the >> >> interface (i.e. torrent download) it then dies, ifconfig down/up >> >> does not help, only replugging of the adapter. >> >> >> >> I've tried running with hw.usb2.axe.debug=15 and the output was many >> >> lines of: >> >> >> >> ? ?axe_bulk_write_callback:853: transfer complete >> >> >> >> then a pause of several seconds and the kernel begins to print : >> >> >> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT >> >> >> >> Another strange thing that I noticed is that, while the interface >> >> seems to be >> >> connected and working, if I type many times ifconfig ue0 consecutively >> >> most of the time it would show different settings for the auto >> >> negotiated link. >> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, >> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. >> >> >> >> The switch does not seem to register link flaps. >> >> >> > >> > axe(4) requires exact link state/speed information from mii(4) to >> > reprogram controller to resolved speed/duplex. In this case >> > ukphy(4) seems to report fake link state/speed to axe(4). >> > >> >> The kernel messages for the interface are : >> >> >> >> ? ?ugen2.5: at usbus2 >> >> ? ?axe0: on usbus2 >> >> ? ?axe0: PHYADDR 0xe0:0x01 >> >> ? ?miibus0: on axe0 >> >> ? ?ukphy0: PHY 1 on miibus0 >> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> >> 1000baseT, 1000baseT-FDX, auto >> >> ? ?ue0: on axe0 >> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx >> >> >> >> devinfo -vr | grep phy >> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 >> >> >> > >> > This looks like Agere systems ET110C TruePHY. Would you try >> > attached patch? Because truephy(4) pokes some undocumented PHY >> > registers on PHY reset I'm not sure this model also requires that >> > magic to make it work though. >> > >> >> Hi Pyun, >> >> Thanks for the patch. >> >> With it the PHY is now detected as truephy. >> The only thing that i notice is that if the media status changes displayed with >> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX >> The packet loss is still there, and the interface again stops to work >> after some time. >> > > Ok, revert previous patch and try attached one. This one does not > try to load ET1011C dsp codes. If this does not work next thing > would be try to load dsp code for ET1011C revision 1 model. > Not sure where I can find required dsp code. > There don't seem to be any improvement with the new patch. The packetloss and media status changes are still here. Maybe check Linux/Solaris/OtherBSD driver? -- Niki From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 15:33:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00001065680 for ; Sat, 28 Mar 2009 15:33:41 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id D25878FC17 for ; Sat, 28 Mar 2009 15:33:41 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: by wf-out-1314.google.com with SMTP id 24so1620317wfg.7 for ; Sat, 28 Mar 2009 08:33:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.171.3 with SMTP id t3mr1367245wfe.195.1238254421568; Sat, 28 Mar 2009 08:33:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Mar 2009 23:33:41 +0800 Message-ID: From: Mars G Miro To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 28 Mar 2009 16:42:50 +0000 Subject: Re: booting from SATA DVD-RAM, no go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:33:42 -0000 On Sat, Mar 28, 2009 at 9:21 PM, Mars G Miro wrote= : > Hi guys > > =A0 It just does: > ... > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > Relocating the loader and the BTX > ... > > =A0Then the screen goes blank. I've tried setting AHCI and unsetting it > (IDE mode), still no go. Tried the 7-STABLE / 8-CURRENT (amd64) > snapshots from February. > > =A0This is on an LG GH22LS40 on a Gigabyte MA78GM-S2H mobo w/ the latest > BIOS from their website. > > =A0Clues? I'll prolly plug an old CD-ROM just to install FreeBSD on it. T= hanks. > rrrrrrrrrr. plugging in an old CD-ROM still gives me the same thing. Next stop: PXE, or just install FreeBSD on the HD in a separate machine altogether ... > > -- > cheers > mars > ----- > P. J. O'Rourke =A0- "If government were a product, selling it would be il= legal." > --=20 cheers mars ----- Mercedes McCambridge - "I'd never been in play long enough for the flowers to die in the dressing room." From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 17:09:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA1E106566B for ; Sat, 28 Mar 2009 17:09:12 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFD98FC1E for ; Sat, 28 Mar 2009 17:09:10 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 16927 invoked by uid 1002); 28 Mar 2009 17:09:08 -0000 Received: from unknown (HELO ?10.10.10.9?) (saifi.khan@twincling.org@59.92.174.200) by s217.sureserver.com with ESMTPA; 28 Mar 2009 17:09:08 -0000 Date: Sat, 28 Mar 2009 22:42:41 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: freebsd-current@freebsd.org, FreeBSD Questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: Too many active children of 'whole' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:09:12 -0000 Hi: Using FreeBSD 8.x snapshot 200902, On a 160GB SATA HDD, i tried creating a 25GB slice and then selected 'install a standard MBR (no boot manager)', the installer gave a warning as: "Disk Slicing warning: Too many active children of 'whole'" What exactly does this mean ? thanks Saifi. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 17:12:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B96B1065715 for ; Sat, 28 Mar 2009 17:12:28 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 6597B8FC17 for ; Sat, 28 Mar 2009 17:12:28 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Lnc55-000176-Ee for freebsd-current@freebsd.org; Sat, 28 Mar 2009 10:12:27 -0700 Message-ID: <22759116.post@talk.nabble.com> Date: Sat, 28 Mar 2009 10:12:27 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <511792.14022.qm@web63903.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <511792.14022.qm@web63903.mail.re1.yahoo.com> Subject: Re: ACPI error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:12:30 -0000 Barney Cordoba wrote: > > > I'm getting an APIC error: > > kernel: ACPI Error (tbxfroot-0308): A valid RSDP was not found [20070320] > kernel: ACPI: Table initialisation failed: AE_NOT_FOUND > kernel: ACPI: Try disabling either ACPI or apic support. > > Is there any hope for this? Unfortunately with ACPI off, the Hard Drive > is found at ad6 where its found at ad8 on 7, so upgrading on this box > will be more painful than usual. > > Its a relatively new (intel bigby) chipset. > > Barney > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > There are experimental acpica patches thanks to jkim. http://people.freebsd.org/~jkim/ -- View this message in context: http://www.nabble.com/ACPI-error-tp22756817p22759116.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 17:21:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D471065674 for ; Sat, 28 Mar 2009 17:21:11 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5AC8FC15 for ; Sat, 28 Mar 2009 17:21:11 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1040069qwb.7 for ; Sat, 28 Mar 2009 10:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=kYQPuupJMQ/dfFO5IuuEvfEk6Ku4leII+pgwHnkOsLw=; b=R+6X5+66Neh7a9R50+ULv43oo6n7Mv0Dk9raFgrhGFuIGZ3lQutC1eMUbqmCbwNy7i 4Mml9sDnKlX5n0unhfmsVS4A/NvRZCFeAoIQAUWeQSDGRDy+3BZvRIgqsDoT5vraK6QI 2R+huoeMXNFVf4dyhBdqGcjq1wR31b5N0sbqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=X0m0G76cCWJkqQx6GtaPbyqyolGn8ILY7uKeO3QO1tD2kgY/DWpQyRivO35Go1QOA+ 1BhagP3rhhco5mB568tmcmi1haARvrW2j8QgsSkcVGQepPL+muVppV27LSUW8IN8A7Ns 3YJ+9ANJdkJtsVqmJFkA67NP13K1y5g89dM2s= Received: by 10.224.46.16 with SMTP id h16mr2116773qaf.179.1238260870628; Sat, 28 Mar 2009 10:21:10 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.18.191]) by mx.google.com with ESMTPS id 6sm3138414yxg.0.2009.03.28.10.21.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 10:21:10 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 5A412B8074; Sat, 28 Mar 2009 14:21:04 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Sat, 28 Mar 2009 14:21:04 -0300 (BRT) Message-ID: <4017c490bd7e22b10413da2ef8f66dc6.squirrel@10.1.1.10> In-Reply-To: <4752992355368de13c4fad50f47c10ca.squirrel@10.1.1.10> References: <4752992355368de13c4fad50f47c10ca.squirrel@10.1.1.10> Date: Sat, 28 Mar 2009 14:21:04 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: why booting from install media (8.0-200902) my usb disk is seen, and after installed it's not ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:21:12 -0000 On Sat, March 28, 2009 11:54, Nenhum_de_Nos wrote: > is there a way I can reproduce boot cd enviroment ? > > I've already copied all I can think would matter from install media and no > luck :( small correction, it is just seen as far as boot is concerned, when sysintall is up it is not (although when pressing ALT+F2 there is a da0 all ok). I tried set kern.cam.scsi_delay=10000 as told, not luck (just detects both cdrom and hd all from usb) 7.1R does behave as subject line. thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 18:59:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968E1106564A for ; Sat, 28 Mar 2009 18:59:59 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 514158FC1F for ; Sat, 28 Mar 2009 18:59:59 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.151.104] (port=52176 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lndl7-000Ovl-Lp; Sat, 28 Mar 2009 21:59:57 +0300 Message-ID: <49CE73BE.606@lissyara.su> Date: Sat, 28 Mar 2009 22:00:14 +0300 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Hans Petter Selasky References: <49C7FE13.90808@lissyara.su> <200903281639.55044.hselasky@c2i.net> <49CE44BB.8000001@lissyara.su> <200903281654.47735.hselasky@c2i.net> In-Reply-To: <200903281654.47735.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: New USB stack and USB floppy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 18:59:59 -0000 Hans Petter Selasky пишет: > On Saturday 28 March 2009, Alex Keda wrote: >> Hans Petter Selasky пишет: >>> On Saturday 28 March 2009, Alex Keda wrote: >>>> Mar 28 18:23:45 HP kernel: pid 5873 (hald-probe-usb2-dev), uid 0: exited >>>> on signal 11 (core dumped) >>> Looks like a problem in hald. Could you debug that? >> What I can do? > > Run gdb on the core dump. I delete this dump (I have tmpfs and reboot after it) and cannot reproduce dump... From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 20:03:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7235106566B; Sat, 28 Mar 2009 20:03:57 +0000 (UTC) (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 967B88FC17; Sat, 28 Mar 2009 20:03:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2SK3tLF057935; Sat, 28 Mar 2009 16:03:55 -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.14.3/8.14.3) with ESMTP id n2SK3t2M037470; Sat, 28 Mar 2009 16:03:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 19ADB7302F; Sat, 28 Mar 2009 15:03:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090328200355.19ADB7302F@freebsd-current.sentex.ca> Date: Sat, 28 Mar 2009 15:03:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 20:03:58 -0000 TB --- 2009-03-28 18:36:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-28 18:36:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-03-28 18:36:38 - cleaning the object tree TB --- 2009-03-28 18:37:06 - cvsupping the source tree TB --- 2009-03-28 18:37:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-03-28 18:37:17 - building world TB --- 2009-03-28 18:37:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 18:37:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 18:37:17 - TARGET=pc98 TB --- 2009-03-28 18:37:17 - TARGET_ARCH=i386 TB --- 2009-03-28 18:37:17 - TZ=UTC TB --- 2009-03-28 18:37:17 - __MAKE_CONF=/dev/null TB --- 2009-03-28 18:37:17 - cd /src TB --- 2009-03-28 18:37:17 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 28 18:37:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 28 20:01:14 UTC 2009 TB --- 2009-03-28 20:01:14 - generating LINT kernel config TB --- 2009-03-28 20:01:14 - cd /src/sys/pc98/conf TB --- 2009-03-28 20:01:14 - /usr/bin/make -B LINT TB --- 2009-03-28 20:01:14 - building LINT kernel TB --- 2009-03-28 20:01:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 20:01:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 20:01:14 - TARGET=pc98 TB --- 2009-03-28 20:01:14 - TARGET_ARCH=i386 TB --- 2009-03-28 20:01:14 - TZ=UTC TB --- 2009-03-28 20:01:14 - __MAKE_CONF=/dev/null TB --- 2009-03-28 20:01:14 - cd /src TB --- 2009-03-28 20:01:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 28 20:01:14 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] i386 -> /src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -DPC98 -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/pc98/src/sys/LINT /src/sys/modules/geom/geom_uzip/../../../geom/uzip/g_uzip.c ===> geom/geom_vinum (depend) @ -> /src/sys machine -> /src/sys/pc98/include i386 -> /src/sys/i386/include make: don't know how to make geom_vinum_create.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-28 20:03:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-28 20:03:54 - ERROR: failed to build lint kernel TB --- 2009-03-28 20:03:54 - 3999.70 user 416.52 system 5236.57 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 20:19:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B3F4106566B for ; Sat, 28 Mar 2009 20:19:19 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id B0C2C8FC12 for ; Sat, 28 Mar 2009 20:19:18 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by fxm11 with SMTP id 11so1380517fxm.43 for ; Sat, 28 Mar 2009 13:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0r3/w7KqbtdTts11PkUjFboq7PTAndVCipAR0C7dewY=; b=TFNw7FWPSn52RmRxremx9wzohNVXW09nRKJKpkFAGIlmIT+5GLYc2JJGKkJ/I5crWb mcILLioewQPJco+f6WIE+s1ctOHzCfOOl+z8ZWv3Aorkx/aBlqL0DG72pPtAM770zKyV OCdRpOp3HKxiMfts6hgE5VMIq0SzPfxbuMZlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PJrL2JwWGkFcsDUdwUSV1MbB9RWN7OaXVRQP0C3WqR8ajQhVDYmG7iV0tb4Sn3w6/0 xJarx6eBmd2NAzVojx9Y6SPou1cAFsF5UrF3e2a97oLFuUUWuCuiGkvOdPApADauina5 cJ4J0FOc976+5vGbBSVAOu9JzOlW0FeZybxgI= MIME-Version: 1.0 Received: by 10.204.118.66 with SMTP id u2mr1229624bkq.132.1238271557671; Sat, 28 Mar 2009 13:19:17 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Mar 2009 16:19:17 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Mars G Miro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: booting from SATA DVD-RAM, no go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 20:19:19 -0000 On Sat, Mar 28, 2009 at 11:33 AM, Mars G Miro wrote: > On Sat, Mar 28, 2009 at 9:21 PM, Mars G Miro > wrote: > > ... > > > > > > This is on an LG GH22LS40 on a Gigabyte MA78GM-S2H mobo w/ the latest > > BIOS from their website. > > > > > If you study the page about the main board MA78GM-S2H http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=2926 please notice Remark part and Operating System part . Some main boards may contain circuitry that it is NOT supported by FreeBSD . In other words , it may not be possible to install Unix type operating systems produced for ONLY Windows unless operating system sources are re-designed for unsupported ( special ) chip(s) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 20:27:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9210D106564A for ; Sat, 28 Mar 2009 20:27:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCC28FC1B for ; Sat, 28 Mar 2009 20:27:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BE5B446B06; Sat, 28 Mar 2009 16:27:19 -0400 (EDT) Date: Sat, 28 Mar 2009 20:27:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dimitry Andric In-Reply-To: <49CE373C.2050908@andric.com> Message-ID: References: <20090328134641.GA32589@sh4-5.1blu.de> <49CE373C.2050908@andric.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: missing lkm if_ppp in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 20:27:20 -0000 On Sat, 28 Mar 2009, Dimitry Andric wrote: > On 2009-03-28 14:46, Matthias Apitz wrote: >> What is the correct way to get the module if_ppp build during "make >> buildkernel KERNCONF=GENERIC"? > > The build of ppp has been disabled, as per Robert Watson's announcement on > 2009-02-16: > > http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0902161233440.5806 > > and this followup, on 2009-03-15: > > http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0903151002310.92013 While my changes would have disabled it, it was actually already disabled from when the new tty framework went in. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 21:10:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FF371065670; Sat, 28 Mar 2009 21:10:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 206C78FC14; Sat, 28 Mar 2009 21:10:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2SLAosb022738; Sat, 28 Mar 2009 17:10:50 -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.14.3/8.14.3) with ESMTP id n2SLAoaO018219; Sat, 28 Mar 2009 17:10:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3630D7302F; Sat, 28 Mar 2009 16:10:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090328211050.3630D7302F@freebsd-current.sentex.ca> Date: Sat, 28 Mar 2009 16:10:50 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 21:10:54 -0000 TB --- 2009-03-28 19:17:23 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-28 19:17:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-03-28 19:17:23 - cleaning the object tree TB --- 2009-03-28 19:18:21 - cvsupping the source tree TB --- 2009-03-28 19:18:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-03-28 19:18:28 - building world TB --- 2009-03-28 19:18:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 19:18:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 19:18:28 - TARGET=ia64 TB --- 2009-03-28 19:18:28 - TARGET_ARCH=ia64 TB --- 2009-03-28 19:18:28 - TZ=UTC TB --- 2009-03-28 19:18:28 - __MAKE_CONF=/dev/null TB --- 2009-03-28 19:18:28 - cd /src TB --- 2009-03-28 19:18:28 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 28 19:18:30 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 28 21:08:24 UTC 2009 TB --- 2009-03-28 21:08:24 - generating LINT kernel config TB --- 2009-03-28 21:08:24 - cd /src/sys/ia64/conf TB --- 2009-03-28 21:08:24 - /usr/bin/make -B LINT TB --- 2009-03-28 21:08:24 - building LINT kernel TB --- 2009-03-28 21:08:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 21:08:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 21:08:24 - TARGET=ia64 TB --- 2009-03-28 21:08:24 - TARGET_ARCH=ia64 TB --- 2009-03-28 21:08:24 - TZ=UTC TB --- 2009-03-28 21:08:24 - __MAKE_CONF=/dev/null TB --- 2009-03-28 21:08:24 - cd /src TB --- 2009-03-28 21:08:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 28 21:08:25 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] @ -> /src/sys machine -> /src/sys/ia64/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/ia64/src/sys/LINT /src/sys/modules/geom/geom_uzip/../../../geom/uzip/g_uzip.c ===> geom/geom_vinum (depend) @ -> /src/sys machine -> /src/sys/ia64/include make: don't know how to make geom_vinum_create.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-28 21:10:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-28 21:10:49 - ERROR: failed to build lint kernel TB --- 2009-03-28 21:10:49 - 5465.50 user 419.22 system 6806.42 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 22:27:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A36106564A for ; Sat, 28 Mar 2009 22:27:28 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9F4D18FC16 for ; Sat, 28 Mar 2009 22:27:27 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 28 Mar 2009 22:27:24 -0000 Received: from p548656C5.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.86.197] by mail.gmx.net (mp058) with SMTP; 28 Mar 2009 23:27:24 +0100 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX1/iLzIdmyHiz+KJd6yQMK5NPy0xU9WRtab8Oq2PTU sbsnXf2RK/Mezs Message-ID: <49CEA474.9020302@gmx.net> Date: Sat, 28 Mar 2009 23:28:04 +0100 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Sam Leffler References: <49C83038.40300@gmx.net> <49CAC1C0.9030506@freebsd.org> In-Reply-To: <49CAC1C0.9030506@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 22:27:28 -0000 Hi Sam, I ran tests with both a CURRENT from March 26 + (the manually updated) wpa_supplicant 0.6.9 and an older CURRENT from March 1 2000h + wpa_supplicant 0.5.11. I included the logs below. Unfortunately, in both cases I get the "WPA: Failed to set PTK to the driver" error and the wireless adapter stops working. FreeBSD: CURRENT from March 26 (manually updated wpa_supplicant) wpa_supplicant 0.6.9 (running with wpa_supplicant_flags="-sd") wlandebug crypto Via dmesg: ----8<---------------------------------------------------------- wlan0: link state changed to UP ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x4), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x4), reseting wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 4 wlan0: ieee80211_crypto_newkey: unable to setup cipher AES-CCM wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 1 wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 ath0: bb hang detected (0x4), reseting ath0: bb hang detected (0x4), reseting ----8<---------------------------------------------------------- From /var/log/messages: ----8<---------------------------------------------------------- Mar 27 13:28:55 impala kernel: wlan0: Ethernet address: 00:21:91:db:15:30 Mar 27 13:28:55 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:28:55 impala wpa_supplicant[426]: Trying to associate with 00:1b:2f:ef:d3:c9 (SSID='IDA' freq=2472 MHz) Mar 27 13:28:55 impala kernel: wlan0: link state changed to UP Mar 27 13:28:55 impala wpa_supplicant[426]: Associated with 00:1b:2f:ef:d3:c9 Mar 27 13:28:55 impala wpa_supplicant[426]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 27 13:28:55 impala wpa_supplicant[426]: TLS: Unsupported Phase2 EAP method 'MSCHAPv2' Mar 27 13:28:55 impala wpa_supplicant[426]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 27 13:28:55 impala wpa_supplicant[426]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 27 13:28:55 impala wpa_supplicant[426]: EAP-MSCHAPV2: Authentication succeeded Mar 27 13:28:55 impala wpa_supplicant[426]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 27 13:28:55 impala wpa_supplicant[426]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 27 13:28:55 impala wpa_supplicant[426]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] Mar 27 13:28:55 impala wpa_supplicant[426]: CTRL-EVENT-CONNECTED - Connection to 00:1b:2f:ef:d3:c9 completed (auth) [id=3 id_str=] Mar 27 13:29:01 impala dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 13:29:01 impala dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 13:29:01 impala dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 13:29:01 impala dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 13:32:43 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 13:33:57 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:34:50 impala kernel: ath0: bb hang detected (0x4), reseting Mar 27 13:38:59 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:39:20 impala su: dthiele to root on /dev/pts/3 Mar 27 13:39:38 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 13:44:03 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:44:28 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 13:49:06 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:49:29 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 13:54:08 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:54:27 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 13:59:11 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 13:59:33 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 14:04:13 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:09:15 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:09:27 impala kernel: ath0: bb hang detected (0x80), reseting Mar 27 14:14:17 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:16:32 impala kernel: ath0: bb hang detected (0x4), reseting Mar 27 14:19:19 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:24:21 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:28:59 impala wpa_supplicant[426]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 27 14:28:59 impala wpa_supplicant[426]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 27 14:29:00 impala wpa_supplicant[426]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 27 14:29:00 impala wpa_supplicant[426]: EAP-MSCHAPV2: Authentication succeeded Mar 27 14:29:00 impala wpa_supplicant[426]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 27 14:29:00 impala wpa_supplicant[426]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 27 14:29:01 impala kernel: wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 4 Mar 27 14:29:01 impala kernel: Mar 27 14:29:01 impala kernel: wlan0: ieee80211_crypto_newkey: unable to setup cipher AES-CCM Mar 27 14:29:01 impala kernel: Mar 27 14:29:01 impala kernel: wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 1 Mar 27 14:29:01 impala kernel: wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 Mar 27 14:29:01 impala wpa_supplicant[426]: WPA: Failed to set PTK to the driver. Mar 27 14:29:01 impala wpa_supplicant[426]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP] Mar 27 14:29:23 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:34:26 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:39:28 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:49:32 impala last message repeated 2 times Mar 27 14:54:34 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 14:55:10 impala kernel: ath0: bb hang detected (0x4), reseting Mar 27 14:59:36 impala wpa_supplicant[426]: CTRL-EVENT-SCAN-RESULTS Mar 27 15:00:30 impala kernel: ath0: bb hang detected (0x4), reseting ----8<---------------------------------------------------------- FreeBSD: CURRENT from March 1 (2000h) wpa_supplicant 0.5.11 (running with wpa_supplicant_flags="-sd") wlandebug crypto (This is the same hardware as above. I just changed the hostname) Via dmesg: ----8<---------------------------------------------------------- wlan0: Ethernet address: 00:21:91:db:15:30 wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: Ethernet address: 00:21:91:db:15:30 wlan0: Ethernet address: 00:21:91:db:15:30 wlan0: link state changed to UP wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: TKIP keyix 1 flags 0x106 rsc 1096785 tsc 1 len 16 wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 4 flags 0x103 rsc 28882 tsc 19125 len 16 wlan0: link state changed to DOWN wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wlan0: link state changed to UP wlan0: [00:1b:2f:ef:d3:b9] key id 1 is not set (decap) wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 65535 wlan0: ieee80211_crypto_setkey: AES-CCM keyix 4 flags 0x103 mac 00:1b:2f:ef:d3:b9 rsc 0 tsc 0 len 16 wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 1 wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 wlan0: [00:1b:2f:ef:d3:b9] AES-CCM replay detected ath0: bb hang detected (0x80), reseting wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 4 wlan0: ieee80211_crypto_newkey: unable to setup cipher AES-CCM wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 1 wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80), reseting ----8<---------------------------------------------------------- From /var/log/messages: ----8<---------------------------------------------------------- Mar 27 15:22:32 edward kernel: wlan0: Ethernet address: 00:21:91:db:15:30 Mar 27 15:22:35 edward wpa_supplicant[2815]: Trying to associate with 00:1b:2f:ef:d3:b9 (SSID='IDA' freq=2442 MHz) Mar 27 15:22:35 edward kernel: wlan0: link state changed to UP Mar 27 15:22:35 edward wpa_supplicant[2815]: Associated with 00:1b:2f:ef:d3:b9 Mar 27 15:22:35 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 27 15:22:35 edward wpa_supplicant[2815]: EAP-PEAP: Unsupported Phase2 method 'MSCHAPv2' Mar 27 15:22:35 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 27 15:22:35 edward wpa_supplicant[2815]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 27 15:22:35 edward wpa_supplicant[2815]: EAP-MSCHAPV2: Authentication succeeded Mar 27 15:22:35 edward wpa_supplicant[2815]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 27 15:22:35 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 27 15:22:35 edward wpa_supplicant[2815]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:b9 [PTK=CCMP GTK=TKIP] Mar 27 15:22:35 edward wpa_supplicant[2815]: CTRL-EVENT-CONNECTED - Connection to 00:1b:2f:ef:d3:b9 completed (auth) [id=3 id_str=] Mar 27 15:22:46 edward dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 15:22:46 edward dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 15:22:46 edward dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 15:22:46 edward dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 15:22:51 edward dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 15:22:51 edward dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 15:22:51 edward dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 15:22:51 edward dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 16:14:58 edward kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 en 0 Mar 27 16:14:58 edward kernel: wlan0: _ieee80211_crypto_delkey: TKIP keyix 1 flags0x106 rsc 1096785 tc 1 len 16 Mar 27 16:14:58 edward kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 lags 0x3 rsc 0 tc 0 len 0 Mar 27 16:14:58 edward kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tc 0 len 0 Mar 27 16:14:58 edward wpa_supplicant[2815]: Trying to associate with 00:1e:2a:f9:0a:64 (SSID='IDA' freq=2472 MHz) Mar 27 16:14:58 edward kernel: wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 4 flags 0x103 rsc 28882 tsc 19125 len16 Mar 27 16:14:58 edward kernel: wlan0: link state changed to DOWN Mar 27 16:14:59 edward kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Mar 27 16:14:59 edward last message repeated 3 times Mar 27 16:14:58 edward wpa_supplicant[2815]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Mar 27 16:15:09 edward wpa_supplicant[2815]: Authentication with 00:00:00:00:00:00 timed out. Mar 27 16:15:21 edward wpa_supplicant[2815]: Authentication with 00:1e:2a:f9:0a:64 timed out. Mar 27 16:15:21 edward wpa_supplicant[2815]: Trying to associate with 00:1b:2f:ef:d3:b9 (SSID='IDA' freq=2442 MHz) Mar 27 16:15:21 edward kernel: wlan0: link state changed to UP Mar 27 16:15:21 edward wpa_supplicant[2815]: Associated with 00:1b:2f:ef:d3:b9 Mar 27 16:15:21 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 27 16:15:21 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 27 16:15:22 edward kernel: wlan0: [00:1b:2f:ef:d3:b9] key id 1 is not set (decap) Mar 27 16:15:22 edward wpa_supplicant[2815]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 27 16:15:22 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 27 16:15:22 edward kernel: wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 65535 Mar 27 16:15:22 edward kernel: wlan0: ieee80211_crypto_setkey: AES-CCM keyix 4 flags 0x103 mac 00:1b:2f:ef:d3:b9 rsc 0 tsc 0 len 16 Mar 27 16:15:23 edward kernel: wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 1 Mar 27 16:15:23 edward kernel: wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 Mar 27 16:15:22 edward wpa_supplicant[2815]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:b9 [PTK=CCMP GTK=TKIP] Mar 27 16:15:22 edward wpa_supplicant[2815]: CTRL-EVENT-CONNECTED - Connection to 00:1b:2f:ef:d3:b9 completed (reauth) [id=3 id_str=] Mar 27 16:15:23 edward kernel: wlan0: [00:1b:2f:ef:d3:b9] AES-CCM replay detected Mar 27 16:15:24 edward dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 16:15:24 edward dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 16:15:24 edward dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 16:15:24 edward dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 16:15:24 edward dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 16:15:24 edward dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 16:15:24 edward dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 16:15:24 edward dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 17:00:09 edward dhclient[3024]: connection closed Mar 27 17:00:09 edward dhclient[3024]: exiting. Mar 27 17:01:00 edward dhclient: New IP Address (wlan0): 192.168.100.54 Mar 27 17:01:00 edward dhclient: New Subnet Mask (wlan0): 255.255.255.0 Mar 27 17:01:00 edward dhclient: New Broadcast Address (wlan0): 192.168.100.255 Mar 27 17:01:00 edward dhclient: New Routers (wlan0): 192.168.100.1 Mar 27 17:09:38 edward kernel: ath0: bb hang detected (0x80), reseting Mar 27 17:15:22 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-STARTED EAP authentication started Mar 27 17:15:22 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Mar 27 17:15:23 edward wpa_supplicant[2815]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Mar 27 17:15:23 edward wpa_supplicant[2815]: EAP-MSCHAPV2: Authentication succeeded Mar 27 17:15:23 edward wpa_supplicant[2815]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Mar 27 17:15:23 edward wpa_supplicant[2815]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Mar 27 17:15:23 edward kernel: wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix Mar 27 17:15:23 edward kernel: Mar 27 17:15:23 edward kernel: wlan0: ieee80211_crypto_newkey: unable to setup cipher AES-CCM Mar 27 17:15:23 edward wpa_supplicant[2815]: WPA: Failed to set PTK to the driver. Mar 27 17:15:23 edward kernel: wlan0: ieee80211_crypto_newkey: cipher flags 0x6 keyix Mar 27 17:15:23 edward kernel: 1 Mar 27 17:15:23 edward kernel: wlan0: ieee80211_crypto_setkey: TKIP keyix 1 flags 0x106 mac ff:ff:ff:ff:ff:ff rsc 0 tsc 0 len 16 Mar 27 17:15:23 edward wpa_supplicant[2815]: WPA: Key negotiation completed with 00:1b:2f:ef:d3:b9 [PTK=CCMP GTK=TKIP] Mar 27 17:16:05 edward kernel: ath0: bb hang detected (0x80), reseting Mar 27 17:18:57 edward kernel: ath0: bb hang detected (0x80), reseting ----8<---------------------------------------------------------- Is there a way to get further information out of wpa_supplicant? Maybe by manually adding some extra logging? Or is it now time to start looking into the related drivers and infrastructure, too? IIRC I did not have this problem on a 7.1-STABLE + wpa_supplicant 0.5.10 and I still have that notebook. Unfortunately I can only use the built-in ipw and an external rum adapter on that machine. Maybe I could use that notebook to get some relevant information, too? Alternatively I could install a 7-STABLE on my current notebook to have access to the ath card, if that would help. Regards, Daniel From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 22:35:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46CBF106566B for ; Sat, 28 Mar 2009 22:35:12 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id C4F838FC18 for ; Sat, 28 Mar 2009 22:35:11 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 30072 invoked by uid 60001); 28 Mar 2009 22:35:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238279709; bh=kkyBn+1JL38hwcfnk0B+RN31RdKXX4LUBzmOnQMH31U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=D7qHW2YTV9hSuGzgI3XLfizqBk3+2Fu/6cg7vmW+l49gFx15fJRnnqehyZiuCzX0v10C2Fvb6J8e95wcGu6nk5NBPkvgej+FPEpcberBu9G0kCoS2ngSnbigZBJx60ng6Q8vtsqx6KGCtZtAsYRQb+80jTrQFivNd2BlzQY9k/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YcD/LVigmucVq+sxoz9D86ImY+ijPqXw3PLIBYx7btu5jqnIKDM30SCke4HwTjjklF19FoGpMYAg9P4qCilSAQJnjqc7x0owAyntagecgWcGtT3hYv9fsw9aBpqa6TkkmaOrCZ0xfAQV/kpODqp7w5bAcNXff2B4u/icVJCunK0=; Message-ID: <848052.92716.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: R3dYQyIVM1nvQCQsA.LNAe7xwWNWouighiIZJ5uMC2ZRPGY4TQsG1qcLAY8qoUNzOTeBCso0Br9u0bMUw9Rl9UAnTZLT7mG4rcjuhq2k2uc3o4Rf9cWJp67jm2h0YD0rq7UmeV6HO4pKOccrbtWv2e7Ltx9b2gKJdYFE3P6pg.UQNu40_SZYA3icoPTXqGA5tmJ3I3iSqgYp_eE- Received: from [98.242.222.229] by web63907.mail.re1.yahoo.com via HTTP; Sat, 28 Mar 2009 15:35:02 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sat, 28 Mar 2009 15:35:02 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Bus Resource busy panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 22:35:12 -0000 I have a situation that results in a panic in 8 that runs happily in 7. Its a bus_alloc_resource of type SYS_RES_MEMORY that is used by 2 separate devices. I see there is an RF_SHAREABLE flag. That flag hadn't been set, but is there something in 8 that now requires it? As a side question, should a bus_alloc_resource call panic the system just because the resource is busy? Barney From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 22:35:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AC8106566C; Sat, 28 Mar 2009 22:35:48 +0000 (UTC) (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 7F1738FC1D; Sat, 28 Mar 2009 22:35:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n2SMZkcS064276; Sat, 28 Mar 2009 18:35:46 -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.14.3/8.14.3) with ESMTP id n2SMZk7C002392; Sat, 28 Mar 2009 18:35:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2FA4C7302F; Sat, 28 Mar 2009 17:35:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090328223546.2FA4C7302F@freebsd-current.sentex.ca> Date: Sat, 28 Mar 2009 17:35:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 22:35:49 -0000 TB --- 2009-03-28 21:11:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-28 21:11:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-03-28 21:11:07 - cleaning the object tree TB --- 2009-03-28 21:11:50 - cvsupping the source tree TB --- 2009-03-28 21:11:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-03-28 21:11:58 - building world TB --- 2009-03-28 21:11:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 21:11:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 21:11:58 - TARGET=sparc64 TB --- 2009-03-28 21:11:58 - TARGET_ARCH=sparc64 TB --- 2009-03-28 21:11:58 - TZ=UTC TB --- 2009-03-28 21:11:58 - __MAKE_CONF=/dev/null TB --- 2009-03-28 21:11:58 - cd /src TB --- 2009-03-28 21:11:58 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 28 21:12:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 28 22:33:21 UTC 2009 TB --- 2009-03-28 22:33:21 - generating LINT kernel config TB --- 2009-03-28 22:33:21 - cd /src/sys/sparc64/conf TB --- 2009-03-28 22:33:21 - /usr/bin/make -B LINT TB --- 2009-03-28 22:33:21 - building LINT kernel TB --- 2009-03-28 22:33:21 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 22:33:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 22:33:21 - TARGET=sparc64 TB --- 2009-03-28 22:33:21 - TARGET_ARCH=sparc64 TB --- 2009-03-28 22:33:21 - TZ=UTC TB --- 2009-03-28 22:33:21 - __MAKE_CONF=/dev/null TB --- 2009-03-28 22:33:21 - cd /src TB --- 2009-03-28 22:33:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 28 22:33:21 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] @ -> /src/sys machine -> /src/sys/sparc64/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sparc64/src/sys/LINT /src/sys/modules/geom/geom_uzip/../../../geom/uzip/g_uzip.c ===> geom/geom_vinum (depend) @ -> /src/sys machine -> /src/sys/sparc64/include make: don't know how to make geom_vinum_create.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-28 22:35:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-28 22:35:46 - ERROR: failed to build lint kernel TB --- 2009-03-28 22:35:46 - 3919.25 user 396.90 system 5079.17 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 22:39:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A28C106566C for ; Sat, 28 Mar 2009 22:39:24 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id EA9008FC08 for ; Sat, 28 Mar 2009 22:39:23 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by bwz8 with SMTP id 8so1381712bwz.43 for ; Sat, 28 Mar 2009 15:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EZ+LWj10QcJ122WRBtyQqJ9flOcDRFEsKEtlGDSkcYI=; b=FvoFFZrNcY5WGKKsXgkSu+fTSALk3+KcUbNroJp+Hv9Og0Xvoc1YE2hSF5HQqFiO/d PdyFeSB370fWSaqXfTK0VMup40KpGErYrlY45/wj65wpHTKyh5ZFjGCy8RQIkxLWBUFq J3QLMCeL20+E87U1dmbKtbLsNz7caM5wKV49U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WSZ5mo6xVWyJPPag4hRGR9heV41f/XOPGXjdxphwYayt//XQeS9rc/t5gfLX5FBOG/ qbQoi8quh7W2QFyxwKD3Mrj8r/WM4ApQk8J6z1S17TuwBG2Sh0hO/+tJLEZEQBKNchF9 iarizhpAmstOE/UP4H8u4/RxXIay6bWXtNAoQ= MIME-Version: 1.0 Received: by 10.223.105.75 with SMTP id s11mr2811016fao.4.1238279962744; Sat, 28 Mar 2009 15:39:22 -0700 (PDT) In-Reply-To: <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> Date: Sun, 29 Mar 2009 00:39:22 +0200 Message-ID: <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> From: Niki Denev To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 22:39:24 -0000 On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev wrote: > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: >>> 2009/3/28 Pyun YongHyeon : >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: >>> >> -----BEGIN PGP SIGNED MESSAGE----- >>> >> Hash: SHA1 >>> >> >>> >> Hello, >>> >> >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) >>> >> problems. >>> >> Basically the network connection works but when some more serious >>> >> traffic hits the >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up >>> >> does not help, only replugging of the adapter. >>> >> >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many >>> >> lines of: >>> >> >>> >> ? ?axe_bulk_write_callback:853: transfer complete >>> >> >>> >> then a pause of several seconds and the kernel begins to print : >>> >> >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT >>> >> >>> >> Another strange thing that I noticed is that, while the interface >>> >> seems to be >>> >> connected and working, if I type many times ifconfig ue0 consecutively >>> >> most of the time it would show different settings for the auto >>> >> negotiated link. >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. >>> >> >>> >> The switch does not seem to register link flaps. >>> >> >>> > >>> > axe(4) requires exact link state/speed information from mii(4) to >>> > reprogram controller to resolved speed/duplex. In this case >>> > ukphy(4) seems to report fake link state/speed to axe(4). >>> > >>> >> The kernel messages for the interface are : >>> >> >>> >> ? ?ugen2.5: at usbus2 >>> >> ? ?axe0: on usbus2 >>> >> ? ?axe0: PHYADDR 0xe0:0x01 >>> >> ? ?miibus0: on axe0 >>> >> ? ?ukphy0: PHY 1 on miibus0 >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >>> >> 1000baseT, 1000baseT-FDX, auto >>> >> ? ?ue0: on axe0 >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx >>> >> >>> >> devinfo -vr | grep phy >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 >>> >> >>> > >>> > This looks like Agere systems ET110C TruePHY. Would you try >>> > attached patch? Because truephy(4) pokes some undocumented PHY >>> > registers on PHY reset I'm not sure this model also requires that >>> > magic to make it work though. >>> > >>> >>> Hi Pyun, >>> >>> Thanks for the patch. >>> >>> With it the PHY is now detected as truephy. >>> The only thing that i notice is that if the media status changes displayed with >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX >>> The packet loss is still there, and the interface again stops to work >>> after some time. >>> >> >> Ok, revert previous patch and try attached one. This one does not >> try to load ET1011C dsp codes. If this does not work next thing >> would be try to load dsp code for ET1011C revision 1 model. >> Not sure where I can find required dsp code. >> > > There don't seem to be any improvement with the new patch. > The packetloss and media status changes are still here. > Maybe check Linux/Solaris/OtherBSD driver? > > -- > Niki > LSI seem to have several documents about this phy chip, including datasheet (which you probably have) and errata : http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf Regards, Niki From owner-freebsd-current@FreeBSD.ORG Sat Mar 28 22:40:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD2B10656DD; Sat, 28 Mar 2009 22:40:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6308FC1E; Sat, 28 Mar 2009 22:40:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n2SMe3md025404; Sat, 28 Mar 2009 18:40:03 -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.14.3/8.14.3) with ESMTP id n2SMe3mG094117; Sat, 28 Mar 2009 18:40:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7E0277302F; Sat, 28 Mar 2009 17:40:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090328224003.7E0277302F@freebsd-current.sentex.ca> Date: Sat, 28 Mar 2009 17:40:03 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 22:40:07 -0000 TB --- 2009-03-28 21:10:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-03-28 21:10:50 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-03-28 21:10:50 - cleaning the object tree TB --- 2009-03-28 21:11:17 - cvsupping the source tree TB --- 2009-03-28 21:11:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-03-28 21:11:25 - building world TB --- 2009-03-28 21:11:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 21:11:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 21:11:25 - TARGET=powerpc TB --- 2009-03-28 21:11:25 - TARGET_ARCH=powerpc TB --- 2009-03-28 21:11:25 - TZ=UTC TB --- 2009-03-28 21:11:25 - __MAKE_CONF=/dev/null TB --- 2009-03-28 21:11:25 - cd /src TB --- 2009-03-28 21:11:25 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 28 21:11:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 28 22:37:29 UTC 2009 TB --- 2009-03-28 22:37:29 - generating LINT kernel config TB --- 2009-03-28 22:37:29 - cd /src/sys/powerpc/conf TB --- 2009-03-28 22:37:29 - /usr/bin/make -B LINT TB --- 2009-03-28 22:37:29 - building LINT kernel TB --- 2009-03-28 22:37:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-03-28 22:37:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-03-28 22:37:29 - TARGET=powerpc TB --- 2009-03-28 22:37:29 - TARGET_ARCH=powerpc TB --- 2009-03-28 22:37:29 - TZ=UTC TB --- 2009-03-28 22:37:29 - __MAKE_CONF=/dev/null TB --- 2009-03-28 22:37:29 - cd /src TB --- 2009-03-28 22:37:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 28 22:37:30 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] @ -> /src/sys machine -> /src/sys/powerpc/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/powerpc/src/sys/LINT /src/sys/modules/geom/geom_uzip/../../../geom/uzip/g_uzip.c ===> geom/geom_vinum (depend) @ -> /src/sys machine -> /src/sys/powerpc/include make: don't know how to make geom_vinum_create.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-03-28 22:40:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-03-28 22:40:03 - ERROR: failed to build lint kernel TB --- 2009-03-28 22:40:03 - 4170.20 user 404.07 system 5353.15 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full