From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 00:10:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C67116A4CE; Sun, 12 Sep 2004 00:10:24 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2307243D53; Sun, 12 Sep 2004 00:10:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8C0ANtR012398; Sat, 11 Sep 2004 20:10:23 -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.12.11/8.12.11) with ESMTP id i8C0AMTP041446; Sat, 11 Sep 2004 20:10:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 76FF27303F; Sat, 11 Sep 2004 20:10:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040912001023.76FF27303F@freebsd-current.sentex.ca> Date: Sat, 11 Sep 2004 20:10:23 -0400 (EDT) Subject: [releng_5 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 00:10:24 -0000 TB --- 2004-09-11 23:54:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-11 23:54:20 - starting RELENG_5 tinderbox run for powerpc/powerpc TB --- 2004-09-11 23:54:20 - checking out the source tree TB --- 2004-09-11 23:54:20 - cd /home/tinderbox/RELENG_5/powerpc/powerpc TB --- 2004-09-11 23:54:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-12 00:02:13 - building world (CFLAGS=-O -pipe) TB --- 2004-09-12 00:02:13 - cd /home/tinderbox/RELENG_5/powerpc/powerpc/src TB --- 2004-09-12 00:02:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REP.c -o asn1_TGS_REP.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REQ.c -o asn1_TGS_REQ.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_Ticket.c -o asn1_Ticket.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TicketFlags.c -o asn1_TicketFlags.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TransitedEncoding.c -o asn1_TransitedEncoding.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_UNSIGNED.c -o asn1_UNSIGNED.So building shared library libasn1.so.7 Abort trap (core dumped) *** Error code 134 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. TB --- 2004-09-12 00:10:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-12 00:10:23 - ERROR: failed to build world TB --- 2004-09-12 00:10:23 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 02:57:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9839D16A4CE for ; Sun, 12 Sep 2004 02:57:14 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6566C43D39 for ; Sun, 12 Sep 2004 02:57:14 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465 for ; Sat, 11 Sep 2004 19:57:13 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DE1CA5D09 for ; Sat, 11 Sep 2004 19:57:12 -0700 (PDT) To: current@freebsd.org Date: Sat, 11 Sep 2004 19:57:12 -0700 From: "Kevin Oberman" Message-Id: <20040912025712.DE1CA5D09@ptavv.es.net> Subject: Weird interrupt issues with RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 02:57:14 -0000 I just updated my old K6-3 system from CURRENT of Jun 13 to RELENG_5 cvsupped today at 19:53 UTC. When I bring up the network interface, I immediately start getting errors from both the Ethernet card and the second disk (where my /usr partition sits). This is the master on the second IDE bus. The boot disk has not such problems. The errors are: ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=10928255 ad2: WARNING - READ_DMA no interrupt but good status xl0: watchdog timeout ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=10928319 ad2: WARNING - READ_DMA no interrupt but good status ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=10989807 ad2: WARNING - READ_DMA no interrupt but good status ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=11855407 ad2: WARNING - WRITE_DMA no interrupt but good status xl0: watchdog timeout ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=10963679 ad2: WARNING - READ_DMA no interrupt but good status I never get failures and the retry count never goes below 2, but the system is a bit slow. If I don't bring up the network, it runs fine with no errors at all from the disk. FreeBSD kzin.es.net 5.2-CURRENT FreeBSD 5.2-CURRENT #27: Sun Jun 13 12:32:53 PDT 2004 root@kzin.es.net:/usr/obj/usr/src/sys/KZIN i386 Here is the dmesg: Copyright (c) 1992-2004 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 5.3-BETA4 #29: Sat Sep 11 13:04:34 PDT 2004 oberman@kzin.es.net:/usr/obj/usr/src/sys/KZIN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x80000800 real memory = 100646912 (95 MB) avail memory = 92942336 (88 MB) K6-family MTRR support enabled (2 registers) ACPI disabled by blacklist. Contact your BIOS vendor. npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 9.0 (no driver attached) xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:da:80:4b:43 atapci0: port 0xd000-0xd00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 cpu0 on motherboard pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) Timecounter "TSC" frequency 451023830 Hz quality 800 Timecounters tick every 10.000 msec ad0: 13031MB [26476/16/63] at ata0-master UDMA33 ATAPI_RESET time = 30us ad2: 13029MB [26473/16/63] at ata1-master UDMA33 acd0: DVDROM at ata1-slave PIO3 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 11.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a I'm guessing that this is interrupt related, but the devices are on completely different IRQs, so I really don't understand how. Any ideas on what could be happening? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 03:16:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 396B116A4CE for ; Sun, 12 Sep 2004 03:16:20 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1ECF43D5A for ; Sun, 12 Sep 2004 03:16:19 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i8C3GJt3010456 for ; Sat, 11 Sep 2004 22:16:19 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.243 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Sat, 11 Sep 2004 22:16:19 -0500 (CDT) Message-ID: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> Date: Sat, 11 Sep 2004 22:16:19 -0500 (CDT) From: "Rusty Nejdl" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tethys.ringofsaturn.com X-Virus-Status: Clean Subject: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.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, 12 Sep 2004 03:16:20 -0000 I am running the latest RELENG_5 as of today with basically a default kernel config (I added smbus support and I'm using SCHED_ULE as my scheduler). Since I upgraded, whenever I try to use XMMS to stream audio and run gaim, the system will completely freeze. I can run either program separately and they work just fine, but if I am logged into gaim, open xmms, and start to stream audio, as soon as sound comes across, the system freezes. If I am streaming audio, open gaim, and login, right before the list of contacts opens up, the system freezes. I am doing a portupgrade -Rf for gaim and xmms right now to see if that has any affect, but wanted to see if anyone else was seeing something weird like this and if anyone had any ideas. The only other thing I can think of would be to use SCHED_4BSD instead, but I had thought that ULE would be a better choice for my dual xeon server. Thanks! Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 04:09:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2516A4CF; Sun, 12 Sep 2004 04:09:48 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E73E443D49; Sun, 12 Sep 2004 04:09:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i8C49kmm003052; Sun, 12 Sep 2004 00:09:46 -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.12.11/8.12.11) with ESMTP id i8C49k5d050971; Sun, 12 Sep 2004 00:09:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D32CD7303F; Sun, 12 Sep 2004 00:09:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040912040945.D32CD7303F@freebsd-current.sentex.ca> Date: Sun, 12 Sep 2004 00:09:45 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 04:09:48 -0000 TB --- 2004-09-12 03:10:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-12 03:10:43 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-12 03:10:43 - checking out the source tree TB --- 2004-09-12 03:10:43 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-12 03:10:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-12 03:16:09 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-12 03:16:09 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-12 03:16:09 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -o mount mount.o mount_ufs.o getmntopts.o vfslist.o gzip -cn /tinderbox/CURRENT/amd64/amd64/src/sbin/mount/mount.8 > mount.8.gz ===> sbin/mount_autofs (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs/mount_autofs.c /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs/mount_autofs.c: In function `ioset': /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs/mount_autofs.c:60: warning: implicit declaration of function `strlen' /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs/mount_autofs.c: In function `main': /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs/mount_autofs.c:80: warning: unused variable `i' *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin/mount_autofs. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-12 04:09:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-12 04:09:45 - ERROR: failed to build world TB --- 2004-09-12 04:09:45 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 05:10:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 576D916A4D2; Sun, 12 Sep 2004 05:10:28 +0000 (GMT) Date: Sun, 12 Sep 2004 05:10:28 +0000 From: Kris Kennaway To: Rusty Nejdl Message-ID: <20040912051028.GA74510@hub.freebsd.org> References: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 05:10:28 -0000 On Sat, Sep 11, 2004 at 10:16:19PM -0500, Rusty Nejdl wrote: > I am running the latest RELENG_5 as of today with basically a default > kernel config (I added smbus support and I'm using SCHED_ULE as my > scheduler). Since I upgraded, whenever I try to use XMMS to stream audio > and run gaim, the system will completely freeze. I can run either program > separately and they work just fine, but if I am logged into gaim, open > xmms, and start to stream audio, as soon as sound comes across, the system > freezes. If I am streaming audio, open gaim, and login, right before the > list of contacts opens up, the system freezes. > > I am doing a portupgrade -Rf for gaim and xmms right now to see if that > has any affect, but wanted to see if anyone else was seeing something > weird like this and if anyone had any ideas. The only other thing I can > think of would be to use SCHED_4BSD instead, but I had thought that ULE > would be a better choice for my dual xeon server. ULE has known problems, that's why 4BSD was made default again. Retry with 4BSD and let us know whether or not the problems persist. Kris From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:13:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F3DA16A4CE; Sun, 12 Sep 2004 06:13:21 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7E8B43D31; Sun, 12 Sep 2004 06:13:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-123-121-27.dsl.snfc21.pacbell.net [68.123.121.27])i8C6DGvd225228; Sun, 12 Sep 2004 02:13:17 -0400 Message-ID: <4143E8FC.7000308@elischer.org> Date: Sat, 11 Sep 2004 23:13:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: NAKATA Maho References: <20040912.120803.607953196.chat95@mac.com> In-Reply-To: <20040912.120803.607953196.chat95@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: KSE and SMP problem in FreeBSD/amd64 5.3BETA3, namely KSEdosen't make use of SMP. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:13:21 -0000 Firstly ,I am very happy to see your mail. We need all bug repors.. even bad ones :-) I have been working on trying to fix problems in this sort of thing in the last few weeks for 5.3 but will be able to examine your work more closely in a few days. I just want you to know that your email will be worked on, even if you do not hear anything immediatly. more notes below.. NAKATA Maho wrote: > Dear amd64 freaks, I noticed that there seems to be a bug > in KSE with SMP configuration. > > Here, I describe my problem in detail. > > the math/atlas port utilize SMP by threading. namely, > if you have 2 processors you can gain the nearly double performance > so KSE is the key technology for SMP. However, for amd64, KSE doesn't > utilize second CPU at all. > > My machine is: > Tyan S2885 > Opteron 1.6GHz x 2 > 2G bytes of memory > > I confirmed that: > o FreeBSD/amd64 5.2.1-RELEASE with KSE doesn't work at all, > dumps core or memory fault, while without KSE works well but > without performance gain (using libmap.conf, and this is not shown here). this is expected. > > o FreeBSD/amd64 5.3-BEAT3 with KSE works at least, however, > doesn't utilize SMP. I will try examine this together with Peter and Dan over the next few days.. Please show me the output in 5.3 of sysctl kern.threads and kern.sched also there will be improvements in beta4 I hope which scheduler? show ldd output for your program please. > o FreeBSD/i386 5.2.1-RELEASE, and 5.3-BEAT3 works well. > > How to repreat: > (it took huge hours to build math/atlas, so I put work dir at) at? > > CVSup your ports tree, please use: > # $FreeBSD: ports/math/atlas/Makefile,v 1.27 2004/09/02 00:25:45 maho Exp $ > > 0a. prepare opteron SMP machine, and install FreeBSD/amd64 5.3-BETA3. > 1a. cd /usr/ports/math/atlas > 2a. make > 3a. wait for long time > 4a. cd /usr/ports/math/atlas/work/ATLAS/bin/THREADED > 5a. make xdlutst (it took only seconds) > 6a. make xdlutst_pt (it took only seconds) > 7a. type ./xdlutst -N 1000 2000 200 (this doesn't utilize SMP and KSE) > NREPS Major M N lda NPVTS TIME MFLOP RESID > ===== ===== ===== ===== ===== ===== ======== ======== ======== > 0 Col 1000 1000 1000 995 0.301 2210.755 3.821e-02 > 0 Col 1200 1200 1200 1194 0.504 2282.569 3.793e-02 > 0 Col 1400 1400 1400 1395 0.794 2303.707 2.843e-02 > 0 Col 1600 1600 1600 1595 1.156 2360.557 2.893e-02 > 0 Col 1800 1800 1800 1793 1.637 2374.130 2.803e-02 > 0 Col 2000 2000 2000 1990 2.192 2431.838 2.744e-02 > > 6 cases ran, 6 cases passed > > > 8a. type ./xdlutst_pt -N 2000 3000 200 > ./xdlutst_pt -N 2000 3000 200 > NREPS Major M N lda NPVTS TIME MFLOP RESID > ===== ===== ===== ===== ===== ===== ======== ======== ======== > 0 Col 2000 2000 2000 1990 2.286 2332.527 2.744e-02 > 0 Col 2200 2200 2200 2194 2.764 2567.795 2.639e-02 > 0 Col 2400 2400 2400 2394 3.766 2446.449 2.721e-02 > 0 Col 2600 2600 2600 2593 4.722 2480.761 2.472e-02 > 0 Col 2800 2800 2800 2795 5.855 2499.038 2.441e-02 > 0 Col 3000 3000 3000 2992 7.302 2464.553 2.442e-02 > > 6 cases ran, 6 cases passed > > Please see the MFLOP column. This indicates the FLOPS of the calculation. > Opteron 1.6G's performance is 2.4GFlops for LU decomposition. > and as you can see no perfomance gain :( > > typical output of top is like that: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 716 root 134 0 185M 179M CPU0 0 1:05 21.09% 21.09% xdlutst_pt > 716 root 134 0 185M 179M RUN 0 1:05 19.53% 19.53% xdlutst_pt > 716 root 20 0 185M 179M kserel 1 1:05 0.00% 0.00% xdlutst_pt > 716 root 20 0 185M 179M ksesig 1 1:05 0.00% 0.00% xdlutst_pt > 716 root 20 0 185M 179M kserel 0 1:05 0.00% 0.00% xdlutst_pt > > two threads of xdlutst_pt are always running on *ONLY CPU0 or CPU1* > -------------------------------------------------------------------- > Next, I have tried i386 version > > 0i. prepare opteron SMP machine same as above, and install FreeBSD/i386 > 5.3-BETA3. > CVSup your ports tree. > > 1i. cd /usr/ports/math/atlas > 2i. make > 3i. wait for long time > 4i. cd /usr/ports/math/atlas/work/ATLAS/bin/THREADED > 5i. make xdlutst (it took only seconds) > 6i. make xdlutst_pt (it took only seconds) > 7i. type ./xdlutst -N 1000 2000 200 (this doesn't utilize SMP and KSE) > ./xdlutst -N 1000 2000 200 > NREPS Major M N lda NPVTS TIME MFLOP RESID > ===== ===== ===== ===== ===== ===== ======== ======== ======== > 0 Col 1000 1000 1000 995 0.307 2170.617 3.437e-02 > 0 Col 1200 1200 1200 1194 0.522 2204.335 3.482e-02 > 0 Col 1400 1400 1400 1395 0.799 2286.888 4.150e-02 > 0 Col 1600 1600 1600 1595 1.164 2345.104 3.598e-02 > 0 Col 1800 1800 1800 1793 1.616 2405.542 3.601e-02 > 0 Col 2000 2000 2000 1990 2.218 2403.157 3.436e-02 > > 6 cases ran, 6 cases passed > > 8i. type ./xdlutst_pt -N 3000 4000 200 (this utilize KSE so that make > full use of SMP) > ./xdlutst_pt -N 3000 4000 200 > NREPS Major M N lda NPVTS TIME MFLOP RESID > ===== ===== ===== ===== ===== ===== ======== ======== ======== > 0 Col 3000 3000 3000 2992 7.157 2514.351 3.650e-02 > 0 Col 3200 3200 3200 3186 5.127 4259.986 3.207e-02 > 0 Col 3400 3400 3400 3392 5.867 4465.006 3.528e-02 > 0 Col 3600 3600 3600 3589 6.791 4579.468 3.519e-02 > 0 Col 3800 3800 3800 3791 8.510 4297.730 3.285e-02 > 0 Col 4000 4000 4000 3995 9.207 4633.234 3.218e-02 > > 6 cases ran, 6 cases passed > > yes, there are perfomance gain by utilizing SMP. > > typical output of top seems like > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 714 root 139 0 301M 300M CPU1 1 2:16 66.41% 66.41% xdlutst_pt > 714 root 139 0 301M 300M RUN 0 2:16 66.41% 66.41% xdlutst_pt > 714 root 20 0 301M 300M kserel 1 2:16 0.00% 0.00% xdlutst_pt > 714 root 20 0 301M 300M kserel 0 2:16 0.00% 0.00% xdlutst_pt > 714 root 20 0 301M 300M ksesig 0 2:16 0.00% 0.00% xdlutst_pt > > Summary: > Difference between 8a and 8i are: > o there are no perfomance gain in 8a whereas 8i gains nearly double. > o the result of top indicates that by KSE of amd64, two threads are produced > correctly, however scheduling is somwhat odd, so that two threads runs > at the same processor, apparently threads are spread over different > processors, though. > > You can try easily, work directory of these two ports are available: > http://people.freebsd.org/~maho/atlas/atlas-work-opteron_dual-amd64.tar.bz > http://people.freebsd.org/~maho/atlas/atlas-work-opteron_dual-i386.tar.bz > > MD5 (atlas-work-opteron_dual-amd64.tar.bz) = 9d9d7e8b00b34a783b7d2172bc404e23 > MD5 (atlas-work-opteron_dual-i386.tar.bz) = 8076a753c7b3edaea7bd446c6473f120 > > Does anybody can fix it? yes we will try. > > Best regards, > --nakata maho > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:39:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18C2116A4CE; Sun, 12 Sep 2004 06:39:45 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C4C43D46; Sun, 12 Sep 2004 06:39:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-123-121-27.dsl.snfc21.pacbell.net [68.123.121.27])i8C6df3d099758; Sun, 12 Sep 2004 02:39:42 -0400 Message-ID: <4143EF29.2080404@elischer.org> Date: Sat, 11 Sep 2004 23:39:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin , Peter Wemm , current@freebsd.org Content-Type: multipart/mixed; boundary="------------070802050901090002030708" Subject: [Patch] panics/hangs with preemption and threads. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:39:45 -0000 This is a multi-part message in MIME format. --------------070802050901090002030708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Guys I think I found a (the?) major cause for the corruptions of the ksegrp/thread runqueue for threaded processes when Premption is turned on.. When a thread is scheduled in setrunqueue() the firt thing that is done is that it is put in the correct place in the ksegrp's run queue,. then if it is in the top N spots (where N is the defined concurrency and is usually <= NCPU) it is passed down to the system scheduler using sched_add(). Sched_add can call maybe_preempt() which can decide to switch out the current thread and switch to the new one immediatly. The trouble with that is that we have already put the new one on the ksegrp's run queue! When that thread is next put on the run queue using setrunqueue() it is already there, and we end up with an infinitly looping run queue. Any code that follows that list will never end. and the system will freeze. Here is a patch that solves it but I'm not happy about it.. John, you wrote the preemption code.. do you have any ideas about how to do this cleaner? One possibility is to make sched_add return a value that indicates if the thread was handled immediatly. that would allow setrunqueue to only set it into the ksegrp's run queue if it was not already handled. Other suggestions welcome. --------------070802050901090002030708 Content-Type: text/plain; name="q.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="q.diff" ==== //depot/projects/nsched/sys/kern/kern_switch.c#21 - /home/julian/p4/nsched/sys/kern/kern_switch.c ==== @@ -396,5 +396,9 @@ return; } + if (((flags & (SRQ_YIELDING|SRQ_OURSELF|SRQ_NOPREEMPT)) == 0) && + maybe_preempt(td)) + return; + tda = kg->kg_last_assigned; if ((kg->kg_avail_opennings <= 0) && @@ -453,7 +457,7 @@ kg->kg_last_assigned = td2; } kg->kg_avail_opennings--; - sched_add(td2, flags); + sched_add(td2, flags|SRQ_NOPREEMPT); } else { CTR3(KTR_RUNQ, "setrunqueue: held: td%p kg%p pid%d", td, td->td_ksegrp, td->td_proc->p_pid); ==== //depot/projects/nsched/sys/kern/sched_4bsd.c#48 - /home/julian/p4/nsched/sys/kern/sched_4bsd.c ==== @@ -1018,7 +1018,8 @@ #endif { - if (maybe_preempt(td)) + if (((flags & SRQ_NOPREEMPT) == 0) && + maybe_preempt(td)) return; } } ==== //depot/projects/nsched/sys/kern/sched_ule.c#30 - /home/julian/p4/nsched/sys/kern/sched_ule.c ==== @@ -1662,13 +1662,13 @@ /* let jeff work out how to map the flags better */ /* I'm open to suggestions */ - if (flags & SRQ_YIELDING) + if (flags & (SRQ_YIELDING|SRQ_NOPREEMPT)) { /* * Preempting during switching can be bad JUJU * especially for KSE processes */ sched_add_internal(td, 0); - else + } else sched_add_internal(td, 1); } ==== //depot/projects/nsched/sys/sys/proc.h#29 - /home/julian/p4/nsched/sys/sys/proc.h ==== @@ -658,6 +658,7 @@ #define SRQ_YIELDING 0x0001 /* we are yielding (from mi_switch) */ #define SRQ_OURSELF 0x0002 /* it is ourself (from mi_switch) */ #define SRQ_INTR 0x0004 /* it is probably urgent */ +#define SRQ_NOPREEMPT 0x0008 /* Just don't ok? */ /* How values for thread_single(). */ #define SINGLE_NO_EXIT 0 --------------070802050901090002030708-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:42:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 212DC16A4CE for ; Sun, 12 Sep 2004 06:42:09 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5E143D58 for ; Sun, 12 Sep 2004 06:42:08 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8C6g3rY049961 for ; Sun, 12 Sep 2004 02:42:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8C6g3iC049958 for ; Sun, 12 Sep 2004 02:42:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 02:42:03 -0400 (EDT) From: Andre Guibert de Bruet To: current@freebsd.org In-Reply-To: <20040911183823.W84468@alpha.siliconlandmark.com> Message-ID: <20040912022558.B84468@alpha.siliconlandmark.com> References: <20040911183823.W84468@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Subject: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeList failed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:42:09 -0000 Replying to myself... I made the cardinal sin of not including a uname -a... The system in question is: FreeBSD bling.home 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Sat Sep 11 18:31:59 EDT 2004 root@bling.home:/usr/CURRENT/sys/i386/compile/BLING i386 I have a fresh dmesg up at http://bling.properkernel.com/dmesg.boot.txt and a boot -v at http://bling.properkernel.com/boot-v.txt Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > On Sat, 11 Sep 2004, Andre Guibert de Bruet wrote: > Anyone have any ideas on this one? > > # cvsupdate [...] > Updating collection src-all/cvs > TreeList failed: Network write failure: ChannelMux.ProtocolError > Will retry at 18:43:42 > ^C > > The machine in question is a dual Athlon with a custom SMP kernel config > which can be found at http://bling.properkernel.com/BLING . Reverting to > GENERIC does _not_ fix the problem. The interface in question is an > nge-compatible 64-bit Linksys card detected as: > > nge0@pci0:8:0: class=0x020000 card=0x10641737 chip=0x0022100b rev=0x00 > hdr=0x00 > vendor = 'National Semiconductor' > device = 'DP83820/1 10/100/1000 Gigabit Ethernet Adapter' > class = network > subclass = ethernet > > I've also noticed data corruption in the form of failed CRCs (And hence > dropped SSH connections) while transferring large amounts of data via SSH > over gige to a machine on its subnet. These problems started occuring after > the giant-less networking megacommit. Older kernels check out without any > such issues. > > Additional information on the system can be found online: > pciconf -vl: http://bling.properkernel.com/pciconf-vl.txt > kernel config: http://bling.properkernel.com/BLING > old dmesg (Can be updated): http://bling.properkernel.com/dmesg.boot.txt From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:44:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3DBFD16A4CF; Sun, 12 Sep 2004 06:44:16 +0000 (GMT) Date: Sun, 12 Sep 2004 06:44:16 +0000 From: Kris Kennaway To: Andre Guibert de Bruet Message-ID: <20040912064416.GA89882@hub.freebsd.org> References: <20040911183823.W84468@alpha.siliconlandmark.com> <20040912022558.B84468@alpha.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912022558.B84468@alpha.siliconlandmark.com> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeList failed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:44:16 -0000 On Sun, Sep 12, 2004 at 02:42:03AM -0400, Andre Guibert de Bruet wrote: > >I've also noticed data corruption in the form of failed CRCs (And hence > >dropped SSH connections) while transferring large amounts of data via SSH > >over gige to a machine on its subnet. These problems started occuring > >after the giant-less networking megacommit. Older kernels check out > >without any such issues. Does it go away if you turn off debug.mpsafenet? If not, it's probably not related to that commit. Kris From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:44:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24AEE16A4CE for ; Sun, 12 Sep 2004 06:44:40 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB8CD43D1D for ; Sun, 12 Sep 2004 06:44:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-123-121-27.dsl.snfc21.pacbell.net [68.123.121.27])i8C6ic3d111592 for ; Sun, 12 Sep 2004 02:44:38 -0400 Message-ID: <4143F04B.6040003@elischer.org> Date: Sat, 11 Sep 2004 23:44:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: ATA cdrom boot wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:44:40 -0000 My test system (todays sources via p4) has started doing: ... atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ... ad0: 9541MB [19386/16/63] at ata0-master UDMA100 ATAPI_RESET time = 50us ATAPI_RESET time = 50us acd0: FAILURE - MODE_SENSE_BIG timed out ATAPI_RESET time = 50us acd0: FAILURE - MODE_SENSE_BIG timed out ATAPI_RESET time = 50us acd0: FAILURE - MODE_SENSE_BIG timed out ATAPI_RESET time = 50us acd0: FAILURE - MODE_SENSE_BIG timed out ATAPI_RESET time = 50us acd0: FAILURE - MODE_SENSE_BIG timed out acd0: CDROM at ata1-master PIO4 ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - TEST_UNIT_READY timed out ATAPI_RESET time = 50us acd0: FAILURE - PREVENT_ALLOW timed out Each of these messages takes between 4 and 30 seconds to print out so booting is considerably slowed. any suggestions/ideas? From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 06:53:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9A8816A4CE; Sun, 12 Sep 2004 06:53:06 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 622C743D45; Sun, 12 Sep 2004 06:53:06 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8C6r5Gk050034; Sun, 12 Sep 2004 02:53:05 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8C6r5lj050031; Sun, 12 Sep 2004 02:53:05 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 02:53:05 -0400 (EDT) From: Andre Guibert de Bruet To: Kris Kennaway In-Reply-To: <20040912064416.GA89882@hub.freebsd.org> Message-ID: <20040912025037.Y84468@alpha.siliconlandmark.com> References: <20040911183823.W84468@alpha.siliconlandmark.com> <20040912064416.GA89882@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@FreeBSD.ORG Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 06:53:06 -0000 On Sun, 12 Sep 2004, Kris Kennaway wrote: > On Sun, Sep 12, 2004 at 02:42:03AM -0400, Andre Guibert de Bruet wrote: > >>> I've also noticed data corruption in the form of failed CRCs (And hence >>> dropped SSH connections) while transferring large amounts of data via SSH >>> over gige to a machine on its subnet. These problems started occuring >>> after the giant-less networking megacommit. Older kernels check out >>> without any such issues. > > Does it go away if you turn off debug.mpsafenet? If not, it's > probably not related to that commit. Setting debug.mpsafenet to 0 allows the SSH transfers to complete. The MD5 checksums and sizes match. Where do we go from here? Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 07:01:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64C9616A4CE for ; Sun, 12 Sep 2004 07:01:29 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C7243D41 for ; Sun, 12 Sep 2004 07:01:26 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8C71MMJ050237; Sun, 12 Sep 2004 03:01:22 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8C71Mh8050234; Sun, 12 Sep 2004 03:01:22 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 03:01:21 -0400 (EDT) From: Andre Guibert de Bruet To: "Thomas T. Veldhouse" In-Reply-To: <41436ABE.7060202@veldy.net> Message-ID: <20040912025902.S84468@alpha.siliconlandmark.com> References: <41436ABE.7060202@veldy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: freebsd-current@freebsd.org Subject: Re: How do I install a kernel from CD over the top of BETA4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 07:01:29 -0000 On Sat, 11 Sep 2004, Thomas T. Veldhouse wrote: > I built two kernels and did not manage to save the old working kernel (I > thought that I had) and now I have NO bootable kernels to boot my 5.3BETA4 > system ... how can I get the kernel off of my 5.2.1 CD so that I can build a > new working kernel (after a fresh cvsup)? Boot off of the CD, and use the rescue shell. Make sure that you mount your root partition with "-o rw". Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 07:17:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2CFE16A4CE for ; Sun, 12 Sep 2004 07:17:15 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5602443D53 for ; Sun, 12 Sep 2004 07:17:14 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i8C7HBMR076318 for ; Sun, 12 Sep 2004 00:17:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i8C7HACD076317 for freebsd-current@freebsd.org; Sun, 12 Sep 2004 00:17:10 -0700 (PDT) (envelope-from obrien) Date: Sun, 12 Sep 2004 00:17:10 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20040912071710.GA76209@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [Fwd: setrunqueue(): corrupt kq_runq] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sean@mcneil.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, 12 Sep 2004 07:17:15 -0000 I was asked to forward this to freebsd-current for a user who has trouble having his email rejected by FreeBSD.org. -- David ----- Forwarded message from Sean McNeil ----- Content-Description: Forwarded message - setrunqueue(): corrupt kq_runq From: Sean McNeil Subject: setrunqueue(): corrupt kq_runq Date: Thu, 09 Sep 2004 11:55:52 -0700 To: freebsd-current@freebsd.org X-Mailer: Ximian Evolution 1.4.6 amd64 -CURRENT system has crashed now several times in the last 2 days. Ever since the change to SCHED_4BSD and PREEMPTION. I certainly hope this is fixed before 5.3-RELEASE. Sep 9 11:43:46 server syslogd: kernel boot file is /boot/kernel/kernel Sep 9 11:43:46 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff004be8e520 Sep 9 11:43:46 server kernel: panic: deadlock in setrunqueue Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21a90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21aa0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21810 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21820 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21590 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c215a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21310 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21320 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21090 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c210a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20e10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20e20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20b90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20ba0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20910 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20920 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20690 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c206a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20410 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20420 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20190 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c201a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ff10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1ff20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fc90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fca0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fa10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fa20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f790 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f7a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f510 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f520 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f290 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f2a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f010 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f020 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ed90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eda0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1eb10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eb20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e890 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e8a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e610 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e620 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Then a reboot. Sean ----- End forwarded message ----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:17:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C741F16A4CE; Sun, 12 Sep 2004 09:17:52 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD9F43D2D; Sun, 12 Sep 2004 09:17:52 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i8C9HoXl002036; Sun, 12 Sep 2004 18:17:50 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2004 18:17:50 +0900 (JST) Message-Id: <200409120917.i8C9HoXl002036@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Sun, 12 Sep 2004 18:17:50 +0900 (JST) cc: takawata@FreeBSD.org Subject: [PANIC] snd_sb16 on 5.3-BETA4 over qemu are fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 09:17:52 -0000 snd_sb16 on 5.3-BETA4 over qemu(modified by nork and takawata) causes panic. But this is well-known problem as kern/71189. http://www.freebsd.org/cgi/query-pr.cgi?pr=71189 I confirmed that this patch is good. Anyone, would you please commit to 6-current and 5.3 branch? From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:49:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D693816A4CF for ; Sun, 12 Sep 2004 09:49:02 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E0843D5D for ; Sun, 12 Sep 2004 09:49:02 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i8C9n0t3071557; Sun, 12 Sep 2004 11:49:00 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41441B60.9040708@DeepCore.dk> Date: Sun, 12 Sep 2004 11:48:16 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4123FC71.8060308@root.org> <41245804.7060008@DeepCore.dk> <412A20A3.8060600@root.org> <412A5C40.4050100@DeepCore.dk> <412A641A.1030809@root.org> <412AEF2E.7080600@DeepCore.dk> <412E8D3C.4060001@root.org> <4130E1E0.6010000@DeepCore.dk> <413266CD.1020107@root.org> In-Reply-To: <413266CD.1020107@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: suspend/resume panic in ACPI.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 09:49:03 -0000 Nate Lawson wrote: > More info about the panic (i.e. message, backtrace, etc.) would help he= re. OK, on a current from todays morning ~10:00 CEST and commenting out the=20 guts of acpi_cmbat.c:resume() I managed to get this trace, hope that=20 helps you in finding out why ACPI panics... (hand transscribed no serial console) panic: vm_page_remove: page not busy trace: panic + 0xbb vm_page_remove + 0x22 vm_page_free_toq + 0x78 vm_page_free_zero + 0x15 _pmap_unwire_pte_hold + 0x65 pmap_unuse_pt + 0x65 pmap_remove_pte + 0xa9 pmap_remove_page + 0x26 pmap_remove + 0xa0 acpi_sleep_machdep + 0x329 acpi_SetSleepState + 0x227 acpi_system_eventhandler_sleep + 0x14 acpi_event_sleep_button_sleep + 0x74 acpi_button_notify_sleep + 0xa0 acpi_task_thread + 0xbd fork_exit + 0x75 fork_trampoline + 0x8 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:41:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CAA16A4CE for ; Sun, 12 Sep 2004 10:41:28 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C8343D2D for ; Sun, 12 Sep 2004 10:41:27 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8CAfQVw037901 for ; Sun, 12 Sep 2004 06:41:26 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36881-09 for ; Sun, 12 Sep 2004 06:41:26 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8CAfQ3e037888 for ; Sun, 12 Sep 2004 06:41:26 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8CAfJ41011425 for ; Sun, 12 Sep 2004 06:41:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 12 Sep 2004 06:46:26 -0400 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 10:41:28 -0000 On the 4 different machines I tried (2 845 and 2 865 chipsets) none seem to work with ichwd. Note, these boards do work with http://freebsd.tamu.edu/wdog/ in RELENG_4 so I know the watchdog is not disabled on the MB. Also, on one box here, I know ichwd worked at one point ( ~ July ) but now it too gives ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 or ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 11:15:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1655616A4CE for ; Sun, 12 Sep 2004 11:15:23 +0000 (GMT) Received: from coruscant.rfc1149.org (coruscant.rfc1149.org [217.160.130.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB3F43D5A for ; Sun, 12 Sep 2004 11:15:22 +0000 (GMT) (envelope-from arne@rfc2549.org) Received: by coruscant.rfc1149.org (Postfix, from userid 110) id C10873F0B; Sun, 12 Sep 2004 13:15:20 +0200 (CEST) Received: from kamino.rfc1149.org (dsl-082-083-044-253.arcor-ip.net [82.83.44.253]) by coruscant.rfc1149.org (Postfix) with ESMTP id AEAD33EBD; Sun, 12 Sep 2004 13:15:12 +0200 (CEST) Received: by kamino.rfc1149.org (Postfix, from userid 1001) id D02644088; Sun, 12 Sep 2004 13:15:09 +0200 (CEST) To: Mike Tancsa In-Reply-To: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> (Mike Tancsa's message of "Sun, 12 Sep 2004 06:46:26 -0400") References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> From: Arne Schwabe Date: Sun, 12 Sep 2004 13:15:09 +0200 Message-ID: <86vfejlow2.fsf@kamino.rfc1149.org> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on coruscant.rfc1149.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: cc: freebsd-current@freebsd.org Subject: Re: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 11:15:23 -0000 Mike Tancsa writes: > On the 4 different machines I tried (2 845 and 2 865 chipsets) none seem to > work with ichwd. Note, these boards do work with > http://freebsd.tamu.edu/wdog/ in RELENG_4 so I know the watchdog is not > disabled on the MB. Also, on one box here, I know ichwd worked at one > point ( ~ July ) but now it too gives > > ichwd0: on motherboard > ichwd0: unable to reserve SMI registers > device_attach: ichwd0 attach returned 6 > > or > ichwd0: on motherboard > ichwd0: unable to reserve SMI registers > device_attach: ichwd0 attach returned 6 Same for me Intel ICH something (The Centrino Chipset) ichwd module loaded ichwd_identify(): found ICH chipset: Intel 82801DBM watchdog timer ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 Arne From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 11:24:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07AAC16A4CE; Sun, 12 Sep 2004 11:24:26 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE24243D39; Sun, 12 Sep 2004 11:24:24 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 0BCD13B8F9; Sun, 12 Sep 2004 13:24:22 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) i8CBOBVc062527; Sun, 12 Sep 2004 13:24:11 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.1/8.13.1/Submit) id i8CBOBih062526; Sun, 12 Sep 2004 13:24:11 +0200 (CEST) (envelope-from schweikh) Date: Sun, 12 Sep 2004 13:24:11 +0200 From: Jens Schweikhardt To: Kris Kennaway Message-ID: <20040912112411.GA62181@schweikhardt.net> References: <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825183342.GA81434@xor.obsecurity.org> User-Agent: Mutt/1.5.6i cc: Maxim Sobolev cc: portmgr@FreeBSD.ORG cc: Ruslan Ermilov cc: current@FreeBSD.ORG cc: Roman Kurakin Subject: Re: ccache support for make buildworld/make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 11:24:26 -0000 On Wed, Aug 25, 2004 at 11:33:42AM -0700, Kris Kennaway wrote: ... # BTW, I don't think there's anything to set up..you just set # CC="ccache cc" or similar. # # Kris Has anyone gotten this to work? I have fixed the "#ident" problem by patching /usr/src/contrib/gcc/c-ppoutput.c to remove the double quotes, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16999 --- src/contrib/gcc/c-ppoutput.c 2004/08/26 14:10:04 1.1 +++ src/contrib/gcc/c-ppoutput.c 2004/08/26 14:10:32 @@ -292,7 +292,7 @@ const cpp_string *str) { maybe_print_line (print.map, line); - fprintf (print.outf, "#ident \"%s\"\n", str->text); + fprintf (print.outf, "#ident %s\n", str->text); print.line++; } and installed that cc et al in /usr/bin. I can make it work for buildkernel (cuts down time to 30%, woohoo!), but $ make -s CC='/usr/local/bin/ccache cc' CXX='/usr/local/bin/ccache c++' buildworld and $ make -s CC='/usr/local/bin/ccache /usr/bin/cc' CXX='/usr/local/bin/ccache /usr/bin/c++' buildworld both fail with [...] ===> lib/libpam/modules/pam_unix (all) ===> lib/libpam/libpam (all) ===> lib/libautofs (all) /share/HEAD/src/lib/libautofs/libautofs.c:49:30: fs/autofs/autofs.h: No such file or directory /share/HEAD/src/lib/libautofs/libautofs.c: In function `autoreq_get': /share/HEAD/src/lib/libautofs/libautofs.c:253: error: invalid use of undefined type `struct autofs_userreq' /share/HEAD/src/lib/libautofs/libautofs.c:253: error: dereferencing pointer to incomplete type /share/HEAD/src/lib/libautofs/libautofs.c: In function `do_autoreq_get': [...] while without ccache the buildworld completes successfully as expected. So it's not an issue with my src tree and it's not an issue of leftovers from previous builds as I always start from scratch with cvs co src in an empty directory. I rather expect some subtle interaction of ccache and the CC environment/make variables with the build. A possible candidate is /usr/bin/mkdep which is used a lot during builds and is sensitive to CC settings. Anyone successfully used ccache for a buildworld? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 12:31:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44E8416A4CE for ; Sun, 12 Sep 2004 12:31:51 +0000 (GMT) Received: from smtp1.netcologne.de (smtp1.netcologne.de [194.8.194.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF7A43D5A for ; Sun, 12 Sep 2004 12:31:50 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-81-173-169-89.netcologne.de [81.173.169.89]) by smtp1.netcologne.de (Postfix) with SMTP id 243DE38CA2 for ; Sun, 12 Sep 2004 14:31:48 +0200 (MEST) Received: (qmail 1602 invoked by uid 1001); 12 Sep 2004 12:32:07 -0000 Date: Sun, 12 Sep 2004 14:31:45 +0200 From: Thomas-Martin Seck To: freebsd-current@freebsd.org, John-Mark Gurney Message-ID: <20040912123144.GA713@laurel.tmseck.homedns.org> Mail-Followup-To: freebsd-current@freebsd.org, John-Mark Gurney References: <20040911185729.GA382@laurel.tmseck.homedns.org> <20040911193523.GB72089@funkthat.com> <20040911195955.GB382@laurel.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911195955.GB382@laurel.tmseck.homedns.org> User-Agent: Mutt/1.4.2.1i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms Subject: Re: RELENG_5: occasional panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 12:31:51 -0000 * I wrote: > > $ gdb /usr/obj/usr/src/sys/CURRENT/kernel.debug > 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"... > (gdb) l *knote+0x27 > 0xc04c16cf is in knote (atomic.h:154). > 149 atomic.h: No such file or directory. > in atomic.h > (gdb) Sorry: $ cd /usr/obj/usr/src/sys/CURRENT $ gdb kernel.debug 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"... (gdb) l *knote+0x27 0xc04c16cf is in knote (atomic.h:154). 149 static __inline int 150 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 151 { 152 int res = exp; 153 154 __asm __volatile ( 155 " " __XSTRING(MPLOCKED) " " 156 " cmpxchgl %1,%2 ; " 157 " setz %%al ; " 158 " movzbl %%al,%0 ; " (gdb) From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 13:35:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FCAD16A4CE; Sun, 12 Sep 2004 13:35:23 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B25F43D46; Sun, 12 Sep 2004 13:35:23 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i8CDZMZC017048; Sun, 12 Sep 2004 08:35:22 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Sun, 12 Sep 2004 08:35:22 -0500 (CDT) Message-ID: <62869.66.13.175.242.1094996122.squirrel@mail.ringofsaturn.com> In-Reply-To: <20040912051028.GA74510@hub.freebsd.org> References: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> <20040912051028.GA74510@hub.freebsd.org> Date: Sun, 12 Sep 2004 08:35:22 -0500 (CDT) From: "Rusty Nejdl" To: "Kris Kennaway" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tethys.ringofsaturn.com X-Virus-Status: Clean cc: Rusty Nejdl cc: current@freebsd.org Subject: Re: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.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, 12 Sep 2004 13:35:23 -0000 Kris Kennaway said: > > ULE has known problems, that's why 4BSD was made default again. Retry > with 4BSD and let us know whether or not the problems persist. > > Kris Kris, This does indeed work. However, I wasn't having problems with ULE until some change was committed in the last week caused this problem for me. The only significant breakage I found so far with ULE was when I had hyperthreading enabled. Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 13:59:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E74B816A4CE for ; Sun, 12 Sep 2004 13:59:18 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90E1743D67 for ; Sun, 12 Sep 2004 13:59:17 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [83.237.13.46] (ppp83-237-13-46.pppoe.mtu-net.ru [83.237.13.46]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i8CDwvHA055686; Sun, 12 Sep 2004 17:58:59 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4144561C.4010401@mcsi.pp.ru> Date: Sun, 12 Sep 2004 17:58:52 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040907 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Julian Elischer References: <4143EF29.2080404@elischer.org> In-Reply-To: <4143EF29.2080404@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: current@freebsd.org Subject: Re: [Patch] panics/hangs with preemption and threads. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 13:59:19 -0000 Julian Elischer wrote: > Guys I think I found a (the?) major cause for the corruptions of the > ksegrp/thread runqueue for threaded processes when Premption is turned on.. Mozilla didn't lock the system up for an hour of hard work with IMAP! That's pretty amazing I'd say. Without this patch it caused hard freeze in 1-5 minutes. I'm using sched_4bsd and HTT ATM. Thanks for finding this bug! Now I'm sure we will have stable 5.3-RELEASE in time. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:03:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4052A16A4CE; Sun, 12 Sep 2004 14:03:26 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D31B43D2D; Sun, 12 Sep 2004 14:03:25 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 643C83B94D; Sun, 12 Sep 2004 16:03:24 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) i8CE3BNc066953; Sun, 12 Sep 2004 16:03:11 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.1/8.13.1/Submit) id i8CE3B2A066952; Sun, 12 Sep 2004 16:03:11 +0200 (CEST) (envelope-from schweikh) Date: Sun, 12 Sep 2004 16:03:11 +0200 From: Jens Schweikhardt To: Kris Kennaway Message-ID: <20040912140311.GA60265@schweikhardt.net> References: <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> <20040912112411.GA62181@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912112411.GA62181@schweikhardt.net> User-Agent: Mutt/1.5.6i cc: Maxim Sobolev cc: Roman Kurakin cc: Ruslan Ermilov cc: current@FreeBSD.ORG cc: portmgr@FreeBSD.ORG Subject: Re: ccache support for make buildworld/make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:03:26 -0000 Following up myself, On Sun, Sep 12, 2004 at 01:24:11PM +0200, Jens Schweikhardt wrote: # On Wed, Aug 25, 2004 at 11:33:42AM -0700, Kris Kennaway wrote: # ... # # BTW, I don't think there's anything to set up..you just set # # CC="ccache cc" or similar. I've investigated further and found that the cc which is used after bootstrapping uses a different start for include path search, e.g. /usr/bin/cc -v ... #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. /usr/obj/share/HEAD/src/i386/usr/bin/cc -v ... #include "..." search starts here: #include <...> search starts here: /usr/obj/share/HEAD/src/i386/usr/include End of search list. This is why the includes are not found when ccache is forced to use /usr/bin/cc. Which somewhat defeats the purpose of ccache: if the build switches compilers, ccache only speeds up the bootstrapping up to that point. Unfortunately, ccache also hashes the compiler's modification timestamp, so each time a new cc is used in the build, this effectively means no more cache hits for all previous compiled files. Hmm. Maybe I could hack ccache to make it ignore the modification timestamp... Hmmm. Room for foot shooting... Hmmm. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:09:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0789A16A4CE; Sun, 12 Sep 2004 14:09:54 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B4643D67; Sun, 12 Sep 2004 14:09:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8CE9rKF013814; Sun, 12 Sep 2004 10:09:53 -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.12.11/8.12.11) with ESMTP id i8CE9qVk020042; Sun, 12 Sep 2004 10:09:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F225B7303F; Sun, 12 Sep 2004 10:09:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040912140952.F225B7303F@freebsd-current.sentex.ca> Date: Sun, 12 Sep 2004 10:09:52 -0400 (EDT) Subject: [releng_5 tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 14:09:54 -0000 TB --- 2004-09-12 13:09:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-12 13:09:09 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2004-09-12 13:09:09 - checking out the source tree TB --- 2004-09-12 13:09:09 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2004-09-12 13:09:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-12 13:16:46 - building world (CFLAGS=-O -pipe) TB --- 2004-09-12 13:16:46 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-12 13:16:46 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-12 14:05:13 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-12 14:05:13 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-12 14:05:13 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Sep 12 14:05:13 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x15a8): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x1668): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x16ec): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text3+0x0): additional relocation overflows omitted from the output *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2004-09-12 14:09:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-12 14:09:52 - ERROR: failed to build generic kernel TB --- 2004-09-12 14:09:52 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 17:05:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBFFB16A4CE; Sat, 11 Sep 2004 17:05:47 +0000 (GMT) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C07343D45; Sat, 11 Sep 2004 17:05:47 +0000 (GMT) (envelope-from gerald@pfeifer.com) Received: from [128.131.111.60] (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 50DC6137D0; Sat, 11 Sep 2004 19:05:44 +0200 (CEST) Date: Sat, 11 Sep 2004 19:05:48 +0200 (CEST) From: Gerald Pfeifer To: Anish Mistry In-Reply-To: <200409060149.35764.mistry.7@osu.edu> Message-ID: References: <47158390.20040827112834@ulstu.ru> <200409060149.35764.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 12 Sep 2004 14:21:58 +0000 cc: Alan Cox cc: anvir@ulstu.ru cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Sep 2004 17:05:48 -0000 On Mon, 6 Sep 2004, Anish Mistry wrote: > Well I guess this is my lucky day. Apply the attached patch for vm_mmap to > your kernel and patch the August wine sources with the wine-mmap.patch and > compile and install wine (be sure to use gmake). This is working on my dev > system with 6-CURRENT as of Saturday night. I currently do not have a 6-CURRENT (or recent 5-STABLE) machine available, and we probably can't require users of our wine port to patch their kernel, so we'd really need to see that in a stock kernel. Is there any chance someone could review/apply that patch= > The wine mmap patch just doesn't reserve the DOS area so DOS programs may not > work. This seems to just work around a side effect of the kernel mmap patch. This i can get into Wine quite easily. > I still think that the kernel mmap patch has issues so I'm hoping Alan > can give us some feedback. Alan? > Anyway this worked for me, YMMV. Thanks a lot! Gerald From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 01:38:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 117D616A4CE for ; Sun, 12 Sep 2004 01:38:48 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB7E043D58 for ; Sun, 12 Sep 2004 01:38:46 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 81383 invoked from network); 12 Sep 2004 01:38:46 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.111.39]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 12 Sep 2004 01:38:46 -0000 Message-ID: <4143A797.4040708@authtec.net> Date: Sun, 12 Sep 2004 09:34:15 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Sep 2004 14:21:58 +0000 Subject: How can I compile PF without option PFIL_HOOKS defined in thekernel conf file? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 01:38:49 -0000 Hi, I tried many times, turning on and off the option PFIL_HOOKS in the kernel conf file to try to get PF compile into the kernel, but without success. When remove option PFIL_HOOKS, PF failed to compile. Here is the error when compiling PF into kernel without PFIL_HOOKS: pf_ioctl.o(.text+0x5230): In function `hook_pf': : undefined reference to `pfil_head_get' pf_ioctl.o(.text+0x5251): In function `hook_pf': : undefined reference to `pfil_add_hook' pf_ioctl.o(.text+0x5260): In function `hook_pf': : undefined reference to `pfil_add_hook' pf_ioctl.o(.text+0x526c): In function `hook_pf': : undefined reference to `pfil_head_get' pf_ioctl.o(.text+0x5284): In function `hook_pf': : undefined reference to `pfil_remove_hook' pf_ioctl.o(.text+0x5293): In function `hook_pf': : undefined reference to `pfil_remove_hook' pf_ioctl.o(.text+0x52ab): In function `hook_pf': : undefined reference to `pfil_add_hook' pf_ioctl.o(.text+0x52ba): In function `hook_pf': : undefined reference to `pfil_add_hook' pf_ioctl.o(.text+0x52f3): In function `dehook_pf': : undefined reference to `pfil_head_get' pf_ioctl.o(.text+0x5310): In function `dehook_pf': : undefined reference to `pfil_remove_hook' pf_ioctl.o(.text+0x531f): In function `dehook_pf': : undefined reference to `pfil_remove_hook' pf_ioctl.o(.text+0x532b): In function `dehook_pf': : undefined reference to `pfil_head_get' pf_ioctl.o(.text+0x5348): In function `dehook_pf': : undefined reference to `pfil_remove_hook' pf_ioctl.o(.text+0x5357): In function `dehook_pf': : undefined reference to `pfil_remove_hook' *** Error code 1 With option PFIL_HOOKS, the compilation failed with the following error (this time PF is compiled OK, but the system does not like it: config -d /usr/obj/usr/src/sys/GENERIC /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/GENERIC: unknown option "PFIL_HOOKS" Does anyone have any suggestion to compile PF into kernel in Beta 3? Thanks sam -- Security Architect/Consultant AuthTec Gateway Limited Mobile: 9839 2464 Email: sam.wun@authtec.net Website: http://www.authtec.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 07:34:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE3CB16A4CE for ; Sun, 12 Sep 2004 07:34:54 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id D872C43D41 for ; Sun, 12 Sep 2004 07:34:53 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 3619 invoked from network); 12 Sep 2004 07:34:52 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.111.39]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 12 Sep 2004 07:34:52 -0000 Message-ID: <4143FB0C.7080400@authtec.net> Date: Sun, 12 Sep 2004 15:30:20 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Sep 2004 14:21:58 +0000 Subject: How to download cvs files for Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 07:34:54 -0000 Hi, I found a tag for downloading the 5.3 Current (not 6.0) with the following cvsup-sup file definition: *default host=cvsup.ca.freebsd.org *default base=/usr *default prefix=/bdata/ncvs *default release=cvs tag=RELENG_5 *default delete use-rel-suffix but this is only download the source. How can I download the cvs file? those files ended with ",v". I need to use it to execute "make release ..." Thanks sam From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 08:46:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3984916A4CE; Sun, 12 Sep 2004 08:46:13 +0000 (GMT) Received: from clever.eusc.inter.net (clever.eusc.inter.net [213.73.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E3D43D5A; Sun, 12 Sep 2004 08:46:12 +0000 (GMT) (envelope-from msch@snafu.de) Received: from dial-76-045.de.inter.net ([213.73.76.45] helo=current.best-eng.de) by clever.eusc.inter.net with esmtp (Exim 3.36 #4) id 1C6Pzt-0000Wt-00; Sun, 12 Sep 2004 10:46:10 +0200 Received: from current.best-eng.de (localhost.best-eng.de [127.0.0.1]) by current.best-eng.de (8.13.1/8.13.1) with ESMTP id i8C8k8qi054688; Sun, 12 Sep 2004 10:46:09 +0200 (CEST) (envelope-from matthias@current.best-eng.de) Received: from localhost (localhost [[UNIX: localhost]]) by current.best-eng.de (8.13.1/8.13.1/Submit) id i8C8k31V054450; Sun, 12 Sep 2004 10:46:03 +0200 (CEST) (envelope-from matthias) From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: freebsd-current@freebsd.org Date: Sun, 12 Sep 2004 10:46:02 +0200 User-Agent: KMail/1.6.2 References: <200408141854.38477.msch@snafu.de> <200408211927.36948.msch@snafu.de> In-Reply-To: <200408211927.36948.msch@snafu.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200409121046.02724.msch@snafu.de> X-Mailman-Approved-At: Sun, 12 Sep 2004 14:21:58 +0000 cc: njl@freebsd.org cc: andre@freebsd.org Subject: Re: ISDN4BSD broken... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.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, 12 Sep 2004 08:46:13 -0000 Hello all, there's still no change - ISDN4BSD still does not work with my TELES S0 16.3 ISA-Card (no PnP). I tried with 6-CURRENT from Sep 10, which has the new commits for ISDN4BSD from andre@freebsd.org, but this did not change anything. (thanks for the hint, Gary!) The last working Version is from Aug 11, 14:00 UTC - at 16:00 UTC it's broken. The kernel files which changed in between are: src/sys/dev/acpica/acpi_pci_link.c (-> 1.19) src/sys/dev/acpica/acpi_pcib.c (-> 1.47) src/sys/dev/acpica/acpi_pcib_acpi.c (-> 1.39) src/sys/dev/acpica/acpi_pcib_pci.c (-> 1.10) src/sys/dev/acpica/acpi_pcibvar.h (-> 1.3) That's all I can do for now - if additional informations are required, please contact me and tell me how to retrieve them... Ciao/BSD - Matthias On Saturday 21 August 2004 19:27, Matthias Schuendehuette wrote: > Hi, > > there's still no change with 5.3-BETA1 :-( > > On Saturday 14 August 2004 18:54, Matthias Schuendehuette wrote: > > Hi all, > > > > I just rebooted into the new cuurent-kernel and found, that i4b > > isn't working any more. Last working kernel was of Aug 11, around > > 1800 UTC. > > > > Aug 14 18:19:46 current kernel: FreeBSD 5.2-CURRENT #0: \ > > Sat Aug 14 17:43:56 CEST 2004 > > [...] > > Aug 14 18:19:46 current kernel: ACPI link \_SB_.PCI0.LNKA \ > > has invalid initial irq 9, ignoring > > (this is a new message, which doesn't show up with my Aug 11 > > kernel) [...] > > Aug 14 18:19:46 current kernel: isic0: [GIANT-LOCKED] > > Aug 14 18:19:46 current kernel: isic0 at port \ > > 0x580-0x59f,0x180-0x19f,0x980-0x99f,0xd80-0xd9f \ > > irq 10 flags 0x3 on isa0 > > Aug 14 18:19:46 current kernel: isic0: passive stack unit 0 > > Aug 14 18:19:46 current kernel: isic0: Teles S0/16.3 > > [...] > > Aug 14 18:19:46 current kernel: i4bisppp: \ > > 2 ISDN SyncPPP device(s) attached > > Aug 14 18:19:46 current kernel: i4b: \ > > ISDN call control device attached > > Aug 14 18:19:46 current kernel: i4btrc: \ > > 1 ISDN trace device(s) attached > > Aug 14 18:19:46 current kernel: i4brbch: \ > > 2 raw B channel access device(s) attached > > Aug 14 18:19:46 current kernel: i4btel: \ > > 2 ISDN telephony interface device(s) attached > > Aug 14 18:19:46 current kernel: i4bipr: \ > > 2 IP over raw HDLC ISDN device(s) attached (VJ header compression) > > Aug 14 18:19:46 current kernel: i4bctl: \ > > ISDN system control port attached > > > > So far, the ISDN-Card is detected and attached as usual, but if I > > try to dial out, the following messages were recorded: > > > > Aug 14 18:22:25 current kernel: i4b-L1 timer3_expired: \ > > state = F4 Awaiting Signal > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > HSCX B: ISTA = 0x0 > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > ISAC: ISTA = 0x94 > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > ISAC: CISQ = 0x1e > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > HSCX B: IMASK = 0xff > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > HSCX A: IMASK = 0xf8 > > Aug 14 18:22:25 current kernel: i4b-L1 isic_recover: \ > > ISAC: IMASK = 0x2a > > Aug 14 18:22:25 current kernel: i4b-L2 i4b_T202_timeout: \ > > unit 0, N202 = 3 > > Aug 14 18:22:25 current kernel: i4b-L1 isic_ph_data_req: \ > > still in state F3! > > Aug 14 18:22:27 current kernel: i4b-L3 T303_timeout: \ > > SETUP not answered, cr = 15 > > Aug 14 18:22:27 current kernel: i4b-L3 next_l3state: \ > > FSM illegal state, state = ST_OW - Out Wait EST, \ > > event = EV_T303EXP - T303 timeout! > > Aug 14 18:22:27 current kernel: i4b-L1 timer3_expired: \ > > state = F4 Awaiting Signal > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > HSCX B: ISTA = 0x0 > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > ISAC: ISTA = 0x4 > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > ISAC: CISQ = 0x32 > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > HSCX B: IMASK = 0xff > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > HSCX A: IMASK = 0xf8 > > Aug 14 18:22:27 current kernel: i4b-L1 isic_recover: \ > > ISAC: IMASK = 0x2a > > > > Any ideas? ACPI or IRQ-Routing related? -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:30:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08ED716A4CE for ; Sun, 12 Sep 2004 14:30:39 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D71843D31 for ; Sun, 12 Sep 2004 14:30:37 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.37.120] (ppp2578.dyn.pacific.net.au [61.8.37.120]) i8CETg23013175; Mon, 13 Sep 2004 00:29:43 +1000 From: Sam Lawrance To: Dan Nelson In-Reply-To: <20040831151437.GE33896@dan.emsphone.com> References: <1093948080.29903.14.camel@localhost> <20040831151437.GE33896@dan.emsphone.com> Content-Type: text/plain Message-Id: <1094999545.78235.12.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 00:32:26 +1000 Content-Transfer-Encoding: 7bit cc: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: sysutils/strace wilderness on 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:30:39 -0000 On Wed, 2004-09-01 at 01:14, Dan Nelson wrote: > In the last episode (Aug 31), Vladimir Grebenschikov said: > > (fresh -CURREMT and fresh strace from ports, UP machine) > > > > It silmple does nothing - sleeps foreaver in suspended: > > > > # strace /bin/ls > > ^T > > load: 0.14 cmd: strace 98957 [suspended] 0.00u 0.00s 0% 760k > > ^C > > # > > This has happened on 5.x for ages. The quick fix is to ^Z, then fg, or > kill -CONT the hung strace process from another vty. I don't know what > strace does different from truss that makes it hang. Nowadays, truss > does almost as good a job as strace, so I don't use it as often as I > used to. The only thing I miss is strace's ability to print the name > of blocking syscalls (read or sleep for example) as it waits. When I do "truss -f make install" on a port (I used palm/synce-serial), the process being traced seems to hang (^T shows [stopevent], I haven't looked further than that). If I run without -f, the process doesn't hang. It looks like the process is hanging at a call to vfork(). Maybe it's not just an strace problem? -Sam From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:31:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9032F16A4EB for ; Sun, 12 Sep 2004 14:31:57 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A79943D54 for ; Sun, 12 Sep 2004 14:31:57 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8CEWgsL025287; Sun, 12 Sep 2004 08:32:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <41445D27.3010103@samsco.org> Date: Sun, 12 Sep 2004 08:28:55 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sam References: <4143FB0C.7080400@authtec.net> In-Reply-To: <4143FB0C.7080400@authtec.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: How to download cvs files for Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:31:57 -0000 sam wrote: > Hi, > > I found a tag for downloading the 5.3 Current (not 6.0) with the > following cvsup-sup file definition: > > *default host=cvsup.ca.freebsd.org > *default base=/usr > *default prefix=/bdata/ncvs > *default release=cvs tag=RELENG_5 > *default delete use-rel-suffix > > but this is only download the source. How can I download the cvs file? > those files ended with ",v". I need to use it to execute "make release ..." > > Thanks > sam Remove the 'tag=RELENG_5' part completely. You will then get a copy of the entire repository that covers all branches, not just RELENG_5. Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:34:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE37816A4CF for ; Sun, 12 Sep 2004 14:34:59 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A9243D2F for ; Sun, 12 Sep 2004 14:34:59 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C6VRS-0004R7-00; Sun, 12 Sep 2004 16:34:58 +0200 Received: from [217.83.3.80] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C6VRR-0007Yc-00; Sun, 12 Sep 2004 16:34:57 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Sun, 12 Sep 2004 16:33:35 +0200 User-Agent: KMail/1.6.2 References: <4143A797.4040708@authtec.net> In-Reply-To: <4143A797.4040708@authtec.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_L5FRBlsBIYWdk1j"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409121633.47109.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: pf4freebsd@freelists.org cc: sam Subject: Re: How can I compile PF without option PFIL_HOOKS defined in thekernel conf file? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:34:59 -0000 --Boundary-02=_L5FRBlsBIYWdk1j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 12 September 2004 03:34, sam wrote: > Hi, > > I tried many times, turning on and off the option PFIL_HOOKS in the > kernel conf file to try to get PF compile into the kernel, but without > success. > > When remove option PFIL_HOOKS, PF failed to compile. Here is the error > when compiling PF into kernel without PFIL_HOOKS: > > pf_ioctl.o(.text+0x5230): In function `hook_pf': > : undefined reference to `pfil_head_get' > *** Error code 1 > > With option PFIL_HOOKS, the compilation failed with the following error > (this time PF is compiled OK, but the system does not like it: > > config -d /usr/obj/usr/src/sys/GENERIC /usr/src/sys/i386/conf/GENERIC > /usr/src/sys/i386/conf/GENERIC: unknown option "PFIL_HOOKS" > > Does anyone have any suggestion to compile PF into kernel in Beta 3? Hmmm ... looks like a bad cvsup to me. Please cvsup to RELENG_5 once more a= nd=20 try again. RELENG_5 still has "options PFIL_HOOKS" available so it seems like you have= =20 CURRENT-ish sys/conf/* stuff in your tree which does not know about=20 PFIL_HOOKS. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_L5FRBlsBIYWdk1j Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBRF5LXyyEoT62BG0RAnP5AJ9DS3wj/MeuvN1yESJ0nlzxYaKi4gCdFGnJ YMrBqXrfWsD2BE/8yqA1hKY= =1VEP -----END PGP SIGNATURE----- --Boundary-02=_L5FRBlsBIYWdk1j-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:49:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E44C16A4CE for ; Sun, 12 Sep 2004 14:49:40 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E3B443D54 for ; Sun, 12 Sep 2004 14:49:40 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8CEnSht052394; Sun, 12 Sep 2004 10:49:28 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8CEnSo2052391; Sun, 12 Sep 2004 10:49:28 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 10:49:28 -0400 (EDT) From: Andre Guibert de Bruet To: sam In-Reply-To: <4140FF73.7090800@authtec.net> Message-ID: <20040912104104.R84468@alpha.siliconlandmark.com> References: <4140FF73.7090800@authtec.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: freebsd-current@freebsd.org Subject: Re: Current crash with db prompt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:49:40 -0000 On Fri, 10 Sep 2004, sam wrote: > After updated the source dated as (09-09-2004), and finished make buildworkd, > and installkernel, the system crashed into a db> prompt. > Does anyone had this problem? should I download the source again? I m not > sure whether I download the source in a bad time or not.. Getting to the db> prompt isn't of interest, it is the messages that are printed at the console right before you are dropped to the kernel debugger that we are after. They usually give a pretty good idea of what went wrong. Downloading fresher sources may or may not resolve your problem, depending upon whether the bug was caught and fixed or masked by another commit. In the future, please attach the panic string along with any messages printed at panic time with your bug report. You might be interested in setting up a serial console to capture these messages without writing everything down manually. There's a detailed section in the handbook on how to do this. Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:50:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 680FE16A4CE for ; Sun, 12 Sep 2004 14:50:43 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3EAB43D3F for ; Sun, 12 Sep 2004 14:50:40 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8CEoZDH027963; Sun, 12 Sep 2004 10:50:36 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8CEoWSB027962; Sun, 12 Sep 2004 10:50:32 -0400 (EDT) (envelope-from green) Date: Sun, 12 Sep 2004 10:50:32 -0400 From: Brian Fundakowski Feldman To: Anish Mistry Message-ID: <20040912145032.GZ928@green.homeunix.org> References: <47158390.20040827112834@ulstu.ru> <200409111707.25937.mistry.7@osu.edu> <20040911212604.GY928@green.homeunix.org> <200409111955.13663.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409111955.13663.mistry.7@osu.edu> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:50:43 -0000 On Sat, Sep 11, 2004 at 07:54:55PM -0400, Anish Mistry wrote: > On Saturday 11 September 2004 05:26 pm, you wrote: > > On Sat, Sep 11, 2004 at 05:07:13PM -0400, Anish Mistry wrote: > > > On Saturday 11 September 2004 02:00 pm, you wrote: > > > > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > > > > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > > > > > [ John, sorry for the duplicate message; this is the correct one. ] > > > > > > > > > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > > > > > Anish Mistry has developed a patch to choose > > > > > > > an appropriate mmap address. He posted it to -current. I haven't > > > > > > > had time to test it. > > > > > > > > > > > > Thanks for the note. Will you have time to test/commit this before > > > > > > 5.3? > > > > > > > > > > > > Anish, do you have any news on this patch? (Wine has been broken > > > > > > for a couple of months now, and it would be great to have at least > > > > > > 5.3 fixed.) > > > > > > > > > > Well I guess this is my lucky day. Apply the attached patch for > > > > > vm_mmap to your kernel and patch the August wine sources with the > > > > > wine-mmap.patch and compile and install wine (be sure to use gmake). > > > > > This is working on my dev system with 6-CURRENT as of Saturday night. > > > > > The wine mmap patch just doesn't reserve the DOS area so DOS programs > > > > > may not work. This seems to just work around a side effect of the > > > > > kernel mmap patch. I still think that the kernel mmap patch has > > > > > issues so I'm hoping Alan can give us some feedback. > > > > > Anyway this worked for me, YMMV. > > > > > > > > Do these combined work for you, minus any modifications to mmap(2)? I > > > > do not feel that the kernel mmap(2) should be modified in this manner, > > > > that it is a strictly userland problem. > > > > > > With only these applied I get old message that wine can't mmap it's > > > address space. > > > > Oh, I'm sorry for not explaining the last step. You need to set the > > environment variable "LD_LIBRARY_LOW_ADDR" to some address, like after > > the first megabyte, or something like that, but before the first "data" > > address. Try, say, 1024000. > Ok, I've tried that, with several different numbers and I either get something > like: > wine: failed to initialize: /usr/local/lib/libwine_unicode.so.1: mmap returned > wrong address: wanted 0xc350000, got 0xc3bd000 > or just the normal: > wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: mmap of entire > address space failed: Cannot allocate memory > > Any other suggestions? Oops, can you try this instead? Can you share with me exactly how you run this "regression test" with WINE (what program, what .wine/config)? cvs diff: Diffing . Index: map_object.c =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/map_object.c,v retrieving revision 1.15 diff -u -r1.15 map_object.c --- map_object.c 3 Aug 2004 08:50:58 -0000 1.15 +++ map_object.c 12 Sep 2004 14:49:16 -0000 @@ -46,12 +46,15 @@ * Map a shared object into memory. The "fd" argument is a file descriptor, * which must be open on the object and positioned at its beginning. * The "path" argument is a pathname that is used only for error messages. + * The "low_addr" argument allows for addresses below the normal data + * area start to be used for mapping if no space is available above. * * The return value is a pointer to a newly-allocated Obj_Entry structure * for the shared object. Returns NULL on failure. */ Obj_Entry * -map_object(int fd, const char *path, const struct stat *sb) +map_object(int fd, const char *path, const struct stat *sb, + unsigned long low_addr) { Obj_Entry *obj; Elf_Ehdr *hdr; @@ -152,6 +155,14 @@ mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), convert_flags(segs[0]->p_flags), fd, base_offset); + /* + * If requested and out of space for the library, try again below + * the normal minimum data segment address. + */ + if (mapbase == (caddr_t) -1 && base_addr == NULL && low_addr != 0) + mapbase = mmap((caddr_t) low_addr, mapsize, + convert_prot(segs[0]->p_flags), convert_flags(segs[0]->p_flags), + fd, base_offset); if (mapbase == (caddr_t) -1) { _rtld_error("%s: mmap of entire address space failed: %s", path, strerror(errno)); Index: rtld.c =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/rtld.c,v retrieving revision 1.99 diff -u -r1.99 rtld.c --- rtld.c 4 Aug 2004 19:12:14 -0000 1.99 +++ rtld.c 11 Sep 2004 17:51:00 -0000 @@ -143,6 +143,9 @@ static char *ld_library_path; /* Environment variable for search path */ static char *ld_preload; /* Environment variable for libraries to load first */ +static unsigned long ld_library_low_addr; /* Environment variable for + alternate data area to + try to map into */ static char *ld_tracing; /* Called from ldd to print libs */ static Obj_Entry *obj_list; /* Head of linked list of shared objects */ static Obj_Entry **obj_tail; /* Link field of last object in list */ @@ -287,6 +290,14 @@ ld_bind_now = getenv(LD_ "BIND_NOW"); if (trust) { + const char *env_low_addr = getenv(LD_ "LIBRARY_LOW_ADDR"); + if (env_low_addr != NULL) { + char *low_addr_endptr = NULL; + errno = 0; + ld_library_low_addr = strtoul(env_low_addr, &low_addr_endptr, 0); + if (*low_addr_endptr != '\0' || errno != 0) + ld_library_low_addr = 0; + } ld_debug = getenv(LD_ "DEBUG"); libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL; ld_library_path = getenv(LD_ "LIBRARY_PATH"); @@ -308,7 +319,7 @@ if (aux_info[AT_EXECFD] != NULL) { /* Load the main program. */ int fd = aux_info[AT_EXECFD]->a_un.a_val; dbg("loading main program"); - obj_main = map_object(fd, argv0, NULL); + obj_main = map_object(fd, argv0, NULL, 0); close(fd); if (obj_main == NULL) die(); @@ -1249,7 +1260,7 @@ if (obj == NULL) { /* First use of this object, so we must map it in */ dbg("loading \"%s\"", path); - obj = map_object(fd, path, &sb); + obj = map_object(fd, path, &sb, ld_library_low_addr); close(fd); if (obj == NULL) { free(path); Index: rtld.h =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/rtld.h,v retrieving revision 1.34 diff -u -r1.34 rtld.h --- rtld.h 3 Aug 2004 08:50:58 -0000 1.34 +++ rtld.h 11 Sep 2004 17:41:45 -0000 @@ -209,7 +209,8 @@ } SymCache; extern void _rtld_error(const char *, ...) __printflike(1, 2); -extern Obj_Entry *map_object(int, const char *, const struct stat *); +extern Obj_Entry *map_object(int, const char *, const struct stat *, + unsigned long); extern void *xcalloc(size_t); extern void *xmalloc(size_t); extern char *xstrdup(const char *); cvs diff: Diffing alpha cvs diff: Diffing amd64 cvs diff: Diffing arm cvs diff: Diffing i386 cvs diff: Diffing ia64 cvs diff: Diffing powerpc cvs diff: Diffing sparc64 -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:34:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A5E516A4CE for ; Sun, 12 Sep 2004 14:34:54 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EE9443D48 for ; Sun, 12 Sep 2004 14:34:53 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 66258 invoked from network); 12 Sep 2004 14:34:51 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.111.39]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 12 Sep 2004 14:34:51 -0000 Message-ID: <41445D7A.6070008@authtec.net> Date: Sun, 12 Sep 2004 22:30:18 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <4143FB0C.7080400@authtec.net> <41445D27.3010103@samsco.org> In-Reply-To: <41445D27.3010103@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Sep 2004 14:53:03 +0000 Subject: Re: How to download cvs files for Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:34:54 -0000 Scott Long wrote: > sam wrote: > >> Hi, >> >> I found a tag for downloading the 5.3 Current (not 6.0) with the >> following cvsup-sup file definition: >> >> *default host=cvsup.ca.freebsd.org >> *default base=/usr >> *default prefix=/bdata/ncvs >> *default release=cvs tag=RELENG_5 >> *default delete use-rel-suffix >> >> but this is only download the source. How can I download the cvs >> file? those files ended with ",v". I need to use it to execute "make >> release ..." >> >> Thanks >> sam > > > Remove the 'tag=RELENG_5' part completely. You will then get a copy of > the entire repository that covers all branches, not just RELENG_5. > > Scott > > Thanks, I got it. After download the src, I used cvs src -r RELENG_5 src to extract 5.3 current instead of 6.0 by default. Thanks sam -- Security Architect/Consultant AuthTec Gateway Limited Mobile: 9839 2464 Email: sam.wun@authtec.net Website: http://www.authtec.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:56:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C7C16A4D1 for ; Sun, 12 Sep 2004 14:56:04 +0000 (GMT) Received: from www.cray1.de (i.would.like.to.spoof.my.realip.de [64.27.85.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A61043D1D for ; Sun, 12 Sep 2004 14:56:04 +0000 (GMT) (envelope-from ubm@u-boot-man.de) Received: from greatsheep.marines (localhost [127.0.0.1]) by www.cray1.de (8.9.3/8.9.3) with SMTP id QAA24746 for ; Sun, 12 Sep 2004 16:55:59 +0200 Date: Sun, 12 Sep 2004 16:59:12 +0200 From: Marc "UBM" Bocklet To: current@freebsd.org Message-Id: <20040912165912.6fab0176.ubm@u-boot-man.de> In-Reply-To: References: <20040911162825.418068e7.ubm@u-boot-man.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: two LORs with acx driver and 6-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:56:04 -0000 On Sat, 11 Sep 2004 21:31:12 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Sat, 11 Sep 2004, Marc UBM Bocklet wrote: > > > > > encountered the following two LORs in the process. This time I was > > intelligent enough to consult the LOR page first, but I did not find > > them listed there. > ... > > Teh LORs: > > > > http://www.u-boot-man.de/~mbocklet/lors.txt > > added as > http://sources.zabbadoz.net/freebsd/lor.html#036 > http://sources.zabbadoz.net/freebsd/lor.html#037 Thanks a lot! :-) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:57:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B77716A4CE; Sun, 12 Sep 2004 14:57:58 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D396443D3F; Sun, 12 Sep 2004 14:57:57 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8CEvjjH005062; Sun, 12 Sep 2004 10:57:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8CEvjIp005059; Sun, 12 Sep 2004 10:57:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 12 Sep 2004 10:57:45 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Guibert de Bruet In-Reply-To: <20040912025037.Y84468@alpha.siliconlandmark.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kris Kennaway cc: current@FreeBSD.ORG Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 14:57:58 -0000 On Sun, 12 Sep 2004, Andre Guibert de Bruet wrote: > On Sun, 12 Sep 2004, Kris Kennaway wrote: > > > On Sun, Sep 12, 2004 at 02:42:03AM -0400, Andre Guibert de Bruet wrote: > > > >>> I've also noticed data corruption in the form of failed CRCs (And hence > >>> dropped SSH connections) while transferring large amounts of data via SSH > >>> over gige to a machine on its subnet. These problems started occuring > >>> after the giant-less networking megacommit. Older kernels check out > >>> without any such issues. > > > > Does it go away if you turn off debug.mpsafenet? If not, it's > > probably not related to that commit. > > Setting debug.mpsafenet to 0 allows the SSH transfers to complete. The > MD5 checksums and sizes match. Where do we go from here? I think I'd look at the following next: - Does your network interface driver support checksum offload? If so, what happens if you disable that? - Is the network interface driver marked as INTR_MPSAFE and/or not IFF_NEEDSGIANT. If either, try setting the driver to run with Giant by removing INTR_MPSAFE and adding IFF_NEEDSGIANT. After that I think we want to try and produce a non-SSH reproduction scenario using a very simple test program... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:02:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF19F16A4CE for ; Sun, 12 Sep 2004 15:02:21 +0000 (GMT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE28D43D2D for ; Sun, 12 Sep 2004 15:02:20 +0000 (GMT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1])i8CF2J848383 for ; Mon, 13 Sep 2004 00:02:19 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-User-Agent: Mew/1.94.2 Emacs/21.3 X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20040704(IM147) Lines: 31 From: Makoto Matsushita To: current@FreeBSD.org Date: Mon, 13 Sep 2004 00:02:16 +0900 Message-Id: <20040913000216E.matusita@jp.FreeBSD.org> Subject: Recent 6.0-CURRENT and VMware 4.2.1: boot problem with PREEMPTION enabled kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 15:02:22 -0000 I've just found that my VMware Workstation virtual machine doesn't boot as expected with recent 6.0-CURRENT kernel. For example, with 6.0-CURRENT-20040912-JPSNAP boot floppies, following three lines are the last message, and stops VM forever: md0: Preloaded image 4423680 bytes at 0xc0a33764 acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% pid 24: corrected slot count (0->1) I've tried to boot with the floppies "boot -v", and got: ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 ata0: resetting done .. pid 24: corrected slot count (0->1) ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=50 ostat1=50 (... and stops) After some try-and-error challenge, it seems that this occurs if PREEMPTION kernel option is enabled (note that SCHD_4BSD is used). In anyway, anybody have experienced this problem? I'm afraid that next 5.3 beta (it'll be 5.3-BETA4) have the same problem. -- - Makoto `MAR' Matsushita From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:08:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF58116A4CE for ; Sun, 12 Sep 2004 15:08:34 +0000 (GMT) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3FE243D2F for ; Sun, 12 Sep 2004 15:08:33 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 51966 invoked by uid 1005); 12 Sep 2004 15:01:51 -0000 Received: from rainer@ultra-secure.de by bsd.ultra-secure.de by uid 89 with qmail-scanner-1.22 (clamdscan: 0.75.1. spamassassin: 2.64. Clear:RC:1(84.128.77.204):. Processed in 0.670393 secs); 12 Sep 2004 15:01:51 -0000 Received: from unknown (HELO ?192.168.1.225?) (rainer@ultra-secure.de@84.128.77.204) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Sep 2004 15:01:50 -0000 From: Rainer Duffner To: sam In-Reply-To: <41445D7A.6070008@authtec.net> References: <4143FB0C.7080400@authtec.net> <41445D27.3010103@samsco.org> <41445D7A.6070008@authtec.net> Content-Type: text/plain Message-Id: <1095001292.4812.2.camel@linux-mobile.example.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 12 Sep 2004 17:01:33 +0200 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: How to download cvs files for Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 15:08:34 -0000 Am So, den 12.09.2004 schrieb sam um 16:30: > Thanks, I got it. After download the src, I used cvs src -r RELENG_5 src There's always /usr/ports/net/cvsup-mirror if you want to have a permanent, private, complete cvsup-mirror. Rainer -- =================================================== ~ Rainer Duffner - rainer@ultra-secure.de ~ ~ Freising - Munich - Germany ~ ~ Unix - Linux - BSD - OpenSource - Security ~ ~ http://www.ultra-secure.de/~rainer/pubkey.pgp ~ =================================================== From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:25:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9818F16A4CE; Sun, 12 Sep 2004 16:25:54 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D0E843D5D; Sun, 12 Sep 2004 16:25:54 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8CGPoN1052900; Sun, 12 Sep 2004 12:25:50 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8CGPnb3052897; Sun, 12 Sep 2004 12:25:49 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 12:25:49 -0400 (EDT) From: Andre Guibert de Bruet To: Robert Watson In-Reply-To: Message-ID: <20040912110720.D84468@alpha.siliconlandmark.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@FreeBSD.ORG Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 16:25:54 -0000 On Sun, 12 Sep 2004, Robert Watson wrote: > On Sun, 12 Sep 2004, Andre Guibert de Bruet wrote: >> On Sun, 12 Sep 2004, Kris Kennaway wrote: >>> On Sun, Sep 12, 2004 at 02:42:03AM -0400, Andre Guibert de Bruet wrote: >>> >>>>> I've also noticed data corruption in the form of failed CRCs (And hence >>>>> dropped SSH connections) while transferring large amounts of data via SSH >>>>> over gige to a machine on its subnet. These problems started occuring >>>>> after the giant-less networking megacommit. Older kernels check out >>>>> without any such issues. >>> >>> Does it go away if you turn off debug.mpsafenet? If not, it's >>> probably not related to that commit. >> >> Setting debug.mpsafenet to 0 allows the SSH transfers to complete. The >> MD5 checksums and sizes match. Where do we go from here? > > I think I'd look at the following next: > > - Does your network interface driver support checksum offload? If so, > what happens if you disable that? It appears that it does, based on the options field reported by ifconfig: nge0: flags=108843 mtu 1500 options=13 I can still reproduce the problem after passing -rxcsum and -txcsum while bringing the interface up. > - Is the network interface driver marked as INTR_MPSAFE and/or not > IFF_NEEDSGIANT. If either, try setting the driver to run with Giant by > removing INTR_MPSAFE and adding IFF_NEEDSGIANT. dev/nge/if_nge.c has the interface marked as IFF_NEEDSGIANT, with no trace of INTR_MPSAFE. My dmesg confirms this: "nge0: [GIANT-LOCKED]" > After that I think we want to try and produce a non-SSH reproduction > scenario using a very simple test program... Attempting to bring a local FreeBSD repo up-to-date causes the issue to manifest itself. If portupgrade is run and execs a fetch for a large tarball from a fast mirror (100KB/s+), the problem manifests itself as well. I cannot yet make any conclusive determination, but preliminary pattern analysis seems to indicate that large bursts of network traffic on this gige interface aid the reproduction of this condition. The machine in question acts as a dns resolver for my small home network and appears to handle light amounts of traffic without any issues. Thanks for the help, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 17:07:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 433F216A4CE; Sun, 12 Sep 2004 17:07:37 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6CA443D55; Sun, 12 Sep 2004 17:07:36 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8CH7ZiF053113; Sun, 12 Sep 2004 13:07:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8CH7ZCm053110; Sun, 12 Sep 2004 13:07:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 12 Sep 2004 13:07:35 -0400 (EDT) From: Andre Guibert de Bruet To: Robert Watson In-Reply-To: <20040912110720.D84468@alpha.siliconlandmark.com> Message-ID: <20040912130336.R84468@alpha.siliconlandmark.com> References: <20040912110720.D84468@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 17:07:37 -0000 Robert, Using an rl-based network card, I am able to transfer data without any problems. Any idea who the nge maintainer is? Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 17:36:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E4F616A4CE; Sun, 12 Sep 2004 17:36:35 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99C8743D41; Sun, 12 Sep 2004 17:36:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-188.dsl.snfc21.pacbell.net [216.100.132.188])i8CHaV3d261640; Sun, 12 Sep 2004 13:36:32 -0400 Message-ID: <4144891F.2070308@elischer.org> Date: Sun, 12 Sep 2004 10:36:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: rnejdl@ringofsaturn.com References: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> <20040912051028.GA74510@hub.freebsd.org> <62869.66.13.175.242.1094996122.squirrel@mail.ringofsaturn.com> In-Reply-To: <62869.66.13.175.242.1094996122.squirrel@mail.ringofsaturn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 17:36:35 -0000 Rusty Nejdl wrote: > Kris Kennaway said: > > >>ULE has known problems, that's why 4BSD was made default again. Retry >>with 4BSD and let us know whether or not the problems persist. >> >>Kris > > > Kris, > > This does indeed work. However, I wasn't having problems with ULE until > some change was committed in the last week caused this problem for me. > The only significant breakage I found so far with ULE was when I had > hyperthreading enabled. We aren't saying that we won't fix ULE.. just that to get you going we suggest 4BSD for now and we'll get back to ULE when we figure it out :-) > > Rusty Nejdl > > > _______________________________________________ > 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 Sun Sep 12 17:43:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30B5116A4CE for ; Sun, 12 Sep 2004 17:43:23 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5AC343D2D for ; Sun, 12 Sep 2004 17:43:22 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i8CHhKe5036569; Sun, 12 Sep 2004 12:43:20 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Sun, 12 Sep 2004 12:43:20 -0500 (CDT) Message-ID: <59222.66.13.175.242.1095011000.squirrel@mail.ringofsaturn.com> In-Reply-To: <4144891F.2070308@elischer.org> References: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> <20040912051028.GA74510@hub.freebsd.org> <62869.66.13.175.242.1094996122.squirrel@mail.ringofsaturn.com> <4144891F.2070308@elischer.org> Date: Sun, 12 Sep 2004 12:43:20 -0500 (CDT) From: "Rusty Nejdl" To: "Julian Elischer" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tethys.ringofsaturn.com X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.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, 12 Sep 2004 17:43:23 -0000 >> >> This does indeed work. However, I wasn't having problems with ULE >> until some change was committed in the last week caused this problem for >> me. The only significant breakage I found so far with ULE was when I had >> hyperthreading enabled. > > We aren't saying that we won't fix ULE.. just that to get you going > we suggest 4BSD for now and we'll get back to ULE when we figure it out > :-) > > Julian and Kris, Thanks! I was just trying to help narrow down something that was introduced that caused problems. I'm using 4BSD now and all is good. Rusty From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 17:43:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD07A16A4D2; Sun, 12 Sep 2004 17:43:28 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D102143D2D; Sun, 12 Sep 2004 17:43:27 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i8CHTSjr019061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 12 Sep 2004 13:29:29 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Brian Fundakowski Feldman Date: Sun, 12 Sep 2004 13:45:34 -0400 User-Agent: KMail/1.6.2 References: <47158390.20040827112834@ulstu.ru> <200409111955.13663.mistry.7@osu.edu> <20040912145032.GZ928@green.homeunix.org> In-Reply-To: <20040912145032.GZ928@green.homeunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_+sIRBuYt87PX2OZ" Message-Id: <200409121345.35186.mistry.7@osu.edu> X-Spam-Status: No, hits=3.0 required=5.0 tests=IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, USER_AGENT_KMAIL,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 17:43:29 -0000 --Boundary-00=_+sIRBuYt87PX2OZ Content-Type: multipart/signed; charset="iso-8859-1"; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_/sIRBctZakl5Vdz"; name=" " Content-Transfer-Encoding: 7bit --Boundary-02=_/sIRBctZakl5Vdz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 12 September 2004 10:50 am, you wrote: > On Sat, Sep 11, 2004 at 07:54:55PM -0400, Anish Mistry wrote: > > On Saturday 11 September 2004 05:26 pm, you wrote: > > > On Sat, Sep 11, 2004 at 05:07:13PM -0400, Anish Mistry wrote: > > > > On Saturday 11 September 2004 02:00 pm, you wrote: > > > > > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > > > > > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > > > > > > [ John, sorry for the duplicate message; this is the correct > > > > > > > one. ] > > > > > > > > > > > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > > > > > > Anish Mistry has developed a patch to > > > > > > > > choose an appropriate mmap address. He posted it to -curren= t. > > > > > > > > I haven't had time to test it. > > > > > > > > > > > > > > Thanks for the note. Will you have time to test/commit this > > > > > > > before 5.3? > > > > > > > > > > > > > > Anish, do you have any news on this patch? (Wine has been > > > > > > > broken for a couple of months now, and it would be great to > > > > > > > have at least 5.3 fixed.) > > > > > > > > > > > > Well I guess this is my lucky day. Apply the attached patch for > > > > > > vm_mmap to your kernel and patch the August wine sources with t= he > > > > > > wine-mmap.patch and compile and install wine (be sure to use > > > > > > gmake). This is working on my dev system with 6-CURRENT as of > > > > > > Saturday night. The wine mmap patch just doesn't reserve the DOS > > > > > > area so DOS programs may not work. This seems to just work > > > > > > around a side effect of the kernel mmap patch. I still think th= at > > > > > > the kernel mmap patch has issues so I'm hoping Alan can give us > > > > > > some feedback. > > > > > > Anyway this worked for me, YMMV. > > > > > > > > > > Do these combined work for you, minus any modifications to mmap(2= )? > > > > > I do not feel that the kernel mmap(2) should be modified in this > > > > > manner, that it is a strictly userland problem. > > > > > > > > With only these applied I get old message that wine can't mmap it's > > > > address space. > > > > > > Oh, I'm sorry for not explaining the last step. You need to set the > > > environment variable "LD_LIBRARY_LOW_ADDR" to some address, like after > > > the first megabyte, or something like that, but before the first "dat= a" > > > address. Try, say, 1024000. > > > > Ok, I've tried that, with several different numbers and I either get > > something like: > > wine: failed to initialize: /usr/local/lib/libwine_unicode.so.1: mmap > > returned wrong address: wanted 0xc350000, got 0xc3bd000 > > or just the normal: > > wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: mmap of > > entire address space failed: Cannot allocate memory > > > > Any other suggestions? > > Oops, can you try this instead? Can you share with me exactly how you > run this "regression test" with WINE (what program, what .wine/config)? > Ok, this instead of getting the wrong address, wine just bails out with: wine: failed to create the process heap. The other message still appears i= f=20 the load address is high enough. This is how I'm testing: I've downloaded the August (20040813) version of wine applied the patch to= =20 comment out the reservation of the dos area in a previous email (attached=20 again, idealy we shouldn't apply this since having the stock wine work woul= d=20 be much better), and did a ./configure && gmake depend && gmake && gmake=20 install. I've attached my wine config file. Then I just end the=20 environmental variable you said and run wine. I'm using Diablo 2 as my tes= t=20 app. =2D-=20 Anish Mistry --Boundary-02=_/sIRBctZakl5Vdz Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBRIs/xqA5ziudZT0RAkpCAKCVw5V8CHO2fVgm46C+j90N/YRtUQCfU7KU RzQn/aUUMWBjP3mjWgkKn9s= =PWX+ -----END PGP SIGNATURE----- --Boundary-02=_/sIRBctZakl5Vdz-- --Boundary-00=_+sIRBuYt87PX2OZ Content-Type: text/x-diff; charset="iso-8859-1"; name="wine-mmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="wine-mmap.patch" --- libs/wine/mmap.c.orig Mon Sep 6 01:23:40 2004 +++ libs/wine/mmap.c Mon Sep 6 01:23:46 2004 @@ -294,7 +294,7 @@ area = LIST_ENTRY( ptr, struct reserved_area, entry ); if (!area->base) return; } - reserve_dos_area(); + /*reserve_dos_area();*/ } #else /* HAVE_MMAP */ --Boundary-00=_+sIRBuYt87PX2OZ-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 17:57:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B161616A4CE for ; Sun, 12 Sep 2004 17:57:34 +0000 (GMT) Received: from www.cray1.de (i.would.like.to.spoof.my.realip.de [64.27.85.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBD9B43D54 for ; Sun, 12 Sep 2004 17:57:33 +0000 (GMT) (envelope-from ubm@u-boot-man.de) Received: from greatsheep.marines (localhost [127.0.0.1]) by www.cray1.de (8.9.3/8.9.3) with SMTP id TAA00408 for ; Sun, 12 Sep 2004 19:57:26 +0200 Date: Sun, 12 Sep 2004 20:00:50 +0200 From: Marc "UBM" Bocklet To: current@freebsd.org Message-Id: <20040912200050.160b3b34.ubm@u-boot-man.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4" Subject: panic with BETA4, bridge.ko and WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 17:57:34 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hiho! :-) I just cvsupped and updated to BETA4. For the fun of it, I deciced to put WITNESS and INVARIANTS in the kernel. When rebooting, I promptly encountered three sucessive LORs and a panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex bridge @ /usr/src/sys/mo dules/bridge/../../net/bridge.c:940 cpuid = 1 KDB: enter: panic [thread 100052] Stopped at kdb_enter+0x30: leave Trace, LORs, config, etc. are attached to my mail. (sorry for the mangled output, but I had to use HyperTerminal) There is no panic at all if I load bridge.ko after the boot process or if I don't load it at all. I did not yet try what happens if bridge is compiled into the kernel. root@greatsheep:/home/sheep# uname -a FreeBSD greatsheep 5.3-BETA4 FreeBSD 5.3-BETA4 #6: Sun Sep 12 17:08:39 CEST 2004 root@greatsheep:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: application/octet-stream; name="lors+panic.txt" Content-Disposition: attachment; filename="lors+panic.txt" Content-Transfer-Encoding: base64 bmV0LmxpbmsuZXRoZXIuYnJpZGdlX2NmZzogbWFsbG9jKE1fV0FJVE9LKSBvZiAiNjQiLCBmb3Jj aW5nIE1fTk9XQUlUIHdpdGggdGhlIGYKb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2NrcyBoZWxk OgpleGNsdXNpdmUgc2xlZXAgbXV0ZXggaWZuZXQgciA9IDAgKDB4YzA4M2E2ODApIGxvY2tlZCBA IC91c3Ivc3JjL3N5cy9uZXQvaWYuYzo2OQo5CmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBicmlkZ2Ug ciA9IDAgKDB4YzA5MTU3YzApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2JyCmlkZ2Uv Li4vLi4vbmV0L2JyaWRnZS5jOjU5NApLREI6IHN0YWNrIGJhY2t0cmFjZToKa2RiX2JhY2t0cmFj ZShjMDgzOTk0YyxkNTQ2ODg3NCwxLDEsMikgYXQga2RiX2JhY2t0cmFjZSsweDJlCndpdG5lc3Nf d2Fybig1LDAsYzA3YjdkNjIsYzA3YTU2ZmYsYzFkN2QwNjApIGF0IHdpdG5lc3Nfd2FybisweDFk Mwp1bWFfemFsbG9jX2FyZyhjMTAzMzU4MCwwLDEwMixjMTA0NWEwMCxkNTQ2ODkwYykgYXQgdW1h X3phbGxvY19hcmcrMHg1NQptYWxsb2MoMzYsYzA3ZWEzYTAsMTAyLDAsZDU0Njg5MGMpIGF0IG1h bGxvYysweGQ2CmV0aGVyX3Jlc29sdmVtdWx0aShjMWE3YjAwMCxkNTQ2ODhlNCxkNTQ2ODkwYyww LGQ1NDY4OTY0KSBhdCBldGhlcl9yZXNvbHZlbXVsdGkrCjB4MTQ3CmlmX2FkZG11bHRpKGMxYTdi MDAwLGQ1NDY4OTBjLGQ1NDY4OTA4LDAsMWMxYykgYXQgaWZfYWRkbXVsdGkrMHg3YgppbjZfYWRk bXVsdGkoZDU0Njg5NmMsYzFhN2IwMDAsZDU0Njg5NjQsMSwwKSBhdCBpbjZfYWRkbXVsdGkrMHg1 ZAppbjZfdXBkYXRlX2lmYShjMWE3YjAwMCxkNTQ2OGE3MCwwLDEsMCkgYXQgaW42X3VwZGF0ZV9p ZmErMHg1ZWYKaW42X2lmYXR0YWNoX2xpbmtsb2NhbChjMWE3YjAwMCwwLGMxOWYyMzkwLGMwNWNl MzZiLGMwN2ViZmE4KSBhdCBpbjZfaWZhdHRhY2hfbGkKbmtsb2NhbCsweDExNgppbjZfaWZhdHRh Y2goYzFhN2IwMDAsMCxjMTk1YzQwMCwwLDApIGF0IGluNl9pZmF0dGFjaCsweGNjCmluNl9pZl91 cChjMWE3YjAwMCxjMTk1YzRhMCkgYXQgaW42X2lmX3VwKzB4MWIKaWZfcm91dGUoYzFhN2IwMDAs MSwwLGQ1NDY4YjkwLGMwOTEyMWI4KSBhdCBpZl9yb3V0ZSsweDY3CmlmX3VwKGMxYTdiMDAwLDAs YzA5MTNkNzAsMWFhLDApIGF0IGlmX3VwKzB4MjEKYnJpZGdlX29uKGMwOTE1N2MwLDEsYzA5MTNk NzAsMWNlLGQ1NDY4YmM4KSBhdCBicmlkZ2Vfb24rMHg4OApyZWNvbmZpZ3VyZV9icmlkZ2VfbG9j a2VkKGMxYzU3NDAwLGMwOTE3NjIwLDQwMCwyNTIsZDU0NjhjMTApIGF0IHJlY29uZmlndXJlX2Jy aQpkZ2VfbG9ja2VkKzB4N2EKc3lzY3RsX2JkZ19jZmcoYzA5MTU2NjAsYzA5MTc2MjAsNDAwLGQ1 NDY4YzEwLGQ1NDY4YzEwKSBhdCBzeXNjdGxfYmRnX2NmZysweGJhCnN5c2N0bF9yb290KDAsZDU0 NjhjN2MsNCxkNTQ2OGMxMCxjMTlmMjMyMCkgYXQgc3lzY3RsX3Jvb3QrMHgxNTQKdXNlcmxhbmRf c3lzY3RsKGMxOWYyMzIwLGQ1NDY4YzdjLDQsMCwwKSBhdCB1c2VybGFuZF9zeXNjdGwrMHgxMmMK X19zeXNjdGwoYzE5ZjIzMjAsZDU0NjhkMTQsMTgsNDMxLDYpIGF0IF9fc3lzY3RsKzB4YWYKc3lz Y2FsbCgyZiwyZiwyZiwwLGJmYmZlZGQwKSBhdCBzeXNjYWxsKzB4MmEwClhpbnQweDgwX3N5c2Nh bGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWYKLS0tIHN5c2NhbGwgKDIwMiwgRnJlZUJTRCBF TEYzMiwgX19zeXNjdGwpLCBlaXAgPSAweDI4MGQ0OTdmLCBlc3AgPSAweGJmYmZlNTNjLAplYnAg PSAweGJmYmZlNTY4IC0tLQptYWxsb2MoTV9XQUlUT0spIG9mICIzMiIsIGZvcmNpbmcgTV9OT1dB SVQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFibGUgbG9jawpzIGhlbGQ6CmV4Y2x1c2l2 ZSBzbGVlcCBtdXRleCBpZm5ldCByID0gMCAoMHhjMDgzYTY4MCkgbG9ja2VkIEAgL3Vzci9zcmMv c3lzL25ldC9pZi5jOjY5CjkKZXhjbHVzaXZlIHNsZWVwIG11dGV4IGJyaWRnZSByID0gMCAoMHhj MDkxNTdjMCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvYnIKaWRnZS8uLi8uLi9uZXQv YnJpZGdlLmM6NTk0CktEQjogc3RhY2sgYmFja3RyYWNlOgprZGJfYmFja3RyYWNlKGMwODM5OTRj LGQ1NDY4ODk0LDEsMSwyKSBhdCBrZGJfYmFja3RyYWNlKzB4MmUKd2l0bmVzc193YXJuKDUsMCxj MDdiN2Q2MixjMDc5MWQ4OSw0MCkgYXQgd2l0bmVzc193YXJuKzB4MWQzCnVtYV96YWxsb2NfYXJn KGMxMDMzNDIwLDAsMixjMTA0NTk2MCwwKSBhdCB1bWFfemFsbG9jX2FyZysweDU1Cm1hbGxvYygx YyxjMDdlYTNhMCwyLGMxY2E2MTgwLGQ1NDY4OTY0KSBhdCBtYWxsb2MrMHhkNgppZl9hZGRtdWx0 aShjMWE3YjAwMCxkNTQ2ODkwYyxkNTQ2ODkwOCwwLDFjMWMpIGF0IGlmX2FkZG11bHRpKzB4YWEK aW42X2FkZG11bHRpKGQ1NDY4OTZjLGMxYTdiMDAwLGQ1NDY4OTY0LDEsMCkgYXQgaW42X2FkZG11 bHRpKzB4NWQKaW42X3VwZGF0ZV9pZmEoYzFhN2IwMDAsZDU0NjhhNzAsMCwxLDApIGF0IGluNl91 cGRhdGVfaWZhKzB4NWVmCmluNl9pZmF0dGFjaF9saW5rbG9jYWwoYzFhN2IwMDAsMCxjMTlmMjM5 MCxjMDVjZTM2YixjMDdlYmZhOCkgYXQgaW42X2lmYXR0YWNoX2xpCm5rbG9jYWwrMHgxMTYKaW42 X2lmYXR0YWNoKGMxYTdiMDAwLDAsYzE5NWM0MDAsMCwwKSBhdCBpbjZfaWZhdHRhY2grMHhjYwpp bjZfaWZfdXAoYzFhN2IwMDAsYzE5NWM0YTApIGF0IGluNl9pZl91cCsweDFiCmlmX3JvdXRlKGMx YTdiMDAwLDEsMCxkNTQ2OGI5MCxjMDkxMjFiOCkgYXQgaWZfcm91dGUrMHg2NwppZl91cChjMWE3 YjAwMCwwLGMwOTEzZDcwLDFhYSwwKSBhdCBpZl91cCsweDIxCmJyaWRnZV9vbihjMDkxNTdjMCwx LGMwOTEzZDcwLDFjZSxkNTQ2OGJjOCkgYXQgYnJpZGdlX29uKzB4ODgKcmVjb25maWd1cmVfYnJp ZGdlX2xvY2tlZChjMWM1NzQwMCxjMDkxNzYyMCw0MDAsMjUyLGQ1NDY4YzEwKSBhdCByZWNvbmZp Z3VyZV9icmkKZGdlX2xvY2tlZCsweDdhCnN5c2N0bF9iZGdfY2ZnKGMwOTE1NjYwLGMwOTE3NjIw LDQwMCxkNTQ2OGMxMCxkNTQ2OGMxMCkgYXQgc3lzY3RsX2JkZ19jZmcrMHhiYQpzeXNjdGxfcm9v dCgwLGQ1NDY4YzdjLDQsZDU0NjhjMTAsYzE5ZjIzMjApIGF0IHN5c2N0bF9yb290KzB4MTU0CnVz ZXJsYW5kX3N5c2N0bChjMTlmMjMyMCxkNTQ2OGM3Yyw0LDAsMCkgYXQgdXNlcmxhbmRfc3lzY3Rs KzB4MTJjCl9fc3lzY3RsKGMxOWYyMzIwLGQ1NDY4ZDE0LDE4LDQzMSw2KSBhdCBfX3N5c2N0bCsw eGFmCnN5c2NhbGwoMmYsMmYsMmYsMCxiZmJmZWRkMCkgYXQgc3lzY2FsbCsweDJhMApYaW50MHg4 MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICgyMDIsIEZy ZWVCU0QgRUxGMzIsIF9fc3lzY3RsKSwgZWlwID0gMHgyODBkNDk3ZiwgZXNwID0gMHhiZmJmZTUz YywKZWJwID0gMHhiZmJmZTU2OCAtLS0KbWFsbG9jKE1fV0FJVE9LKSBvZiAiMzIiLCBmb3JjaW5n IE1fTk9XQUlUIHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBhYmxlIGxvY2sKcyBoZWxkOgpl eGNsdXNpdmUgc2xlZXAgbXV0ZXggaWZuZXQgciA9IDAgKDB4YzA4M2E2ODApIGxvY2tlZCBAIC91 c3Ivc3JjL3N5cy9uZXQvaWYuYzo2OQo5CmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBicmlkZ2UgciA9 IDAgKDB4YzA5MTU3YzApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2JyCmlkZ2UvLi4v Li4vbmV0L2JyaWRnZS5jOjU5NApLREI6IHN0YWNrIGJhY2t0cmFjZToKa2RiX2JhY2t0cmFjZShj MDgzOTk0YyxkNTQ2ODg5NCwxLDEsMikgYXQga2RiX2JhY2t0cmFjZSsweDJlCndpdG5lc3Nfd2Fy big1LDAsYzA3YjdkNjIsYzA3OTFkODksYzA3OWY0ZWQpIGF0IHdpdG5lc3Nfd2FybisweDFkMwp1 bWFfemFsbG9jX2FyZyhjMTAzMzQyMCwwLDIsYzEwNDU5NjAsYzFjNDkxODApIGF0IHVtYV96YWxs b2NfYXJnKzB4NTUKbWFsbG9jKDFjLGMwN2VhM2EwLDIsYzFjYTYxODAsZDU0Njg5NjQpIGF0IG1h bGxvYysweGQ2CmlmX2FkZG11bHRpKGMxYTdiMDAwLGQ1NDY4OTBjLGQ1NDY4OTA4LDAsMWMxYykg YXQgaWZfYWRkbXVsdGkrMHhjNwppbjZfYWRkbXVsdGkoZDU0Njg5NmMsYzFhN2IwMDAsZDU0Njg5 NjQsMSwwKSBhdCBpbjZfYWRkbXVsdGkrMHg1ZAppbjZfdXBkYXRlX2lmYShjMWE3YjAwMCxkNTQ2 OGE3MCwwLDEsMCkgYXQgaW42X3VwZGF0ZV9pZmErMHg1ZWYKaW42X2lmYXR0YWNoX2xpbmtsb2Nh bChjMWE3YjAwMCwwLGMxOWYyMzkwLGMwNWNlMzZiLGMwN2ViZmE4KSBhdCBpbjZfaWZhdHRhY2hf bGkKbmtsb2NhbCsweDExNgppbjZfaWZhdHRhY2goYzFhN2IwMDAsMCxjMTk1YzQwMCwwLDApIGF0 IGluNl9pZmF0dGFjaCsweGNjCmluNl9pZl91cChjMWE3YjAwMCxjMTk1YzRhMCkgYXQgaW42X2lm X3VwKzB4MWIKaWZfcm91dGUoYzFhN2IwMDAsMSwwLGQ1NDY4YjkwLGMwOTEyMWI4KSBhdCBpZl9y b3V0ZSsweDY3CmlmX3VwKGMxYTdiMDAwLDAsYzA5MTNkNzAsMWFhLDApIGF0IGlmX3VwKzB4MjEK YnJpZGdlX29uKGMwOTE1N2MwLDEsYzA5MTNkNzAsMWNlLGQ1NDY4YmM4KSBhdCBicmlkZ2Vfb24r MHg4OApyZWNvbmZpZ3VyZV9icmlkZ2VfbG9ja2VkKGMxYzU3NDAwLGMwOTE3NjIwLDQwMCwyNTIs ZDU0NjhjMTApIGF0IHJlY29uZmlndXJlX2JyaQpkZ2VfbG9ja2VkKzB4N2EKc3lzY3RsX2JkZ19j ZmcoYzA5MTU2NjAsYzA5MTc2MjAsNDAwLGQ1NDY4YzEwLGQ1NDY4YzEwKSBhdCBzeXNjdGxfYmRn X2NmZysweDFhN2IKMDAwLGQ1NDY4OTY0LDEsMCkgYXQgaW42X2FkZG11bHRpKzB4NWQKaW42X3Vw ZGF0ZV9pZmEoYzFhN2IwMDAsZDU0NjhhNzAsMCwxLDApIGF0IGluNl91cGRhdGVfaWZhKzB4NWVm CmluNl9pZmF0dGFjaF9saW5rbG9jYWwoYzFhN2IwMDAsMCxjMTlmMjM5MCxjMDVjZTM2YixjMDdl YmZhOCkgYXQgaW42X2lmYXR0YWNoX2xpCm5rbG9jYWwrMHgxMTYKaW42X2lmYXR0YWNoKGMxYTdi MDAwLDAsYzE5NWM0MDAsMCwwKSBhdCBpbjZfaWZhdHRhY2grMHhjYwppbjZfaWZfdXAoYzFhN2Iw MDAsYzE5NWM0YTApIGF0IGluNl9pZl91cCsweDFiCmlmX3JvdXRlKGMxYTdiMDAwLDEsMCxkNTQ2 OGI5MCxjMDkxMjFiOCkgYXQgaWZfcm91dGUrMHg2NwppZl91cChjMWE3YjAwMCwwLGMwOTEzZDcw LDFhYSwwKSBhdCBpZl91cCsweDIxCmJyaWRnZV9vbihjMDkxNTdjMCwxLGMwOTEzZDcwLDFjZSxk NTQ2OGJjOCkgYXQgYnJpZGdlX29uKzB4ODgKcmVjb25maWd1cmVfYnJpZGdlX2xvY2tlZChjMWM1 NzQwMCxjMDkxNzYyMCw0MDAsMjUyLGQ1NDY4YzEwKSBhdCByZWNvbmZpZ3VyZV9icmkKZGdlX2xv Y2tlZCsweDdhCnN5c2N0bF9iZGdfY2ZnKGMwOTE1NjYwLGMwOTE3NjIwLDQwMCxkNTQ2OGMxMCxk NTQ2OGMxMCkgYXQgc3lzY3RsX2JkZ19jZmcrMHhiYQpzeXNjdGxfcm9vdCgwLGQ1NDY4YzdjLDQs ZDU0NjhjMTAsYzE5ZjIzMjApIGF0IHN5c2N0bF9yb290KzB4MTU0CnVzZXJsYW5kX3N5c2N0bChj MTlmMjMyMCxkNTQ2OGM3Yyw0LDAsMCkgYXQgdXNlcmxhbmRfc3lzY3RsKzB4MTJjCl9fc3lzY3Rs KGMxOWYyMzIwLGQ1NDY4ZDE0LDE4LDQzMSw2KSBhdCBfX3N5c2N0bCsweGFmCnN5c2NhbGwoMmYs MmYsMmYsMCxiZmJmZWRkMCkgYXQgc3lzY2FsbCsweDJhMApYaW50MHg4MF9zeXNjYWxsKCkgYXQg WGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICgyMDIsIEZyZWVCU0QgRUxGMzIsIF9f c3lzY3RsKSwgZWlwID0gMHgyODBkNDk3ZiwgZXNwID0gMHhiZmJmZTUzYywKZWJwID0gMHhiZmJm ZTU2OCAtLS0KcGFuaWM6IF9tdHhfbG9ja19zbGVlcDogcmVjdXJzZWQgb24gbm9uLXJlY3Vyc2l2 ZSBtdXRleCBicmlkZ2UgQCAvdXNyL3NyYy9zeXMvbW8KZHVsZXMvYnJpZGdlLy4uLy4uL25ldC9i cmlkZ2UuYzo5NDAKCmNwdWlkID0gMQpLREI6IGVudGVyOiBwYW5pYwpbdGhyZWFkIDEwMDA1Ml0K U3RvcHBlZCBhdCAgICAgIGtkYl9lbnRlcisweDMwOiBsZWF2ZQ== --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: application/octet-stream; name="locks.txt" Content-Disposition: attachment; filename="locks.txt" Content-Transfer-Encoding: base64 ZGI+IHNob3cgbG9ja3MKZXhjbHVzaXZlIHNsZWVwIG11dGV4IGlmbmV0IHIgPSAwICgweGMwODNh NjgwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMvbmV0L2lmLmM6Njk5CmV4Y2x1c2l2ZSBzbGVlcCBt dXRleCBicmlkZ2UgciA9IDAgKDB4YzA5MTU3YzApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9tb2R1 bGVzL2JyaWRnZS8uLi8uLi9uZXQvYnJpZGdlLmM6NTk0CmV4Y2x1c2l2ZSBzeCBzeXNjdGwgbG9j ayByID0gMCAoMHhjMDgwZjVhMCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeXNj dGwuYzoxMzE1CmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBHaWFudCByID0gMCAoMHhjMDgwZGQwMCkg bG9ja2VkIEAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxMjU1CmRiPg== --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: application/octet-stream; name="trace.txt" Content-Disposition: attachment; filename="trace.txt" Content-Transfer-Encoding: base64 ZGI+IHRyCmtkYl9lbnRlcihjMDdhMGViYywxLGMwN2EwMmZiLGQ1NDY4NWY0LGMxOWYyMzIwKSBh dCBrZGJfZW50ZXIrMHgzMApwYW5pYyhjMDdhMDJmYixjMDkxM2M4MyxjMDkxM2Q3MCwzYWMsYzA5 MTU3YzApIGF0IHBhbmljKzB4MTRlCl9tdHhfbG9ja19zbGVlcChjMDkxNTdjMCxjMTlmMjMyMCww LGMwOTEzZDcwLDNhYykgYXQgX210eF9sb2NrX3NsZWVwKzB4NDQKX210eF9sb2NrX2ZsYWdzKGMw OTE1N2MwLDAsYzA5MTNkNzAsM2FjLDApIGF0IF9tdHhfbG9ja19mbGFncysweGMwCmJkZ19mb3J3 YXJkKGMxZDg2ODAwLGMxYTdiMDAwLGMwN2I3YWNiLGQ1NDY4NmYwLGMwNWNjZTg2KSBhdCBiZGdf Zm9yd2FyZCsweGIwCmV0aGVyX291dHB1dF9mcmFtZShjMWE3YjAwMCxjMWQ4NjgwMCw2LGQ1NDY4 ODVjLGQ1NDY4NzA4KSBhdCBldGhlcl9vdXRwdXRfZnJhbWUrCjB4OTkKZXRoZXJfb3V0cHV0KGMx YTdiMDAwLGMxZDg2ODAwLGQ1NDY4ODVjLDAsMCkgYXQgZXRoZXJfb3V0cHV0KzB4NDNlCm5kNl9v dXRwdXQoYzFhN2IwMDAsYzFhN2IwMDAsYzFkODY4MDAsZDU0Njg4NWMsMCkgYXQgbmQ2X291dHB1 dCsweDNjMQppcDZfb3V0cHV0KGMxZDg2ODAwLGMwODQwYjQwLDAsMCxkNTQ2ODhjMCkgYXQgaXA2 X291dHB1dCsweGY3NwptbGQ2X3NlbmRwa3QoYzFjYTYyMDAsODMsMCxjMWNhNjIwMCxkNTQ2ODkz OCkgYXQgbWxkNl9zZW5kcGt0KzB4MjcyCm1sZDZfc3RhcnRfbGlzdGVuaW5nKGMxY2E2MjAwLDJj LDEsYzFjNDkxODAsMWMxYykgYXQgbWxkNl9zdGFydF9saXN0ZW5pbmcrMHg3OAppbjZfYWRkbXVs dGkoZDU0Njg5NmMsYzFhN2IwMDAsZDU0Njg5NjQsMSwwKSBhdCBpbjZfYWRkbXVsdGkrMHgxMGYK aW42X3VwZGF0ZV9pZmEoYzFhN2IwMDAsZDU0NjhhNzAsMCwxLDApIGF0IGluNl91cGRhdGVfaWZh KzB4NWVmCmluNl9pZmF0dGFjaF9saW5rbG9jYWwoYzFhN2IwMDAsMCxjMTlmMjM5MCxjMDVjZTM2 YixjMDdlYmZhOCkgYXQgaW42X2lmYXR0YWNoX2xpCm5rbG9jYWwrMHgxMTYKaW42X2lmYXR0YWNo KGMxYTdiMDAwLDAsYzE5NWM0MDAsMCwwKSBhdCBpbjZfaWZhdHRhY2grMHhjYwppbjZfaWZfdXAo YzFhN2IwMDAsYzE5NWM0YTApIGF0IGluNl9pZl91cCsweDFiCmlmX3JvdXRlKGMxYTdiMDAwLDEs MCxkNTQ2OGI5MCxjMDkxMjFiOCkgYXQgaWZfcm91dGUrMHg2NwppZl91cChjMWE3YjAwMCwwLGMw OTEzZDcwLDFhYSwwKSBhdCBpZl91cCsweDIxCmJyaWRnZV9vbihjMDkxNTdjMCwxLGMwOTEzZDcw LDFjZSxkNTQ2OGJjOCkgYXQgYnJpZGdlX29uKzB4ODgKcmVjb25maWd1cmVfYnJpZGdlX2xvY2tl ZChjMWM1NzQwMCxjMDkxNzYyMCw0MDAsMjUyLGQ1NDY4YzEwKSBhdCByZWNvbmZpZ3VyZV9icmkK ZGdlX2xvY2tlZCsweDdhCnN5c2N0bF9iZGdfY2ZnKGMwOTE1NjYwLGMwOTE3NjIwLDQwMCxkNTQ2 OGMxMCxkNTQ2OGMxMCkgYXQgc3lzY3RsX2JkZ19jZmcrMHhiYQpzeXNjdGxfcm9vdCgwLGQ1NDY4 YzdjLDQsZDU0NjhjMTAsYzE5ZjIzMjApIGF0IHN5c2N0bF9yb290KzB4MTU0CnVzZXJsYW5kX3N5 c2N0bChjMTlmMjMyMCxkNTQ2OGM3Yyw0LDAsMCkgYXQgdXNlcmxhbmRfc3lzY3RsKzB4MTJjCl9f c3lzY3RsKGMxOWYyMzIwLGQ1NDY4ZDE0LDE4LDQzMSw2KSBhdCBfX3N5c2N0bCsweGFmCnN5c2Nh bGwoMmYsMmYsMmYsMCxiZmJmZWRkMCkgYXQgc3lzY2FsbCsweDJhMApYaW50MHg4MF9zeXNjYWxs KCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICgyMDIsIEZyZWVCU0QgRUxG MzIsIF9fc3lzY3RsKSwgZWlwID0gMHgyODBkNDk3ZiwgZXNwID0gMHhiZmJmZTUzYywKZWJwID0g MHhiZmJmZTU2OCAtLS0= --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: application/octet-stream; name="dmesg.boot" Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1CRVRBNCAjNjogU3VuIFNlcCAxMiAxNzowODozOSBD RVNUIDIwMDQKICAgIHJvb3RAZ3JlYXRzaGVlcDovdXNyL29iai91c3Ivc3JjL3N5cy9TVUJNQVJJ TkVfU01QCldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBl cmZvcm1hbmNlLgpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMApDUFU6IFBlbnRpdW0gSUlJL1BlbnRpdW0gSUlJIFhlb24vQ2VsZXJvbiAoNDUxLjAyLU1I eiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjczICBT dGVwcGluZyA9IDMKICBGZWF0dXJlcz0weDM4M2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1Is U1NFPgpyZWFsIG1lbW9yeSAgPSA1MzY3Mzk4NDAgKDUxMSBNQikKYXZhaWwgbWVtb3J5ID0gNTE1 Njc0MTEyICg0OTEgTUIpCkFDUEkgQVBJQyBUYWJsZTogPE9FTVRZTiBPRU1UWU5UQj4KRnJlZUJT RC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1Ap OiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQppb2FwaWMwIDxWZXJzaW9uIDEu MT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9j ZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxPRU1U WU4gT0VNVFlOVEI+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBPdmVycmlkaW5nIFNDSSBJbnRlcnJ1 cHQgZnJvbSBJUlEgOSB0byBJUlEgMjAKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVj b3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3Bp X3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBv biBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNw aTAKY3B1MTogRmFpbGVkIHRvIGF0dGFjaCB0aHJvdHRsaW5nIFBfQ05UCnBjaWIwOiA8QUNQSSBI b3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjAKYWdwMDogPEludGVsIDgyNDQzR1ggaG9zdCB0byBQQ0kgYnJpZGdlPiBt ZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMApwY2liMTogPFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPFBDSSBidXM+IG9uIHBj aWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwCmlzYTA6IDxJ U0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgUElJWDQgVURNQTMzIGNvbnRyb2xsZXI+ IHBvcnQgMHhmZmEwLTB4ZmZhZiwweDM3NiwweDE3MC0weDE3NywweDNmNiwweDFmMC0weDFmNyBh dCBkZXZpY2UgNy4xIG9uIHBjaTAKYXRhMDogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCmF0YTE6IGNo YW5uZWwgIzEgb24gYXRhcGNpMAp1aGNpMDogPEludGVsIDgyMzcxQUIvRUIgKFBJSVg0KSBVU0Ig Y29udHJvbGxlcj4gcG9ydCAweGVmODAtMHhlZjlmIGlycSAxOSBhdCBkZXZpY2UgNy4yIG9uIHBj aTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjM3MUFCL0VCIChQSUlYNCkg VVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6IElu dGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIw OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAppbnRwbTA6IDxJbnRlbCA4 MjM3MUFCIFBvd2VyIG1hbmFnZW1lbnQgY29udHJvbGxlcj4gcG9ydCAweDQ0MC0weDQ0ZiBpcnEg OSBhdCBkZXZpY2UgNy4zIG9uIHBjaTAKaW50cG0wOiBJL08gbWFwcGVkIDQ0MAppbnRwbTA6IGlu dHIgSVJRIDkgZW5hYmxlZCByZXZpc2lvbiAwCmludHBtMDogW0dJQU5ULUxPQ0tFRF0KaW50c21i MDogPEludGVsIFBJSVg0IFNNQlVTIEludGVyZmFjZT4gb24gaW50cG0wCnNtYnVzMDogPFN5c3Rl bSBNYW5hZ2VtZW50IEJ1cz4gb24gaW50c21iMApzbWIwOiA8U01CdXMgZ2VuZXJpYyBJL08+IG9u IHNtYnVzMAppbnRwbTA6IFBNIEkvTyBtYXBwZWQgNDAwIApzeW0wOiA8ODk2PiBwb3J0IDB4ZTQw MC0weGU0ZmYgbWVtIDB4ZmViZTAwMDAtMHhmZWJlMWZmZiwweGZlYmU4MDAwLTB4ZmViZTgzZmYg aXJxIDE3IGF0IGRldmljZSAxMS4wIG9uIHBjaTAKc3ltMDogU3ltYmlvcyBOVlJBTSwgSUQgNywg RmFzdC00MCwgTFZELCBwYXJpdHkgY2hlY2tpbmcKc3ltMDogb3BlbiBkcmFpbiBJUlEgbGluZSBk cml2ZXIsIHVzaW5nIG9uLWNoaXAgU1JBTQpzeW0wOiB1c2luZyBMT0FEL1NUT1JFLWJhc2VkIGZp cm13YXJlLgpzeW0wOiBoYW5kbGluZyBwaGFzZSBtaXNtYXRjaCBmcm9tIFNDUklQVFMuCnN5bTA6 IFtHSUFOVC1MT0NLRURdCnN5bTE6IDw4OTY+IHBvcnQgMHhlODAwLTB4ZThmZiBtZW0gMHhmZWJm MDAwMC0weGZlYmYxZmZmLDB4ZmViZjgwMDAtMHhmZWJmODNmZiBpcnEgMTggYXQgZGV2aWNlIDEx LjEgb24gcGNpMApzeW0xOiBTeW1iaW9zIE5WUkFNLCBJRCA3LCBGYXN0LTQwLCBMVkQsIHBhcml0 eSBjaGVja2luZwpzeW0xOiBvcGVuIGRyYWluIElSUSBsaW5lIGRyaXZlciwgdXNpbmcgb24tY2hp cCBTUkFNCnN5bTE6IHVzaW5nIExPQUQvU1RPUkUtYmFzZWQgZmlybXdhcmUuCnN5bTE6IGhhbmRs aW5nIHBoYXNlIG1pc21hdGNoIGZyb20gU0NSSVBUUy4Kc3ltMTogW0dJQU5ULUxPQ0tFRF0KcGNt MDogPEF1ZGlvUENJIEVTMTM3My04PiBwb3J0IDB4ZWYwMC0weGVmM2YgaXJxIDE4IGF0IGRldmlj ZSAxMi4wIG9uIHBjaTAKcGNtMDogPENpcnJ1cyBMb2dpYyBDUzQyOTcgQUM5NyBDb2RlYz4KcGNt MDogW0dJQU5ULUxPQ0tFRF0KZnhwMDogPEludGVsIDgyNTU5IFByby8xMDAgRXRoZXJuZXQ+IHBv cnQgMHhlZTgwLTB4ZWViZiBtZW0gMHhmZWEwMDAwMC0weGZlYWZmZmZmLDB4ZmViZGYwMDAtMHhm ZWJkZmZmZiBpcnEgMTkgYXQgZGV2aWNlIDEzLjAgb24gcGNpMAptaWlidXMwOiA8TUlJIGJ1cz4g b24gZnhwMAppbnBoeTA6IDxpODI1NTUgMTAvMTAwIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVz MAppbnBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRY LCBhdXRvCmZ4cDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOmUwOjgxOjEwOmU0OjQ5CnBjaTA6IDxk aXNwbGF5LCBWR0E+IGF0IGRldmljZSAxNC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnhsMDogPDND b20gM2M5MDVCLUZYL1NDIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZWMwMC0weGVjN2YgbWVt IDB4ZmViZGVmODAtMHhmZWJkZWZmZiBpcnEgMTYgYXQgZGV2aWNlIDE2LjAgb24gcGNpMAp4bDA6 IEV0aGVybmV0IGFkZHJlc3M6IDAwOjUwOmRhOjI2OjY5OjMwCnhsMTogPDNDb20gM2M5MDVDLVRY IEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZTA4MC0weGUwZmYgbWVtIDB4ZmViZGVmMDAtMHhm ZWJkZWY3ZiBpcnEgMTggYXQgZGV2aWNlIDE4LjAgb24gcGNpMAptaWlidXMxOiA8TUlJIGJ1cz4g b24geGwxCnhscGh5MDogPDNjOTA1QyAxMC8xMDAgaW50ZXJuYWwgUEhZPiBvbiBtaWlidXMxCnhs cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1 dG8KeGwxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowMTowMjpiMzozMjpiYwphY3BpX2J1dHRvbjA6 IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChp ODA0Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJk PiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0K cHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURd CnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMKZmRjMDogPGZsb3BweSBkcml2 ZSBjb250cm9sbGVyPiBwb3J0IDB4M2Y3LDB4M2Y0LTB4M2Y1LDB4M2YyLTB4M2YzIGlycSA2IGRy cSAyIG9uIGFjcGkwCmZkYzA6IGNtZCAzIGZhaWxlZCBhdCBvdXQgYnl0ZSAxIG9mIDMKZGV2aWNl X2F0dGFjaDogZmRjMCBhdHRhY2ggcmV0dXJuZWQgNgpzaW8wIHBvcnQgMHgzZjgtMHgzZmYgaXJx IDQgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEsIGNvbnNvbGUKc2lvMSBwb3J0IDB4MmY4LTB4 MmZmIGlycSAzIG9uIGFjcGkwCnNpbzE6IHR5cGUgMTY1NTBBCnBwYzAgcG9ydCAweDc3OC0weDc3 ZiwweDM3OC0weDM3ZiBpcnEgNyBkcnEgMyBvbiBhY3BpMApwcGMwOiBHZW5lcmljIGNoaXBzZXQg KEVDUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2 LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBs aXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCmxwdDA6IDxQcmludGVyPiBv biBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+ IG9uIHBwYnVzMApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjcsMHgz ZjQtMHgzZjUsMHgzZjItMHgzZjMgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogY21kIDMgZmFp bGVkIGF0IG91dCBieXRlIDEgb2YgMwpkZXZpY2VfYXR0YWNoOiBmZGMwIGF0dGFjaCByZXR1cm5l ZCA2Cm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4Y2MwMDAtMHhjYzdmZiwweGM4 MDAwLTB4Y2JmZmYsMHhjMDAwMC0weGM3ZmZmIG9uIGlzYTAKcG10aW1lcjAgb24gaXNhMApzYzA6 IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmly dHVhbCBjb25zb2xlcywgZmxhZ3M9MHgxMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBv cnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKc2JjMDogPENyZWF0 aXZlIFNCMTYvU0IzMj4gYXQgcG9ydCAweDM4OC0weDM4YiwweDMzMC0weDMzMSwweDIyMC0weDIy ZiBpcnEgNSBkcnEgNSwxIG9uIGlzYTAKc2JjMDogW0dJQU5ULUxPQ0tFRF0KcGNtMTogPFNCMTYg RFNQIDQuMTM+IG9uIHNiYzAKcGNtMTogW0dJQU5ULUxPQ0tFRF0KYXRhMjogPEdlbmVyaWMgRVNE SS9JREUvQVRBIGNvbnRyb2xsZXI+IGF0IHBvcnQgMHgzNmUtMHgzNmYsMHgxNjgtMHgxNmYgaXJx IDEwIG9uIGlzYTAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwphY3BpX2NwdTog dGhyb3R0bGluZyBlbmFibGVkLCA4IHN0ZXBzICgxMDAlIHRvIDEyLjUlKSwgY3VycmVudGx5IDEw MC4wJQphZDI6IDgwNTZNQiA8U1QzODQyMUEvOC4wMT4gWzE2MzY4LzE2LzYzXSBhdCBhdGExLW1h c3RlciBVRE1BMzMKV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUK KG5vcGVyaXBoOnN5bTA6MDotMTotMSk6IFNDU0kgQlVTIHJlc2V0IGRlbGl2ZXJlZC4KKG5vcGVy aXBoOnN5bTE6MDotMTotMSk6IFNDU0kgQlVTIHJlc2V0IGRlbGl2ZXJlZC4KSW50ZXJydXB0IHN0 b3JtIGRldGVjdGVkIG9uICJpcnE5OiBpbnRwbTAiOyB0aHJvdHRsaW5nIGludGVycnVwdCBzb3Vy Y2UKZGEwIGF0IHN5bTEgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8RlVKSVRTVSBNQUczMTgy TEMgNTIxMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIApkYTA6IDgwLjAwME1C L3MgdHJhbnNmZXJzICg0MC4wMDBNSHosIG9mZnNldCAzMSwgMTZiaXQpLCBUYWdnZWQgUXVldWVp bmcgRW5hYmxlZApkYTA6IDE3NDI5TUIgKDM1Njk0ODYwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUgg NjNTL1QgMjIyMUMpClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpNb3VudGluZyByb290IGZyb20g dWZzOi9kZXYvYWQyczFhCg== --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4 Content-Type: application/octet-stream; name="SUBMARINE_SMP" Content-Disposition: attachment; filename="SUBMARINE_SMP" Content-Transfer-Encoding: base64 CgptYWNoaW5lCQlpMzg2CmNwdQkJSTY4Nl9DUFUKaWRlbnQJCVNVQk1BUklORV9TTVAKCiMgVG8g c3RhdGljYWxseSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZp Y2UuaGludHMKI2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVmYXVsdCBwbGFjZXMgdG8gbG9v ayBmb3IgZGV2aWNlcy4KCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRo IGdkYigxKSBkZWJ1ZyBzeW1ib2xzCgojb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVs ZXIKb3B0aW9ucwkJU0NIRURfNEJTRAkJIyA0QlNEIHNjaGVkdWxlcgpvcHRpb25zIAlJTkVUCQkJ IyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlvbnMg cHJvdG9jb2xzCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9wdGlv bnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQKb3B0aW9u cyAJVUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAJ VUZTX0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0 aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJ TkZTQ0xJRU5UCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVS CQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVz YWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQKb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1Mg RmlsZXN5c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9u cyAJUFJPQ0ZTCQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRp b25zIAlQU0VVRE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VP TV9HUFQJCSMgR1VJRCBQYXJ0aXRpb24gVGFibGVzLgpvcHRpb25zIAlDT01QQVRfNDMJCSMgQ29t cGF0aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNE NAkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDQKb3B0aW9ucyAJU0NTSV9ERUxBWT01MDAwCQkj IERlbGF5IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NTSQpvcHRpb25zIAlLVFJBQ0UJCQkjIGt0 cmFjZSgxKSBzdXBwb3J0Cm9wdGlvbnMgCVNZU1ZTSE0JCQkjIFNZU1Ytc3R5bGUgc2hhcmVkIG1l bW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJIyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9wdGlv bnMgCVNZU1ZTRU0JCQkjIFNZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlfS1BPU0lYX1BS SU9SSVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9ucwpv cHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2Rldgpv cHRpb25zIAlBSENfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBp biBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuCm9wdGlvbnMgCUFI RF9SRUdfUFJFVFRZX1BSSU5UCSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJ CQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRvIGRyaXZlci4Kb3B0aW9ucyAJUEZJTF9IT09LUwkJ IyBwZmlsKDkpIGZyYW1ld29yawpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJIyBHaWFudCBtdXRl eCBpcyBhZGFwdGl2ZS4KCiMgRGVidWdnaW5nIGZvciB1c2UgaW4gLWN1cnJlbnQKb3B0aW9ucyAJ S0RCCQkJIyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1cHBvcnQuCm9wdGlvbnMgCUREQgkJCSMg U3VwcG9ydCBEREIuCm9wdGlvbnMgCUdEQgkJCSMgU3VwcG9ydCByZW1vdGUgR0RCLgpvcHRpb25z IAlJTlZBUklBTlRTCQkjIEVuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKb3B0 aW9ucyAJSU5WQVJJQU5UX1NVUFBPUlQJIyBFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFs IHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKb3B0aW9ucyAJV0lUTkVTUwkJCSMg RW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNsZXMKb3B0aW9ucyAJV0lU TkVTU19TS0lQU1BJTgkjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQK CiMgVG8gbWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCB0d28gYXJlIG5lZWRlZApvcHRpb25z IAlTTVAJCSMgU3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtlcm5lbApkZXZpY2UJCWFwaWMJCSMg SS9PIEFQSUMKCiMgQnVzIHN1cHBvcnQuICBEbyBub3QgcmVtb3ZlIGlzYSwgZXZlbiBpZiB5b3Ug aGF2ZSBubyBpc2Egc2xvdHMKZGV2aWNlCQlpc2EKZGV2aWNlCQllaXNhCmRldmljZQkJcGNpCgoj IEZsb3BweSBkcml2ZXMKZGV2aWNlCQlmZGMKCiMgQVRBIGFuZCBBVEFQSSBkZXZpY2VzCmRldmlj ZQkJYXRhCmRldmljZQkJYXRhZGlzawkJIyBBVEEgZGlzayBkcml2ZXMKZGV2aWNlCQlhdGFyYWlk CQkjIEFUQSBSQUlEIGRyaXZlcwpkZXZpY2UJCWF0YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVz CmRldmljZQkJYXRhcGlmZAkJIyBBVEFQSSBmbG9wcHkgZHJpdmVzCmRldmljZQkJYXRhcGlzdAkJ IyBBVEFQSSB0YXBlIGRyaXZlcwpvcHRpb25zIAlBVEFfU1RBVElDX0lECSMgU3RhdGljIGRldmlj ZSBudW1iZXJpbmcKCiMgU0NTSSBDb250cm9sbGVycwojZGV2aWNlCQlhaGIJCSMgRUlTQSBBSEEx NzQyIGZhbWlseQpkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2 aWNlcwojZGV2aWNlCQlhaGQJCSMgQUhBMzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBk ZXZpY2VzCiNkZXZpY2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQojZGV2 aWNlCQlpc3AJCSMgUWxvZ2ljIGZhbWlseQojZGV2aWNlCQltcHQJCSMgTFNJLUxvZ2ljIE1QVC1G dXNpb24KI2RldmljZQkJbmNyCQkjIE5DUi9TeW1iaW9zIExvZ2ljCmRldmljZQkJc3ltCQkjIE5D Ui9TeW1iaW9zIExvZ2ljIChuZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3InKQojZGV2aWNl CQl0cm0JCSMgVGVrcmFtIERDMzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoKI2RldmljZQkJYWR2 CQkjIEFkdmFuc3lzIFNDU0kgYWRhcHRlcnMKI2RldmljZQkJYWR3CQkjIEFkdmFuc3lzIHdpZGUg U0NTSSBhZGFwdGVycwojZGV2aWNlCQlhaGEJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMK I2RldmljZQkJYWljCQkjIEFkYXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNd NjAuCiNkZXZpY2UJCWJ0CQkjIEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRhcHRl cnMKCiNkZXZpY2UJCW5jdgkJIyBOQ1IgNTNDNTAwCiNkZXZpY2UJCW5zcAkJIyBXb3JrYml0IE5p bmphIFNDU0ktMwojZGV2aWNlCQlzdGcJCSMgVE1DIDE4QzMwLzE4QzUwCgojIFNDU0kgcGVyaXBo ZXJhbHMKZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpCmRldmlj ZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3Mg KGRpc2tzKQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykKZGV2aWNl CQljZAkJIyBDRApkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NT SSBhY2Nlc3MpCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5k IFNBRi1URSkKCgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQ Uy8yIG1vdXNlCmRldmljZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNl CQlhdGtiZAkJIyBBVCBrZXlib2FyZApkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJ CXZnYQkJIyBWR0EgdmlkZW8gY2FyZCBkcml2ZXIKCmRldmljZQkJc3BsYXNoCQkjIFNwbGFzaCBz Y3JlZW4gYW5kIHNjcmVlbiBzYXZlciBzdXBwb3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQg Y29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2aWNlCQlzYwoKIyBF bmFibGUgdGhpcyBmb3IgdGhlIHBjdnQgKFZUMjIwIGNvbXBhdGlibGUpIGNvbnNvbGUgZHJpdmVy CiNkZXZpY2UJCXZ0CiNvcHRpb25zIAlYU0VSVkVSCQkjIHN1cHBvcnQgZm9yIFggc2VydmVyIG9u IGEgdnQgY29uc29sZQojb3B0aW9ucyAJRkFUX0NVUlNPUgkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vy c29yCgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEZsb2F0 aW5nIHBvaW50IHN1cHBvcnQgLSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgKCiMgUG93ZXIg bWFuYWdlbWVudCBzdXBwb3J0IChzZWUgTk9URVMgZm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJ YXBtCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1NC4KZGV2aWNlCQlw bXRpbWVyCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBwb3J0CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJy aWRnZSBzdXBwb3J0CmRldmljZQkJY2JiCQkjIGNhcmRidXMgKHllbnRhKSBicmlkZ2UKZGV2aWNl CQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0KSBidXMKZGV2aWNlCQljYXJkYnVzCQkjIENhcmRC dXMgKDMyLWJpdCkgYnVzCgojIFNlcmlhbCAoQ09NKSBwb3J0cwpkZXZpY2UJCXNpbwkJIyA4MjUw LCAxNls0NV01MCBiYXNlZCBzZXJpYWwgcG9ydHMKCiMgUGFyYWxsZWwgcG9ydApkZXZpY2UJCXBw YwpkZXZpY2UJCXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQls cHQJCSMgUHJpbnRlcgpkZXZpY2UJCXBsaXAJCSMgVENQL0lQIG92ZXIgcGFyYWxsZWwKZGV2aWNl CQlwcGkJCSMgUGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBS ZXF1aXJlcyBzY2J1cyBhbmQgZGEKCgojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBj b21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuCiMgTk9URTogQmUgc3VyZSB0byBrZWVwIHRo ZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEKZGV2aWNl CQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CiNkZXZpY2UJCWJmZQkJIyBCcm9hZGNvbSBCQ000 NDB4IDEwLzEwMCBFdGhlcm5ldAojZGV2aWNlCQliZ2UJCSMgQnJvYWRjb20gQkNNNTcweHggR2ln YWJpdCBFdGhlcm5ldAojZGV2aWNlCQlkYwkJIyBERUMvSW50ZWwgMjExNDMgYW5kIHZhcmlvdXMg d29ya2FsaWtlcwpkZXZpY2UJCWZ4cAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgy NTU3LCA4MjU1OCkKI2RldmljZQkJcGNuCQkjIEFNRCBBbTc5Qzk3eCBQQ0kgMTAvMTAwIChwcmVj ZWRlbmNlIG92ZXIgJ2xuYycpCiNkZXZpY2UJCXJlCQkjIFJlYWxUZWsgODEzOUMrLzgxNjkvODE2 OVMvODExMFMKZGV2aWNlCQlybAkJIyBSZWFsVGVrIDgxMjkvODEzOQojZGV2aWNlCQlzZgkJIyBB ZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpCiNkZXZpY2UJCXNpcwkJIyBTaWxpY29uIElu dGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2CiNkZXZpY2UJCXNrCQkjIFN5c0tvbm5l Y3QgU0stOTg0eCAmIFNLLTk4MnggZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQlzdGUJCSMgU3Vu ZGFuY2UgU1QyMDEgKEQtTGluayBERkUtNTUwVFgpCiNkZXZpY2UJCXRpCQkjIEFsdGVvbiBOZXR3 b3JrcyBUaWdvbiBJL0lJIGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJdGwJCSMgVGV4YXMgSW5z dHJ1bWVudHMgVGh1bmRlckxBTgojZGV2aWNlCQl0eAkJIyBTTUMgRXRoZXJQb3dlciBJSSAoODNj MTcwIGBgRVBJQycnKQojZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJCiNkZXZpY2UJ CXdiCQkjIFdpbmJvbmQgVzg5Qzg0MEYKZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21l cmFuZycnLCBgYEN5Y2xvbmUnJykKCiMgV2lyZWxlc3MgTklDIGNhcmRzCmRldmljZQkJd2xhbgkJ IyA4MDIuMTEgc3VwcG9ydApkZXZpY2UJCWFuCQkjIEFpcm9uZXQgNDUwMC80ODAwIDgwMi4xMSB3 aXJlbGVzcyBOSUNzLgpkZXZpY2UJCWF3aQkJIyBCYXlTdGFjayA2NjAgYW5kIG90aGVycwpkZXZp Y2UJCXdpCQkjIFdhdmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgoj ZGV2aWNlCQl3bAkJIyBPbGRlciBub24gODAyLjExIFdhdmVsYW4gd2lyZWxlc3MgTklDLgoKIyBQ c2V1ZG8gZGV2aWNlcy4KZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQlt ZW0JCSMgTWVtb3J5IGFuZCBrZXJuZWwgbWVtb3J5IGRldmljZXMKZGV2aWNlCQlpbwkJIyBJL08g ZGV2aWNlCmRldmljZQkJcmFuZG9tCQkjIEVudHJvcHkgZGV2aWNlCmRldmljZQkJZXRoZXIJCSMg RXRoZXJuZXQgc3VwcG9ydApkZXZpY2UJCXNsCQkjIEtlcm5lbCBTTElQCmRldmljZQkJcHBwCQkj IEtlcm5lbCBQUFAKZGV2aWNlCQl0dW4JCSMgUGFja2V0IHR1bm5lbC4KZGV2aWNlCQlwdHkJCSMg UHNldWRvLXR0eXMgKHRlbG5ldCBldGMpCmRldmljZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKZGV2 aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKZGV2aWNlCQlmYWl0aAkJIyBJUHY2 LXRvLUlQdjQgcmVsYXlpbmcgKHRyYW5zbGF0aW9uKQoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJs ZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0 cmF0aXZlIGNvbnNlcXVlbmNlcyBvZiBlbmFibGluZyB0aGlzIQpkZXZpY2UJCWJwZgkJIyBCZXJr ZWxleSBwYWNrZXQgZmlsdGVyCgojIFVTQiBzdXBwb3J0CmRldmljZQkJdWhjaQkJIyBVSENJIFBD SS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UK ZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAocmVxdWlyZWQpCiNkZXZpY2UJCXVkYnAJCSMgVVNCIERv dWJsZSBCdWxrIFBpcGUgZGV2aWNlcwpkZXZpY2UJCXVnZW4JCSMgR2VuZXJpYwpkZXZpY2UJCXVo aWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2VzIgpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQK ZGV2aWNlCQl1bHB0CQkjIFByaW50ZXIKZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3Jh Z2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKZGV2aWNlCQl1bXMJCSMgTW91c2UKZGV2aWNlCQl1 cmlvCQkjIERpYW1vbmQgUmlvIDUwMCBNUDMgcGxheWVyCmRldmljZQkJdXNjYW5uZXIJIyBTY2Fu bmVycwojIFVTQiBFdGhlcm5ldCwgcmVxdWlyZXMgbWlpCiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsg VVNCIEV0aGVybmV0CiNkZXZpY2UJCWF4ZQkJIyBBU0lYIEVsZWN0cm9uaWNzIFVTQiBFdGhlcm5l dAojZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0IgRXRoZXJuZXQKI2RldmljZQkJa3VlCQkjIEthd2Fz YWtpIExTSSBVU0IgRXRoZXJuZXQKI2RldmljZQkJcnVlCQkjIFJlYWxUZWsgUlRMODE1MCBVU0Ig RXRoZXJuZXQKCgojIyMgY3VzdG9tIG9wdGlvbnMgZm9yIFNVQk1BUklORV9TTVAgIyMjCgoKIyBz b3VuZCBkZXZpY2VzCgpkZXZpY2UJCXNvdW5kCmRldmljZQkJc25kX3NiYwpkZXZpY2UJCSJzbmRf c2IxNiIKCgojIyBuZXR3b3JraW5nIG9wdGlvbnMgIyMKCiMgcGYgCgpkZXZpY2UJCXBmCmRldmlj ZQkJcGZsb2cKZGV2aWNlCQlwZnN5bmMKCiMgYWx0cQoKb3B0aW9ucwkJQUxUUQpvcHRpb25zCQlB TFRRX0NCUQpvcHRpb25zCQlBTFRRX1JFRApvcHRpb25zCQlBTFRRX1JJTwpvcHRpb25zCQlBTFRR X0hGU0MKb3B0aW9ucwkJQUxUUV9DRE5SCm9wdGlvbnMJCUFMVFFfUFJJUQpvcHRpb25zCQlBTFRR X05PUENDCm9wdGlvbnMJCUFMVFFfREVCVUcKCiMgcnVkaW1lbnRhcnkgcHJvdGVjdGlvbgoKb3B0 aW9ucwkJSVBTVEVBTFRICm9wdGlvbnMJCVRDUF9EUk9QX1NZTkZJTgoKCgojIHJlYXNvbmFibGUg aHogbGV2ZWwKCm9wdGlvbnMJCUhaPTIwMDAKCgoKIyMgc2V0IGNvbnNvbGUgcmVzb2x1dGlvbiB0 byA4MDB4NjAwLCAxMDI0eDc2OCBhd2FpdHMhISAjIwoKIyBWRVNBIHN1cHBvcnQKCm9wdGlvbnMJ CVZFU0EKCiMgcmFzdGVyIGRpc3BsYXkgc3VwcG9ydCBmb3IgODAweDYwMCByZXNvbHV0aW9uCgpv cHRpb25zCQlTQ19QSVhFTF9NT0RFCgoKCiMgc3VwcG9ydCBmb3IgSU5URUwgUElJWDQgU01CdXMK CmRldmljZQkJc21idXMKZGV2aWNlCQlpbnRwbQpkZXZpY2UJCXNtYgoKCgojIGVuYWJsZSBkZXZp Y2UgcG9sbGluZwoKI29wdGlvbnMgCURFVklDRV9QT0xMSU5HCgog --Multipart=_Sun__12_Sep_2004_20_00_50_+0200_O4xlW+3NVhs/l2s4-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 18:02:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8468E16A4CE; Sun, 12 Sep 2004 18:02:30 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7066743D48; Sun, 12 Sep 2004 18:02:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8CI2KDL072590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Sep 2004 21:02:21 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8CI2L4P018322; Sun, 12 Sep 2004 21:02:21 +0300 (EEST) (envelope-from ru) Date: Sun, 12 Sep 2004 21:02:21 +0300 From: Ruslan Ermilov To: Jens Schweikhardt Message-ID: <20040912180221.GB18232@ip.net.ua> References: <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> <20040912112411.GA62181@schweikhardt.net> <20040912140311.GA60265@schweikhardt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20040912140311.GA60265@schweikhardt.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Maxim Sobolev cc: portmgr@FreeBSD.ORG cc: Roman Kurakin cc: current@FreeBSD.ORG cc: Kris Kennaway Subject: Re: ccache support for make buildworld/make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 18:02:30 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2004 at 04:03:11PM +0200, Jens Schweikhardt wrote: > Following up myself, >=20 > On Sun, Sep 12, 2004 at 01:24:11PM +0200, Jens Schweikhardt wrote: > # On Wed, Aug 25, 2004 at 11:33:42AM -0700, Kris Kennaway wrote: > # ... > # # BTW, I don't think there's anything to set up..you just set > # # CC=3D"ccache cc" or similar. >=20 > I've investigated further and found that the cc which is used > after bootstrapping uses a different start for include path > search, e.g. >=20 > /usr/bin/cc -v ... > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. >=20 > /usr/obj/share/HEAD/src/i386/usr/bin/cc -v ... > #include "..." search starts here: > #include <...> search starts here: > /usr/obj/share/HEAD/src/i386/usr/include > End of search list. >=20 > This is why the includes are not found when ccache is forced to use > /usr/bin/cc. Which somewhat defeats the purpose of ccache: if the > build switches compilers, ccache only speeds up the bootstrapping > up to that point. Unfortunately, ccache also hashes the compiler's > modification timestamp, so each time a new cc is used in the build, > this effectively means no more cache hits for all previous compiled > files. >=20 > Hmm. Maybe I could hack ccache to make it ignore the modification > timestamp... Hmmm. Room for foot shooting... Hmmm. >=20 ccache can be useful with "make all". But with buildworld, since the compiler is alwys rebuilt, ccache is only useful with -DNOCLEAN, when the compiler is not upgraded. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRI8tqRfpzJluFF4RAnqIAJ4tpQRM5E1HcOUOGng3CxMHdrU91QCeKmaS FK/jrhlA+v2loArX3uKPv9I= =7cQT -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 18:23:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 357FE16A4CE; Sun, 12 Sep 2004 18:23:01 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3B4243D3F; Sun, 12 Sep 2004 18:23:00 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8CIMoQI051153; Sun, 12 Sep 2004 11:22:54 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409121822.i8CIMoQI051153@gw.catspoiler.org> Date: Sun, 12 Sep 2004 11:22:50 -0700 (PDT) From: Don Lewis To: nork@FreeBSD.org In-Reply-To: <200409120917.i8C9HoXl002036@sakura.ninth-nine.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: takawata@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: stephane@FreeBSD.org Subject: Re: [PANIC] snd_sb16 on 5.3-BETA4 over qemu are fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 18:23:01 -0000 On 12 Sep, Norikatsu Shigemura wrote: > snd_sb16 on 5.3-BETA4 over qemu(modified by nork and takawata) > causes panic. But this is well-known problem as kern/71189. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=71189 > > I confirmed that this patch is good. Anyone, would you please > commit to 6-current and 5.3 branch? I just commited the patch to 6-CURRENT. I'll commit it to RELENG_5 in a few days, with re@ approval. From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 19:42:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61E8A16A4CE; Sun, 12 Sep 2004 19:42:11 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1E0243D3F; Sun, 12 Sep 2004 19:42:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8CJgArv070412; Sun, 12 Sep 2004 15:42:10 -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.12.11/8.12.11) with ESMTP id i8CJgAYp023134; Sun, 12 Sep 2004 15:42:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4740F7303F; Sun, 12 Sep 2004 15:42:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040912194210.4740F7303F@freebsd-current.sentex.ca> Date: Sun, 12 Sep 2004 15:42:10 -0400 (EDT) Subject: [releng_5 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 19:42:11 -0000 TB --- 2004-09-12 18:14:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-12 18:14:11 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2004-09-12 18:14:11 - checking out the source tree TB --- 2004-09-12 18:14:11 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2004-09-12 18:14:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-12 18:22:14 - building world (CFLAGS=-O -pipe) TB --- 2004-09-12 18:22:14 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-12 18:22:14 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-12 19:22:18 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-12 19:22:18 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-12 19:22:18 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Sep 12 19:22:18 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Sep 12 19:35:15 UTC 2004 TB --- 2004-09-12 19:35:15 - generating LINT kernel config TB --- 2004-09-12 19:35:15 - cd /home/tinderbox/RELENG_5/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-12 19:35:15 - /usr/bin/make -B LINT TB --- 2004-09-12 19:35:15 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-12 19:35:15 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-12 19:35:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 12 19:35:15 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2483: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2004-09-12 19:42:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-12 19:42:10 - ERROR: failed to build lint kernel TB --- 2004-09-12 19:42:10 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 19:57:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC29D16A4CE; Sun, 12 Sep 2004 19:57:50 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADD0343D1F; Sun, 12 Sep 2004 19:57:49 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.100] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i8CJvcMu030267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Sep 2004 21:57:41 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4144AA29.2020003@portaone.com> Date: Sun, 12 Sep 2004 22:57:29 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> <20040912112411.GA62181@schweikhardt.net> <20040912140311.GA60265@schweikhardt.net> <20040912180221.GB18232@ip.net.ua> In-Reply-To: <20040912180221.GB18232@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Kris Kennaway cc: Roman Kurakin cc: portmgr@FreeBSD.ORG cc: current@FreeBSD.ORG cc: Jens Schweikhardt Subject: Re: ccache support for make buildworld/make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 19:57:50 -0000 I have in mind extension for ccache which would allow it to be used with buildworld. Instead of using hashed values of compiler binary size and its last modification time, ccache should be using hash of the compiler binary. To avoid hashing several megabytes worth image on each invocation, compiler binary hash value can be by itself cached using hashed values of compiler binary size and its last modification time. Since linking the same objects from the cache is likely to produce the same binary, bootstrap compiler generated on the second ccached buildworld will be the same as one generated on the first one. -Maxim Ruslan Ermilov wrote: > On Sun, Sep 12, 2004 at 04:03:11PM +0200, Jens Schweikhardt wrote: > >>Following up myself, >> >>On Sun, Sep 12, 2004 at 01:24:11PM +0200, Jens Schweikhardt wrote: >># On Wed, Aug 25, 2004 at 11:33:42AM -0700, Kris Kennaway wrote: >># ... >># # BTW, I don't think there's anything to set up..you just set >># # CC="ccache cc" or similar. >> >>I've investigated further and found that the cc which is used >>after bootstrapping uses a different start for include path >>search, e.g. >> >>/usr/bin/cc -v ... >>#include "..." search starts here: >>#include <...> search starts here: >> /usr/include >>End of search list. >> >>/usr/obj/share/HEAD/src/i386/usr/bin/cc -v ... >>#include "..." search starts here: >>#include <...> search starts here: >> /usr/obj/share/HEAD/src/i386/usr/include >>End of search list. >> >>This is why the includes are not found when ccache is forced to use >>/usr/bin/cc. Which somewhat defeats the purpose of ccache: if the >>build switches compilers, ccache only speeds up the bootstrapping >>up to that point. Unfortunately, ccache also hashes the compiler's >>modification timestamp, so each time a new cc is used in the build, >>this effectively means no more cache hits for all previous compiled >>files. >> >>Hmm. Maybe I could hack ccache to make it ignore the modification >>timestamp... Hmmm. Room for foot shooting... Hmmm. >> > > ccache can be useful with "make all". But with buildworld, since > the compiler is alwys rebuilt, ccache is only useful with -DNOCLEAN, > when the compiler is not upgraded. > > > Cheers, From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 19:58:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8351D16A4CE; Sun, 12 Sep 2004 19:58:17 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 197FE43D45; Sun, 12 Sep 2004 19:58:17 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8CJwGts072923; Sun, 12 Sep 2004 15:58:16 -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.12.11/8.12.11) with ESMTP id i8CJwGkm094598; Sun, 12 Sep 2004 15:58:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4BA1C7303F; Sun, 12 Sep 2004 15:58:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040912195816.4BA1C7303F@freebsd-current.sentex.ca> Date: Sun, 12 Sep 2004 15:58:16 -0400 (EDT) Subject: [releng_5 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 19:58:17 -0000 TB --- 2004-09-12 19:42:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-12 19:42:10 - starting RELENG_5 tinderbox run for powerpc/powerpc TB --- 2004-09-12 19:42:10 - checking out the source tree TB --- 2004-09-12 19:42:10 - cd /home/tinderbox/RELENG_5/powerpc/powerpc TB --- 2004-09-12 19:42:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-12 19:50:04 - building world (CFLAGS=-O -pipe) TB --- 2004-09-12 19:50:04 - cd /home/tinderbox/RELENG_5/powerpc/powerpc/src TB --- 2004-09-12 19:50:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REP.c -o asn1_TGS_REP.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REQ.c -o asn1_TGS_REQ.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_Ticket.c -o asn1_Ticket.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TicketFlags.c -o asn1_TicketFlags.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TransitedEncoding.c -o asn1_TransitedEncoding.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_UNSIGNED.c -o asn1_UNSIGNED.So building shared library libasn1.so.7 Abort trap (core dumped) *** Error code 134 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. TB --- 2004-09-12 19:58:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-12 19:58:16 - ERROR: failed to build world TB --- 2004-09-12 19:58:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 20:07:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3768516A4CE for ; Sun, 12 Sep 2004 20:07:55 +0000 (GMT) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50C3F43D45 for ; Sun, 12 Sep 2004 20:07:53 +0000 (GMT) (envelope-from keramida@linux.gr) Received: (qmail 17185 invoked by uid 207); 12 Sep 2004 20:07:52 -0000 Received: from keramida@linux.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.47):. Processed in 0.995955 secs); 12 Sep 2004 20:07:52 -0000 Received: from dialup47.ach.sch.gr (HELO gothmog.gr) ([81.186.70.47]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Sep 2004 20:07:50 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i8CHOGgb001144 for ; Sun, 12 Sep 2004 20:24:16 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i8CFNpiJ024356; Sun, 12 Sep 2004 18:23:51 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sun, 12 Sep 2004 18:23:51 +0300 From: Giorgos Keramidas To: Rob Message-ID: <20040912152350.GB54693@gothmog.gr> References: <4140AFB0.6020002@pythonemproject.com> <4140C687.3080406@linuxpowered.com> <4140C9A7.9020407@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140C9A7.9020407@pythonemproject.com> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Mergemaster and a mess of /etc (was: Re: Still getting warning messages for rc.conf & default/rc.conf entries) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 20:07:55 -0000 On 2004-09-09 14:22, Rob wrote: > I will probably recompile the whole system. Have only used mergemaser > once, and somehow everything became a mess. Now I just compare > timestamps and do it manually. You can actually do this fast with the > right technique. Until I started using mergemaster almost exclusively, I used to update my /etc with the following sequence of steps: # cd /usr/src/etc # mkdir /tmp/temproot # make DESTDIR="/tmp/temproot" distrib-dirs # make DESTDIR="/tmp/temproot" distribution # cd /tmp/temproot ; diff -ruN /etc etc > /tmp/patchfile Then I manually edited /tmp/patchfile and applied it to my /etc taking care to run cap_mkdb on /etc/login.conf and pwd_mkdb if /etc/passwd was changed. All these can be handled by mergemaster just fine, though. I still do run the same sequence of steps from time to time, but only as a check to make sure that my /etc doesn't contain stale custom files (not included as part of the base system source) that I created some time ago and then forgot to update or delete when they became useless. To make a long story short, what exactly is it about mergemaster that gives you difficulties and why do you think that your /etc is a mess? A good way to find out is to run the commands shown above and then post the diff output saved in `/tmp/patchfile' to me. I'll check the differences of your /etc from the /usr/src/etc sources and tell you what I find out. * Note: the patchfile might contain critical information (such as the encrypted password of your root account). A bit of caution and a bit of careful editing of the file, to avoid posting sensitive information to a stranger like me (or even worse to a public list), would be fine. Just make sure you don't strip off useful stuff too. - Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 20:07:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E30E16A4CE for ; Sun, 12 Sep 2004 20:07:56 +0000 (GMT) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B168743D45 for ; Sun, 12 Sep 2004 20:07:55 +0000 (GMT) (envelope-from keramida@linux.gr) Received: (qmail 17231 invoked by uid 207); 12 Sep 2004 20:07:54 -0000 Received: from keramida@linux.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.47):. Processed in 1.187073 secs); 12 Sep 2004 20:07:54 -0000 Received: from dialup47.ach.sch.gr (HELO gothmog.gr) ([81.186.70.47]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Sep 2004 20:07:52 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i8CHOGgZ001144 for ; Sun, 12 Sep 2004 20:24:16 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i8CFbAW5024399; Sun, 12 Sep 2004 18:37:10 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sun, 12 Sep 2004 18:37:10 +0300 From: Giorgos Keramidas To: Rob Message-ID: <20040912153710.GC54693@gothmog.gr> References: <4140C31C.8020801@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140C31C.8020801@pythonemproject.com> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Re: warning messages from root mount until login, also my rc.conf file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 20:07:56 -0000 On 2004-09-09 13:54, Rob wrote: > Sorry about attaching files but can't seem to put them inline with > mozilla. Perhaps Sylpheed would work better. Copy/paste works in mozilla as expected, but you should probably stick to attachments for material that the text formatting matters at all, since Mozilla and practically all the GUI mailers that I've tried tend to do strange and evil things to the formatting of text. > #!/bin/sh > # > [snip a file that looks a lot like a copy of defaults/rc.conf in /etc]. Hmmm, this is wrong. Definitely wrong. The `rc.conf' file in /etc is meant to be a much smaller file than `/etc/defaults/rc.conf' and it most certainly does *NOT* need an initial #!/bin/sh line. The `/etc/rc.conf' file is not supposed to be a copy of the entire `/etc/defaults/rc.conf' file. It should only contain overrides (as the comment of the first paragraph below mentions: > # This is rc.conf - a file full of useful variables that you can set > # to change the default startup behavior of your system. You should > # not edit this file! Put any overrides into one of the ${rc_conf_files} > # instead and you will be able to update these defaults later without > # spamming your local configuration information. If this is not /etc/rc.conf but /etc/defaults/rc.conf please read again the comments above. You should not edit this file directly! If this is your /etc/rc.conf though, make sure you trim away whatever is not needed. An rc.conf file that would work fine for a workstation with one network interface card and several customizations for local services and/or options could look like this (most of this is copied from my own rc.conf at home): # system console options: cursor="destructive" keyrate="200.35" # misc options: clear_tmp_enable="YES" dumpdev="/dev/ad0s3b" # network related options: hostname="pc15.example.net" network_interfaces="lo0 sis0" ifconfig_lo0="inet 127.0.0.1" ifconfig_sis0="inet 192.168.0.30" # firewall setup: firewall_enable="YES" firewall_quiet="YES" firewall_logging="YES" firewall_type="/etc/ipfw.rules" # 1. enabled services: usbd_enable="YES" syslogd_enable="YES" syslogd_flags="-s -s" # 2. disabled services: inetd_enable="NO" sshd_enable="NO" rpc_lockd_enable="NO" rpc_statd_enable="NO" portmap_enable="NO" devd_enable="NO" - Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 20:10:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2B6216A4D2 for ; Sun, 12 Sep 2004 20:10:43 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D3C43D39 for ; Sun, 12 Sep 2004 20:10:43 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8CKAUhC010329; Sun, 12 Sep 2004 16:10:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8CKAU85010324; Sun, 12 Sep 2004 16:10:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 12 Sep 2004 16:10:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Guibert de Bruet In-Reply-To: <20040912130336.R84468@alpha.siliconlandmark.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 20:10:44 -0000 On Sun, 12 Sep 2004, Andre Guibert de Bruet wrote: > Using an rl-based network card, I am able to transfer data without any > problems. Any idea who the nge maintainer is? I'm not sure we have an nge maintainer, but I'm also not sure it's needed much maintenance (perhaps until now). Bill Paul wrote it, I believe, however. I'm thinking there are a couple of things we should try doing: - First, we should confirm that Giant really is properly held in some strategic places in the driver. I.e., slap down GIANT_REQUIRED in a bunch of interesting looking places (perhaps the head of most of the functions). We could be entering the ioctl code w/o Giant, perhaps, or the watch dog. - Attempt to identify whether or not the corruption corresponds with other failure modes that may be present, such as packet loss. Perhaps we're looking at a problem with reassembly and/or retransmission. It would be useful to know, for example, if the counters relating to TCP packet loss go up at about the time corruption occurs. - We should probably build a test tool to characterize the corruption a bit better. We could potentially start out just by dd'ing a big file of zeros through netcat between two hosts using if_nge, and confirm that the zeros get there in one piece, and then try with more complex data patterns that would reveal improper ordering, etc. - For grins, could you try running the same software with TCP SACK turned off and confirm that the problem is still present? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 20:13:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ECFD16A4CE for ; Sun, 12 Sep 2004 20:13:57 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE0A143D46 for ; Sun, 12 Sep 2004 20:13:56 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i8CKDuSm043734 for ; Sun, 12 Sep 2004 15:13:56 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Sun, 12 Sep 2004 15:13:56 -0500 (CDT) Message-ID: <54544.66.13.175.242.1095020036.squirrel@mail.ringofsaturn.com> In-Reply-To: <59222.66.13.175.242.1095011001.squirrel@mail.ringofsaturn.com> References: <1131.66.13.175.243.1094958979.squirrel@mail.ringofsaturn.com> <20040912051028.GA74510@hub.freebsd.org> <62869.66.13.175.242.1094996122.squirrel@mail.ringofsaturn.com> <4144891F.2070308@elischer.org> <59222.66.13.175.242.1095011001.squirrel@mail.ringofsaturn.com> Date: Sun, 12 Sep 2004 15:13:56 -0500 (CDT) From: "Rusty Nejdl" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on tethys.ringofsaturn.com X-Virus-Status: Clean Subject: Re: Freeze up on Beta-4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.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, 12 Sep 2004 20:13:57 -0000 One other thing that has come up with moving to 4BSD as my scheduler and running BETA4 is that now WINE won't stop running. With Beta3 and ULE as my scheduler, I could run MSMoney within wine just fine and close it just fine. Now, when I close the program, wine stays around and uses 100% of my cpu. A kill -9 must be used to stop the process. Thanks! Rusty From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 20:16:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F3216A4CE for ; Sun, 12 Sep 2004 20:16:13 +0000 (GMT) Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0BDC43D1D for ; Sun, 12 Sep 2004 20:16:12 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by fed1rmmtao06.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040912201612.OMTG27594.fed1rmmtao06.cox.net@mezz.mezzweb.com> for ; Sun, 12 Sep 2004 16:16:12 -0400 Date: Sun, 12 Sep 2004 15:16:14 -0500 To: freebsd-current@freebsd.org From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.54 (Linux, build 751) Subject: What's default value of -ftemplate-depth in GCC 3.4.2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 20:16:13 -0000 Hello, I am not sure if I am right, but I have a feel that it is possible that GCC has forgotten to make the change in the document. Or, maybe someone change the GCC 3.4.2's default in FreeBSD? Current, in the document said that the default value is 17 but it looks like it's more than 17 to me. http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C---Dialect-Options.html#C++%20Dialect%20Options ============================================= -ftemplate-depth-n Set the maximum instantiation depth for template classes to n. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17. ============================================= I am working on the games/wesnoth update to 0.8.4 and it will fail build on FreeBSD 4.x w/ GCC 2.9x. But, it doesn't fail the build on FreeBSD 5.x w/ GCC 3.4.2. The error looks like this: ============================================= In file included from display.hpp:17, from font.hpp:19, from about.cpp:15: /usr/include/g++/stl_iterator.h: In function `void destroy >::frame *>(animated >::frame *, animated >::frame *)': /usr/include/g++/stl_iterator.h:154: template instantiation depth exceeds maximum of 17 /usr/include/g++/stl_iterator.h:154: (use -ftemplate-depth-NN to increase the maximum) /usr/include/g++/stl_iterator.h:154: instantiating `iterator_traits >::frame *>' [...goes on...] ============================================= So, I added the -ftemplate-depth-20 and it was insteresting that it will fail the build on FreeBSD 5.x w/ GCC 3.4.2 now. Changed it to 45 and it successed. So... This is what it makes me think that GCC team might have change something that is undocumented. Althought, I didn't check the changelog lower than 3.4.1. I don't know where the right place for me to check the default value of -ftemplate-depth. The developer of Wesnoth said that his source code doesn't has more than 10 template depth and said that FreeBSD 4.x's compiler has the bug... I am not sure if he is right, since if I put -ftemplate-depth-20 and it will fail on GCC 3.4.2 either. One more thing, how can I count the template depth in any source code? Cheers, Mezz -- mezz7 at cox.net - mezz at FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 21:30:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 029D916A4CE for ; Sun, 12 Sep 2004 21:30:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA32343D58 for ; Sun, 12 Sep 2004 21:30:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8CLUS5k011830; Sun, 12 Sep 2004 17:30:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8CLURvn011827; Sun, 12 Sep 2004 17:30:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 12 Sep 2004 17:30:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Guibert de Bruet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: 6-CURRENT Network stack issues w/SMP? (Was: Re: TreeListfailed: Network write failure: ChannelMux.ProtocolError) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 21:30:41 -0000 On Sun, 12 Sep 2004, Robert Watson wrote: > On Sun, 12 Sep 2004, Andre Guibert de Bruet wrote: > > > Using an rl-based network card, I am able to transfer data without any > > problems. Any idea who the nge maintainer is? > > I'm not sure we have an nge maintainer, but I'm also not sure it's > needed much maintenance (perhaps until now). Bill Paul wrote it, I > believe, however. I'm thinking there are a couple of things we should > try doing: Another thing to try is to use the ping command with a large packet size (maybe just below MTU) and relatively rapid rate to see if it reports any data corruption. That might help us confirm whether this is isolated to UDP or not. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 23:22:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 972D516A4F1 for ; Sun, 12 Sep 2004 23:22:43 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1497B43D1D for ; Sun, 12 Sep 2004 23:22:43 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc13) with ESMTP id <2004091223224201600holrue> (Authid: europax); Sun, 12 Sep 2004 23:22:42 +0000 Message-ID: <4144DA7C.5070103@pythonemproject.com> Date: Sun, 12 Sep 2004 16:23:40 -0700 From: Rob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <4140AFB0.6020002@pythonemproject.com> <4140C687.3080406@linuxpowered.com> <4140C9A7.9020407@pythonemproject.com> <20040912152350.GB54693@gothmog.gr> In-Reply-To: <20040912152350.GB54693@gothmog.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Mergemaster and a mess of /etc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@pythonemproject.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, 12 Sep 2004 23:22:43 -0000 Giorgos Keramidas wrote: >On 2004-09-09 14:22, Rob wrote: > > >>I will probably recompile the whole system. Have only used mergemaser >>once, and somehow everything became a mess. Now I just compare >>timestamps and do it manually. You can actually do this fast with the >>right technique. >> >> > >Until I started using mergemaster almost exclusively, I used to update my >/etc with the following sequence of steps: > > # cd /usr/src/etc > # mkdir /tmp/temproot > # make DESTDIR="/tmp/temproot" distrib-dirs > # make DESTDIR="/tmp/temproot" distribution > # cd /tmp/temproot ; diff -ruN /etc etc > /tmp/patchfile > >Then I manually edited /tmp/patchfile and applied it to my /etc taking care >to run cap_mkdb on /etc/login.conf and pwd_mkdb if /etc/passwd was changed. > >All these can be handled by mergemaster just fine, though. I still do run >the same sequence of steps from time to time, but only as a check to make >sure that my /etc doesn't contain stale custom files (not included as part >of the base system source) that I created some time ago and then forgot to >update or delete when they became useless. > >To make a long story short, what exactly is it about mergemaster that gives >you difficulties and why do you think that your /etc is a mess? A good way >to find out is to run the commands shown above and then post the diff >output saved in `/tmp/patchfile' to me. I'll check the differences of your >/etc from the /usr/src/etc sources and tell you what I find out. > >* Note: the patchfile might contain critical information (such as the > encrypted password of your root account). A bit of caution and a bit of > careful editing of the file, to avoid posting sensitive information to a > stranger like me (or even worse to a public list), would be fine. Just > make sure you don't strip off useful stuff too. > >- Giorgos > >_______________________________________________ >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" > > > Thank you for information. I think the problem is not mergemaster, but me. I've just temporarilly gotten burnt out on computers. I'm sure in a week or so I will be fine. ;Rob From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 23:30:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB5916A4CE for ; Sun, 12 Sep 2004 23:30:24 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7216A43D39 for ; Sun, 12 Sep 2004 23:30:24 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc13) with ESMTP id <2004091223302301600hli93e> (Authid: europax); Sun, 12 Sep 2004 23:30:23 +0000 Message-ID: <4144DC4F.10209@pythonemproject.com> Date: Sun, 12 Sep 2004 16:31:27 -0700 From: Rob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <4140C31C.8020801@pythonemproject.com> <20040912153710.GC54693@gothmog.gr> In-Reply-To: <20040912153710.GC54693@gothmog.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: warning messages from root mount until login, also my rc.conf file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@pythonemproject.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, 12 Sep 2004 23:30:24 -0000 Giorgos Keramidas wrote: >On 2004-09-09 13:54, Rob wrote: > > >>Sorry about attaching files but can't seem to put them inline with >>mozilla. Perhaps Sylpheed would work better. >> >> > >Copy/paste works in mozilla as expected, but you should probably stick >to attachments for material that the text formatting matters at all, >since Mozilla and practically all the GUI mailers that I've tried tend >to do strange and evil things to the formatting of text. > > > >>#!/bin/sh >># >>[snip a file that looks a lot like a copy of defaults/rc.conf in /etc]. >> >> > >Hmmm, this is wrong. Definitely wrong. The `rc.conf' file in /etc is >meant to be a much smaller file than `/etc/defaults/rc.conf' and it most >certainly does *NOT* need an initial #!/bin/sh line. > >The `/etc/rc.conf' file is not supposed to be a copy of the entire >`/etc/defaults/rc.conf' file. It should only contain overrides (as the >comment of the first paragraph below mentions: > > > >># This is rc.conf - a file full of useful variables that you can set >># to change the default startup behavior of your system. You should >># not edit this file! Put any overrides into one of the ${rc_conf_files} >># instead and you will be able to update these defaults later without >># spamming your local configuration information. >> >> > >If this is not /etc/rc.conf but /etc/defaults/rc.conf please read again >the comments above. You should not edit this file directly! > >If this is your /etc/rc.conf though, make sure you trim away whatever is >not needed. An rc.conf file that would work fine for a workstation with >one network interface card and several customizations for local services >and/or options could look like this (most of this is copied from my own >rc.conf at home): > > # system console options: > cursor="destructive" > keyrate="200.35" > > # misc options: > clear_tmp_enable="YES" > dumpdev="/dev/ad0s3b" > > # network related options: > hostname="pc15.example.net" > network_interfaces="lo0 sis0" > ifconfig_lo0="inet 127.0.0.1" > ifconfig_sis0="inet 192.168.0.30" > > # firewall setup: > firewall_enable="YES" > firewall_quiet="YES" > firewall_logging="YES" > firewall_type="/etc/ipfw.rules" > > # 1. enabled services: > usbd_enable="YES" > syslogd_enable="YES" > syslogd_flags="-s -s" > # 2. disabled services: > inetd_enable="NO" > sshd_enable="NO" > rpc_lockd_enable="NO" > rpc_statd_enable="NO" > portmap_enable="NO" > devd_enable="NO" > >- Giorgos > >_______________________________________________ >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" > > > With a couple of exceptions, like nfs, I didnt think I had unused info in there. I will take a look at it and also what I posted. Maybe I goofed and did post defaults/etc Rob From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 00:13:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2335616A4CE for ; Mon, 13 Sep 2004 00:13:42 +0000 (GMT) Received: from demonserver.de (demonserver.de [217.160.109.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3697A43D45 for ; Mon, 13 Sep 2004 00:13:41 +0000 (GMT) (envelope-from email@demonlord.de) Received: from localhost (demonserver [127.0.0.1]) by demonserver.de (Postfix) with ESMTP id 1D45F16B5A8 for ; Mon, 13 Sep 2004 02:13:16 +0200 (CEST) Received: from demonserver.de ([127.0.0.1]) by localhost (demonserver.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20913-05 for ; Mon, 13 Sep 2004 02:13:15 +0200 (CEST) Received: from [172.16.100.5] (i538781F4.versanet.de [83.135.129.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by demonserver.de (Postfix) with ESMTP id 2DE6D16B501 for ; Mon, 13 Sep 2004 02:13:14 +0200 (CEST) Message-ID: <4144E620.8070603@demonlord.de> Date: Mon, 13 Sep 2004 02:13:20 +0200 From: Christian Reiss User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig504176DDA0B8D8FF92ECE7A4" X-Virus-Scanned: by amavisd-new at demonserver.de using F-Prot. Subject: FreeBSD / PostFix / Sasl / PAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 00:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig504176DDA0B8D8FF92ECE7A4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greetings! I hope I picked the right discussion list for this. I am having trouble with FreeBSD-latest and Postfix / SASL2 / PAM authentification. It seems the saslauthd is core'dumping all the time, that is, when a user tried to auth him/herself per smtp. PostFix uses a configuration file that is known to work on another system, I tripple checked that. I am pretty sure the problem lies within the sasl2 stuff somewhere. Nearly all HowTo's on the net either deal with Sasl/Pam_mysql or deal with pam (what i need) but dont help me. /var/log/maillog --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- Sep 12 23:55:54 alpha-labs postfix/smtpd[20053]: warning: user.host.com[1.2.3.4]: SASL PLAIN authentication failed Sep 12 23:55:54 alpha-labs postfix/smtpd[20053]: warning: SASL authentication failure: size read failed Sep 12 23:55:54 alpha-labs postfix/smtpd[20053]: warning: user.host.com[1.2.3.4]: SASL LOGIN authentication failed Sep 12 23:56:02 alpha-labs postfix/smtpd[20053]: lost connection after AUTH from user.host.com[1.2.3.4] Sep 12 23:56:02 alpha-labs postfix/smtpd[20053]: disconnect from user.host.com[1.2.3.4] --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- /var/log/messages --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- Sep 12 23:55:54 myhost kernel: pid 20047 (saslauthd), uid 0: exited on signal 11 (core dumped) Sep 12 23:55:54 myhost kernel: pid 20048 (saslauthd), uid 0: exited on signal 11 (core dumped) --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- uname -a --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- FreeBSD alpha-labs 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Sep 7 15:13:48 CEST 2004 root@:/usr/obj/usr/src/sys/ALPHALABS i386 --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- root@alpha-labs:~# postconf -m static sdbm cidr pcre regexp environ proxy btree unix hash --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- root@alpha-labs:/usr/ports/security/cyrus-sasl2-saslauthd# saslauthd -a pam -d saslauthd[20046] :main : num_procs : 5 saslauthd[20046] :main : mech_option: NULL saslauthd[20046] :main : run_path : /var/state/saslauthd saslauthd[20046] :main : auth_mech : pam saslauthd[20046] :ipc_init : using accept lock file: /var/state/saslauthd/mux.accept saslauthd[20046] :detach_tty : master pid is: 0 saslauthd[20046] :ipc_init : listening on socket: /var/state/saslauthd/mux saslauthd[20046] :main : using process model saslauthd[20046] :have_baby : forked child: 20047 saslauthd[20047] :get_accept_lock : acquired accept lock saslauthd[20046] :have_baby : forked child: 20048 saslauthd[20046] :have_baby : forked child: 20049 saslauthd[20046] :have_baby : forked child: 20050 saslauthd[20048] :get_accept_lock : acquired accept lock saslauthd[20047] :rel_accept_lock : released accept lock saslauthd[20046] :handle_sigchld : child exited: 20047 saslauthd[20049] :get_accept_lock : acquired accept lock saslauthd[20048] :rel_accept_lock : released accept lock saslauthd[20046] :handle_sigchld : child exited: 20048 --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- /usr/local/lib/sasl2/smtpd.conf --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- pwcheck_method: saslauthd mech_list: plain login --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- /etc/pam.d/smtp --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- auth required pam_unix.so no_warn try_first_pass --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- excert of /usr/local/etc/postfix/main.cf --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- excert of /etc/groups --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- mail:*:6:postfix --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- /var/state/saslauthd --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- total 580 drwxrwx--- 2 cyrus mail 512B Sep 12 23:55 . drwxr-xr-x 3 root wheel 512B Sep 12 23:51 .. srwxrwxrwx 1 root mail 0B Sep 12 23:55 mux -rw------- 1 root mail 0B Sep 12 23:55 mux.accept -rw------- 1 root mail 560K Sep 12 23:55 saslauthd.core --w------- 1 root mail 0B Sep 12 23:55 saslauthd.pid.lock --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- gdb saslauthd saslauthd.core --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- #0 0x2829b923 in strcasecmp () from /lib/libc.so.5 #1 0x282f711c in login_access () from /usr/lib/pam_login_access.so.2 #2 0x282f7004 in login_access () from /usr/lib/pam_login_access.so.2 #3 0x282f6e59 in login_access () from /usr/lib/pam_login_access.so.2 #4 0x282f6d43 in login_access () from /usr/lib/pam_login_access.so.2 #5 0x282f6aa0 in pam_sm_acct_mgmt () from /usr/lib/pam_login_access.so.2 #6 0x28203377 in openpam_dispatch () from /usr/lib/libpam.so.2 #7 0x282028b4 in pam_acct_mgmt () from /usr/lib/libpam.so.2 #8 0x0804a324 in ?? () #9 0x08056000 in ?? () #10 0x80000000 in ?? () #11 0xbfbfe498 in ?? () #12 0xbfbfe494 in ?? () #13 0xbfbfe090 in ?? () #14 0x08056000 in ?? () #15 0x0804a0b4 in ?? () #16 0xbfbfe4a0 in ?? () #17 0xbfbfead0 in ?? () #18 0xbfbfe9c0 in ?? () #19 0x08056000 in ?? () #20 0x0804d21a in ?? () #21 0xbfbfead0 in ?? () #22 0xbfbfe9c0 in ?? () #23 0xbfbfe778 in ?? () #24 0x0804d255 in ?? () #25 0xbfbfead0 in ?? () #26 0xbfbfe9c0 in ?? () #27 0xbfbfe8b0 in ?? () #28 0xbfbfe7a0 in ?? () #29 0x282ca4b0 in __sF () from /lib/libc.so.5 #30 0x08050970 in ?? () #31 0xbfbfead0 in ?? () #32 0x00000000 in ?? () #33 0x282ca4b0 in __sF () from /lib/libc.so.5 #34 0x00000000 in ?? () #35 0xbfbfe7a8 in ?? () #36 0x282b15aa in __vfprintf () from /lib/libc.so.5 Previous frame inner to this frame (corrupt stack?) --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- Any help would be gladly appreciated.. Its the fourth night I spent on this problem. *sigh* Thanks in advance, Christian. -- Christian Reiss demonserver.de "Don't give up, lose interest." GPG Key ID 02FF71B2 . Public Key can be obtained here: http://www.demonlord.de/pgp.txt OpenPGP Keyserver - http://pgp.demonserver.de --------------enig504176DDA0B8D8FF92ECE7A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBROYiGLayMgL/cbIRAvbMAJoDRBtouJIqJ+P2OBLqBE/nO+jpTwCffdW6 lRDn/7jXqDWBARsQ884veII= =K0/1 -----END PGP SIGNATURE----- --------------enig504176DDA0B8D8FF92ECE7A4-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 00:30:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A960316A4CE for ; Mon, 13 Sep 2004 00:30:02 +0000 (GMT) Received: from mail.mcneil.com (rrcs-24-199-45-54.west.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7379A43D41 for ; Mon, 13 Sep 2004 00:30:02 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id F170AF1960 for ; Sun, 12 Sep 2004 17:30:01 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00642-06 for ; Sun, 12 Sep 2004 17:30:01 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 02789F1827 for ; Sun, 12 Sep 2004 17:30:00 -0700 (PDT) From: Sean McNeil To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1095035400.56381.5.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 12 Sep 2004 17:30:00 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: kadmin core dumping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 00:30:02 -0000 I have had this problem for a very long time. I really haven't found anything I can point my finger at about this, but it seems like there is something wrong with the key generation: A simple thing like kadmin -l kadmin> init MCNEIL.COM would core dump with #11 0x0000000000000000 in ?? () #12 0x00000002009863ca in krb5_string_to_key_data_salt_opaque ( context=0xc0f02010, enctype=201589254, password= {length = 6, data = 0x408d78}, salt= {salttype = KRB5_PW_SALT, saltvalue = {length = 26, data = 0x50f320}}, opaque={length = 0, data = 0x0}, key=0x7) at /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/crypto.c:1007 #13 0x0000000200986321 in krb5_string_to_key_data_salt (context=0xcc182000, enctype=-955776509, password={length = 6, data = 0x408d78}, salt= {salttype = KRB5_PW_SALT, saltvalue = {length = 26, data = 0x50f320}}, key=0x7fffffffe858) I've always suspected that I have something old in my system that is causing this. Now I wonder if it isn't openssl from the ports. For some reason, kadmin is linked with libcrypto.so.3 instead of the libcrypto.so in /usr/lib: /usr/bin/kadmin: libkadm5clnt.so.7 => /usr/lib/libkadm5clnt.so.7 (0x200636000) libkadm5srv.so.7 => /usr/lib/libkadm5srv.so.7 (0x20073f000) libhdb.so.7 => /usr/lib/libhdb.so.7 (0x20084d000) libkrb5.so.7 => /usr/lib/libkrb5.so.7 (0x200960000) libroken.so.7 => /usr/lib/libroken.so.7 (0x200aa9000) libasn1.so.7 => /usr/lib/libasn1.so.7 (0x200bb9000) libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x200ce2000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x200f30000) libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x201049000) libreadline.so.4 => /lib/libreadline.so.4 (0x20114b000) libncurses.so.5 => /lib/libncurses.so.5 (0x201285000) libldap-2.2.so.7 => /usr/local/lib/libldap-2.2.so.7 (0x2013e0000) liblber-2.2.so.7 => /usr/local/lib/liblber-2.2.so.7 (0x201519000) libc.so.5 => /lib/libc.so.5 (0x201628000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x20182c000) libssl.so.3 => /usr/local/lib/libssl.so.3 (0x201944000) Could this be a problem, or is it just in there because sasl is? Sean From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 00:32:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24CEA16A4CF for ; Mon, 13 Sep 2004 00:32:39 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id D621943D45 for ; Mon, 13 Sep 2004 00:32:38 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from focus.dantavious.com (pcp04630633pcs.gambrl01.md.comcast.net[68.49.58.89]) by comcast.net (rwcrmhc11) with ESMTP id <200409130032380130051p7be> (Authid: dantavious); Mon, 13 Sep 2004 00:32:38 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Sun, 12 Sep 2004 20:42:29 -0400 User-Agent: KMail/1.7 References: <200409101624.21412.Lutz.Bichler@unibw-muenchen.de> In-Reply-To: <200409101624.21412.Lutz.Bichler@unibw-muenchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409122042.30075.dantavious@comcast.net> Subject: Re: Problem with snd_ich.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 00:32:39 -0000 On Friday 10 September 2004 10:24 am, Lutz Bichler wrote: Did you ever get an answer to yoru problem? I kinda was having the same problem. When booting up, I would be able to get sound wihen I play songs from the console. When I booted into kde 3.3 during the splash sreen I would lose the sound. If I want to have sound during the kde session I have to wait until kde is up and running then load snd_ich. If I log out of that current session I have to reboot and start the process all over.. Derrick > Hi, > > i have a "funny" problem with snd_ich on 5.3 Beta3. Whenever i boot my > machine, sound.ko and snd_ich.ko are loaded, but i do not get any sound > working. After unloading and reloading snd_ich.ko things work fine. Any > idea abou what going wrong at boot-time loading of the modules? > > Some information about my machine: > > lutz@medusa:~> cat /dev/sndstat > FreeBSD Audio Driver (newpcm) Installed devices: pcm0: (82801BA)> at io 0x1000, 0x2000 irq 5 bufsz 16384 kld snd_ich (1p/1r/0v > channels duplex default) > > lutz@medusa:~> pciconf -vl > pcm0@pci0:31:5: class=0x040100 card=0x0056110a chip=0x24458086 rev=0x04 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82801BA/BAM (ICH2/ICH2-M) AC'97 Audio Controller' > class = multimedia > subclass = audio > > Regards, > Lutz > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 00:36:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D84016A4CE for ; Mon, 13 Sep 2004 00:36:43 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C5343D2D for ; Mon, 13 Sep 2004 00:36:43 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 169F5304C for ; Sun, 12 Sep 2004 19:36:18 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01472-05 for ; Sun, 12 Sep 2004 19:36:13 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 2643E304A for ; Sun, 12 Sep 2004 19:36:13 -0500 (CDT) Message-ID: <4144EB8E.1080407@veldy.net> Date: Sun, 12 Sep 2004 19:36:30 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA25901D27301F95DB7C53D23" X-Virus-Scanned: by amavisd-new at veldy.net Subject: PF and FreeBSD 5.x? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 00:36:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA25901D27301F95DB7C53D23 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I noticed the existance of the /etc/pf.conf and /etc/pf.os. The file pf.conf makes reference to /usr/share/pf, which does not exist. Further looking through LINT, there does not appear to be a way to enable PF as opposed to IPFILTER or IPFIREWALL. So, is PF to be available for 5.3-RELEASE? If so, how can I expect to use this under the current 5.3-BETA4? Thanks in advance, Tom Veldhouse --------------enigA25901D27301F95DB7C53D23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBROuRARgTFXYf0wARApIZAJ4i5l2omrY1cNUr31ksUf4IgvUAlACfXe2G 9NgLU0tfl2d7Q+M7zXnpJ9s= =E1k7 -----END PGP SIGNATURE----- --------------enigA25901D27301F95DB7C53D23-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 00:47:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1167A16A4CE; Mon, 13 Sep 2004 00:47:32 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685DD43D54; Mon, 13 Sep 2004 00:47:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8D0mOMx026714; Sun, 12 Sep 2004 18:48:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4144ED69.6050107@samsco.org> Date: Sun, 12 Sep 2004 18:44:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org Subject: FreeBSD 5.3-BETA4 available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 00:47:33 -0000 The FreeBSD Release Engineering Team is proud to announce the availability of FreeBSD 5.3-BETA4. This is the fourth BETA of the 5.3 release cycle. It is intended for early adopters and those wishing to help find and/or fix bugs. The 5.3 release cycle will continue with weekly BETA builds while bugs are being fixed and features finalized. The schedule is at http://www.freebsd.org/releases/5.3R/schedule.html. Be sure to check the "Known issues" below, there are known problems still being worked on at this time. At this time the Release Engineering team anticipates releasing at least one more BETA snapshot before the first Release Candidate. The schedule will be updated for this shortly. Fixed and Enhancements made since BETA3: - ATA works on sparc64 and ia64 again. This was due to several bugs in busdma. sparc64 no longer defaults to having ATA DMA be off. - Better support for statically linked threaded programs in GDB. - Support for more Broadcom and Realtek-based NICs - Fixes for MSDOS internationalization support. - Many fixes for ATA including speed fixes for ICH* chips, better error recovery, and better support for devices that respond as both master and slave. - Various locking fixes for AIO, the network stack, and socket polling. - The default scheduler is now 4BSD. The switch was made in the interest maximizing stability for 5.3. Users are still encouraged to try the the ULE scheduler, though known bugs exist with it when PREEMPTION is also turned on. - Kernel debugging and malloc debugging options have been turned off for the remainder of the RELENG_5 branch. - Merge of the massive scheduler cleanup and bug fixes from 6-CURRENT. This addresses a number of stability problems that have existed for over 2 months including deadlocks, randomly aborted processes, and panics. This also improves the performance of the 4BSD scheduler by keeping idle processors busy during light and medium loads. Known issues in this release: - There are scattered reports of data corruption on SMP systems under high load. This could be due to a known bug in the gvinum subsystem, but it could be due to unknown factors. We are investigating this and hope to correct it soon. - pst(4) is known to cause a system panic during the boot time. - The Synaptics Touchpad mouse support is known to have issues with responsiveness. It can be disabled with 'hint.psm.0.flags="0x200"' in "/boot/device.hints". This will be resolved for the release. - There are reports of packet corruption with the nge(1) driver when the network stack is run without Giant. These are being investigated. A complete list of defects that will be fixed for the release can be found at http://www.freebsd.org/releases/5.3R/todo.html. Availability: For people wishing to upgrade older systems using cvsup(1) and the procedure described in src/UPDATING the CVS tag to use is RELENG_5 at this point. Note that like all RELENG_X branches this is an active development branch. We do not recommend those branches for normal use (for normal use RELENG_X_Y branches are more appropriate, e.g. RELENG_4_10 is the current stable branch). As of this writing, ISO images and FTP install directories are available for the following architectures: i386: all images available alpha: images will be available shortly amd64: all images available ia64: mini ISO available pc98: mini ISO available sparc64: mini ISO available, full disc1 will be available soon MD5 (5.3-BETA4-amd64-bootonly.iso) = 7f75a2e07f8bbcadd9b9e3d7cee06677 MD5 (5.3-BETA4-amd64-disc2.iso) = d98c8be8c48afcacffaa910241ca7f35 MD5 (5.3-BETA4-amd64-miniinst.iso) = 9a1fb23cfc58f7c4261a2150a5b28670 MD5 (5.3-BETA4-amd64-disc1.iso) = 678f953a4631db3aeb91120d9123d646 MD5 (5.3-BETA4-i386-bootonly.iso) = 82f3bd499d2241340bc219660f3acf1c MD5 (5.3-BETA4-i386-disc2.iso) = 7da064e4b47726873376a14becd840fd MD5 (5.3-BETA4-i386-miniinst.iso) = f333569c4436256740e8be8c68f8d54d MD5 (5.3-BETA4-i386-disc1.iso) = 380d3a63a817feeb1650e6b3d07505ce MD5 (5.3-BETA4-ia64-bootonly.iso) = ca272a954af6b5f10e1abb59fefd5d51 MD5 (5.3-BETA4-ia64-disc2.iso) = 189e6dd0a9d6be10ba5cd0d2e4ffd4ea MD5 (5.3-BETA4-ia64-miniinst.iso) = d5b38b5add52de5b00b9294af99ae5bb MD5 (5.3-BETA4-pc98-disc2.iso) = 855de6f83c403a4748d083c9759aa5ec MD5 (5.3-BETA4-pc98-miniinst.iso) = cfc61e3273757099c1e83589fcbd7495 MD5 (5.3-BETA4.tar.bz2) = e2853d340d12f340fe8eb482e0a1fc33 MD5 (5.3-BETA4-sparc64-bootonly.iso) = 07c4e060e41fc0bf78923d9fe4deac03 MD5 (5.3-BETA4-sparc64-disc2.iso) = dfe6f9eb046aa46e33d750572bd25c50 MD5 (5.3-BETA4-sparc64-miniinst.iso) = 4310a4f4cfefcafc9b3b902fe1763870 The Release Engineering Team From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:01:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 887C116A4D5 for ; Mon, 13 Sep 2004 01:01:09 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3616643D31 for ; Mon, 13 Sep 2004 01:01:09 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C6fDN-0006Pu-00; Mon, 13 Sep 2004 03:01:05 +0200 Received: from [84.128.134.217] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C6fDN-00029a-00; Mon, 13 Sep 2004 03:01:05 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Mon, 13 Sep 2004 02:59:44 +0200 User-Agent: KMail/1.6.2 References: <4144EB8E.1080407@veldy.net> In-Reply-To: <4144EB8E.1080407@veldy.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_JEPRB4dEnIyuBGM"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409130259.53355.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: "Thomas T. Veldhouse" Subject: Re: PF and FreeBSD 5.x? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:01:09 -0000 --Boundary-02=_JEPRB4dEnIyuBGM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 13 September 2004 02:36, Thomas T. Veldhouse wrote: > I noticed the existance of the /etc/pf.conf and /etc/pf.os. The file > pf.conf makes reference to /usr/share/pf, which does not exist. Further > looking through LINT, there does not appear to be a way to enable PF as > opposed to IPFILTER or IPFIREWALL. So, is PF to be available for > 5.3-RELEASE? If so, how can I expect to use this under the current > 5.3-BETA4? You can build pf into your kernel by putting: device pf device pflog device pfsync into your KERNCONF. The latter two are optional. Alternatively you can use = the=20 loadable module. In any case you can enable pf by setting: pf_enable=3D"YES" in /etc/rc.conf. For additional tweaks see the rc.conf(5) manpage. And yes,= =20 this is supposed to work in BETA4 "out-of-the-box". The missing share/pf is a shortcoming that should be addressed.=20 Maybe /etc/pf.conf should even be removed in order to avoid mergemaster (or= =20 the like) running over a good pf.conf. Can you submit the share/pf issue as a PR so that I keep track of it, pleas= e? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_JEPRB4dEnIyuBGM Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBRPEJXyyEoT62BG0RAigrAJ45HXPQ+OZD4agKFtt/RJzgcN5FEACeICXI GzQ4qZIiBqDNtnxXypfJJQE= =RHTE -----END PGP SIGNATURE----- --Boundary-02=_JEPRB4dEnIyuBGM-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:12:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CB3816A4CE for ; Mon, 13 Sep 2004 01:12:35 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4280043D41 for ; Mon, 13 Sep 2004 01:12:35 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 6640D304C; Sun, 12 Sep 2004 20:12:10 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01611-08; Sun, 12 Sep 2004 20:12:05 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 3A23A304A; Sun, 12 Sep 2004 20:12:05 -0500 (CDT) Message-ID: <4144F3F7.3070702@veldy.net> Date: Sun, 12 Sep 2004 20:12:23 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <4144EB8E.1080407@veldy.net> <200409130259.53355.max@love2party.net> In-Reply-To: <200409130259.53355.max@love2party.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E5DB4735BE66E8D769987E7" X-Virus-Scanned: by amavisd-new at veldy.net cc: freebsd-current@freebsd.org Subject: Re: PF and FreeBSD 5.x? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:12:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E5DB4735BE66E8D769987E7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Max Laier wrote: >Can you submit the share/pf issue as a PR so that I keep track of it, please? > > > Thanks! Will do. Tom Veldhouse --------------enig6E5DB4735BE66E8D769987E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBRPP6ARgTFXYf0wARAgoCAKCCYsFvMxQOkXDYVO0CnA1Rb/Hg1ACgpKba sUnkAw+xN1YRO71x+zPg/Eo= =HuGg -----END PGP SIGNATURE----- --------------enig6E5DB4735BE66E8D769987E7-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:13:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E314616A4D0 for ; Mon, 13 Sep 2004 01:13:54 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B5E343D58 for ; Mon, 13 Sep 2004 01:13:54 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id BAC364EFD9D; Mon, 13 Sep 2004 09:13:50 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id B81584EFD9A; Mon, 13 Sep 2004 09:13:50 +0800 (CST) Date: Mon, 13 Sep 2004 09:13:50 +0800 (CST) From: Tai-hwa Liang To: Mike Tancsa In-Reply-To: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> Message-ID: <0409130912018.25090@www.mmlab.cse.yzu.edu.tw> References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:13:55 -0000 On Sun, 12 Sep 2004, Mike Tancsa wrote: > > On the 4 different machines I tried (2 845 and 2 865 chipsets) none seem to > work with ichwd. Note, these boards do work with > http://freebsd.tamu.edu/wdog/ in RELENG_4 so I know the watchdog is not > disabled on the MB. Also, on one box here, I know ichwd worked at one > point ( ~ July ) but now it too gives > > ichwd0: on motherboard > ichwd0: unable to reserve SMI registers > device_attach: ichwd0 attach returned 6 > > or > ichwd0: on motherboard > ichwd0: unable to reserve SMI registers > device_attach: ichwd0 attach returned 6 That's exactly what I saw on the other three laptops(-CURRENT cvsup'ed about 3 days ago): * Toshiba Satellite 3000, Pentium III Mobile 1GHz ichwd module loaded ichwd_identify(): found ICH chipset: Intel 82801CAM watchdog timer ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 * Thinkpad R40, Mobile Celeron 2GHz ichwd module loaded ichwd_identify(): found ICH chipset: Intel 82801DBM watchdog timer ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 * Thinkpad T40, Centrino ichwd module loaded ichwd_identify(): found ICH chipset: Intel 82801DBM watchdog timer ichwd0: on motherboard ichwd0: unable to reserve SMI registers device_attach: ichwd0 attach returned 6 From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:30:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D17716A4CE for ; Mon, 13 Sep 2004 01:30:28 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF56743D1D for ; Mon, 13 Sep 2004 01:30:27 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8D1UJYF051718; Sun, 12 Sep 2004 18:30:23 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409130130.i8D1UJYF051718@gw.catspoiler.org> Date: Sun, 12 Sep 2004 18:30:19 -0700 (PDT) From: Don Lewis To: dantavious@comcast.net In-Reply-To: <200409122042.30075.dantavious@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: Problem with snd_ich.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:30:28 -0000 On 12 Sep, Derrick Edwards wrote: > On Friday 10 September 2004 10:24 am, Lutz Bichler wrote: > > Did you ever get an answer to yoru problem? I kinda was having the same > problem. When booting up, I would be able to get sound wihen I play songs > from the console. When I booted into kde 3.3 during the splash sreen I would > lose the sound. If I want to have sound during the kde session I have to wait > until kde is up and running then load snd_ich. If I log out of that current > session I have to reboot and start the process all over.. > Derrick > >> Hi, >> >> i have a "funny" problem with snd_ich on 5.3 Beta3. Whenever i boot my >> machine, sound.ko and snd_ich.ko are loaded, but i do not get any sound >> working. After unloading and reloading snd_ich.ko things work fine. Any >> idea abou what going wrong at boot-time loading of the modules? You might want to try this patch: Index: sys/dev/sound/pcm/channel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v retrieving revision 1.97 diff -u -r1.97 channel.c --- sys/dev/sound/pcm/channel.c 28 Feb 2004 19:47:02 -0000 1.97 +++ sys/dev/sound/pcm/channel.c 9 Sep 2004 20:41:18 -0000 @@ -405,9 +405,9 @@ if ((c->flags & CHN_F_MAPPED) || !(c->flags & CHN_F_TRIGGERED)) return; - chn_trigger(c, PCMTRIG_EMLDMARD); chn_dmaupdate(c); ret = chn_rdfeed(c); + chn_trigger(c, PCMTRIG_EMLDMARD); if (ret) printf("chn_rdfeed: %d\n", ret); @@ -417,15 +417,21 @@ static void chn_rdintr(struct pcm_channel *c) { - int ret; CHN_LOCKASSERT(c); /* tell the driver to update the primary buffer if non-dma */ - chn_trigger(c, PCMTRIG_EMLDMARD); /* update pointers in primary buffer */ chn_dmaupdate(c); /* ...and feed from primary to secondary */ - ret = chn_rdfeed(c); + chn_rdfeed(c); + chn_trigger(c, PCMTRIG_EMLDMARD); +} + +int +chn_hwunownedbufoffset(struct pcm_channel *c) +{ + return ((c->direction == PCMDIR_PLAY) ? sndbuf_getfreeptr(c->bufhard) : + sndbuf_getreadyptr(c->bufhard)); } /* Index: sys/dev/sound/pcm/channel.h =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.h,v retrieving revision 1.30 diff -u -r1.30 channel.h --- sys/dev/sound/pcm/channel.h 28 Feb 2004 19:47:02 -0000 1.30 +++ sys/dev/sound/pcm/channel.h 9 Sep 2004 20:36:34 -0000 @@ -93,6 +93,7 @@ void chn_intr(struct pcm_channel *c); int chn_wrfeed(struct pcm_channel *c); int chn_rdfeed(struct pcm_channel *c); +int chn_hwunownedbufoffset(struct pcm_channel *c); int chn_abort(struct pcm_channel *c); void chn_wrupdate(struct pcm_channel *c); Index: sys/dev/sound/pci/ich.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pci/ich.c,v retrieving revision 1.42 diff -u -r1.42 ich.c --- sys/dev/sound/pci/ich.c 16 Jul 2004 03:59:27 -0000 1.42 +++ sys/dev/sound/pci/ich.c 9 Sep 2004 20:36:10 -0000 @@ -336,11 +336,33 @@ { struct sc_chinfo *ch = data; struct sc_info *sc = ch->parent; + u_int32_t lbb, lbi, lvi, nlbi; switch (go) { case PCMTRIG_START: ch->run = 1; ich_wr(sc, ch->regbase + ICH_REG_X_BDBAR, (u_int32_t)(ch->desc_addr), 4); + lvi = ((chn_hwunownedbufoffset(ch->channel) + + ch->blkcnt * ch->blksz - 1) / ch->blksz) % ch->blkcnt; + ich_wr(sc, ch->regbase + ICH_REG_X_LVI, lvi, 1); + ich_wr(sc, ch->regbase + ICH_REG_X_CR, ICH_X_CR_RPBM | ICH_X_CR_LVBIE | ICH_X_CR_IOCE, 1); + break; + + case PCMTRIG_EMLDMAWR: + case PCMTRIG_EMLDMARD: + lvi = ich_rd(sc, ch->regbase + ICH_REG_X_LVI, 1); + lbi = lvi % ch->blkcnt; + lbb = lvi / ch->blkcnt; + nlbi = ((chn_hwunownedbufoffset(ch->channel) + + ch->blkcnt * ch->blksz - 1) / ch->blksz) % ch->blkcnt; + nlbi = (chn_hwunownedbufoffset(ch->channel) / ch->blksz + + ch->blkcnt - 1) % ch->blkcnt; + if (nlbi < lbi) + lbb = (lbb + 1) % (ICH_DTBL_LENGTH / ch->blkcnt); + lvi = lbb * ch->blkcnt + nlbi; + ich_wr(sc, ch->regbase + ICH_REG_X_LVI, lvi, 1); + /* restart channel in case DMA underflowed and shut down */ + /* XXX - track restarts? */ ich_wr(sc, ch->regbase + ICH_REG_X_CR, ICH_X_CR_RPBM | ICH_X_CR_LVBIE | ICH_X_CR_IOCE, 1); break; @@ -394,7 +416,7 @@ { struct sc_info *sc = (struct sc_info *)p; struct sc_chinfo *ch; - u_int32_t cbi, lbi, lvi, st, gs; + u_int32_t st, gs; int i; gs = ich_rd(sc, ICH_REG_GLOB_STA, 4) & ICH_GLOB_STA_IMASK; @@ -417,20 +439,6 @@ /* block complete - update buffer */ if (ch->run) chn_intr(ch->channel); - lvi = ich_rd(sc, ch->regbase + ICH_REG_X_LVI, 1); - cbi = ch->civ % ch->blkcnt; - if (cbi == 0) - cbi = ch->blkcnt - 1; - else - cbi--; - lbi = lvi % ch->blkcnt; - if (cbi >= lbi) - lvi += cbi - lbi; - else - lvi += cbi + ch->blkcnt - lbi; - lvi %= ICH_DTBL_LENGTH; - ich_wr(sc, ch->regbase + ICH_REG_X_LVI, lvi, 1); - } /* clear status bit */ ich_wr(sc, ch->regbase + From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:48:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72D1416A4CE for ; Mon, 13 Sep 2004 01:48:10 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C7243D39 for ; Mon, 13 Sep 2004 01:48:09 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9BA0E653D2; Mon, 13 Sep 2004 02:48:07 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51318-04-2; Mon, 13 Sep 2004 02:48:07 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-74.dsl.snfc21.pacbell.net [67.121.95.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id BFBAC65213; Mon, 13 Sep 2004 02:48:06 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 6882B63B3; Sun, 12 Sep 2004 18:48:04 -0700 (PDT) Date: Sun, 12 Sep 2004 18:48:04 -0700 From: Bruce M Simpson To: Arne Schwabe Message-ID: <20040913014804.GB22583@empiric.icir.org> Mail-Followup-To: Arne Schwabe , Mike Tancsa , freebsd-current@freebsd.org References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> <86vfejlow2.fsf@kamino.rfc1149.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86vfejlow2.fsf@kamino.rfc1149.org> cc: freebsd-current@freebsd.org cc: Mike Tancsa Subject: Re: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:48:10 -0000 Try disabling ACPI sysresource range reservations with: debug.acpi.disabled="sysresource" in /boot/loader.conf. I haven't tried this for ichwd but doing this allowed me to load mdodd@'s SMI/SMBIOS modules for ThinkPad. BMS From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 03:05:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C941716A4CE; Mon, 13 Sep 2004 03:05:48 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F91E43D39; Mon, 13 Sep 2004 03:05:48 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from melfina.ninth-nine.com ([IPv6:2002:d312:f91e::1]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i8D35jwh068045; Mon, 13 Sep 2004 12:05:46 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 13 Sep 2004 12:05:44 +0900 From: Norikatsu Shigemura To: Don Lewis Message-Id: <20040913120544.00bedd2f.nork@FreeBSD.org> In-Reply-To: <200409121822.i8CIMoQI051153@gw.catspoiler.org> References: <200409120917.i8C9HoXl002036@sakura.ninth-nine.com> <200409121822.i8CIMoQI051153@gw.catspoiler.org> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.4; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [IPv6:2002:db7f:4a79::1]); Mon, 13 Sep 2004 12:05:47 +0900 (JST) cc: takawata@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: nork@FreeBSD.org cc: stephane@FreeBSD.org Subject: Re: [PANIC] snd_sb16 on 5.3-BETA4 over qemu are fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 03:05:49 -0000 On Sun, 12 Sep 2004 11:22:50 -0700 (PDT) Don Lewis wrote: > On 12 Sep, Norikatsu Shigemura wrote: > > snd_sb16 on 5.3-BETA4 over qemu(modified by nork and takawata) > > causes panic. But this is well-known problem as kern/71189. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=71189 > > I confirmed that this patch is good. Anyone, would you please > > commit to 6-current and 5.3 branch? > I just commited the patch to 6-CURRENT. I'll commit it to RELENG_5 in a > few days, with re@ approval. Thank you very much! From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 03:37:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30C6516A4CE; Mon, 13 Sep 2004 03:37:10 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE22843D41; Mon, 13 Sep 2004 03:37:09 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8D3b7pj048681; Sun, 12 Sep 2004 23:37:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48195-07; Sun, 12 Sep 2004 23:37:07 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8D3b7DI048645; Sun, 12 Sep 2004 23:37:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8D3avZj013405; Sun, 12 Sep 2004 23:36:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040912220440.0867d3d0@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 12 Sep 2004 23:42:08 -0400 To: Bruce M Simpson From: Mike Tancsa In-Reply-To: <20040913014804.GB22583@empiric.icir.org> References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> <86vfejlow2.fsf@kamino.rfc1149.org> <20040913014804.GB22583@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b cc: freebsd-current@freebsd.org Subject: Re: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 03:37:10 -0000 At 09:48 PM 12/09/2004, Bruce M Simpson wrote: >Try disabling ACPI sysresource range reservations with: > debug.acpi.disabled="sysresource" > >in /boot/loader.conf. I haven't tried this for ichwd but doing this allowed >me to load mdodd@'s SMI/SMBIOS modules for ThinkPad. Hmmm, this seems to help a bit but the functionality is not there. The module loads and doesnt complain, but it doesnt work in that the daemon does not seem to be able to "arm" it so that it reboots I tried it as a kld and as statically compiled into the kernel and no dice on either and statically compiled in is worse. Also, why would booting without ACPI not work as well if its the "problem" ? Adding a couple of printfs to the watchdog, the ioctl is returning zero But if I kill -9 the daemon, the box does not reboot From the console, ichwd module loaded ichwd_identify(): found ICH chipset: Intel 82801EB/ER watchdog timer ichwd0: on motherboard ichwd0: timer disabled ichwd0: timer enabled ichwd0: timeout set to 28 ticks ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded FreeBSD/i386 (releng5-865.sentex.ca) (ttyd0) login: ichwd0: timer reloaded FreeBSD/i386 (releng5-865.sentex.ca) (ttyd0) login: ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded ichwd0: timer reloaded One last thing which I dont know if its significant or not, but after loading the kld, on reboot I get Shutting down local daemons:. Writing entropy file:. Terminated . Sep 12 23:00:39 releng5-865 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 2 0 0 done No buffers busy after final sync Uptime: 16m36s Shutting down ACPI ACPI-0265: *** Error: Hardware never changed modes ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 05:45:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03E0016A4CE for ; Mon, 13 Sep 2004 05:45:56 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A9C43D67 for ; Mon, 13 Sep 2004 05:45:55 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id D93D150B82; Mon, 13 Sep 2004 14:45:53 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4A14650BAE; Mon, 13 Sep 2004 14:45:52 +0900 (JST) Date: Mon, 13 Sep 2004 14:45:52 +0900 Message-ID: <7mpt4qoh67.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Dan Nelson In-Reply-To: <20040910150120.GH5008@dan.emsphone.com> References: <7m7jr2p5an.wl@black.imgsrc.co.jp> <20040910150120.GH5008@dan.emsphone.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Current Subject: Re: ktrace for linux binary X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 05:45:56 -0000 At Fri, 10 Sep 2004 10:01:21 -0500, Dan Nelson wrote: > > Is there a magic for this? > > Install the devel/linux_kdump port. Wow, thanks, it worked! -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 06:39:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E2A16A4CE; Mon, 13 Sep 2004 06:39:42 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B395F43D1D; Mon, 13 Sep 2004 06:39:41 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8D6dYZF081535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 09:39:35 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8D6dZrs060230; Mon, 13 Sep 2004 09:39:35 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Sep 2004 09:39:35 +0300 From: Ruslan Ermilov To: Maxim Sobolev Message-ID: <20040913063935.GB58490@ip.net.ua> References: <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> <20040912112411.GA62181@schweikhardt.net> <20040912140311.GA60265@schweikhardt.net> <20040912180221.GB18232@ip.net.ua> <4144AA29.2020003@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: <4144AA29.2020003@portaone.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: portmgr@FreeBSD.org cc: Kris Kennaway cc: Roman Kurakin cc: current@FreeBSD.org cc: Jens Schweikhardt Subject: Re: ccache support for make buildworld/make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 06:39:42 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2004 at 10:57:29PM +0300, Maxim Sobolev wrote: > I have in mind extension for ccache which would allow it to be used with= =20 > buildworld. Instead of using hashed values of compiler binary size and=20 > its last modification time, ccache should be using hash of the compiler= =20 > binary. To avoid hashing several megabytes worth image on each=20 > invocation, compiler binary hash value can be by itself cached using=20 > hashed values of compiler binary size and its last modification time.=20 >=20 That would work, indeed. :-) > Since linking the same objects from the cache is likely to produce the=20 > same binary, bootstrap compiler generated on the second ccached=20 > buildworld will be the same as one generated on the first one. >=20 Even not from cache: # cd /usr/obj/usr/home/src/RELENG_4/gnu/usr.bin/cc/cc1/ # strip cc1 # md5 ./cc1 /usr/libexec/cc1 MD5 (./cc1) =3D 32173c94754290242a6b026cf96ce108 MD5 (/usr/libexec/cc1) =3D 32173c94754290242a6b026cf96ce108 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRUCnqRfpzJluFF4RApxsAJ9mxUrzAePxvErDtQNTGb3n5y+9VwCfeZOO R2mTVgTxwZ18epeOrhf3Xag= =vjKr -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:17:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B40DB16A4CE for ; Mon, 13 Sep 2004 08:17:27 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6193943D1D for ; Mon, 13 Sep 2004 08:17:27 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1C6m04-0000V7-Up for current@freebsd.org; Mon, 13 Sep 2004 10:15:49 +0200 Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1C6m04-0000V3-Cu for current@freebsd.org; Mon, 13 Sep 2004 10:15:48 +0200 Message-ID: <414557C3.9020101@anduin.net> Date: Mon, 13 Sep 2004 10:18:11 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040709) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=ham version=2.63 Subject: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 08:17:27 -0000 Hi all, I have tried - and failed - repeatedly since end of May/early June to build world on my amd64 system. Since the instability issues (amd64-specific and others) surfaced early June I haven't been overly concerned about this, since I luckily found a 'sweet spot' of relative stability back then and haven't needed to upgrade. Now that 5.3 is getting near, though, I am trying to build world again, to prepare for an upgrade. After removing /usr/obj and all subdirs of /usr/src plus running a cvsup against RELENG_5 (which I assume is what I need to get the latest 5-branch code), I am still unable to compile world (fails in lib/libc - following is the output of a 'make' in that directory): cc -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libc/net/getaddrinfo.c In file included from /usr/src/include/string.h:49, from /usr/src/lib/libc/net/getaddrinfo.c:89: /usr/src/include/strings.h:41: error: syntax error before "__pure" /usr/src/include/strings.h:50: error: syntax error before "__pure" /usr/src/include/strings.h:51: error: syntax error before "__pure" /usr/src/include/strings.h:52: error: syntax error before "__pure" /usr/src/include/strings.h:53: error: syntax error before "__pure" In file included from /usr/src/lib/libc/net/getaddrinfo.c:89: /usr/src/include/string.h:61: error: syntax error before "__pure" /usr/src/include/string.h:62: error: syntax error before "__pure" /usr/src/include/string.h:68: error: syntax error before "__pure" /usr/src/include/string.h:71: error: syntax error before "__pure" /usr/src/include/string.h:72: error: syntax error before "__pure" /usr/src/include/string.h:75: error: syntax error before "__pure" /usr/src/include/string.h:87: error: syntax error before "__pure" /usr/src/include/string.h:92: error: syntax error before "__pure" /usr/src/include/string.h:95: error: syntax error before "__pure" /usr/src/include/string.h:97: error: syntax error before "__pure" /usr/src/include/string.h:98: error: syntax error before "__pure" /usr/src/include/string.h:103: error: syntax error before "__pure" /usr/src/include/string.h:104: error: syntax error before "__pure" /usr/src/lib/libc/net/getaddrinfo.c: In function `explore_numeric_scope': /usr/src/lib/libc/net/getaddrinfo.c:1271: warning: implicit declaration of function `strchr' /usr/src/lib/libc/net/getaddrinfo.c: In function `get_canonname': /usr/src/lib/libc/net/getaddrinfo.c:1315: warning: implicit declaration of function `strlen' /usr/src/lib/libc/net/getaddrinfo.c: In function `getanswer': /usr/src/lib/libc/net/getaddrinfo.c:1790: warning: implicit declaration of function `strcasecmp' /usr/src/lib/libc/net/getaddrinfo.c: In function `_gethtent': /usr/src/lib/libc/net/getaddrinfo.c:2073: warning: implicit declaration of function `strpbrk' *** Error code 1 Stop in /usr/src/lib/libc. Anyone? Did I miss some important information? Did I forget to RTFM or something? Thanks, /Eirik From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:54:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACDFE16A4CE for ; Mon, 13 Sep 2004 08:54:09 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9878043D4C for ; Mon, 13 Sep 2004 08:54:08 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8D8rwML083255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 11:53:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8D8s0tY081188; Mon, 13 Sep 2004 11:54:00 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Sep 2004 11:53:59 +0300 From: Ruslan Ermilov To: Eirik Oeverby Message-ID: <20040913085359.GA31628@ip.net.ua> References: <414557C3.9020101@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <414557C3.9020101@anduin.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org Subject: Re: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 08:54:09 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2004 at 10:18:11AM +0200, Eirik Oeverby wrote: > Hi all, >=20 > I have tried - and failed - repeatedly since end of May/early June to=20 > build world on my amd64 system. Since the instability issues=20 > (amd64-specific and others) surfaced early June I haven't been overly=20 > concerned about this, since I luckily found a 'sweet spot' of relative=20 > stability back then and haven't needed to upgrade. >=20 > Now that 5.3 is getting near, though, I am trying to build world again,= =20 > to prepare for an upgrade. After removing /usr/obj and all subdirs of=20 > /usr/src plus running a cvsup against RELENG_5 (which I assume is what I= =20 > need to get the latest 5-branch code), I am still unable to compile=20 > world (fails in lib/libc - following is the output of a 'make' in that=20 > directory): >=20 Hmm, from the output below, it looks like you're trying to just "make" while in src/ rather than doing a full "make buildworld". Don't do that -- you need a new toolchain (including the compiler) to understand a new syntax like the "__pure" keyword. buildworld will take care of upgrading the compiler and binutils for you, and use them to compile the rest of the world. If you still see an error while doing "make buildworld", please provide me with more information, such as which stage of buildworld it breaks, the contents of your /etc/make.conf, etc. > cc -O -pipe -I/usr/src/lib/libc/include=20 > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale=20 > -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > -Wno-uninitialized -c /usr/src/lib/libc/net/getaddrinfo.c > In file included from /usr/src/include/string.h:49, > from /usr/src/lib/libc/net/getaddrinfo.c:89: > /usr/src/include/strings.h:41: error: syntax error before "__pure" > /usr/src/include/strings.h:50: error: syntax error before "__pure" > /usr/src/include/strings.h:51: error: syntax error before "__pure" > /usr/src/include/strings.h:52: error: syntax error before "__pure" > /usr/src/include/strings.h:53: error: syntax error before "__pure" > In file included from /usr/src/lib/libc/net/getaddrinfo.c:89: > /usr/src/include/string.h:61: error: syntax error before "__pure" > /usr/src/include/string.h:62: error: syntax error before "__pure" > /usr/src/include/string.h:68: error: syntax error before "__pure" > /usr/src/include/string.h:71: error: syntax error before "__pure" > /usr/src/include/string.h:72: error: syntax error before "__pure" > /usr/src/include/string.h:75: error: syntax error before "__pure" > /usr/src/include/string.h:87: error: syntax error before "__pure" > /usr/src/include/string.h:92: error: syntax error before "__pure" > /usr/src/include/string.h:95: error: syntax error before "__pure" > /usr/src/include/string.h:97: error: syntax error before "__pure" > /usr/src/include/string.h:98: error: syntax error before "__pure" > /usr/src/include/string.h:103: error: syntax error before "__pure" > /usr/src/include/string.h:104: error: syntax error before "__pure" > /usr/src/lib/libc/net/getaddrinfo.c: In function `explore_numeric_scope': > /usr/src/lib/libc/net/getaddrinfo.c:1271: warning: implicit declaration= =20 > of function `strchr' > /usr/src/lib/libc/net/getaddrinfo.c: In function `get_canonname': > /usr/src/lib/libc/net/getaddrinfo.c:1315: warning: implicit declaration= =20 > of function `strlen' > /usr/src/lib/libc/net/getaddrinfo.c: In function `getanswer': > /usr/src/lib/libc/net/getaddrinfo.c:1790: warning: implicit declaration= =20 > of function `strcasecmp' > /usr/src/lib/libc/net/getaddrinfo.c: In function `_gethtent': > /usr/src/lib/libc/net/getaddrinfo.c:2073: warning: implicit declaration= =20 > of function `strpbrk' > *** Error code 1 >=20 > Stop in /usr/src/lib/libc. >=20 >=20 > Anyone? Did I miss some important information? Did I forget to RTFM or=20 > something? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRWAnqRfpzJluFF4RAprhAJ9runCAshI3/W5o+d96bkonBf85dwCfY02f FRcINL7RKySK63cO+gglJJw= =KNHI -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:59:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 627D216A4CE for ; Mon, 13 Sep 2004 08:59:07 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8427043D49 for ; Mon, 13 Sep 2004 08:59:06 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8D8u4mx028565 for current@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 13 Sep 2004 12:56:04 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8D8skNW028514 for ; (8.12.8/vak/2.1) Mon, 13 Sep 2004 12:54:46 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414560D3.10108@cronyx.ru> Date: Mon, 13 Sep 2004 12:56:51 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Large mem disk with not very recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 08:59:07 -0000 Hi, I have the following idea/problem. I want to build world in memory. I've put in to my system 1G of memory and tried to put on it sources. But all times I've tried to do that system went to panic. I've used md with malloc type. Any ideas? rik From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:02:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F120616A4CE for ; Mon, 13 Sep 2004 09:01:59 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8206F43D48 for ; Mon, 13 Sep 2004 09:01:59 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1C6mhA-000JuB-VF for current@FreeBSD.org; Mon, 13 Sep 2004 11:00:21 +0200 Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1C6mh8-000JtR-TC; Mon, 13 Sep 2004 11:00:19 +0200 Message-ID: <4145622E.7040405@anduin.net> Date: Mon, 13 Sep 2004 11:02:38 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040709) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <414557C3.9020101@anduin.net> <20040913085359.GA31628@ip.net.ua> In-Reply-To: <20040913085359.GA31628@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 cc: current@FreeBSD.org Subject: Re: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:02:00 -0000 Ruslan Ermilov wrote: > On Mon, Sep 13, 2004 at 10:18:11AM +0200, Eirik Oeverby wrote: > >>Hi all, >> >>I have tried - and failed - repeatedly since end of May/early June to >>build world on my amd64 system. Since the instability issues >>(amd64-specific and others) surfaced early June I haven't been overly >>concerned about this, since I luckily found a 'sweet spot' of relative >>stability back then and haven't needed to upgrade. >> >>Now that 5.3 is getting near, though, I am trying to build world again, >>to prepare for an upgrade. After removing /usr/obj and all subdirs of >>/usr/src plus running a cvsup against RELENG_5 (which I assume is what I >>need to get the latest 5-branch code), I am still unable to compile >>world (fails in lib/libc - following is the output of a 'make' in that >>directory): >> > > Hmm, from the output below, it looks like you're trying to just "make" > while in src/ rather than doing a full "make buildworld". Don't do > that -- you need a new toolchain (including the compiler) to understand > a new syntax like the "__pure" keyword. buildworld will take care of > upgrading the compiler and binutils for you, and use them to compile > the rest of the world. > > If you still see an error while doing "make buildworld", please provide > me with more information, such as which stage of buildworld it breaks, > the contents of your /etc/make.conf, etc. > This is the error I get when I do a 'make' from /usr/src/lib/libc. The 'make buildworld' from /usr/src (which is what I did at first, but it hides many of the error messages, therefore I tried 'make' in lib/libc). The exact output of 'make buildworld' (from the time of the error) is: cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c crypt_xdr.c -o crypt_xdr.So cc -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c nslexer.c cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c nslexer.c -o nslexer.So /dev/stdout: In function `_nsyylex': /dev/stdout:711: warning: label `find_rule' defined but not used /usr/src/lib/libc/net/nslexer.l: At top level: /dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used *** Error code 1 /dev/stdout: In function `_nsyylex': /dev/stdout:711: warning: label `find_rule' defined but not used /usr/src/lib/libc/net/nslexer.l: At top level: /dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error As to which stage this is I don't know - it has been building for quite a while when this happens. I'm running another buildworld now, dumping the output to files. Let me know if you need these. My make.conf looks like this: # -- use.perl generated deltas -- # # Created: Tue Jun 15 19:14:25 2004 # Setting to use base perl from ports: PERL_VER=5.8.4 PERL_VERSION=5.8.4 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo # Enable 'make update' in /usr/src and /usr/ports SUP_UPDATE= yes SUP= /usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPHOST= cvsup.de.FreeBSD.org #SUPFILE= /usr/share/examples/cvsup/standard-supfile SUPFILE= /usr/share/examples/cvsup/stable-supfile PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile DOCSUPFILE= /usr/share/examples/cvsup/doc-supfile So far that's what I've got for you. Thanks, /Eirik > >>cc -O -pipe -I/usr/src/lib/libc/include >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k >>-Wno-uninitialized -c /usr/src/lib/libc/net/getaddrinfo.c >>In file included from /usr/src/include/string.h:49, >> from /usr/src/lib/libc/net/getaddrinfo.c:89: >>/usr/src/include/strings.h:41: error: syntax error before "__pure" >>/usr/src/include/strings.h:50: error: syntax error before "__pure" >>/usr/src/include/strings.h:51: error: syntax error before "__pure" >>/usr/src/include/strings.h:52: error: syntax error before "__pure" >>/usr/src/include/strings.h:53: error: syntax error before "__pure" >>In file included from /usr/src/lib/libc/net/getaddrinfo.c:89: >>/usr/src/include/string.h:61: error: syntax error before "__pure" >>/usr/src/include/string.h:62: error: syntax error before "__pure" >>/usr/src/include/string.h:68: error: syntax error before "__pure" >>/usr/src/include/string.h:71: error: syntax error before "__pure" >>/usr/src/include/string.h:72: error: syntax error before "__pure" >>/usr/src/include/string.h:75: error: syntax error before "__pure" >>/usr/src/include/string.h:87: error: syntax error before "__pure" >>/usr/src/include/string.h:92: error: syntax error before "__pure" >>/usr/src/include/string.h:95: error: syntax error before "__pure" >>/usr/src/include/string.h:97: error: syntax error before "__pure" >>/usr/src/include/string.h:98: error: syntax error before "__pure" >>/usr/src/include/string.h:103: error: syntax error before "__pure" >>/usr/src/include/string.h:104: error: syntax error before "__pure" >>/usr/src/lib/libc/net/getaddrinfo.c: In function `explore_numeric_scope': >>/usr/src/lib/libc/net/getaddrinfo.c:1271: warning: implicit declaration >>of function `strchr' >>/usr/src/lib/libc/net/getaddrinfo.c: In function `get_canonname': >>/usr/src/lib/libc/net/getaddrinfo.c:1315: warning: implicit declaration >>of function `strlen' >>/usr/src/lib/libc/net/getaddrinfo.c: In function `getanswer': >>/usr/src/lib/libc/net/getaddrinfo.c:1790: warning: implicit declaration >>of function `strcasecmp' >>/usr/src/lib/libc/net/getaddrinfo.c: In function `_gethtent': >>/usr/src/lib/libc/net/getaddrinfo.c:2073: warning: implicit declaration >>of function `strpbrk' >>*** Error code 1 >> >>Stop in /usr/src/lib/libc. >> >> >>Anyone? Did I miss some important information? Did I forget to RTFM or >>something? > > > > Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:19:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BEDE16A4CE; Mon, 13 Sep 2004 09:19:47 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE8043D45; Mon, 13 Sep 2004 09:19:46 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8D9JgUW083573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 12:19:43 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8D9JiMT013954; Mon, 13 Sep 2004 12:19:44 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Sep 2004 12:19:43 +0300 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20040913091943.GB31628@ip.net.ua> References: <200409130834.i8D8Y2ls032527@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <200409130834.i8D8Y2ls032527@freefall.freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Dima Dorfman Subject: One method of compile testing WARNS changes on several architectures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:19:47 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I thought I'd sent this out, because the standard method (through "make universe") is very time consuming when the only thing you want is to compile-test a change that covers a small part of src/. The method offered here will save you many hours then. On Mon, Sep 13, 2004 at 08:34:02AM +0000, Dima Dorfman wrote: > When you make changes like this, it's a good idea to see if you can > clamp down the program to a higher WARNS level. In this case, the > program compiles cleanly with WARNS=3D2 after your change, so I set > that. Setting WARNS in the Makefile makes sure that future changes to > the program don't cause more warnings. Since WARNS means that warnings > will break the build, though, it's good to be able to test the change > on more than one architecture to make sure you don't miss any > platform-specific issues. >=20 To test with a minimal time effort, you do this (while in src/): $ make toolchain TARGET_ARCH=3D This step should be repeated for each architecture to be tested against. This will take a lot of time, but an order less than a full buildworld. $ make _depend everything SUBDIR_OVERRIDER=3D TARGET_ARCH=3D (The underscore before "depend" is intentional.) is a part of src/ tree that you want to test (can be a list), and should be looped over with each architecture to be tested against. Example. To test if a changed bin/cat still compiles cleanly under Alpha and AMD64, e.g. due to you clamping down the WARNS level, you do this: 1. Prepare the toolchains: make toolchain TARGET_ARCH=3Dalpha make toolchain TARGET_ARCH=3Damd64 2. Test changes: make _depend everything SUBDIR_OVERRIDE=3Dbin/cat TARGET_ARCH=3Dalpha make _depend everything SUBDIR_OVERRIDE=3Dbin/cat TARGET_ARCH=3Damd64 3. You can then modify cat's sources/makefile, and repeat step #2. P.S. The syntax for PC98 would be "TARGET_ARCH=3Di386 TARGET=3Dpc98". Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRWYvqRfpzJluFF4RAuv2AJwKmW/3sqCDWLNMFd1WEzGcRZMjzQCgmzKC oumD9+AGq8v8k12Nr3p9Qus= =PA8B -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:24:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 143C916A4CF for ; Mon, 13 Sep 2004 09:24:20 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EF0F43D2F for ; Mon, 13 Sep 2004 09:24:19 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [195.159.6.24] (ws24.ns5.powertech.no [195.159.6.24]) by smtp1.powertech.no (Postfix) with ESMTP id 3DDDB8317; Mon, 13 Sep 2004 11:24:17 +0200 (CEST) In-Reply-To: <4142D833.4060802@DeepCore.dk> References: <4142D833.4060802@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Frode Nordahl Date: Mon, 13 Sep 2004 11:24:19 +0200 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619) cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:24:20 -0000 On Sep 11, 2004, at 12:49, S=F8ren Schmidt wrote: > OK I got this this setup now: > > atapci0: port=20 > 0xb000-0xb03f,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407=20= > mem 0xfd000000-0xfd01ffff irq 16 at device 3.0 on pci0 > ad1: 14305MB [29065/16/63] at ata2-master=20 > UDMA100 > ad2: 14305MB [29065/16/63] at ata3-master=20 > UDMA100 > ar0: 14305MB [1823/255/63] status: READY subdisks: > > Controller the same, disks are an earlier verision of those "low=20 > profile" Maxtor disks, just somewhat slover than yours. > > pizzabox# dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 122.908771 secs (17062672 bytes/sec) I have done some more test now, reseated cables, disabling other IDE=20 controllers etc. to no avail. I have tested both drives against the=20 ICH2 controller with very good results. After some fooling around I found the following: ar0: ATA RAID1 subdisks: ad4 ad6 status: READY # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D100 100+0 records in 100+0 records out 104857600 bytes transferred in 29.298259 secs (3578970 bytes/sec) # atacontrol detach ata2 # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.080246 secs (34041957 bytes/sec) (this also works when writing 2GB...) That is, whenever I run with a single disk or a degraded RAID transfer=20= speeds are ok. I have tried this both ways, so it is not one of the=20 disks / cables that is broken. As soon as I rebuild the RAID again,=20 write speeds drop to 3MB/s. Any ideas as of how to debug this? Mvh, Frode > -S=F8ren > From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:29:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1789616A4CE for ; Mon, 13 Sep 2004 09:29:59 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B3343D46 for ; Mon, 13 Sep 2004 09:29:58 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8D9TrmF083715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 12:29:54 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8D9Ttxq014021; Mon, 13 Sep 2004 12:29:55 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Sep 2004 12:29:54 +0300 From: Ruslan Ermilov To: Eirik Oeverby Message-ID: <20040913092954.GC31628@ip.net.ua> References: <414557C3.9020101@anduin.net> <20040913085359.GA31628@ip.net.ua> <4145622E.7040405@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <4145622E.7040405@anduin.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:29:59 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2004 at 11:02:38AM +0200, Eirik Oeverby wrote: > Ruslan Ermilov wrote: [...] > >If you still see an error while doing "make buildworld", please provide > >me with more information, such as which stage of buildworld it breaks, > >the contents of your /etc/make.conf, etc. >=20 > This is the error I get when I do a 'make' from /usr/src/lib/libc. The=20 > 'make buildworld' from /usr/src (which is what I did at first, but it=20 > hides many of the error messages, therefore I tried 'make' in lib/libc).= =20 >=20 You now have an explanation why you're not supposed to do it. ;) > The exact output of 'make buildworld' (from the time of the error) is: >=20 > cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include=20 > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale=20 > -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > -Wno-uninitialized -c crypt_xdr.c -o crypt_xdr.So > cc -O -pipe -I/usr/src/lib/libc/include=20 > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale=20 > -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > -Wno-uninitialized -c nslexer.c > cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include=20 > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale=20 > -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > -Wno-uninitialized -c nslexer.c -o nslexer.So > /dev/stdout: In function `_nsyylex': > /dev/stdout:711: warning: label `find_rule' defined but not used > /usr/src/lib/libc/net/nslexer.l: At top level: > /dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used > *** Error code 1 > /dev/stdout: In function `_nsyylex': > /dev/stdout:711: warning: label `find_rule' defined but not used > /usr/src/lib/libc/net/nslexer.l: At top level: > /dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used > *** Error code 1 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error >=20 > As to which stage this is I don't know - it has been building for quite= =20 > a while when this happens. I'm running another buildworld now, dumping=20 > the output to files. Let me know if you need these. >=20 Yes. Please put the *compressed* output (both stdout and stderr) from a non-parallel (that is, without -jN) "make buildworld" command available somewhere for download. Please also provide me with the outputs of the following commands: uname -srm grep __FreeBSD_version /usr/include/osreldate.h ident /usr/bin/lex P.S. Does the PR bin/71406 look familiar? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRWiSqRfpzJluFF4RAss4AJ4ycz1Lx65U+gl87HNQHi6qDCp+cQCfaL1j 1qIEanTw1NLg5qtnzQiPZ/k= =qHwx -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:40:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55A4916A4CE for ; Mon, 13 Sep 2004 09:40:40 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCB8743D49 for ; Mon, 13 Sep 2004 09:40:39 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1C6nIb-0001zt-KV for current@freebsd.org; Mon, 13 Sep 2004 11:39:02 +0200 Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1C6nIZ-0001zg-Uh; Mon, 13 Sep 2004 11:39:00 +0200 Message-ID: <41456B43.5050707@anduin.net> Date: Mon, 13 Sep 2004 11:41:23 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040709) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <414557C3.9020101@anduin.net> <20040913085359.GA31628@ip.net.ua> <4145622E.7040405@anduin.net> <20040913092954.GC31628@ip.net.ua> In-Reply-To: <20040913092954.GC31628@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 cc: current@freebsd.org Subject: Re: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:40:40 -0000 Ruslan Ermilov wrote: > On Mon, Sep 13, 2004 at 11:02:38AM +0200, Eirik Oeverby wrote: > >>Ruslan Ermilov wrote: > > [...] > >>>If you still see an error while doing "make buildworld", please provide >>>me with more information, such as which stage of buildworld it breaks, >>>the contents of your /etc/make.conf, etc. >> >>This is the error I get when I do a 'make' from /usr/src/lib/libc. The >>'make buildworld' from /usr/src (which is what I did at first, but it >>hides many of the error messages, therefore I tried 'make' in lib/libc). >> > > You now have an explanation why you're not supposed to do it. ;) > > >>The exact output of 'make buildworld' (from the time of the error) is: >> >>cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k >>-Wno-uninitialized -c crypt_xdr.c -o crypt_xdr.So >>cc -O -pipe -I/usr/src/lib/libc/include >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k >>-Wno-uninitialized -c nslexer.c >>cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k >>-Wno-uninitialized -c nslexer.c -o nslexer.So >>/dev/stdout: In function `_nsyylex': >>/dev/stdout:711: warning: label `find_rule' defined but not used >>/usr/src/lib/libc/net/nslexer.l: At top level: >>/dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used >>*** Error code 1 >>/dev/stdout: In function `_nsyylex': >>/dev/stdout:711: warning: label `find_rule' defined but not used >>/usr/src/lib/libc/net/nslexer.l: At top level: >>/dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used >>*** Error code 1 >>2 errors >>*** Error code 2 >>1 error >>*** Error code 2 >>1 error >>*** Error code 2 >>1 error >>*** Error code 2 >>1 error >>*** Error >> >>As to which stage this is I don't know - it has been building for quite >>a while when this happens. I'm running another buildworld now, dumping >>the output to files. Let me know if you need these. >> > > Yes. Please put the *compressed* output (both stdout and stderr) from > a non-parallel (that is, without -jN) "make buildworld" command available > somewhere for download. http://anduin.net/stdout.txt.gz http://anduin.net/stderr.txt.gz > > Please also provide me with the outputs of the following commands: > > uname -srm > grep __FreeBSD_version /usr/include/osreldate.h > ident /usr/bin/lex [root@anduin] /usr/src# uname -srm FreeBSD 5.2-CURRENT amd64 [root@anduin] /usr/src# grep __FreeBSD_version /usr/include/osreldate.h #undef __FreeBSD_version #define __FreeBSD_version 502112 [root@anduin] /usr/src# ident /usr/bin/lex /usr/bin/lex: $FreeBSD: src/lib/csu/amd64/crti.S,v 1.6 2002/05/15 04:19:49 obrien Exp $ $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc Exp $ $Header: /home/daffy/u0/vern/flex/RCS/flex.skl,v 2.91 96/09/10 16:58:48 vern Exp $ $FreeBSD: src/usr.bin/lex/flex.skl,v 1.7 2002/09/09 02:58:42 obrien Exp $ $FreeBSD: src/lib/csu/amd64/crtn.S,v 1.5 2002/05/15 04:19:49 obrien Exp $ $FreeBSD: src/lib/csu/common/crtbrand.c,v 1.4 2003/10/17 15:43:13 peter Exp $ $FreeBSD: src/lib/csu/amd64/crt1.c,v 1.13 2003/04/30 19:27:07 peter Exp $ $FreeBSD: src/usr.bin/lex/ccl.c,v 1.6 2002/06/30 05:25:03 obrien Exp $ $FreeBSD: src/usr.bin/lex/dfa.c,v 1.6 2002/06/30 05:25:03 obrien Exp $ $FreeBSD: src/usr.bin/lex/ecs.c,v 1.6 2002/06/30 05:25:03 obrien Exp $ $FreeBSD: src/usr.bin/lex/gen.c,v 1.6 2002/06/30 05:25:03 obrien Exp $ $FreeBSD: src/usr.bin/lex/main.c,v 1.8 2002/06/30 05:25:04 obrien Exp $ $FreeBSD: src/usr.bin/lex/misc.c,v 1.6 2002/06/30 05:25:04 obrien Exp $ $FreeBSD: src/usr.bin/lex/nfa.c,v 1.6 2002/06/30 05:25:04 obrien Exp $ $FreeBSD: src/usr.bin/lex/sym.c,v 1.6 2002/06/30 05:25:04 obrien Exp $ $FreeBSD: src/usr.bin/lex/tblcmp.c,v 1.6 2002/06/30 05:25:04 obrien Exp $ $FreeBSD: src/usr.bin/lex/yylex.c,v 1.6 2002/06/30 05:25:04 obrien Exp $ [root@anduin] /usr/src# > > P.S. Does the PR bin/71406 look familiar? Sure does, symptoms look the same. I have just ran a 'make' and 'make install' in usr.bin/yacc, and am now rebuilding world. Did I miss something, or should this now work? /Eirik > > > Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:41:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BEBF16A4CE for ; Mon, 13 Sep 2004 09:41:49 +0000 (GMT) Received: from southcross.homeunix.org (dhcp20.iit.cnr.it [146.48.99.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFCC543D1F for ; Mon, 13 Sep 2004 09:41:48 +0000 (GMT) (envelope-from flag@tin.it) Received: by southcross.homeunix.org (Postfix, from userid 1001) id 09AAF209B; Mon, 13 Sep 2004 11:51:59 +0200 (CEST) Date: Mon, 13 Sep 2004 11:51:58 +0200 From: Paolo Pisati To: FreeBSD_Current Message-ID: <20040913095158.GA870@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: pxe FreeBSD-5.3-beta4: btx halted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:41:49 -0000 Hi guys, i'm pxe-booting freebsd inside a vmware system running on top of my freebsd box that acts like dhcp/tftp/nfs/etcetc server for the diskless (vmware) client. vmware boots, it gets ip&c from dhcp server, starts tftp and trasfer the bootloader but then, it hangs with a regs dump and the msg: btx halted. To see a complete regs dump and error code i made a screenshot of it available here: http://www.gufi.org/~flag/vmware-btx-hlt.gif any idea would be GREATLY appreciated cause it would be very nice to make it work... =) (and it would help me a lot for kernel debugging... =P) bye -- Paolo Italian FreeBSD User Group: http://www.gufi.org From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:42:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF2F516A4CE for ; Mon, 13 Sep 2004 09:42:58 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AEDF43D5C for ; Mon, 13 Sep 2004 09:42:58 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i8D9guw9083523; Mon, 13 Sep 2004 11:42:56 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41456B73.9000701@DeepCore.dk> Date: Mon, 13 Sep 2004 11:42:11 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frode Nordahl References: <4142D833.4060802@DeepCore.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:42:58 -0000 Frode Nordahl wrote: > On Sep 11, 2004, at 12:49, S=F8ren Schmidt wrote: >> pizzabox# dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 >> 2000+0 records in >> 2000+0 records out >> 2097152000 bytes transferred in 122.908771 secs (17062672 bytes/sec) >=20 > I have done some more test now, reseated cables, disabling other IDE=20 > controllers etc. to no avail. I have tested both drives against the ICH= 2=20 > controller with very good results. >=20 > After some fooling around I found the following: > ar0: ATA RAID1 subdisks: ad4 ad6 status: READY > # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 29.298259 secs (3578970 bytes/sec) > # atacontrol detach ata2 > # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 3.080246 secs (34041957 bytes/sec) >=20 > (this also works when writing 2GB...) >=20 > That is, whenever I run with a single disk or a degraded RAID transfer = > speeds are ok. I have tried this both ways, so it is not one of the=20 > disks / cables that is broken. As soon as I rebuild the RAID again,=20 > write speeds drop to 3MB/s. >=20 > Any ideas as of how to debug this? Sounds strange indeed, there is some performance degradation to be=20 expected from RAID1 (you have to write to both disks) but nothing that=20 ruins performance this badly. I cannot reproduce it no matter what I=20 try, so I'm pretty sure the reason should be found outside ATA. It could be because the two channels are competing for the PCI bus and=20 the arbitration of that fails so you get alot of PCI retries, that is=20 outside ATA's reach to control.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 09:50:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31D9116A4CE; Mon, 13 Sep 2004 09:50:15 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 664DB43D1F; Mon, 13 Sep 2004 09:50:14 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id F23DE11AB1; Mon, 13 Sep 2004 11:50:12 +0200 (CEST) Date: Mon, 13 Sep 2004 11:50:12 +0200 From: "Simon L. Nielsen" To: Ruslan Ermilov Message-ID: <20040913095012.GB766@zaphod.nitro.dk> References: <200409130834.i8D8Y2ls032527@freefall.freebsd.org> <20040913091943.GB31628@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <20040913091943.GB31628@ip.net.ua> User-Agent: Mutt/1.5.6i cc: current@FreeBSD.org cc: Dima Dorfman Subject: Re: One method of compile testing WARNS changes on several architectures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 09:50:15 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.09.13 12:19:43 +0300, Ruslan Ermilov wrote: > To test with a minimal time effort, you do this (while in src/): >=20 > $ make toolchain TARGET_ARCH=3D >=20 > This step should be repeated for each architecture to be tested > against. This will take a lot of time, but an order less than a > full buildworld. >=20 > $ make _depend everything SUBDIR_OVERRIDER=3D TARGET_ARCH=3D >=20 > (The underscore before "depend" is intentional.) is a part > of src/ tree that you want to test (can be a list), and > should be looped over with each architecture to be tested against. >=20 > Example. To test if a changed bin/cat still compiles cleanly under > Alpha and AMD64, e.g. due to you clamping down the WARNS level, you > do this: >=20 > 1. Prepare the toolchains: >=20 > make toolchain TARGET_ARCH=3Dalpha > make toolchain TARGET_ARCH=3Damd64 >=20 > 2. Test changes: >=20 > make _depend everything SUBDIR_OVERRIDE=3Dbin/cat TARGET_ARCH=3Dalpha > make _depend everything SUBDIR_OVERRIDE=3Dbin/cat TARGET_ARCH=3Damd64 >=20 > 3. You can then modify cat's sources/makefile, and repeat step #2. >=20 > P.S. The syntax for PC98 would be "TARGET_ARCH=3Di386 TARGET=3Dpc98". This seems like something that IMO really should be put in some documentation. Perhaps the Developers Handbook? (I can Docbook'ify it if needed). --=20 Simon L. Nielsen FreeBSD Documentation Team --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRW1Uh9pcDSc1mlERAuQIAJ9ryDvPFAu1+hMqHho/vqB5Ui51owCfY+4t VVjlrz7X6b3zHbdVbEVlxRI= =ldJ6 -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 10:08:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C56D16A4CE for ; Mon, 13 Sep 2004 10:08:23 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 768B443D46 for ; Mon, 13 Sep 2004 10:08:22 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8DA8H67084279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 13:08:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8DA8JtE015718; Mon, 13 Sep 2004 13:08:19 +0300 (EEST) (envelope-from ru) Date: Mon, 13 Sep 2004 13:08:18 +0300 From: Ruslan Ermilov To: Eirik Oeverby Message-ID: <20040913100818.GA15613@ip.net.ua> References: <414557C3.9020101@anduin.net> <20040913085359.GA31628@ip.net.ua> <4145622E.7040405@anduin.net> <20040913092954.GC31628@ip.net.ua> <41456B43.5050707@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <41456B43.5050707@anduin.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: Unable to build world since early June X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 10:08:23 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2004 at 11:41:23AM +0200, Eirik Oeverby wrote: > Ruslan Ermilov wrote: > >On Mon, Sep 13, 2004 at 11:02:38AM +0200, Eirik Oeverby wrote: > >>The exact output of 'make buildworld' (from the time of the error) is: > >> > >>cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include=20 > >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale= =20 > >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > >>-Wno-uninitialized -c crypt_xdr.c -o crypt_xdr.So > >>cc -O -pipe -I/usr/src/lib/libc/include=20 > >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale= =20 > >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > >>-Wno-uninitialized -c nslexer.c > >>cc -fpic -DPIC -O -pipe -I/usr/src/lib/libc/include=20 > >>-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64=20 > >>-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6= =20 > >>-I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale= =20 > >>-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP=20 > >>-DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k=20 > >>-Wno-uninitialized -c nslexer.c -o nslexer.So > >>/dev/stdout: In function `_nsyylex': > >>/dev/stdout:711: warning: label `find_rule' defined but not used > >>/usr/src/lib/libc/net/nslexer.l: At top level: > >>/dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used > >>*** Error code 1 > >>/dev/stdout: In function `_nsyylex': > >>/dev/stdout:711: warning: label `find_rule' defined but not used > >>/usr/src/lib/libc/net/nslexer.l: At top level: > >>/dev/stdout:1678: warning: 'yy_flex_realloc' defined but not used > >>*** Error code 1 > >>2 errors > >>*** Error code 2 > >>1 error > >>*** Error code 2 > >>1 error > >>*** Error code 2 > >>1 error > >>*** Error code 2 > >>1 error > >>*** Error > >> > >>As to which stage this is I don't know - it has been building for quite= =20 > >>a while when this happens. I'm running another buildworld now, dumping= =20 > >>the output to files. Let me know if you need these. > >> > > > >Yes. Please put the *compressed* output (both stdout and stderr) from > >a non-parallel (that is, without -jN) "make buildworld" command available > >somewhere for download. >=20 > http://anduin.net/stdout.txt.gz > http://anduin.net/stderr.txt.gz >=20 Ugh, I meant the combined output, but okay, I probably don't need it, please go on reading. > >Please also provide me with the outputs of the following commands: > > > >uname -srm > >grep __FreeBSD_version /usr/include/osreldate.h > >ident /usr/bin/lex >=20 > [root@anduin] /usr/src# uname -srm > FreeBSD 5.2-CURRENT amd64 > [root@anduin] /usr/src# grep __FreeBSD_version /usr/include/osreldate.h > #undef __FreeBSD_version > #define __FreeBSD_version 502112 > [root@anduin] /usr/src# ident /usr/bin/lex > $FreeBSD: src/usr.bin/lex/flex.skl,v 1.7 2002/09/09 02:58:42 obrien = Exp $ > $FreeBSD: src/usr.bin/lex/gen.c,v 1.6 2002/06/30 05:25:03 obrien Exp= $ >=20 OK, problem analyzed and understood. Here's the analysis: Your /usr/bin/lex was compiled using the above two files/revisions. Now consider this change: : $ ident gen.c flex.skl : gen.c: : $FreeBSD: src/usr.bin/lex/gen.c,v 1.7 2004/01/06 18:54:55 nectar Exp= $ :=20 : flex.skl: : $FreeBSD: src/usr.bin/lex/flex.skl,v 1.8 2004/01/06 19:03:44 nectar = Exp $ :=20 : RCS file: /home/ncvs/src/usr.bin/lex/gen.c,v : Working file: gen.c : head: 1.7 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 13; selected revisions: 1 : description: : ---------------------------- : revision 1.7 : date: 2004/01/06 18:54:55; author: nectar; state: Exp; lines: +2 -0 : Work around a `label defined but not used' warning in *generated* code. Here's what happens to your system: your build environment is broken, and it fools "make buildworld" into thinking that it's running on the OS whose version of 502112, when in fact it's not. More explanation follows... The 502112 bump was done in sys/sys/param.h, in this revision: : Index: param.h : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D : RCS file: /home/ncvs/src/sys/sys/param.h,v : retrieving revision 1.190 : retrieving revision 1.191 : diff -u -p -r1.190 -r1.191 : --- param.h 11 Apr 2004 21:57:07 -0000 1.190 : +++ param.h 13 Apr 2004 09:33:33 -0000 1.191 : @@ -32,7 +32,7 @@ : * SUCH DAMAGE. : * : * @(#)param.h 8.3 (Berkeley) 4/4/95 : - * $FreeBSD: src/sys/sys/param.h,v 1.190 2004/04/11 21:57:07 mux Exp $ : + * $FreeBSD: src/sys/sys/param.h,v 1.191 2004/04/13 09:33:33 ru Exp $ : */ : =20 : #ifndef _SYS_PARAM_H_ : @@ -55,7 +55,7 @@ : * scheme is: <0 if release branch, otherwise 1= >xx : */ : #undef __FreeBSD_version : -#define __FreeBSD_version 502111 /* Master, propagated to newvers = */ : +#define __FreeBSD_version 502112 /* Master, propagated to newvers = */ : =20 : #ifndef LOCORE : #include Note the __FreeBSD_version bump was done on 2004/04/13, while the lex change in question (that your /usr/bin/lex does not actually have) was done on 200= 4/01/06, three months *earlier*. If you were really running the 502112 system, your /usr/bin/lex would already have it. buildworld correctly tries to upgrade "lex" for systems which have a stale = one; here's a relevant excerpt from src/Makefile.inc1: : .if ${BOOTSTRAPPING} < 502102 : _lex=3D usr.bin/lex : .endif 502101 and 502102 correspond to revisions 1.177 and 1.178 of param.h, 2003/12/19 and 2004/01/30, respectively, so the 2004/01/06 (the date the "lex" change was made) falls into this range. So this means that your build system is broken. The most common way to do it is to run "make includes" that will spam your /usr/include with headers that do not match the rest of your installed world. This can also be a result of a failed "make installworld". Here's the recipe for you. Apply it only once, when you recover from a broken build system, you don't need it normally. It may work, or may not, depending on how broken your build system is, but chances are good: make buildworld OSRELDATE=3D0 Make sure to specify OSRELDATE=3D0 when doing "make installworld". Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRXGSqRfpzJluFF4RArwTAJ0eQd8C4oRIYtb7kyZYVacN9xIAiACaAilc CUlwvK48Y9NSCNIOn6Xn9qU= =yrGW -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 10:40:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F57816A4CE; Mon, 13 Sep 2004 10:40:02 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A79543D41; Mon, 13 Sep 2004 10:40:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8DAe1uH010165; Mon, 13 Sep 2004 06:40:01 -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.12.11/8.12.11) with ESMTP id i8DAe11r089640; Mon, 13 Sep 2004 06:40:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4A7327303F; Mon, 13 Sep 2004 06:40:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040913104001.4A7327303F@freebsd-current.sentex.ca> Date: Mon, 13 Sep 2004 06:40:01 -0400 (EDT) Subject: [releng_5 tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 10:40:02 -0000 TB --- 2004-09-13 09:39:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-13 09:39:06 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2004-09-13 09:39:06 - checking out the source tree TB --- 2004-09-13 09:39:06 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2004-09-13 09:39:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-13 09:46:44 - building world (CFLAGS=-O -pipe) TB --- 2004-09-13 09:46:44 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-13 09:46:44 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-13 10:35:20 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-13 10:35:20 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-13 10:35:20 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Sep 13 10:35:20 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x15a8): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x1668): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x16ec): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text3+0x0): additional relocation overflows omitted from the output *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2004-09-13 10:40:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-13 10:40:01 - ERROR: failed to build generic kernel TB --- 2004-09-13 10:40:01 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 10:51:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 9AA0F16A4D0; Mon, 13 Sep 2004 10:51:33 +0000 (GMT) Date: Mon, 13 Sep 2004 10:51:33 +0000 From: Kris Kennaway To: Roman Kurakin Message-ID: <20040913105133.GA85717@hub.freebsd.org> References: <414560D3.10108@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414560D3.10108@cronyx.ru> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: Large mem disk with not very recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 10:51:33 -0000 On Mon, Sep 13, 2004 at 12:56:51PM +0400, Roman Kurakin wrote: > Hi, > > I have the following idea/problem. I want to build world in memory. > I've put in to my system 1G of memory and tried to put on it sources. > But all times I've tried to do that system went to panic. I've used md > with malloc type. > > Any ideas? Please provide more information. It's likely you're trying to create a md that is too big, though. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 11:12:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 140A916A4CE for ; Mon, 13 Sep 2004 11:12:58 +0000 (GMT) Received: from expert.ukrtel.net (expert.ukrtel.net [195.5.6.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8CE043D55 for ; Mon, 13 Sep 2004 11:12:56 +0000 (GMT) (envelope-from astesin@ukrtelecom.net) Received: from hoexch005.sl.ukrtelecom.net (sltrans.ukrtel.net [195.5.37.133]) by expert.ukrtel.net (Netscape Messaging Server 3.5) with ESMTP id AAA4F40; Mon, 13 Sep 2004 14:09:40 +0300 Received: from hoexc010.ho.ukrtelecom.net (hoexc010.ukrtelecom.net [10.10.1.10]) by hoexch005.sl.ukrtelecom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S12JXCRB; Mon, 13 Sep 2004 14:15:08 +0300 Received: by hoexc010.ukrtelecom.net with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Sep 2004 14:12:50 +0300 Message-ID: <1152675CA9EDD71187130002B3CE5ADA0BFBC08F@hoexc010.ukrtelecom.net> From: astesin@ukrtelecom.net To: frode@nordahl.net Date: Mon, 13 Sep 2004 14:12:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 11:12:58 -0000 Dear Frode, > > Any ideas as of how to debug this? > > Sounds strange indeed, there is some performance degradation to be > expected from RAID1 (you have to write to both disks) but > nothing that ruins performance this badly. I cannot reproduce it no matter what I > try, so I'm pretty sure the reason should be found outside > ATA. It could be because the two channels are competing for > the PCI bus and the arbitration of that fails so you get alot of PCI retries, that is > outside ATA's reach to control.. Dealing with Intel mobos for about 10 years, I should mention that almost 100% of those strange problems are solved with BIOS upgrades, issued by Intel pretty much silently. I suggest going to http://intel.com and to get the very-very-latest BIOS for your board somewhere at "support and download", put it into, make "Load default settings", reboot, than set whatever settings you need (including "RAID enabled"), tell it to "reset config settings", reboot into FreeBSD and try testing again. I'm almost sure that RAID firmware will be also upgraded together with BIOS upgrade and you have a good chance to win. With D865PERL motherboard BIOS upgrade to P19 helped to solve non-trivial ATA RAID problems for me last week. Additionally, I'll be installing BETA4 onto the box with Intel S875WP1 w/Promise RAID this evening, RAID 1+0 configuration (4 Western Digital 7200 SATA drives, not Raptors), and I'll check it myself and see what happens. Will inform you ASAP. WBR, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 11:20:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D23E16A4CE for ; Mon, 13 Sep 2004 11:20:09 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68C8B43D2F for ; Mon, 13 Sep 2004 11:20:06 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8DBH6hw036052 for current@FreeBSD.ORG.checked; (8.12.8/vak/2.1) Mon, 13 Sep 2004 15:17:06 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8DBGG3R036000; (8.12.8/vak/2.1) Mon, 13 Sep 2004 15:16:16 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414581FE.6060702@cronyx.ru> Date: Mon, 13 Sep 2004 15:18:22 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <414560D3.10108@cronyx.ru> <20040913105133.GA85717@hub.freebsd.org> In-Reply-To: <20040913105133.GA85717@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@FreeBSD.ORG Subject: Re: Large mem disk with not very recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 11:20:09 -0000 Kris Kennaway wrote: >On Mon, Sep 13, 2004 at 12:56:51PM +0400, Roman Kurakin wrote: > > >>Hi, >> >> I have the following idea/problem. I want to build world in memory. >>I've put in to my system 1G of memory and tried to put on it sources. >>But all times I've tried to do that system went to panic. I've used md >>with malloc type. >> >> Any ideas? >> >> > >Please provide more information. It's likely you're trying to create >a md that is too big, though. > > It is about 800Mb. But system panics while I try to extract source tree. It is not very recent current. The intent of my question was to get some hints how to set up such build area, I belive it should help to make compilation much faster than using hard drive. My home system is not ready for panic investigation now. I'll update it to current and set console to it and will try again. PS. Sorry to all for my last posts to current that are so weak in "technical" details, the debug technique I used before was without remote debugging since most of problems were very near my code and it was enough for me anlo three things: my mind, printed sources, and printf. So now I am in stage of adaptation to/setting up remote debugging. rik >Kris > >-- >In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > > > > From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 11:22:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B1416A4CE for ; Mon, 13 Sep 2004 11:22:10 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5ED843D53 for ; Mon, 13 Sep 2004 11:22:09 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I3Z00LF28WWTT@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Mon, 13 Sep 2004 13:22:08 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 13 Sep 2004 13:22:07 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])i8DBM7RA014102; Mon, 13 Sep 2004 13:22:07 +0200 (MEST) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id 1C1C02846D; Mon, 13 Sep 2004 13:22:02 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id BFEBD613A; Mon, 13 Sep 2004 13:22:01 +0200 (CEST) Date: Mon, 13 Sep 2004 13:22:01 +0200 From: Christian Brueffer In-reply-to: <20040913014804.GB22583@empiric.icir.org> To: Arne Schwabe , Mike Tancsa , freebsd-current@freebsd.org Message-id: <20040913112201.GA1344@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary="/04w6evG8XlLl3ft"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.5.1i X-Operating-System: FreeBSD 5.2-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> <86vfejlow2.fsf@kamino.rfc1149.org> <20040913014804.GB22583@empiric.icir.org> Subject: Re: ichwd working for anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 11:22:10 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2004 at 06:48:04PM -0700, Bruce M Simpson wrote: > Try disabling ACPI sysresource range reservations with: > debug.acpi.disabled=3D"sysresource" >=20 > in /boot/loader.conf. I haven't tried this for ichwd but doing this allow= ed > me to load mdodd@'s SMI/SMBIOS modules for ThinkPad. >=20 FYI, this allows the amdpm driver to attach now. Before, I was getting: amdpm0: could not map i/o space - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBRYLZbHYXjKDtmC0RAlTmAJ4rVb1PSztA+KepvpvuwR07SovoEACgzr89 KTyo6CrXKYznLYYgjIfDdMc= =vzZK -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 11:50:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD7716A4D2 for ; Mon, 13 Sep 2004 11:50:26 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 199D243D60 for ; Mon, 13 Sep 2004 11:50:20 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.46.197] (ppp2EC5.dyn.pacific.net.au [61.8.46.197]) i8DBneMM024153 for ; Mon, 13 Sep 2004 21:49:41 +1000 From: Sam Lawrance To: current@freebsd.org Content-Type: text/plain Message-Id: <1095076295.77709.50.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 21:51:36 +1000 Content-Transfer-Encoding: 7bit Subject: truss -f "hangs" when traced process vfork()s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 11:50:27 -0000 Hello, If I run "truss -f make clean" in a port directory, I wind up with a situation like the following. There are three processes concerned: truss, the initially traced process, and the newly forked child: root 77739 0.0 0.2 1304 764 v1 I+ 7:50PM 0:00.02 truss -f make clean root 77740 0.0 0.1 540 376 v1 DL+ 7:50PM 0:00.01 make clean root 77741 0.0 0.1 540 376 v1 DV+ 7:50PM 0:00.00 make clean Backtrace of truss. Truss is waiting for an event to be reported from procfs (everything past msleep omitted). msleep(c1c07f28,c1c07e6c,15c,c08052e3,0) at msleep+0x312 procfs_ioctl(c16ee960,c1c07e00,c173d480,40147004,ce674c60) at procfs_ioctl+0x139 pfs_ioctl(ce674b88) at pfs_ioctl+0xd9 vn_ioctl(c2f0ae14,40147004,ce674c60,c293bc00,c16ee960) at vn_ioctl+0x187 ioctl(c16ee960,ce674d14,3,1,292) at ioctl+0x551 syscall(2f,2f,2f,8057038,2) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d8123, esp = 0xbfbfeccc, ebp = 0xbfbfed50 --- Backtrace of the initially traced process. The process has vfork()ed and is awaiting return from fork1(). vfork() calls fork1() with the RFPPWAIT flag set, so the syscall won't return until the child process exits. msleep(c1c07e00,c1c0706c,5c,c080749a,0) at msleep+0x322 fork1(c1908c80,80000034,0,d33b9ce4,c1908c80) at fork1+0x14f9 vfork(c1908c80,d33b9d14,0,1,213) at vfork+0x1b syscall(2f,2f,2f,8080ba5,0) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (66, FreeBSD ELF32, vfork), eip = 0x805c0a0, esp = 0xbfbfd780, ebp = 0xbfbfdbb8 --- Backtrace of the child process. The process has been stopped because it has generated an event and has tracing flags set (like its parent). msleep(c1c0712c,c1c0706c,5c,c080b3bb,0,c1c07128) at msleep+0x322 stopevent(c1c07000,4,1) at stopevent+0x54 syscall(2f,2f,2f,0,0) at syscall+0x1f7 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x8064d03, esp = 0xbfbfd76c, ebp = 0xbfbfdbb8 --- Normally, truss will fork a copy of itself to trace the child process once it gets the PID. However, the initially traced process is still in vfork(). So: - truss is waiting (PIOCFWAIT) for the initially traced process to stop - the initially traced process is waiting for vfork() to return - the child process created by the vfork() has been created, stopped at the first event, and is waiting to be continued (PIOCCONT) - but since truss is still waiting for for the initial process to stop on return from vfork(), it doesn't have a PID for the child, and so has not forked another truss to trace the child. The child is stranded and won't return. I haven't thought much about a solution, but perhaps truss needs to fork at syscall entry rather than syscall exit, in cases where the traced process has executed a fork that RFPPWAITs. Is this right? Shall I file a PR? -- FreeBSD dirk.no.domain 5.3-BETA4 FreeBSD 5.3-BETA4 #5: Mon Sep 13 11:20:19 EST 2004 sam@dirk.no.domain:/usr/obj/usr/src/sys/GENERIC i386 From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 11:53:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83DB716A4CE; Mon, 13 Sep 2004 11:53:28 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD1E43D5A; Mon, 13 Sep 2004 11:53:28 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C6pOh-0008G0-00; Mon, 13 Sep 2004 13:53:27 +0200 Received: from [84.128.134.217] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C6pOg-0000a9-00; Mon, 13 Sep 2004 13:53:27 +0200 From: Max Laier To: current@freebsd.org Date: Mon, 13 Sep 2004 13:51:58 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_unYRBynnNyfiBgW"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200409131352.14180.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: HEADSUP: Format correction for /var/log/pflog on archs w/ 64Bit timeval X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 11:53:28 -0000 --Boundary-02=_unYRBynnNyfiBgW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, as reported with http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/71096=20 pflogd(8) was storing machine dependend timevals in the pflog pcap file. Th= is=20 has been fixed in current a while ago and I just MT5'ed it back. Please make sure that you move away your old /var/log/pflog before the next= =20 update of pflogd(8). This affects only archs where "long" is 64bit width (all but i386 and pc98) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_unYRBynnNyfiBgW Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBRYnuXyyEoT62BG0RAsd+AJwIUS5G6PqKbrli8sIjC1GThjD3lQCfbTO+ KC3JREUU9s5mY9jc3nXS5Wk= =W9Tq -----END PGP SIGNATURE----- --Boundary-02=_unYRBynnNyfiBgW-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 13:28:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC3316A4CE for ; Mon, 13 Sep 2004 13:28:51 +0000 (GMT) Received: from KVIW12.KVI.nl (KVIW12.KVI.nl [129.125.15.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2BD43D5D for ; Mon, 13 Sep 2004 13:28:50 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIS10.KVI.nl ("port 43328"@KVIS10.KVI.nl [129.125.27.60]) <01LETNOI668OD3ZEGE@KVI.nl> for current@freebsd.org; Mon, 13 Sep 2004 15:28:42 +0200 (MET DST) Received: from KVIW14.KVI.nl by KVIS10.KVI.nl (AvMailGate-2.0.2-8) id 21073-2A530F88; Mon, 13 Sep 2004 15:28:42 +0200 Received: from kvip88 ("port 53356"@KVIP88.KVI.nl [129.125.15.152]) <01LETNO0KJAID3ZEX4@KVI.nl> for current@freebsd.org; Mon, 13 Sep 2004 15:28:19 +0200 (MET DST) Date: Mon, 13 Sep 2004 15:28:18 +0200 From: "Alexander S. Usov" To: current@freebsd.org Message-id: <200409131528.18199.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.55; host: kvi.nl) Subject: problems with msdosfs_iconv in BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 13:28:51 -0000 Hi! After updating to BETA4 I have started experiencing problems booting the system with msdos partitions in fstab. The filesystem checks in the early part of the bootstrap produces the message msdosfs: Unable to load iconv library: Shared object "libiconv.so" not found, required by "msdosfs" : Unknown error: 0 msdosfs: msdosfs_iconv: No such file or directory I saw this message in case of only msdosfs compiled in kernel and when all msdosfs, msdosfs_iconv, libiconv are compiled in. Strange, that it happens only during the second or third boot, and then persist until I comment out the corresponding line from fstab "/dev/ad0s2 /mnt msdosfs rw,-uusov,-gusov,-m644,-M755,-Wkoi2dos,-Lru_RU.KOI8-R 0 0" to let it boot. Then it's possible to mount it manually. Strange, that afterwards it gives you one-two more successful boots, and strarts complaining again. Also, when it complaind and proposes a shell to correct the problem, manual mounts also fail, but just letting it to boot corrects the problem and mounting starts working fine. IMHO it looks like a some problem with ld cache, but I didn't tried yet if rebuilding it will help. -- Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 13:42:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5913E16A4CE for ; Mon, 13 Sep 2004 13:42:49 +0000 (GMT) Received: from KVIW13.KVI.nl (KVIW13.KVI.nl [129.125.15.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D6043D4C for ; Mon, 13 Sep 2004 13:42:49 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIS10.KVI.nl ("port 43346"@KVIS10.KVI.nl [129.125.27.60]) <01LETO6UOX6YD3ZEGE@KVI.nl> for current@freebsd.org; Mon, 13 Sep 2004 15:42:43 +0200 (MET DST) Received: from KVIW06.KVI.NL by KVIS10.KVI.nl (AvMailGate-2.0.2-8) id 22812-5D10A7C2; Mon, 13 Sep 2004 15:42:42 +0200 Received: from kvip88 ("port 64638"@KVIP88.KVI.nl [129.125.15.152]) <01LETO6LB4TQD3ZEGE@KVI.nl> for current@freebsd.org; Mon, 13 Sep 2004 15:42:30 +0200 (MET DST) Date: Mon, 13 Sep 2004 15:42:29 +0200 From: "Alexander S. Usov" To: current@freebsd.org Message-id: <200409131542.29997.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.55; host: kvi.nl) Subject: USB issues in BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 13:42:49 -0000 Hi again! :) One more strange problem with BETA4 and usb-plugged HDD. The hardware (the logs here are from BETA3, but i BETA4 the issue is still present, part of the logs is skipped to save the space): intel centrino notebook, dmesg output follows uhci0: port 0x1800-0x181f irq 10 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhci1: port 0x1820-0x183f irq 5 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhci2: port 0x1840-0x185f irq 10 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 ehci0: mem 0xd0000000-0xd00003ff irq 10 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 Plugging in the USB2 hdd case after booting produces: umass0: Genesys Logic USB TO IDE, rev 2.00/0.02, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) I don't like this 1 MB/s transfer speed, and in reality it gives 8-9 MB/s. Trying to boot with the case plugged in gives right after ata detection: umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED da0 at umass-sim1 bus 1 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) umass0: at uhub0 port 1 (addr 2) disconnected umass0: detached -- Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 14:41:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0978716A4CE for ; Mon, 13 Sep 2004 14:41:47 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5899443D3F for ; Mon, 13 Sep 2004 14:41:46 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4105850B81; Mon, 13 Sep 2004 23:41:45 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id B82E050B8C; Mon, 13 Sep 2004 23:41:43 +0900 (JST) Date: Mon, 13 Sep 2004 23:41:43 +0900 Message-ID: <7misainsd4.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "Elliot Finley" In-Reply-To: <7my8jgomga.wl@black.imgsrc.co.jp> References: <06c601c4973a$1d1c5570$32cba1cd@science1> <7m8ybip6qm.wl@black.imgsrc.co.jp> <072201c4975c$db5bfa00$32cba1cd@science1> <7mzn3xo1mj.wl@black.imgsrc.co.jp> <07bb01c49812$bf4463a0$32cba1cd@science1> <7my8jgomga.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 14:41:47 -0000 At Sun, 12 Sep 2004 00:27:17 +0900, kuriyama wrote: > > Just so you're clear on what I'm doing. I made the code change, then in > > /usr/src/lib/libc I do a 'make' then a 'make install', then I do a > > 'portsdb -fu'. > > Thanks. My patch fixes 3 boxes in my office, but I find next one > still dumps core even with patch. I'll dig into more... Okay, I find NetBSD has already fixes for this. Please test with this patch if you still have problem with "portsdb -u". ==== //depot/user/kuriyama/ref5/src/lib/libc/db/btree/bt_split.c#3 - /home/kuriyama/p4/kuriyama/ref5/src/lib/libc/db/btree/bt_split.c ==== @@ -355,8 +355,6 @@ /* Put the new right page for the split into place. */ if ((r = __bt_new(t, &npg)) == NULL) return (NULL); - /* XXX: Workaround for broken page data. */ - memset(r, 0xff, t->bt_psize); r->pgno = npg; r->lower = BTDATAOFF; r->upper = t->bt_psize; @@ -728,7 +726,7 @@ * the right page. */ if (skip <= off) { - skip = 0; + skip = MAX_PAGE_OFFSET; rval = l; } else { rval = r; @@ -738,7 +736,7 @@ for (off = 0; nxt < top; ++off) { if (skip == nxt) { ++off; - skip = 0; + skip = MAX_PAGE_OFFSET; } switch (h->flags & P_TYPE) { case P_BINTERNAL: -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:35:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3235F16A4CE for ; Sun, 12 Sep 2004 15:35:16 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85FB643D53 for ; Sun, 12 Sep 2004 15:35:15 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id 53B6FDCFBA; Sun, 12 Sep 2004 17:35:14 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 29530A5677; Sun, 12 Sep 2004 17:35:14 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 074F89F830; Sun, 12 Sep 2004 17:35:14 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id E53DBD421A; Sun, 12 Sep 2004 17:35:13 +0200 (CEST) Received: from roadrunner.q.local (roadrunner [192.168.0.147]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i8CFZDTH097971; Sun, 12 Sep 2004 17:35:13 +0200 (CEST) (envelope-from q@roadrunner.q.local) Received: from roadrunner.q.local (localhost.q.local [127.0.0.1]) by roadrunner.q.local (8.13.1/8.12.10) with ESMTP id i8CFZDYM001661; Sun, 12 Sep 2004 17:35:13 +0200 (CEST) (envelope-from q@roadrunner.q.local) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.12.10/Submit) id i8CFZD1v001660; Sun, 12 Sep 2004 17:35:13 +0200 (CEST) (envelope-from q) Date: Sun, 12 Sep 2004 17:35:13 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20040912153513.GB816@galgenberg.net> Mail-Followup-To: current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) X-Mailman-Approved-At: Mon, 13 Sep 2004 14:48:07 +0000 cc: bzeeb+freebsd+lor@zabbadoz.net Subject: LOR in snd_ad1816 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Sep 2004 15:35:16 -0000 --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, this is from an oldish P2 with an ad1816 sound card. I don't have regular access to the machine, so feedback might be slow. lock order reversal 1st 0xc1621780 pcm0 (sound softc) @ /usr/src/sys/modules/sound/driver/ad18= 16/../../../../dev/sound/isa/ad1816.c:83 2nd 0xc16213c0 pcm0:play:0 (pcm play channel) @ /usr/src/sys/modules/sound= /sound/../../../dev/sound/pcm/channel.c:503 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08bdf80,c08bdeb8,c084c8bc) at kdb_backtrace+0x29 witness_checkorder(c16213c0,9,c09eec4c,1f7) at witness_checkorder+0x544 _mtx_lock_flags(c16213c0,0,c09eec4c,1f7,c1621680) at _mtx_lock_flags+0x5b chn_intr(c161a780,c1621640,c14ffd80,c1502c60,cbcfdd1c) at chn_intr+0x1b ad1816_intr(c161a900) at ad1816_intr+0x7b ithread_loop(c14ffd80,cbcfdd48,c14ffd80,c05ed66c,0) at ithread_loop+0x124 fork_exit(c05ed66c,c14ffd80,cbcfdd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xcbcfdd7c, ebp =3D 0 --- Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --T7mxYSe680VjQnyC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBRGywmArGtfDbn0QRAnTAAJ9ZhAFrGAFNkVccqDC9dVEluoJe+ACg7KNX 7GaJkuv3v+jJkKy7VcNO9jg= =WUoQ -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:41:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BAE516A4CF for ; Mon, 13 Sep 2004 01:41:27 +0000 (GMT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F3DC43D3F for ; Mon, 13 Sep 2004 01:41:27 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id 7056838CBF3 for ; Mon, 13 Sep 2004 09:39:34 +0800 (CST) Message-ID: <4144FA4A.5090601@gddsn.org.cn> Date: Mon, 13 Sep 2004 09:39:22 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040706 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Sep 2004 14:48:07 +0000 Subject: 6-CURRENT build ppp failed with -DNONETGRAPH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 01:41:27 -0000 hi,list: get the following error mesgs with today's kernel: ..... cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/tty.c /usr/src/usr.sbin/ppp/tty.c:577: warning: unused parameter 'auxfd' /usr/src/usr.sbin/ppp/tty.c:577: warning: unused parameter 'nauxfd' /usr/src/usr.sbin/ppp/tty.c:626: warning: unused parameter 'auxfd' /usr/src/usr.sbin/ppp/tty.c:626: warning: unused parameter 'nauxfd' *** Error code 1 any ideas? From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 04:00:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6E8E16A4CE for ; Mon, 13 Sep 2004 04:00:55 +0000 (GMT) Received: from www.ideaway.net (ideaway.net [207.251.107.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A5943D41 for ; Mon, 13 Sep 2004 04:00:55 +0000 (GMT) (envelope-from mspam@www.ideaway.net) Received: from www.ideaway.net (localhost [127.0.0.1]) by localhost (8.10.2/8.10.2) with ESMTP id i8D40l726098 for ; Mon, 13 Sep 2004 00:00:47 -0400 From: "Mike" To: freebsd-current@freebsd.org Date: Sun, 12 Sep 2004 23:00:47 -0500 Message-Id: <20040913040047.M3346@www.ideaway.net> X-Mailer: Open WebMail 1.81 20021203 X-OriginatingIP: 68.162.178.157 (mike@www.ideaway.net) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailman-Approved-At: Mon, 13 Sep 2004 14:49:54 +0000 Subject: cbb1: bad Vcc request. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 04:00:56 -0000 I receive this message on boot, and am unable to use the picmic wireless card in this pc (toshiba portege) on REGENG_5. I have a slightly dated -current in which I could only get the wireless cards to work on after applying the patch in the comments at http://www.freebsd.org/cgi/query-pr.cgi?pr=66848 I cvsup'ed recently, and it appears the pccard.c file has had quite a bit of change, however the same problem as existed before persists. I have emailed imp@ since the pr appears to be "owned" by him, however I have no response on the status of this problem. Will this be fixed before RC1 comes out? Is there something I am doing wrong to cause this problem? Is there something I can do to help debug this problem? What I believe is a relevant section of dmesg is below. Thank you, Mike Sep 7 19:53:04 maximator kernel: usb0: USB revision 1.0 Sep 7 19:53:04 maximator kernel: uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 7 19:53:04 maximator kernel: uhub0: 2 ports with 2 removable, self powered Sep 7 19:53:04 maximator kernel: pci0: at device 17.0 (no driver attached) Sep 7 19:53:04 maximator kernel: cbb0: at device 19.0 on pci0 Sep 7 19:53:04 maximator kernel: cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0 Sep 7 19:53:04 maximator kernel: cardbus0: on cbb0 Sep 7 19:53:04 maximator kernel: pccard0: <16-bit PCCard bus> on cbb0 Sep 7 19:53:04 maximator kernel: $PIR: 0:19 INTA routed to irq 11 Sep 7 19:53:04 maximator kernel: cbb0: [MPSAFE] Sep 7 19:53:04 maximator kernel: cbb0: bad Vcc request. ctrl=0xf000ef08, status=0xf000e2c3 Sep 7 19:53:04 maximator kernel: cbb_power: 0V Sep 7 19:53:04 maximator kernel: cbb0: PCI Configuration space: Sep 7 19:53:04 maximator kernel: 0x00: 0x060f1179 0x04800007 0x06070006 0x00820000 Sep 7 19:53:04 maximator kernel: 0x10: 0x00000000 0x04800000 0x00141400 0xfffff000 Sep 7 19:53:04 maximator kernel: 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc Sep 7 19:53:04 maximator kernel: 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400010b Sep 7 19:53:04 maximator kernel: 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 Sep 7 19:53:04 maximator kernel: 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xa0: 0x860011f0 0x00000002 0x00000000 0x0000d100 Sep 7 19:53:04 maximator kernel: 0xb0: 0x3f3f3fc3 0x0a081020 0x00010100 0x000003f1 Sep 7 19:53:04 maximator kernel: 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 Sep 7 19:53:04 maximator kernel: cbb1: at device 19.1 on pci0 Sep 7 19:53:04 maximator kernel: cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x1000 Sep 7 19:53:04 maximator kernel: cardbus1: on cbb1 Sep 7 19:53:04 maximator kernel: pccard1: <16-bit PCCard bus> on cbb1 Sep 7 19:53:04 maximator kernel: $PIR: 0:19 INTB routed to irq 11 Sep 7 19:53:04 maximator kernel: cbb1: [MPSAFE] Sep 7 19:53:04 maximator kernel: cbb1: bad Vcc request. ctrl=0x7200700, status=0x7200720 Sep 7 19:53:04 maximator kernel: cbb_power: 0V Sep 7 19:53:04 maximator kernel: cbb1: PCI Configuration space: Sep 7 19:53:04 maximator kernel: 0x00: 0x060f1179 0x04800007 0x06070006 0x00820000 Sep 7 19:53:04 maximator kernel: 0x10: 0x00001000 0x04800000 0x00151500 0xfffff000 Sep 7 19:53:04 maximator kernel: 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc Sep 7 19:53:04 maximator kernel: 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400020b Sep 7 19:53:04 maximator kernel: 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 Sep 7 19:53:04 maximator kernel: 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xa0: 0x860021f0 0x00000002 0x00000000 0x0000d100 Sep 7 19:53:04 maximator kernel: 0xb0: 0x3f3f3fc3 0x0a081020 0x00010100 0x000003f1 Sep 7 19:53:04 maximator kernel: 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 Sep 7 19:53:04 maximator kernel: 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 Sep 7 19:53:04 maximator kernel: cpu0 on motherboard Sep 7 19:53:04 maximator kernel: isa0: on motherboard From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:44:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A505B16A4CE for ; Mon, 13 Sep 2004 08:44:05 +0000 (GMT) Received: from mail-out.emea.daimlerchrysler.com (mail-out.emea.daimlerchrysler.com [141.113.102.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB7343D53 for ; Mon, 13 Sep 2004 08:44:04 +0000 (GMT) (envelope-from class_consulting.leidinger@daimlerchrysler.com) Date: Mon, 13 Sep 2004 10:42:49 +0200 From: class_consulting.leidinger@daimlerchrysler.com To: current@FreeBSD.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 13 Sep 2004 14:48:07 +0000 Subject: panic very early at boot with -current (20040912-SESNAP) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 08:44:05 -0000 Hi, please excuse if this mails exhibits unfriendly behavior, I'm not the mail-admin here and I have to use Lotus Notes... I've downloaded the 20040912 sesnap of -current to install it on my laptop. It panics immediatly after loading the kernel. The manufacturer of the Laptop went away, so there's no chance to get a new BIOS. Additionally it doesn't has serial lines or a floppy drive. 4.x doesn't panic, but it isn't able to find the root-FS (I think it can't find the CD drive). The panic (non verbose boot) looks like: ---snip--- [Copyright] [WITNESS enabled] [Timecounter i8254] [mobile Athlon XP 1800+] [239 MB real memory] [npx] pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 [in a verbose boot I see "found ->" for vendor 0x1106 and devices 0x3156 (revid=0x00) and device 0xb091 (revid=0x0) and for vendor 0x1524, dev 0x1410] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xe7136 faul code = supervisor read, page not present instruction pointer = 0x8:0xc00e9005 stack pointer = 0x10:0xc1021a4c frame pointer = 0x10:0xc1021a4c 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 = 0 (swapper) [thread 0] Stopped at 0xc00e9005: cmpb %cs:0x1(%esi),%bl db> trace kernbase(...) end(...) db> ---snip--- Booting with ACPI enabled (the non default mode of booting from the cdboot CD) changes the behavior, no panic and it boots just fine into sysinstall. I hope we can replace this panic with a "please try to boot with ACPI enabled" or something like this in RELENG_5_3, since we will get bad press if we ship without a fix and a tester stumbles over this problem. It's definitivly a showstopper for novices which want to give FreeBSD a try and don't know as much about FreeBSD as we do. I can provide additional information of a verbose boot or debug specific parts and report back, but I can't download and burn something until I'm back home (at the weekend). I haven't installed 6-current yet, but the already installed DragonFly 1.0 boots just fine, so if you need some additional information which I can provide with a copy&paste (by hand, my laptop has no other possibility to share data with my office-computer) from DragonFly (e.g. pciconv -l), just ask. The same applies for information I can get with a "cdboot" image of -current without installing FreeBSD. Bye, Alexander. -- Alexander Leidinger, Diplom-Informatiker Class Consulting Admin im MIF-Projekt (T-Systems / Daimler-Chrysler) Tel.: 0711/972-44286 From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 13:58:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA5216A4CE for ; Mon, 13 Sep 2004 13:58:50 +0000 (GMT) Received: from GreenSrv.rz.unibw-muenchen.de (greensrv.RZ.UniBw-Muenchen.de [137.193.10.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACF043D6D for ; Mon, 13 Sep 2004 13:58:49 +0000 (GMT) (envelope-from lutz@medusa.informatik.unibw-muenchen.de) Received: from localhost (GreenSrv [127.0.0.1])i8DDwPgu012486 for ; Mon, 13 Sep 2004 15:58:25 +0200 Received: from GreenSrv.rz.unibw-muenchen.de ([127.0.0.1]) by localhost (GreenSrv [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12297-04 for ; Mon, 13 Sep 2004 15:58:20 +0200 (CEST) Received: from medusa.informatik.unibw-muenchen.de (medusa.Informatik.UniBw-Muenchen.de [137.193.60.34])i8DDwIcw012464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Sep 2004 15:58:18 +0200 X-Remarks: If SPAM is relayed via GreenSrv.rz.unibw-muenchen.de to outside of unibw-muenchen.de, please report it to abuse@unibw-muenchen.de Received: from lutz by medusa.informatik.unibw-muenchen.de with local (Exim 4.42 (FreeBSD)) id 1C6rJv-0000D8-Jv for current@freebsd.org; Mon, 13 Sep 2004 15:56:39 +0200 From: Lutz Bichler Organization: University of the Federal Armed Forces Munich To: current@freebsd.org Date: Mon, 13 Sep 2004 15:56:39 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409131556.39420.Lutz.Bichler@unibw-muenchen.de> Sender: Lutz Bichler X-Virus-Scanned: by amavisd-new at GreenSrv.rz.unibw-muenchen.de X-Mailman-Approved-At: Mon, 13 Sep 2004 14:48:07 +0000 Subject: Problem with snd_ich X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 13:58:50 -0000 Hi, i tried the patch, which was sent to the list. Unfortunately it does not change anything. Regards Lutz From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 15:19:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 888CA16A4CE for ; Mon, 13 Sep 2004 15:19:18 +0000 (GMT) Received: from outmx001.isp.belgacom.be (outmx001.isp.belgacom.be [195.238.3.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id C226C43D2D for ; Mon, 13 Sep 2004 15:19:12 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx001.isp.belgacom.be (localhost [127.0.0.1]) with ESMTP id i8DFIxVh024834 for ; Mon, 13 Sep 2004 17:19:03 +0200 (envelope-from ) Received: from [192.168.70.42] (154.110-136-217.adsl.skynet.be [217.136.110.154])with ESMTP id i8DFItPU024800; Mon, 13 Sep 2004 17:18:55 +0200 (envelope-from ) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Mon, 13 Sep 2004 17:20:58 +0200 User-Agent: KMail/1.6.2 References: <20040913040047.M3346@www.ideaway.net> In-Reply-To: <20040913040047.M3346@www.ideaway.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409131720.58573.tijl@ulyssis.org> cc: mspam@www.ideaway.net Subject: Re: cbb1: bad Vcc request. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 15:19:18 -0000 Hello Mike, On Monday 13 September 2004 06:00, Mike wrote: > I receive this message on boot, and am unable to use the picmic > wireless card in this pc (toshiba portege) on REGENG_5. I have a > slightly dated -current in which I could only get the wireless > cards to work on after applying the patch in the comments at > http://www.freebsd.org/cgi/query-pr.cgi?pr=66848 > I cvsup'ed recently, and it appears the pccard.c file has > had quite a bit of change, however the same problem as > existed before persists. I had the same problem when I recently switched to 5-current. The PR you referred to, fixed it. You can find a more up to date patch at http://lists.freebsd.org/pipermail/freebsd-mobile/2004-September/004726.html From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 15:24:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30E5D16A4CE; Mon, 13 Sep 2004 15:24:21 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99C5043D53; Mon, 13 Sep 2004 15:24:20 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8DFOJLn094703; Mon, 13 Sep 2004 11:24:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 94643-01; Mon, 13 Sep 2004 11:24:19 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8DFOJVL094668; Mon, 13 Sep 2004 11:24:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8DFOADv015374; Mon, 13 Sep 2004 11:24:11 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040913111109.087cb9d0@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 13 Sep 2004 11:29:17 -0400 To: Bruce M Simpson From: Mike Tancsa In-Reply-To: <6.1.2.0.0.20040912220440.0867d3d0@64.7.153.2> References: <6.1.2.0.0.20040912063508.050a4fb0@64.7.153.2> <86vfejlow2.fsf@kamino.rfc1149.org> <20040913014804.GB22583@empiric.icir.org> <6.1.2.0.0.20040912220440.0867d3d0@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-current@freebsd.org Subject: Re: ichwd working for anyone ? (and watchdog vs watchdogd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 15:24:21 -0000 At 11:42 PM 12/09/2004, Mike Tancsa wrote: >At 09:48 PM 12/09/2004, Bruce M Simpson wrote: >>Try disabling ACPI sysresource range reservations with: >> debug.acpi.disabled="sysresource" >> >>in /boot/loader.conf. I haven't tried this for ichwd but doing this allowed >>me to load mdodd@'s SMI/SMBIOS modules for ThinkPad. > >Hmmm, this seems to help a bit but the functionality is not there. The >module loads and doesnt complain, but it doesnt work in that the daemon >does not seem to be able to "arm" it so that it reboots This might be a problem with the ichwd at this point. I grabbed the original watchdog kld from, http://freebsd.tamu.edu/wdog/ and applied the following patches --- i8xxwd.c Wed Mar 24 07:25:35 2004 +++ ../i8xxwd-current.patches/i8xxwd.c Mon Sep 13 11:02:44 2004 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -48,6 +49,7 @@ {VENDORID_INTEL, DEVICEID_82801CAX, "Intel 82801CA/82801CAM watchdog device"}, {VENDORID_INTEL, DEVICEID_82801DB, "Intel 82801DB watchdog device"}, {VENDORID_INTEL, DEVICEID_82801E, "Intel 82801E watchdog device"}, + {VENDORID_INTEL, DEVICEID_82801EBR, "Intel 82801EB / ER watchdog timer" }, {VENDORID_INTEL, 0, ""}, }; --- i8xxwd.h Wed Mar 24 07:16:17 2004 +++ ../i8xxwd-current.patches/i8xxwd.h Mon Sep 13 11:02:17 2004 @@ -43,7 +43,9 @@ #define DEVICEID_82801CAX 0x2480 #define DEVICEID_82801DB 0x24c0 #define DEVICEID_82801E 0x2450 - +#define DEVICEID_82801EBR 0x24d0 + + #define SMIBASE_OFFSET 0x30 #define TCOBASE_OFFSET 0x60 #define PMBASE 0x40 Loading just this module and then using watchdogd -t 10 and then a kill -9 of the watchdogd program and the box reboots about 10 seconds later. With icwhd, no reboot. And I can get the i8xxwd kld to work just fine without having to put debug.acpi.disabled="sysresource" in /boot/loader.conf Also, why are there 2 watchdog programs in the base ? releng5-865# which watchdog /usr/sbin/watchdog releng5-865# which watchdogd /usr/sbin/watchdogd releng5-865# ---Mike >I tried it as a kld and as statically compiled into the kernel and no dice >on either and statically compiled in is worse. > >Also, why would booting without ACPI not work as well if its the "problem" ? > > >Adding a couple of printfs to the watchdog, the ioctl is returning zero > > >But if I kill -9 the daemon, the box does not reboot > > From the console, > >ichwd module loaded >ichwd_identify(): found ICH chipset: Intel 82801EB/ER watchdog timer >ichwd0: on motherboard >ichwd0: timer disabled >ichwd0: timer enabled >ichwd0: timeout set to 28 ticks >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded > >FreeBSD/i386 (releng5-865.sentex.ca) (ttyd0) > >login: >ichwd0: timer reloaded > >FreeBSD/i386 (releng5-865.sentex.ca) (ttyd0) > >login: ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded >ichwd0: timer reloaded > > > >One last thing which I dont know if its significant or not, but after >loading the kld, on reboot I get > > >Shutting down local daemons:. >Writing entropy file:. >Terminated >. >Sep 12 23:00:39 releng5-865 syslogd: exiting on signal 15 >Waiting (max 60 seconds) for system process `vnlru' to stop...done >Waiting (max 60 seconds) for system process `bufdaemon' to stop...done >Waiting (max 60 seconds) for system process `syncer' to stop... >Syncing disks, vnodes remaining...2 2 2 2 0 0 done >No buffers busy after final sync >Uptime: 16m36s >Shutting down ACPI > ACPI-0265: *** Error: Hardware never changed modes > > ---Mike >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 15:25:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D449516A4D0; Mon, 13 Sep 2004 15:25:21 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD78C43D54; Mon, 13 Sep 2004 15:25:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8DFPr1L029181; Mon, 13 Sep 2004 09:25:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4145BB0D.20905@samsco.org> Date: Mon, 13 Sep 2004 09:21:49 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roman Kurakin References: <414560D3.10108@cronyx.ru> <20040913105133.GA85717@hub.freebsd.org> <414581FE.6060702@cronyx.ru> In-Reply-To: <414581FE.6060702@cronyx.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: Large mem disk with not very recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 15:25:22 -0000 Roman Kurakin wrote: > Kris Kennaway wrote: > >> On Mon, Sep 13, 2004 at 12:56:51PM +0400, Roman Kurakin wrote: >> >> >>> Hi, >>> >>> I have the following idea/problem. I want to build world in memory. >>> I've put in to my system 1G of memory and tried to put on it sources. >>> But all times I've tried to do that system went to panic. I've used md >>> with malloc type. >>> >>> Any ideas? >>> >> >> >> Please provide more information. It's likely you're trying to create >> a md that is too big, though. >> >> > It is about 800Mb. But system panics while I try to extract source tree. > It is not very recent > current. The intent of my question was to get some hints how to set up > such build area, I > belive it should help to make compilation much faster than using hard > drive. My home system > is not ready for panic investigation now. I'll update it to current and > set console to it and will > try again. > > > PS. Sorry to all for my last posts to current that are so weak in > "technical" details, the debug > technique I used before was without remote debugging since most of > problems were very > near my code and it was enough for me anlo three things: my mind, > printed sources, and printf. > So now I am in stage of adaptation to/setting up remote debugging. > > rik What kind of panic was it? Try using swap backing instead of malloc. Malloc will consume wired memory and will generally make life difficult for other parts of the kernel that need memory later. Swap-backed pages will stay in RAM until the VM needs to push them out due to memory pressure. Scott From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 15:34:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15E4D16A4CE for ; Mon, 13 Sep 2004 15:34:39 +0000 (GMT) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3EB743D31 for ; Mon, 13 Sep 2004 15:34:37 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net id i8DFYakN004058 (8.12.10/1.4); Mon, 13 Sep 2004 17:34:36 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id i8DFYalr007131 (8.12.10/2.02); Mon, 13 Sep 2004 17:34:36 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Mon, 13 Sep 2004 17:34:36 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: kern.ipc.nmbclusters X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 15:34:39 -0000 Hi. Increasing kern.ipc.nmbclusters on a running box generally causes 'kmem_map too small' panics, because (I guess) vm.kmem_size is not adjusted accordingly. Similarly things go very wrong if I boot with 'kern.ipc.nmbcluster=0' in /boot/loader.conf. Is one supposed to do any of this? :) Just curious. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 16:02:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F19116A4CE for ; Mon, 13 Sep 2004 16:02:59 +0000 (GMT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 549CD43D53 for ; Mon, 13 Sep 2004 16:02:58 +0000 (GMT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1])i8DG2v897221 for ; Tue, 14 Sep 2004 01:02:57 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <20040913000216E.matusita@jp.FreeBSD.org> References: <20040913000216E.matusita@jp.FreeBSD.org> X-User-Agent: Mew/1.94.2 Emacs/21.3 X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20040704(IM147) Lines: 10 From: Makoto Matsushita To: current@FreeBSD.org Date: Tue, 14 Sep 2004 01:02:55 +0900 Message-Id: <20040914010255H.matusita@jp.FreeBSD.org> Subject: Re: Recent 6.0-CURRENT and VMware 4.2.1: boot problem with PREEMPTION enabled kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Sep 2004 16:02:59 -0000 matusita> I've just found that my VMware Workstation virtual machine doesn't matusita> boot as expected with recent 6.0-CURRENT kernel. For example, with matusita> 6.0-CURRENT-20040912-JPSNAP boot floppies, following three lines are matusita> the last message, and stops VM forever: Hmm, it seems that 5.3-BETA4 boot floppies have no problem... -- - Makoto `MAR' Matsushita From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 16:16:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C2416A4CE; Mon, 13 Sep 2004 16:16:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9AD443D53; Mon, 13 Sep 2004 16:16:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i8DGGYMI049549; Mon, 13 Sep 2004 12:16:34 -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.12.11/8.12.11) with ESMTP id i8DGGYbJ015262; Mon, 13 Sep 2004 12:16:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 222E17303F; Mon, 13 Sep 2004 12:16:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040913161634.222E17303F@freebsd-current.sentex.ca> Date: Mon, 13 Sep 2004 12:16:34 -0400 (EDT) Subject: [releng_5 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: