From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 01:28:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1878116A400 for ; Sun, 25 Mar 2007 01:28:04 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id D90B613C468 for ; Sun, 25 Mar 2007 01:28:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l2P1A1aA007866; Sat, 24 Mar 2007 20:10:02 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l2P1A0T5007865; Sat, 24 Mar 2007 20:10:00 -0500 (CDT) (envelope-from brooks) Date: Sat, 24 Mar 2007 20:10:00 -0500 From: Brooks Davis To: Yar Tikhiy Message-ID: <20070325011000.GB7607@lor.one-eyed-alien.net> References: <20070322173144.46C7D45047@ptavv.es.net> <20070323110315.GB19357@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <20070323110315.GB19357@comp.chem.msu.su> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sat, 24 Mar 2007 20:10:02 -0500 (CDT) Cc: current@freebsd.org Subject: Re: ifconfig stopped loading driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 01:28:04 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 23, 2007 at 02:03:16PM +0300, Yar Tikhiy wrote: > On Thu, Mar 22, 2007 at 10:31:44AM -0700, Kevin Oberman wrote: > > > Date: Thu, 22 Mar 2007 09:15:22 -0700 > > > From: "Kip Macy" > > > > > > On 3/22/07, Kevin Oberman wrote: > > > > For a long time under V6 and current (and probably V5), if I issued= an > > > > ifconfig for my Atheros card, the driver (along with the HAL and ra= te > > > > modules) would auto-load and my card would be found. > > > > > > > > Starting with my March 19 build, this no longer happens. I need to = boot > > > > single-user and manually load the module if I will need it. I don't= want > > > > the card to start by default since I don't want the radio on when I= am > > > > flying. > > > > > > > > Was this a deliberate change or did something break? It is a real p= ain. > >=20 > > O.K. It is clearly a deliberate change, although I am not sure the > > effect is what was intended. > >=20 > > The call to ifmaybeload(ifname) was moved inside of the if for a > > "create" which applies to pseudo-devices, but not "real" interfaces. As > > a result, the driver never gets loaded. I read the commit message, but I > > don't think that this is the right way to fix the problem > > described. (I'm not sure, what a better approach might be, though.) > >=20 > > This breaks behavior that goes back over 7 years, having appeared in > > the first release of V4. I can work around it, but it's going to be a > > big surprise to many and it is sure a pain in the neck to me. >=20 > I readily admit that my change provoked your trouble. When committing > it, I took into account only cloned interfaces, but not hardware > ones, perhaps because I had never used modules for hardware interfaces. >=20 > Nevertheless, I still think that the practice of loading the module > on any ifconfig command is poor in spite of its age. It can be > worked around only by dirty hacks. One of them is an ifconfig > option not to load the module for devd scripts to use it when > shutting down the interface. Another one is to load the module > only on "positive" ifconfig commands, such as "up" and "alias" > (incl. the first address,) but not on "negative" ones, e.g., "down" > and "-alias" -- but what to do with "ifconfig -alias up" then? >=20 > Perhaps it's time to have "ifconfig foo0 load" along with "ifconfig > bar0 create" to allow loading the module explicitly. People even > won't have to specify "load" in their rc.conf files as rc.d can add > it for them when, and only when, the interface is started. >=20 > Comments? This is a bad idea, IMO. I think ifconfig shouldn't attempt to load modules at all, but am willing to be overruled for historical cases. Added bits to ifconfig to make it a cripped version of kldload with a wierd syntax makes no sense. -- Brooks --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGBcvoXY6L6fI4GtQRAiEkAKCMye2mKfgjaz6S536FlBnY5DBm3wCgghBE LQcweVVIZvRnVhWurUHkJjY= =Uex5 -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 06:14:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1C5B16A400 for ; Sun, 25 Mar 2007 06:14:47 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id C0A2D13C465 for ; Sun, 25 Mar 2007 06:14:47 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a7.g.dreamhost.com (sd-green-bigip-83.dreamhost.com [208.97.132.83]) by sumo.dreamhost.com (Postfix) with ESMTP id 206E517BD7C for ; Sat, 24 Mar 2007 22:50:16 -0700 (PDT) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a7.g.dreamhost.com (Postfix) with ESMTP id D178C5C0C2 for ; Sat, 24 Mar 2007 22:50:13 -0700 (PDT) Message-ID: <46060D94.2060506@cyberwang.net> Date: Sun, 25 Mar 2007 01:50:12 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 06:14:47 -0000 It's really strange. Ever since I updated to the latest source, loading snd_ich leads to a kernel panic. oich_add_done is where it panics, I don't have any experience gathering information that might be relevant, but if anyone wants to look in to the issue i will provide and learn anything required to resolve the issue (not having sound is a serious issue!) From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 09:59:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB10616A400 for ; Sun, 25 Mar 2007 09:59:40 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1CB13C44C for ; Sun, 25 Mar 2007 09:59:40 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.5.6) with ESMTP id md50000991770.msg for ; Sun, 25 Mar 2007 13:42:22 +0400 Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 13:42:15 +0400 Date: Sun, 25 Mar 2007 13:41:51 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: freebsd-current@freebsd.org Message-ID: <20070325133125.X899@free.home.local> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1606194510-1174815711=:899" X-OriginalArrivalTime: 25 Mar 2007 09:42:18.0251 (UTC) FILETIME=[E0CB45B0:01C76EC1] X-Spam-Processed: mx.gfk.ru, Sun, 25 Mar 2007 13:42:22 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx.gfk.ru, Sun, 25 Mar 2007 13:42:23 +0400 Cc: Subject: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 09:59:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1606194510-1174815711=:899 Content-Type: TEXT/PLAIN; charset=KOI8-R; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE I'm getting repeatable panic with kernel & userland from yesterday evening= =20 when I try to connect to Internet using bluetooth to connect to my phone: "rfcomm_pppd -a e60 -c -C dun -l mts". Everything works well with kernel from last weekend. With yesterday kernel= =20 it always panic. Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex radix node head r =3D 0 (0xc30bc37c) locked @ /usr/sr= c/sys/net/rtsock.c:1258 KDB: stack backtrace: db_trace_self_wrapper(c0923433) at db_trace_self_wrapper+0x25 kdb_backtrace(1,c350b240,c,d61c1a5c,d61c1a50,...) at kdb_backtrace+0x29 witness_warn(5,0,c0933ff7) at witness_warn+0x192 trap(d61c1a5c) at trap+0x10b calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc074a451, esp =3D 0xd61c1a9c, ebp =3D 0xd61c1adc --= - sysctl_dumpentry(c324ebb8,d61c1b28) at sysctl_dumpentry+0x65 rn_walktree(c30bc300,c074a3ec,d61c1b28,c30bc37c,0,...) at rn_walktree+0x7a sysctl_rtsock(c0a05060,d61c1c20,4,d61c1b98,c0a05060,...) at sysctl_rtsock+0= x10a sysctl_root(0,d61c1c18,6,d61c1b98) at sysctl_root+0x12f userland_sysctl(c3255000,d61c1c18,6,0,bfbfdedc,0,0,0,d61c1c14,0,c0a51808,0,= c09605c8,51e) at userland_sysctl+0xf4 __sysctl(c3255000,d61c1d00) at __sysctl+0x77 syscall(d61c1d38) at syscall+0x252 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip =3D 0x2830a027, esp =3D 0xb= fbfde6c, ebp =3D 0xbfbfdea8 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address=09=3D 0x0 fault code=09=09=3D supervisor read, page not present instruction pointer=09=3D 0x20:0xc074a451 stack pointer=09 =3D 0x28:0xd61c1a9c frame pointer=09 =3D 0x28:0xd61c1adc code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b =09=09=09=3D DPL 0, pres 1, def32 1, gran 1 processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 current process=09=09=3D 963 (ppp) trap number=09=09=3D 12 panic: page fault cpuid =3D 0 -->bt #0 doadump () at pcpu.h:172 #1 0xc06c2d74 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc06c307e in panic (fmt=3D0xc0904aff "%s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc08c04da in trap_fatal (frame=3D0xd61c1a5c, eva=3D0) at /usr/src/sys/i386/i386/trap.c:868 #4 0xc08bfb1f in trap (frame=3D0xd61c1a5c) at /usr/src/sys/i386/i386/trap.= c:276 #5 0xc08a9ebb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc074a451 in sysctl_dumpentry (rn=3D0xc324ebb8, vw=3D0xd61c1b28) at /usr/src/sys/net/rtsock.c:1091 #7 0xc074696e in rn_walktree (h=3D0xc356c494, f=3D0xc074a3ec , w=3D0xd61c1b28) at /usr/src/sys/net/radix.c:1083 #8 0xc074a9aa in sysctl_rtsock (oidp=3D0xc0a05060, arg1=3D0xd61c1c20, arg2= =3D4, req=3D0xc30bc300) at /usr/src/sys/net/rtsock.c:1259 #9 0xc06caf0f in sysctl_root (oidp=3D0x0, arg1=3D0xd61c1c20, arg2=3D4, req=3D0xd61c1b98) at /usr/src/sys/kern/kern_sysctl.c:1282 #10 0xc06cb0e0 in userland_sysctl (td=3D0xc356c494, name=3D0xd61c1c18, name= len=3D6, old=3D0xd61c1b98, oldlenp=3D0xbfbfdedc, inkernel=3D0, new=3D0x0, newlen=3D3277243540, retval=3D0xd61c1c14, flags=3D-1017723756) at /usr/src/sys/kern/kern_sysctl.c:1377 #11 0xc06caf97 in __sysctl (td=3D0xc3255000, uap=3D0xd61c1d00) at /usr/src/sys/kern/kern_sysctl.c:1312 #12 0xc08c07b2 in syscall (frame=3D0xd61c1d38) at /usr/src/sys/i386/i386/trap.c:1010 #13 0xc08a9f20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) -->f 6 #6 0xc074a451 in sysctl_dumpentry (rn=3D0xc324ebb8, vw=3D0xd61c1b28) at /usr/src/sys/net/rtsock.c:1091 1091=09=09=09info.rti_info[RTAX_IFA] =3D rt->rt_ifa->ifa_addr; -->p *rt $1 =3D {rt_nodes =3D {{rn_mklist =3D 0x0, rn_parent =3D 0xc324ebd0, rn_bit = =3D -97, rn_bmask =3D 0 '\0', rn_flags =3D 5 '\005', rn_u =3D {rn_leaf =3D { rn_Key =3D 0xc352a600 "\034\034", rn_Mask =3D 0xc3233cb0 "\f", '=FF' , rn_Dupedkey =3D 0x0}, rn_node =3D {rn_Off =3D -1017993728, rn_L =3D 0xc3233cb0, rn_R =3D 0x0}}}, {rn_mklist =3D 0x0, rn_parent =3D 0xc324ee28, rn_bit =3D 93, rn_bmask =3D 4 '\004', rn_flags =3D 4 '\004', rn_u =3D {rn_leaf =3D { rn_Key =3D 0xb
, rn_Mask =3D 0xc324ee= 88 "", rn_Dupedkey =3D 0xc324ebb8}, rn_node =3D {rn_Off =3D 11, rn_L =3D 0xc324ee88, rn_R =3D 0xc324ebb8}}}}, rt_gateway =3D 0xc= 352a61c, rt_flags =3D 8388867, rt_ifp =3D 0xc30c0000, rt_ifa =3D 0x0, rt_rmx =3D = { rmx_mtu =3D 1500, rmx_expire =3D 0, rmx_pksent =3D 0}, rt_refcnt =3D 0= , rt_genmask =3D 0x0, rt_llinfo =3D 0x0, rt_gwroute =3D 0x0, rt_parent =3D= 0x0, rt_mtx =3D {lock_object =3D {lo_name =3D 0xc0924097 "rtentry", lo_type =3D 0xc0924097 "rtentry", lo_flags =3D 21168128, lo_witness_= data =3D { lod_list =3D {stqe_next =3D 0xc0a621d0}, lod_witness =3D 0xc0a621d= 0}}, mtx_lock =3D 4, mtx_recurse =3D 0}} --0-1606194510-1174815711=:899-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 10:29:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 042BF16A402; Sun, 25 Mar 2007 10:29:03 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sun, 25 Mar 2007 18:28:36 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070325182836.548f3585.ariff@FreeBSD.org> In-Reply-To: <46060D94.2060506@cyberwang.net> References: <46060D94.2060506@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__25_Mar_2007_18_28_36_+0800_D1Hiu0Az.OtbB_FE" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 10:29:05 -0000 --Signature=_Sun__25_Mar_2007_18_28_36_+0800_D1Hiu0Az.OtbB_FE Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 01:50:12 -0400 Sean Bryant wrote: > It's really strange. >=20 > Ever since I updated to the latest source, loading snd_ich leads to > a kernel panic. oich_add_done is where it panics, I don't have any=20 > experience gathering information that might be relevant, but if > anyone wants to look in to the issue i will provide and learn > anything required to resolve the issue (not having sound is a > serious issue!) Not having enough debugging informations is a serious issue, too Besides, how do you come up with "oich_add_done" ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug.html -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sun__25_Mar_2007_18_28_36_+0800_D1Hiu0Az.OtbB_FE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBk7Ulr+deMUwTNoRAlTuAJ0ZdY0ILjy8bDueLfxeZQI1NYr/AQCgkJbL bpahnUBbhURn9kOvpIDB9QU= =Y5K4 -----END PGP SIGNATURE----- --Signature=_Sun__25_Mar_2007_18_28_36_+0800_D1Hiu0Az.OtbB_FE-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 10:45:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2756516A403 for ; Sun, 25 Mar 2007 10:45:10 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av8-1-sn3.vrr.skanova.net (av8-1-sn3.vrr.skanova.net [81.228.9.183]) by mx1.freebsd.org (Postfix) with ESMTP id D786013C46A for ; Sun, 25 Mar 2007 10:45:09 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 904E1380A4; Sun, 25 Mar 2007 12:45:08 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5E1933800B; Sun, 25 Mar 2007 12:45:08 +0200 (CEST) Received: from [192.168.1.198] (81-234-214-163-no68.tbcn.telia.com [81.234.214.163]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 0933737E47; Sun, 25 Mar 2007 12:45:07 +0200 (CEST) From: Joel Dahl To: Ariff Abdullah In-Reply-To: <20070325182836.548f3585.ariff@FreeBSD.org> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> Content-Type: text/plain Date: Sun, 25 Mar 2007 12:45:06 +0200 Message-Id: <1174819506.1150.4.camel@jesus.automatvapen.se> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Sean Bryant Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 10:45:10 -0000 On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: > On Sun, 25 Mar 2007 01:50:12 -0400 > Sean Bryant wrote: > > It's really strange. > > > > Ever since I updated to the latest source, loading snd_ich leads to > > a kernel panic. oich_add_done is where it panics, I don't have any > > experience gathering information that might be relevant, but if > > anyone wants to look in to the issue i will provide and learn > > anything required to resolve the issue (not having sound is a > > serious issue!) > > Not having enough debugging informations is a serious issue, too > Besides, how do you come up with "oich_add_done" ? "ohci_add_done" sounds more likely: joel@jesus [/usr/src] grep -R add_done * sys/dev/usb/ohci.c:static void ohci_add_done(ohci_softc_t *, ohci_physaddr_t); sys/dev/usb/ohci.c: ohci_add_done(sc, done &~ OHCI_DONE_INTRS); sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t *sc, ohci_physaddr_t done) sys/dev/usb/ohci.c: panic("ohci_add_done: addr 0x%08lx not found", (u_long)done); -- Joel From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 09:01:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 273C916A402 for ; Sun, 25 Mar 2007 09:01:32 +0000 (UTC) (envelope-from mosworld@lgphilips-lcd.com) Received: from nospam.lgphilips-lcd.com (relay.lgphilips-lcd.com [203.247.144.180]) by mx1.freebsd.org (Postfix) with SMTP id BD8F913C44B for ; Sun, 25 Mar 2007 09:01:31 +0000 (UTC) (envelope-from mosworld@lgphilips-lcd.com) Received: (snipe 23273 invoked by uid 0); 25 Mar 2007 17:34:49 +0900 Received: from mosworld@lgphilips-lcd.com with Spamsniper 2.94.24 (Processed in 0.028831 secs); Received: from unknown (HELO gwkumi04.lgphilips-lcd.com) (156.147.188.200) by unknown with SMTP; 25 Mar 2007 17:34:49 +0900 X-RCPTTO: freebsd-current@freebsd.org Received: from gwpaju02.lgphilips-lcd.com ([172.19.68.12]) by gwkumi04.lgphilips-lcd.com (Lotus Domino Release 6.5.4FP1) with ESMTP id 2007032517345233-3894599 ; Sun, 25 Mar 2007 17:34:52 +0900 To: freebsd-current@freebsd.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: "SUNGBAK KIM" Date: Sun, 25 Mar 2007 17:34:48 +0900 X-MIMETrack: Serialize by Router on GWPAJU02/LGPHILIPS(Release 6.5.4FP1 | June 19, 2005) at 2007-03-25 17:34:49, Serialize complete at 2007-03-25 17:34:49, Itemize by SMTP Server on GWKUMI04/LGPHILIPS(Release 6.5.4FP1|June 19, 2005) at 2007-03-25 오후 05:34:52, Serialize by Router on GWKUMI04/LGPHILIPS(Release 6.5.4FP1|June 19, 2005) at 2007-03-25 오후 05:34:52, Serialize complete at 2007-03-25 오후 05:34:52 X-Mailman-Approved-At: Sun, 25 Mar 2007 11:23:15 +0000 Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NI PCI-GPIB tnt4882 test failed on FreeBSD Current 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 09:01:32 -0000 I'm a one of traditional FreeBSD leaf user since Release 2.x and testing GPIB control with FreeBSD 7.0 Current because of supporting NI PCI-GPIB interface card. I finished testing on Red Hat 9, which shows on http://linux-gpib.sourceforge.net/ but prefer to use with FreeBSD. I have trouble with controlling tnt4882 driver although appropriate kerenel configuration and having /dev/gpibxx entry. I will show testing status 1. Hardware information Hardware : CPU CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 2. Install : FreeBSD 6.2R (i386) -> make update(Mar. 24 2007) with standard-supfile -> make world, make kernel (No build option & Compile option in /etc/make.conf ) 3. KERNEL CONFIG & Configuration shell > more /usr/src/sys/i386/conf/GENERIC ... device pcii device tnt4882 shell > uname -a FreeBSD xxx.yyy.com 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sat Mar 24 15:11:47 KST 2007 root@xxx.yyy.com:/usr/obj/usr/src/sys/GENERIC i386 shell > dmesg ... tnt48820: mem 0xe7207000-0xe72077ff,0xe7200000-0xe7203fff irq 19 at device 8.0 on pci0 tnt48820: [ITHREAD] ... shell > ls -alF /dev/gpib* crw-rw-rw- 1 gpib gpib 0, 38 Mar 25 14:46 gpib0ib crw-rw-rw- 1 gpib gpib 0, 37 Mar 25 14:46 gpib0l 4. Basic Code Testing I compiled *IDN? Qurey C code as shown below archive but no response from instrument (AFG3102, etc and linux-gpib returned good results ). http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2005-February/010164.html and modyfied Code returned dmm = 0 /*** PRINT DMM ****/ dmm = ibdev(0, 11, 0, T1s, 1, 0); printf(" dmm = %d\n", dmm); if (dmm < 0) errx(1, "ibdev = %d\n", dmm); ibwrt(dmm, "*IDN?\r\n", 7); I think dmm should be dmm > 0, if properly configured. right ? What is mis-configured ? Please notice me. ################################################### Kim Sung Bak /Research Engineer LG.Philips LCD Fax: +82-31-933-7594 Tel: +82-31-933-7308 Mobile: +82-19-9181-8136 mail: NOSPAMmosworld@lgphilips-lcd.comNOSPAM Homeage: http://www.lghilips-lcd.com/ #################################################### From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 10:54:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5E8416A401 for ; Sun, 25 Mar 2007 10:54:59 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id B75F013C45E for ; Sun, 25 Mar 2007 10:54:59 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id DA02F2AD569F; Sun, 25 Mar 2007 10:54:57 +0000 (UTC) Received: from [69.31.99.14] (pool014.dhcp.your.org [69.31.99.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id D1A66A0A44E; Sun, 25 Mar 2007 10:54:56 +0000 (UTC) In-Reply-To: <4600C451.2020407@samsco.org> References: <52299CBE-F3AD-439D-820D-3FC3458614F8@dragondata.com> <4600C451.2020407@samsco.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Sun, 25 Mar 2007 05:55:32 -0500 To: Scott Long X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Sun, 25 Mar 2007 11:23:31 +0000 Cc: freebsd-current@freebsd.org Subject: Re: aac & PAE not happy in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 10:55:00 -0000 On Mar 21, 2007, at 12:36 AM, Scott Long wrote: >> Booting the same kernel without PAE I get the same thing: >> aacch0: port 0xcc00-0xccff mem >> 0xfccff000-0xfccfffff irq 30 at device 6.0 on pci5 >> aacch1: port 0xc800-0xc8ff mem >> 0xfccfe000-0xfccfefff irq 31 at device 6.1 on pci5 >> aac0: mem 0xf0000000-0xf7ffffff irq 30 at device >> 8.1 on pci4 >> aac0: [FAST] >> aac0: Adaptec Raid Controller 2.0.0-1 >> and it works fine. >> Is this a known problem, or is there any other info I can give? >> Happy to try anything anyone might suggest. :) > > The device is asking for 128MB of register space. This is exhausting > the limit on the amount of kernel mapped memory, hence the panic. The > difference between PAE and non-PAE is likely that the non-PAE case > isn't consuming as much kernel address space for the extra page > tables, > so you're squeaking by. > > The 128MB of register space is wrong, but it's something that the aac > firmware is causing. I don't have a 2650, but my 2450 only tries to > claim 4K for registers for the aac device, and the hardware is > basically > identical to the 2650. Maybe try flashing in a newer (or older) > firmware? Knowing what firmware version you have would help. Okay, after spending the better part of the weekend trying to figure out how to PXE boot the floppies that Dell gives you (using their own version of DOS), I've upgraded to the very latest system BIOS, controller firmware and kernel, and it's still requesting 128MB of memory. Nothing seems to have changed really. Any other suggestions? Booting into Linux seems to show that it's also eating 128MB of memory space there, so it's nothing FreeBSD is doing to cause this. Does your controller have the 128MB dimm for caching? I still can't see why they'd expose that to the host, but it's my only theory at the moment. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 12:59:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C70B016A404 for ; Sun, 25 Mar 2007 12:59:45 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.freebsd.org (Postfix) with ESMTP id 45A3513C48C for ; Sun, 25 Mar 2007 12:59:44 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.5.6) with ESMTP id md50000991833.msg for ; Sun, 25 Mar 2007 16:57:48 +0400 Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 16:58:00 +0400 Date: Sun, 25 Mar 2007 16:57:35 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: freebsd-current@freebsd.org In-Reply-To: <20070325133125.X899@free.home.local> Message-ID: <20070325164936.K928@free.home.local> References: <20070325133125.X899@free.home.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Mar 2007 12:58:00.0964 (UTC) FILETIME=[37FF1440:01C76EDD] X-Spam-Processed: mx.gfk.ru, Sun, 25 Mar 2007 16:57:48 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx.gfk.ru, Sun, 25 Mar 2007 16:57:48 +0400 Cc: Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 12:59:45 -0000 > I'm getting repeatable panic with kernel & userland from yesterday evening > when I try to connect to Internet using bluetooth to connect to my phone: > "rfcomm_pppd -a e60 -c -C dun -l mts". The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). It does not panic (in rtsock.c) when I use mpd. Yuriy From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 13:48:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 429A616A402 for ; Sun, 25 Mar 2007 13:48:46 +0000 (UTC) (envelope-from samarunraj@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id BF79C13C458 for ; Sun, 25 Mar 2007 13:48:45 +0000 (UTC) (envelope-from samarunraj@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2379299nfc for ; Sun, 25 Mar 2007 06:48:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=QJkgQpggH0iXnNMIUbF0L2kJuoPVDDSiGV2q38uIVcsH8HNl/SNH1FygrWWOttFmEkM6/zsbrWFjVbrgc7khLl18xrG8P6tykXPDnrkGiSM8F3bJ3ZUKSAaEFztGXjCQyZ4vk/MO82hHuJqAlNUADFpa0c8fRANamGF6lMX5R50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CGdCZNiN4oZLis5ldeBnvpdO+9zdFvHbZUegs3oL1HCpDDrK1n/O58CvXJSnbrm755XPhklyFI1bw9T9WmvoEv3LD0JgYiAh0BwLS2SMzSv3ihAnlZsB7PFu5/DlFovOkRFUfonwwo2270aDXlUBcZ5LZ/KWEe5DITOBxciHVD4= Received: by 10.78.178.5 with SMTP id a5mr2517132huf.1174828959490; Sun, 25 Mar 2007 06:22:39 -0700 (PDT) Received: by 10.78.200.16 with HTTP; Sun, 25 Mar 2007 06:22:39 -0700 (PDT) Message-ID: <4fd6fc030703250622g36ddd5f9r833fb4440958a249@mail.gmail.com> Date: Sun, 25 Mar 2007 18:52:39 +0530 From: "Sam Arun Raj Seeniraj" To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_169866_31505932.1174828959441" Cc: Subject: Resurrecting old FreeBSD size with a rewrite using libelf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 13:48:46 -0000 ------=_Part_169866_31505932.1174828959441 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello there, This patch is to resurrect the old FreeBSD size with a rewrite using libelf. Currently supports elf objects, ar(1) archives and core dumps in elf. Can handle ELF of various architectures using libelf but doesn't support any other object file formats unlike the GNU size. The cmdline parameters as similar to the GNU size minus the long formats. The output will be also be similar save for difference in indentation. This is my first patch to FreeBSD & new to the code style, recent convert from Windows :). Looking for a public review. Tested by doing, - make universe - Comparing output of GNU size versus this against a vast number of elf objects from different architectures. - core dumps from i386,amd64 and sparc64 - These were the only ones I could lay my hands on. (NOTE: Will disable GNU size) Apply against, /usr in -current as "patch -p0 < size.diff" Cheers, -Sam Arun Raj samarunraj@gmail.com ------=_Part_169866_31505932.1174828959441 Content-Type: text/x-diff; name=size.diff; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ezpit4so Content-Disposition: attachment; filename="size.diff" ZGlmZiAtTmF1ciBzcmMvZ251L3Vzci5iaW4vYmludXRpbHMvTWFrZWZpbGUgc3JjMS9nbnUvdXNy LmJpbi9iaW51dGlscy9NYWtlZmlsZQotLS0gc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL01ha2Vm aWxlCUZyaSBKdW4gMjUgMTM6MDQ6NTYgMjAwNAorKysgc3JjMS9nbnUvdXNyLmJpbi9iaW51dGls cy9NYWtlZmlsZQlTdW4gSmFuIDE0IDA1OjQ5OjQwIDIwMDcKQEAgLTIsNiArMiw2IEBACiAKIFNV QkRJUj0JCWxpYmliZXJ0eSBsaWJiZmQgbGlib3Bjb2RlcyBsaWJiaW51dGlscyBcCiAJCWFkZHIy bGluZSBhciBhcyBsZCBubSBvYmpjb3B5IG9iamR1bXAgcmFubGliIHJlYWRlbGYgXAotCQlzaXpl IHN0cmluZ3Mgc3RyaXAgZG9jCisJCXN0cmluZ3Mgc3RyaXAgZG9jCiAKIC5pbmNsdWRlIDxic2Qu c3ViZGlyLm1rPgpkaWZmIC1OYXVyIHNyYy91c3IuYmluL01ha2VmaWxlIHNyYzEvdXNyLmJpbi9N YWtlZmlsZQotLS0gc3JjL3Vzci5iaW4vTWFrZWZpbGUJU3VuIEphbiAxNCAwNTozNzowNyAyMDA3 CisrKyBzcmMxL3Vzci5iaW4vTWFrZWZpbGUJU3VuIEphbiAxNCAwNTo1MDowMSAyMDA3CkBAIC0x NjgsNiArMTY4LDcgQEAKIAlzZWQgXAogCXNoYXIgXAogCXNob3dtb3VudCBcCisJc2l6ZSBcCiAJ JHtfc21idXRpbH0gXAogCXNvY2tzdGF0IFwKIAlzcGxpdCBcCmRpZmYgLU5hdXIgc3JjL3Vzci5i aW4vc2l6ZS9NYWtlZmlsZSBzcmMxL3Vzci5iaW4vc2l6ZS9NYWtlZmlsZQotLS0gc3JjL3Vzci5i aW4vc2l6ZS9NYWtlZmlsZQlUaHUgSmFuICAxIDA1OjMwOjAwIDE5NzAKKysrIHNyYzEvdXNyLmJp bi9zaXplL01ha2VmaWxlCVN1biBKYW4gMTQgMDU6NTA6MTIgMjAwNwpAQCAtMCwwICsxLDggQEAK KyMgJEZyZWVCU0Q6IC9yZXBvbWFuL3IvbmN2cy9zcmMvdXNyLmJpbi9zaXplL01ha2VmaWxlLHYg MS4wIDIwMDcvMDQvMjUgMDE6NTk6MjcgU2FtIEV4cCAkCisKK1BST0c9ICAgc2l6ZQorV0FSTlM/ PSA2CitMREFERD0gIC1sZWxmCisKKy5pbmNsdWRlIDxic2QucHJvZy5taz4KKwpkaWZmIC1OYXVy IHNyYy91c3IuYmluL3NpemUvc2l6ZS4xIHNyYzEvdXNyLmJpbi9zaXplL3NpemUuMQotLS0gc3Jj L3Vzci5iaW4vc2l6ZS9zaXplLjEJVGh1IEphbiAgMSAwNTozMDowMCAxOTcwCisrKyBzcmMxL3Vz ci5iaW4vc2l6ZS9zaXplLjEJU3VuIEphbiAxNCAwNTo1MDoxMCAyMDA3CkBAIC0wLDAgKzEsMTMy IEBACisuXCIgQ29weXJpZ2h0IChjKSAyMDA3IFMuU2FtIEFydW4gUmFqCisuXCIgQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKy5cIgorLlwiIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorLlwiIG1vZGlmaWNhdGlvbiwgYXJlIHBl cm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworLlwiIGFyZSBt ZXQ6CisuXCIgMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo ZSBhYm92ZSBjb3B5cmlnaHQKKy5cIiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisuXCIgMi4gUmVkaXN0cmlidXRpb25zIGlu IGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKy5cIiAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCisuXCIgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHBy b3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKy5cIgorLlwiIFRISVMgU09GVFdBUkUgSVMg UFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKy5c IiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBM SU1JVEVEIFRPLCBUSEUKKy5cIiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ IEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorLlwiIEFSRSBESVNDTEFJTUVE LiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxF CisuXCIgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVN UExBUlksIE9SIENPTlNFUVVFTlRJQUwKKy5cIiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworLlwiIE9SIFNFUlZJ Q0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBU SU9OKQorLlwiIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwg V0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisuXCIgTElBQklMSVRZLCBPUiBUT1JUIChJTkNM VURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorLlwiIE9V VCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9T U0lCSUxJVFkgT0YKKy5cIiBTVUNIIERBTUFHRS4KKy5cIgorLlwiICRGcmVlQlNEOiAvcmVwb21h bi9yL25jdnMvc3JjL3Vzci5iaW4vc2l6ZS9zaXplLjEsdiAxLjAgMjAwNy8wNC8yNSAxNzo1ODoy MiBTYW0gRXhwICQKKy5cIgorLkRkIE1hcmNoIDI1LCAyMDA3CisuRHQgU0laRSAxCisuT3MKKy5T aCBOQU1FCisuTm0gc2l6ZQorLk5kICJkaXNwbGF5IHNlY3Rpb24gc2l6ZXMgYW5kIHRvdGFsIHNp emUgaW4iCisuVG4gRUxGCitmaWxlcy4KKy5TaCBTWU5PUFNJUworLk5tCisuT3AgRmwgQWRob3R4 CisuT3AgQXIKKy5TaCBERVNDUklQVElPTgorVGhlCisuTm0KK3V0aWxpdHkKK2xpc3RzIHRoZSBz aXplIG9mIHZhcmlvdXMgc2VjdGlvbnMgYW5kIHRvdGFsIHNpemUgKGlmIGNob29zZW4pIGZvciBl YWNoIGlucHV0CisuQXIgZmlsZS4KK1RoZQorLk5tCit1dGlsaXR5IGNhbiBvcGVyYXRlIG9uIEVM RiBvYmplY3QsCisuWHIgYXIgMQorYXJjaGl2ZXMsIGFuZCBjb3JlIGR1bXBzLgorLlBwCitJZiBu byBmaWxlIG5hbWUgaXMgc3BlY2lmaWVkIGluIHRoZSBpbnB1dCwgImEub3V0IiBpcyBhc3N1bWVk LgorLlBwCitUaGUgZm9sbG93aW5nIG9wdGlvbnMgYXJlIGF2YWlsYWJsZToKKy5CbCAtdGFnIC13 aWR0aCBpbmRlbnQKKy5JdCBGbCBBCitUaGUgb3V0cHV0IG9mCisuTm0KK3dpbGwgcmVzZW1ibGUg b3V0cHV0IGZyb20gU3lzdGVtIFYKKy5ObSAuCitCeSBkZWZhdWx0LCBvbmUgbGluZSBvZiBvdXRw dXQgaXMgZ2VuZXJhdGVkIGZvciBlYWNoIEVMRiBvYmplY3Qgb3IgZWFjaCBtb2R1bGUKK2luIGFu IGFyY2hpdmUsIGlmIHRoaXMgb3B0aW9uIGlzIG5vdCBjaG9vc2VuLgorLkl0IEZsIHQKK1Nob3dz IGN1bXVsYXRpdmUgdG90YWxzIG9mIHNlY3Rpb24gc2l6ZXMgZnJvbSBhbGwgb2JqZWN0cy4gTm90 IGF2YWlsYWJsZSB3aGVuCitTeXN0ZW0gViBvdXRwdXQgZm9ybWF0CisuRmwgQQoraXMgY2hvb3Nl bi4KKy5JdCBGbCBkIHwgRmwgbyB8IEZsIHgKK1RoZSBzZWN0aW9uIHNpemVzIGNhbiBiZSBkaXNw bGF5ZWQgZWl0aGVyIGluIGRlY2ltYWwsIG9jdGFsIG9yIGhleGFkZWNpbWFsIGJ5CitjaG9vc2lu ZyBvbmUgb2YgdGhlc2Ugb3B0aW9ucy4gVG90YWxzCisuRmwgdAorYXJlIGFsd2F5cyBkaXNwbGF5 ZWQgaW4gdHdvIHJhZGl4ZXM7IGRlY2ltYWwgYW5kIGhleGFkZWNpbWFsIGZvcgorLkZsIGQKK29y CisuRmwgeAorb3V0cHV0LCBvciBvY3RhbCBhbmQgaGV4YWRlY2ltYWwgaWYKKy5GbCBvCitpcyBj aG9vc2VuLgorLkl0IEZsIGgKK1RoaXMgcHJpbnRzIGEgdXNhZ2Ugc3VtbWFyeSBhbmQgZXhpdHMu CisuRWwKKy5TaCBFWElUIFNUQVRVUworLkV4IC1zdGQKKy5TaCBFWEFNUExFUworVGhlIGZvbGxv d2luZyBhcmUgZXhhbXBsZXMgb2YgdHlwaWNhbCB1c2FnZQorb2YgdGhlCisuTm0KK2NvbW1hbmQ6 CisuUHAKKy5EbCAiJCBzaXplIC9iaW4vbHMiCisuRGwgInRleHQgICAgICAgZGF0YSAgICAgICBi c3MgICAgICAgIGRlYyAgICAgICAgaGV4ICAgICAgICBmaWxlbmFtZSIKKy5EbCAiMjA5NzUgICAg ICA1NDAgICAgICAgIDM5MiAgICAgICAgMjE5MDcgICAgICA1NTkzICAgICAgICAvYmluL2xzIgor LlBwCisuRGwgIiQgc2l6ZSAtdHggL2Jpbi9scyAvYmluL2RkIgorLkRsICJ0ZXh0ICAgICAgIGRh dGEgICAgICAgYnNzICAgICAgICBkZWMgICAgICAgIGhleCAgICAgICAgZmlsZW5hbWUiCisuRGwg IjB4NTFlZiAgICAgMHgyMWMgICAgICAweDE4OCAgICAgIDIxOTA3ICAgICAgNTU5MyAgICAgICAg L2Jpbi9scyIKKy5EbCAiMHgzZGY1ICAgICAweDE3MCAgICAgIDB4MjAwICAgICAgMTY3NDEgICAg ICA0MTY1ICAgICAgICAvYmluL2RkIgorLkRsICIweDhmZTQgICAgIDB4MzhjICAgICAgMHgzODgg ICAgICAzODY0OCAgICAgIDk2ZjggICAgICAgKFRPVEFMUykiCisuU2ggU0VFIEFMU08KKy5YciBh ciAxICwKKy5YciBvYmpkdW1wIDEgLAorLlhyIHJlYWRlbGYgMQorLlJzCisuJUEgIkFUJlQgVW5p eCBTeXN0ZW1zIExhYnMiCisuJVQgIlN5c3RlbSBWIEFwcGxpY2F0aW9uIEJpbmFyeSBJbnRlcmZh Y2UiCisuJU8gaHR0cDovL3d3dy5zY28uY29tL2RldmVsb3BlcnMvZ2FiaS8KKy5SZQorLlNoIEhJ U1RPUlkKK1RoZQorLk5tCit1dGlsaXR5IGZpcnN0IGFwcGVhcmVkIGluCisuQXQgdjYuCitUaGUg bGFzdCBGcmVlQlNEIAorLk5tCit3YXMgZGlzY29udGludWVkIGluIAorLkZ4IHY1ICwKK3doZW4g aTM4Ni1vbmx5IGEub3V0IGZvcm1hdCB3YXMgZHJvcHBlZCBpbiBmYXZvciBvZiBFTEYuCisuU2gg QVVUSE9SUworLkFuIC1ub3NwbGl0CitUaGUKKy5ObQordXRpbGl0eSB3YXMgcmUtd3JpdHRlbiBi eQorLkFuIFMuU2FtIEFydW4gUmFqIEFxIHNhbWFydW5yYWpAZ21haWwuY29tCitUaGlzIG1hbnVh bCBwYWdlIHdhcyB3cml0dGVuIGJ5CisuQW4gUy5TYW0gQXJ1biBSYWogQXEgc2FtYXJ1bnJhakBn bWFpbC5jb20KKy5TaCBMSU1JVEFUSU9OUworVW5saWtlIHRoZSBHTlUKKy5ObQordGhpcyBkb2Vz bid0IHN1cHBvcnQgbXVsdGlwbGUgb2JqZWN0IGZpbGUgZm9ybWF0cywgb25seSBFTEYgdXNpbmcg dGhlCisuWHIgZWxmIDMKK2FuZAorLlhyIGdlbGYgMworQVBJJ3MuCmRpZmYgLU5hdXIgc3JjL3Vz ci5iaW4vc2l6ZS9zaXplLmMgc3JjMS91c3IuYmluL3NpemUvc2l6ZS5jCi0tLSBzcmMvdXNyLmJp bi9zaXplL3NpemUuYwlUaHUgSmFuICAxIDA1OjMwOjAwIDE5NzAKKysrIHNyYzEvdXNyLmJpbi9z aXplL3NpemUuYwlTdW4gSmFuIDE0IDA2OjAxOjE4IDIwMDcKQEAgLTAsMCArMSw4MTYgQEAKKy8q LQorICogQ29weXJpZ2h0IChjKSAyMDA3IFMuU2FtIEFydW4gUmFqCisgKiBBbGwgcmlnaHRzIHJl c2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5h cnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVk IHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICog MS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBj b3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisg KiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhF IEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9S IElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQor ICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hB TEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVD VCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVO VElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVN RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFU QSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVT RUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBT VFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RI RVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09G VFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFN QUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRDog c3JjL3Vzci5iaW4vc2l6ZS9zaXplLmMsdiAxLjAgMjAwNy8wNC8yNCAxNzo1ODoyMiBTYW0gRXhw ICQiKTsKKworI2luY2x1ZGUgPGVyci5oPgorI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8 Z2V0b3B0Lmg+CisjaW5jbHVkZSA8c3RkaW50Lmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNs dWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDxzeXNleGl0cy5o PgorI2luY2x1ZGUgPHVuaXN0ZC5oPgorCisjaW5jbHVkZSA8bGliZWxmLmg+CisjaW5jbHVkZSA8 Z2VsZi5oPgorCisjZGVmaW5lIEJVRl9TSVpFCTQwCisjZGVmaW5lIEVMRl9BTElHTih2YWwseCkg XAorCSgoKHZhbCkgKyAoeCkgLSAxKSA+ICh2YWwpID8gKCgodmFsKSsoeCktMSkgJiB+KCh4KS0x KSkgOiB+MCkKKworI2lmbmRlZiBOVF9BVVhWCisjZGVmaW5lIE5UX0FVWFYgNgorI2VuZGlmCisj aWZuZGVmIE5UX0xXUFNUQVRVUworI2RlZmluZSBOVF9MV1BTVEFUVVMgMTYKKyNlbmRpZgorI2lm bmRlZiBOVF9QUkZQUkVHCisjZGVmaW5lIE5UX1BSRlBSRUcgMgorI2VuZGlmCisjaWZuZGVmIE5U X1BTVEFUVVMKKyNkZWZpbmUgTlRfUFNUQVRVUyAxMAorI2VuZGlmCisjaWZuZGVmIE5UX1BTSU5G TworI2RlZmluZSBOVF9QU0lORk8gMTMKKyNlbmRpZgorI2lmbmRlZiBOVF9QUlhGUFJFRworI2Rl ZmluZSBOVF9QUlhGUFJFRyAweDQ2ZTYyYjdmCisjZW5kaWYKKyNpZm5kZWYgUFRfR05VX0VIX0ZS QU1FCisjZGVmaW5lIFBUX0dOVV9FSF9GUkFNRQkoUFRfTE9PUyArIDB4NDc0ZTU1MCkKKyNlbmRp ZgorI2lmbmRlZiBQVF9HTlVfU1RBQ0sKKyNkZWZpbmUgUFRfR05VX1NUQUNLIChQVF9MT09TICsg MHg0NzRlNTUxKQorI2VuZGlmCisKK2VudW0gb3V0cHV0X3N0eWxlIHsKKwlTVFlMRV9CRVJLRUxF WSwKKwlTVFlMRV9TWVNWCit9OworCitlbnVtIHJhZGl4X3N0eWxlIHsKKwlSQURJWF9PQ1RBTCwK KwlSQURJWF9ERUNJTUFMLAorCVJBRElYX0hFWCAKK307CisKK3NpemVfdCBzZWNfbmFtZV9sZW47 Cit1aW50MzJfdCBic3Nfc2l6ZV90b3RhbCwgZGF0YV9zaXplX3RvdGFsLCB0ZXh0X3NpemVfdG90 YWw7Cit1aW50MzJfdCBic3Nfc2l6ZSwgZGF0YV9zaXplLCB0ZXh0X3NpemUsIHRvdGFsX3NpemU7 CitpbnQgc2hvd190b3RhbHM7CitlbnVtIHJhZGl4X3N0eWxlIHJhZGl4OworZW51bSBvdXRwdXRf c3R5bGUgc3R5bGU7Citjb25zdCBjaGFyIGRlZmF1bHRfbmFtZVtdID0gImEub3V0IjsKKworaW50 CWhhbmRsZV9lbGYoY2hhciBjb25zdCAqKTsKK2ludAloYW5kbGVfY29yZShjaGFyIGNvbnN0ICos IEVsZiAqZWxmLCBHRWxmX0VoZHIgKik7Cit2b2lkCWhhbmRsZV9jb3JlX25vdGUoRWxmICosIEdF bGZfRWhkciAqLCBHRWxmX1BoZHIgKiwgcGlkX3QpOwordm9pZAlnZXRfY29yZV9jbWRsaW5lX3Bp ZChFbGYgKiwgR0VsZl9FaGRyICosIEdFbGZfUGhkciAqLAorCSAgICBjaGFyICoqLCBwaWRfdCAq KTsKK3ZvaWQJaGFuZGxlX3BoZHIoRWxmICosIEdFbGZfRWhkciAqLCBHRWxmX1BoZHIgKiwgdWlu dDMyX3QsCisgICAgCSAgICBjb25zdCBjaGFyICopOwordm9pZAl1c2FnZSh2b2lkKTsKK3ZvaWQJ cHJpbnRfbnVtYmVyKGludCwgdWludDMyX3QsIGVudW0gcmFkaXhfc3R5bGUsIGNoYXIpOwordm9p ZAliZXJrZWxleV9oZWFkZXIodm9pZCk7Cit2b2lkCWJlcmtlbGV5X2Zvb3Rlcihjb25zdCBjaGFy ICosIGNvbnN0IGNoYXIgKiwgY29uc3QgY2hhciAqKTsKK3ZvaWQJYmVya2VsZXlfY2FsYyhHRWxm X1NoZHIgKik7Cit2b2lkCWJlcmtlbGV5X3RvdGFscyh2b2lkKTsKK3ZvaWQJc3lzdl9oZWFkZXIo Y29uc3QgY2hhciAqLCBFbGZfQXJoZHIgKik7Cit2b2lkCXN5c3ZfZm9vdGVyKHZvaWQpOwordm9p ZAlzeXN2X2NhbGMoRWxmICosIEdFbGZfRWhkciAqLCBHRWxmX1NoZHIgKiwgaW50KTsKKworLyoK KyAqIHNpemUgdXRpbGl0eSB1c2luZyBlbGYoMykgYW5kIGdlbGYoMykgQVBJIHRvIGxpc3Qgc2Vj dGlvbiBzaXplcyBhbmQKKyAqIHRvdGFsIGluIGVsZiBmaWxlcy4gU3VwcG9ydHMgb25seSBlbGYg ZmlsZXMgKGNvcmUgZHVtcHMgaW4gZWxmCisgKiBpbmNsdWRlZCkgdGhhdCBjYW4gYmUgb3BlbmVk IGJ5IGxpYmVsZiwgb3RoZXIgZm9ybWF0cyBhcmUgbm90IHN1cHBvcnRlZC4KKyAqLworaW50Citt YWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCit7CisJaW50IGNoLCBleGl0X2NvZGU7CisKKwlz ZWNfbmFtZV9sZW4gPSAxOTsKKwlleGl0X2NvZGUgPSBFWF9PSzsKKwlzdHlsZSA9IFNUWUxFX0JF UktFTEVZOworCXJhZGl4ID0gUkFESVhfREVDSU1BTDsKKwlpZiAoZWxmX3ZlcnNpb24oRVZfQ1VS UkVOVCkgPT0gRVZfTk9ORSkKKwkJZXJyeChFWF9TT0ZUV0FSRSwgIkVMRiBsaWJyYXJ5IGluaXRp YWxpemF0aW9uIGZhaWxlZDogJXMiLAorCQkgICAgZWxmX2Vycm1zZygtMSkpOworCisJd2hpbGUg KChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiQWRob3R4IikpICE9IC0xKQorCQlzd2l0Y2goKGNo YXIpY2gpIHsKKwkJY2FzZSAnQSc6CisJCQlzdHlsZSA9IFNUWUxFX1NZU1Y7CisJCQlicmVhazsK KwkJY2FzZSAnZCc6CisJCQlyYWRpeCA9IFJBRElYX0RFQ0lNQUw7CisJCQlicmVhazsKKwkJY2Fz ZSAndCc6CisJCQlzaG93X3RvdGFscyA9IDE7CisJCQlicmVhazsKKwkJY2FzZSAnbyc6CisJCQly YWRpeCA9IFJBRElYX09DVEFMOworCQkJYnJlYWs7CisJCWNhc2UgJ3gnOgorCQkJcmFkaXggPSBS QURJWF9IRVg7CisJCQlicmVhazsKKwkJY2FzZSAnaCc6CisJCWNhc2UgJz8nOgorCQlkZWZhdWx0 OgorCQkJdXNhZ2UoKTsKKwkJCS8qIE5PVFJFQUNIRUQgKi8KKwkJfQorCWFyZ2MgLT0gb3B0aW5k OworCWFyZ3YgKz0gb3B0aW5kOworCisJaWYgKCEqYXJndikgeworCQlleGl0X2NvZGUgPSBoYW5k bGVfZWxmKGRlZmF1bHRfbmFtZSk7CisJCWlmIChleGl0X2NvZGUgPT0gRVhfU09GVFdBUkUgfHwg ZXhpdF9jb2RlID09IEVYX0RBVEFFUlIpIAorCQkJd2FybngoIiVzOiBGaWxlIGZvcm1hdCBub3Qg cmVjb2duaXplZCIsIGRlZmF1bHRfbmFtZSk7CisJCWlmIChleGl0X2NvZGUgPT0gRVhfTk9JTlBV VCkKKwkJCXdhcm54KCInJXMnOiBObyBzdWNoIGZpbGUiLCBkZWZhdWx0X25hbWUpOworCX0KKwll bHNlIHdoaWxlICgqYXJndikgeworCQlleGl0X2NvZGUgPSBoYW5kbGVfZWxmKCphcmd2KTsKKwkJ aWYgKGV4aXRfY29kZSA9PSBFWF9TT0ZUV0FSRSB8fCBleGl0X2NvZGUgPT0gRVhfREFUQUVSUikK KwkJCXdhcm54KCIlczogRmlsZSBmb3JtYXQgbm90IHJlY29nbml6ZWQiLCAqYXJndik7CisJCWlm IChleGl0X2NvZGUgPT0gRVhfTk9JTlBVVCkKKwkJCXdhcm54KCInJXMnOiBObyBzdWNoIGZpbGUi LCAqYXJndik7CisJCWFyZ3YrKzsKKwl9CisJaWYgKHN0eWxlID09IFNUWUxFX0JFUktFTEVZKQor CQliZXJrZWxleV90b3RhbHMoKTsKKyAgICAgICAgcmV0dXJuIChleGl0X2NvZGUpOworfQorCitz dGF0aWMgRWxmX0RhdGEgKgoreGxhdGV0b20oRWxmICplbGYsIEdFbGZfRWhkciAqZWxmaGRyLCB2 b2lkICpfc3JjLCB2b2lkICpfZHN0LAorICAgIEVsZl9UeXBlIHR5cGUsIHNpemVfdCBzaXplKQor eworCUVsZl9EYXRhIHNyYywgZHN0OworCisJc3JjLmRfYnVmID0gX3NyYzsKKwlzcmMuZF90eXBl ID0gdHlwZTsKKwlzcmMuZF92ZXJzaW9uID0gZWxmaGRyLT5lX3ZlcnNpb247CisJc3JjLmRfc2l6 ZSA9IHNpemU7CisJZHN0LmRfYnVmID0gX2RzdDsKKwlkc3QuZF92ZXJzaW9uID0gZWxmaGRyLT5l X3ZlcnNpb247CisJZHN0LmRfc2l6ZSA9IHNpemU7CisJcmV0dXJuIGdlbGZfeGxhdGV0b20oZWxm LCAmZHN0LCAmc3JjLCBlbGZoZHItPmVfaWRlbnRbRUlfREFUQV0pOworfQorCisjZGVmaW5lIE5P VEVfT0ZGU0VUXzMyKG5oZHIsIG5hbWVzeiwgb2Zmc2V0KSAJCQlcCisJKChjaGFyICopbmhkciAr IHNpemVvZihFbGYzMl9OaGRyKSArCQkJXAorCSAgICBFTEZfQUxJR04oKGludDMyX3QpbmFtZXN6 LCA0KSArIG9mZnNldCkKKworI2RlZmluZSBOT1RFX09GRlNFVF82NChuaGRyLCBuYW1lc3osIG9m ZnNldCkgCQkJXAorCSgoY2hhciAqKW5oZHIgKyBzaXplb2YoRWxmMzJfTmhkcikgKwkJCVwKKwkg ICAgRUxGX0FMSUdOKChpbnQzMl90KW5hbWVzeiwgOCkgKyBvZmZzZXQpCisKKyNkZWZpbmUgUElE MzIobmhkciwgbmFtZXN6LCBvZmZzZXQpIAkJCQlcCisJKHBpZF90KSooKGludCAqKSgodWludHB0 cl90KU5PVEVfT0ZGU0VUXzMyKG5oZHIsCVwKKwkgICAgbmFtZXN6LCBvZmZzZXQpKSk7CisKKyNk ZWZpbmUgUElENjQobmhkciwgbmFtZXN6LCBvZmZzZXQpIAkJCQlcCisJKHBpZF90KSooKGludCAq KSgodWludHB0cl90KU5PVEVfT0ZGU0VUXzY0KG5oZHIsCVwKKwkgICAgbmFtZXN6LCBvZmZzZXQp KSk7CisKKyNkZWZpbmUgTkVYVF9OT1RFKGVsZmhkciwgZGVzY3N6LCBuYW1lc3osIG9mZnNldCkg ZG8gewkJXAorCWlmIChlbGZoZHItPmVfaWRlbnRbRUlfQ0xBU1NdID09IEVMRkNMQVNTMzIpIHsg CQlcCisJCW9mZnNldCArPSBFTEZfQUxJR04oKGludDMyX3QpZGVzY3N6LCA0KSArIAlcCisJCSAg ICBzaXplb2YoRWxmMzJfTmhkcikgKyAJCQlcCisJCSAgICAgICAgRUxGX0FMSUdOKChpbnQzMl90 KW5hbWVzeiwgNCk7IAkJXAorCX0gZWxzZSB7CQkJCQkJXAorCQlvZmZzZXQgKz0gRUxGX0FMSUdO KChpbnQzMl90KWRlc2NzeiwgOCkgKyAJXAorCQkgICAgc2l6ZW9mKEVsZjMyX05oZHIpICsgCQkJ XAorCQkgICAgICAgIEVMRl9BTElHTigoaW50MzJfdCluYW1lc3osIDgpOyAJCVwKKwl9CQkJCQkJ CVwKK30gd2hpbGUgKDApCisKKy8qCisgKiBSZXRyaWV2ZXMgdGhlIGNvbW1hbmQgbGluZSBhbmQg cGlkIGZyb20gdGhlIGNvcmUgZmlsZS4KKyAqLwordm9pZAorZ2V0X2NvcmVfY21kbGluZV9waWQo RWxmICplbGYsIEdFbGZfRWhkciAqZWxmaGRyLCBHRWxmX1BoZHIgKnBoZHIsCisgICAgY2hhciAq KmNtZF9saW5lLCBwaWRfdCAqcGlkKQoreworCUdFbGZfT2ZmIG9mZnNldDsJCisJc2l6ZV90IG1h eF9zaXplOworCXBpZF90IHA7CisJRWxmMzJfTmhkciAqbmhkciwgbmhkcl9sOworCXVpbnRwdHJf dCBhZGRyOwkKKwlpbnQgdmVyOwkKKwljaGFyICpkYXRhLCAqbmFtZTsKKwl1aW50OF90IGNsYXNz OwkKKworCWlmIChlbGYgPT0gTlVMTCB8fCBlbGZoZHIgPT0gTlVMTCB8fCBwaGRyID09IE5VTEwg fHwKKwkgICAgcGlkID09IE5VTEwgfHwgY21kX2xpbmUgPT0gTlVMTCkKKwkJcmV0dXJuOworCQor CWRhdGEgPSBlbGZfcmF3ZmlsZShlbGYsICZtYXhfc2l6ZSk7CisJb2Zmc2V0ID0gcGhkci0+cF9v ZmZzZXQ7CisJd2hpbGUgKGRhdGEgIT0gTlVMTCAmJiBvZmZzZXQgPCBwaGRyLT5wX29mZnNldCAr IHBoZHItPnBfZmlsZXN6KSB7CisJCW5oZHIgPSAoRWxmMzJfTmhkciAqKSh1aW50cHRyX3QpKChj aGFyKilkYXRhICsgb2Zmc2V0KTsKKwkJbWVtc2V0KCZuaGRyX2wsIDAsIHNpemVvZihFbGYzMl9O aGRyKSk7CisJCWlmICgheGxhdGV0b20oZWxmLCBlbGZoZHIsICZuaGRyLT5uX3R5cGUsICZuaGRy X2wubl90eXBlLAorCQkJRUxGX1RfV09SRCwgc2l6ZW9mKEVsZjMyX1dvcmQpKSB8fAorCQkgICAg IXhsYXRldG9tKGVsZiwgZWxmaGRyLCAmbmhkci0+bl9kZXNjc3osICZuaGRyX2wubl9kZXNjc3os CisJCQlFTEZfVF9XT1JELCBzaXplb2YoRWxmMzJfV29yZCkpIHx8CisJCSAgICAheGxhdGV0b20o ZWxmLCBlbGZoZHIsICZuaGRyLT5uX25hbWVzeiwgJm5oZHJfbC5uX25hbWVzeiwKKwkJCUVMRl9U X1dPUkQsIHNpemVvZihFbGYzMl9Xb3JkKSkpCisJCQlicmVhazsKKworCQluYW1lID0gKGNoYXIg KikoKGNoYXIgKiluaGRyICsgc2l6ZW9mKEVsZjMyX05oZHIpKTsKKwkJY2xhc3MgPSBlbGZoZHIt PmVfaWRlbnRbRUlfQ0xBU1NdOworCQlzd2l0Y2ggKG5oZHJfbC5uX3R5cGUpIHsKKwkJY2FzZSBO VF9QUlNUQVRVUzogeworCQkJcCA9IDA7CisJCQlpZiAoZWxmaGRyLT5lX2lkZW50W0VJX09TQUJJ XSA9PSBFTEZPU0FCSV9GUkVFQlNEICYmCisJCQkgICAgbmhkcl9sLm5fbmFtZXN6ID09IDB4OCAm JgorCQkJICAgICFzdHJjbXAobmFtZSwiRnJlZUJTRCIpKSB7CisJCQkJaWYgKGNsYXNzID09IEVM RkNMQVNTMzIpIHsKKwkJCQkJYWRkciA9ICh1aW50cHRyX3QpTk9URV9PRkZTRVRfMzIobmhkciwK KwkJCQkJICAgIG5oZHJfbC5uX25hbWVzeiwwKTsKKwkJCQkJdmVyID0gKigoaW50ICopYWRkcik7 CisJCQkJfSBlbHNlIHsKKwkJCQkJYWRkciA9ICh1aW50cHRyX3QpTk9URV9PRkZTRVRfNjQobmhk ciwKKwkJCQkJICAgIG5oZHJfbC5uX25hbWVzeiwwKTsKKwkJCQkJdmVyID0gKigoaW50ICopYWRk cik7CisJCQkJfQorCQkJCWlmICgheGxhdGV0b20oZWxmLCBlbGZoZHIsICZ2ZXIsCisJCQkJICAg ICZ2ZXIsIEVMRl9UX1dPUkQsIHNpemVvZihpbnQpKSkgeworCQkJCQlORVhUX05PVEUoZWxmaGRy LCBuaGRyX2wubl9kZXNjc3osCisJCQkJCSAgICBuaGRyX2wubl9uYW1lc3osIG9mZnNldCk7CisJ CQkJCWNvbnRpbnVlOworCQkJCX0JCisJCQkJaWYgKHZlciA9PSAxICYmIGNsYXNzID09IEVMRkNM QVNTMzIpCisJCQkJCXAgPSBQSUQzMihuaGRyLCBuaGRyX2wubl9uYW1lc3osIDI0KTsKKwkJCQlp ZiAodmVyID09IDEgJiYgY2xhc3MgPT0gRUxGQ0xBU1M2NCkKKwkJCQkJcCA9IFBJRDY0KG5oZHIs IG5oZHJfbC5uX25hbWVzeiwgNDApOworCQkJfQorCQkJaWYgKHhsYXRldG9tKGVsZiwgZWxmaGRy LCAmcCwgJnAsIEVMRl9UX1dPUkQsCisJCQkgICAgc2l6ZW9mKHBpZF90KSkpCisJCQkJKnBpZCA9 IHA7CisJCX0KKwkJYnJlYWs7CisJCWNhc2UgTlRfUFNJTkZPOgorCQljYXNlIE5UX1BSUFNJTkZP OiB7CisJCQkvKiBGcmVlQlNEIDY0LWJpdCAqLworCQkJaWYgKG5oZHJfbC5uX2Rlc2NzeiA9PSAw eDc4ICYmCisJCQkJIXN0cmNtcChuYW1lLCJGcmVlQlNEIikpIHsKKwkJCQkqY21kX2xpbmUgPSBz dHJkdXAoTk9URV9PRkZTRVRfNjQobmhkciwKKwkJCQkgICAgbmhkcl9sLm5fbmFtZXN6LCAzMykp OworCQkJLyogRnJlZUJTRCAzMi1iaXQgKi8KKwkJCX0gZWxzZSBpZiAobmhkcl9sLm5fZGVzY3N6 ID09IDB4NmMgJiYKKwkJCQkhc3RyY21wKG5hbWUsIkZyZWVCU0QiKSkgeworCQkJCSpjbWRfbGlu ZSA9IHN0cmR1cChOT1RFX09GRlNFVF8zMihuaGRyLAorCQkJCSAgICBuaGRyX2wubl9uYW1lc3os IDI1KSk7CisJCQl9CisJCQkvKiBTdHJpcCBhbnkgdHJhaWxpbmcgc3BhY2VzICovCisJCQlpZiAo KmNtZF9saW5lICE9IE5VTEwpIHsKKwkJCQljaGFyICpzOworCisJCQkJcyA9ICpjbWRfbGluZSAr IHN0cmxlbigqY21kX2xpbmUpOworCQkJCXdoaWxlIChzID4gKmNtZF9saW5lKSB7CisJCQkJCWlm ICgqKHMtMSkgIT0gMHgyMCkgYnJlYWs7CisJCQkJCXMtLTsKKwkJCQl9CisJCQkJKnMgPSAwOwor CQkJfQorCQkJYnJlYWs7CisJCX0KKwkJZGVmYXVsdDoKKwkJCWJyZWFrOworCQl9CisJCU5FWFRf Tk9URShlbGZoZHIsIG5oZHJfbC5uX2Rlc2Nzeiwgbmhkcl9sLm5fbmFtZXN6LCBvZmZzZXQpOwor CX0KK30KKworLyoKKyAqIFBhcnNlIGluZGl2aWR1YWwgbm90ZSBlbnRyaWVzIGluc2lkZSBhIFBU X05PVEUgc2VnbWVudC4KKyAqLwordm9pZAoraGFuZGxlX2NvcmVfbm90ZShFbGYgKmVsZiwgR0Vs Zl9FaGRyICplbGZoZHIsIEdFbGZfUGhkciAqcGhkciwgcGlkX3QgcGlkKQoreworCXNpemVfdCBt YXhfc2l6ZTsKKwl1aW50NjRfdCByYXdfc2l6ZTsKKwlHRWxmX09mZiBvZmZzZXQ7CisJRWxmMzJf TmhkciAqbmhkciwgbmhkcl9sOworCWNoYXIgYnVmW0JVRl9TSVpFXSwgKmRhdGEsICpuYW1lOwor CisJaWYgKGVsZiA9PSBOVUxMIHx8IGVsZmhkciA9PSBOVUxMIHx8IHBoZHIgPT0gTlVMTCkKKwkJ cmV0dXJuOworCQorCWRhdGEgPSBlbGZfcmF3ZmlsZShlbGYsICZtYXhfc2l6ZSk7CisJb2Zmc2V0 ID0gcGhkci0+cF9vZmZzZXQ7CisJcmF3X3NpemUgPSAwOworCXdoaWxlIChkYXRhICE9IE5VTEwg JiYgb2Zmc2V0IDwgcGhkci0+cF9vZmZzZXQgKyBwaGRyLT5wX2ZpbGVzeikgeworCQluaGRyID0g KEVsZjMyX05oZHIgKikodWludHB0cl90KSgoY2hhciopZGF0YSArIG9mZnNldCk7CisJCW1lbXNl dCgmbmhkcl9sLCAwLCBzaXplb2YoRWxmMzJfTmhkcikpOworCQlpZiAoIXhsYXRldG9tKGVsZiwg ZWxmaGRyLCAmbmhkci0+bl90eXBlLCAmbmhkcl9sLm5fdHlwZSwKKwkJCUVMRl9UX1dPUkQsIHNp emVvZihFbGYzMl9Xb3JkKSkgfHwKKwkJICAgICF4bGF0ZXRvbShlbGYsZWxmaGRyLCAmbmhkci0+ bl9kZXNjc3osICZuaGRyX2wubl9kZXNjc3osCisJCQlFTEZfVF9XT1JELCBzaXplb2YoRWxmMzJf V29yZCkpIHx8CisJCSAgICAheGxhdGV0b20oZWxmLGVsZmhkciwgJm5oZHItPm5fbmFtZXN6LCAm bmhkcl9sLm5fbmFtZXN6LAorCQkJRUxGX1RfV09SRCwgc2l6ZW9mKEVsZjMyX1dvcmQpKSkKKwkJ CWJyZWFrOworCisJCW5hbWUgPSAoY2hhciAqKSgoY2hhciAqKW5oZHIgKyBzaXplb2YoRWxmMzJf TmhkcikpOworCQlzd2l0Y2ggKG5oZHJfbC5uX3R5cGUpIHsKKwkJY2FzZSBOVF9QUlNUQVRVUzog eworCQkJaWYgKGVsZmhkci0+ZV9pZGVudFtFSV9PU0FCSV0gPT0gRUxGT1NBQklfRlJFRUJTRCAm JgorCQkJICAgIG5oZHJfbC5uX25hbWVzeiA9PSAweDggJiYKKwkJCSAgICAhc3RyY21wKG5hbWUs IkZyZWVCU0QiKSkgeworCQkJCWlmIChlbGZoZHItPmVfaWRlbnRbRUlfQ0xBU1NdID09IEVMRkNM QVNTMzIpIHsKKwkJCQkJcmF3X3NpemUgPSAodWludDY0X3QpKigodWludDMyX3QgKikKKwkJCQkJ ICAgICh1aW50cHRyX3QpKG5hbWUgKyAKKwkJCQkJCUVMRl9BTElHTigoaW50MzJfdCkKKwkJCQkJ CW5oZHJfbC5uX25hbWVzeiwgNCkgKyA4KSk7CisJCQkJCXhsYXRldG9tKGVsZiwgZWxmaGRyLCAm cmF3X3NpemUsCisJCQkJCSAgICAmcmF3X3NpemUsIEVMRl9UX1dPUkQsCisJCQkJCSAgICBzaXpl b2YodWludDY0X3QpKTsKKwkJCQl9IGVsc2UgeworCQkJCQlyYXdfc2l6ZSA9ICooKHVpbnQ2NF90 ICopKHVpbnRwdHJfdCkKKwkJCQkJICAgIChuYW1lICsgRUxGX0FMSUdOKChpbnQzMl90KQorCQkJ CQkJbmhkcl9sLm5fbmFtZXN6LCA4KSArIDE2KSk7CisJCQkJCXhsYXRldG9tKGVsZiwgZWxmaGRy LCAmcmF3X3NpemUsCisJCQkJCSAgICAmcmF3X3NpemUsIEVMRl9UX1hXT1JELAorCQkJCQkgICAg c2l6ZW9mKHVpbnQ2NF90KSk7CisJCQkJfQorCQkJfQorCQkJaWYgKHJhd19zaXplICE9IDAgJiYg c3R5bGUgPT0gU1RZTEVfU1lTVikgeworCQkJCSh2b2lkKSBzbnByaW50ZihidWYsIEJVRl9TSVpF LCAiJXMvJWQiLAorCQkJCSAgICAiLnJlZyIsIHBpZCk7CisJCQkJKHZvaWQpIHByaW50ZigiJS0x OHMgIiwgYnVmKTsKKwkJCQlwcmludF9udW1iZXIoMTAsICh1aW50MzJfdClyYXdfc2l6ZSwKKwkJ CQkgICAgcmFkaXgsICcgJyk7CisJCQkJcHJpbnRfbnVtYmVyKDEwLCAodWludDMyX3QpMCwKKwkJ CQkgICAgcmFkaXgsICdcbicpOworCQkJCSh2b2lkKSBwcmludGYoIiUtMThzICIsICIucmVnIik7 CisJCQkJcHJpbnRfbnVtYmVyKDEwLCAodWludDMyX3QpcmF3X3NpemUsCisJCQkJICAgIHJhZGl4 LCAnICcpOworCQkJCXByaW50X251bWJlcigxMCwgKHVpbnQzMl90KTAsIHJhZGl4LCAnXG4nKTsK KwkJCQl0ZXh0X3NpemVfdG90YWwgKz0gcmF3X3NpemUgKiAyOworCQkJfQorCQl9CQorCQlicmVh azsKKwkJY2FzZSBOVF9QUkZQUkVHOiAvKiBzYW1lIGFzIE5UX0ZQUkVHU0VUICovCisJCQlpZiAo c3R5bGUgPT0gU1RZTEVfU1lTVikgeworCQkJCSh2b2lkKSBzbnByaW50ZihidWYsIEJVRl9TSVpF LAorCQkJCSAgICAiJXMvJWQiLCAiLnJlZzIiLCBwaWQpOworCQkJCSh2b2lkKSBwcmludGYoIiUt MThzICIsIGJ1Zik7CisJCQkJcHJpbnRfbnVtYmVyKDEwLCAodWludDMyX3Qpbmhkcl9sLm5fZGVz Y3N6LAorCQkJCSAgICByYWRpeCwgJyAnKTsKKwkJCQlwcmludF9udW1iZXIoMTAsICh1aW50MzJf dCkwLCByYWRpeCwgJ1xuJyk7CisJCQkJKHZvaWQpIHByaW50ZigiJS0xOHMgIiwgIi5yZWcyIik7 CisJCQkJcHJpbnRfbnVtYmVyKDEwLCAodWludDMyX3Qpbmhkcl9sLm5fZGVzY3N6LAorCQkJCSAg ICByYWRpeCwgJyAnKTsKKwkJCQlwcmludF9udW1iZXIoMTAsICh1aW50MzJfdCkwLCByYWRpeCwg J1xuJyk7CisJCQkJdGV4dF9zaXplX3RvdGFsICs9IG5oZHJfbC5uX2Rlc2NzeiAqIDI7CisJCQl9 CisJCQlicmVhazsKKwkJY2FzZSBOVF9BVVhWOgorCQkJaWYgKHN0eWxlID09IFNUWUxFX1NZU1Yp IHsKKwkJCQkodm9pZCkgcHJpbnRmKCIlLTE4cyAiLCAiLmF1eHYiKTsKKwkJCQlwcmludF9udW1i ZXIoMTAsICh1aW50MzJfdCluaGRyX2wubl9kZXNjc3osCisJCQkJICAgIHJhZGl4LCAnICcpOwor CQkJCXByaW50X251bWJlcigxMCwgKHVpbnQzMl90KTAsIHJhZGl4LCAnXG4nKTsKKwkJCQl0ZXh0 X3NpemVfdG90YWwgKz0gbmhkcl9sLm5fZGVzY3N6OworCQkJfQorCQkJYnJlYWs7CisJCWNhc2Ug TlRfUFJYRlBSRUc6CisJCQlpZiAoc3R5bGUgPT0gU1RZTEVfU1lTVikgeworCQkJCSh2b2lkKSBz bnByaW50ZihidWYsIEJVRl9TSVpFLAorCQkJCSAgICAiJXMvJWQiLCAiLnJlZy14ZnAiLCBwaWQp OworCQkJCSh2b2lkKSBwcmludGYoIiUtMThzICIsIGJ1Zik7CisJCQkJcHJpbnRfbnVtYmVyKDEw LCAodWludDMyX3Qpbmhkcl9sLm5fZGVzY3N6LAorCQkJCSAgICByYWRpeCwgJyAnKTsKKwkJCQlw cmludF9udW1iZXIoMTAsICh1aW50MzJfdCkwLCByYWRpeCwgJ1xuJyk7CisJCQkJKHZvaWQpIHBy aW50ZigiJS0xOHMgIiwgIi5yZWcteGZwIik7CisJCQkJcHJpbnRfbnVtYmVyKDEwLCAodWludDMy X3Qpbmhkcl9sLm5fZGVzY3N6LAorCQkJCSAgICByYWRpeCwgJyAnKTsKKwkJCQlwcmludF9udW1i ZXIoMTAsICh1aW50MzJfdCkwLCByYWRpeCwgJ1xuJyk7CisJCQkJdGV4dF9zaXplX3RvdGFsICs9 IG5oZHJfbC5uX2Rlc2NzeiAqIDI7CisJCQl9CisJCQlicmVhazsKKwkJY2FzZSBOVF9QU1RBVFVT OgorCQljYXNlIE5UX0xXUFNUQVRVUzoKKwkJZGVmYXVsdDoKKwkJCWJyZWFrOworCQl9CisJCU5F WFRfTk9URShlbGZoZHIsIG5oZHJfbC5uX2Rlc2Nzeiwgbmhkcl9sLm5fbmFtZXN6LCBvZmZzZXQp OworCX0KK30KKworLyoKKyAqIEhhbmRsZXMgcHJvZ3JhbSBoZWFkZXJzIGV4Y2VwdCBmb3IgUFRf Tk9URSwgd2hlbiBzeXN2IG91dHB1dCBzdGx5ZSBpcyAKKyAqIGNob29zZW4sIHByaW50cyBvdXQg dGhlIHNlZ21lbnQgbmFtZSBhbmQgbGVuZ3RoLiBGb3IgYmVya2VseSBvdXRwdXQgCisgKiBzdHls ZSBvbmx5IFBUX0xPQUQgc2VnbWVudHMgYXJlIGhhbmRsZWQsIGFuZCB0ZXh0LAorICogZGF0YSwg YnNzIHNpemUgaXMgY2FsY3VsYXRlZCBmb3IgdGhlbS4KKyAqLwordm9pZAoraGFuZGxlX3BoZHIo RWxmICplbGYsIEdFbGZfRWhkciAqZWxmaGRyLCBHRWxmX1BoZHIgKnBoZHIsCisgICAgdWludDMy X3QgaWR4LCBjb25zdCBjaGFyICpuYW1lKQorewkKKwl1aW50MzJfdCBhZGRyLCBzaXplOworCWlu dCBzcGxpdDsKKwljaGFyIGJ1ZltCVUZfU0laRV07CQorCisJaWYgKGVsZiA9PSBOVUxMIHx8IGVs ZmhkciA9PSBOVUxMIHx8IHBoZHIgPT0gTlVMTCkKKwkJcmV0dXJuOworCisJc2l6ZSA9IGFkZHIg PSAwOworCXNwbGl0ID0gKHBoZHItPnBfbWVtc3ogPiAwKSAmJiAJKHBoZHItPnBfZmlsZXN6ID4g MCkgJiYgCisJICAgIChwaGRyLT5wX21lbXN6ID4gcGhkci0+cF9maWxlc3opOworCisJaWYgKHN0 eWxlID09IFNUWUxFX1NZU1YpIHsKKwkJKHZvaWQpIHNucHJpbnRmKGJ1ZiwgQlVGX1NJWkUsCisJ CSAgICAiJXMlZCVzIiwgbmFtZSwgaWR4LCAoc3BsaXQgPyAiYSIgOiAiIikpOworCQkodm9pZCkg cHJpbnRmKCIlLTE4cyAiLCBidWYpOworCQlwcmludF9udW1iZXIoMTAsICh1aW50MzJfdClwaGRy LT5wX2ZpbGVzeiwgcmFkaXgsICcgJyk7CisJCXByaW50X251bWJlcigxMCwgKHVpbnQzMl90KXBo ZHItPnBfdmFkZHIsIHJhZGl4LCAnXG4nKTsKKwkJdGV4dF9zaXplX3RvdGFsICs9IHBoZHItPnBf ZmlsZXN6OworCQlpZiAoc3BsaXQpIHsKKwkJCXNpemUgPSAodWludDMyX3QpKHBoZHItPnBfbWVt c3ogLSBwaGRyLT5wX2ZpbGVzeik7CisJCQlhZGRyID0gKHVpbnQzMl90KShwaGRyLT5wX3ZhZGRy ICsgcGhkci0+cF9maWxlc3opOworCQkJKHZvaWQpIHNucHJpbnRmKGJ1ZiwgQlVGX1NJWkUsICIl cyVkJXMiLCBuYW1lLAorCQkJICAgIGlkeCwgImIiKTsKKwkJCXRleHRfc2l6ZV90b3RhbCArPSBw aGRyLT5wX21lbXN6IC0gcGhkci0+cF9maWxlc3o7CisJCQkodm9pZCkgcHJpbnRmKCIlLTE4cyAi LCBidWYpOworCQkJcHJpbnRfbnVtYmVyKDEwLCBzaXplLCByYWRpeCwgJyAnKTsKKwkJCXByaW50 X251bWJlcigxMCwgYWRkciwgcmFkaXgsICdcbicpOworCQl9CisJfSBlbHNlIHsKKwkJaWYgKHBo ZHItPnBfdHlwZSAhPSBQVF9MT0FEKQorCQkJcmV0dXJuOworCQlpZiAoKHBoZHItPnBfZmxhZ3Mg JiBQRl9SKSAmJiAoKHBoZHItPnBfZmxhZ3MgJiBQRl9YKSB8fAorCQkgICAgISgocGhkci0+cF9m bGFncyAmIFBGX1cpKSkgJiYgKHBoZHItPnBfZmlsZXN6ICE9IDApKSB7CisJCQl0ZXh0X3NpemUg Kz0gcGhkci0+cF9maWxlc3o7CisJCQlpZiAoc3BsaXQpCisJCQkJdGV4dF9zaXplICs9IHBoZHIt PnBfbWVtc3ogLSBwaGRyLT5wX2ZpbGVzejsKKwkJfSBlbHNlIGlmICgocGhkci0+cF9mbGFncyAm IFBGX1IpICYmCisJCSAgICAocGhkci0+cF9mbGFncyAmIFBGX1cpICYmIChwaGRyLT5wX2ZpbGVz eiAhPSAwKSkgeworCQkJZGF0YV9zaXplICs9IHBoZHItPnBfZmlsZXN6OworCQkJaWYgKHNwbGl0 KQorCQkJCWRhdGFfc2l6ZSArPSBwaGRyLT5wX21lbXN6IC0gcGhkci0+cF9maWxlc3o7CisJCX0g ZWxzZSB7CisJCQlic3Nfc2l6ZSArPSBwaGRyLT5wX2ZpbGVzejsKKwkJCWlmIChzcGxpdCkKKwkJ CQlic3Nfc2l6ZSArPSBwaGRyLT5wX21lbXN6IC0gcGhkci0+cF9maWxlc3o7CisJCX0KKwl9Cit9 CisKKy8qCisgKiBHaXZlbiBhIGNvcmUgZHVtcCBmaWxlLCB0aGlzIGZ1bmN0aW9uIG1hcHMgcHJv Z3JhbSBoZWFkZXJzIHRvIHNlZ21lbnRzLgorICovCitpbnQKK2hhbmRsZV9jb3JlKGNoYXIgY29u c3QgKm5hbWUsIEVsZiAqZWxmLCBHRWxmX0VoZHIgKmVsZmhkcikKK3sKKwlHRWxmX1BoZHIgcGhk cjsKKwl1aW50MzJfdCBpOwkKKwlwaWRfdCBwaWQ7CisJY2hhciAqY29yZV9jbWRsaW5lOworCWNv bnN0IGNoYXIgKnNlZ19uYW1lOworCisJaWYgKG5hbWUgPT0gTlVMTCB8fCBlbGYgPT0gTlVMTCB8 fCBlbGZoZHIgPT0gTlVMTCkKKwkJcmV0dXJuIChFWF9EQVRBRVJSKTsKKwlpZiAgKGVsZmhkci0+ ZV9zaG51bSAhPSAwIHx8IGVsZmhkci0+ZV90eXBlICE9IEVUX0NPUkUpCisJCXJldHVybiAoRVhf REFUQUVSUik7CisJCisJc2VnX25hbWUgPSBjb3JlX2NtZGxpbmUgPSBOVUxMOworCXBpZCA9IDA7 CisJaWYgKHN0eWxlID09IFNUWUxFX1NZU1YpCisJCXN5c3ZfaGVhZGVyKG5hbWUsIE5VTEwpOwor CWVsc2UKKwkJYmVya2VsZXlfaGVhZGVyKCk7CisKKwlmb3IgKGkgPSAwOyBpIDwgZWxmaGRyLT5l X3BobnVtOyBpKyspIHsKKwkJaWYgKGdlbGZfZ2V0cGhkcihlbGYsIGksICZwaGRyKSAhPSBOVUxM KSB7CisJCQlpZiAocGhkci5wX3R5cGUgPT0gUFRfTk9URSkgeworCQkJCWhhbmRsZV9waGRyKGVs ZiwgZWxmaGRyLCAmcGhkciwgaSwgIm5vdGUiKTsKKwkJCQlnZXRfY29yZV9jbWRsaW5lX3BpZChl bGYsIGVsZmhkciwgJnBoZHIsCisJCQkJICAgICZjb3JlX2NtZGxpbmUsICZwaWQpOworCQkJCWhh bmRsZV9jb3JlX25vdGUoZWxmLCBlbGZoZHIsICZwaGRyLCBwaWQpOworCQkJfSBlbHNlIHsKKwkJ CQlzd2l0Y2gocGhkci5wX3R5cGUpIHsKKwkJCQljYXNlIFBUX05VTEw6CisJCQkJCXNlZ19uYW1l ID0gIm51bGwiOworCQkJCQlicmVhazsKKwkJCQljYXNlIFBUX0xPQUQ6CisJCQkJCXNlZ19uYW1l ID0gImxvYWQiOworCQkJCQlicmVhazsKKwkJCQljYXNlIFBUX0RZTkFNSUM6CisJCQkJCXNlZ19u YW1lID0gImR5bmFtaWMiOworCQkJCQlicmVhazsKKwkJCQljYXNlIFBUX0lOVEVSUDoKKwkJCQkJ c2VnX25hbWUgPSAiaW50ZXJwIjsKKwkJCQkJYnJlYWs7CisJCQkJY2FzZSBQVF9TSExJQjoKKwkJ CQkJc2VnX25hbWUgPSAic2hsaWIiOworCQkJCQlicmVhazsKKwkJCQljYXNlIFBUX1BIRFI6CisJ CQkJCXNlZ19uYW1lID0gInBoZHIiOworCQkJCQlicmVhazsKKwkJCQljYXNlIFBUX0dOVV9FSF9G UkFNRToKKwkJCQkJc2VnX25hbWUgPSAiZWhfZnJhbWVfaGRyIjsKKwkJCQkJYnJlYWs7CisJCQkJ Y2FzZSBQVF9HTlVfU1RBQ0s6CisJCQkJCXNlZ19uYW1lID0gInN0YWNrIjsKKwkJCQkJYnJlYWs7 CisJCQkJZGVmYXVsdDoKKwkJCQkJc2VnX25hbWUgPSAic2VnbWVudCI7CisJCQkJfQorCQkJCWhh bmRsZV9waGRyKGVsZiwgZWxmaGRyLCAmcGhkciwgaSwgc2VnX25hbWUpOworCQkJfQorCQl9CisJ fQorCisJaWYgKHN0eWxlID09IFNUWUxFX0JFUktFTEVZKSB7CisJCWlmIChjb3JlX2NtZGxpbmUg IT0gTlVMTCkgeworCQkJYmVya2VsZXlfZm9vdGVyKGNvcmVfY21kbGluZSwgbmFtZSwKKwkJCSAg ICAiY29yZSBmaWxlIGludm9rZWQgYXMiKTsKKwkJfSBlbHNlIHsKKwkJCWJlcmtlbGV5X2Zvb3Rl cihjb3JlX2NtZGxpbmUsIG5hbWUsICJjb3JlIGZpbGUiKTsKKwkJfQorCX0gZWxzZSB7CisJCXN5 c3ZfZm9vdGVyKCk7CisJCWlmIChjb3JlX2NtZGxpbmUgIT0gTlVMTCkgeworCQkJKHZvaWQpIHBy aW50ZigiIChjb3JlIGZpbGUgaW52b2tlZCBhcyAlcylcblxuIiwKKwkJCSAgICBjb3JlX2NtZGxp bmUpOworCQl9IGVsc2UgeworCQkJKHZvaWQpIHByaW50ZigiIChjb3JlIGZpbGUpXG5cbiIpOwor CQl9CisJfQorCWZyZWUoY29yZV9jbWRsaW5lKTsKKwlyZXR1cm4gKEVYX09LKTsKK30KKworLyoK KyAqIEdpdmVuIGFuIGVsZiBvYmplY3QsYXIoMSkgZmlsZW5hbWUsIGFuZCBiYXNlZCBvbiB0aGUg b3V0cHV0IHN0eWxlIAorICogYW5kIHJhZGl4IGZvcm1hdCB0aGUgdmFyaW91cyBzZWN0aW9ucyBh bmQgdGhlaXIgbGVuZ3RoIHdpbGwgYmUgcHJpbnRlZAorICogb3IgdGhlIHNpemUgb2YgdGhlIHRl eHQsIGRhdGEsIGJzcyBzZWN0aW9ucyB3aWxsIGJlIHByaW50ZWQgb3V0LgorICovCitpbnQKK2hh bmRsZV9lbGYoY2hhciBjb25zdCAqbmFtZSkKK3sKKwlHRWxmX0VoZHIgZWxmaGRyOworCUdFbGZf U2hkciBzaGRyOworCUVsZiAqZWxmLCAqZWxmMTsKKwlFbGZfQXJoZHIgKmFyaGRyOworCUVsZl9T Y24gKnNjbjsKKwlFbGZfQ21kIGVsZl9jbWQ7CisJaW50IGV4aXRfY29kZSwgZmQ7CisKKwlpZiAo bmFtZSA9PSBOVUxMKQorCQlyZXR1cm4gKEVYX05PSU5QVVQpOworCisJaWYgKChmZCA9IG9wZW4o bmFtZSwgT19SRE9OTFksIDApKSA8IDApCisJCXJldHVybiAoRVhfTk9JTlBVVCk7CisKKwllbGZf Y21kID0gRUxGX0NfUkVBRDsKKwllbGYxID0gZWxmX2JlZ2luKGZkLCBlbGZfY21kLCBOVUxMKTsK Kwl3aGlsZSAoKGVsZiA9IGVsZl9iZWdpbihmZCwgZWxmX2NtZCwgZWxmMSkpICE9IE5VTEwpIHsK KwkJYXJoZHIgPSBlbGZfZ2V0YXJoZHIoZWxmKTsKKwkJaWYgKGVsZl9raW5kKGVsZikgPT0gRUxG X0tfTk9ORSAmJiBhcmhkciA9PSBOVUxMKSB7CisJCQkodm9pZCkgZWxmX2VuZChlbGYpOworCQkJ KHZvaWQpIGVsZl9lbmQoZWxmMSk7CisJCQkodm9pZCkgY2xvc2UoZmQpOworCQkJcmV0dXJuIChF WF9EQVRBRVJSKTsKKwkJfQorCQlpZiAoZWxmX2tpbmQoZWxmKSAhPSBFTEZfS19FTEYgfHwKKwkJ CShnZWxmX2dldGVoZHIoZWxmLCAmZWxmaGRyKSA9PSBOVUxMKSkgeworCQkJZWxmX2NtZCA9IGVs Zl9uZXh0KGVsZik7CisJCQkodm9pZCkgZWxmX2VuZChlbGYpOworCQkJd2FybngoIiVzOiBGaWxl IGZvcm1hdCBub3QgcmVjb2duaXplZCIsCisJCQkgICAgYXJoZHItPmFyX25hbWUpOworCQkJY29u dGludWU7CisJCX0KKwkJLyogQ29yZSBkdW1wcyBhcmUgaGFuZGxlZCBzZXBlcmF0ZWx5ICovCisJ CWlmIChlbGZoZHIuZV9zaG51bSA9PSAwICYmIGVsZmhkci5lX3R5cGUgPT0gRVRfQ09SRSkgewor CQkJZXhpdF9jb2RlID0gaGFuZGxlX2NvcmUobmFtZSwgZWxmLCAmZWxmaGRyKTsKKwkJCSh2b2lk KSBlbGZfZW5kKGVsZik7CisJCQkodm9pZCkgZWxmX2VuZChlbGYxKTsKKwkJCSh2b2lkKSBjbG9z ZShmZCk7CisJCQlyZXR1cm4gKGV4aXRfY29kZSk7CisJCX0gZWxzZSB7CisJCQlzY24gPSBOVUxM OworCQkJaWYgKHN0eWxlID09IFNUWUxFX0JFUktFTEVZKSB7CisJCQkJYmVya2VsZXlfaGVhZGVy KCk7CisJCQkJd2hpbGUgKChzY24gPSBlbGZfbmV4dHNjbihlbGYsIHNjbikpICE9IE5VTEwpIHsK KwkJCQkJaWYgKGdlbGZfZ2V0c2hkcihzY24sICZzaGRyKSAhPSBOVUxMKQorCQkJCQkJYmVya2Vs ZXlfY2FsYygmc2hkcik7CisJCQkJfQorCQkJfSBlbHNlIHsKKwkJCQkvKgorCQkJCSAqIFBlcmZv cm0gYSBkcnkgcnVuIHRvIGZpbmQgdGhlIGxlbmd0aCBvZgorCQkJCSAqIHRoZSBsYXJnZXN0IHNl Z21lbnQgbmFtZS4KKwkJCQkgKi8KKwkJCQl3aGlsZSAoKHNjbiA9IGVsZl9uZXh0c2NuKGVsZiwg c2NuKSkgIT0gTlVMTCkgeworCQkJCQlpZiAoZ2VsZl9nZXRzaGRyKHNjbiwgJnNoZHIpICE9CU5V TEwpIHsKKwkJCQkJCXN5c3ZfY2FsYyhlbGYsICZlbGZoZHIsCisJCQkJCQkgICAgJnNoZHIsIDEp OworCQkJCQl9CisJCQkJfQorCQkJCXN5c3ZfaGVhZGVyKG5hbWUsIGFyaGRyKTsKKwkJCQlzY24g PSBOVUxMOworCQkJCXdoaWxlICgoc2NuID0gZWxmX25leHRzY24oZWxmLCBzY24pKSAhPSBOVUxM KSB7CisJCQkJCWlmIChnZWxmX2dldHNoZHIoc2NuLCAmc2hkcikgIT0JTlVMTCkKKwkJCQkJCXN5 c3ZfY2FsYyhlbGYsICZlbGZoZHIsCisJCQkJCQkgICAgJnNoZHIsIDApOworCQkJCX0KKwkJCX0K KwkJCWlmIChzdHlsZSA9PSBTVFlMRV9CRVJLRUxFWSkgeworCQkJCWlmIChhcmhkciAhPSBOVUxM KSB7CisJCQkJCWJlcmtlbGV5X2Zvb3RlcihuYW1lLCBhcmhkci0+YXJfbmFtZSwKKwkJCQkJICAg ICJleCIpOworCQkJCX0gZWxzZSB7CisJCQkJCWJlcmtlbGV5X2Zvb3RlcihuYW1lLCBOVUxMLCAi ZXgiKTsKKwkJCQl9CisJCQl9IGVsc2UgeworCQkJCXN5c3ZfZm9vdGVyKCk7CisJCQl9CisJCX0K KwkJZWxmX2NtZCA9IGVsZl9uZXh0KGVsZik7CisJCSh2b2lkKSBlbGZfZW5kKGVsZik7CisJfQor CSh2b2lkKSBlbGZfZW5kKGVsZjEpOworCSh2b2lkKSBjbG9zZShmZCk7CisJcmV0dXJuIChFWF9P Syk7Cit9CisKK3ZvaWQKK3ByaW50X251bWJlcihpbnQgd2lkdGgsIHVpbnQzMl90IG51bSwgZW51 bSByYWRpeF9zdHlsZSByYWQsIGNoYXIgYykKK3sKKwljaGFyIGJ1ZmZlcltCVUZfU0laRV07CisK Kwkodm9pZCkgc25wcmludGYoYnVmZmVyLCBCVUZfU0laRSwgKHJhZCA9PSBSQURJWF9ERUNJTUFM ID8gIiVsdSIgOgorCSAgICAoKHJhZCA9PSBSQURJWF9PQ1RBTCkgPyAiMCVsbyIgOiAiMHglbHgi KSksCisJICAgICh1bnNpZ25lZCBsb25nIGludCludW0pOworCSh2b2lkKSBwcmludGYoIiUtKnMl YyIsIHdpZHRoLCBidWZmZXIsIGMpOworfQorCisvKgorICogU3lzdiBmb3JtYXR0aW5nIGhlbHBl ciBmdW5jdGlvbnMuCisgKi8KK3ZvaWQKK3N5c3ZfaGVhZGVyKGNvbnN0IGNoYXIgKm5hbWUsIEVs Zl9BcmhkciAqYXJoZHIpCit7CisJdGV4dF9zaXplX3RvdGFsID0gMDsKKwlpZiAoYXJoZHIgIT0g TlVMTCkgeworCQkodm9pZCkgcHJpbnRmKCIlcyAgIChleCAlcyk6XG4lLSpzJS0xMHMgJS0xMHNc biIsCisJCSAgICBhcmhkci0+YXJfbmFtZSwgbmFtZSwgKGludClzZWNfbmFtZV9sZW4sCisJCSAg ICAic2VjdGlvbiIsInNpemUiLCJhZGRyIik7CisJfSBlbHNlIHsKKwkJKHZvaWQpIHByaW50Zigi JXMgIDpcbiUtKnMlLTEwcyAlLTEwc1xuIiwKKwkJICAgIG5hbWUsIChpbnQpc2VjX25hbWVfbGVu LCAic2VjdGlvbiIsCisJCSAgICAic2l6ZSIsICJhZGRyIik7CisJfQorfQorCit2b2lkCitzeXN2 X2NhbGMoRWxmICplbGYsIEdFbGZfRWhkciAqZWxmaGRyLCBHRWxmX1NoZHIgKnNoZHIsIGludCBk cnlfcnVuKQoreworCWNoYXIgKnNlY3Rpb25fbmFtZTsKKworCXNlY3Rpb25fbmFtZSA9IGVsZl9z dHJwdHIoZWxmLCBlbGZoZHItPmVfc2hzdHJuZHgsCisJCQkJCShzaXplX3Qpc2hkci0+c2hfbmFt ZSk7CisJaWYgKCFkcnlfcnVuKSB7CisJCWlmICgoc2hkci0+c2hfdHlwZSA9PSBTSFRfU1lNVEFC IHx8CisJCSAgICBzaGRyLT5zaF90eXBlID09IFNIVF9TVFJUQUIgfHwgc2hkci0+c2hfdHlwZSA9 PSBTSFRfUkVMQSB8fAorCQkgICAgc2hkci0+c2hfdHlwZSA9PSBTSFRfUkVMKSAmJiBzaGRyLT5z aF9hZGRyID09IDApIAorCQkJcmV0dXJuOworCQkodm9pZCkgcHJpbnRmKCIlLSpzIiwgKGludClz ZWNfbmFtZV9sZW4sIHNlY3Rpb25fbmFtZSk7CisJCXByaW50X251bWJlcigxMCwgKHVpbnQzMl90 KXNoZHItPnNoX3NpemUsIHJhZGl4LCAnICcpOworCQlwcmludF9udW1iZXIoMTAsICh1aW50MzJf dClzaGRyLT5zaF9hZGRyLCByYWRpeCwgJ1xuJyk7CisJCXRleHRfc2l6ZV90b3RhbCArPSBzaGRy LT5zaF9zaXplOworCX0gZWxzZSB7CisJCWlmIChzZWNfbmFtZV9sZW4gPCBzdHJsZW4oc2VjdGlv bl9uYW1lKSkKKwkJCXNlY19uYW1lX2xlbiA9IHN0cmxlbihzZWN0aW9uX25hbWUpICsgMzsKKwl9 IAorfQorCit2b2lkCitzeXN2X2Zvb3RlcigpCit7CisJKHZvaWQpIHByaW50ZigiJS0qcyIsIChp bnQpc2VjX25hbWVfbGVuLCAiVG90YWwiKTsKKwlwcmludF9udW1iZXIoMTAsIHRleHRfc2l6ZV90 b3RhbCwgcmFkaXgsICdcbicpOworCSh2b2lkKSBwcmludGYoIlxuIik7Cit9CisKKy8qCisgKiBi ZXJrZWxleSBzdHlsZSBvdXRwdXQgZm9ybWF0dGluZyBoZWxwZXIgZnVuY3Rpb25zLgorICovCit2 b2lkCitiZXJrZWxleV9oZWFkZXIoKQoreworCXRleHRfc2l6ZSA9IGRhdGFfc2l6ZSA9IGJzc19z aXplID0gMDsKK30KKwordm9pZAorYmVya2VsZXlfY2FsYyhHRWxmX1NoZHIgKnNoZHIpCit7CisJ aWYgKHNoZHIgIT0gTlVMTCkgeworCQlpZiAoIShzaGRyLT5zaF9mbGFncyAmIFNIRl9BTExPQykp IAorCQkJcmV0dXJuOworCQlpZiAoKHNoZHItPnNoX2ZsYWdzICYgU0hGX0FMTE9DKSAmJiAKKwkJ ICAgICgoc2hkci0+c2hfZmxhZ3MgJiBTSEZfRVhFQ0lOU1RSKSB8fAorCQkgICAgIShzaGRyLT5z aF9mbGFncyAmIFNIRl9XUklURSkpKQorCQkJdGV4dF9zaXplICs9IHNoZHItPnNoX3NpemU7CisJ CWVsc2UgaWYgKChzaGRyLT5zaF9mbGFncyAmIFNIRl9BTExPQykgJiYgCisJCSAgICAoc2hkci0+ c2hfZmxhZ3MgJiBTSEZfV1JJVEUpICYmCisJCSAgICAoc2hkci0+c2hfdHlwZSAhPSBTSFRfTk9C SVRTKSkKKwkJCWRhdGFfc2l6ZSArPSBzaGRyLT5zaF9zaXplOworCQllbHNlCisJCQlic3Nfc2l6 ZSArPSBzaGRyLT5zaF9zaXplOworCX0KK30KKwordm9pZAorYmVya2VsZXlfdG90YWxzKHZvaWQp Cit7CisJbG9uZyB1bnNpZ25lZCBpbnQgZ3JhbmRfdG90YWw7CisKKwlpZiAoc2hvd190b3RhbHMp IHsKKwkJZ3JhbmRfdG90YWwgPSB0ZXh0X3NpemVfdG90YWwgKyBkYXRhX3NpemVfdG90YWwgKwor CQkgICAgYnNzX3NpemVfdG90YWw7CisJCXByaW50X251bWJlcigxMCwgdGV4dF9zaXplX3RvdGFs LCByYWRpeCwgJyAnKTsKKwkJcHJpbnRfbnVtYmVyKDEwLCBkYXRhX3NpemVfdG90YWwsIHJhZGl4 LCAnICcpOworCQlwcmludF9udW1iZXIoMTAsIGJzc19zaXplX3RvdGFsLCByYWRpeCwgJyAnKTsK KwkJaWYgKHJhZGl4ID09IFJBRElYX09DVEFMKQorCQkJcHJpbnRfbnVtYmVyKDEwLCBncmFuZF90 b3RhbCwgUkFESVhfT0NUQUwsICcgJyk7CisJCWVsc2UKKwkJCXByaW50X251bWJlcigxMCwgZ3Jh bmRfdG90YWwsIFJBRElYX0RFQ0lNQUwsICcgJyk7CisJCSh2b2lkKSBwcmludGYoIiUtMTBseCAo VE9UQUxTKVxuIiwgZ3JhbmRfdG90YWwpOworCX0KK30KKwordm9pZAorYmVya2VsZXlfZm9vdGVy KGNvbnN0IGNoYXIgKm5hbWUsIGNvbnN0IGNoYXIgKmFyX25hbWUsIGNvbnN0IGNoYXIgKm1zZykK K3sKKwlzdGF0aWMgaW50IGhlYWRlcl9wcmludGVkOworCWNvbnN0IGNoYXIgKmNvbF9uYW1lOwor CisJaWYgKCFoZWFkZXJfcHJpbnRlZCkgeworCQkocmFkaXggPT0gUkFESVhfT0NUQUwpID8gKGNv bF9uYW1lID0gIm9jdCIpIDoKKwkJICAgIChjb2xfbmFtZSA9ICJkZWMiKTsKKwkJKHZvaWQpIHBy aW50ZigiJS0xMHMgJS0xMHMgJS0xMHMgJS0xMHMgJS0xMHMgZmlsZW5hbWVcbiIsCisJCSAgICAi dGV4dCIsImRhdGEiLCJic3MiLGNvbF9uYW1lLCJoZXgiKTsKKwkJaGVhZGVyX3ByaW50ZWQgPSAx OworCX0KKworCXRvdGFsX3NpemUgPSB0ZXh0X3NpemUgKyBkYXRhX3NpemUgKyBic3Nfc2l6ZTsK KwlpZiAoc2hvd190b3RhbHMpIHsKKwkJdGV4dF9zaXplX3RvdGFsICs9IHRleHRfc2l6ZTsKKwkJ YnNzX3NpemVfdG90YWwgKz0gYnNzX3NpemU7CisJCWRhdGFfc2l6ZV90b3RhbCArPSBkYXRhX3Np emU7CisJfQorCisJcHJpbnRfbnVtYmVyKDEwLCB0ZXh0X3NpemUsIHJhZGl4LCAnICcpOworCXBy aW50X251bWJlcigxMCwgZGF0YV9zaXplLCByYWRpeCwgJyAnKTsKKwlwcmludF9udW1iZXIoMTAs IGJzc19zaXplLCByYWRpeCwgJyAnKTsKKwlpZiAocmFkaXggPT0gUkFESVhfT0NUQUwpCisJCXBy aW50X251bWJlcigxMCwgdG90YWxfc2l6ZSwgUkFESVhfT0NUQUwsICcgJyk7CisJZWxzZQorCQlw cmludF9udW1iZXIoMTAsIHRvdGFsX3NpemUsIFJBRElYX0RFQ0lNQUwsICcgJyk7CisJKHZvaWQp IHByaW50ZigiJS0xMGx4XHQiLCAobG9uZyB1bnNpZ25lZCBpbnQpdG90YWxfc2l6ZSk7CisJaWYg KGFyX25hbWUgIT0gTlVMTCAmJiBuYW1lICE9IE5VTEwpCisJCSh2b2lkKSBwcmludGYoIiVzICgl cyAlcylcbiIsIGFyX25hbWUsIG1zZywgbmFtZSk7CisJZWxzZSBpZiAoYXJfbmFtZSAhPSBOVUxM ICYmIG5hbWUgPT0gTlVMTCkKKwkJKHZvaWQpIHByaW50ZigiJXMgKCVzKVxuIiwgYXJfbmFtZSwg bXNnKTsKKwllbHNlCisJCSh2b2lkKSBwcmludGYoIiVzXG4iLCBuYW1lKTsKK30KKwordm9pZAor dXNhZ2UoKQoreworCSh2b2lkKSBmcHJpbnRmKHN0ZGVyciwgInVzYWdlOiBzaXplIFstQWRob3R4 XSBmaWxlIC4uLlxuIik7CisJZXhpdChFWF9VU0FHRSk7Cit9Cg== ------=_Part_169866_31505932.1174828959441-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 15:12:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73D3916A401; Sun, 25 Mar 2007 15:12:43 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id E622C13C43E; Sun, 25 Mar 2007 15:12:42 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id l2PEYH4G004343; Sun, 25 Mar 2007 15:34:17 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HVTnU-0005pl-W6; Sun, 25 Mar 2007 15:34:16 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.8/8.13.8) with ESMTP id l2PEYGat085664; Sun, 25 Mar 2007 15:34:16 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.8/8.13.8/Submit) with ESMTP id l2PEY93k085614; Sun, 25 Mar 2007 15:34:14 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 25 Mar 2007 15:34:09 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: "Wojciech A. Koszek" In-Reply-To: <20070324233307.GA93841@FreeBSD.czest.pl> Message-ID: <20070325153013.E77473@ury.york.ac.uk> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Robert Watson , Peter Jeremy , freebsd-current@freebsd.org, Alex Kozlov Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 15:12:43 -0000 On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: > On Sun, Mar 25, 2007 at 08:00:41AM +1000, Peter Jeremy wrote: >> On 2007-Mar-24 15:32:00 +0100, Robert Watson wrote: >>> On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: >>>> I'd like to have this enabled by default, and I know there should be no >>>> strong objections. >>> >>> I agree -- the memory used by it is very small compared to the amount of >>> memory in modern systems, and the potential administrative benefit is very >>> large. As long as it remains an option, the embedded folk can turn it off >>> easily. >> Ideally, we would include it in a .comment section that wasn't loaded. >> Unfortunately my ELF-foo isn't up to this (I've tried something similar >> many years ago and couldn't get the linker to DWIW). > > In my current implementation, kernel configuration content is converted > to the string and is actually put into separate ELF section. However, > it's not .comment but a loadable section, since otherwise you wouldn't > be able to obtain the configuration of a running system. strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' should still work if it was in a .comment section Gavin From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 15:25:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD2BA16A401 for ; Sun, 25 Mar 2007 15:25:34 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a7.g.dreamhost.com (sd-green-bigip-177.dreamhost.com [208.97.132.177]) by mx1.freebsd.org (Postfix) with ESMTP id 93B9B13C44C for ; Sun, 25 Mar 2007 15:25:34 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a7.g.dreamhost.com (Postfix) with ESMTP id 04D4F5C102; Sun, 25 Mar 2007 08:25:31 -0700 (PDT) Message-ID: <4606946B.7080209@cyberwang.net> Date: Sun, 25 Mar 2007 11:25:31 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Joel Dahl References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> In-Reply-To: <1174819506.1150.4.camel@jesus.automatvapen.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org, Ariff Abdullah Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 15:25:34 -0000 Joel Dahl wrote: > On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: > >> On Sun, 25 Mar 2007 01:50:12 -0400 >> Sean Bryant wrote: >> >>> It's really strange. >>> >>> Ever since I updated to the latest source, loading snd_ich leads to >>> a kernel panic. oich_add_done is where it panics, I don't have any >>> experience gathering information that might be relevant, but if >>> anyone wants to look in to the issue i will provide and learn >>> anything required to resolve the issue (not having sound is a >>> serious issue!) >>> >> Not having enough debugging informations is a serious issue, too >> Besides, how do you come up with "oich_add_done" ? >> > > "ohci_add_done" sounds more likely: > > joel@jesus [/usr/src] grep -R add_done * > sys/dev/usb/ohci.c:static void ohci_add_done(ohci_softc_t *, ohci_physaddr_t); > sys/dev/usb/ohci.c: ohci_add_done(sc, done &~ OHCI_DONE_INTRS); > sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t *sc, ohci_physaddr_t done) > sys/dev/usb/ohci.c: panic("ohci_add_done: addr 0x%08lx not found", (u_long)done); > > That was it! Sorry. Ariff, ohci_add_done is on the actual panic line. that's how I come up with that. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 15:34:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C4EF616A407; Sun, 25 Mar 2007 15:34:08 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sun, 25 Mar 2007 23:33:41 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070325233341.7e31cc8c.ariff@FreeBSD.org> In-Reply-To: <4606946B.7080209@cyberwang.net> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__25_Mar_2007_23_33_41_+0800_6S/WH0w6fyh=zJzK" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 15:34:10 -0000 --Signature=_Sun__25_Mar_2007_23_33_41_+0800_6S/WH0w6fyh=zJzK Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 11:25:31 -0400 Sean Bryant wrote: > Joel Dahl wrote: > > On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: > > =20 > >> On Sun, 25 Mar 2007 01:50:12 -0400 > >> Sean Bryant wrote: > >> =20 > >>> It's really strange. > >>> > >>> Ever since I updated to the latest source, loading snd_ich leads > >to >> a kernel panic. oich_add_done is where it panics, I don't > >have any >> experience gathering information that might be > >relevant, but if >> anyone wants to look in to the issue i will > >provide and learn >> anything required to resolve the issue (not > >having sound is a >> serious issue!) > >>> =20 > >> Not having enough debugging informations is a serious issue, too > >> Besides, how do you come up with "oich_add_done" ? > >> =20 > > > > "ohci_add_done" sounds more likely: > > > > joel@jesus [/usr/src] grep -R add_done * > > sys/dev/usb/ohci.c:static void ohci_add_done(ohci_softc_t > > *, ohci_physaddr_t); sys/dev/usb/ohci.c: =20 > > ohci_add_done(sc, done &~ OHCI_DONE_INTRS); > > sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t *sc, ohci_physaddr_t > > done) sys/dev/usb/ohci.c: panic("ohci_add_done: addr > > 0x%08lx not found", (u_long)done); > > > > =20 > That was it! Sorry. >=20 > Ariff, ohci_add_done is on the actual panic line. that's how I come > up with that. > So where does the "loading snd_ich cause panic" fits in? Are you saying that it is all about "kldload snd_ich" or panic during boot? -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sun__25_Mar_2007_23_33_41_+0800_6S/WH0w6fyh=zJzK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBpZVlr+deMUwTNoRArQIAJ4yYQBLJBWTEvyVdg1FvdBWBPIG0wCgkDPy qyDmjp48hTVphSB5OV5YWJQ= =KL0k -----END PGP SIGNATURE----- --Signature=_Sun__25_Mar_2007_23_33_41_+0800_6S/WH0w6fyh=zJzK-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 15:47:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FA9216A400; Sun, 25 Mar 2007 15:47:34 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a20.g.dreamhost.com (sd-green-bigip-177.dreamhost.com [208.97.132.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6657913C44B; Sun, 25 Mar 2007 15:47:32 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a20.g.dreamhost.com (Postfix) with ESMTP id 6B139FE843; Sun, 25 Mar 2007 08:47:31 -0700 (PDT) Message-ID: <46069992.40706@cyberwang.net> Date: Sun, 25 Mar 2007 11:47:30 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> In-Reply-To: <20070325233341.7e31cc8c.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 15:47:34 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 11:25:31 -0400 > Sean Bryant wrote: > >> Joel Dahl wrote: >> >>> On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: >>> >>> >>>> On Sun, 25 Mar 2007 01:50:12 -0400 >>>> Sean Bryant wrote: >>>> >>>> >>>>> It's really strange. >>>>> >>>>> Ever since I updated to the latest source, loading snd_ich leads >>>>> >>> to >> a kernel panic. oich_add_done is where it panics, I don't >>> have any >> experience gathering information that might be >>> relevant, but if >> anyone wants to look in to the issue i will >>> provide and learn >> anything required to resolve the issue (not >>> having sound is a >> serious issue!) >>> >>>>> >>>>> >>>> Not having enough debugging informations is a serious issue, too >>>> Besides, how do you come up with "oich_add_done" ? >>>> >>>> >>> "ohci_add_done" sounds more likely: >>> >>> joel@jesus [/usr/src] grep -R add_done * >>> sys/dev/usb/ohci.c:static void ohci_add_done(ohci_softc_t >>> *, ohci_physaddr_t); sys/dev/usb/ohci.c: >>> ohci_add_done(sc, done &~ OHCI_DONE_INTRS); >>> sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t *sc, ohci_physaddr_t >>> done) sys/dev/usb/ohci.c: panic("ohci_add_done: addr >>> 0x%08lx not found", (u_long)done); >>> >>> >>> >> That was it! Sorry. >> >> Ariff, ohci_add_done is on the actual panic line. that's how I come >> up with that. >> >> > > So where does the "loading snd_ich cause panic" fits in? Are you > saying that it is all about "kldload snd_ich" or panic during boot? > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > panic during boot. not when loading the kernel module: pcm0: port 0xdc00-0xdcff mem 0xd5003000-0xd5003fff irq 23 at device 4.0 on pci0 pcm0: [ITHREAD] pcm0: cannot reset channel 0 pcm0: unable to initialize the card device_attach: pcm0 attach returned 6 that's what happens when I load the module after everything has started. snd_ich worked as of 3/06/07. I decided to give my machine an update and the panic is what happened. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 16:12:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C7A6316A400; Sun, 25 Mar 2007 16:12:17 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Mon, 26 Mar 2007 00:11:47 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070326001147.7bbc28ed.ariff@FreeBSD.org> In-Reply-To: <46069992.40706@cyberwang.net> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__26_Mar_2007_00_11_47_+0800_mZCG0Z6ZQ_1uKcO9" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 16:12:19 -0000 --Signature=_Mon__26_Mar_2007_00_11_47_+0800_mZCG0Z6ZQ_1uKcO9 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 11:47:30 -0400 Sean Bryant wrote: > Ariff Abdullah wrote: > > On Sun, 25 Mar 2007 11:25:31 -0400 > > Sean Bryant wrote: > > =20 > >> Joel Dahl wrote: > >> =20 > >>> On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: > >>> =20 > >>> =20 > >>>> On Sun, 25 Mar 2007 01:50:12 -0400 > >>>> Sean Bryant wrote: > >>>> =20 > >>>> =20 > >>>>> It's really strange. > >>>>> > >>>>> Ever since I updated to the latest source, loading snd_ich > >leads >>>> =20 > >>> to >> a kernel panic. oich_add_done is where it panics, I don't > >>> have any >> experience gathering information that might be > >>> relevant, but if >> anyone wants to look in to the issue i will > >>> provide and learn >> anything required to resolve the issue > >(not >> having sound is a >> serious issue!) > >>> =20 > >>>>> =20 > >>>>> =20 > >>>> Not having enough debugging informations is a serious issue, > >too >>> Besides, how do you come up with "oich_add_done" ? > >>>> =20 > >>>> =20 > >>> "ohci_add_done" sounds more likely: > >>> > >>> joel@jesus [/usr/src] grep -R add_done * > >>> sys/dev/usb/ohci.c:static void =20 > >ohci_add_done(ohci_softc_t >> *, ohci_physaddr_t); > >sys/dev/usb/ohci.c: >> ohci_add_done(sc, done &~ > >OHCI_DONE_INTRS); >> sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t > >*sc, ohci_physaddr_t >> done) sys/dev/usb/ohci.c: =20 > >panic("ohci_add_done: addr >> 0x%08lx not found", (u_long)done); > >>> > >>> =20 > >>> =20 > >> That was it! Sorry. > >> > >> Ariff, ohci_add_done is on the actual panic line. that's how I > >come > up with that. > >> > >> =20 > > > > So where does the "loading snd_ich cause panic" fits in? Are you > > saying that it is all about "kldload snd_ich" or panic during > > boot? > > > > > panic during boot. not when loading the kernel module: >=20 > pcm0: port 0xdc00-0xdcff mem 0xd5003000-0xd5003fff > irq 23 at device 4.0 on pci0 > pcm0: [ITHREAD] > pcm0: cannot reset channel 0 > pcm0: unable to initialize the card > device_attach: pcm0 attach returned 6 >=20 >=20 > that's what happens when I load the module after everything has > started. snd_ich worked as of 3/06/07. I decided to give my machine > an update and the panic is what happened. >=20 >=20 I'm suspecting something more generic. Virtually, nothing is changed within snd_ich land within that timeframe, except few bug fixes mostly during detach procedure. Besides, your panic source is from USB land, not snd_ich. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__26_Mar_2007_00_11_47_+0800_mZCG0Z6ZQ_1uKcO9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBp9Dlr+deMUwTNoRAh/LAKDajeigWPnshI+xPMhOtMOCBe3q2wCgxtDP WXyj3euBbd2+8LkIrUsi0U8= =hoKy -----END PGP SIGNATURE----- --Signature=_Mon__26_Mar_2007_00_11_47_+0800_mZCG0Z6ZQ_1uKcO9-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 16:30:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B9516A402 for ; Sun, 25 Mar 2007 16:30:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DC36713C44B for ; Sun, 25 Mar 2007 16:30:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l2PGUmb1012170; Sun, 25 Mar 2007 10:30:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4606A3B2.9050005@samsco.org> Date: Sun, 25 Mar 2007 10:30:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Kevin Day References: <52299CBE-F3AD-439D-820D-3FC3458614F8@dragondata.com> <4600C451.2020407@samsco.org> <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> In-Reply-To: <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 25 Mar 2007 09:30:53 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: aac & PAE not happy in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 16:30:57 -0000 Kevin Day wrote: > > On Mar 21, 2007, at 12:36 AM, Scott Long wrote: >>> Booting the same kernel without PAE I get the same thing: >>> aacch0: port 0xcc00-0xccff mem >>> 0xfccff000-0xfccfffff irq 30 at device 6.0 on pci5 >>> aacch1: port 0xc800-0xc8ff mem >>> 0xfccfe000-0xfccfefff irq 31 at device 6.1 on pci5 >>> aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 >>> on pci4 >>> aac0: [FAST] >>> aac0: Adaptec Raid Controller 2.0.0-1 >>> and it works fine. >>> Is this a known problem, or is there any other info I can give? Happy >>> to try anything anyone might suggest. :) >> >> The device is asking for 128MB of register space. This is exhausting >> the limit on the amount of kernel mapped memory, hence the panic. The >> difference between PAE and non-PAE is likely that the non-PAE case >> isn't consuming as much kernel address space for the extra page tables, >> so you're squeaking by. >> >> The 128MB of register space is wrong, but it's something that the aac >> firmware is causing. I don't have a 2650, but my 2450 only tries to >> claim 4K for registers for the aac device, and the hardware is basically >> identical to the 2650. Maybe try flashing in a newer (or older) >> firmware? Knowing what firmware version you have would help. > > Okay, after spending the better part of the weekend trying to figure out > how to PXE boot the floppies that Dell gives you (using their own > version of DOS), I've upgraded to the very latest system BIOS, > controller firmware and kernel, and it's still requesting 128MB of > memory. Nothing seems to have changed really. > > Any other suggestions? Booting into Linux seems to show that it's also > eating 128MB of memory space there, so it's nothing FreeBSD is doing to > cause this. > > Does your controller have the 128MB dimm for caching? I still can't see > why they'd expose that to the host, but it's my only theory at the moment. > Sorry for the confusion, it turns out that my math was wrong and my machine is mapping all of the DIMM space as well, though it's not 128MB. Exposing the full DIMM size to the host is really just an act of laziness on the part of the firmware engineers; it's convenient for debugging the firmware and doing other development tasks, but it's not useful for anything else. So, we're left with figuring out workarounds. I'm not sure if the driver can force less of the space to be mapped, I'll look into that. The other workaround is to change VM_KMEM_SIZE_MAX in /sys/i386/include/vmparam.h to a larger value, but probably no more than around 500. Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 16:42:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEF1516A403 for ; Sun, 25 Mar 2007 16:42:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 80E3A13C489 for ; Sun, 25 Mar 2007 16:42:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id EE79D17382; Sun, 25 Mar 2007 16:42:45 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l2PGgi4u001231; Sun, 25 Mar 2007 16:42:45 GMT (envelope-from phk@critter.freebsd.dk) To: "SUNGBAK KIM" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Mar 2007 17:34:48 +0900." Date: Sun, 25 Mar 2007 16:42:44 +0000 Message-ID: <1230.1174840964@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: NI PCI-GPIB tnt4882 test failed on FreeBSD Current 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 16:42:47 -0000 In message , "SUNGBAK KIM" writes: >GPIB control with FreeBSD 7.0 Current because of supporting NI PCI-GPIB >interface card. >4. Basic Code Testing > >I compiled *IDN? Qurey C code as shown below archive but no response from >instrument (AFG3102, etc and linux-gpib returned good results ). > >http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2005-February/010164.html > >and modyfied Code returned dmm = 0 > >/*** PRINT DMM ****/ >dmm = ibdev(0, 11, 0, T1s, 1, 0); >printf(" dmm = %d\n", dmm); >if (dmm < 0) > errx(1, "ibdev = %d\n", dmm); > ibwrt(dmm, "*IDN?\r\n", 7); > >I think dmm should be dmm > 0, if properly configured. right ? zero is a valid handle, so that is OK. Off the top of my head I cannot see what should be wrong, but our GPIB code is not very mature, or for that matter, well tested. I have used it mostly with my various HP equipment and have only ever tried it with one non-HP piece of equipment: my Tex scope. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 17:09:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DA2B16A408; Sun, 25 Mar 2007 17:09:52 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9449A13C459; Sun, 25 Mar 2007 17:09:51 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup105.ach.sch.gr [81.186.70.105]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PGwp5h009064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2007 19:59:09 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PGwic1001620; Sun, 25 Mar 2007 19:58:45 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PGwhlF001619; Sun, 25 Mar 2007 19:58:43 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 25 Mar 2007 19:58:43 +0300 From: Giorgos Keramidas To: Andrey Chernov , current@freebsd.org Message-ID: <20070325165843.GA1558@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070324124732.GA767@nagual.pp.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.669, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 17:09:52 -0000 On 2007-03-24 15:47, Andrey Chernov wrote: > Very recent -current cause complete lockup in case and after small > amount of network activity happens. No panic, no ddb console - nothing > just lockup. Previously working kernel is from Mar 22. I suspect > recent round of TCP changes. I'm seeing kernel panics with a kernel updates to: changeset: 129918:f239d4a0fa1e tag: tip user: imp date: Fri Mar 23 23:47:59 2007 +0000 summary: Default to booting off the SD card. It is more useful, [...] The panic happens after a small amount of network activity, inside the TCP SACK code: --------------------------------------------------------------------------- Physical memory: 495 MB Dumping 54 MB: 39 23 7 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc048043f in db_fncall (dummy1=-747300744, dummy2=0, dummy3=-1065545344, dummy4=0xd3751854 "@\037\206�") at /home/build/src/sys/ddb/db_command.c:486 #2 0xc048024b in db_command (last_cmdp=0xc07dec24, cmd_table=0x0) at /home/build/src/sys/ddb/db_command.c:401 #3 0xc0480306 in db_command_loop () at /home/build/src/sys/ddb/db_command.c:453 #4 0xc0481f51 in db_trap (type=3, code=0) at /home/build/src/sys/ddb/db_main.c:222 #5 0xc058a574 in kdb_trap (type=3, code=0, tf=0xd37519ec) at /home/build/src/sys/kern/subr_kdb.c:502 #6 0xc07164c9 in trap (frame=0xd37519ec) at /home/build/src/sys/i386/i386/trap.c:621 #7 0xc070041b in calltrap () at /home/build/src/sys/i386/i386/exception.s:139 #8 0xc058a29b in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc056b628 in panic (fmt=0xc0776652 "%s: SACK invalid") at /home/build/src/sys/kern/kern_shutdown.c:547 #10 0xc0627513 in tcp_sack_doack (tp=0xc300f740, to=0xd3751ac8, th_ack=3759729646) at /home/build/src/sys/netinet/tcp_sack.c:374 #11 0xc0623f88 in tcp_do_segment (m=0xc310ca00, th=0xc3140834, so=0xc3020570, tp=0xc300f740, drop_hdrlen=52, tlen=138) at /home/build/src/sys/netinet/tcp_input.c:1900 #12 0xc0622f01 in tcp_input (m=0xc310ca00, off0=20) at /home/build/src/sys/netinet/tcp_input.c:1004 #13 0xc061c3a5 in ip_input (m=0xc310ca00) at /home/build/src/sys/netinet/ip_input.c:662 #14 0xc05ee3c4 in netisr_dispatch (num=2, m=0x0) at /home/build/src/sys/net/netisr.c:278 #15 0xc05e7f85 in ether_demux (ifp=0xc2a55800, m=0xc310ca00) at /home/build/src/sys/net/if_ethersubr.c:829 #16 0xc05e7dc5 in ether_input (ifp=0xc2a55800, m=0xc310ca00) at /home/build/src/sys/net/if_ethersubr.c:687 #17 0xc04bdb18 in fxp_intr_body (sc=0xc2a74000, ifp=0xc2a55800, statack=0 '\0', count=-1) at /home/build/src/sys/dev/fxp/if_fxp.c:1705 #18 0xc04bd871 in fxp_intr (xsc=0xc2a74000) at /home/build/src/sys/dev/fxp/if_fxp.c:1526 #19 0xc0556d85 in ithread_execute_handlers (p=0xc2a4f480, ie=0xc2976800) at /home/build/src/sys/kern/kern_intr.c:682 #20 0xc0556eab in ithread_loop (arg=0xc2a7bad0) at /home/build/src/sys/kern/kern_intr.c:766 #21 0xc0555e84 in fork_exit (callout=0xc0556e44 , arg=0xc2a7bad0, frame=0xd3751d38) at /home/build/src/sys/kern/kern_fork.c:814 #22 0xc0700490 in fork_trampoline () at /home/build/src/sys/i386/i386/exception.s:205 (kgdb) up 10 #10 0xc0627513 in tcp_sack_doack (tp=0xc300f740, to=0xd3751ac8, th_ack=3759729646) at /home/build/src/sys/netinet/tcp_sack.c:374 374 KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", __func__)); (kgdb) list 369 struct sackhole *cur, *temp; 370 struct sackblk sack, sack_blocks[TCP_MAX_SACK + 1], *sblkp; 371 int i, j, num_sack_blks; 372 373 INP_LOCK_ASSERT(tp->t_inpcb); 374 KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", __func__)); 375 376 num_sack_blks = 0; 377 /* 378 * If SND.UNA will be advanced by SEG.ACK, and if SACK holes exist, (kgdb) --------------------------------------------------------------------------- Disabling SACK lets me use my laptop again: net.inet.tcp.sack.enable=0 without any panics. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 17:17:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92B7816A403; Sun, 25 Mar 2007 17:17:13 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a19.g.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207]) by mx1.freebsd.org (Postfix) with ESMTP id 7803613C4B9; Sun, 25 Mar 2007 17:17:13 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a19.g.dreamhost.com (Postfix) with ESMTP id 6AA1E1022B; Sun, 25 Mar 2007 10:17:10 -0700 (PDT) Message-ID: <4606AE95.6010606@cyberwang.net> Date: Sun, 25 Mar 2007 13:17:09 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> In-Reply-To: <20070326001147.7bbc28ed.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 17:17:13 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 11:47:30 -0400 > Sean Bryant wrote: > >> Ariff Abdullah wrote: >> >>> On Sun, 25 Mar 2007 11:25:31 -0400 >>> Sean Bryant wrote: >>> >>> >>>> Joel Dahl wrote: >>>> >>>> >>>>> On Sun, 2007-03-25 at 18:28 +0800, Ariff Abdullah wrote: >>>>> >>>>> >>>>> >>>>>> On Sun, 25 Mar 2007 01:50:12 -0400 >>>>>> Sean Bryant wrote: >>>>>> >>>>>> >>>>>> >>>>>>> It's really strange. >>>>>>> >>>>>>> Ever since I updated to the latest source, loading snd_ich >>>>>>> >>> leads >>>> >>> >>>>> to >> a kernel panic. oich_add_done is where it panics, I don't >>>>> have any >> experience gathering information that might be >>>>> relevant, but if >> anyone wants to look in to the issue i will >>>>> provide and learn >> anything required to resolve the issue >>>>> >>> (not >> having sound is a >> serious issue!) >>> >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Not having enough debugging informations is a serious issue, >>>>>> >>> too >>> Besides, how do you come up with "oich_add_done" ? >>> >>>>>> >>>>>> >>>>>> >>>>> "ohci_add_done" sounds more likely: >>>>> >>>>> joel@jesus [/usr/src] grep -R add_done * >>>>> sys/dev/usb/ohci.c:static void >>>>> >>> ohci_add_done(ohci_softc_t >> *, ohci_physaddr_t); >>> sys/dev/usb/ohci.c: >> ohci_add_done(sc, done &~ >>> OHCI_DONE_INTRS); >> sys/dev/usb/ohci.c:ohci_add_done(ohci_softc_t >>> *sc, ohci_physaddr_t >> done) sys/dev/usb/ohci.c: >>> panic("ohci_add_done: addr >> 0x%08lx not found", (u_long)done); >>> >>>>> >>>>> >>>>> >>>> That was it! Sorry. >>>> >>>> Ariff, ohci_add_done is on the actual panic line. that's how I >>>> >>> come > up with that. >>> >>>> >>>> >>> So where does the "loading snd_ich cause panic" fits in? Are you >>> saying that it is all about "kldload snd_ich" or panic during >>> boot? >>> >>> >>> >> panic during boot. not when loading the kernel module: >> >> pcm0: port 0xdc00-0xdcff mem 0xd5003000-0xd5003fff >> irq 23 at device 4.0 on pci0 >> pcm0: [ITHREAD] >> pcm0: cannot reset channel 0 >> pcm0: unable to initialize the card >> device_attach: pcm0 attach returned 6 >> >> >> that's what happens when I load the module after everything has >> started. snd_ich worked as of 3/06/07. I decided to give my machine >> an update and the panic is what happened. >> >> >> > > I'm suspecting something more generic. Virtually, nothing is changed > within snd_ich land within that timeframe, except few bug fixes mostly > during detach procedure. > > Besides, your panic source is from USB land, not snd_ich. > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > That's what I suspected. So I just installed the latest HPS usb stack and it's the same. pcm0: port 0xdc00-0xdcff,0x4400-0x44ff mem 0xd5003000-0xd5003fff irq 23 at device 4.0 on pci0 pcm0: [ITHREAD] pcm0: cannot reset channel 0 pcm0: unable to initialize the card device_attach: pcm0 attach returned 6 With the latest HPS USB stack not sure if that's the same one in HEAD or not. Maybe something is conflicting or some other change has caused the resources to be tied up. That's a really rough guess with no evidence to support it. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 17:28:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id D3E4716A403; Sun, 25 Mar 2007 17:28:53 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Mon, 26 Mar 2007 01:28:26 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070326012826.7bd36ac8.ariff@FreeBSD.org> In-Reply-To: <4606AE95.6010606@cyberwang.net> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__26_Mar_2007_01_28_26_+0800_bHIwsfW_8Df/EOzZ" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 17:28:55 -0000 --Signature=_Mon__26_Mar_2007_01_28_26_+0800_bHIwsfW_8Df/EOzZ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 13:17:09 -0400 Sean Bryant wrote: [....] > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>> That was it! Sorry. > >>>> > >>>> Ariff, ohci_add_done is on the actual panic line. that's how I > >>>> =20 > >>> come > up with that. > >>> =20 > >>>> =20 > >>>> =20 > >>> So where does the "loading snd_ich cause panic" fits in? Are you > >>> saying that it is all about "kldload snd_ich" or panic during > >>> boot? > >>> > >>> > >>> =20 > >> panic during boot. not when loading the kernel module: > >> > >> pcm0: port 0xdc00-0xdcff mem > >0xd5003000-0xd5003fff > irq 23 at device 4.0 on pci0 > >> pcm0: [ITHREAD] > >> pcm0: cannot reset channel 0 > >> pcm0: unable to initialize the card > >> device_attach: pcm0 attach returned 6 > >> > >> > >> that's what happens when I load the module after everything has > >> started. snd_ich worked as of 3/06/07. I decided to give my > >machine > an update and the panic is what happened. > >> > >> > >> =20 > > > > I'm suspecting something more generic. Virtually, nothing is > > changed within snd_ich land within that timeframe, except few bug > > fixes mostly during detach procedure. > > > > Besides, your panic source is from USB land, not snd_ich. > > > That's what I suspected. So I just installed the latest HPS usb > stack and it's the same. >=20 > pcm0: port 0xdc00-0xdcff,0x4400-0x44ff mem=20 > 0xd5003000-0xd5003fff irq 23 at device 4.0 on pci0 > pcm0: [ITHREAD] > pcm0: cannot reset channel 0 > pcm0: unable to initialize the card > device_attach: pcm0 attach returned 6 >=20 Try this one: (sys/dev/sound/pci/ich.c) http://people.freebsd.org/~ariff/test/ich.c (no, this has nothing to do with the panic at all) >=20 > With the latest HPS USB stack not sure if that's the same one in > HEAD or not. > Maybe something is conflicting or some other change has caused the=20 > resources to be tied up. That's a really rough guess with no > evidence to support it. >=20 You should reproduce the panic, generate the dump, submit the backtrace so things will become much clear for us. Will you? -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__26_Mar_2007_01_28_26_+0800_bHIwsfW_8Df/EOzZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBrE6lr+deMUwTNoRApGCAKC3uVBUyq34So1jy3jjxg44ZzEa/ACfbmXk Fr992v4cBEzWOsw4UHDQbZs= =Iwij -----END PGP SIGNATURE----- --Signature=_Mon__26_Mar_2007_01_28_26_+0800_bHIwsfW_8Df/EOzZ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 17:44:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5583216A400; Sun, 25 Mar 2007 17:44:16 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a18.g.dreamhost.com (sd-green-bigip-202.dreamhost.com [208.97.132.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3A81913C48C; Sun, 25 Mar 2007 17:44:16 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a18.g.dreamhost.com (Postfix) with ESMTP id 9F4F25B52D; Sun, 25 Mar 2007 10:44:15 -0700 (PDT) Message-ID: <4606B4EC.50709@cyberwang.net> Date: Sun, 25 Mar 2007 13:44:12 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> In-Reply-To: <20070326012826.7bd36ac8.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 17:44:16 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 13:17:09 -0400 > Sean Bryant wrote: > [....] > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> That was it! Sorry. >>>>>> >>>>>> Ariff, ohci_add_done is on the actual panic line. that's how I >>>>>> >>>>>> >>>>> come > up with that. >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>> So where does the "loading snd_ich cause panic" fits in? Are you >>>>> saying that it is all about "kldload snd_ich" or panic during >>>>> boot? >>>>> >>>>> >>>>> >>>>> >>>> panic during boot. not when loading the kernel module: >>>> >>>> pcm0: port 0xdc00-0xdcff mem >>>> >>> 0xd5003000-0xd5003fff > irq 23 at device 4.0 on pci0 >>> >>>> pcm0: [ITHREAD] >>>> pcm0: cannot reset channel 0 >>>> pcm0: unable to initialize the card >>>> device_attach: pcm0 attach returned 6 >>>> >>>> >>>> that's what happens when I load the module after everything has >>>> started. snd_ich worked as of 3/06/07. I decided to give my >>>> >>> machine > an update and the panic is what happened. >>> >>>> >>>> >>> I'm suspecting something more generic. Virtually, nothing is >>> changed within snd_ich land within that timeframe, except few bug >>> fixes mostly during detach procedure. >>> >>> Besides, your panic source is from USB land, not snd_ich. >>> >>> >> That's what I suspected. So I just installed the latest HPS usb >> stack and it's the same. >> >> pcm0: port 0xdc00-0xdcff,0x4400-0x44ff mem >> 0xd5003000-0xd5003fff irq 23 at device 4.0 on pci0 >> pcm0: [ITHREAD] >> pcm0: cannot reset channel 0 >> pcm0: unable to initialize the card >> device_attach: pcm0 attach returned 6 >> >> > > Try this one: (sys/dev/sound/pci/ich.c) > > http://people.freebsd.org/~ariff/test/ich.c > > (no, this has nothing to do with the panic at all) > > >> With the latest HPS USB stack not sure if that's the same one in >> HEAD or not. >> Maybe something is conflicting or some other change has caused the >> resources to be tied up. That's a really rough guess with no >> evidence to support it. >> >> > > You should reproduce the panic, generate the dump, submit the > backtrace so things will become much clear for us. Will you? > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > Will do. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 17:47:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D802B16A404 for ; Sun, 25 Mar 2007 17:47:52 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 60FD413C4B9 for ; Sun, 25 Mar 2007 17:47:52 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2PHllb6052117; Sun, 25 Mar 2007 21:47:47 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2PHll45052116; Sun, 25 Mar 2007 21:47:47 +0400 (MSD) (envelope-from ache) Date: Sun, 25 Mar 2007 21:47:47 +0400 From: Andrey Chernov To: Giorgos Keramidas Message-ID: <20070325174747.GA52093@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Giorgos Keramidas , current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <20070325165843.GA1558@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070325165843.GA1558@kobe.laptop> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 17:47:52 -0000 On Sun, Mar 25, 2007 at 07:58:43PM +0300, Giorgos Keramidas wrote: > > Disabling SACK lets me use my laptop again: > > net.inet.tcp.sack.enable=0 > > without any panics. I very suspect this commit (can't check right now for sure): tcp_sack.c revision 1.35 date: 2007/03/23 18:33:21; author: andre; state: Exp; lines: +1 -0 Bring SACK option handling in tcp_dooptions() in line with all other options and ajust users accordingly. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 18:40:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FFE116A401 for ; Sun, 25 Mar 2007 18:40:42 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6A02013C4C7 for ; Sun, 25 Mar 2007 18:40:42 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.150.69]) by VL-MO-MR001.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JFG00FM2ZRPQO80@VL-MO-MR001.ip.videotron.ca> for freebsd-current@freebsd.org; Sun, 25 Mar 2007 13:40:37 -0400 (EDT) Date: Sun, 25 Mar 2007 13:40:27 -0400 From: Nicolas Blais To: freebsd-current@freebsd.org Message-id: <200703251340.36525.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart5622395.63fBd87lZd; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit User-Agent: KMail/1.9.6 Subject: gjournal questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 18:40:42 -0000 --nextPart5622395.63fBd87lZd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've been experimenting with gjournal with the hopes of using it in my new= =20 server (SuperMicro 5015M-NTB) . I have several questions, hopefully someone= =20 can help me out. 1. I simulated a crash (hard power-off while transfering files). When I=20 rebooted, I got the following on my console: ad0: 78167MB at ata0-master UDMA133 acd0: DVDR at ata1-master UDMA33 ad4: 76319MB at ata2-master SATA150 ad6: 76319MB at ata3-master SATA150 ad10: 76319MB at ata5-master SATA150 GEOM_JOURNAL: Journal 2822006383: ad10s1 contains data. GEOM_JOURNAL: Journal 2822006383: ad10s1 contains journal. GEOM_JOURNAL: Journal ad10s1 clean. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 0= x00 0x01 ar0: 76293MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: R/W mount of /mnt/journaled denied. Filesystem is not clean - run= =20 fsck Only /mnt/journaled (ad10s1.journal) is gjournaled. Why doesn't fsck, which= is=20 running in background mode by now, check my /mnt/journaled and tag it clean= ?=20 I have to manually fsck /dev/ad10s1.journal and manually remount it. This i= s=20 a no-go because I want my system to be able to run without the helps of us,= =20 bipeds even in the event of a crash :). /usr and /var where fsck'ed in=20 background as expected. Therefore, is it possible to make a crash recovery with gjournal without th= e=20 need of humains? Short story: I'm leaving for Afghanistan in August and tha= t=20 specific server will not have anyone doing maintenance other than 2. Since my new server will require a fresh installation, can I set up my=20 gjournal slices from within sysinstall by choosing "Custom NewFS" and putti= ng=20 the -J option in there? Will that load the gjournal module? What is the=20 correct way to implement gjournal from a fresh start? 3. From gjournal(8) man page: "It is not recommended to use gjournal for sm= all=20 file systems (e.g.: only few gigabytes big)." How much is a "few"? Is it <= =20 10gb? <50gb? I intend to use gjournal on /var (10gb), /usr (100gb), /home=20 (1tb) and some misc mounts. (~25-100gb). 4. I'm thinking of using gmirror instead of my MB's onboard raid. I found f= rom=20 previous posts that I can mount async, disable soft-updates and that for=20 simplicity it would be better to mirror the whole drive instead of slices=20 (which is what I want to know). Anything else I could use/know about using= =20 gmirror and gjournal?=20 Thank you VERY MUCH for your help. Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #17: Sun Mar 25 10:07:13 EDT 2007 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://plaintext.clkroot.net/security/nb_root.asc --nextPart5622395.63fBd87lZd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGBrQM4wTBlvcsbJURAqyxAJ9hPboYSeGI1tHxwAMok/3mkJzrtACdHAbu EUU83l8y1m0G3X2tQot0aDU= =mO7Y -----END PGP SIGNATURE----- --nextPart5622395.63fBd87lZd-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 18:49:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD4BD16A402 for ; Sun, 25 Mar 2007 18:49:00 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8513513C458 for ; Sun, 25 Mar 2007 18:49:00 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.150.69]) by VL-MH-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JFH00F6L05NOSB0@VL-MH-MR002.ip.videotron.ca> for freebsd-current@freebsd.org; Sun, 25 Mar 2007 13:49:00 -0400 (EDT) Date: Sun, 25 Mar 2007 13:48:58 -0400 From: Nicolas Blais In-reply-to: <20070325165843.GA1558@kobe.laptop> To: freebsd-current@freebsd.org Message-id: <200703251348.58972.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart5596178.avFzQm9Z5a; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <20070324124732.GA767@nagual.pp.ru> <20070325165843.GA1558@kobe.laptop> User-Agent: KMail/1.9.6 Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 18:49:00 -0000 --nextPart5596178.avFzQm9Z5a Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > The panic happens after a small amount of network activity, inside the > TCP SACK code: > > -------------------------------------------------------------------------= =2D- > Physical memory: 495 MB > Dumping 54 MB: 39 23 7 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0xc048043f in db_fncall (dummy1=3D-747300744, dummy2=3D0, > dummy3=3D-1065545344, dummy4=3D0xd3751854 "@\037\206=C0") at > /home/build/src/sys/ddb/db_command.c:486 #2 0xc048024b in db_command > (last_cmdp=3D0xc07dec24, cmd_table=3D0x0) at > /home/build/src/sys/ddb/db_command.c:401 #3 0xc0480306 in db_command_loop > () at /home/build/src/sys/ddb/db_command.c:453 #4 0xc0481f51 in db_trap > (type=3D3, code=3D0) at /home/build/src/sys/ddb/db_main.c:222 #5 0xc058a= 574 in > kdb_trap (type=3D3, code=3D0, tf=3D0xd37519ec) at > /home/build/src/sys/kern/subr_kdb.c:502 #6 0xc07164c9 in trap > (frame=3D0xd37519ec) at /home/build/src/sys/i386/i386/trap.c:621 #7=20 > 0xc070041b in calltrap () at /home/build/src/sys/i386/i386/exception.s:139 > #8 0xc058a29b in kdb_enter (msg=3D0x12
) at > cpufunc.h:60 #9 0xc056b628 in panic (fmt=3D0xc0776652 "%s: SACK invalid"= ) at > /home/build/src/sys/kern/kern_shutdown.c:547 #10 0xc0627513 in > tcp_sack_doack (tp=3D0xc300f740, to=3D0xd3751ac8, th_ack=3D3759729646) at > /home/build/src/sys/netinet/tcp_sack.c:374 #11 0xc0623f88 in tcp_do_segme= nt > (m=3D0xc310ca00, th=3D0xc3140834, so=3D0xc3020570, tp=3D0xc300f740, drop_= hdrlen=3D52, > tlen=3D138) at /home/build/src/sys/netinet/tcp_input.c:1900 #12 0xc0622f0= 1 in > tcp_input (m=3D0xc310ca00, off0=3D20) at > /home/build/src/sys/netinet/tcp_input.c:1004 #13 0xc061c3a5 in ip_input > (m=3D0xc310ca00) at /home/build/src/sys/netinet/ip_input.c:662 #14 0xc05e= e3c4 > in netisr_dispatch (num=3D2, m=3D0x0) at /home/build/src/sys/net/netisr.c= :278 > #15 0xc05e7f85 in ether_demux (ifp=3D0xc2a55800, m=3D0xc310ca00) at > /home/build/src/sys/net/if_ethersubr.c:829 #16 0xc05e7dc5 in ether_input > (ifp=3D0xc2a55800, m=3D0xc310ca00) at > /home/build/src/sys/net/if_ethersubr.c:687 #17 0xc04bdb18 in fxp_intr_body > (sc=3D0xc2a74000, ifp=3D0xc2a55800, statack=3D0 '\0', count=3D-1) at > /home/build/src/sys/dev/fxp/if_fxp.c:1705 #18 0xc04bd871 in fxp_intr > (xsc=3D0xc2a74000) at /home/build/src/sys/dev/fxp/if_fxp.c:1526 #19 > 0xc0556d85 in ithread_execute_handlers (p=3D0xc2a4f480, ie=3D0xc2976800) = at > /home/build/src/sys/kern/kern_intr.c:682 #20 0xc0556eab in ithread_loop > (arg=3D0xc2a7bad0) at /home/build/src/sys/kern/kern_intr.c:766 #21 0xc055= 5e84 > in fork_exit (callout=3D0xc0556e44 , arg=3D0xc2a7bad0, > frame=3D0xd3751d38) at /home/build/src/sys/kern/kern_fork.c:814 #22 > 0xc0700490 in fork_trampoline () at > /home/build/src/sys/i386/i386/exception.s:205 (kgdb) up 10 > #10 0xc0627513 in tcp_sack_doack (tp=3D0xc300f740, to=3D0xd3751ac8, > th_ack=3D3759729646) at /home/build/src/sys/netinet/tcp_sack.c:374 374 = =20 > KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", __func__)); > (kgdb) list > 369 struct sackhole *cur, *temp; > 370 struct sackblk sack, sack_blocks[TCP_MAX_SACK + 1], *sblk= p; > 371 int i, j, num_sack_blks; > 372 > 373 INP_LOCK_ASSERT(tp->t_inpcb); > 374 KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", > __func__)); 375 > 376 num_sack_blks =3D 0; > 377 /* > 378 * If SND.UNA will be advanced by SEG.ACK, and if SACK > holes exist, (kgdb) > -------------------------------------------------------------------------= =2D- > > Disabling SACK lets me use my laptop again: > > net.inet.tcp.sack.enable=3D0 > > without any panics. Same here. If you want to quickly crash your system,=20 net.inet.tcp.sack.enable=3D1 and start a torrent :) I couldn't find what was causing my desktop to crash until I STOPPED trying= to=20 restart my torrent after boot :) . Though net.inet.tcp.sack.enable=3D0 fixe= d=20 it. Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #17: Sun Mar 25 10:07:13 EDT 2007 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://plaintext.clkroot.net/security/nb_root.asc --nextPart5596178.avFzQm9Z5a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGBrYK4wTBlvcsbJURAto2AKCmfkFrHnhTed/eNgTkaEWKYJsjlQCfTVzO KFSgUTUojrrhtzgHA2dTu54= =kFja -----END PGP SIGNATURE----- --nextPart5596178.avFzQm9Z5a-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 18:50:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A2A516A536; Sun, 25 Mar 2007 18:50:15 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.freebsd.org (Postfix) with ESMTP id CF27A13C44B; Sun, 25 Mar 2007 18:50:14 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from [90.224.61.75] (90.224.61.75) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 45D47D3D009C8AAB; Sun, 25 Mar 2007 19:41:07 +0200 Message-ID: <4606B42A.502@gmail.com> Date: Sun, 25 Mar 2007 19:40:58 +0200 From: Niclas Zeising User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Giorgos Keramidas References: <20070324124732.GA767@nagual.pp.ru> <20070325165843.GA1558@kobe.laptop> In-Reply-To: <20070325165843.GA1558@kobe.laptop> Content-Type: multipart/mixed; boundary="------------080305050202080106070600" Cc: current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 18:50:15 -0000 This is a multi-part message in MIME format. --------------080305050202080106070600 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Giorgos Keramidas wrote: > On 2007-03-24 15:47, Andrey Chernov wrote: >> Very recent -current cause complete lockup in case and after small >> amount of network activity happens. No panic, no ddb console - nothing >> just lockup. Previously working kernel is from Mar 22. I suspect >> recent round of TCP changes. > > I'm seeing kernel panics with a kernel updates to: > > changeset: 129918:f239d4a0fa1e > tag: tip > user: imp > date: Fri Mar 23 23:47:59 2007 +0000 > summary: Default to booting off the SD card. It is more useful, [...] > > The panic happens after a small amount of network activity, inside the > TCP SACK code: > > --------------------------------------------------------------------------- > Physical memory: 495 MB > Dumping 54 MB: 39 23 7 > [SNIP stack trace] > --------------------------------------------------------------------------- > > Disabling SACK lets me use my laptop again: > > net.inet.tcp.sack.enable=0 > > without any panics. I've got another panic with current sources, in tcp_output.c The panic happens right after the system goes to multiuser, sometimes I have time to login, but it blows within a minute. Looking at the stack trace (taken from /var/log/messages, I have KDB_TRACE in my kernel) it seems like it panics multiple times. The panic is network-related, booting the system in single user mode without networking works like a charm, so I've done a back trace from the core file, which is attached. I still have the core file around, so I can get more information. Regards! //Niclas Here is a stack trace from the panic: Sleeping on "-" with the following non-sleepable locks held: exclusive sleep mutex tcp r = 0 (0xc07e90cc) locked @ /usr/src/sys/netinet/tcp_input.c:619 KDB: stack backtrace: db_trace_self_wrapper(c071d5f1,e409fc9c,c0580e33,c07e6fec,e409fcb0,...) at db_trace_self_wrapper+0x27 kdb_backtrace(c07e6fec,e409fcb0,1,0,c3badbd0,...) at kdb_backtrace+0x2f witness_warn(5,0,c071b75c,c070bd17,0,...) at witness_warn+0x1af msleep_spin(c3c46200,c3c4621c,c070bd17,0,1,...) at msleep_spin+0x1eb taskqueue_thread_loop(c3c4a214,e409fd38,c0717d8c,326,c3baf000,...) at taskqueue_thread_loop+0x8d fork_exit(c057b52a,c3c4a214,e409fd38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe409fd70, ebp = 0 --- kernel boot file is /boot/kernel/kernel Sleeping thread (tid 100035, pid 30) owns a non-sleepable lock sched_switch(c3badbd0,0,1,179,c079fdf8,...) at sched_switch+0x10a mi_switch(1,0,c071e040,1cc,0,...) at mi_switch+0x2d0 sleepq_switch(c3c46200,0,c071e040,21e,e409fcd4,...) at sleepq_switch+0x10d sleepq_wait(c3c46200,0,c071b75c,c070bd17,0,...) at sleepq_wait+0x66 msleep_spin(c3c46200,c3c4621c,c070bd17,0,1,...) at msleep_spin+0x20d taskqueue_thread_loop(c3c4a214,e409fd38,c0717d8c,326,c3baf000,...) at taskqueue_thread_loop+0x8d fork_exit(c057b52a,c3c4a214,e409fd38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe409fd70, ebp = 0 --- panic: sleeping thread KDB: stack backtrace: db_trace_self_wrapper(c071d5f1,e25cfb90,c054e887,c071b028,c079cae0,...) at db_trace_self_wrapper+0x27 kdb_backtrace(c071b028,c079cae0,c071e729,e25cfb9c,100,...) at kdb_backtrace+0x2f panic(c071e729,ffffffff,1e,ae,8,...) at panic+0xb8 propagate_priority(c3abe6c0,0,c071e6ca,287,c07a0380,...) at propagate_priority+0xe7 turnstile_wait(c07e90cc,c3badbd0,0,18b,c3badbd2,...) at turnstile_wait+0x499 _mtx_lock_sleep(c07e90cc,c3abe6c0,0,c072ad06,7f,...) at _mtx_lock_sleep+0x122 _mtx_lock_flags(c07e90cc,0,c072ad06,7f,e25cfc70,...) at _mtx_lock_flags+0xec tcp_slowtimo(c054429f,c079d0e4,1,c0719efe,0,...) at tcp_slowtimo+0x3b pfslowtimo(0,0,c071c0f5,ee,0,...) at pfslowtimo+0x52 softclock(0,c054429f,c079c8b0,1,c3aa66a0,...) at softclock+0x27b ithread_execute_handlers(c3abdb40,c3abb400,c0717f9c,30e,c3abe6c0,...) at ithread_execute_handlers+0x14c ithread_loop(c3aa66a0,e25cfd38,c0717d8c,326,c3abdb40,...) at ithread_loop+0x77 fork_exit(c0535d55,c3aa66a0,e25cfd38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe25cfd70, ebp = 0 --- KDB: enter: panic Physical memory: 1015 MB Dumping 97 MB: 82 66 50 34 18 2 --------------080305050202080106070600 Content-Type: text/plain; name="trace.out" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="trace.out" # kgdb /boot/kernel/kernel /var/crash/vmcore.2 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Sleeping thread (tid 100035, pid 30) owns a non-sleepable lock sched_switch(c3badbd0,0,1,179,c079fdf8,...) at sched_switch+0x10a mi_switch(1,0,c071e040,1cc,0,...) at mi_switch+0x2d0 sleepq_switch(c3c46200,0,c071e040,21e,e409fcd4,...) at sleepq_switch+0x10d sleepq_wait(c3c46200,0,c071b75c,c070bd17,0,...) at sleepq_wait+0x66 msleep_spin(c3c46200,c3c4621c,c070bd17,0,1,...) at msleep_spin+0x20d taskqueue_thread_loop(c3c4a214,e409fd38,c0717d8c,326,c3baf000,...) at taskqueue_thread_loop+0x8d fork_exit(c057b52a,c3c4a214,e409fd38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe409fd70, ebp = 0 --- panic: sleeping thread KDB: stack backtrace: db_trace_self_wrapper(c071d5f1,e25cfb90,c054e887,c071b028,c079cae0,...) at db_trace_self_wrapper+0x27 kdb_backtrace(c071b028,c079cae0,c071e729,e25cfb9c,100,...) at kdb_backtrace+0x2f panic(c071e729,ffffffff,1e,ae,8,...) at panic+0xb8 propagate_priority(c3abe6c0,0,c071e6ca,287,c07a0380,...) at propagate_priority+0xe7 turnstile_wait(c07e90cc,c3badbd0,0,18b,c3badbd2,...) at turnstile_wait+0x499 _mtx_lock_sleep(c07e90cc,c3abe6c0,0,c072ad06,7f,...) at _mtx_lock_sleep+0x122 _mtx_lock_flags(c07e90cc,0,c072ad06,7f,e25cfc70,...) at _mtx_lock_flags+0xec tcp_slowtimo(c054429f,c079d0e4,1,c0719efe,0,...) at tcp_slowtimo+0x3b pfslowtimo(0,0,c071c0f5,ee,0,...) at pfslowtimo+0x52 softclock(0,c054429f,c079c8b0,1,c3aa66a0,...) at softclock+0x27b ithread_execute_handlers(c3abdb40,c3abb400,c0717f9c,30e,c3abe6c0,...) at ithread_execute_handlers+0x14c ithread_loop(c3aa66a0,e25cfd38,c0717d8c,326,c3abdb40,...) at ithread_loop+0x77 fork_exit(c0535d55,c3aa66a0,e25cfd38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe25cfd70, ebp = 0 --- KDB: enter: panic Physical memory: 1015 MB Dumping 97 MB: 82 66 50 34 18 2 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc044b92d in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xe25cf980 " Wx�") at /usr/src/sys/ddb/db_command.c:486 #2 0xc044b6fc in db_command (last_cmdp=0xc0784e24, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #3 0xc044b7c3 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #4 0xc044d731 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #5 0xc05728f0 in kdb_trap (type=0, code=0, tf=0x0) at /usr/src/sys/kern/subr_kdb.c:502 #6 0xc06db633 in trap (frame=0xe25cfb1c) at /usr/src/sys/i386/i386/trap.c:621 #7 0xc06cb0db in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xc0572668 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc054e89d in panic (fmt=0xc071e729 "sleeping thread") at /usr/src/sys/kern/kern_shutdown.c:547 #10 0xc057c0b7 in propagate_priority (td=0xc3badbd0) at /usr/src/sys/kern/subr_turnstile.c:205 #11 0xc057d061 in turnstile_wait (lock=0xc07e90cc, owner=0xc3badbd0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:682 #12 0xc05444e5 in _mtx_lock_sleep (m=0xc07e90cc, tid=3282822848, opts=0, file=0x1
, line=1) at /usr/src/sys/kern/kern_mutex.c:411 #13 0xc0543f4c in _mtx_lock_flags (m=0xc07e90cc, opts=0, file=0xc072ad06 "/usr/src/sys/netinet/tcp_timer.c", line=127) ---Type to continue, or q to quit--- at /usr/src/sys/kern/kern_mutex.c:194 #14 0xc060884b in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:127 #15 0xc05996c5 in pfslowtimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:481 #16 0xc055e1e3 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:273 #17 0xc0535c88 in ithread_execute_handlers (p=0xc3abdb40, ie=0xc3abb400) at /usr/src/sys/kern/kern_intr.c:682 #18 0xc0535dcc in ithread_loop (arg=0xc3aa66a0) at /usr/src/sys/kern/kern_intr.c:766 #19 0xc05349ac in fork_exit (callout=0xc0535d55 , arg=0x12, frame=0x12) at /usr/src/sys/kern/kern_fork.c:814 #20 0xc06cb150 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) bt full #0 doadump () at pcpu.h:172 No locals. #1 0xc044b92d in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xe25cf980 " Wx�") at /usr/src/sys/ddb/db_command.c:486 fn_addr = -1068179472 args = {-1066111392, -497223348, -1065855328, -497223332, -1069239410, -1065855328, -1066111392, -497223300, -497223348, 0} nargs = 0 retval = -1011678976 t = 0 #2 0xc044b6fc in db_command (last_cmdp=0xc0784e24, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 cmd = (struct command *) 0xc0746e60 t = 0 modif = " Wx�\000\000\000\000\000�ッ W\177�`\213y�\r\000\000\000\001\000\000\000숟\\�1�L�\000\001냉\aK\004 �\213y잚q~� Wx픵\000\000\000 Wx�\034�\\循�\\詢�D�\204칝�\b�D�\000\000\000\000\020\000\000\000\034�\\� Wx잊�D� Wx잊Nx픵\000\000\000<�\\�" addr = 0 count = 1999 have_addr = 0 result = 0 #3 0xc044b7c3 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 No locals. ---Type to continue, or q to quit--- #4 0xc044d731 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 jb = {{_jb = {-497223108, -497223136, -497223056, 3, -497222884, -1069230384, -1066618544, -497222288, 18, 0, -497223056, -1068029843}}} prev_jb = (void *) 0x0 bkpt = 0 #5 0xc05728f0 in kdb_trap (type=0, code=0, tf=0x0) at /usr/src/sys/kern/subr_kdb.c:502 handled = 0 #6 0xc06db633 in trap (frame=0xe25cfb1c) at /usr/src/sys/i386/i386/trap.c:621 td = (struct thread *) 0xc3abe6c0 p = (struct proc *) 0xc3abdb40 i = 0 ucode = 0 type = 3 code = 0 addr = -1064743456 eva = 0 ksi = {ksi_link = {tqe_next = 0xc071ae56, tqe_prev = 0xe25cfaf0}, ksi_info = {si_signo = 0, si_errno = -1066291153, si_code = -1065760017, si_pid = -497222888, si_uid = 3797744372, si_status = -1069240794, si_addr = 0xe25cfb18, si_value = {sival_int = -1, sival_ptr = 0xffffffff}, _reason = {_fault = {_trapno = -497222940}, _timer = {_timerid = -497222940, _overrun = -1069230212}, _mesgq = { _mqd = -497222940}, _poll = {_band = -497222940}, __spare__ = { ---Type to continue, or q to quit--- __spare1__ = -497222940, __spare2__ = {-1069230212, -497222876, -497222892, -1066277079, 1, -497222892, -1066623191}}}}, ksi_flags = -1012144448, ksi_sigq = 0x0} #7 0xc06cb0db in calltrap () at /usr/src/sys/i386/i386/exception.s:139 No locals. #8 0xc0572668 in kdb_enter (msg=0x12
) at cpufunc.h:60 No locals. #9 0xc054e89d in panic (fmt=0xc071e729 "sleeping thread") at /usr/src/sys/kern/kern_shutdown.c:547 td = (struct thread *) 0xc3abe6c0 bootopt = 256 newpanic = 1 ap = 0xe25cfb9c "����\036" buf = "sleeping thread", '\0' #10 0xc057c0b7 in propagate_priority (td=0xc3badbd0) at /usr/src/sys/kern/subr_turnstile.c:205 tc = (struct turnstile_chain *) 0xc07e90cc ts = (struct turnstile *) 0xc3ab2d40 pri = 52 #11 0xc057d061 in turnstile_wait (lock=0xc07e90cc, owner=0xc3badbd0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:682 tc = (struct turnstile_chain *) 0xc07a0380 ts = (struct turnstile *) 0xc3ab2d40 ---Type to continue, or q to quit--- td = (struct thread *) 0xc3abe6c0 td1 = (struct thread *) 0xc07e90cc #12 0xc05444e5 in _mtx_lock_sleep (m=0xc07e90cc, tid=3282822848, opts=0, file=0x1
, line=1) at /usr/src/sys/kern/kern_mutex.c:411 v = 3238088704 #13 0xc0543f4c in _mtx_lock_flags (m=0xc07e90cc, opts=0, file=0xc072ad06 "/usr/src/sys/netinet/tcp_timer.c", line=127) at /usr/src/sys/kern/kern_mutex.c:194 No locals. #14 0xc060884b in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:127 No locals. #15 0xc05996c5 in pfslowtimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:481 dp = (struct domain *) 0xc076dde0 pr = (struct protosw *) 0xc076d9c8 #16 0xc055e1e3 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:273 c_func = (void (*)(void *)) 0xc0599673 c_arg = (void *) 0x0 c_mtx = (struct mtx *) 0x0 c_flags = 22 c = (struct callout *) 0xc1015000 bucket = (struct callout_tailq *) 0xd7b13170 curticks = 180004 ---Type to continue, or q to quit--- steps = 0 depth = 1 mpcalls = 1 mtxcalls = 0 gcalls = 0 #17 0xc0535c88 in ithread_execute_handlers (p=0xc3abdb40, ie=0xc3abb400) at /usr/src/sys/kern/kern_intr.c:682 ih = (struct intr_handler *) 0xc3ab9d00 ihn = (struct intr_handler *) 0xc3c58400 #18 0xc0535dcc in ithread_loop (arg=0xc3aa66a0) at /usr/src/sys/kern/kern_intr.c:766 ithd = (struct intr_thread *) 0xc3aa66a0 ie = (struct intr_event *) 0xc3abb400 td = (struct thread *) 0xc3abe6c0 p = (struct proc *) 0xc3abdb40 __func__ = "ithread_loop" #19 0xc05349ac in fork_exit (callout=0xc0535d55 , arg=0x12, frame=0x12) at /usr/src/sys/kern/kern_fork.c:814 p = (struct proc *) 0xc3abdb40 td = (struct thread *) 0x1 #20 0xc06cb150 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 No locals. (kgdb) q # --------------080305050202080106070600-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 18:56:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED94916A400; Sun, 25 Mar 2007 18:56:08 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a14.g.dreamhost.com (sd-green-bigip-66.dreamhost.com [208.97.132.66]) by mx1.freebsd.org (Postfix) with ESMTP id D1F8513C48C; Sun, 25 Mar 2007 18:56:08 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a14.g.dreamhost.com (Postfix) with ESMTP id 069B1190E26; Sun, 25 Mar 2007 11:56:07 -0700 (PDT) Message-ID: <4606C5C6.2060407@cyberwang.net> Date: Sun, 25 Mar 2007 14:56:06 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> In-Reply-To: <20070326012826.7bd36ac8.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 18:56:09 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 13:17:09 -0400 > Sean Bryant wrote: > [....] > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> That was it! Sorry. >>>>>> >>>>>> Ariff, ohci_add_done is on the actual panic line. that's how I >>>>>> >>>>>> >>>>> come > up with that. >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>> So where does the "loading snd_ich cause panic" fits in? Are you >>>>> saying that it is all about "kldload snd_ich" or panic during >>>>> boot? >>>>> >>>>> >>>>> >>>>> >>>> panic during boot. not when loading the kernel module: >>>> >>>> pcm0: port 0xdc00-0xdcff mem >>>> >>> 0xd5003000-0xd5003fff > irq 23 at device 4.0 on pci0 >>> >>>> pcm0: [ITHREAD] >>>> pcm0: cannot reset channel 0 >>>> pcm0: unable to initialize the card >>>> device_attach: pcm0 attach returned 6 >>>> >>>> >>>> that's what happens when I load the module after everything has >>>> started. snd_ich worked as of 3/06/07. I decided to give my >>>> >>> machine > an update and the panic is what happened. >>> >>>> >>>> >>> I'm suspecting something more generic. Virtually, nothing is >>> changed within snd_ich land within that timeframe, except few bug >>> fixes mostly during detach procedure. >>> >>> Besides, your panic source is from USB land, not snd_ich. >>> >>> >> That's what I suspected. So I just installed the latest HPS usb >> stack and it's the same. >> >> pcm0: port 0xdc00-0xdcff,0x4400-0x44ff mem >> 0xd5003000-0xd5003fff irq 23 at device 4.0 on pci0 >> pcm0: [ITHREAD] >> pcm0: cannot reset channel 0 >> pcm0: unable to initialize the card >> device_attach: pcm0 attach returned 6 >> >> > > Try this one: (sys/dev/sound/pci/ich.c) > > http://people.freebsd.org/~ariff/test/ich.c > > (no, this has nothing to do with the panic at all) > > >> With the latest HPS USB stack not sure if that's the same one in >> HEAD or not. >> Maybe something is conflicting or some other change has caused the >> resources to be tied up. That's a really rough guess with no >> evidence to support it. >> >> > > You should reproduce the panic, generate the dump, submit the > backtrace so things will become much clear for us. Will you? > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > Okay I disabled the remote debugging things to get a dump but it keeps saying no dump device defined. I explicitly set it to my swap device. and still the same result. any ideas? From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 19:37:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8227016A400; Sun, 25 Mar 2007 19:37:23 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D84C513C44C; Sun, 25 Mar 2007 19:37:22 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup96.ach.sch.gr [81.186.70.96]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PJakrV018556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2007 22:36:54 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PJadc0080079; Sun, 25 Mar 2007 22:36:40 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PJadXl080078; Sun, 25 Mar 2007 22:36:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 25 Mar 2007 22:36:39 +0300 From: Giorgos Keramidas To: Andrey Chernov , current@freebsd.org Message-ID: <20070325193639.GA79938@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> <20070325165843.GA1558@kobe.laptop> <20070325174747.GA52093@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070325174747.GA52093@nagual.pp.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.67, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 19:37:23 -0000 On 2007-03-25 21:47, Andrey Chernov wrote: > On Sun, Mar 25, 2007 at 07:58:43PM +0300, Giorgos Keramidas wrote: > > > > Disabling SACK lets me use my laptop again: > > > > net.inet.tcp.sack.enable=0 > > > > without any panics. > > I very suspect this commit (can't check right now for sure): > > tcp_sack.c > revision 1.35 > date: 2007/03/23 18:33:21; author: andre; state: Exp; lines: +1 -0 > Bring SACK option handling in tcp_dooptions() in line with all other > options and ajust users accordingly. Thanks, I'll revert this changeset locally and test :) From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 19:50:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EC5716A403 for ; Sun, 25 Mar 2007 19:50:28 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id DC03713C44B for ; Sun, 25 Mar 2007 19:50:27 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup96.ach.sch.gr [81.186.70.96]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PJnslV019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2007 22:50:05 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PJnljx087409; Sun, 25 Mar 2007 22:49:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PJnldN087408; Sun, 25 Mar 2007 22:49:47 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 25 Mar 2007 22:49:46 +0300 From: Giorgos Keramidas To: Nicolas Blais Message-ID: <20070325194946.GC79938@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> <20070325165843.GA1558@kobe.laptop> <200703251348.58972.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703251348.58972.nb_root@videotron.ca> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.673, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 19:50:28 -0000 On 2007-03-25 13:48, Nicolas Blais wrote: > > The panic happens after a small amount of network activity, inside > > the TCP SACK code: > > > > --------------------------------------------------------------------------- > > Disabling SACK lets me use my laptop again: > > > > net.inet.tcp.sack.enable=0 > > > > without any panics. > > Same here. If you want to quickly crash your system, > net.inet.tcp.sack.enable=1 and start a torrent :) > > I couldn't find what was causing my desktop to crash until I STOPPED > trying to restart my torrent after boot :) . Though > net.inet.tcp.sack.enable=0 fixed it. Rebuilding a kernel will take a while here. If you can try reverting the following commit before I do, let me know if it fixes the panic. % andre 2007-03-23 18:33:21 UTC % % FreeBSD src repository % % Modified files: % sys/netinet tcp_input.c tcp_sack.c % Log: % Bring SACK option handling in tcp_dooptions() in line with all other % options and ajust users accordingly. % % Revision Changes Path % 1.326 +7 -4 src/sys/netinet/tcp_input.c % 1.35 +1 -0 src/sys/netinet/tcp_sack.c From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 19:50:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D92716A401 for ; Sun, 25 Mar 2007 19:50:23 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE2813C455 for ; Sun, 25 Mar 2007 19:50:21 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 43A762AD5683; Sun, 25 Mar 2007 19:50:19 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 28634A0A44E; Sun, 25 Mar 2007 19:50:18 +0000 (UTC) In-Reply-To: <4606A3B2.9050005@samsco.org> References: <52299CBE-F3AD-439D-820D-3FC3458614F8@dragondata.com> <4600C451.2020407@samsco.org> <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> <4606A3B2.9050005@samsco.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevin Day Date: Sun, 25 Mar 2007 14:50:27 -0500 To: Scott Long X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Sun, 25 Mar 2007 19:51:14 +0000 Cc: freebsd-current@freebsd.org Subject: Re: aac & PAE not happy in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 19:50:23 -0000 On Mar 25, 2007, at 11:30 AM, Scott Long wrote: > Kevin Day wrote: >> Okay, after spending the better part of the weekend trying to >> figure out how to PXE boot the floppies that Dell gives you (using >> their own version of DOS), I've upgraded to the very latest system >> BIOS, controller firmware and kernel, and it's still requesting >> 128MB of memory. Nothing seems to have changed really. >> Any other suggestions? Booting into Linux seems to show that it's >> also eating 128MB of memory space there, so it's nothing FreeBSD >> is doing to cause this. >> Does your controller have the 128MB dimm for caching? I still >> can't see why they'd expose that to the host, but it's my only >> theory at the moment. > > Sorry for the confusion, it turns out that my math was wrong and my > machine is mapping all of the DIMM space as well, though it's not > 128MB. > Exposing the full DIMM size to the host is really just an act of > laziness on the part of the firmware engineers; it's convenient for > debugging the firmware and doing other development tasks, but it's not > useful for anything else. So, we're left with figuring out > workarounds. > I'm not sure if the driver can force less of the space to be mapped, > I'll look into that. The other workaround is to change > VM_KMEM_SIZE_MAX > in /sys/i386/include/vmparam.h to a larger value, but probably no more > than around 500. Okay, I tried: 400 - no difference 500 - Gets further into the boot, but runs out when it tries to exec init(?) 550 - aac0 complains "Not enough contiguous memory available", then the next PCI device that tries to run can't alloc anything 600 - back to what was happening at 400, aac0 can't alloc enough kernel virtual memory Any other suggestions? -- Kevin From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 20:20:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87AB216A404 for ; Sun, 25 Mar 2007 20:20:22 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECA413C44B for ; Sun, 25 Mar 2007 20:20:22 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.150.69]) by VL-MH-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JFH00DVD75XR600@VL-MH-MR002.ip.videotron.ca> for freebsd-current@freebsd.org; Sun, 25 Mar 2007 16:20:21 -0400 (EDT) Date: Sun, 25 Mar 2007 16:20:12 -0400 From: Nicolas Blais In-reply-to: <20070325194946.GC79938@kobe.laptop> To: freebsd-current@freebsd.org Message-id: <200703251620.20879.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart2282447.PsX8fNXYT7; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> User-Agent: KMail/1.9.6 Cc: Giorgos Keramidas Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 20:20:22 -0000 --nextPart2282447.PsX8fNXYT7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On March 25, 2007 03:49:46 pm Giorgos Keramidas wrote: > On 2007-03-25 13:48, Nicolas Blais wrote: > > > The panic happens after a small amount of network activity, inside > > > the TCP SACK code: > > > > > > ---------------------------------------------------------------------= =2D- > > >---- Disabling SACK lets me use my laptop again: > > > > > > net.inet.tcp.sack.enable=3D0 > > > > > > without any panics. > > > > Same here. If you want to quickly crash your system, > > net.inet.tcp.sack.enable=3D1 and start a torrent :) > > > > I couldn't find what was causing my desktop to crash until I STOPPED > > trying to restart my torrent after boot :) . Though > > net.inet.tcp.sack.enable=3D0 fixed it. > > Rebuilding a kernel will take a while here. If you can try reverting > the following commit before I do, let me know if it fixes the panic. > > % andre 2007-03-23 18:33:21 UTC > % > % FreeBSD src repository > % > % Modified files: > % sys/netinet tcp_input.c tcp_sack.c > % Log: > % Bring SACK option handling in tcp_dooptions() in line with all other > % options and ajust users accordingly. > % > % Revision Changes Path > % 1.326 +7 -4 src/sys/netinet/tcp_input.c > % 1.35 +1 -0 src/sys/netinet/tcp_sack.c Done.=20 I reverted tcp_input.c to 1.325 and tcp_sack.c to 1.34. I was able to start= =20 many torrents without a panic. I believe the revert fixed the problem, as=20 previously, just starting 1 torrent would panic (unless =20 net.inet.tcp.sack.enable=3D0) , now I have 5 running fine. Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #18: Sun Mar 25 16:03:50 EDT 2007 =20 nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://plaintext.clkroot.net/security/nb_root.asc --nextPart2282447.PsX8fNXYT7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGBtl84wTBlvcsbJURArGQAKCd86keT+l3InjnQxa3t5P4QAdaggCfa3le ZwTxaxWxkUQ+dFAJ2VpOIg8= =F4G+ -----END PGP SIGNATURE----- --nextPart2282447.PsX8fNXYT7-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 20:21:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 5747416A404; Sun, 25 Mar 2007 20:21:08 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Mon, 26 Mar 2007 04:20:40 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070326042040.37c66edb.ariff@FreeBSD.org> In-Reply-To: <4606C5C6.2060407@cyberwang.net> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> <4606C5C6.2060407@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__26_Mar_2007_04_20_40_+0800_2ynNs2T/WkcRfcBE" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 20:21:09 -0000 --Signature=_Mon__26_Mar_2007_04_20_40_+0800_2ynNs2T/WkcRfcBE Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 14:56:06 -0400 Sean Bryant wrote: > > > > Try this one: (sys/dev/sound/pci/ich.c) > > > > http://people.freebsd.org/~ariff/test/ich.c > > > > (no, this has nothing to do with the panic at all) > > > > =20 At least, you should tell me whether this fix your attach issue or not. > >> With the latest HPS USB stack not sure if that's the same one in > >> HEAD or not. > >> Maybe something is conflicting or some other change has caused > >the > resources to be tied up. That's a really rough guess with no > >> evidence to support it. > >> > >> =20 > > > > You should reproduce the panic, generate the dump, submit the > > backtrace so things will become much clear for us. Will you? > > > Okay I disabled the remote debugging things to get a dump but it > keeps saying no dump device defined. I explicitly set it to my swap > device. and still the same result. any ideas? >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__26_Mar_2007_04_20_40_+0800_2ynNs2T/WkcRfcBE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBtmYlr+deMUwTNoRAqNlAJ44HrmPo+haj/ZQ3HdYUC5EGkKT9wCgjX3g Da+hcY/ybCr4ounvQzTC+kg= =OFpE -----END PGP SIGNATURE----- --Signature=_Mon__26_Mar_2007_04_20_40_+0800_2ynNs2T/WkcRfcBE-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 20:36:20 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4921116A400 for ; Sun, 25 Mar 2007 20:36:20 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7104213C45D for ; Sun, 25 Mar 2007 20:36:18 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup96.ach.sch.gr [81.186.70.96]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PKYTB7022030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2007 23:34:41 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PKYEx3001461; Sun, 25 Mar 2007 23:34:22 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PKYDCk001460; Sun, 25 Mar 2007 23:34:13 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 25 Mar 2007 23:34:13 +0300 From: Giorgos Keramidas To: ariff@freebsd.org, current@freebsd.org Message-ID: <20070325203412.GA1396@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.095, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: snd_hda fails to probe after 15 March X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 20:36:20 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ariff and -current, Some time after March 15, snd_hda started failing to attach to pcm0 on my laptop. I haven't managed to nail the change down to a single commit yet, but I've attached the files: dmesg.boot-15 boot -v output of March 15 kernel dmesg.boot-25 boot -v output of March 25 kernel devinfo-15 devinfo -v output of March 15 kernel devinfo-25 devinfo -v output of March 25 kernel There seems to be at least one more message in dmesg.boot-25 which seems relevant to snd_hda failing to attach: pcm0: [MPSAFE] pcm0: [ITHREAD] +pcm0: hdac_get_capabilities: Invalid rirb size (0) +device_attach: pcm0 attach returned 6 pcib1: irq 17 at device 28.0 on pci0 If you need anything more to troubleshoot this, let me know :) - Giorgos --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot-15" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Thu Mar 15 05:04:56 EET 2007 build@kobe:/home/build/obj/home/build/src/sys/KOBE WARNING: WITNESS option enabled, expect reduced performance. Using 64 colors for the VM-PQ tuning (2048, 8) Preloaded elf kernel "/boot/kernel.safe/kernel" at 0xc09d6000. Preloaded elf module "/boot/kernel.safe/cpufreq.ko" at 0xc09d6250. Preloaded elf module "/boot/kernel.safe/snd_hda.ko" at 0xc09d6304. Preloaded elf module "/boot/kernel.safe/sound.ko" at 0xc09d63b8. Preloaded elf module "/boot/kernel.safe/acpi.ko" at 0xc09d6468. Table 'FACP' at 0x1f7a0068 Table 'SSDT' at 0x1f7a511c Table 'BOOT' at 0x1f7a0040 Table 'APIC' at 0x1f7a5cd4 MADT: Found table at 0x1f7a5cd4 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193175 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1828765103 Hz CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1828.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfe9fbff Features2=0xc1a9> Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 528089088 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001ee80fff, 505778176 bytes (123481 pages) avail memory = 507088896 (483 MB) INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f02b0 bios32: Entry = 0xfc229 (c00fc229) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xd27d pnpbios: Found PnP BIOS data at 0xc00f0960 pnpbios: Entry = f0000:9106 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 193df351 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> feeder_register: snd_unit=0 snd_maxautovchans=4 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 ath_rate: version 1.2 random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80001014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xccad6000 pa 0x9e000 ACPI timer: 1/1 1/1 1/1 1/1 0/817 1/1 1/1 1/1 1/1 1/1 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base 0xffd80000, size 19, enabled map[14]: type 4, range 32, base 0xcff8, size 3, enabled map[18]: type 3, range 32, base 0xe0000000, size 28, enabled map[1c]: type 1, range 32, base 0xffd40000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0, size 19, memory disabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base 0, size 14, memory disabled found-> vendor=0x8086, dev=0x27d0, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d4, revid=0x02 bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c8, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 0xcf80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 0xcf60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 0xcf40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 0xcf20, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xffd3fc00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c4, revid=0x02 bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xafa0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0xcff8-0xcfff mem 0xffd80000-0xffdfffff,0xe0000000-0xefffffff,0xffd40000-0xffd7ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffd80000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffd80000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xffd40000 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: at device 2.1 on pci0 pcm0: at device 27.0 on pci0 pcm0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0x80000000 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 pcm0: [MPSAFE] pcm0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xffc00000-0xffcfffff pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x8086, dev=0x4222, revid=0x02 bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 0xffcff000, size 12, enabled pcib2: requested memory range 0xffcff000-0xffcfffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 pci2: at device 0.0 (no driver attached) uhci0: port 0xcf80-0xcf9f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf80 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcf60-0xcf7f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf60 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcf40-0xcf5f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf40 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xcf20-0xcf3f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf20 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffd3fc00-0xffd3ffff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xffd3fc00 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xffa00000-0xffafffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x1092, revid=0x02 bus=3, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xffaff000, size 12, enabled pcib3: requested memory range 0xffaff000-0xffafffff: good map[14]: type 4, range 32, base 0xbf40, size 6, enabled pcib3: requested I/O range 0xbf40-0xbf7f: in range pcib3: matched entry for 3.8.INTA pcib3: slot 8 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8039, revid=0x00 bus=3, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x104c, dev=0x803a, revid=0x00 bus=3, slot=11, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 11, memory disabled map[14]: type 1, range 32, base 0, size 14, memory disabled found-> vendor=0x104c, dev=0x803b, revid=0x00 bus=3, slot=11, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=d, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x104c, dev=0x803c, revid=0x00 bus=3, slot=11, func=3 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=d, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 8, memory disabled fxp0: port 0xbf40-0xbf7f mem 0xffaff000-0xffafffff irq 20 at device 8.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xffaff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1092 1179 0001 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:0e:7b:77:8c:f0 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54 fxp0: [MPSAFE] fxp0: [ITHREAD] cbb0: at device 11.0 on pci3 pcib3: cbb0 requested memory range 0xffa00000-0xffafffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xffa00000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib3: matched entry for 3.11.INTA pcib3: slot 11 INTA hardwired to IRQ 21 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824008 0x10: 0xffa00000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400115 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x08009060 0x02130019 0x00070000 0x01aa1022 0x90: 0x606404c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e020001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x7ac8413a 0x90001500 0x00000000 0x00000000 fwohci0: vendor=104c, dev=803a fwohci0: vendor=104c, dev=803a fwohci0: <1394 Open Host Controller Interface> at device 11.1 on pci3 pcib3: fwohci0 requested memory range 0xffa00000-0xffafffff: good fwohci0: Lazy allocation of 0x800 bytes rid 0x10 type 3 at 0xffa01000 pcib3: matched entry for 3.11.INTB pcib3: slot 11 INTB hardwired to IRQ 20 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:39:00:00:ad:d6:2a fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:39:ad:d6:2a fwe0: bpf attached fwe0: Ethernet address: 02:00:39:ad:d6:2a fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci3: at device 11.2 (no driver attached) pci3: at device 11.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xafa0-0xafaf irq 19 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xafa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 57 ata1: [MPSAFE] ata1: [ITHREAD] acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 1 hz: 14318180 opts: leg_route count_size Timecounter "HPET" frequency 14318180 Hz quality 2000 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 60 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ums0: on uhub0 ums0: 3 buttons and Z dir. ugen0: on uhub1 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83125692 hz Timecounter "TSC" frequency 1828765103 Hz quality -100 Timecounters tick every 10.000 msec pfsync0: bpf attached lo0: bpf attached pflog0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire atapicam: atapicam0 already exists; skipping it ad0: 76319MB at ata0-master SATA150 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 battery0: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization done, tried 1 times ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: HDA_DEBUG: HDA Config: on=0x00000000 off=0x00000000 pcm0: HDA_DEBUG: Starting CORB Engine... pcm0: HDA_DEBUG: Starting RIRB Engine... pcm0: HDA_DEBUG: Enabling controller interrupt... pcm0: HDA_DEBUG: Scanning HDA codecs... pcm0: HDA_DEBUG: Probing codec: 0 pcm0: HDA_DEBUG: startnode=1 endnode=2 pcm0: HDA_DEBUG: Found AFG nid=1 [startnode=1 endnode=2] pcm0: HDA_DEBUG: Parsing AFG nid=1 cad=0 pcm0: Vendor: 0x000011d4 pcm0: Device: 0x00001981 pcm0: Revision: 0x00000002 pcm0: Stepping: 0x00000000 pcm0: PCI Subvendor: 0x00011179 pcm0: Nodes: start=2 endnode=32 total=30 pcm0: HDA_DEBUG: Parsing Ctls... pcm0: HDA_DEBUG: Parsing vendor patch... pcm0: HDA_DEBUG: Building AFG tree... pcm0: HDA_DEBUG: HWiP: HDA Widget Parser - Revision 1 pcm0: HDA_DEBUG: HWiP: Found 2 DAC path using HDA_PARSE_MIXER strategy. pcm0: HDA_DEBUG: AFG commit... pcm0: HDA_DEBUG: Ctls commit... pcm0: [ 1] Ctl nid=5 Bind to NONE pcm0: [ 2] Ctl nid=5 Bind to NONE pcm0: [ 3] Ctl nid=6 Bind to NONE pcm0: [ 4] Ctl nid=7 DISABLED pcm0: [ 5] Ctl nid=8 Bind to NONE pcm0: [ 6] Ctl nid=9 DISABLED pcm0: [ 7] Ctl nid=9 DISABLED pcm0: [11] Ctl nid=19 Bind to NONE pcm0: [13] Ctl nid=24 Bind to NONE pcm0: [14] Ctl nid=24 Bind to NONE pcm0: [15] Ctl nid=26 Bind to NONE pcm0: [16] Ctl nid=27 Bind to NONE pcm0: [18] Ctl nid=29 Bind to NONE pcm0: [19] Ctl nid=30 Bind to NONE pcm0: [20] Ctl nid=31 Bind to NONE pcm0: HDA_DEBUG: PCMDIR_PLAY setup... pcm0: HDA_DEBUG: PCMDIR_REC setup... pcm0: HDA_DEBUG: OSS mixer initialization... pcm0: HDA_DEBUG: Pin sense: nid=6 res=0x0000bfe7 pcm0: HDA_DEBUG: Enabling headphone/speaker audio routing switching: pcm0: HDA_DEBUG: index=4 nid=6 pci_subvendor=0x00011179 codec=0x11d41981 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: HDA_DEBUG: Registering PCM channels... pcm0: sndbuf_setmap 1e958000, 4000; 0xd4c70000 -> 1e958000 pcm0: sndbuf_setmap 1e954000, 4000; 0xd4c74000 -> 1e954000 pcm0: pcm0: pcm0: pcm0: pcm0: HDA config/quirks: forcestereo vref pcm0: pcm0: +-------------------+ pcm0: | DUMPING HDA NODES | pcm0: +-------------------+ pcm0: pcm0: Default Parameter pcm0: ----------------- pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e007f pcm0: PCM size: 16 20 24 pcm0: PCM rate: 8 11 16 22 32 44 48 pcm0: IN amp: 0x00270300 pcm0: OUT amp: 0x80053f3d pcm0: pcm0: nid: 2 [DIGITAL] [DISABLED] pcm0: name: audio output pcm0: widget_cap: 0x00030311 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Stream cap: 0x00000005 pcm0: Format: AC3 PCM pcm0: PCM cap: 0x00020060 pcm0: PCM size: 16 pcm0: PCM rate: 44 48 pcm0: connections: 2 pcm0: | pcm0: + <- nid=1 [GHOST!] [UNKNOWN] pcm0: | pcm0: + <- nid=4 [audio input] pcm0: pcm0: nid: 3 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000441 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e007f pcm0: PCM size: 16 20 24 pcm0: PCM rate: 8 11 16 22 32 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 4 [ANALOG] pcm0: name: audio input pcm0: widget_cap: 0x00100511 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000800 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x0006007f pcm0: PCM size: 16 20 pcm0: PCM rate: 8 11 16 22 32 44 48 pcm0: connections: 1 pcm0: | pcm0: + <- nid=21 [audio selector] pcm0: pcm0: nid: 5 [ANALOG] pcm0: name: pin: speaker (fixed) pcm0: widget_cap: 0x00400187 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0001173f pcm0: ISC TRQD HP OUT IN VREF[ 50 80 GROUND HIZ ] EAPD : UNSOL pcm0: Pin config: 0x90170110 pcm0: Pin control: 0x00000040 OUT pcm0: EAPD: 0x00000002 pcm0: Output amp: 0x80053f3d pcm0: mute=1 step=63 size=5 offset=61 pcm0: Input amp: 0x00270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: | pcm0: + <- nid=14 [audio mixer] (selected) pcm0: pcm0: nid: 6 [ANALOG] pcm0: name: pin: headphones out (jack) pcm0: widget_cap: 0x00400185 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000001f pcm0: ISC TRQD HP OUT : UNSOL pcm0: Pin config: 0x0221101f pcm0: Pin control: 0x000000c0 HP OUT pcm0: Output amp: 0x80053f3d pcm0: mute=1 step=63 size=5 offset=61 pcm0: connections: 2 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: | pcm0: + <- nid=14 [audio mixer] (selected) pcm0: pcm0: nid: 7 [ANALOG] [DISABLED] pcm0: name: pin: other (none) pcm0: widget_cap: 0x00400104 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000010 pcm0: OUT pcm0: Pin config: 0x40f000fe pcm0: Pin control: 0x00000040 OUT pcm0: Output amp: 0x80053f3d pcm0: mute=1 step=63 size=5 offset=61 pcm0: connections: 1 pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: pcm0: nid: 8 [ANALOG] pcm0: name: pin: Mic in (jack) pcm0: widget_cap: 0x00400083 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Pin cap: 0x00001727 pcm0: ISC TRQD IN VREF[ 50 80 GROUND HIZ ] : UNSOL pcm0: Pin config: 0x02a11020 pcm0: Pin control: 0x00000024 IN pcm0: Input amp: 0x00270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 0 pcm0: pcm0: nid: 9 [ANALOG] [DISABLED] pcm0: name: pin: other (none) pcm0: widget_cap: 0x00400187 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00001737 pcm0: ISC TRQD OUT IN VREF[ 50 80 GROUND HIZ ] : UNSOL pcm0: Pin config: 0x40f000fd pcm0: Pin control: 0x00000060 IN OUT pcm0: Output amp: 0x80053f3d pcm0: mute=1 step=63 size=5 offset=61 pcm0: Input amp: 0x00270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: pcm0: nid: 10 [DIGITAL] [DISABLED] pcm0: name: pin: other (none) pcm0: widget_cap: 0x00400301 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000010 pcm0: OUT pcm0: Pin config: 0x40f000fc pcm0: Pin control: 0x00000040 OUT pcm0: connections: 1 pcm0: | pcm0: + <- nid=2 [audio output] [DISABLED] pcm0: pcm0: nid: 11 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x00300101 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000000 pcm0: connections: 6 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=9 [pin: other (none)] [DISABLED] pcm0: | pcm0: + <- nid=14 [audio mixer] (selected) pcm0: | pcm0: + <- nid=5 [pin: speaker (fixed)] pcm0: | pcm0: + <- nid=24 [pin: Mic in (fixed)] pcm0: pcm0: nid: 12 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x00200101 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000000 pcm0: connections: 2 pcm0: | pcm0: + <- nid=30 [audio selector] pcm0: | pcm0: + <- nid=31 [audio selector] pcm0: pcm0: nid: 13 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010c pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000021 pcm0: Output amp: 0x800b0f0f pcm0: mute=1 step=15 size=11 offset=15 pcm0: connections: 2 pcm0: | pcm0: + <- nid=16 [beep widget] (selected) pcm0: | pcm0: + <- nid=22 [pin: other (fixed)] pcm0: pcm0: nid: 14 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x00200101 pcm0: Parse flags: 0x00000003 pcm0: Ctl flags: 0x000000b1 pcm0: connections: 8 pcm0: | pcm0: + <- nid=13 [audio selector] pcm0: | pcm0: + <- nid=17 [audio selector] pcm0: | pcm0: + <- nid=18 [audio selector] pcm0: | pcm0: + <- nid=19 [audio selector] pcm0: | pcm0: + <- nid=26 [audio selector] pcm0: | pcm0: + <- nid=27 [audio selector] pcm0: | pcm0: + <- nid=28 [audio selector] pcm0: | pcm0: + <- nid=29 [audio selector] pcm0: pcm0: nid: 15 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x00200100 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000000 pcm0: connections: 1 pcm0: | pcm0: + <- nid=11 [audio selector] pcm0: pcm0: nid: 16 [ANALOG] pcm0: name: beep widget pcm0: widget_cap: 0x00700000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000021 pcm0: connections: 0 pcm0: pcm0: nid: 17 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: pcm0: nid: 18 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=8 [pin: Mic in (jack)] pcm0: pcm0: nid: 19 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=9 [pin: other (none)] [DISABLED] pcm0: pcm0: nid: 20 [ANALOG] pcm0: name: power widget pcm0: widget_cap: 0x00500500 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 6 pcm0: | pcm0: + <- nid=13 [audio selector] (selected) pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=144 [GHOST!] [UNKNOWN] pcm0: | pcm0: + <- nid=19 [audio selector] pcm0: | pcm0: + <- nid=154 [GHOST!] [UNKNOWN] pcm0: | pcm0: + <- nid=29 [audio selector] pcm0: pcm0: nid: 21 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000006 pcm0: Ctl flags: 0x00000800 pcm0: Output amp: 0x80050f00 pcm0: mute=1 step=15 size=5 offset=0 pcm0: connections: 8 pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=9 [pin: other (none)] [DISABLED] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=25 [pin: other (none)] [DISABLED] pcm0: | pcm0: + <- nid=5 [pin: speaker (fixed)] pcm0: | pcm0: + <- nid=24 [pin: Mic in (fixed)] (selected) pcm0: | pcm0: + <- nid=23 [pin: other (none)] [DISABLED] pcm0: pcm0: nid: 22 [ANALOG] pcm0: name: pin: other (fixed) pcm0: widget_cap: 0x00400000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000020 pcm0: IN pcm0: Pin config: 0x90f70150 pcm0: Pin control: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 23 [ANALOG] [DISABLED] pcm0: name: pin: other (none) pcm0: widget_cap: 0x00400081 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000027 pcm0: ISC TRQD IN : UNSOL pcm0: Pin config: 0x40f000fb pcm0: Pin control: 0x00000020 IN pcm0: connections: 0 pcm0: pcm0: nid: 24 [ANALOG] pcm0: name: pin: Mic in (fixed) pcm0: widget_cap: 0x00400187 pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Pin cap: 0x00001737 pcm0: ISC TRQD OUT IN VREF[ 50 80 GROUND HIZ ] : UNSOL pcm0: Pin config: 0x92a7012e pcm0: Pin control: 0x00000024 IN pcm0: Output amp: 0x80053f3d pcm0: mute=1 step=63 size=5 offset=61 pcm0: Input amp: 0x00270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=3 [audio output] (selected) pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: pcm0: nid: 25 [ANALOG] [DISABLED] pcm0: name: pin: other (none) pcm0: widget_cap: 0x00400001 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000020 pcm0: IN pcm0: Pin config: 0x40f000fa pcm0: Pin control: 0x00000020 IN pcm0: connections: 0 pcm0: pcm0: nid: 26 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=5 [pin: speaker (fixed)] pcm0: pcm0: nid: 27 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=23 [pin: other (none)] [DISABLED] pcm0: pcm0: nid: 28 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=24 [pin: Mic in (fixed)] pcm0: pcm0: nid: 29 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 1 pcm0: | pcm0: + <- nid=25 [pin: other (none)] [DISABLED] pcm0: pcm0: nid: 30 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 1 pcm0: | pcm0: + <- nid=8 [pin: Mic in (jack)] pcm0: pcm0: nid: 31 [ANALOG] pcm0: name: audio selector pcm0: widget_cap: 0x0030010d pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 1 pcm0: | pcm0: + <- nid=24 [pin: Mic in (fixed)] pcm0: pcm0: +------------------------+ pcm0: | DUMPING HDA AMPLIFIERS | pcm0: +------------------------+ pcm0: pcm0: 1: nid=5 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 2: nid=5 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 3: nid=6 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 4: nid=7 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 5: nid=8 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 6: nid=9 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 7: nid=9 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 8: nid=13 dir=0x1 index=0 ossmask=0x00000021 ossdev=5 pcm0: 9: nid=17 dir=0x1 index=0 ossmask=0x00000011 ossdev=4 pcm0: 10: nid=18 dir=0x1 index=0 ossmask=0x00000081 ossdev=7 pcm0: 11: nid=19 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 12: nid=21 dir=0x1 index=0 ossmask=0x00000800 ossdev=0 pcm0: 13: nid=24 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 14: nid=24 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 15: nid=26 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 16: nid=27 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 17: nid=28 dir=0x1 index=0 ossmask=0x00000081 ossdev=7 pcm0: 18: nid=29 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 19: nid=30 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 20: nid=31 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: pcm0: +-----------------------------------+ pcm0: | DUMPING HDA AUDIO/VOLUME CONTROLS | pcm0: +-----------------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- nid: 13 index: 0 mute: 1 step: 15 size: 11 off: 15 dir=0x1 ossmask=0x00000021 pcm0: | pcm0: +- nid: 17 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000011 pcm0: | pcm0: +- nid: 18 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000081 pcm0: | pcm0: +- nid: 28 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000081 pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- nid: 17 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000011 pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- nid: 18 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000081 pcm0: | pcm0: +- nid: 28 index: 0 mute: 1 step: 31 size: 5 off: 23 dir=0x1 ossmask=0x00000081 pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- nid: 21 index: 0 mute: 1 step: 15 size: 5 off: 0 dir=0x1 ossmask=0x00000800 pcm0: pcm0: Speaker/Beep (OSS: speaker) pcm0: | pcm0: +- nid: 13 index: 0 mute: 1 step: 15 size: 11 off: 15 dir=0x1 ossmask=0x00000021 pcm0: pcm0: Playback path: pcm0: pcm0: nid=5 [pin: speaker (fixed)] pcm0: ^ pcm0: | pcm0: +-----<------+ pcm0: ^ pcm0: | pcm0: nid=14 [audio mixer] pcm0: ^ pcm0: | pcm0: nid=17 [audio selector] pcm0: ^ pcm0: | pcm0: nid=3 [audio output] pcm0: pcm0: nid=6 [pin: headphones out (jack)] pcm0: ^ pcm0: | pcm0: +-----<------+ pcm0: ^ pcm0: | pcm0: nid=14 [audio mixer] pcm0: ^ pcm0: | pcm0: nid=17 [audio selector] pcm0: ^ pcm0: | pcm0: nid=3 [audio output] pcm0: pcm0: Recording sources: pcm0: pcm0: nid=21 [audio selector] pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] [recsrc: vol, pcm, speaker, mic] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=5 [pin: speaker (fixed)] pcm0: | pcm0: + <- nid=24 [pin: Mic in (fixed)] [recsrc: vol, mic] pcm0: pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: PCM Playback: 1 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e007f pcm0: PCM size: 16 20 24 pcm0: PCM rate: 8 11 16 22 32 44 48 pcm0: DAC: 3 pcm0: pcm0: PCM Record: 1 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x0006007f pcm0: PCM size: 16 20 pcm0: PCM rate: 8 11 16 22 32 44 48 pcm0: ADC: 4 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot-25" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Sun Mar 25 22:10:32 EEST 2007 build@kobe:/home/build/obj/home/build/src/sys/KOBE WARNING: WITNESS option enabled, expect reduced performance. Using 64 colors for the VM-PQ tuning (2048, 8) Preloaded elf kernel "/boot/kernel/kernel" at 0xc09d7000. Preloaded elf module "/boot/kernel/snd_hda.ko" at 0xc09d7248. Preloaded elf module "/boot/kernel/sound.ko" at 0xc09d72f4. Preloaded elf module "/boot/kernel/cpufreq.ko" at 0xc09d73a0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc09d744c. Calibrating clock(s) ... i8254 clock: 1193178 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1828761143 Hz CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1828.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfe9fbff Features2=0xc1a9> Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 528089088 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001ee80fff, 505778176 bytes (123481 pages) avail memory = 507105280 (483 MB) Table 'FACP' at 0x1f7a0068 Table 'SSDT' at 0x1f7a511c Table 'BOOT' at 0x1f7a0040 Table 'APIC' at 0x1f7a5cd4 MADT: Found table at 0x1f7a5cd4 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f02b0 bios32: Entry = 0xfc229 (c00fc229) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xd27d pnpbios: Found PnP BIOS data at 0xc00f0960 pnpbios: Entry = f0000:9106 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 193df351 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ACPI: RSDP @ 0x0xf01e0/0x0014 (v 0 TOSHIB) ACPI: RSDT @ 0x0x1f7a0000/0x003C (v 1 TOSHIB 750 0x00970814 TASM 0x04010000) ACPI: FACP @ 0x0x1f7a0068/0x0084 (v 2 TOSHIB 750 0x20030101 TASM 0x04010000) ACPI: DSDT @ 0x0x1f7a00ec/0x5030 (v 1 TOSHIB A0044 0x20060301 MSFT 0x0100000E) ACPI: FACS @ 0x0xeee00/0x0040 ACPI: SSDT @ 0x0x1f7a511c/0x0306 (v 1 TOSHIB A0044 0x20050926 MSFT 0x0100000E) ACPI: BOOT @ 0x0x1f7a0040/0x0028 (v 1 TOSHIB 750 0x00970814 TASM 0x04010000) ACPI: APIC @ 0x0x1f7a5cd4/0x0068 (v 1 TOSHIB 750 0x00970814 TASM 0x04010000) ACPI: MCFG @ 0x0x1f7a5d3c/0x003C (v 1 TOSHIB 750 0x00970814 TASM 0x04010000) ACPI: HPET @ 0x0x1f7a5dac/0x0038 (v 1 TOSHIB 750 0x00970814 TASM 0x04010000) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 feeder_register: snd_unit=0 snd_maxautovchans=4 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xccad6000 pa 0x9e000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80001014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1f6a0000 (3) failed ACPI timer: 1/2 1/1 1/2 0/805 1/1 1/1 1/1 1/1 1/1 1/1 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 Validation 0 11 N 0 3 4 5 6 7 11 After Disable 0 255 N 0 3 4 5 6 7 11 cpu0: on acpi0 ACPI: SSDT @ 0x0x1f7a5764/0x00F3 (v 1 TOSHIB A0044 0x20050623 MSFT 0x0100000E) ACPI: SSDT @ 0x0x1f7a58cd/0x034E (v 1 TOSHIB A0044 0x20050916 MSFT 0x0100000E) est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x1f7a5857/0x0076 (v 1 TOSHIB A0044 0x20050623 MSFT 0x0100000E) ACPI: SSDT @ 0x0x1f7a5c1b/0x0079 (v 1 TOSHIB A0044 0x20050916 MSFT 0x0100000E) est1: on cpu1 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base 0xffd80000, size 19, enabled map[14]: type 4, range 32, base 0xcff8, size 3, enabled map[18]: type 3, range 32, base 0xe0000000, size 28, enabled map[1c]: type 1, range 32, base 0xffd40000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0, size 19, memory disabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base 0, size 14, memory disabled found-> vendor=0x8086, dev=0x27d0, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d4, revid=0x02 bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c8, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 0xcf80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 0xcf60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 0xcf40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 0xcf20, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xffd3fc00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c4, revid=0x02 bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xafa0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0xcff8-0xcfff mem 0xffd80000-0xffdfffff,0xe0000000-0xefffffff,0xffd40000-0xffd7ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffd80000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xffd80000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xffd40000 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: at device 2.1 on pci0 pcm0: at device 27.0 on pci0 pcm0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xf0000000 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: hdac_get_capabilities: Invalid rirb size (0) device_attach: pcm0 attach returned 6 pcib1: irq 17 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xffc00000-0xffcfffff pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x8086, dev=0x4222, revid=0x02 bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 0xffcff000, size 12, enabled pcib2: requested memory range 0xffcff000-0xffcfffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 pci2: at device 0.0 (no driver attached) uhci0: port 0xcf80-0xcf9f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf80 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcf60-0xcf7f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf60 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcf40-0xcf5f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf40 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xcf20-0xcf3f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcf20 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffd3fc00-0xffd3ffff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xffd3fc00 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xffa00000-0xffafffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x1092, revid=0x02 bus=3, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xffaff000, size 12, enabled pcib3: requested memory range 0xffaff000-0xffafffff: good map[14]: type 4, range 32, base 0xbf40, size 6, enabled pcib3: requested I/O range 0xbf40-0xbf7f: in range pcib3: matched entry for 3.8.INTA pcib3: slot 8 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8039, revid=0x00 bus=3, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x104c, dev=0x803a, revid=0x00 bus=3, slot=11, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 11, memory disabled map[14]: type 1, range 32, base 0, size 14, memory disabled found-> vendor=0x104c, dev=0x803b, revid=0x00 bus=3, slot=11, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=d, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x104c, dev=0x803c, revid=0x00 bus=3, slot=11, func=3 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=d, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 8, memory disabled fxp0: port 0xbf40-0xbf7f mem 0xffaff000-0xffafffff irq 20 at device 8.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xffaff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1092 1179 0001 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:0e:7b:77:8c:f0 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54 fxp0: [MPSAFE] fxp0: [ITHREAD] cbb0: at device 11.0 on pci3 pcib3: cbb0 requested memory range 0xffa00000-0xffafffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xffa00000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib3: matched entry for 3.11.INTA pcib3: slot 11 INTA hardwired to IRQ 21 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824008 0x10: 0xffa00000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400115 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x08009060 0x02130019 0x00070000 0x01aa1022 0x90: 0x606404c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e020001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x7ac8413a 0x90001500 0x00000000 0x00000000 fwohci0: vendor=104c, dev=803a fwohci0: vendor=104c, dev=803a fwohci0: <1394 Open Host Controller Interface> at device 11.1 on pci3 pcib3: fwohci0 requested memory range 0xffa00000-0xffafffff: good fwohci0: Lazy allocation of 0x800 bytes rid 0x10 type 3 at 0xffa01000 pcib3: matched entry for 3.11.INTB pcib3: slot 11 INTB hardwired to IRQ 20 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:39:00:00:ad:d6:2a fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:39:ad:d6:2a fwe0: bpf attached fwe0: Ethernet address: 02:00:39:ad:d6:2a fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci3: at device 11.2 (no driver attached) pci3: at device 11.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xafa0-0xafaf irq 19 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xafa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 57 ata1: [MPSAFE] ata1: [ITHREAD] acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 1 hz: 14318180 opts: leg_route count_size Timecounter "HPET" frequency 14318180 Hz quality 2000 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 60 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8e01 0x8e01 0x8e01 0x8e01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ums0: on uhub0 ums0: 3 buttons and Z dir. ugen0: on uhub1 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83125518 hz Timecounter "TSC" frequency 1828761143 Hz quality -100 Timecounters tick every 10.000 msec pflog0: bpf attached pfsync0: bpf attached lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire atapicam: atapicam0 already exists; skipping it ad0: 76319MB at ata0-master SATA150 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 battery0: battery initialization start acpi_acad0: acline initialization start battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=devinfo-15 nexus0 legacy0 npx0 acpi0 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 est0 p4tcc0 acpi_perf0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 est1 p4tcc1 acpi_perf1 cpufreq1 pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.EXPL pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x27a0 subvendor=0x1179 subdevice=0x0001 class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x27a2 subvendor=0x1179 subdevice=0x0003 class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.VGA_ agp0 drm0 vgapci1 pnpinfo vendor=0x8086 device=0x27a6 subvendor=0x1179 subdevice=0x0003 class=0x038000 at slot=2 function=1 drm1 pcm0 pnpinfo vendor=0x8086 device=0x27d8 subvendor=0x1179 subdevice=0x0001 class=0x040300 at slot=27 function=0 handle=\_SB_.PCI0.AZAL unknown pcib1 pnpinfo vendor=0x8086 device=0x27d0 subvendor=0x1179 subdevice=0x0001 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.PEX1 pci1 pcib2 pnpinfo vendor=0x8086 device=0x27d4 subvendor=0x1179 subdevice=0x0001 class=0x060400 at slot=28 function=2 handle=\_SB_.PCI0.MPEX pci2 unknown pnpinfo vendor=0x8086 device=0x4222 subvendor=0x8086 subdevice=0x1041 class=0x028000 at slot=0 function=0 handle=\_SB_.PCI0.MPEX.WLAN uhci0 pnpinfo vendor=0x8086 device=0x27c8 subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 usb0 uhub0 ums0 pnpinfo vendor=0x0458 product=0x0036 devclass=0x00 devsubclass=0x00 release=0x0110 sernum="" intclass=0x03 intsubclass=0x01 at port=0 interface=0 uhci1 pnpinfo vendor=0x8086 device=0x27c9 subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 usb1 uhub1 ugen0 pnpinfo vendor=0x0483 product=0x2016 devclass=0x00 devsubclass=0x00 release=0x0001 sernum="" at port=0 uhci2 pnpinfo vendor=0x8086 device=0x27ca subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.USB3 usb2 uhub2 uhci3 pnpinfo vendor=0x8086 device=0x27cb subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=3 handle=\_SB_.PCI0.USB4 usb3 uhub3 ehci0 pnpinfo vendor=0x8086 device=0x27cc subvendor=0x1179 subdevice=0x0001 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EHCI usb4 uhub4 pcib3 pnpinfo vendor=0x8086 device=0x2448 subvendor=0x1179 subdevice=0x0001 class=0x060401 at slot=30 function=0 handle=\_SB_.PCI0.PCIB pci3 fxp0 pnpinfo vendor=0x8086 device=0x1092 subvendor=0x1179 subdevice=0x0001 class=0x020000 at slot=8 function=0 handle=\_SB_.PCI0.PCIB.LAN_ miibus0 inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1 cbb0 pnpinfo vendor=0x104c device=0x8039 subvendor=0x1179 subdevice=0x0001 class=0x060700 at slot=11 function=0 handle=\_SB_.PCI0.PCIB.CRD0 cardbus0 pccard0 fwohci0 pnpinfo vendor=0x104c device=0x803a subvendor=0x1179 subdevice=0x0001 class=0x0c0010 at slot=11 function=1 handle=\_SB_.PCI0.PCIB.IEEE firewire0 sbp0 fwe0 unknown pnpinfo vendor=0x104c device=0x803b subvendor=0x1179 subdevice=0x0001 class=0x018000 at slot=11 function=2 unknown pnpinfo vendor=0x104c device=0x803c subvendor=0x1179 subdevice=0x0001 class=0x080501 at slot=11 function=3 handle=\_SB_.PCI0.PCIB.SDC_ isab0 pnpinfo vendor=0x8086 device=0x27b9 subvendor=0x1179 subdevice=0x0001 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.FNC0 isa0 pmtimer0 sc0 vga0 adv0 aha0 aic0 bt0 cs0 ed0 fdc0 fe0 ie0 le0 ppc0 sio0 sio1 sio2 sio3 sn0 vt0 orm0 pnpinfo pnpid=ORM0000 atapci0 pnpinfo vendor=0x8086 device=0x27c4 subvendor=0x1179 subdevice=0x0001 class=0x010180 at slot=31 function=2 handle=\_SB_.PCI0.FNC2 ata0 ad0 subdisk0 atapicam0 ata1 acd0 atapicam1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.FNC0.DMAC atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.FNC0.PIC_ attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.FNC0.PIT_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.FNC0.SPKR npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.FNC0.NDP_ atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.FNC0.KBC_ atkbd0 psm0 psmcpnp0 pnpinfo _HID=PNP0F13 _UID=0 at handle=\_SB_.PCI0.FNC0.PS2M attimer1 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.FNC0.RTC_ acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.FNC0.SYSR unknown pnpinfo _HID=IFX0102 _UID=0 at handle=\_SB_.PCI0.FNC0.TPM_ acpi_hpet0 pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.FNC0.HPET unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE0.HD_0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE1.ODD1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.VGA_.LCD_ unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.VGA_.CRT_ unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB1.HUB1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB2.HUB2 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB3.HUB3 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB4.HUB4 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.EHCI.HUB0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX1.GLAN unknown pnpinfo _HID=TOS6205 _UID=0 at handle=\_SB_.BT__ acpi_lid0 pnpinfo _HID=PNP0C0D _UID=0 at handle=\_SB_.LID_ battery0 pnpinfo _HID=PNP0C0A _UID=1 at handle=\_SB_.BAT1 acpi_button0 pnpinfo _HID=PNP0C0C _UID=0 at handle=\_SB_.PWRB acpi_acad0 pnpinfo _HID=ACPI0003 _UID=0 at handle=\_SB_.ADP1 unknown pnpinfo _HID=TOS6208 _UID=0 at handle=\_SB_.VALZ unknown pnpinfo _HID=TOS620A _UID=0 at handle=\_SB_.HAPS acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THRM acpi_timer0 pnpinfo unknown at unknown --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=devinfo-25 nexus0 apic0 legacy0 ram0 npx0 acpi0 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 est0 p4tcc0 acpi_perf0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 est1 p4tcc1 acpi_perf1 cpufreq1 pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.EXPL pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x27a0 subvendor=0x1179 subdevice=0x0001 class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x27a2 subvendor=0x1179 subdevice=0x0003 class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.VGA_ agp0 drm0 vgapci1 pnpinfo vendor=0x8086 device=0x27a6 subvendor=0x1179 subdevice=0x0003 class=0x038000 at slot=2 function=1 drm1 pcm0 pnpinfo vendor=0x8086 device=0x27d8 subvendor=0x1179 subdevice=0x0001 class=0x040300 at slot=27 function=0 handle=\_SB_.PCI0.AZAL pcib1 pnpinfo vendor=0x8086 device=0x27d0 subvendor=0x1179 subdevice=0x0001 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.PEX1 pci1 pcib2 pnpinfo vendor=0x8086 device=0x27d4 subvendor=0x1179 subdevice=0x0001 class=0x060400 at slot=28 function=2 handle=\_SB_.PCI0.MPEX pci2 unknown pnpinfo vendor=0x8086 device=0x4222 subvendor=0x8086 subdevice=0x1041 class=0x028000 at slot=0 function=0 handle=\_SB_.PCI0.MPEX.WLAN uhci0 pnpinfo vendor=0x8086 device=0x27c8 subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 usb0 uhub0 ums0 pnpinfo vendor=0x0458 product=0x0036 devclass=0x00 devsubclass=0x00 release=0x0110 sernum="" intclass=0x03 intsubclass=0x01 at port=0 interface=0 uhci1 pnpinfo vendor=0x8086 device=0x27c9 subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 usb1 uhub1 ugen0 pnpinfo vendor=0x0483 product=0x2016 devclass=0x00 devsubclass=0x00 release=0x0001 sernum="" at port=0 uhci2 pnpinfo vendor=0x8086 device=0x27ca subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.USB3 usb2 uhub2 uhci3 pnpinfo vendor=0x8086 device=0x27cb subvendor=0x1179 subdevice=0x0001 class=0x0c0300 at slot=29 function=3 handle=\_SB_.PCI0.USB4 usb3 uhub3 ehci0 pnpinfo vendor=0x8086 device=0x27cc subvendor=0x1179 subdevice=0x0001 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EHCI usb4 uhub4 pcib3 pnpinfo vendor=0x8086 device=0x2448 subvendor=0x1179 subdevice=0x0001 class=0x060401 at slot=30 function=0 handle=\_SB_.PCI0.PCIB pci3 fxp0 pnpinfo vendor=0x8086 device=0x1092 subvendor=0x1179 subdevice=0x0001 class=0x020000 at slot=8 function=0 handle=\_SB_.PCI0.PCIB.LAN_ miibus0 inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1 cbb0 pnpinfo vendor=0x104c device=0x8039 subvendor=0x1179 subdevice=0x0001 class=0x060700 at slot=11 function=0 handle=\_SB_.PCI0.PCIB.CRD0 cardbus0 pccard0 fwohci0 pnpinfo vendor=0x104c device=0x803a subvendor=0x1179 subdevice=0x0001 class=0x0c0010 at slot=11 function=1 handle=\_SB_.PCI0.PCIB.IEEE firewire0 sbp0 fwe0 unknown pnpinfo vendor=0x104c device=0x803b subvendor=0x1179 subdevice=0x0001 class=0x018000 at slot=11 function=2 unknown pnpinfo vendor=0x104c device=0x803c subvendor=0x1179 subdevice=0x0001 class=0x080501 at slot=11 function=3 handle=\_SB_.PCI0.PCIB.SDC_ isab0 pnpinfo vendor=0x8086 device=0x27b9 subvendor=0x1179 subdevice=0x0001 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.FNC0 isa0 pmtimer0 sc0 vga0 adv0 aha0 aic0 bt0 cs0 ed0 fdc0 fe0 ie0 le0 ppc0 sio0 sio1 sio2 sio3 sn0 vt0 orm0 pnpinfo pnpid=ORM0000 atapci0 pnpinfo vendor=0x8086 device=0x27c4 subvendor=0x1179 subdevice=0x0001 class=0x010180 at slot=31 function=2 handle=\_SB_.PCI0.FNC2 ata0 ad0 subdisk0 atapicam0 ata1 acd0 atapicam1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.FNC0.DMAC atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.FNC0.PIC_ attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.FNC0.PIT_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.FNC0.SPKR npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.FNC0.NDP_ atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.FNC0.KBC_ atkbd0 psm0 psmcpnp0 pnpinfo _HID=PNP0F13 _UID=0 at handle=\_SB_.PCI0.FNC0.PS2M attimer1 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.FNC0.RTC_ acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.FNC0.SYSR unknown pnpinfo _HID=IFX0102 _UID=0 at handle=\_SB_.PCI0.FNC0.TPM_ acpi_hpet0 pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.FNC0.HPET unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE0.HD_0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.FNC2.IDE1.ODD1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.VGA_.LCD_ unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.VGA_.CRT_ unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB1.HUB1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB2.HUB2 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB3.HUB3 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB4.HUB4 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.EHCI.HUB0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX1.GLAN unknown pnpinfo _HID=TOS6205 _UID=0 at handle=\_SB_.BT__ acpi_lid0 pnpinfo _HID=PNP0C0D _UID=0 at handle=\_SB_.LID_ battery0 pnpinfo _HID=PNP0C0A _UID=1 at handle=\_SB_.BAT1 acpi_button0 pnpinfo _HID=PNP0C0C _UID=0 at handle=\_SB_.PWRB acpi_acad0 pnpinfo _HID=ACPI0003 _UID=0 at handle=\_SB_.ADP1 unknown pnpinfo _HID=TOS6208 _UID=0 at handle=\_SB_.VALZ unknown pnpinfo _HID=TOS620A _UID=0 at handle=\_SB_.HAPS acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THRM acpi_timer0 pnpinfo unknown at unknown --BOKacYhQ+x31HxR3-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 20:39:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F8BA16A401; Sun, 25 Mar 2007 20:39:42 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6AD13C48C; Sun, 25 Mar 2007 20:39:41 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup96.ach.sch.gr [81.186.70.96]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PKRtQW021775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2007 23:28:04 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PKRnMI001596; Sun, 25 Mar 2007 23:27:50 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PKRntH001595; Sun, 25 Mar 2007 23:27:49 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 25 Mar 2007 23:27:49 +0300 From: Giorgos Keramidas To: andre@freebsd.org Message-ID: <20070325202749.GA1503@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703251620.20879.nb_root@videotron.ca> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.088, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.31, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 20:39:42 -0000 Hi Andre, The attached thread below is a reply from Nicolas Blais which shows some problems with the recent SACK changes. Any idea how we can proceed from this point? - Giorgos On 2007-03-25 16:20, Nicolas Blais wrote: > On March 25, 2007 03:49:46 pm Giorgos Keramidas wrote: > > On 2007-03-25 13:48, Nicolas Blais wrote: > > > > The panic happens after a small amount of network activity, inside > > > > the TCP SACK code: > > > > > > > > ----------------------------------------------------------------------- > > > >---- Disabling SACK lets me use my laptop again: > > > > > > > > net.inet.tcp.sack.enable=0 > > > > > > > > without any panics. > > > > > > Same here. If you want to quickly crash your system, > > > net.inet.tcp.sack.enable=1 and start a torrent :) > > > > > > I couldn't find what was causing my desktop to crash until I STOPPED > > > trying to restart my torrent after boot :) . Though > > > net.inet.tcp.sack.enable=0 fixed it. > > > > Rebuilding a kernel will take a while here. If you can try reverting > > the following commit before I do, let me know if it fixes the panic. > > > > % andre 2007-03-23 18:33:21 UTC > > % > > % FreeBSD src repository > > % > > % Modified files: > > % sys/netinet tcp_input.c tcp_sack.c > > % Log: > > % Bring SACK option handling in tcp_dooptions() in line with all other > > % options and ajust users accordingly. > > % > > % Revision Changes Path > > % 1.326 +7 -4 src/sys/netinet/tcp_input.c > > % 1.35 +1 -0 src/sys/netinet/tcp_sack.c > > Done. > > I reverted tcp_input.c to 1.325 and tcp_sack.c to 1.34. I was able to start > many torrents without a panic. I believe the revert fixed the problem, as > previously, just starting 1 torrent would panic (unless > net.inet.tcp.sack.enable=0) , now I have 5 running fine. > > Nicolas. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 21:17:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B228016A400; Sun, 25 Mar 2007 21:17:07 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a5.g.dreamhost.com (sd-green-bigip-74.dreamhost.com [208.97.132.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEAE13C458; Sun, 25 Mar 2007 21:17:07 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a5.g.dreamhost.com (Postfix) with ESMTP id 412AB14D6AA; Sun, 25 Mar 2007 14:17:04 -0700 (PDT) Message-ID: <4606E6D0.8070108@cyberwang.net> Date: Sun, 25 Mar 2007 17:17:04 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> <4606C5C6.2060407@cyberwang.net> <20070326042040.37c66edb.ariff@FreeBSD.org> In-Reply-To: <20070326042040.37c66edb.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 21:17:07 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 14:56:06 -0400 > Sean Bryant wrote: > >>> Try this one: (sys/dev/sound/pci/ich.c) >>> >>> http://people.freebsd.org/~ariff/test/ich.c >>> >>> (no, this has nothing to do with the panic at all) >>> >>> >>> > > At least, you should tell me whether this fix your attach issue or > not. > > >>>> With the latest HPS USB stack not sure if that's the same one in >>>> HEAD or not. >>>> Maybe something is conflicting or some other change has caused >>>> >>> the > resources to be tied up. That's a really rough guess with no >>> >>>> evidence to support it. >>>> >>>> >>>> >>> You should reproduce the panic, generate the dump, submit the >>> backtrace so things will become much clear for us. Will you? >>> >>> >> Okay I disabled the remote debugging things to get a dump but it >> keeps saying no dump device defined. I explicitly set it to my swap >> device. and still the same result. any ideas? >> >> > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > It does attach, but now reports channels are dead after so much delay. From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 21:18:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 1520616A400; Sun, 25 Mar 2007 21:18:09 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Mon, 26 Mar 2007 05:17:42 +0800 From: Ariff Abdullah To: Giorgos Keramidas Message-Id: <20070326051742.36edb849.ariff@FreeBSD.org> In-Reply-To: <20070325203412.GA1396@kobe.laptop> References: <20070325203412.GA1396@kobe.laptop> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__26_Mar_2007_05_17_42_+0800_NjpWPMvMZKidHAka" Cc: current@freebsd.org Subject: Re: snd_hda fails to probe after 15 March X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 21:18:11 -0000 --Signature=_Mon__26_Mar_2007_05_17_42_+0800_NjpWPMvMZKidHAka Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Mar 2007 23:34:13 +0300 Giorgos Keramidas wrote: > Hi Ariff and -current, >=20 > Some time after March 15, snd_hda started failing to attach to > pcm0 on my laptop. I haven't managed to nail the change down to > a single commit yet, but I've attached the files: >=20 > dmesg.boot-15 boot -v output of March 15 kernel > dmesg.boot-25 boot -v output of March 25 kernel > devinfo-15 devinfo -v output of March 15 kernel > devinfo-25 devinfo -v output of March 25 kernel >=20 > There seems to be at least one more message in dmesg.boot-25 which > seems relevant to snd_hda failing to attach: >=20 > pcm0: [MPSAFE] > pcm0: [ITHREAD] > +pcm0: hdac_get_capabilities: Invalid rirb size (0) > +device_attach: pcm0 attach returned 6 > pcib1: irq 17 at device 28.0 on pci0 >=20 > If you need anything more to troubleshoot this, let me know :) >=20 Try reverting hdac.c, down to cvs revision 1.27 Does this has anything to do with recent nexus changes? It seems that snd_ich plagued by a quite simmilar issue, lately. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__26_Mar_2007_05_17_42_+0800_NjpWPMvMZKidHAka Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGBub2lr+deMUwTNoRAiSuAKCCvBGQPyUk0JScm8CsI9joKPoieACgkVK3 u8cWliSY7oJiiWiGnw2lsjU= =osi8 -----END PGP SIGNATURE----- --Signature=_Mon__26_Mar_2007_05_17_42_+0800_NjpWPMvMZKidHAka-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 21:45:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5AD416A405; Sun, 25 Mar 2007 21:45:15 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 36EB113C45B; Sun, 25 Mar 2007 21:45:14 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup96.ach.sch.gr [81.186.70.96]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2PLicZ4026019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2007 00:44:47 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2PLiLER001447; Mon, 26 Mar 2007 00:44:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PLi8mh001446; Mon, 26 Mar 2007 00:44:08 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 26 Mar 2007 00:44:08 +0300 From: Giorgos Keramidas To: Ariff Abdullah Message-ID: <20070325214408.GA1113@kobe.laptop> References: <20070325203412.GA1396@kobe.laptop> <20070326051742.36edb849.ariff@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070326051742.36edb849.ariff@FreeBSD.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.087, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.31, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@freebsd.org Subject: Re: snd_hda fails to probe after 15 March X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Mar 2007 21:45:15 -0000 On 2007-03-26 05:17, Ariff Abdullah wrote: >On Sun, 25 Mar 2007 23:34:13 +0300 >Giorgos Keramidas wrote: >> Hi Ariff and -current, >> >> Some time after March 15, snd_hda started failing to attach to >> pcm0 on my laptop. I haven't managed to nail the change down to >> a single commit yet, but I've attached the files: >> >> dmesg.boot-15 boot -v output of March 15 kernel >> dmesg.boot-25 boot -v output of March 25 kernel >> devinfo-15 devinfo -v output of March 15 kernel >> devinfo-25 devinfo -v output of March 25 kernel >> >> There seems to be at least one more message in dmesg.boot-25 which >> seems relevant to snd_hda failing to attach: >> >> pcm0: [MPSAFE] >> pcm0: [ITHREAD] >> +pcm0: hdac_get_capabilities: Invalid rirb size (0) >> +device_attach: pcm0 attach returned 6 >> pcib1: irq 17 at device 28.0 on pci0 >> >> If you need anything more to troubleshoot this, let me know :) > > Try reverting hdac.c, down to cvs revision 1.27 No luck with that version and a -DNO_CLEAN build. I'll try a full kernel and modules recompile next. > Does this has anything to do with recent nexus changes? It seems that > snd_ich plagued by a quite simmilar issue, lately. Maybe. I'm not sure if it's related. Any pointer to changes which I can try is much appreciated :) From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 22:47:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCCA116A400 for ; Sun, 25 Mar 2007 22:47:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAC213C469 for ; Sun, 25 Mar 2007 22:47:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 86994 invoked from network); 25 Mar 2007 22:16:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Mar 2007 22:16:07 -0000 Message-ID: <4606FC1A.3090009@freebsd.org> Date: Mon, 26 Mar 2007 00:47:54 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Giorgos Keramidas References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> In-Reply-To: <20070325202749.GA1503@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 22:47:55 -0000 Giorgos Keramidas wrote: > Hi Andre, > > The attached thread below is a reply from Nicolas Blais which shows some > problems with the recent SACK changes. Any idea how we can proceed from > this point? I'm looking into it and have got a good backtrace from Wojciech too. -- Andre > - Giorgos > > On 2007-03-25 16:20, Nicolas Blais wrote: >> On March 25, 2007 03:49:46 pm Giorgos Keramidas wrote: >>> On 2007-03-25 13:48, Nicolas Blais wrote: >>>>> The panic happens after a small amount of network activity, inside >>>>> the TCP SACK code: >>>>> >>>>> ----------------------------------------------------------------------- >>>>> ---- Disabling SACK lets me use my laptop again: >>>>> >>>>> net.inet.tcp.sack.enable=0 >>>>> >>>>> without any panics. >>>> Same here. If you want to quickly crash your system, >>>> net.inet.tcp.sack.enable=1 and start a torrent :) >>>> >>>> I couldn't find what was causing my desktop to crash until I STOPPED >>>> trying to restart my torrent after boot :) . Though >>>> net.inet.tcp.sack.enable=0 fixed it. >>> Rebuilding a kernel will take a while here. If you can try reverting >>> the following commit before I do, let me know if it fixes the panic. >>> >>> % andre 2007-03-23 18:33:21 UTC >>> % >>> % FreeBSD src repository >>> % >>> % Modified files: >>> % sys/netinet tcp_input.c tcp_sack.c >>> % Log: >>> % Bring SACK option handling in tcp_dooptions() in line with all other >>> % options and ajust users accordingly. >>> % >>> % Revision Changes Path >>> % 1.326 +7 -4 src/sys/netinet/tcp_input.c >>> % 1.35 +1 -0 src/sys/netinet/tcp_sack.c >> Done. >> >> I reverted tcp_input.c to 1.325 and tcp_sack.c to 1.34. I was able to start >> many torrents without a panic. I believe the revert fixed the problem, as >> previously, just starting 1 torrent would panic (unless >> net.inet.tcp.sack.enable=0) , now I have 5 running fine. >> >> Nicolas. > > From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 23:28:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A33E016A402 for ; Sun, 25 Mar 2007 23:28:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 15A6913C46E for ; Sun, 25 Mar 2007 23:28:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 87284 invoked from network); 25 Mar 2007 22:56:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Mar 2007 22:56:59 -0000 Message-ID: <460705AE.5040107@freebsd.org> Date: Mon, 26 Mar 2007 01:28:46 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Giorgos Keramidas References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> In-Reply-To: <20070325202749.GA1503@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 23:28:47 -0000 Giorgos Keramidas wrote: > Hi Andre, > > The attached thread below is a reply from Nicolas Blais which shows some > problems with the recent SACK changes. Any idea how we can proceed from > this point? Please update to rev. 1.36 of sys/netinet/tcp_sack.c. The KASSERT() was too tight but actually caught a bug that would have caused a crash anyway. -- Andre > - Giorgos > > On 2007-03-25 16:20, Nicolas Blais wrote: >> On March 25, 2007 03:49:46 pm Giorgos Keramidas wrote: >>> On 2007-03-25 13:48, Nicolas Blais wrote: >>>>> The panic happens after a small amount of network activity, inside >>>>> the TCP SACK code: >>>>> >>>>> ----------------------------------------------------------------------- >>>>> ---- Disabling SACK lets me use my laptop again: >>>>> >>>>> net.inet.tcp.sack.enable=0 >>>>> >>>>> without any panics. >>>> Same here. If you want to quickly crash your system, >>>> net.inet.tcp.sack.enable=1 and start a torrent :) >>>> >>>> I couldn't find what was causing my desktop to crash until I STOPPED >>>> trying to restart my torrent after boot :) . Though >>>> net.inet.tcp.sack.enable=0 fixed it. >>> Rebuilding a kernel will take a while here. If you can try reverting >>> the following commit before I do, let me know if it fixes the panic. >>> >>> % andre 2007-03-23 18:33:21 UTC >>> % >>> % FreeBSD src repository >>> % >>> % Modified files: >>> % sys/netinet tcp_input.c tcp_sack.c >>> % Log: >>> % Bring SACK option handling in tcp_dooptions() in line with all other >>> % options and ajust users accordingly. >>> % >>> % Revision Changes Path >>> % 1.326 +7 -4 src/sys/netinet/tcp_input.c >>> % 1.35 +1 -0 src/sys/netinet/tcp_sack.c >> Done. >> >> I reverted tcp_input.c to 1.325 and tcp_sack.c to 1.34. I was able to start >> many torrents without a panic. I believe the revert fixed the problem, as >> previously, just starting 1 torrent would panic (unless >> net.inet.tcp.sack.enable=0) , now I have 5 running fine. >> >> Nicolas. > > From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 00:06:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6BC716A401 for ; Mon, 26 Mar 2007 00:06:09 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id 651B313C458 for ; Mon, 26 Mar 2007 00:06:02 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([85.172.12.47]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l2PNWwTF062082; Mon, 26 Mar 2007 03:33:08 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HVcCt-0000KL-To; Mon, 26 Mar 2007 03:33:03 +0400 To: Yuriy Tsibizov References: <20070325133125.X899@free.home.local> <20070325164936.K928@free.home.local> From: Boris Samorodov Date: Mon, 26 Mar 2007 03:33:03 +0400 In-Reply-To: <20070325164936.K928@free.home.local> (Yuriy Tsibizov's message of "Sun, 25 Mar 2007 16:57:35 +0400 (MSD)") Message-ID: <54646144@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: freebsd-current@freebsd.org Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 00:06:10 -0000 On Sun, 25 Mar 2007 16:57:35 +0400 (MSD) Yuriy Tsibizov wrote: > > I'm getting repeatable panic with kernel & userland from yesterday > > evening when I try to connect to Internet using bluetooth to connect > > to my phone: > > "rfcomm_pppd -a e60 -c -C dun -l mts". > The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). > It does not panic (in rtsock.c) when I use mpd. The same here, panic when ppp is started. Any news? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 02:26:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3EB016A400 for ; Mon, 26 Mar 2007 02:26:37 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id 764BE13C458 for ; Mon, 26 Mar 2007 02:26:37 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.96] (cpe-24-169-228-178.twmi.res.rr.com [24.169.228.178]) by lexi.siliconlandmark.com (8.13.8/8.13.3) with ESMTP id l2Q2QJcX048596; Sun, 25 Mar 2007 21:26:20 -0500 (EST) (envelope-from andy@siliconlandmark.com) In-Reply-To: <20070325202749.GA1503@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6492040F-3601-4289-A789-7E9D2E1D6723@siliconlandmark.com> Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Sun, 25 Mar 2007 22:26:17 -0400 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.7/2930/Sun Mar 25 16:01:32 2007 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=4.485, required 6, AWL -0.53, BAYES_00 -2.60, RCVD_IN_NJABL_DUL 1.95, RCVD_IN_SORBS_DUL 2.05, RCVD_IN_WHOIS_INVALID 2.23, SPF_SOFTFAIL 1.38) X-SL-SpamScore: 4 X-MailScanner-From: andy@siliconlandmark.com Cc: Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 02:26:37 -0000 On Mar 25, 2007, at 4:27 PM, Giorgos Keramidas wrote: > The attached thread below is a reply from Nicolas Blais which shows > some > problems with the recent SACK changes. Any idea how we can proceed > from > this point? Just another data point: I have a kernel from today which does not exhibit this problem (Though SACK is turned on and enabled at both endpoints). It does however still have the excessive DUP ACKs problem (Previously reported). uname -a: FreeBSD bling.properkernel.com 7.0-CURRENT FreeBSD 7.0- CURRENT #1: Sun Mar 25 18:12:26 EDT 2007 andy@bling.properkernel.com:/usr/obj/usr/src/sys/BLING i386 Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 04:55:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDA2F16A400; Mon, 26 Mar 2007 04:55:30 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9B48B13C44C; Mon, 26 Mar 2007 04:55:30 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l2Q4tQJ0071136; Sun, 25 Mar 2007 23:55:27 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4607523E.50201@freebsd.org> Date: Sun, 25 Mar 2007 23:55:26 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Gavin Atkinson References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> In-Reply-To: <20070325153013.E77473@ury.york.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2930/Sun Mar 25 16:01:32 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Robert Watson , freebsd-current@freebsd.org, "Wojciech A. Koszek" , Alex Kozlov , Peter Jeremy Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 04:55:30 -0000 On 03/25/07 09:34, Gavin Atkinson wrote: > On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: >> On Sun, Mar 25, 2007 at 08:00:41AM +1000, Peter Jeremy wrote: >>> On 2007-Mar-24 15:32:00 +0100, Robert Watson wrote: >>>> On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: >>>>> I'd like to have this enabled by default, and I know there should be no >>>>> strong objections. >>>> I agree -- the memory used by it is very small compared to the amount of >>>> memory in modern systems, and the potential administrative benefit is very >>>> large. As long as it remains an option, the embedded folk can turn it off >>>> easily. >>> Ideally, we would include it in a .comment section that wasn't loaded. >>> Unfortunately my ELF-foo isn't up to this (I've tried something similar >>> many years ago and couldn't get the linker to DWIW). >> In my current implementation, kernel configuration content is converted >> to the string and is actually put into separate ELF section. However, >> it's not .comment but a loadable section, since otherwise you wouldn't >> be able to obtain the configuration of a running system. > > strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' > > should still work if it was in a .comment section Unless you no longer have the running kernel, or it has changed since the boot up of the system. A sysctl knob to dump it is *very* useful. Eric From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 09:24:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9AA816A400 for ; Mon, 26 Mar 2007 09:24:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 67A3913C44C for ; Mon, 26 Mar 2007 09:24:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5E49D.dip.t-dialin.net [84.165.228.157]) by redbull.bpaserver.net (Postfix) with ESMTP id D8A1B2E167; Mon, 26 Mar 2007 11:24:35 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 110D65B4817; Mon, 26 Mar 2007 11:24:33 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2Q9OWDm062664; Mon, 26 Mar 2007 11:24:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 26 Mar 2007 11:24:32 +0200 Message-ID: <20070326112432.b857m21s00wss008@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 26 Mar 2007 11:24:32 +0200 From: Alexander Leidinger To: Giorgos Keramidas References: <20070325203412.GA1396@kobe.laptop> In-Reply-To: <20070325203412.GA1396@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.787, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_SN 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org, ariff@freebsd.org Subject: Re: snd_hda fails to probe after 15 March X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 09:24:41 -0000 Quoting Giorgos Keramidas (from Sun, 25 Mar 2007 23:34:13 +0300): > Hi Ariff and -current, > > Some time after March 15, snd_hda started failing to attach to > pcm0 on my laptop. I haven't managed to nail the change down to > a single commit yet, but I've attached the files: > pcm0: [MPSAFE] > pcm0: [ITHREAD] > +pcm0: hdac_get_capabilities: Invalid rirb size (0) > +device_attach: pcm0 attach returned 6 > pcib1: irq 17 at device 28.0 on pci0 There where some changes to the low level bus code. To nexus and IIRC to some bus space functions. Committd by, jhb. Try to find the corresponding commit, back it out and try again. Bye, Alexander. -- Garbage In - Gospel Out. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 09:44:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3DDD16A401; Mon, 26 Mar 2007 09:44:26 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA7313C45B; Mon, 26 Mar 2007 09:44:25 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id l2Q9iMbB003672; Mon, 26 Mar 2007 10:44:22 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id l2Q9iJD8044799; Mon, 26 Mar 2007 10:44:22 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id l2Q9iHq3044798; Mon, 26 Mar 2007 10:44:17 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Eric Anderson In-Reply-To: <4607523E.50201@freebsd.org> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2007 10:44:16 +0100 Message-Id: <1174902256.44767.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Robert Watson , freebsd-current@freebsd.org, "Wojciech A. Koszek" , Alex Kozlov , Peter Jeremy Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 09:44:27 -0000 On Sun, 2007-03-25 at 23:55 -0500, Eric Anderson wrote: > On 03/25/07 09:34, Gavin Atkinson wrote: > > On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: > >> On Sun, Mar 25, 2007 at 08:00:41AM +1000, Peter Jeremy wrote: > >>> On 2007-Mar-24 15:32:00 +0100, Robert Watson wrote: > >>>> On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: > >>>>> I'd like to have this enabled by default, and I know there should be no > >>>>> strong objections. > >>>> I agree -- the memory used by it is very small compared to the amount of > >>>> memory in modern systems, and the potential administrative benefit is very > >>>> large. As long as it remains an option, the embedded folk can turn it off > >>>> easily. > >>> Ideally, we would include it in a .comment section that wasn't loaded. > >>> Unfortunately my ELF-foo isn't up to this (I've tried something similar > >>> many years ago and couldn't get the linker to DWIW). > >> In my current implementation, kernel configuration content is converted > >> to the string and is actually put into separate ELF section. However, > >> it's not .comment but a loadable section, since otherwise you wouldn't > >> be able to obtain the configuration of a running system. > > > > strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' > > > > should still work if it was in a .comment section > > Unless you no longer have the running kernel, or it has changed since > the boot up of the system. A sysctl knob to dump it is *very* useful. Would it? The main benefit that I see is to be able to say "That kernel config doesn't boot, what did I have in my last kernel?". I can't think of a single situation where you would be likely to have a kernel still running, but no longer have a copy of it in /boot/kernel or /boot/kernel.old. Note that I'm not against the suggestion, I just don't think I see the point. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 09:52:33 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BB4716A401 for ; Mon, 26 Mar 2007 09:52:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 238E113C44B for ; Mon, 26 Mar 2007 09:52:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l2Q9ZQAX076380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 13:35:26 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l2Q9ZPgO076379; Mon, 26 Mar 2007 13:35:25 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 26 Mar 2007 13:35:25 +0400 From: Gleb Smirnoff To: Boris Samorodov Message-ID: <20070326093525.GO2713@FreeBSD.org> References: <20070325133125.X899@free.home.local> <20070325164936.K928@free.home.local> <54646144@bsam.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <54646144@bsam.ru> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 09:52:33 -0000 On Mon, Mar 26, 2007 at 03:33:03AM +0400, Boris Samorodov wrote: B> > > I'm getting repeatable panic with kernel & userland from yesterday B> > > evening when I try to connect to Internet using bluetooth to connect B> > > to my phone: B> > > "rfcomm_pppd -a e60 -c -C dun -l mts". B> B> > The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). B> > It does not panic (in rtsock.c) when I use mpd. B> B> The same here, panic when ppp is started. Any news? Can you confirm that backing out last rtsock.c revision fixes the problem? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 10:23:24 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3851C16A402; Mon, 26 Mar 2007 10:23:24 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id ABDC113C45E; Mon, 26 Mar 2007 10:23:23 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2QAMRxu001509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2007 13:22:41 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2QALwkk001601; Mon, 26 Mar 2007 13:22:21 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2PNQi4g001113; Mon, 26 Mar 2007 02:26:44 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 26 Mar 2007 02:26:44 +0300 From: Giorgos Keramidas To: Ariff Abdullah Message-ID: <20070325232643.GA1059@kobe.laptop> References: <20070325203412.GA1396@kobe.laptop> <20070326051742.36edb849.ariff@FreeBSD.org> <20070325214408.GA1113@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070325214408.GA1113@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.524, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.38, BAYES_00 -2.60, DATE_IN_PAST_06_12 0.50) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@FreeBSD.org Subject: Re: snd_hda fails to probe after 15 March X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 10:23:24 -0000 On 2007-03-26 00:44, Giorgos Keramidas wrote: >On 2007-03-26 05:17, Ariff Abdullah wrote: >>On Sun, 25 Mar 2007 23:34:13 +0300 >>Giorgos Keramidas wrote: >>> Some time after March 15, snd_hda started failing to attach to >>> pcm0 on my laptop. I haven't managed to nail the change down to >>> a single commit yet, but I've attached the files: >>> [...] >>> There seems to be at least one more message in dmesg.boot-25 which >>> seems relevant to snd_hda failing to attach: >>> >>> pcm0: [MPSAFE] >>> pcm0: [ITHREAD] >>> +pcm0: hdac_get_capabilities: Invalid rirb size (0) >>> +device_attach: pcm0 attach returned 6 >>> pcib1: irq 17 at device 28.0 on pci0 >>> >>> If you need anything more to troubleshoot this, let me know :) >> >> Try reverting hdac.c, down to cvs revision 1.27 > > No luck with that version and a -DNO_CLEAN build. I'll try a full > kernel and modules recompile next. A full kernel rebuild doesn't work either. In fact, even if I boot a HEAD kernel, with hdac.c down to 1.27 and I load the snd_hda module from the old kernel, I still get: pcm0: \ mem 0xf0000000-0xf0003fff irq 22 at device 27.0 on pci0 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: hdac_get_capabilities: Invalid rirb size (0) device_attach: pcm0 attach returned 6 pci1: driver added pci2: driver added Apparently, rirbsize in hdac.c:1122 is not initialized or it is initialized to zero: 1122 rirbsize = HDAC_READ_1(&sc->mem, HDAC_RIRBSIZE); [...] 1133 device_printf(sc->dev, "%s: Invalid rirb size (%x)\n", 1134 __func__, rirbsize); 1135 return (ENXIO); I was initially loading snd_hda from 'loader.conf', with: snd_hda_load="YES" but I don't know if this makes any difference. Unloading the module and loading it manually doesn't seem to fix the call to HDAC_READ_1() which sets rirbsize. From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 10:26:55 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0805A16A400; Mon, 26 Mar 2007 10:26:55 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6215C13C44B; Mon, 26 Mar 2007 10:26:53 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2QAQJ1U001716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2007 13:26:28 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2QAQ2nE002006; Mon, 26 Mar 2007 13:26:13 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2QAQ2kI002002; Mon, 26 Mar 2007 13:26:02 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 26 Mar 2007 13:26:02 +0300 From: Giorgos Keramidas To: Andre Oppermann Message-ID: <20070326102601.GA1781@kobe.laptop> References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460705AE.5040107@freebsd.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.774, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.62, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@FreeBSD.org, Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 10:26:55 -0000 On 2007-03-26 01:28, Andre Oppermann wrote: >Giorgos Keramidas wrote: >> Hi Andre, >> The attached thread below is a reply from Nicolas Blais which shows some >> problems with the recent SACK changes. Any idea how we can proceed from >> this point? > > Please update to rev. 1.36 of sys/netinet/tcp_sack.c. The KASSERT() was > too tight but actually caught a bug that would have caused a crash anyway. Excellent, thanks for the fast fix. I'm updating my CVSup tree as I type this, and I'll let you know after a while how things go. From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 11:17:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8E4E16A402 for ; Mon, 26 Mar 2007 11:17:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 643A213C48A for ; Mon, 26 Mar 2007 11:17:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l2QBH3IY002129; Mon, 26 Mar 2007 21:17:03 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l2QBH3Sl002128; Mon, 26 Mar 2007 21:17:03 +1000 (EST) (envelope-from peter) Date: Mon, 26 Mar 2007 21:17:03 +1000 From: Peter Jeremy To: Eric Anderson Message-ID: <20070326111702.GD838@turion.vk2pj.dyndns.org> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <4607523E.50201@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 11:17:04 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Mar-25 23:55:26 -0500, Eric Anderson wrote: >On 03/25/07 09:34, Gavin Atkinson wrote: >>strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' >> >>should still work if it was in a .comment section > >Unless you no longer have the running kernel, or it has changed since=20 >the boot up of the system. A sysctl knob to dump it is *very* useful. Note that kern.bootfile will get updated during installkernel. I also can't think of a situation where I would have lost all copies of my running kernel as well as the config file that was used to build it. This could potentially happen if you ran two or more installkernels without rebooting but I can't think of any reason why I would do that: If a kernel builds, I am likely to try booting it before going onto something else. If a kernel doesn't build, it won't install. Overall, having the config file loaded strikes me as a waste of RAM. --=20 Peter Jeremy --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGB6uu/opHv/APuIcRAu+CAJ9S0zFoD6ID0jlnWrUyYeifk18/vwCgkKFw xP+ybZ7CmQGYsy7BNBqe0UQ= =h06A -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 09:17:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C8B716A403 for ; Mon, 26 Mar 2007 09:17:08 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [207.245.121.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2E36C13C4B7 for ; Mon, 26 Mar 2007 09:17:07 +0000 (UTC) (envelope-from tom@uffner.com) Received: from kali.uffner.com (static-71-162-143-90.phlapa.fios.verizon.net [71.162.143.90]) by eris.uffner.com (8.13.3/8.13.3) with ESMTP id l2Q8oOqG068992 for ; Mon, 26 Mar 2007 03:50:25 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <4607893B.3080409@uffner.com> Date: Mon, 26 Mar 2007 04:50:03 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070324 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------090704030805070501010609" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (eris.uffner.com [192.168.1.212]); Mon, 26 Mar 2007 04:50:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.6/2923/Sun Mar 25 04:39:36 2007 on eris.uffner.com X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 26 Mar 2007 11:52:38 +0000 Subject: current panics when Netgear WG511T ejected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 09:17:08 -0000 This is a multi-part message in MIME format. --------------090704030805070501010609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I recently installed a more current -CURRENT on my laptop, and discovered that it panics when I eject my wireless network card. the laptop is a Sony Vaio PCG-XG9. the Wireless card is a Netgear WG511T (Atheros 5212, cardbus, 802.11 b/g) It does not seem to matter if the card was installed when the system boots or was inserted later, i get the same panic either way if i eject it. other than not being able to remove it, the card works fine. FreeBSD kali.uffner.com 7.0-CURRENT FreeBSD 7.0-CURRENT #18: Thu Mar 22 20:29:36 EDT 2007 tom@kali.uffner.com:/usr/obj/usr/src/sys/KALI i386 Id Refs Address Size Name 1 26 0xc0400000 38d574 kernel 2 1 0xc078e000 1267c if_ath.ko 3 2 0xc07a1000 44a4 ath_rate.ko 4 4 0xc07a6000 23b78 wlan.ko 5 3 0xc07ca000 2ec38 ath_hal.ko 6 1 0xc07f9000 d7d8 if_ed.ko 7 2 0xc0807000 43230 sound.ko 8 1 0xc084b000 cc18 snd_ds1.ko 9 1 0xc0858000 c2e4 random.ko 10 1 0xc0865000 2f50 wlan_wep.ko 11 1 0xc0868000 9a94 sio.ko 12 2 0xc0872000 47b0 ucom.ko 13 1 0xc0877000 4c4c uplcom.ko 14 1 0xc087c000 682f4 acpi.ko 15 1 0xc1978000 2000 green_saver.ko --------------090704030805070501010609 Content-Type: text/plain; name="KALI" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="KALI" # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.329 2001/11/06 16:15:47 obrien Exp $ machine i386 cpu I686_CPU ident KALI maxusers 0 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD options PREEMPTION # Enable kernel thread preemption options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device #options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD6 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # Debugging for use in -current options KDB #Enable the kernel debugger options DDB #Enable the kernel debugger #device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # At keyboard controller device atkbd # at keyboard device psm # psm mouse device kbdmux # keyboard multiplexer device vga # VGA screen # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards # Pseudo devices - the number indicates how many units to allocate. device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic #device uplcom # USB support for Prolific PL-2303/2303X/2303HX #device ucom # USB tty support device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device ums # Mouse options SC_HISTORY_SIZE=800 # number of history buffer lines options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" device spic --------------090704030805070501010609 Content-Type: text/plain; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.boot" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #18: Thu Mar 22 20:29:36 EDT 2007 tom@kali.uffner.com:/usr/obj/usr/src/sys/KALI Preloaded elf kernel "/boot/kernel/kernel" at 0xc08e6000. Preloaded elf module "/boot/kernel/if_ath.ko" at 0xc08e6160. Preloaded elf module "/boot/kernel/ath_rate.ko" at 0xc08e620c. Preloaded elf module "/boot/kernel/wlan.ko" at 0xc08e62bc. Preloaded elf module "/boot/kernel/ath_hal.ko" at 0xc08e6368. Preloaded elf module "/boot/kernel/if_ed.ko" at 0xc08e6414. Preloaded elf module "/boot/kernel/sound.ko" at 0xc08e64c0. Preloaded elf module "/boot/kernel/snd_ds1.ko" at 0xc08e656c. Preloaded elf module "/boot/kernel/random.ko" at 0xc08e6618. Preloaded elf module "/boot/kernel/wlan_wep.ko" at 0xc08e66c4. Preloaded elf module "/boot/kernel/sio.ko" at 0xc08e6774. Preloaded elf module "/boot/kernel/ucom.ko" at 0xc08e681c. Preloaded elf module "/boot/kernel/uplcom.ko" at 0xc08e68c8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08e6974. Calibrating clock(s) ... i8254 clock: 1193194 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 496310398 Hz CPU: Intel Pentium III (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 134152192 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000007d6efff, 118792192 bytes (29002 pages) avail memory = 121634816 (116 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7100 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x11e pnpbios: Found PnP BIOS data at 0xc00f7130 pnpbios: Entry = f0000:b329 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> feeder_register: snd_unit=0 snd_maxautovchans=4 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 ath_rate: version 1.2 null: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled random: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 12 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 12 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: wakeup code va 0xc3d55000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi0: reservation of 100000, 7f00000 (3) failed acpi0: reservation of 0, a0000 (3) failed ACPI timer: 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x8010 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.7.INTD at func 2: 9 ACPI: Found matching pin for 0.8.INTA at func 0: 9 ACPI: Found matching pin for 0.9.INTA at func 0: 9 ACPI: Found matching pin for 0.10.INTA at func 0: 9 ACPI: Found matching pin for 0.12.INTA at func 0: 255 ACPI: Found matching pin for 0.12.INTB at func 1: 255 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base 0x40000000, size 24, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x001f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x8c (35000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0xfc90, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[20]: type 4, range 32, base 0xfca0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 9 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type 4, range 32, base 0x1040, size 4, enabled found-> vendor=0x104d, dev=0x8039, revid=0x02 bus=0, slot=8, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x04 (1000 ns) intpin=a, irq=9 powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xfedf7000, size 11, enabled map[14]: type 1, range 32, base 0xfedf7c00, size 9, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.LNKD:0) pcib0: slot 8 INTA routed to irq 9 via \\_SB_.LNKD found-> vendor=0x1073, dev=0x0010, revid=0x02 bus=0, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x19 (6250 ns) intpin=a, irq=9 powerspec 1 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base 0xfedf8000, size 15, enabled map[14]: type 4, range 32, base 0xfcc0, size 6, enabled map[18]: type 4, range 32, base 0xfc8c, size 2, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.LNKC:0) pcib0: slot 9 INTA routed to irq 9 via \\_SB_.LNKC found-> vendor=0x127a, dev=0x2005, revid=0x01 bus=0, slot=10, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xfede0000, size 16, enabled map[14]: type 4, range 32, base 0xfc78, size 3, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.LNKB:0) pcib0: slot 10 INTA routed to irq 9 via \\_SB_.LNKB found-> vendor=0x1180, dev=0x0478, revid=0x80 bus=0, slot=12, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x1180, dev=0x0478, revid=0x80 bus=0, slot=12, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled agp0: on hostb0 hostb0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 16M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfe800000-0xfecfffff pcib1: prefetched decode 0xfd000000-0xfdffffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.VID0 - AE_NOT_FOUND pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10c8, dev=0x0005, revid=0x20 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0207, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type 1, range 32, base 0xfe800000, size 22, enabled pcib1: requested memory range 0xfe800000-0xfebfffff: good map[18]: type 1, range 32, base 0xfec00000, size 20, enabled pcib1: requested memory range 0xfec00000-0xfecfffff: good pcib0: matched entry for 0.1.INTA (src \\_SB_.LNKA:0) pcib0: slot 1 INTA routed to irq 9 via \\_SB_.LNKA pcib1: slot 0 INTA is routed to irq 9 vgapci0: mem 0xfd000000-0xfdffffff,0xfe800000-0xfebfffff,0xfec00000-0xfecfffff irq 9 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc90-0xfc9f at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc90 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfca0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) pcm0: port 0xfcc0-0xfcff,0xfc8c-0xfc8f mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 pcm0: Reserved 0x8000 bytes for rid 0x10 type 3 at 0xfedf8000 ds1: setmap (7c57000, 3de4), nseg=1, error=0 pcm0: pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM 3D Audio pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: sndbuf_setmap 19d000, 1000; 0xc1769000 -> 19d000 pcm0: sndbuf_setmap 1a1000, 1000; 0xc176d000 -> 1a1000 pcm0: sndbuf_setmap 1b0000, 1000; 0xc177e000 -> 1b0000 pcm0: sndbuf_setmap 1ae000, 1000; 0xc177c000 -> 1ae000 pcm0: sndbuf_setmap 1ac000, 1000; 0xc177a000 -> 1ac000 pcm0: sndbuf_setmap 1aa000, 1000; 0xc1778000 -> 1aa000 want format 268435472 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) setspeed, channel pcm0:play:0:dsp0.p0 want speed 4000, try speed 4000, got speed 4000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 setspeed, channel pcm0:play:0:dsp0.p0 want speed 4000, try speed 4000, got speed 4000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 setspeed, channel pcm0:play:0:dsp0.p0 want speed 48000, try speed 48000, got speed 48000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 pci0: at device 10.0 (no driver attached) cbb0: at device 12.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: matched entry for 0.12.INTA (src \\_SB_.LNKA:0) pcib0: slot 12 INTA routed to irq 9 via \\_SB_.LNKA cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x04781180 0x02100007 0x06070080 0x00822000 0x10: 0x80000000 0x020000dc 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x04000109 0x40: 0x804f104d 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x804f104d 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe190001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 12.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: matched entry for 0.12.INTB (src \\_SB_.LNKB:0) pcib0: slot 12 INTB routed to irq 9 via \\_SB_.LNKB cbb1: [MPSAFE] cbb1: [ITHREAD] cbb1: PCI Configuration space: 0x00: 0x04781180 0x02100007 0x06070080 0x00822000 0x10: 0x80001000 0x020000dc 0x20050400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x04000209 0x40: 0x804f104d 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x804f104d 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe190001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [FILTER] battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 pmtimer: pmtimer0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) spic0: device model type = 1 spic0: at port 0x10a0-0x10a4 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 496310398 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: setting PIO4 on PIIX4 chip ad0: setting UDMA33 on PIIX4 chip ad0: 17301MB at ata0-master UDMA33 ad0: 35433216 sectors [37495C/15H/63S] 16 sectors/interrupt 1 depth queue ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout GEOM: new disk ad0 battery0: battery initialization start battery1: battery initialization start acpi_acad0: acline initialization start battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM_LABEL: Label for provider ad0s1 is msdosfs/NO NAME. fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init splash: image decoder found: green_saver battery1: battery initialization failed, giving up cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff unknown: Lazy allocation of 0x10000 bytes rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: map[10]: type 1, range 32, base 0x88000000, size 16, enabled found-> vendor=0x168c, dev=0x0013, revid=0x01 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus0 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff ath0: [MPSAFE] ath0: [ITHREAD] ath0: hal channel 2412/a0 -> 1 ath0: hal channel 2412/c0 -> 1 ath0: hal channel 2417/a0 -> 2 ath0: hal channel 2417/c0 -> 2 ath0: hal channel 2422/a0 -> 3 ath0: hal channel 2422/c0 -> 3 ath0: hal channel 2427/a0 -> 4 ath0: hal channel 2427/c0 -> 4 ath0: hal channel 2432/a0 -> 5 ath0: hal channel 2432/c0 -> 5 ath0: hal channel 2437/a0 -> 6 ath0: hal channel 2437/c0 -> 6 ath0: hal channel 2437/d0 -> 6 ath0: hal channel 2442/a0 -> 7 ath0: hal channel 2442/c0 -> 7 ath0: hal channel 2447/a0 -> 8 ath0: hal channel 2447/c0 -> 8 ath0: hal channel 2452/a0 -> 9 ath0: hal channel 2452/c0 -> 9 ath0: hal channel 2457/a0 -> 10 ath0: hal channel 2457/c0 -> 10 ath0: hal channel 2462/a0 -> 11 ath0: hal channel 2462/c0 -> 11 ath0: using obsoleted if_watchdog interface ath0: bpf attached ath0: Ethernet address: 00:0f:b5:22:be:69 ath0: bpf attached ath0: bpf attached ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: mac 5.9 phy 4.3 radio 4.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: link state changed to UP ath0: link state changed to DOWN Fatal trap 12: page fault while in kernel mode fault virtual address = 0x50 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05ab9b9 stack pointer = 0x28:0xc7b20b5c frame pointer = 0x28:0xc7b20b9c 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 = 25 (cbb0 event thread) panic: from debugger Uptime: 4m5s Physical memory: 119 MB Dumping 24 MB: 9 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #18: Thu Mar 22 20:29:36 EDT 2007 tom@kali.uffner.com:/usr/obj/usr/src/sys/KALI Preloaded elf kernel "/boot/kernel/kernel" at 0xc08e6000. Preloaded elf module "/boot/kernel/if_ath.ko" at 0xc08e6160. Preloaded elf module "/boot/kernel/ath_rate.ko" at 0xc08e620c. Preloaded elf module "/boot/kernel/wlan.ko" at 0xc08e62bc. Preloaded elf module "/boot/kernel/ath_hal.ko" at 0xc08e6368. Preloaded elf module "/boot/kernel/if_ed.ko" at 0xc08e6414. Preloaded elf module "/boot/kernel/sound.ko" at 0xc08e64c0. Preloaded elf module "/boot/kernel/snd_ds1.ko" at 0xc08e656c. Preloaded elf module "/boot/kernel/random.ko" at 0xc08e6618. Preloaded elf module "/boot/kernel/wlan_wep.ko" at 0xc08e66c4. Preloaded elf module "/boot/kernel/sio.ko" at 0xc08e6774. Preloaded elf module "/boot/kernel/ucom.ko" at 0xc08e681c. Preloaded elf module "/boot/kernel/uplcom.ko" at 0xc08e68c8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08e6974. Calibrating clock(s) ... i8254 clock: 1193193 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 496310603 Hz CPU: Intel Pentium III (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 134152192 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000007d6efff, 118792192 bytes (29002 pages) avail memory = 121634816 (116 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7100 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x11e pnpbios: Found PnP BIOS data at 0xc00f7130 pnpbios: Entry = f0000:b329 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> feeder_register: snd_unit=0 snd_maxautovchans=4 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 ath_rate: version 1.2 null: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled random: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 12 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 12 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: wakeup code va 0xc3d55000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi0: reservation of 100000, 7f00000 (3) failed acpi0: reservation of 0, a0000 (3) failed ACPI timer: 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 9 Validation 0 9 N 0 9 After Disable 0 255 N 0 9 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x8010 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.7.INTD at func 2: 9 ACPI: Found matching pin for 0.8.INTA at func 0: 9 ACPI: Found matching pin for 0.9.INTA at func 0: 9 ACPI: Found matching pin for 0.10.INTA at func 0: 9 ACPI: Found matching pin for 0.12.INTA at func 0: 255 ACPI: Found matching pin for 0.12.INTB at func 1: 255 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base 0x40000000, size 24, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x001f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x8c (35000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0xfc90, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[20]: type 4, range 32, base 0xfca0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 9 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type 4, range 32, base 0x1040, size 4, enabled found-> vendor=0x104d, dev=0x8039, revid=0x02 bus=0, slot=8, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x04 (1000 ns) intpin=a, irq=9 powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xfedf7000, size 11, enabled map[14]: type 1, range 32, base 0xfedf7c00, size 9, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.LNKD:0) pcib0: slot 8 INTA routed to irq 9 via \\_SB_.LNKD found-> vendor=0x1073, dev=0x0010, revid=0x02 bus=0, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x19 (6250 ns) intpin=a, irq=9 powerspec 1 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base 0xfedf8000, size 15, enabled map[14]: type 4, range 32, base 0xfcc0, size 6, enabled map[18]: type 4, range 32, base 0xfc8c, size 2, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.LNKC:0) pcib0: slot 9 INTA routed to irq 9 via \\_SB_.LNKC found-> vendor=0x127a, dev=0x2005, revid=0x01 bus=0, slot=10, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xfede0000, size 16, enabled map[14]: type 4, range 32, base 0xfc78, size 3, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.LNKB:0) pcib0: slot 10 INTA routed to irq 9 via \\_SB_.LNKB found-> vendor=0x1180, dev=0x0478, revid=0x80 bus=0, slot=12, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled found-> vendor=0x1180, dev=0x0478, revid=0x80 bus=0, slot=12, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0, size 12, memory disabled agp0: on hostb0 hostb0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 16M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfe800000-0xfecfffff pcib1: prefetched decode 0xfd000000-0xfdffffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.VID0 - AE_NOT_FOUND pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10c8, dev=0x0005, revid=0x20 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0207, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type 1, range 32, base 0xfe800000, size 22, enabled pcib1: requested memory range 0xfe800000-0xfebfffff: good map[18]: type 1, range 32, base 0xfec00000, size 20, enabled pcib1: requested memory range 0xfec00000-0xfecfffff: good pcib0: matched entry for 0.1.INTA (src \\_SB_.LNKA:0) pcib0: slot 1 INTA routed to irq 9 via \\_SB_.LNKA pcib1: slot 0 INTA is routed to irq 9 vgapci0: mem 0xfd000000-0xfdffffff,0xfe800000-0xfebfffff,0xfec00000-0xfecfffff irq 9 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc90-0xfc9f at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc90 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfca0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) pcm0: port 0xfcc0-0xfcff,0xfc8c-0xfc8f mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 pcm0: Reserved 0x8000 bytes for rid 0x10 type 3 at 0xfedf8000 ds1: setmap (7c57000, 3de4), nseg=1, error=0 pcm0: pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM 3D Audio pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: sndbuf_setmap 19d000, 1000; 0xc1769000 -> 19d000 pcm0: sndbuf_setmap 1a1000, 1000; 0xc176d000 -> 1a1000 pcm0: sndbuf_setmap 1b0000, 1000; 0xc177e000 -> 1b0000 pcm0: sndbuf_setmap 1ae000, 1000; 0xc177c000 -> 1ae000 pcm0: sndbuf_setmap 1ac000, 1000; 0xc177a000 -> 1ac000 pcm0: sndbuf_setmap 1aa000, 1000; 0xc1778000 -> 1aa000 want format 268435472 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) setspeed, channel pcm0:play:0:dsp0.p0 want speed 4000, try speed 4000, got speed 4000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 setspeed, channel pcm0:play:0:dsp0.p0 want speed 4000, try speed 4000, got speed 4000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 setspeed, channel pcm0:play:0:dsp0.p0 want speed 48000, try speed 48000, got speed 48000 feederflags 0 trying feeder_vchan (0x10000010 -> 0x10000010)... got it chn_fmtchain: 0x10000010 -> 0x10000010 (maxdepth: 0) r = 0 setspeed done, r = 0 pci0: at device 10.0 (no driver attached) cbb0: at device 12.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: matched entry for 0.12.INTA (src \\_SB_.LNKA:0) pcib0: slot 12 INTA routed to irq 9 via \\_SB_.LNKA cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x04781180 0x02100007 0x06070080 0x00822000 0x10: 0x80000000 0x020000dc 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x04000109 0x40: 0x804f104d 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x804f104d 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe190001 0xe0: 0x24c0c000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 12.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: matched entry for 0.12.INTB (src \\_SB_.LNKB:0) pcib0: slot 12 INTB routed to irq 9 via \\_SB_.LNKB cbb1: [MPSAFE] cbb1: [ITHREAD] cbb1: PCI Configuration space: 0x00: 0x04781180 0x02100007 0x06070080 0x00822000 0x10: 0x80001000 0x020000dc 0x20050400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x04000209 0x40: 0x804f104d 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x804f104d 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe190001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 73 fdc0: [FILTER] battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 pmtimer: pmtimer0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) spic0: device model type = 1 spic0: at port 0x10a0-0x10a4 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 496310603 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: setting PIO4 on PIIX4 chip ad0: setting UDMA33 on PIIX4 chip ad0: 17301MB at ata0-master UDMA33 ad0: 35433216 sectors [37495C/15H/63S] 16 sectors/interrupt 1 depth queue ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout GEOM: new disk ad0 battery0: battery initialization start battery1: battery initialization start acpi_acad0: acline initialization start cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff unknown: Lazy allocation of 0x10000 bytes rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: map[10]: type 1, range 32, base 0x88000000, size 16, enabled found-> vendor=0x168c, dev=0x0013, revid=0x01 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus0 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff ath0: [MPSAFE] ath0: [ITHREAD] ath0: hal channel 2412/a0 -> 1 ath0: hal channel 2412/c0 -> 1 ath0: hal channel 2417/a0 -> 2 ath0: hal channel 2417/c0 -> 2 ath0: hal channel 2422/a0 -> 3 ath0: hal channel 2422/c0 -> 3 ath0: hal channel 2427/a0 -> 4 ath0: hal channel 2427/c0 -> 4 ath0: hal channel 2432/a0 -> 5 ath0: hal channel 2432/c0 -> 5 ath0: hal channel 2437/a0 -> 6 ath0: hal channel 2437/c0 -> 6 ath0: hal channel 2437/d0 -> 6 ath0: hal channel 2442/a0 -> 7 ath0: hal channel 2442/c0 -> 7 ath0: hal channel 2447/a0 -> 8 ath0: hal channel 2447/c0 -> 8 ath0: hal channel 2452/a0 -> 9 ath0: hal channel 2452/c0 -> 9 ath0: hal channel 2457/a0 -> 10 ath0: hal channel 2457/c0 -> 10 ath0: hal channel 2462/a0 -> 11 ath0: hal channel 2462/c0 -> 11 ath0: using obsoleted if_watchdog interface ath0: bpf attached ath0: Ethernet address: 00:0f:b5:22:be:69 ath0: bpf attached ath0: bpf attached ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: mac 5.9 phy 4.3 radio 4.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM_LABEL: Label for provider ad0s1 is msdosfs/NO NAME. fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted start_init: trying /sbin/init WARNING: /home was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted --------------090704030805070501010609 Content-Type: text/plain; name="typescript" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="typescript" Script started on Mon Mar 26 03:43:04 2007 [kali#:/boot/kernel:ttyp2] kgdb kernel.symbols /var/crash/vmcore.2 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <5>ath0: link state changed to DOWN Fatal trap 12: page fault while in kernel mode fault virtual address = 0x50 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05ab9b9 stack pointer = 0x28:0xc7b20b5c frame pointer = 0x28:0xc7b20b9c 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 = 25 (cbb0 event thread) panic: from debugger Uptime: 4m5s Physical memory: 119 MB Dumping 24 MB: 9 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) add-symbol-file /boot/kernel/if_ath.ko.symbols 0xc0791510 add symbol table from file "/boot/kernel/if_ath.ko.symbols" at .text_addr = 0xc0791510 (y or n) y Reading symbols from /boot/kernel/if_ath.ko.symbols...done. (kgdb) add-symbol-file /boot/kernel/ath_rate.ko.symbols 0xc07a1a50 add symbol table from file "/boot/kernel/ath_rate.ko.symbols" at .text_addr = 0xc07a1a50 (y or n) y Reading symbols from /boot/kernel/ath_rate.ko.symbols...done. (kgdb) add-symbol-file /boot/kernel/wlan.ko.symbols 0xc07aaf00 add symbol table from file "/boot/kernel/wlan.ko.symbols" at .text_addr = 0xc07aaf00 (y or n) y Reading symbols from /boot/kernel/wlan.ko.symbols...done. (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc0508fe6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc050934d in panic (fmt=0xc067fffe "from debugger") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc042eee7 in db_panic (addr=-1067796039, have_addr=0, count=-1, modif=0xc7b20908 "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc042ee70 in db_command (last_cmdp=0xc06de1a4, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #5 0xc042ef55 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #6 0xc04311e5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc052fda5 in kdb_trap (type=0, code=0, tf=0x0) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc066093c in trap_fatal (frame=0xc7b20b1c, eva=80) at /usr/src/sys/i386/i386/trap.c:859 #9 0xc0660615 in trap_pfault (frame=0xc7b20b1c, usermode=0, eva=80) at /usr/src/sys/i386/i386/trap.c:777 #10 0xc066018c in trap (frame=0xc7b20b1c) at /usr/src/sys/i386/i386/trap.c:462 #11 0xc064ef9b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc05ab9b9 in rt_newmaddrmsg (cmd=-1048376576, ifma=0xc1b721e0) at /usr/src/sys/net/rtsock.c:967 #13 0xc05a1125 in if_delmulti_locked (ifp=0xc17a2800, ifma=0xc1b721e0, detaching=1) at /usr/src/sys/net/if.c:2528 #14 0xc059cc76 in if_purgemaddrs (ifp=0xc17a2800) at /usr/src/sys/net/if.c:636 #15 0xc059cdf7 in if_detach (ifp=0xc17a2800) at /usr/src/sys/net/if.c:701 #16 0xc05a3a70 in ether_ifdetach (ifp=0xc17a2800) at /usr/src/sys/net/if_ethersubr.c:924 #17 0xc07ab5a2 in ieee80211_ifdetach (ic=0xc1b643c8) at /usr/src/sys/modules/wlan/../../net80211/ieee80211.c:279 #18 0xc079220b in ath_detach (sc=0xc1b64000) at /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:669 #19 0xc079b1eb in ath_pci_detach (dev=0xc1922280) at /usr/src/sys/modules/ath/../../dev/ath/if_ath_pci.c:223 #20 0xc0529a0a in device_detach (dev=0xc1922280) at device_if.h:211 #21 0xc04549a4 in cardbus_detach_card (cbdev=0xc1755880) at /usr/src/sys/dev/cardbus/cardbus.c:235 #22 0xc0475509 in cbb_removal (sc=0xc1722000) at card_if.h:94 #23 0xc0475077 in cbb_event_thread (arg=0xc1722000) at /usr/src/sys/dev/pccbb/pccbb.c:486 #24 0xc04ecb30 in fork_exit (callout=0xc0474f20 , arg=0xc1830b00, frame=0xc1830b00) at /usr/src/sys/kern/kern_fork.c:814 #25 0xc064f010 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) up 12 #12 0xc05ab9b9 in rt_newmaddrmsg (cmd=-1048376576, ifma=0xc1b721e0) at /usr/src/sys/net/rtsock.c:967 967 ifmam = mtod(m, struct ifma_msghdr *); (kgdb) p *ifma $1 = {ifma_link = {tqe_next = 0xc1b721c0, tqe_prev = 0xc17a28bc}, ifma_addr = 0xc189e080, ifma_lladdr = 0xc193c340, ifma_ifp = 0x0, ifma_refcount = 0, ifma_protospec = 0xc193c280, ifma_llifma = 0xc1b721c0} (kgdb) p m $2 = (struct mbuf *) 0xc1830b00 (kgdb) p *m $3 = {m_hdr = {mh_next = 0xc1830a00, mh_nextpkt = 0x0, mh_data = 0xc1830b34 "X", mh_len = 16, mh_flags = 2, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {rcvif = 0x0, len = 88, header = 0x0, csum_flags = 0, csum_data = 0, tso_segsz = 0, ether_vtag = 0, tags = { slh_first = 0x0}}, MH_dat = {MH_ext = { ext_buf = 0x10050058
, ext_free = 0, ext_args = 0x0, ext_size = 0, ref_cnt = 0x40, ext_type = 0}, MH_databuf = "X\000\005\020", '\0' , "@\000\000\000\000\000\000\000\000\006\000 \177\000\000\001\177\000\000\001�\230\000\031\020\037\210g?\237~\017\200\020\027\001\000\000\000\000\001\001\b\n\000\000B\215k�U", '\0' }}, M_databuf = "\000\000\000\000X", '\0' , "X\000\005\020", '\0' , "@\000\000\000\000\000\000\000\000\006\000 \177\000\000\001\177\000\000\001�\230\000\031\020\037\210g?\237~\017\200\020\027\001\000\000\000\000\001\001\b\n\000\000B\215k�U", '\0' }} (kgdb) up #13 0xc05a1125 in if_delmulti_locked (ifp=0xc17a2800, ifma=0xc1b721e0, detaching=1) at /usr/src/sys/net/if.c:2528 2528 rt_newmaddrmsg(RTM_DELMADDR, ifma); (kgdb) p *ifp $4 = {if_softc = 0xc1b64000, if_l2com = 0xc1756340, if_link = {tqe_next = 0x0, tqe_prev = 0xc17bf408}, if_xname = "ath0", '\0' , if_dname = 0xc16cc0ac "ath", if_dunit = 0, if_addrhead = { tqh_first = 0xc1940a00, tqh_last = 0xc1940a60}, if_klist = {kl_list = { slh_first = 0x0}, kl_lock = 0xc04e5f40 , kl_unlock = 0xc04e5fa0 , kl_locked = 0xc04e5ff0 , kl_lockarg = 0xc06f2c38}, if_pcount = 0, if_carp = 0x0, if_bpf = 0xc193c640, if_index = 2, if_timer = 0, if_vlantrunk = 0x0, if_flags = 34818, if_capabilities = 0, if_capenable = 0, if_linkmib = 0x0, if_linkmiblen = 0, if_data = { ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 32 ' ', ifi_link_state = 1 '\001', ifi_recvquota = 0 '\0', ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 54000000, ifi_ipackets = 12, ifi_ierrors = 32, ifi_opackets = 3, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 1753, ifi_obytes = 726, ifi_imcasts = 10, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 110, ifi_lastchange = {tv_sec = 1174796489, tv_usec = 156365}}, if_multiaddrs = {tqh_first = 0xc1b721e0, tqh_last = 0xc1b721c0}, if_amcount = 0, if_output = 0xc07bd8b0 , if_input = 0xc05a3290 , if_start = 0xc0792da0 , if_ioctl = 0xc0798c50 , if_watchdog = 0xc0798bc0 , if_init = 0xc0792750 , if_resolvemulti = 0xc05a3c30 , if_addr = 0xc1940a00, if_spare2 = 0xc1b64230, if_spare3 = 0x0, if_drv_flags = 0, if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50, ifq_drops = 0, ifq_mtx = {mtx_object = { lo_name = 0xc17a2810 "ath0", lo_type = 0xc06950bf "if send queue", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 50, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xc17a2800, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xc067b4c0 "������", if_bridge = 0x0, lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc17a2970}, if_afdata = {0x0 }, if_afdata_initialized = 2, if_afdata_mtx = {mtx_object = { lo_name = 0xc06950b5 "if_afdata", lo_type = 0xc06950b5 "if_afdata", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, if_starttask = { ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc05a14d0 , ta_context = 0xc17a2800}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc059eca0 , ta_context = 0xc17a2800}, if_addr_mtx = {mtx_object = {lo_name = 0xc069504b "if_addr_mtx", lo_type = 0xc069504b "if_addr_mtx", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3244942176, mtx_recurse = 0}, if_clones = {le_next = 0x0, le_prev = 0x0}, if_groups = {tqh_first = 0xc189e690, tqh_last = 0xc189e694}, if_pf_kif = 0x0} (kgdb) q 1.686u 0.217s 20:55.17 0.1% 2545+1206k 135+0io 30pf+0w [kali#:/boot/kernel:ttyp2] exit exit Script done on Mon Mar 26 04:04:23 2007 --------------090704030805070501010609-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 11:56:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5778C16A400 for ; Mon, 26 Mar 2007 11:56:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3344F13C44B for ; Mon, 26 Mar 2007 11:56:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org ([192.147.25.65]:63725) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HVnaN-000Ia2-4V; Mon, 26 Mar 2007 06:42:04 -0500 Date: Mon, 26 Mar 2007 06:42:01 -0500 (CDT) From: Larry Rosenman To: Peter Jeremy In-Reply-To: <20070326111702.GD838@turion.vk2pj.dyndns.org> Message-ID: <20070326063907.G59155@thebighonker.lerctr.org> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> <20070326111702.GD838@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 DomainKey-Status: no signature Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 11:56:22 -0000 On Mon, 26 Mar 2007, Peter Jeremy wrote: > On 2007-Mar-25 23:55:26 -0500, Eric Anderson wrote: >> On 03/25/07 09:34, Gavin Atkinson wrote: >>> strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' >>> >>> should still work if it was in a .comment section >> >> Unless you no longer have the running kernel, or it has changed since >> the boot up of the system. A sysctl knob to dump it is *very* useful. > > Note that kern.bootfile will get updated during installkernel. I also > can't think of a situation where I would have lost all copies of my > running kernel as well as the config file that was used to build it. > This could potentially happen if you ran two or more installkernels > without rebooting but I can't think of any reason why I would do that: > If a kernel builds, I am likely to try booting it before going onto > something else. If a kernel doesn't build, it won't install. > > Overall, having the config file loaded strikes me as a waste of RAM. I had a weird situation where the /usr/src directory got trashed, but the system was still up. I did *NOT* have a good copy of the config so had to recreate it. Configs are generally between 4 & 8K, so we're talking 1-2 (maybe 3) pages of memory. In the whole scheme of things, it's not a lot of memory, and would be VERY useful in the case of stupidity like the above, and for other reasons stated upthread. We waste far more memory on other things in the system. 1-3 pages for this kind of USEFUL info is not a waste IMHO. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 12:26:27 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEA6216A400 for ; Mon, 26 Mar 2007 12:26:27 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4328113C48A for ; Mon, 26 Mar 2007 12:26:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l2QCQOvw077761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 16:26:24 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l2QCQN1J077760; Mon, 26 Mar 2007 16:26:24 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 26 Mar 2007 16:26:23 +0400 From: Gleb Smirnoff To: Boris Samorodov Message-ID: <20070326122623.GR2713@FreeBSD.org> References: <20070325133125.X899@free.home.local> <20070325164936.K928@free.home.local> <54646144@bsam.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="R92lf0Oi2sxyK3LA" Content-Disposition: inline In-Reply-To: <54646144@bsam.ru> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 12:26:27 -0000 --R92lf0Oi2sxyK3LA Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Boris, Yuriy, On Mon, Mar 26, 2007 at 03:33:03AM +0400, Boris Samorodov wrote: B> On Sun, 25 Mar 2007 16:57:35 +0400 (MSD) Yuriy Tsibizov wrote: B> B> > > I'm getting repeatable panic with kernel & userland from yesterday B> > > evening when I try to connect to Internet using bluetooth to connect B> > > to my phone: B> > > "rfcomm_pppd -a e60 -c -C dun -l mts". B> B> > The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). B> > It does not panic (in rtsock.c) when I use mpd. B> B> The same here, panic when ppp is started. Any news? Can you please try the attached patch? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --R92lf0Oi2sxyK3LA Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="rtsock.c.diff" Index: rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.140 diff -u -p -r1.140 rtsock.c --- rtsock.c 22 Mar 2007 10:51:03 -0000 1.140 +++ rtsock.c 26 Mar 2007 09:44:53 -0000 @@ -514,7 +514,9 @@ route_output(struct mbuf *m, struct sock senderr(error); RT_LOCK(rt); } - if (info.rti_ifa != rt->rt_ifa && rt->rt_ifa != NULL && + if (info.rti_ifa != NULL && + info.rti_ifa != rt->rt_ifa && + rt->rt_ifa != NULL && rt->rt_ifa->ifa_rtrequest != NULL) { rt->rt_ifa->ifa_rtrequest(RTM_DELETE, rt, &info); @@ -528,12 +530,11 @@ route_output(struct mbuf *m, struct sock } rt->rt_flags |= RTF_GATEWAY; } - if (info.rti_ifa != rt->rt_ifa) { + if (info.rti_ifa != NULL && + info.rti_ifa != rt->rt_ifa) { + IFAREF(info.rti_ifa); rt->rt_ifa = info.rti_ifa; - if (info.rti_ifa != NULL) { - IFAREF(info.rti_ifa); - rt->rt_ifp = info.rti_ifp; - } + rt->rt_ifp = info.rti_ifp; } /* Allow some flags to be toggled on change. */ if (rtm->rtm_fmask & RTF_FMASK) --R92lf0Oi2sxyK3LA-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:09:07 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7CDA16A403; Mon, 26 Mar 2007 13:09:07 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE9913C46E; Mon, 26 Mar 2007 13:09:07 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from darklight.abyss.local (darklight.abyss.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 1C9FA62D456; Mon, 26 Mar 2007 16:58:04 +0400 (MSD) Received: from darklight.abyss.local (yuri@localhost [127.0.0.1]) by darklight.abyss.local (8.13.8/8.13.8) with ESMTP id l2QCvc0b000974; Mon, 26 Mar 2007 16:57:39 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) Received: (from yuri@localhost) by darklight.abyss.local (8.13.8/8.13.8/Submit) id l2QCvafI000969; Mon, 26 Mar 2007 16:57:36 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) X-Authentication-Warning: darklight.abyss.local: yuri set sender to y.pankov@irbis.net.ru using -f Date: Mon, 26 Mar 2007 16:57:35 +0400 From: Yuri Pankov To: Gleb Smirnoff Message-ID: <20070326125734.GA915@darklight.abyss.local> References: <20070325133125.X899@free.home.local> <20070325164936.K928@free.home.local> <54646144@bsam.ru> <20070326122623.GR2713@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20070326122623.GR2713@FreeBSD.org> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: ClamAV 0.90.1/2931/Mon Mar 26 12:43:40 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Mon, 26 Mar 2007 16:58:05 +0400 (MSD) Cc: freebsd-current@FreeBSD.org Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 13:09:07 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 26, 2007 at 04:26:23PM +0400, Gleb Smirnoff wrote: > Boris, Yuriy, >=20 > On Mon, Mar 26, 2007 at 03:33:03AM +0400, Boris Samorodov wrote: > B> On Sun, 25 Mar 2007 16:57:35 +0400 (MSD) Yuriy Tsibizov wrote: > B>=20 > B> > > I'm getting repeatable panic with kernel & userland from yesterday > B> > > evening when I try to connect to Internet using bluetooth to conne= ct > B> > > to my phone: > B> > > "rfcomm_pppd -a e60 -c -C dun -l mts". > B>=20 > B> > The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). > B> > It does not panic (in rtsock.c) when I use mpd. > B>=20 > B> The same here, panic when ppp is started. Any news? >=20 > Can you please try the attached patch? >=20 > --=20 > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE Hi Gleb, I haven't tried to backout last rtsock.c revision, but patch fixes problem for me. Thank you --=20 Yuri --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGB8M+8hBlB0qMSXYRAhkIAKDCieWfiL1lothCj9qZlxoe3llTEwCfagoY 4BIN6pGpXwifQbsq28A9PrQ= =Vfhl -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:12:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FAE716A402 for ; Mon, 26 Mar 2007 13:12:35 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1040E13C484 for ; Mon, 26 Mar 2007 13:12:34 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l2QDCXFh057633; Mon, 26 Mar 2007 08:12:34 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4607C6C1.40301@freebsd.org> Date: Mon, 26 Mar 2007 08:12:33 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Peter Jeremy References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> <20070326111702.GD838@turion.vk2pj.dyndns.org> In-Reply-To: <20070326111702.GD838@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2931/Mon Mar 26 03:43:40 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 13:12:35 -0000 On 03/26/07 06:17, Peter Jeremy wrote: > On 2007-Mar-25 23:55:26 -0500, Eric Anderson wrote: >> On 03/25/07 09:34, Gavin Atkinson wrote: >>> strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' >>> >>> should still work if it was in a .comment section >> Unless you no longer have the running kernel, or it has changed since >> the boot up of the system. A sysctl knob to dump it is *very* useful. > > Note that kern.bootfile will get updated during installkernel. I also > can't think of a situation where I would have lost all copies of my > running kernel as well as the config file that was used to build it. > This could potentially happen if you ran two or more installkernels > without rebooting but I can't think of any reason why I would do that: > If a kernel builds, I am likely to try booting it before going onto > something else. If a kernel doesn't build, it won't install. > > Overall, having the config file loaded strikes me as a waste of RAM. > As Larry mentioned, the kernel config file (say GENERIC) is about 10k uncompressed. If it's bzipped or gzipped, as it is (including comments, etc) it ends up ~4k. My kernel, is about 7500k (not far from GENERIC), so the additional .05% is probably not noticeable by anyone. One reason you might not have the kernel lying around is because the system is net booted, so the kernel was sent across the network. You might have many different kernel configs running, and the kernel file may not be available to the hosts. Anyway, to me, the extra few kb in the kernel is not going to be noticeable by anyone except a small fraction of the users, and those users are already removing tons of stuff and have a very stripped down kernel anyhow. So, they can have a "options NO_INCLUDE_CONFIG" that will save them the 4kb if they want. It's hard for me to argue against having it in GENERIC, since the additional size is minimal (negligible actually), there are no adverse side affects, and there is great benefit for those of us who actually can think of situations where it would be helpful, and of course you can always optionally remove it. Eric From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:13:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00A9616A400 for ; Mon, 26 Mar 2007 13:13:17 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.freebsd.org (Postfix) with ESMTP id 774FD13C46A for ; Mon, 26 Mar 2007 13:13:16 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id l2QDDDTd009435; Mon, 26 Mar 2007 14:13:13 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id l2QDDCF0045618; Mon, 26 Mar 2007 14:13:13 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id l2QDDCJ7045617; Mon, 26 Mar 2007 14:13:12 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Larry Rosenman In-Reply-To: <20070326063907.G59155@thebighonker.lerctr.org> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> <20070326111702.GD838@turion.vk2pj.dyndns.org> <20070326063907.G59155@thebighonker.lerctr.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2007 14:13:11 +0100 Message-Id: <1174914791.44767.17.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 13:13:17 -0000 On Mon, 2007-03-26 at 06:42 -0500, Larry Rosenman wrote: > On Mon, 26 Mar 2007, Peter Jeremy wrote: > > > On 2007-Mar-25 23:55:26 -0500, Eric Anderson wrote: > >> On 03/25/07 09:34, Gavin Atkinson wrote: > >>> strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' > >>> > >>> should still work if it was in a .comment section > >> > >> Unless you no longer have the running kernel, or it has changed since > >> the boot up of the system. A sysctl knob to dump it is *very* useful. > > > > Note that kern.bootfile will get updated during installkernel. I also > > can't think of a situation where I would have lost all copies of my > > running kernel as well as the config file that was used to build it. > > This could potentially happen if you ran two or more installkernels > > without rebooting but I can't think of any reason why I would do that: > > If a kernel builds, I am likely to try booting it before going onto > > something else. If a kernel doesn't build, it won't install. > > > > Overall, having the config file loaded strikes me as a waste of RAM. > > I had a weird situation where the /usr/src directory got trashed, but the > system was still up. I did *NOT* have a good copy of the config so had > to recreate it. ... but you had the running kernel in /boot/kernel? In which case, a .comment section would be fine. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:27:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84E0716A401 for ; Mon, 26 Mar 2007 13:27:34 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id E324D13C469 for ; Mon, 26 Mar 2007 13:27:33 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l2QDw8sm013730 for ; Mon, 26 Mar 2007 13:58:09 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l2QDw7FO013729 for freebsd-current@freebsd.org; Mon, 26 Mar 2007 13:58:07 GMT (envelope-from dunstan) Date: Mon, 26 Mar 2007 13:58:06 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org Message-ID: <20070326135806.GA13651@FreeBSD.czest.pl> Mail-Followup-To: "Wojciech A. Koszek" , freebsd-current@freebsd.org References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <4607523E.50201@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Mon, 26 Mar 2007 13:58:09 +0000 (UTC) Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 13:27:34 -0000 On Sun, Mar 25, 2007 at 11:55:26PM -0500, Eric Anderson wrote: > On 03/25/07 09:34, Gavin Atkinson wrote: > >On Sat, 24 Mar 2007, Wojciech A. Koszek wrote: > >>On Sun, Mar 25, 2007 at 08:00:41AM +1000, Peter Jeremy wrote: [..] > >strings `sysctl -n kern.bootfile` | grep ^___ | sed -e 's/^___//' > > > >should still work if it was in a .comment section > > > Unless you no longer have the running kernel, or it has changed since > the boot up of the system. A sysctl knob to dump it is *very* useful. The main intention of my work is ask beggining user if he has specific option compiled into the kernel, and do it as easy, as typing "kldstat" for checking, if he has required KLD loaded. Yes, it is useful there. config -k , where the can be either /boot/kernel/kernel or kernel from port-mortem analysisshould be also quite useful. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:32:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BD0916A402 for ; Mon, 26 Mar 2007 13:32:45 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id B4A3813C44C for ; Mon, 26 Mar 2007 13:32:44 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l2QE3Ku3013770 for ; Mon, 26 Mar 2007 14:03:20 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l2QE3JiR013769 for freebsd-current@freebsd.org; Mon, 26 Mar 2007 14:03:19 GMT (envelope-from dunstan) Date: Mon, 26 Mar 2007 14:03:18 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org Message-ID: <20070326140317.GB13651@FreeBSD.czest.pl> Mail-Followup-To: "Wojciech A. Koszek" , freebsd-current@freebsd.org References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> <1174902256.44767.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <1174902256.44767.3.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Mon, 26 Mar 2007 14:03:20 +0000 (UTC) Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 13:32:45 -0000 On Mon, Mar 26, 2007 at 10:44:16AM +0100, Gavin Atkinson wrote: > On Sun, 2007-03-25 at 23:55 -0500, Eric Anderson wrote: > > On 03/25/07 09:34, Gavin Atkinson wrote: [..] > Note that I'm not against the suggestion, I just don't think I see the > point. In the first post, I mentioned about additional system interface (sysctl), and the extended config(8), that will be able to obtain configuration from the "offline" kernel, such as: config -k /boot/kernel.old/kernel Or config -k /mnt/boot/kernel/kernel I didn't say that the feature will be removed. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 13:35:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FDF916A400 for ; Mon, 26 Mar 2007 13:35:57 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id BA89A13C457 for ; Mon, 26 Mar 2007 13:35:54 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from localhost ([127.0.0.1] helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1HVpMX-0004pJ-0B; Mon, 26 Mar 2007 16:35:53 +0300 Received: from kozlov by ravenloft.kiev.ua with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HVpMC-000PKA-Jg; Mon, 26 Mar 2007 16:35:32 +0300 Date: Mon, 26 Mar 2007 16:35:32 +0300 From: Alex Kozlov To: Eric Anderson , freebsd-current@freebsd.org Message-ID: <20070326133532.GA97275@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis detailz: (0.0 points, 10.0 required) X-Mailman-Approved-At: Mon, 26 Mar 2007 13:59:06 +0000 Cc: Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 13:35:57 -0000 On Mon, Mar 26, 2007 at 08:12:33AM -0500, Eric Anderson wrote: > >Overall, having the config file loaded strikes me as a waste of RAM. > > > As Larry mentioned, the kernel config file (say GENERIC) is about 10k > uncompressed. If it's bzipped or gzipped, as it is (including comments, > etc) it ends up ~4k. My kernel, is about 7500k (not far from GENERIC), > so the additional .05% is probably not noticeable by anyone. gzip is a bad idea. If You compress config, strings kernel | grep ^___ | sed -e 's/^___//' would no longer work. -- Adios From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 14:44:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 048F816A401 for ; Mon, 26 Mar 2007 14:44:03 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id CD18B13C44B for ; Mon, 26 Mar 2007 14:44:02 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l2QEi2ho074711; Mon, 26 Mar 2007 09:44:02 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4607DC32.1010700@freebsd.org> Date: Mon, 26 Mar 2007 09:44:02 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Alex Kozlov References: <20070326133532.GA97275@ravenloft.kiev.ua> In-Reply-To: <20070326133532.GA97275@ravenloft.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2931/Mon Mar 26 03:43:40 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 14:44:03 -0000 On 03/26/07 08:35, Alex Kozlov wrote: > On Mon, Mar 26, 2007 at 08:12:33AM -0500, Eric Anderson wrote: >>> Overall, having the config file loaded strikes me as a waste of RAM. >>> >> As Larry mentioned, the kernel config file (say GENERIC) is about 10k >> uncompressed. If it's bzipped or gzipped, as it is (including comments, >> etc) it ends up ~4k. My kernel, is about 7500k (not far from GENERIC), >> so the additional .05% is probably not noticeable by anyone. > gzip is a bad idea. If You compress config, > strings kernel | grep ^___ | sed -e 's/^___//' > would no longer work. Good point. So, leaving it uncompressed makes it 0.1% of the kernel. :) Still ok by me. Eric From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 16:25:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B729E16A400 for ; Mon, 26 Mar 2007 16:25:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0CA13C468 for ; Mon, 26 Mar 2007 16:25:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id BFB2B20C33F; Mon, 26 Mar 2007 12:25:17 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 26 Mar 2007 12:25:17 -0400 X-Sasl-enc: WQqmy/I/H3VMy1ZPbo59dm/9T32ARQhrYuE+tjfMxtdD 1174926317 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 44B4F1135E; Mon, 26 Mar 2007 12:25:17 -0400 (EDT) Message-ID: <4607F3EA.30902@FreeBSD.org> Date: Mon, 26 Mar 2007 17:25:14 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Tom Uffner References: <4607893B.3080409@uffner.com> In-Reply-To: <4607893B.3080409@uffner.com> Content-Type: multipart/mixed; boundary="------------060906000603030708070900" Cc: freebsd-current@freebsd.org Subject: Re: current panics when Netgear WG511T ejected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 16:25:17 -0000 This is a multi-part message in MIME format. --------------060906000603030708070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please try this patch. Regards, BMS --------------060906000603030708070900 Content-Type: text/x-patch; name="if.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if.c.diff" ==== //depot/user/bms/netdev/sys/net/if.c#10 - /home/bms/p4/netdev/sys/net/if.c ==== --- /tmp/tmp.1084.0 Mon Mar 26 17:18:47 2007 +++ /home/bms/p4/netdev/sys/net/if.c Mon Mar 26 17:18:33 2007 @@ -2513,19 +2513,19 @@ * If the ifnet is detaching, null out references to ifnet, * so that upper protocol layers will notice, and not attempt * to obtain locks for an ifnet which no longer exists. - * It is OK to call rt_newmaddrmsg() with a NULL ifp. + * XXX: rt_newaddrmsg() needs to be called before the ifnet instance + * is detached from the system interface list. */ if (detaching) { #ifdef DIAGNOSTIC printf("%s: detaching ifnet instance %p\n", __func__, ifp); #endif + rt_newmaddrmsg(RTM_DELMADDR, ifma); ifma->ifma_ifp = NULL; } if (--ifma->ifma_refcount > 0) return 0; - - rt_newmaddrmsg(RTM_DELMADDR, ifma); /* * If this ifma is a network-layer ifma, a link-layer ifma may --------------060906000603030708070900-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 16:39:43 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E1CE16A478 for ; Mon, 26 Mar 2007 16:39:43 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id 65DDC13C457 for ; Mon, 26 Mar 2007 16:39:42 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l2QHAIPO016766 for ; Mon, 26 Mar 2007 17:10:18 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l2QHAHjX016765 for freebsd-current@FreeBSD.ORG; Mon, 26 Mar 2007 17:10:18 GMT (envelope-from dunstan) Date: Mon, 26 Mar 2007 17:10:16 +0000 From: "Wojciech A. Koszek" To: freebsd-current@FreeBSD.ORG Message-ID: <20070326171016.GA16746@FreeBSD.czest.pl> Mail-Followup-To: "Wojciech A. Koszek" , freebsd-current@FreeBSD.ORG References: <20070324135333.GA86105@FreeBSD.czest.pl> <200703261347.l2QDl6rM021066@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <200703261347.l2QDl6rM021066@lurza.secnetix.de> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Mon, 26 Mar 2007 17:10:18 +0000 (UTC) Cc: Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 16:39:43 -0000 On Mon, Mar 26, 2007 at 03:47:06PM +0200, Oliver Fromme wrote: > Wojciech A. Koszek wrote: > > Alex Kozlov wrote: > > > Wojciech A. Koszek wrote: > > > > Current implementation of INCLUDE_CONFIG_FILE option has number of > > > > issues. Including it in MAC or SMP configurations will bring only text > > > > of this single file into the kernel file. We're not able to see > > > > configuration of running ("live") kernel, which could be helpful while > > > > tracking users' reports. You can't get easy to use file format, ready > > > > for configuration process. > > > > > > > > In my Perforce wkoszek_kconftxt branch: > > > > > > > > //depot/user/wkoszek/wkoszek_kconftxt/... > > > > > > > > I brought some modifications to existing config(8) and added system > > > > interface that would let us to see configuration of running kernel > > > > (currently -- via kern.conftxt sysctl), as well as other kernel file > > > > through config(8)'s -k option. > > > > > > By the way, any plan to include INCLUDE_CONFIG_FILE in GENERIC? > > > > I'd like to have this enabled by default, and I know there should be no > > strong objections. > > No objection from me, but please fix it so include files > are also included in the kernel. > > Many of my kernel config files have only few lines (e.g. > "options SMP" and "include MYKERNEL"). Currently, the > INCLUDE_CONFIG_FILE feature only includes those two lines, > rendering that feature useless (and even potentially > dangerous if someone relies on his config to be in the > kernel). You'll get full configuration file, no matter what you include. After redirecting it to file, you'll be able to compile the kernel with no additional modifications. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 17:29:49 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10F8816A405 for ; Mon, 26 Mar 2007 17:29:49 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A0A9113C4FB for ; Mon, 26 Mar 2007 17:29:48 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003646534.msg; Mon, 26 Mar 2007 18:14:27 +0100 Message-ID: <036601c76fca$31f427f0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Wojciech A. Koszek" , References: <20070324135333.GA86105@FreeBSD.czest.pl><200703261347.l2QDl6rM021066@lurza.secnetix.de> <20070326171016.GA16746@FreeBSD.czest.pl> Date: Mon, 26 Mar 2007 18:14:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-Spam-Processed: multiplay.co.uk, Mon, 26 Mar 2007 18:14:27 +0100 X-MDAV-Processed: multiplay.co.uk, Mon, 26 Mar 2007 18:14:28 +0100 Cc: Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 17:29:49 -0000 Wojciech A. Koszek wrote: > You'll get full configuration file, no matter what you include. After > redirecting it to file, you'll be able to compile the kernel with no > additional modifications. Please make is so, had this already been the case would have saved many an hour trying to determine strange failures after loosing a machines original config and hence having to recreate from scratch. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 14:16:00 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C2B816A413; Mon, 26 Mar 2007 14:16:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9FC13C4C9; Mon, 26 Mar 2007 14:15:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (sjivid@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l2QDl6Fp021067; Mon, 26 Mar 2007 15:47:12 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l2QDl6rM021066; Mon, 26 Mar 2007 15:47:06 +0200 (CEST) (envelope-from olli) Date: Mon, 26 Mar 2007 15:47:06 +0200 (CEST) Message-Id: <200703261347.l2QDl6rM021066@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, Alex Kozlov , wkoszek@FreeBSD.ORG In-Reply-To: <20070324135333.GA86105@FreeBSD.czest.pl> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 26 Mar 2007 15:47:12 +0200 (CEST) X-Mailman-Approved-At: Mon, 26 Mar 2007 18:08:58 +0000 Cc: Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, Alex Kozlov , wkoszek@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 14:16:00 -0000 Wojciech A. Koszek wrote: > Alex Kozlov wrote: > > Wojciech A. Koszek wrote: > > > Current implementation of INCLUDE_CONFIG_FILE option has number of > > > issues. Including it in MAC or SMP configurations will bring only text > > > of this single file into the kernel file. We're not able to see > > > configuration of running ("live") kernel, which could be helpful while > > > tracking users' reports. You can't get easy to use file format, ready > > > for configuration process. > > > > > > In my Perforce wkoszek_kconftxt branch: > > > > > > //depot/user/wkoszek/wkoszek_kconftxt/... > > > > > > I brought some modifications to existing config(8) and added system > > > interface that would let us to see configuration of running kernel > > > (currently -- via kern.conftxt sysctl), as well as other kernel file > > > through config(8)'s -k option. > > > > By the way, any plan to include INCLUDE_CONFIG_FILE in GENERIC? > > I'd like to have this enabled by default, and I know there should be no > strong objections. No objection from me, but please fix it so include files are also included in the kernel. Many of my kernel config files have only few lines (e.g. "options SMP" and "include MYKERNEL"). Currently, the INCLUDE_CONFIG_FILE feature only includes those two lines, rendering that feature useless (and even potentially dangerous if someone relies on his config to be in the kernel). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch�ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M�n- chen, HRB 125758, Gesch�ftsf�hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 18:21:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22A6116A404 for ; Mon, 26 Mar 2007 18:21:53 +0000 (UTC) (envelope-from ralph.zitz@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id D78E213C48C for ; Mon, 26 Mar 2007 18:21:52 +0000 (UTC) (envelope-from ralph.zitz@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1719049nza for ; Mon, 26 Mar 2007 11:21:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=H8zjP5B5QXkY8BwhwX6KI1S2d7h7d+u53Eog4QBAkVzJEcZpdEexxB6jUop3urOmBquDJiRdgVUe6oV0rMtr1S2of0c/3dClTsiEdCensBYcDzTfzOaUNV34xBzlem/vnpFJznHZt/18uhgpbTQOXUHEETZ4EnMxttx7BBLHZ4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tC7f5wNEoAKKwKFjwE3CLebqSbUQiofhxfHJ1mg560HZAjzbg7PJdY+8yyiyiM3jBYiF3b58lPxOjy/Lav/Tyd477CN4+jWljFWuBH0cHd0lqVAAvn3ZcOe1AN1q/EZ4VO/LHKJhgeadF6m9o/SgcPTXnSXBvTXO24VGkDmDjUA= Received: by 10.65.219.1 with SMTP id w1mr13556728qbq.1174931708822; Mon, 26 Mar 2007 10:55:08 -0700 (PDT) Received: by 10.64.148.16 with HTTP; Mon, 26 Mar 2007 10:55:08 -0700 (PDT) Message-ID: Date: Mon, 26 Mar 2007 19:55:08 +0200 From: "Ralph Zitz" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem compiling kernel on current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 18:21:53 -0000 Hello In the last couple of days I have had trouble compiling the kernel. A few days ago I cvsup'ed the sources on my -current box, and this is what I get when I try and compile the kernel. Can anyone tell me what might be wrong here? Note that I completely deleted /usr/src to make sure everything was updated before building. ===> crypto (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include ln -sf /usr/obj/usr/src/sys/mobile/opt_param.h opt_param.h ln -sf /usr/obj/usr/src/sys/mobile/opt_ddb.h opt_ddb.h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/mobile /usr/src/sys/modules/crypto/../../opencrypto/crypto.c cryptodev_if.c /usr/src/sys/modules/crypto/../../opencrypto/criov.c /usr/src/sys/modules/crypto/../../opencrypto/cryptosoft.c /usr/src/sys/modules/crypto/../../opencrypto/xform.c /usr/src/sys/modules/crypto/../../opencrypto/cast.c /usr/src/sys/modules/crypto/../../opencrypto/deflate.c /usr/src/sys/modules/crypto/../../opencrypto/rmd160.c /usr/src/sys/modules/crypto/../../crypto/rijndael/rijndael-alg-fst.c/usr/src/sys/modules/crypto/../../crypto/rijndael/rijndael- api.c /usr/src/sys/modules/crypto/../../opencrypto/skipjack.c /usr/src/sys/modules/crypto/../../crypto/blowfish/bf_enc.c /usr/src/sys/modules/crypto/../../crypto/blowfish/bf_skey.c /usr/src/sys/modules/crypto/../../crypto/des/des_ecb.c /usr/src/sys/modules/crypto/../../crypto/des/des_enc.c /usr/src/sys/modules/crypto/../../crypto/des/des_setkey.c /usr/src/sys/modules/crypto/../../crypto/sha1.c /usr/src/sys/modules/crypto/../../crypto/sha2/sha2.c ===> cryptodev (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/mobile /usr/src/sys/modules/cryptodev/../../opencrypto/cryptodev.c In file included from /usr/src/sys/modules/cryptodev/../../opencrypto/cryptodev.c:54: @/sys/bus.h:513:23: device_if.h: No such file or directory @/sys/bus.h:514:20: bus_if.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 18:27:26 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 528FC16A400 for ; Mon, 26 Mar 2007 18:27:26 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id BE50D13C4AD for ; Mon, 26 Mar 2007 18:27:23 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([85.172.12.219]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l2QIQwOj014034; Mon, 26 Mar 2007 22:27:09 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HVtuG-0000E6-Qj; Mon, 26 Mar 2007 22:27:00 +0400 To: Gleb Smirnoff References: <20070325133125.X899@free.home.local> <20070325164936.K928@free.home.local> <54646144@bsam.ru> <20070326122623.GR2713@FreeBSD.org> <20070326125734.GA915@darklight.abyss.local> From: Boris Samorodov Date: Mon, 26 Mar 2007 22:27:00 +0400 In-Reply-To: <20070326125734.GA915@darklight.abyss.local> (Yuri Pankov's message of "Mon, 26 Mar 2007 16:57:35 +0400") Message-ID: <01038459@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: freebsd-current@FreeBSD.org Subject: Re: panic in rtsock.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 18:27:26 -0000 Gleb, On Mon, 26 Mar 2007 16:57:35 +0400 Yuri Pankov wrote: > On Mon, Mar 26, 2007 at 04:26:23PM +0400, Gleb Smirnoff wrote: > > On Mon, Mar 26, 2007 at 03:33:03AM +0400, Boris Samorodov wrote: > > B> On Sun, 25 Mar 2007 16:57:35 +0400 (MSD) Yuriy Tsibizov wrote: > > B> > > B> > > I'm getting repeatable panic with kernel & userland from yesterday > > B> > > evening when I try to connect to Internet using bluetooth to connect > > B> > > to my phone: > > B> > > "rfcomm_pppd -a e60 -c -C dun -l mts". > > B> > > B> > The same panic accurs when I use /usr/sbin/ppp (with old V.34 modem). > > B> > It does not panic (in rtsock.c) when I use mpd. > > B> > > B> The same here, panic when ppp is started. Any news? > > > > Can you please try the attached patch? > I haven't tried to backout last rtsock.c revision, but patch fixes problem > for me. +1. The patch helped. > Thank you Thanks for the quick patch! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 18:38:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F86716A403 for ; Mon, 26 Mar 2007 18:38:41 +0000 (UTC) (envelope-from SRS1=ac8bec1153d1cc3760f5feda3c32f9cb6e83ba04=es.net==ac8bec1153d1cc3760f5feda3c32f9cb6e83ba04=286=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 30D1813C44C for ; Mon, 26 Mar 2007 18:38:41 +0000 (UTC) (envelope-from SRS1=ac8bec1153d1cc3760f5feda3c32f9cb6e83ba04=es.net==ac8bec1153d1cc3760f5feda3c32f9cb6e83ba04=286=es.net=oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id FVA27941 for ; Mon, 26 Mar 2007 11:26:41 -0700 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id FVA40139 for ; Mon, 26 Mar 2007 11:26:39 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DFDB045042 for ; Mon, 26 Mar 2007 11:26:38 -0700 (PDT) To: current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1174933598_70662P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2007 11:26:38 -0700 From: "Kevin Oberman" Message-Id: <20070326182638.DFDB045042@ptavv.es.net> Cc: Subject: network problems with yesterday's current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 18:38:41 -0000 --==_Exmh_1174933598_70662P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Running current of Mar. 25 at about 23:45 UTC. I am having an odd problem with my on-board bge. I can do most things without problems. I ssh into remote systems via IPv4 or IPv6. I can browse the web without issues and use finger. DNS is fine. I can't "fetch" a file. % fetch http://www.bytelabs.org/pb-browser-0.4.tgz fetch: http://www.bytelabs.org/pb-browser-0.4.tgz: Connection refused I can get this file with my browser, though. fetch(1) also fails in the same way for FTP access. This is an example, but any fetch(1) seems to fail this way. Also, my gnome-weather-applet also fails over bge0. When I am connected by my wireless (ath0), this all works fine. I turned off my firewall and ran tcpdump. It saw NO packets when I tried this (tcpdump -vp tcp). The interface shows no errors. I suspect that the same thing was happening with a Mar. 19 kernel, but I can't absolutely confirm this right now. I don't have a clue of where to even look for this. Any suggestions would be appreciated. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1174933598_70662P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGCBBekn3rs5h7N1ERAnooAJ4wlLKXYyo+SWszj0UjWJCrWBuJgACfcujm JWdTbm/lziff9iDCEbeFBvs= =R1jl -----END PGP SIGNATURE----- --==_Exmh_1174933598_70662P-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 18:39:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C03E816A405 for ; Mon, 26 Mar 2007 18:39:22 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A81F13C46E for ; Mon, 26 Mar 2007 18:39:22 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2QIdLAr060703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 11:39:22 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46081359.6020708@errno.com> Date: Mon, 26 Mar 2007 11:39:21 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: Ralph Zitz References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problem compiling kernel on current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 18:39:22 -0000 Ralph Zitz wrote: > Hello > > In the last couple of days I have had trouble compiling the kernel. > A few days ago I cvsup'ed the sources on my -current box, and this is > what I > get when I try and compile the kernel. Can anyone tell me what might be > wrong here? Note that I completely deleted /usr/src to make sure everything > was updated before building. > > ===> crypto (depend) > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > ln -sf /usr/obj/usr/src/sys/mobile/opt_param.h opt_param.h > ln -sf /usr/obj/usr/src/sys/mobile/opt_ddb.h opt_ddb.h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c > awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/obj/usr/src/sys/mobile > /usr/src/sys/modules/crypto/../../opencrypto/crypto.c cryptodev_if.c > /usr/src/sys/modules/crypto/../../opencrypto/criov.c > /usr/src/sys/modules/crypto/../../opencrypto/cryptosoft.c > /usr/src/sys/modules/crypto/../../opencrypto/xform.c > /usr/src/sys/modules/crypto/../../opencrypto/cast.c > /usr/src/sys/modules/crypto/../../opencrypto/deflate.c > /usr/src/sys/modules/crypto/../../opencrypto/rmd160.c > /usr/src/sys/modules/crypto/../../crypto/rijndael/rijndael-alg-fst.c/usr/src/sys/modules/crypto/../../crypto/rijndael/rijndael- > > api.c /usr/src/sys/modules/crypto/../../opencrypto/skipjack.c > /usr/src/sys/modules/crypto/../../crypto/blowfish/bf_enc.c > /usr/src/sys/modules/crypto/../../crypto/blowfish/bf_skey.c > /usr/src/sys/modules/crypto/../../crypto/des/des_ecb.c > /usr/src/sys/modules/crypto/../../crypto/des/des_enc.c > /usr/src/sys/modules/crypto/../../crypto/des/des_setkey.c > /usr/src/sys/modules/crypto/../../crypto/sha1.c > /usr/src/sys/modules/crypto/../../crypto/sha2/sha2.c > ===> cryptodev (depend) > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/obj/usr/src/sys/mobile > /usr/src/sys/modules/cryptodev/../../opencrypto/cryptodev.c > In file included from > /usr/src/sys/modules/cryptodev/../../opencrypto/cryptodev.c:54: > @/sys/bus.h:513:23: device_if.h: No such file or directory > @/sys/bus.h:514:20: bus_if.h: No such file or directory > mkdep: compile failed Please update again; some changes were missed in the initial commit to this area of the system. Should be correct now. Sam From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 19:12:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90E1916A401 for ; Mon, 26 Mar 2007 19:12:23 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 753C813C43E for ; Mon, 26 Mar 2007 19:12:22 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by mu-out-0910.google.com with SMTP id g7so2849135muf for ; Mon, 26 Mar 2007 12:12:21 -0700 (PDT) Received: by 10.82.175.2 with SMTP id x2mr14451151bue.1174934897297; Mon, 26 Mar 2007 11:48:17 -0700 (PDT) Received: by 10.82.149.16 with HTTP; Mon, 26 Mar 2007 11:48:17 -0700 (PDT) Message-ID: Date: Mon, 26 Mar 2007 21:48:17 +0300 From: "Vlad GALU" To: "Kevin Oberman" In-Reply-To: <20070326182638.DFDB045042@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070326182638.DFDB045042@ptavv.es.net> Cc: current@freebsd.org Subject: Re: network problems with yesterday's current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 19:12:23 -0000 On 3/26/07, Kevin Oberman wrote: > Running current of Mar. 25 at about 23:45 UTC. > > I am having an odd problem with my on-board bge. I can do most things > without problems. I ssh into remote systems via IPv4 or IPv6. I can > browse the web without issues and use finger. DNS is fine. > > I can't "fetch" a file. > % fetch http://www.bytelabs.org/pb-browser-0.4.tgz > fetch: http://www.bytelabs.org/pb-browser-0.4.tgz: Connection refused > I can get this file with my browser, though. fetch(1) also fails in the > same way for FTP access. > > This is an example, but any fetch(1) seems to fail this way. Also, my > gnome-weather-applet also fails over bge0. > > When I am connected by my wireless (ath0), this all works fine. > > I turned off my firewall and ran tcpdump. It saw NO packets when I tried > this (tcpdump -vp tcp). The interface shows no errors. > > I suspect that the same thing was happening with a Mar. 19 kernel, but > I can't absolutely confirm this right now. > > I don't have a clue of where to even look for this. Any suggestions > would be appreciated. A "me too" here. I have lots of processes stuck in tcp state. > -- > 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 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:26:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 579B816A404 for ; Mon, 26 Mar 2007 20:26:03 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from paperboy.b1tt3r.org (206-45-95-183.static.mts.net [206.45.95.183]) by mx1.freebsd.org (Postfix) with ESMTP id 01D6813C4B8 for ; Mon, 26 Mar 2007 20:26:02 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from nibiru.b1tt3r.org ([192.168.1.23]) by paperboy.b1tt3r.org (8.13.6/8.13.6) with SMTP id l2QKMTsI049143 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2007 14:22:29 -0600 (CST) (envelope-from scs@b1tt3r.org) Received: by nibiru.b1tt3r.org (sSMTP sendmail emulation); Mon, 26 Mar 2007 15:17:15 -0500 Date: Mon, 26 Mar 2007 15:17:15 -0500 From: Sam Stein To: freebsd-current@freebsd.org Message-ID: <20070326201715.GA49208@nibiru.b1tt3r.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Organization: b1tt3r X-OS: FreeBSD nibiru.b1tt3r.org 6.2-STABLE i386 User-Agent: Mutt/1.5.14 (2007-02-12) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on paperboy.b1tt3r.org Subject: X wont start after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:26:03 -0000 I'm sure this is probably my fault.. but I figure I might as well post this in case someone else had the same problem. I just upgraded, the same way I always do (the instructions in /usr/src/Makefile) and now X hangs, I think it has something to do with either the delete-old or delete-old-libs target, and I'm wondering if I should recompile X, but in that case... its probably not just X that's having problems... and just so you know, this is a -CURRENT system I am talking about... i'm just emailing from a -STABLE system. Thanks. -- Sam Stein Computer Technician/Programmer Steintech Behold the unborn fetus and Weep salt tears crocodilian; All life is sacred (save, of course, An enemy civilian). From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:48:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8A8016A402; Mon, 26 Mar 2007 20:48:12 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1025B13C4B9; Mon, 26 Mar 2007 20:48:12 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (4ho69yay1g75iy3l@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l2QKNOv4021671; Mon, 26 Mar 2007 12:23:24 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l2QKNNH3021670; Mon, 26 Mar 2007 13:23:23 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Mar 2007 12:23:23 -0800 From: John-Mark Gurney To: Peter Jeremy Message-ID: <20070326202323.GH73385@funkthat.com> Mail-Followup-To: Peter Jeremy , Eric Anderson , freebsd-current@freebsd.org References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> <20070324220041.GI847@turion.vk2pj.dyndns.org> <20070324233307.GA93841@FreeBSD.czest.pl> <20070325153013.E77473@ury.york.ac.uk> <4607523E.50201@freebsd.org> <20070326111702.GD838@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070326111702.GD838@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-current@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:48:12 -0000 Peter Jeremy wrote this message on Mon, Mar 26, 2007 at 21:17 +1000: > This could potentially happen if you ran two or more installkernels > without rebooting but I can't think of any reason why I would do that: installkernel is smart enough only to move kernel to kernel.old if the current bootfile is kernel... So, running installkernel twice won't delete the current running kernel.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:58:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1182B16A402 for ; Mon, 26 Mar 2007 20:58:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id F1AFC13C44B for ; Mon, 26 Mar 2007 20:58:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWQ015293; Mon, 26 Mar 2007 15:58:15 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:05:55 -0400 User-Agent: KMail/1.9.6 References: <45EFC8DD.9030202@KeithPitcher.com> In-Reply-To: <45EFC8DD.9030202@KeithPitcher.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261505.55688.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Keith Pitcher Subject: Re: slow unless CPU is in use, part 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:58:31 -0000 On Thursday 08 March 2007 03:27:09 am Keith Pitcher wrote: > A followup and more information about the system being slow unless the > CPU is in use, then things work well. > > I tried to boot from the latest amd64 snapshot, to see if it was a 6.2 > to 7.0 upgrade issue but the laptop doesn't seem to like it in that it > core dumps almost instantly after the loader starts and I can't see what > scrolls by. I did cvsup today and recompiled everything, but I'm still > having the issue of dragging (Up to 5 seconds to switch ttys if nothing > is running, or for a character to display after being entered). > > I haven't narrowed down what level of CPU usage makes things fast. > Things that I know do the trick are mpg123, or compiling a port.. > > As the hardware worked fine under 6.2 for a week, and I've been using > visual studio under vista without issues (Other than Vista doesn't like > parts of VS 05 that is...), I don't believe there's an issue of an > overheating CPU or other hardware issues. Try sysctl machdep.cpu_idle_hlt=0. It will make yuor machine run warmer though. > pci0: on pcib0 > pcib0: HT Bridge at 0:14:0 has non-default MSI window 0x602000a > pcib0: HT Bridge at 0:16:1 has non-default MSI window 0x0 I would really like to see the output of 'pciconf -lc' on this machine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:58:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE62E16A406; Mon, 26 Mar 2007 20:58:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5091B13C4BC; Mon, 26 Mar 2007 20:58:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWR015293; Mon, 26 Mar 2007 15:58:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:11:03 -0400 User-Agent: KMail/1.9.6 References: <45F0D1F5.9010200@elischer.org> In-Reply-To: <45F0D1F5.9010200@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261511.04364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:28 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Julian Elischer , FreeBSD Current Subject: Re: proc lock might become an sx lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:58:48 -0000 On Thursday 08 March 2007 10:18:13 pm Julian Elischer wrote: > currently the thread list in the process is protected by the sched lock. > for a process with a lot of threads this is probably not a good idea. > I experimented with making it protected by the proc loc, but the following > sort of thing happens a lot: > > sx_slock(&allproc_lock); > FOREACH_PROC_IN_SYSTEM(p) { > mtx_lock_spin(&sched_lock); > FOREACH_THREAD_IN_PROC(p, td) { > ... > } > mtx_unlock_spin(&sched_lock); > > Changing the protection of the thread list to use the proc lock would > replace the sched_lock with the proc lock, but..... > this has a problem.. the proc lock is a mutex and can therefore not be inside the > allproc_lock. > > and in fact you get: > > Trying to mount root from ufs:/dev/aacd0s1d > panic: blockable sleep lock (sleep mutex) process lock @ kern/sched_4bsd.c:383 > cpuid = 2 > KDB: enter: panic > [thread pid 48 tid 100054 ] > Stopped at kdb_enter+0x2b: nop > db> bt > Tracing pid 48 tid 100054 td 0xc5ff4a20 > kdb_enter(c06ce300) at kdb_enter+0x2b > panic(c06d3506,c06e7061,c06cd73b,c06cff47,17f,...) at panic+0x11c > witness_checkorder(c60a12c8,9,c06cff47,17f) at witness_checkorder+0xb8 > _mtx_lock_flags(c60a12c8,0,c06cff3e,17f,85,...) at _mtx_lock_flags+0x87 > schedcpu(e65a9d24,c0516f50,0,e65a9d38,c6259000,...) at schedcpu+0x80 > schedcpu_thread(0,e65a9d38) at schedcpu_thread+0x9 > > My reading of the man page is that making it an sx lock and locking it in > shared mode would be sufficient for this sort of thing (assuming we are not changing > the thread list) and would be just fine. > > I'm not very familiar with the implementation of sx locks in freeBSD so I'm just learning > about them. > > am I reading this right? and does anyone else have any thoughts on this? Use rwlocks to make a mutex have reader/writer semantics but still fit into the current lock order. However, you likely should coordinate sched_lock changes like this with Attilio and Jeff R first as they are removing sched_lock and already have substantial diffs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:58:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE62E16A406; Mon, 26 Mar 2007 20:58:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5091B13C4BC; Mon, 26 Mar 2007 20:58:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWR015293; Mon, 26 Mar 2007 15:58:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:11:03 -0400 User-Agent: KMail/1.9.6 References: <45F0D1F5.9010200@elischer.org> In-Reply-To: <45F0D1F5.9010200@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261511.04364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:28 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Julian Elischer , FreeBSD Current Subject: Re: proc lock might become an sx lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:58:48 -0000 On Thursday 08 March 2007 10:18:13 pm Julian Elischer wrote: > currently the thread list in the process is protected by the sched lock. > for a process with a lot of threads this is probably not a good idea. > I experimented with making it protected by the proc loc, but the following > sort of thing happens a lot: > > sx_slock(&allproc_lock); > FOREACH_PROC_IN_SYSTEM(p) { > mtx_lock_spin(&sched_lock); > FOREACH_THREAD_IN_PROC(p, td) { > ... > } > mtx_unlock_spin(&sched_lock); > > Changing the protection of the thread list to use the proc lock would > replace the sched_lock with the proc lock, but..... > this has a problem.. the proc lock is a mutex and can therefore not be inside the > allproc_lock. > > and in fact you get: > > Trying to mount root from ufs:/dev/aacd0s1d > panic: blockable sleep lock (sleep mutex) process lock @ kern/sched_4bsd.c:383 > cpuid = 2 > KDB: enter: panic > [thread pid 48 tid 100054 ] > Stopped at kdb_enter+0x2b: nop > db> bt > Tracing pid 48 tid 100054 td 0xc5ff4a20 > kdb_enter(c06ce300) at kdb_enter+0x2b > panic(c06d3506,c06e7061,c06cd73b,c06cff47,17f,...) at panic+0x11c > witness_checkorder(c60a12c8,9,c06cff47,17f) at witness_checkorder+0xb8 > _mtx_lock_flags(c60a12c8,0,c06cff3e,17f,85,...) at _mtx_lock_flags+0x87 > schedcpu(e65a9d24,c0516f50,0,e65a9d38,c6259000,...) at schedcpu+0x80 > schedcpu_thread(0,e65a9d38) at schedcpu_thread+0x9 > > My reading of the man page is that making it an sx lock and locking it in > shared mode would be sufficient for this sort of thing (assuming we are not changing > the thread list) and would be just fine. > > I'm not very familiar with the implementation of sx locks in freeBSD so I'm just learning > about them. > > am I reading this right? and does anyone else have any thoughts on this? Use rwlocks to make a mutex have reader/writer semantics but still fit into the current lock order. However, you likely should coordinate sched_lock changes like this with Attilio and Jeff R first as they are removing sched_lock and already have substantial diffs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 634BE16A566; Mon, 26 Mar 2007 20:58:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3207813C46E; Mon, 26 Mar 2007 20:58:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWS015293; Mon, 26 Mar 2007 15:58:34 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:13:26 -0400 User-Agent: KMail/1.9.6 References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> In-Reply-To: <86r6rt6z27.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703261513.27148.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Julian Elischer , FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:01 -0000 On Tuesday 13 March 2007 09:41:20 am Dag-Erling Sm=F8rgrav wrote: > Julian Elischer writes: > > answering myself.. > > comes from having options LOCK_PROFILING in my kernel. > > adding the same to /etc/make.conf and recompiling netstat and libkvm=20 helped. > > (not sure if both are needed) >=20 > This is very bad. LOCK_PROFILING should have no visible effect on > userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: > to isolate userland from kernel structures. They should not contain > any locks or anything else which would be affected by LOCK_PROFILING > or other kernel options. LOCK_PROFILING (and it's predecessor MUTEX_PROFILING) have always resulted = in=20 variant object sizes in the kernel. They shouldn't be visible to userland= =20 though, and fixing xfoo is the right step IMHO. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 634BE16A566; Mon, 26 Mar 2007 20:58:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3207813C46E; Mon, 26 Mar 2007 20:58:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWS015293; Mon, 26 Mar 2007 15:58:34 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:13:26 -0400 User-Agent: KMail/1.9.6 References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> In-Reply-To: <86r6rt6z27.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703261513.27148.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Julian Elischer , FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:01 -0000 On Tuesday 13 March 2007 09:41:20 am Dag-Erling Sm=F8rgrav wrote: > Julian Elischer writes: > > answering myself.. > > comes from having options LOCK_PROFILING in my kernel. > > adding the same to /etc/make.conf and recompiling netstat and libkvm=20 helped. > > (not sure if both are needed) >=20 > This is very bad. LOCK_PROFILING should have no visible effect on > userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: > to isolate userland from kernel structures. They should not contain > any locks or anything else which would be affected by LOCK_PROFILING > or other kernel options. LOCK_PROFILING (and it's predecessor MUTEX_PROFILING) have always resulted = in=20 variant object sizes in the kernel. They shouldn't be visible to userland= =20 though, and fixing xfoo is the right step IMHO. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62A2E16A501; Mon, 26 Mar 2007 20:58:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id E5CA813C455; Mon, 26 Mar 2007 20:58:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWU015293; Mon, 26 Mar 2007 15:58:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:23:09 -0400 User-Agent: KMail/1.9.6 References: <17911.62465.534926.306376@jerusalem.litteratus.org> In-Reply-To: <17911.62465.534926.306376@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261523.09636.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Huff , current@freebsd.org Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:01 -0000 On Wednesday 14 March 2007 09:09:21 am Robert Huff wrote: > > After updating my -CURRENT box to > > FreeBSD 7.0-CURRENT #0: Tue Mar 13 22:38:20 EST 2007 i386 > > one of the network cards was not found at boot. Checking with > pciconf produced: > > none1@pci0:11:0: class=0x020000 card=0x00000000 chip=0x00091011 rev=0x11 hdr=0x00 > vendor = 'Digital Equipment Corporation' > device = 'DecChip 21140 Fast Ethernet Adapter' > class = network > subclass = ethernet > > and loading if_de.ko by hand produced the following: > > de0: port 0xa000 > -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 > de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 > de0: using obsoleted if_watchdog interface > de0: Ethernet address: 00:c0:95:f8:17:af > de0: [GIANT-LOCKED] > de0: [ITHREAD] de(4) hasn't used Giant in a long while now. Do you have really stale sources or something? Maybe debug.mpsafenet=0 is set? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62A2E16A501; Mon, 26 Mar 2007 20:58:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id E5CA813C455; Mon, 26 Mar 2007 20:58:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWU015293; Mon, 26 Mar 2007 15:58:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:23:09 -0400 User-Agent: KMail/1.9.6 References: <17911.62465.534926.306376@jerusalem.litteratus.org> In-Reply-To: <17911.62465.534926.306376@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261523.09636.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Huff , current@freebsd.org Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:02 -0000 On Wednesday 14 March 2007 09:09:21 am Robert Huff wrote: > > After updating my -CURRENT box to > > FreeBSD 7.0-CURRENT #0: Tue Mar 13 22:38:20 EST 2007 i386 > > one of the network cards was not found at boot. Checking with > pciconf produced: > > none1@pci0:11:0: class=0x020000 card=0x00000000 chip=0x00091011 rev=0x11 hdr=0x00 > vendor = 'Digital Equipment Corporation' > device = 'DecChip 21140 Fast Ethernet Adapter' > class = network > subclass = ethernet > > and loading if_de.ko by hand produced the following: > > de0: port 0xa000 > -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 > de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 > de0: using obsoleted if_watchdog interface > de0: Ethernet address: 00:c0:95:f8:17:af > de0: [GIANT-LOCKED] > de0: [ITHREAD] de(4) hasn't used Giant in a long while now. Do you have really stale sources or something? Maybe debug.mpsafenet=0 is set? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB8D16A507 for ; Mon, 26 Mar 2007 20:59:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id A568713C45D for ; Mon, 26 Mar 2007 20:59:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWV015293; Mon, 26 Mar 2007 15:58:56 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:27:34 -0400 User-Agent: KMail/1.9.6 References: <45F87476.8060604@nipsi.de> <4603C6A3.9050404@nipsi.de> In-Reply-To: <4603C6A3.9050404@nipsi.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261527.35147.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:58 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dennis Berger Subject: Re: hp dl360 doesn't boot 7.0 snapshot march. please confirm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:02 -0000 On Friday 23 March 2007 08:22:59 am Dennis Berger wrote: > Can somebody confirm this? > regards, > -Dennis Does turning off VPD fix the hang? > Dennis Berger schrieb: > > Hi list, > > FreeBSD 6.2 can be bootet correctly besides a strange 3 minute timeout > > after da0 has been detected on ciss0 > > FreeBSD 7.0 current from march or feb couldn't be bootet at all the > > kernel stuck after "pci2: on pcib6 found". Normally the > > kernel would find the ciss0 device after that, but it doesn't. and the > > kernel stuck. > > booting in verbose / safe /without acpi / disabling acpi related stuff > > in bios had no effect on this issue. > > Any hints whats going on with ciss driver on dl360 g4p box? > > regards, > > -Dennis > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F6316A507 for ; Mon, 26 Mar 2007 20:59:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EFD6113C45D for ; Mon, 26 Mar 2007 20:59:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWT015293; Mon, 26 Mar 2007 15:58:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:16:44 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261516.45003.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:58:44 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pyunyh@gmail.com Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:59:03 -0000 On Tuesday 13 March 2007 08:02:43 am Danny Braniss wrote: > the question now, is to see if the nfe driver can check if it was > used by the PXE, and flip the address. or have NVIDIA comeup with > a patch ... It could use a hueristic based on the vendor-portion of the MAC address to see if it is flipped. It is probably a bug in the PXE rom when it shuts down the card. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C210716A53D for ; Mon, 26 Mar 2007 20:59:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6668C13C4C3 for ; Mon, 26 Mar 2007 20:59:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWW015293; Mon, 26 Mar 2007 15:59:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 15:54:34 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261554.34864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:59:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pluknet Subject: Re: panic, page fault while in kernel mode (firefox related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:59:03 -0000 On Monday 19 March 2007 08:19:48 pm pluknet wrote: > Hi, > > I got kernel trap 12 with 'Address out of bounds' error (is it considerable?), > while running a firefox-bin on CURRENT as of March 18. It's a x86 UP. > It's not a flash related as in neighbor topic :p (simply because I use > the flashblock > plugin). It silently panicked without any foreign additional effects > like a heavy load > anymore while I worked in another virtual window. Try rebuilding your kernel from scratch. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D18BF16A618; Mon, 26 Mar 2007 20:59:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8079213C457; Mon, 26 Mar 2007 20:59:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWX015293; Mon, 26 Mar 2007 15:59:03 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 16:00:28 -0400 User-Agent: KMail/1.9.6 References: <20070324194418.GA80314@stud.fit.vutbr.cz> In-Reply-To: <20070324194418.GA80314@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261600.29473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:59:04 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Divacky Roman , current@freebsd.org Subject: Re: panic in -current with games/bos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:07 -0000 On Saturday 24 March 2007 03:44:18 pm Divacky Roman wrote: > hi > > I just installed and tried to run games/bos it went well but > when starting a mission the system paniced.. I was in X > so I don't have a panic message. Turn on crash dumps and set debug.debugger_on_panic=0. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 20:59:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D18BF16A618; Mon, 26 Mar 2007 20:59:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8079213C457; Mon, 26 Mar 2007 20:59:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2QKwEWX015293; Mon, 26 Mar 2007 15:59:03 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Mar 2007 16:00:28 -0400 User-Agent: KMail/1.9.6 References: <20070324194418.GA80314@stud.fit.vutbr.cz> In-Reply-To: <20070324194418.GA80314@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261600.29473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Mar 2007 15:59:04 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2934/Mon Mar 26 15:04:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Divacky Roman , current@freebsd.org Subject: Re: panic in -current with games/bos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 20:59:07 -0000 On Saturday 24 March 2007 03:44:18 pm Divacky Roman wrote: > hi > > I just installed and tried to run games/bos it went well but > when starting a mission the system paniced.. I was in X > so I don't have a panic message. Turn on crash dumps and set debug.debugger_on_panic=0. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 21:28:31 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66D7D16A400 for ; Mon, 26 Mar 2007 21:28:31 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [207.245.121.212]) by mx1.freebsd.org (Postfix) with ESMTP id 10E3513C45A for ; Mon, 26 Mar 2007 21:28:30 +0000 (UTC) (envelope-from tom@uffner.com) Received: from kali.uffner.com (static-71-162-143-90.phlapa.fios.verizon.net [71.162.143.90]) by eris.uffner.com (8.13.3/8.13.3) with ESMTP id l2QLST3o084179; Mon, 26 Mar 2007 17:28:29 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <46083AE6.2020600@uffner.com> Date: Mon, 26 Mar 2007 17:28:06 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070324 SeaMonkey/1.1.1 MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4607893B.3080409@uffner.com> <4607F3EA.30902@FreeBSD.org> In-Reply-To: <4607F3EA.30902@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------060503040805080900080705" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (eris.uffner.com [192.168.1.212]); Mon, 26 Mar 2007 17:28:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.6/2931/Mon Mar 26 03:43:40 2007 on eris.uffner.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: current panics when Netgear WG511T ejected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Mar 2007 21:28:31 -0000 This is a multi-part message in MIME format. --------------060503040805080900080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce M. Simpson wrote: > Please try this patch. slightly different this time, but it still panics. seems to be trying to delete nonexistent addresses. should it even be here? i don't have any multicast addrs defined, just one dhcp-assigned unicast addr. ath0: flags=8843 metric 0 mtu 1500 ether 00:0f:b5:22:be:69 inet 10.69.69.151 netmask 0xffffff00 broadcast 10.69.69.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid Doke channel 1 bssid 00:18:01:e4:fa:95 authmode OPEN privacy MIXED deftxkey UNDEF wepkey 1:40-bit txpowmax 36 bmiss 7 protmode CTS burst bintval 100 --------------060503040805080900080705 Content-Type: text/plain; name="kgdb.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kgdb.log" [kali#:/boot/kernel:ttyp2] kgdb kernel.symbols /var/crash/vmcore.3 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <5>ath0: link state changed to DOWN Fatal trap 12: page fault while in kernel mode fault virtual address = 0x50 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05ab9c9 stack pointer = 0x28:0xc7b20b5c frame pointer = 0x28:0xc7b20b9c 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 = 25 (cbb0 event thread) panic: from debugger Uptime: 54s Physical memory: 119 MB Dumping 23 MB: 8 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) add-symbol-file /boot/kernel/if_ath.ko.symbols 0xc0791510 add symbol table from file "/boot/kernel/if_ath.ko.symbols" at .text_addr = 0xc0791510 (y or n) y Reading symbols from /boot/kernel/if_ath.ko.symbols...done. (kgdb) add-symbol-file /boot/kernel/ath_rate.ko.symbols 0xc07a1a50 add symbol table from file "/boot/kernel/ath_rate.ko.symbols" at .text_addr = 0xc07a1a50 (y or n) y Reading symbols from /boot/kernel/ath_rate.ko.symbols...done. (kgdb) add-symbol-file /boot/kernel/wlan.ko.symbols 0xc07aaf00 add symbol table from file "/boot/kernel/wlan.ko.symbols" at .text_addr = 0xc07aaf00 (y or n) y Reading symbols from /boot/kernel/wlan.ko.symbols...done. (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc0508fe6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc050934d in panic (fmt=0xc067fffe "from debugger") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc042eee7 in db_panic (addr=-1067796023, have_addr=0, count=-1, modif=0xc7b20908 "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc042ee70 in db_command (last_cmdp=0xc06de1a4, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #5 0xc042ef55 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #6 0xc04311e5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc052fda5 in kdb_trap (type=0, code=0, tf=0x0) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc066094c in trap_fatal (frame=0xc7b20b1c, eva=80) at /usr/src/sys/i386/i386/trap.c:859 #9 0xc0660625 in trap_pfault (frame=0xc7b20b1c, usermode=0, eva=80) at /usr/src/sys/i386/i386/trap.c:777 #10 0xc066019c in trap (frame=0xc7b20b1c) at /usr/src/sys/i386/i386/trap.c:462 #11 0xc064efab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc05ab9c9 in rt_newmaddrmsg (cmd=-1048376320, ifma=0xc1923c00) at /usr/src/sys/net/rtsock.c:967 #13 0xc05a110c in if_delmulti_locked (ifp=0x0, ifma=0xc1923c00, detaching=1) at /usr/src/sys/net/if.c:2523 #14 0xc059cc76 in if_purgemaddrs (ifp=0xc17c0800) at /usr/src/sys/net/if.c:636 #15 0xc059cdf7 in if_detach (ifp=0xc17c0800) at /usr/src/sys/net/if.c:701 #16 0xc05a3a80 in ether_ifdetach (ifp=0xc17c0800) at /usr/src/sys/net/if_ethersubr.c:924 #17 0xc07ab5a2 in ieee80211_ifdetach (ic=0xc18393c8) at /usr/src/sys/modules/wlan/../../net80211/ieee80211.c:279 #18 0xc079220b in ath_detach (sc=0xc1839000) at /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:669 #19 0xc079b1eb in ath_pci_detach (dev=0xc17e4500) at /usr/src/sys/modules/ath/../../dev/ath/if_ath_pci.c:223 #20 0xc0529a0a in device_detach (dev=0xc17e4500) at device_if.h:211 #21 0xc04549a4 in cardbus_detach_card (cbdev=0xc1755880) at /usr/src/sys/dev/cardbus/cardbus.c:235 #22 0xc0475509 in cbb_removal (sc=0xc1722000) at card_if.h:94 #23 0xc0475077 in cbb_event_thread (arg=0xc1722000) at /usr/src/sys/dev/pccbb/pccbb.c:486 #24 0xc04ecb30 in fork_exit (callout=0xc0474f20 , arg=0xc1830c00, frame=0xc1830c00) at /usr/src/sys/kern/kern_fork.c:814 #25 0xc064f020 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) up 13 #13 0xc05a110c in if_delmulti_locked (ifp=0x0, ifma=0xc1923c00, detaching=1) at /usr/src/sys/net/if.c:2523 2523 rt_newmaddrmsg(RTM_DELMADDR, ifma); (kgdb) up #14 0xc059cc76 in if_purgemaddrs (ifp=0xc17c0800) at /usr/src/sys/net/if.c:636 636 if_delmulti_locked(ifp, ifma, 1); (kgdb) l *0xc059cc76 0xc059cc76 is in if_purgemaddrs (/usr/src/sys/net/if.c:635). 630 { 631 struct ifmultiaddr *ifma; 632 struct ifmultiaddr *next; 633 634 IF_ADDR_LOCK(ifp); 635 TAILQ_FOREACH_SAFE(ifma, &ifp->if_multiaddrs, ifma_link, next) 636 if_delmulti_locked(ifp, ifma, 1); 637 IF_ADDR_UNLOCK(ifp); 638 } 639 (kgdb) q 1.585u 0.151s 11:20.55 0.2% 2484+1180k 23+0io 1pf+0w --------------060503040805080900080705-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 21:28:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B9EB16A402; Mon, 26 Mar 2007 21:28:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id BECB013C468; Mon, 26 Mar 2007 21:28:39 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2QLSciN062038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 14:28:39 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46083B06.9080005@errno.com> Date: Mon, 26 Mar 2007 14:28:38 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Baldwin References: <200703261516.45003.jhb@freebsd.org> In-Reply-To: <200703261516.45003.jhb@freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 21:28:40 -0000 John Baldwin wrote: > On Tuesday 13 March 2007 08:02:43 am Danny Braniss wrote: >> the question now, is to see if the nfe driver can check if it was >> used by the PXE, and flip the address. or have NVIDIA comeup with >> a patch ... > > It could use a hueristic based on the vendor-portion of the MAC address to see > if it is flipped. It is probably a bug in the PXE rom when it shuts down the > card. > Presumably the mac address is from an nvida-assigned block so just check the vendor nibbles... Sam From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 00:05:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8396916A40A for ; Tue, 27 Mar 2007 00:05:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 17F2B13C4FD for ; Tue, 27 Mar 2007 00:05:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1792819nza for ; Mon, 26 Mar 2007 17:05:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=c+ZLOXuGoC6l5S7/n5YqssJ9bmBGcpCHz68kY+bJgRkft6JKK8XqEHCDRL6Tw3RQrIjiFxwMrM0HDZKiyByDBQhsqcVOQRFuMNitNHfNAIyL7P3ADwprbfBFY+jIbSLxJxRA6is4ZnWXGf7ta0yDq+stC5WcwQekqjtvuNheQdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=HSv1STmkCQ4228piUj5g1zM6yVHLmE0cj4RxSRsrw1KzIBe9AtWpYPO27RODAyZPxS5PCNyS7wYT8vpvvhn31JpCOkot8eligVR1f1CrwDQSCnbjYE7XTfxkhAGpCmtxP2zbewhIXopLfyVPfqpV5umjQSZFgLqlWc5dKIHIv8Y= Received: by 10.64.199.2 with SMTP id w2mr14221686qbf.1174953949261; Mon, 26 Mar 2007 17:05:49 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 39sm39844453nzk.2007.03.26.17.05.46; Mon, 26 Mar 2007 17:05:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l2R0B3Fx046105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 09:11:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2R0B3x7046104; Tue, 27 Mar 2007 09:11:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 27 Mar 2007 09:11:03 +0900 From: Pyun YongHyeon To: Sam Leffler Message-ID: <20070327001103.GA45955@cdnetworks.co.kr> References: <200703261516.45003.jhb@freebsd.org> <46083B06.9080005@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46083B06.9080005@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 00:05:50 -0000 On Mon, Mar 26, 2007 at 02:28:38PM -0700, Sam Leffler wrote: > John Baldwin wrote: > > On Tuesday 13 March 2007 08:02:43 am Danny Braniss wrote: > >> the question now, is to see if the nfe driver can check if it was > >> used by the PXE, and flip the address. or have NVIDIA comeup with > >> a patch ... > > > > It could use a hueristic based on the vendor-portion of the MAC address to see > > if it is flipped. It is probably a bug in the PXE rom when it shuts down the > > card. > > > > Presumably the mac address is from an nvida-assigned block so just check > the vendor nibbles... > Latest nfe(4) has a code that checks for swapped ethernet address bit which was got by accessing an undocumented register. It seems that this works pretty well for all known NVIDIA NICs and Danny Braniss also confirmed it. > Sam > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 00:24:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C421D16A403 for ; Tue, 27 Mar 2007 00:24:54 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from paperboy.b1tt3r.org (206-45-95-183.static.mts.net [206.45.95.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5EC13C4BA for ; Tue, 27 Mar 2007 00:24:54 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from nibiru.b1tt3r.org ([192.168.1.23]) by paperboy.b1tt3r.org (8.13.6/8.13.6) with SMTP id l2R0Vp17049822 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2007 18:31:51 -0600 (CST) (envelope-from scs@b1tt3r.org) Received: by nibiru.b1tt3r.org (sSMTP sendmail emulation); Mon, 26 Mar 2007 19:26:38 -0500 Date: Mon, 26 Mar 2007 19:26:38 -0500 From: Sam Stein To: freebsd-current@freebsd.org Message-ID: <20070327002638.GA49939@nibiru.b1tt3r.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20070326201715.GA49208@nibiru.b1tt3r.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20070326201715.GA49208@nibiru.b1tt3r.org> Organization: b1tt3r X-OS: FreeBSD nibiru.b1tt3r.org 6.2-STABLE i386 User-Agent: Mutt/1.5.14 (2007-02-12) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on paperboy.b1tt3r.org Subject: Re: X wont start after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 00:24:54 -0000 Actually, dont bother answering till I recompile everything.. I'll tell you if I still got the problem after that. +++ Sam Stein [freebsd] [26/03/07 15:17 -0500]: >I'm sure this is probably my fault.. but I figure I might as well post this >in case someone else had the same problem. I just upgraded, the same way I >always do (the instructions in /usr/src/Makefile) and now X hangs, I think >it >has something to do with either the delete-old or delete-old-libs target, >and >I'm wondering if I should recompile X, but in that case... its probably not >just X that's having problems... and just so you know, this is a -CURRENT >system I am talking about... i'm just emailing from a -STABLE system. >Thanks. > >-- >Sam Stein >Computer Technician/Programmer >Steintech > >Behold the unborn fetus and > Weep salt tears crocodilian; >All life is sacred (save, of course, > An enemy civilian). >_______________________________________________ >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" -- Sam Stein Computer Technician/Programmer Steintech What did Mickey Mouse get for Christmas? A Dan Quayle watch. From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 00:41:55 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4062F16A400 for ; Tue, 27 Mar 2007 00:41:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id F423413C45B for ; Tue, 27 Mar 2007 00:41:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id E7E7420C508; Mon, 26 Mar 2007 20:41:54 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 26 Mar 2007 20:41:55 -0400 X-Sasl-enc: TbNK8O4DFc7TN1bxbdQ6e+qwqx8rhhEM+uYpF8Jt+SrO 1174956114 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 905141133D; Mon, 26 Mar 2007 20:41:54 -0400 (EDT) Message-ID: <46086850.1060505@FreeBSD.org> Date: Tue, 27 Mar 2007 01:41:52 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Tom Uffner References: <4607893B.3080409@uffner.com> <4607F3EA.30902@FreeBSD.org> <46083AE6.2020600@uffner.com> In-Reply-To: <46083AE6.2020600@uffner.com> Content-Type: multipart/mixed; boundary="------------020009040009070109090304" Cc: freebsd-current@FreeBSD.org Subject: Re: current panics when Netgear WG511T ejected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 00:41:55 -0000 This is a multi-part message in MIME format. --------------020009040009070109090304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom Uffner wrote: > > slightly different this time, but it still panics. seems to be trying > to delete nonexistent addresses. should it even be here? i don't have > any multicast addrs defined, just one dhcp-assigned unicast addr. Yup, it should be there. The IP stack will always join 224.0.0.1, this is standards compliant behaviour. Even if you have no multicast addresses explicitly configured by yourself or any application, the multicast code is always used on any system configured with INET. I believe this new patch should fix your panic. Because the hardware is being ejected, the netinet part of the stack won't see the detach first, but net will, and this is where the panic is happening. In this particular case, net is doing the cleanup because of the unexpected detach. It looks like it is the ll_ifma which is causing problems. The problem with ll_ifma is that it is also linked into the if_multiaddrs tailq; we must link AF_LINK addresses in this tailq or things like joining a link-layer group alone will not work. As such it will get seen twice by the same function but in a different role. Previously FreeBSD would just leak memory instead of panicking in situations like this. I rewrote this code to null out the ifp's when ifnet was detached, so that netinet could detect the detach of the underlying layer, and not try to reenter the net code improperly; this was particularly important to avoid bad situations with locking. If the interface needs Giant, the locking is particularly nasty. Regards, BMS --------------020009040009070109090304 Content-Type: text/x-patch; name="if.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if.c.diff" --- //depot/vendor/freebsd/src/sys/net/if.c 2007/03/20 03:17:45 +++ //depot/user/bms/netdev/sys/net/if.c 2007/03/27 00:40:17 @@ -2512,21 +2512,27 @@ /* * If the ifnet is detaching, null out references to ifnet, * so that upper protocol layers will notice, and not attempt - * to obtain locks for an ifnet which no longer exists. - * It is OK to call rt_newmaddrmsg() with a NULL ifp. + * to obtain locks for an ifnet which no longer exists. The + * routing socket announcement must happen before the ifnet + * instance is detached from the system. */ if (detaching) { #ifdef DIAGNOSTIC printf("%s: detaching ifnet instance %p\n", __func__, ifp); #endif - ifma->ifma_ifp = NULL; + /* + * ifp may already be nulled out if we are being reentered + * to delete the ll_ifma. + */ + if (ifp != NULL) { + rt_newmaddrmsg(RTM_DELMADDR, ifma); + ifma->ifma_ifp = NULL; + } } if (--ifma->ifma_refcount > 0) return 0; - rt_newmaddrmsg(RTM_DELMADDR, ifma); - /* * If this ifma is a network-layer ifma, a link-layer ifma may * have been associated with it. Release it first if so. --------------020009040009070109090304-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 01:59:46 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0214D16A400; Tue, 27 Mar 2007 01:59:46 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [207.245.121.212]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD6E13C45E; Tue, 27 Mar 2007 01:59:45 +0000 (UTC) (envelope-from tom@uffner.com) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) by eris.uffner.com (8.13.3/8.13.3) with ESMTP id l2R1xhTF098384; Mon, 26 Mar 2007 21:59:44 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <46087A8F.9000606@uffner.com> Date: Mon, 26 Mar 2007 21:59:43 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070303 SeaMonkey/1.1.1 MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4607893B.3080409@uffner.com> <4607F3EA.30902@FreeBSD.org> <46083AE6.2020600@uffner.com> <46086850.1060505@FreeBSD.org> In-Reply-To: <46086850.1060505@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (eris.uffner.com [192.168.1.212]); Mon, 26 Mar 2007 21:59:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.6/2931/Mon Mar 26 03:43:40 2007 on eris.uffner.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: current panics when Netgear WG511T ejected (and other NICs too) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 01:59:46 -0000 Bruce M. Simpson wrote: > I believe this new patch should fix your panic. Because the hardware is > being ejected, the netinet part of the stack won't see the detach first, > but net will, and this is where the panic is happening. thank you very much. that appears to have fixed it for the Netgear card, and presumably any other well-behaved cardbus NIC that had the same problem. my Linksys Etherfast card which previously had the same panic, no longer panics on eject, but it still does some weird stuff when inserted & ejected: pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Linksys, EtherFast 10/100 PC Card (PCMPC100), pccard0: Manufacturer code 0x149, product 0xc1ab pccard0: function 0: network adapter, ccr addr 400 mask 1 pccard0: function 0, config table entry 16: I/O card; irq mask befc; iomask 5, iospace 0-1f; mwait_required io16 irqlevel pccard0: function 0, config table entry 1: I/O card; irq mask befc; iomask a, iospace 300-31f; mwait_required io16 irqlevel pccard0: function 0, config table entry 2: I/O card; irq mask befc; iomask a, iospace 320-33f; mwait_required io16 irqlevel pccard0: function 0, config table entry 3: I/O card; irq mask befc; iomask a, iospace 340-35f; mwait_required io16 irqlevel pccard0: function 0, config table entry 4: I/O card; irq mask befc; iomask a, iospace 380-39f; mwait_required io16 irqlevel pccard0: function 0, config table entry 5: I/O card; irq mask befc; iomask a, iospace 200-21f; mwait_required io16 irqlevel pccard0: function 0, config table entry 6: I/O card; irq mask befc; iomask a, iospace 220-23f; mwait_required io16 irqlevel pccard0: function 0, config table entry 7: I/O card; irq mask befc; iomask a, iospace 240-25f; mwait_required io16 irqlevel ed0: at port 0x100-0x11f irq 9 function 0 config 16 on pccard0 ed0: Trying DL100xx probing ed0: CIR is 5 ed0: [MPSAFE] ed0: [ITHREAD] ed0: using obsoleted if_watchdog interface ed0: bpf attached ed0: Ethernet address: 00:e0:98:70:10:ee ed0: type DL10019 (16 bit) pccard0: Card already inserted. pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Linksys, EtherFast 10/100 PC Card (PCMPC100), pccard0: Manufacturer code 0x149, product 0xc1ab pccard0: function 0: network adapter, ccr addr 400 mask 1 pccard0: function 0, config table entry 16: I/O card; irq mask befc; iomask 5, iospace 0-1f; mwait_required io16 irqlevel pccard0: function 0, config table entry 1: I/O card; irq mask befc; iomask a, iospace 300-31f; mwait_required io16 irqlevel pccard0: function 0, config table entry 2: I/O card; irq mask befc; iomask a, iospace 320-33f; mwait_required io16 irqlevel pccard0: function 0, config table entry 3: I/O card; irq mask befc; iomask a, iospace 340-35f; mwait_required io16 irqlevel pccard0: function 0, config table entry 4: I/O card; irq mask befc; iomask a, iospace 380-39f; mwait_required io16 irqlevel pccard0: function 0, config table entry 5: I/O card; irq mask befc; iomask a, iospace 200-21f; mwait_required io16 irqlevel pccard0: function 0, config table entry 6: I/O card; irq mask befc; iomask a, iospace 220-23f; mwait_required io16 irqlevel pccard0: function 0, config table entry 7: I/O card; irq mask befc; iomask a, iospace 240-25f; mwait_required io16 irqlevel ed1: at port 0x120-0x13f irq 9 function 0 config 16 on pccard0 ed1: Trying DL100xx probing ed1: CIR is 5 ed1: [MPSAFE] ed1: [ITHREAD] ed1: using obsoleted if_watchdog interface ed1: bpf attached ed1: Ethernet address: 00:e0:98:70:10:ee ed1: type DL10019 (16 bit) ed0: device timeout ed0: device timeout ed1: detached cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=0, type=3, addr=88000000) cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=0, type=1, addr=9) cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=0, type=4, addr=100) ed0: device timeout ed0: device timeout ed0: device timeout ed0: device timeout ed0: device timeout From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 03:27:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3807816A400 for ; Tue, 27 Mar 2007 03:27:46 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1286F13C45B for ; Tue, 27 Mar 2007 03:27:46 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R3Rjev014449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Mar 2007 20:27:45 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R3RijK007438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Mar 2007 20:27:45 -0700 Message-ID: <46097E4E.2060804@u.washington.edu> Date: Tue, 27 Mar 2007 20:27:58 +0000 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070326182638.DFDB045042@ptavv.es.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.26.201433 X-Uwash-Spam: Gauge=XIII, Probability=13%, Report='DATE_IN_FUTURE_12_24 1.3, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: network problems with yesterday's current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 03:27:46 -0000 Vlad GALU wrote: > On 3/26/07, Kevin Oberman wrote: >> Running current of Mar. 25 at about 23:45 UTC. >> >> I am having an odd problem with my on-board bge. I can do most things >> without problems. I ssh into remote systems via IPv4 or IPv6. I can >> browse the web without issues and use finger. DNS is fine. >> >> I can't "fetch" a file. >> % fetch http://www.bytelabs.org/pb-browser-0.4.tgz >> fetch: http://www.bytelabs.org/pb-browser-0.4.tgz: Connection refused >> I can get this file with my browser, though. fetch(1) also fails in the >> same way for FTP access. >> >> This is an example, but any fetch(1) seems to fail this way. Also, my >> gnome-weather-applet also fails over bge0. >> >> When I am connected by my wireless (ath0), this all works fine. >> >> I turned off my firewall and ran tcpdump. It saw NO packets when I tried >> this (tcpdump -vp tcp). The interface shows no errors. >> >> I suspect that the same thing was happening with a Mar. 19 kernel, but >> I can't absolutely confirm this right now. >> >> I don't have a clue of where to even look for this. Any suggestions >> would be appreciated. > > A "me too" here. I have lots of processes stuck in tcp state. Samba was acting really strange (locks up frequently) the past week or so once I upgraded for the ACPI update :(.. sshd does similar from time to time as well =\.. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 03:37:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FA1E16A401 for ; Tue, 27 Mar 2007 03:37:21 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from paperboy.b1tt3r.org (206-45-95-183.static.mts.net [206.45.95.183]) by mx1.freebsd.org (Postfix) with ESMTP id A822B13C4AD for ; Tue, 27 Mar 2007 03:37:20 +0000 (UTC) (envelope-from scs@b1tt3r.org) Received: from nibiru.b1tt3r.org ([192.168.1.23]) by paperboy.b1tt3r.org (8.13.6/8.13.6) with SMTP id l2R3iIpr050235 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2007 21:44:18 -0600 (CST) (envelope-from scs@b1tt3r.org) Received: by nibiru.b1tt3r.org (sSMTP sendmail emulation); Mon, 26 Mar 2007 22:39:06 -0500 Date: Mon, 26 Mar 2007 22:39:06 -0500 From: Sam Stein To: freebsd-current@freebsd.org Message-ID: <20070327033906.GA89004@nibiru.b1tt3r.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Organization: b1tt3r X-OS: FreeBSD nibiru.b1tt3r.org 6.2-STABLE i386 User-Agent: Mutt/1.5.14 (2007-02-12) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on paperboy.b1tt3r.org Subject: Hey all X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 03:37:21 -0000 I forgot to say hi to the list... heh.. Hi all, I'll be following this list regularly hope I can be of some help, and if I need some hope you guys can be of some. :) -- Sam Stein Computer Technician/Programmer Steintech From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 04:52:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D002F16A400 for ; Tue, 27 Mar 2007 04:52:54 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5519A13C458 for ; Tue, 27 Mar 2007 04:52:54 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2R4qqYr011305; Tue, 27 Mar 2007 08:52:52 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2R4qqoB011304; Tue, 27 Mar 2007 08:52:52 +0400 (MSD) (envelope-from ache) Date: Tue, 27 Mar 2007 08:52:52 +0400 From: Andrey Chernov To: Andre Oppermann Message-ID: <20070327045252.GA3256@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Andre Oppermann , Giorgos Keramidas , freebsd-current@freebsd.org, Nicolas Blais References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460705AE.5040107@freebsd.org> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-current@freebsd.org, Giorgos Keramidas , Nicolas Blais Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 04:52:54 -0000 On Mon, Mar 26, 2007 at 01:28:46AM +0200, Andre Oppermann wrote: > Giorgos Keramidas wrote: > >Hi Andre, > > > >The attached thread below is a reply from Nicolas Blais which shows some > >problems with the recent SACK changes. Any idea how we can proceed from > >this point? > > Please update to rev. 1.36 of sys/netinet/tcp_sack.c. The KASSERT() was > too tight but actually caught a bug that would have caused a crash anyway. The problem is deeper than that ((( I still got the same lockup, just with more net activity. I even try to completely disable sack, with the same result, so probem is somewhere else. Last working kernel still from Mar 22. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 05:04:31 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4BC016A400 for ; Tue, 27 Mar 2007 05:04:31 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B102913C45D for ; Tue, 27 Mar 2007 05:04:31 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 28976 invoked from network); 27 Mar 2007 05:04:33 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 27 Mar 2007 05:04:33 -0000 Message-ID: <4608A5D9.2010902@root.org> Date: Mon, 26 Mar 2007 22:04:25 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 05:04:32 -0000 Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. It boots and ad0 is not detected so it can't mount root. The device is: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 PCI config: atapci0@pci0:17:1: class=0x01018a card=0x120a14ff chip=0x05711106 rev=0x06 hdr=0x00 boot -v working: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=7f ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=50 stat1=ff devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ... ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad0: setting PIO4 on 8235 chip ad0: DMA limited to UDMA33, device found non-ATA66 cable ad0: setting UDMA33 on 8235 chip ad0: 38154MB at ata0-master UDMA33 ad0: 78140160 sectors [77520C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: reinit done .. ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: reinit done .. ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on 8235 chip acd0: setting UDMA33 on 8235 chip acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc -------------------------- boot -v broken: atapci0: ... atapci0: reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 ata0: on atapci0 atapci0: reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=7f ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=50 stat1=ff devices=0x1 ... ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ... ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=58 ostat1=7f ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=50 stat1=ff devices=0x1 ata0: reinit done .. ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=58 ostat1=7f ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=50 stat1=ff devices=0x1 ata0: reinit done .. Thanks, Nate From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 05:10:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67EDB16A403 for ; Tue, 27 Mar 2007 05:10:48 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4233913C468 for ; Tue, 27 Mar 2007 05:10:48 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R5AlT7001725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Mar 2007 22:10:48 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R5Alis030937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Mar 2007 22:10:47 -0700 Message-ID: <46099675.3040609@u.washington.edu> Date: Tue, 27 Mar 2007 22:11:01 +0000 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> In-Reply-To: <20070327045252.GA3256@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.26.215934 X-Uwash-Spam: Gauge=XIII, Probability=13%, Report='DATE_IN_FUTURE_12_24 1.3, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 05:10:48 -0000 Andrey Chernov wrote: > On Mon, Mar 26, 2007 at 01:28:46AM +0200, Andre Oppermann wrote: >> Giorgos Keramidas wrote: >>> Hi Andre, >>> >>> The attached thread below is a reply from Nicolas Blais which shows some >>> problems with the recent SACK changes. Any idea how we can proceed from >>> this point? >> Please update to rev. 1.36 of sys/netinet/tcp_sack.c. The KASSERT() was >> too tight but actually caught a bug that would have caused a crash anyway. > > The problem is deeper than that ((( > I still got the same lockup, just with more net activity. > I even try to completely disable sack, with the same result, so probem is > somewhere else. Last working kernel still from Mar 22. I'll give a CVSup / upgrade a try and see what happens. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 05:23:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1560916A405 for ; Tue, 27 Mar 2007 05:23:17 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id ADE9113C459 for ; Tue, 27 Mar 2007 05:23:16 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.96] (cpe-24-169-228-178.twmi.res.rr.com [24.169.228.178]) by lexi.siliconlandmark.com (8.13.8/8.13.3) with ESMTP id l2R5N1M2094335 for ; Tue, 27 Mar 2007 00:23:01 -0500 (EST) (envelope-from andy@siliconlandmark.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7F42CA7D-24C4-4A47-AC67-8F5E6A248380@siliconlandmark.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Andre Guibert de Bruet Date: Tue, 27 Mar 2007 01:23:00 -0400 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.7/2937/Mon Mar 26 18:20:45 2007 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=4.489, required 6, AWL -0.52, BAYES_00 -2.60, RCVD_IN_NJABL_DUL 1.95, RCVD_IN_SORBS_DUL 2.05, RCVD_IN_WHOIS_INVALID 2.23, SPF_SOFTFAIL 1.38) X-SL-SpamScore: 4 X-MailScanner-From: andy@siliconlandmark.com Cc: Subject: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1306 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 05:23:17 -0000 Hi, I got this earlier today. I managed to get what appears to be a sane dump: Unread portion of the kernel message buffer: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1306 cpuid = 0 KDB: enter: panic Physical memory: 3575 MB Dumping 324 MB: 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc0451f5d in db_fncall (dummy1=0, dummy2=0, dummy3=2399, dummy4=0xe545b704 "") at /usr/src/sys/ddb/db_command.c:486 #2 0xc0451d2c in db_command (last_cmdp=0xc07ae024, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #3 0xc0451df3 in db_command_loop () at /usr/src/sys/ddb/db_command.c: 453 #4 0xc0453d61 in db_trap (type=3, code=0) at /usr/src/sys/ddb/ db_main.c:222 #5 0xc0592d9f in kdb_trap (type=0, code=0, tf=0xe545b8a8) at /usr/ src/sys/kern/subr_kdb.c:502 #6 0xc070007b in trap (frame=0xe545b8a8) at /usr/src/sys/i386/i386/ trap.c:621 #7 0xc06e729b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xc0592ac0 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc056e0e5 in panic (fmt=0xc074451f "mtx_lock() of destroyed mutex @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:547 #10 0xc0563397 in _mtx_lock_flags (m=0xc70322b8, opts=0, file=0xc075261b "/usr/src/sys/net/route.c", line=1306) at /usr/src/ sys/kern/kern_mutex.c:186 #11 0xc060b768 in rt_check (lrt=0x12, lrt0=0xe545b9a0, dst=0x12) at / usr/src/sys/net/route.c:1306 #12 0xc060ec84 in arpresolve (ifp=0xc6a3fc00, rt0=0xc6f8ee88, m=0xc6c6e700, dst=0xc6ac88b0, desten=0xe545b9c0 "?E??r`?\0309\201?") at /usr/src/sys/netinet/if_ether.c:378 #13 0xc05fdcee in ether_output (ifp=0xc6a3fc00, m=0xc6c6e700, dst=0xc6ac88b0, rt0=0x12) at /usr/src/sys/net/if_ethersubr.c:170 #14 0xc0621f6e in ip_output (m=0xc6c6e700, opt=0x1, ro=0xe545ba28, flags=0, imo=0x0, inp=0xc71c2000) at /usr/src/sys/netinet/ip_output.c: 561 #15 0xc062af48 in tcp_output (tp=0xc71ce910) at /usr/src/sys/netinet/ tcp_output.c:1122 #16 0xc06290bc in tcp_do_segment (m=0xc6c6e700, th=0xc6c6e758, so=0xca1282b8, tp=0xc71ce910, drop_hdrlen=40, tlen=0) at /usr/src/sys/ netinet/tcp_input.c:2537 #17 0xc0627041 in tcp_input (m=0xc6c6e700, off0=40) at /usr/src/sys/ netinet/tcp_input.c:1004 #18 0xc061f5c4 in ip_input (m=0xc6c6e700) at /usr/src/sys/netinet/ ip_input.c:662 #19 0xc0605c2a in netisr_processqueue (ni=0xc0812dd8) at /usr/src/sys/ net/netisr.c:236 #20 0xc0605e64 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #21 0xc055514a in ithread_execute_handlers (p=0xc6947900, ie=0xc6988580) at /usr/src/sys/kern/kern_intr.c:682 #22 0xc055528f in ithread_loop (arg=0xc6887940) at /usr/src/sys/kern/ kern_intr.c:766 #23 0xc0553e4c in fork_exit (callout=0xc0555217 , arg=0x12, frame=0x12) at /usr/src/sys/kern/kern_fork.c:814 #24 0xc06e7310 in fork_trampoline () at /usr/src/sys/i386/i386/ exception.s:205 File revisions listed appear to be in sync with what cvsweb presently has. They are: $FreeBSD: src/sys/kern/kern_mutex.c,v 1.187 2007/03/22 16:09:23 jhb Exp $ $FreeBSD: src/sys/net/route.c,v 1.118 2006/11/23 05:57:15 bde Exp $ $FreeBSD: src/sys/netinet/if_ether.c,v 1.160 2007/03/22 10:37:53 glebius Exp $ $FreeBSD: src/sys/net/if_ethersubr.c,v 1.226 2007/03/22 19:08:39 bms Exp $ $FreeBSD: src/sys/netinet/ip_output.c,v 1.271 2007/03/23 09:43:36 bms Exp $ $FreeBSD: src/sys/netinet/tcp_output.c,v 1.130 2007/03/21 19:37:55 andre Exp $ $FreeBSD: src/sys/netinet/tcp_input.c,v 1.329 2007/03/24 22:15:02 maxim Exp $ $FreeBSD: src/sys/netinet/ip_input.c,v 1.325 2007/03/19 19:00:51 andre Exp $ $FreeBSD: src/sys/net/netisr.c,v 1.18 2006/11/28 11:19:36 rwatson Exp $ Any suggestions? Cheers! Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 05:28:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09E7B16A401; Tue, 27 Mar 2007 05:28:13 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 816F713C44C; Tue, 27 Mar 2007 05:28:12 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2R5SBki000858; Tue, 27 Mar 2007 09:28:11 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2R5SAP8000857; Tue, 27 Mar 2007 09:28:10 +0400 (MSD) (envelope-from ache) Date: Tue, 27 Mar 2007 09:28:10 +0400 From: Andrey Chernov To: Garrett Cooper , Andre Oppermann Message-ID: <20070327052810.GA772@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Garrett Cooper , Andre Oppermann , freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46099675.3040609@u.washington.edu> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 05:28:13 -0000 On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: > > The problem is deeper than that ((( > > I still got the same lockup, just with more net activity. > > I even try to completely disable sack, with the same result, so probem is > > somewhere else. Last working kernel still from Mar 22. > > I'll give a CVSup / upgrade a try and see what happens. Additional non-default details from my machine which may (or may not) affect the thing: net.inet.tcp.recvspace: 65536 -> 65160 net.inet.tcp.sendspace: 32768 -> 65160 net.inet.tcp.keepidle: 7200000 -> 600000 net.inet.ip.ttl: 64 -> 128 kern.ipc.somaxconn: 128 -> 1024 net.inet.tcp.blackhole: 0 -> 2 net.inet.udp.blackhole: 0 -> 1 net.inet.tcp.mssdflt: 512 -> 1460 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether xx:xx:xx:xx:xx:xx inet xxx.xx.xx.xx netmask 0xffffff00 broadcast xxx.xx.xx.xxx inet xxx.xx.xx.xx netmask 0xffffffff broadcast xxx.xx.xx.xx media: Ethernet autoselect (100baseTX ) status: active Additional routing options: ignore ICMP redirect=YES -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 05:45:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86C5B16A402; Tue, 27 Mar 2007 05:45:04 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 09FAE13C46C; Tue, 27 Mar 2007 05:45:03 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2R5j2cV001083; Tue, 27 Mar 2007 09:45:02 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2R5j2om001082; Tue, 27 Mar 2007 09:45:02 +0400 (MSD) (envelope-from ache) Date: Tue, 27 Mar 2007 09:45:01 +0400 From: Andrey Chernov To: Garrett Cooper , Andre Oppermann , freebsd-current@freebsd.org Message-ID: <20070327054501.GA1026@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Garrett Cooper , Andre Oppermann , freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070327052810.GA772@nagual.pp.ru> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 05:45:04 -0000 On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: > On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: > > > The problem is deeper than that ((( > > > I still got the same lockup, just with more net activity. > > > I even try to completely disable sack, with the same result, so probem is > > > somewhere else. Last working kernel still from Mar 22. > > > > I'll give a CVSup / upgrade a try and see what happens. > > Additional non-default details from my machine which may (or may not) > affect the thing: Yet one detail about lockup: external pings to the machine works in the lockup situation, but no any TCP services is available. Attempting to press power button to initiate soft reboot says that "acpi ... not ready yet". -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 06:01:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 513EC16A401 for ; Tue, 27 Mar 2007 06:01:30 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC9713C45E for ; Tue, 27 Mar 2007 06:01:28 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.96] (cpe-24-169-228-178.twmi.res.rr.com [24.169.228.178]) by lexi.siliconlandmark.com (8.13.8/8.13.3) with ESMTP id l2R61FeB095016 for ; Tue, 27 Mar 2007 01:01:20 -0500 (EST) (envelope-from andy@siliconlandmark.com) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7F42CA7D-24C4-4A47-AC67-8F5E6A248380@siliconlandmark.com> References: <7F42CA7D-24C4-4A47-AC67-8F5E6A248380@siliconlandmark.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43C0C7D6-2685-4E57-8B70-00C1D78A83CD@siliconlandmark.com> Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Tue, 27 Mar 2007 02:01:13 -0400 To: current@freebsd.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.7/2937/Mon Mar 26 18:20:45 2007 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=3.289, required 6, AWL 0.51, BAYES_00 -2.60, RCVD_IN_NJABL_DUL 1.95, RCVD_IN_SORBS_DUL 2.05, SPF_SOFTFAIL 1.38) X-SL-SpamScore: 3 X-MailScanner-From: andy@siliconlandmark.com Cc: Subject: Re: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1306 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 06:01:30 -0000 On Mar 27, 2007, at 1:23 AM, Andre Guibert de Bruet wrote: > I got this earlier today. I managed to get what appears to be a > sane dump: > > Unread portion of the kernel message buffer: > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1306 > cpuid = 0 > KDB: enter: panic > Physical memory: 3575 MB > Dumping 324 MB: 309 293 277 261 245 229 213 197 181 165 149 133 117 > 101 85 69 53 37 21 5 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0xc0451f5d in db_fncall (dummy1=0, dummy2=0, dummy3=2399, > dummy4=0xe545b704 "") at /usr/src/sys/ddb/db_command.c:486 > #2 0xc0451d2c in db_command (last_cmdp=0xc07ae024, cmd_table=0x0) > at /usr/src/sys/ddb/db_command.c:401 > #3 0xc0451df3 in db_command_loop () at /usr/src/sys/ddb/ > db_command.c:453 > #4 0xc0453d61 in db_trap (type=3, code=0) at /usr/src/sys/ddb/ > db_main.c:222 > #5 0xc0592d9f in kdb_trap (type=0, code=0, tf=0xe545b8a8) at /usr/ > src/sys/kern/subr_kdb.c:502 > #6 0xc070007b in trap (frame=0xe545b8a8) at /usr/src/sys/i386/i386/ > trap.c:621 > #7 0xc06e729b in calltrap () at /usr/src/sys/i386/i386/exception.s: > 139 > #8 0xc0592ac0 in kdb_enter (msg=0x12
) > at cpufunc.h:60 > #9 0xc056e0e5 in panic (fmt=0xc074451f "mtx_lock() of destroyed > mutex @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:547 > #10 0xc0563397 in _mtx_lock_flags (m=0xc70322b8, opts=0, > file=0xc075261b "/usr/src/sys/net/route.c", line=1306) at /usr/src/ > sys/kern/kern_mutex.c:186 > #11 0xc060b768 in rt_check (lrt=0x12, lrt0=0xe545b9a0, dst=0x12) > at /usr/src/sys/net/route.c:1306 > #12 0xc060ec84 in arpresolve (ifp=0xc6a3fc00, rt0=0xc6f8ee88, > m=0xc6c6e700, dst=0xc6ac88b0, desten=0xe545b9c0 "?E??r`?\0309 > \201?") at /usr/src/sys/netinet/if_ether.c:378 > #13 0xc05fdcee in ether_output (ifp=0xc6a3fc00, m=0xc6c6e700, > dst=0xc6ac88b0, rt0=0x12) at /usr/src/sys/net/if_ethersubr.c:170 > #14 0xc0621f6e in ip_output (m=0xc6c6e700, opt=0x1, ro=0xe545ba28, > flags=0, imo=0x0, inp=0xc71c2000) at /usr/src/sys/netinet/ > ip_output.c:561 > #15 0xc062af48 in tcp_output (tp=0xc71ce910) at /usr/src/sys/ > netinet/tcp_output.c:1122 > #16 0xc06290bc in tcp_do_segment (m=0xc6c6e700, th=0xc6c6e758, > so=0xca1282b8, tp=0xc71ce910, drop_hdrlen=40, tlen=0) at /usr/src/ > sys/netinet/tcp_input.c:2537 > #17 0xc0627041 in tcp_input (m=0xc6c6e700, off0=40) at /usr/src/sys/ > netinet/tcp_input.c:1004 > #18 0xc061f5c4 in ip_input (m=0xc6c6e700) at /usr/src/sys/netinet/ > ip_input.c:662 > #19 0xc0605c2a in netisr_processqueue (ni=0xc0812dd8) at /usr/src/ > sys/net/netisr.c:236 > #20 0xc0605e64 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 > #21 0xc055514a in ithread_execute_handlers (p=0xc6947900, > ie=0xc6988580) at /usr/src/sys/kern/kern_intr.c:682 > #22 0xc055528f in ithread_loop (arg=0xc6887940) at /usr/src/sys/ > kern/kern_intr.c:766 > #23 0xc0553e4c in fork_exit (callout=0xc0555217 , > arg=0x12, frame=0x12) at /usr/src/sys/kern/kern_fork.c:814 > #24 0xc06e7310 in fork_trampoline () at /usr/src/sys/i386/i386/ > exception.s:205 (kgdb) frame 11 #11 0xc060b768 in rt_check (lrt=0x12, lrt0=0xe545b9a0, dst=0x12) at / usr/src/sys/net/route.c:1306 1306 RT_LOCK(rt); /* NB: gwroute */ (kgdb) list 1301 /* XXX BSD/OS checks dst->sa_family != AF_NS */ 1302 if (rt->rt_flags & RTF_GATEWAY) { 1303 if (rt->rt_gwroute == NULL) 1304 goto lookup; 1305 rt = rt->rt_gwroute; 1306 RT_LOCK(rt); /* NB: gwroute */ 1307 if ((rt->rt_flags & RTF_UP) == 0) { 1308 rtfree(rt); /* unlock gwroute */ 1309 rt = rt0; 1310 lookup: (kgdb) inspect *rt $12 = {rt_nodes = {{rn_mklist = 0x0, rn_parent = 0xc7032270, rn_bit = -1, rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = { rn_Key = 0xc9435400 "??????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????? My?????????????????????????????????????????????????????????????????????? ???"..., rn_Mask = 0x0, rn_Dupedkey = 0x0}, rn_node = {rn_Off = -918334464, rn_L = 0x0, rn_R = 0x0}}}, { rn_mklist = 0x0, rn_parent = 0xc7032090, rn_bit = 63, rn_bmask = 1 '\001', rn_flags = 0 '\0', rn_u = {rn_leaf = {rn_Key = 0x7
, rn_Mask = 0xc70320f0 "\020????$\003???", rn_Dupedkey = 0xc7032258}, rn_node = {rn_Off = 7, rn_L = 0xc70320f0, rn_R = 0xc7032258}}}}, rt_gateway = 0xc9435410, rt_flags = 131076, rt_ifp = 0xc6a3fc00, rt_ifa = 0xc6cbf200, rt_rmx = {rmx_mtu = 1500, rmx_expire = 106852, rmx_pksent = 0}, rt_refcnt = 0, rt_genmask = 0x0, rt_llinfo = 0x0, rt_gwroute = 0x0, rt_parent = 0x0, rt_mtx = {lock_object = {lo_name = 0xc07498ec "rtentry", lo_type = 0xc07498ec "rtentry", lo_flags = 21102592, lo_witness_data = {lod_list = {stqe_next = 0xc07d5050}, lod_witness = 0xc07d5050}}, mtx_lock = 6, mtx_recurse = 0}} (kgdb) inspect **lrt0 $42 = {rt_nodes = {{rn_mklist = 0xc6c7f7a0, rn_parent = 0xc6ac1e34, rn_bit = -1, rn_bmask = 0 '\0', rn_flags = 4 '\004', rn_u = {rn_leaf = { rn_Key = 0xc6ac88a0 "\020\002", rn_Mask = 0xc6aaee00 "", rn_Dupedkey = 0x0}, rn_node = {rn_Off = -961771360, rn_L = 0xc6aaee00, rn_R = 0x0}}}, { rn_mklist = 0x0, rn_parent = 0x0, rn_bit = 0, rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {rn_Key = 0x0, rn_Mask = 0x0, rn_Dupedkey = 0x0}, rn_node = { rn_Off = 0, rn_L = 0x0, rn_R = 0x0}}}}, rt_gateway = 0xc6ac88b0, rt_flags = 2051, rt_ifp = 0xc6a3fc00, rt_ifa = 0xc6cbf200, rt_rmx = {rmx_mtu = 1500, rmx_expire = 0, rmx_pksent = 506624}, rt_refcnt = 2, rt_genmask = 0x0, rt_llinfo = 0x0, rt_gwroute = 0xc7032258, rt_parent = 0x0, rt_mtx = {lock_object = { lo_name = 0xc07498ec "rtentry", lo_type = 0xc07498ec "rtentry", lo_flags = 21168128, lo_witness_data = {lod_list = {stqe_next = 0xc07d5050}, lod_witness = 0xc07d5050}}, mtx_lock = 3331623026, mtx_recurse = 0}} This system's uname -a: FreeBSD bling.properkernel.com 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Mar 25 18:12:26 EDT 2007 andy@bling.properkernel.com:/usr/obj/ usr/src/sys/BLING i386 Before I called doadump(), there were a series of hardware watchdog timeouts on this system's msk0 interface. I do not know if this is related to the problem at hand... Meanwhile, please excuse my kgdb-fu, as I am still fairly green. If there is other output that would help diagnose the problem, please let me know. Cheers, Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 06:14:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43FCB16A405 for ; Tue, 27 Mar 2007 06:14:31 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 0423413C489 for ; Tue, 27 Mar 2007 06:14:30 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2277881ana for ; Mon, 26 Mar 2007 23:14:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EGwDkqBOpudXc9Kr0fVQn3Oz6oKhGKC4+rFxG3r2lBDUUIk1r4B+C8FrfZ4Tl2JtsR6tJIncH7Qmw6ua7o91PwghDzT5rceKFmJ2jdC07NjvCcJVQkGvdePuz0wTcBwCXxNy176Uu5/emXw5V+3MzwyJmW2nh1dChIuVxV8qo6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ffbd2T/NdxZ25gcqg1/ihV9+2jqD6hd7Myfg3XA5Emlf961xLxjhBSephgs9834p5MOu5BR7YolpPMbNwajG6+XQAPIrmEyXeuQNKuEDGBPW8pxSVMA71Cc4BUSD8H5LcyfzhE+IKDqkgKqDvhlnESvz/Rli+MolY2Se2spXYL0= Received: by 10.100.93.5 with SMTP id q5mr5660453anb.1174974472104; Mon, 26 Mar 2007 22:47:52 -0700 (PDT) Received: by 10.100.32.4 with HTTP; Mon, 26 Mar 2007 22:47:52 -0700 (PDT) Message-ID: <910e60e80703262247p152072f7q59a0b7ff4832ad4a@mail.gmail.com> Date: Tue, 27 Mar 2007 14:47:52 +0900 From: dikshie To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: panic related to ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 06:14:31 -0000 I got panic related to ACPI. Panic occurs on boot time so I cant do dump to disk so here's: http://www.sfc.wide.ad.jp/~dikshie/panic/03270001.jpg http://www.sfc.wide.ad.jp/~dikshie/panic/03270002.jpg -- -dikshie- From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 08:29:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 793C016A400 for ; Tue, 27 Mar 2007 08:29:17 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D79B513C459 for ; Tue, 27 Mar 2007 08:29:16 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2R8Sggv016580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2007 11:28:48 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2R8SOKi002490; Tue, 27 Mar 2007 11:28:35 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2R8SOGF002489; Tue, 27 Mar 2007 11:28:24 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 27 Mar 2007 11:28:24 +0300 From: Giorgos Keramidas To: Nate Lawson Message-ID: <20070327082823.GA2356@kobe.laptop> References: <4608A5D9.2010902@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4608A5D9.2010902@root.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.513, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.69, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org, S?ren Schmidt Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 08:29:17 -0000 On 2007-03-26 22:04, Nate Lawson wrote: > Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. > It boots and ad0 is not detected so it can't mount root. > > The device is: > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 > > PCI config: > atapci0@pci0:17:1: class=0x01018a card=0x120a14ff chip=0x05711106 > rev=0x06 hdr=0x00 There are other devices which also have detection problems. snd_ich and snd_hda are two that I know. Can you try updating to a kernel before the latest ACPI import? We seem to be having various interesting problems with the kernel during the last 10 days or so, and that's one of the major changes that went in... From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 08:57:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 334C516A407 for ; Tue, 27 Mar 2007 08:57:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 78A4013C4D9 for ; Tue, 27 Mar 2007 08:57:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 5900 invoked from network); 27 Mar 2007 08:25:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Mar 2007 08:25:17 -0000 Message-ID: <4608DC71.9080001@freebsd.org> Date: Tue, 27 Mar 2007 10:57:21 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrey Chernov , Garrett Cooper , Andre Oppermann , freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> In-Reply-To: <20070327054501.GA1026@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 08:57:22 -0000 Andrey Chernov wrote: > On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: >> On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: >>>> The problem is deeper than that ((( >>>> I still got the same lockup, just with more net activity. >>>> I even try to completely disable sack, with the same result, so probem is >>>> somewhere else. Last working kernel still from Mar 22. >>> I'll give a CVSup / upgrade a try and see what happens. >> Additional non-default details from my machine which may (or may not) >> affect the thing: > > Yet one detail about lockup: external pings to the machine works in the > lockup situation, but no any TCP services is available. I can only think of a TCP_INFO_LOCK() leak here blocking any further progress. When I'm back in the office in about an hour I'll prepare a test patch. > Attempting to press power button to initiate soft reboot says that "acpi > ... not ready yet". -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 09:14:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 983FA16A405 for ; Tue, 27 Mar 2007 09:14:22 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 7254F13C489 for ; Tue, 27 Mar 2007 09:14:22 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R9ELRd005430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Mar 2007 02:14:22 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2R9ELji000359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Mar 2007 02:14:21 -0700 Message-ID: <4609CF8B.5090306@u.washington.edu> Date: Wed, 28 Mar 2007 02:14:35 +0000 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <4608DC71.9080001@freebsd.org> In-Reply-To: <4608DC71.9080001@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.27.15933 X-Uwash-Spam: Gauge=XIII, Probability=13%, Report='DATE_IN_FUTURE_12_24 1.3, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 09:14:22 -0000 Andre Oppermann wrote: > Andrey Chernov wrote: >> On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: >>> On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: >>>>> The problem is deeper than that ((( >>>>> I still got the same lockup, just with more net activity. >>>>> I even try to completely disable sack, with the same result, so >>>>> probem is somewhere else. Last working kernel still from Mar 22. >>>> I'll give a CVSup / upgrade a try and see what happens. >>> Additional non-default details from my machine which may (or may not) >>> affect the thing: >> >> Yet one detail about lockup: external pings to the machine works in >> the lockup situation, but no any TCP services is available. > > I can only think of a TCP_INFO_LOCK() leak here blocking any further > progress. When I'm back in the office in about an hour I'll prepare > a test patch. > >> Attempting to press power button to initiate soft reboot says that >> "acpi ... not ready yet". I noticed that my machine's been locking up a bit lately (kernel core dumps in /var/crash), so I'll investigate a bit more if this situation persists (did a clean rebuild with world and kernel this evening). If you want some of my info, please let me know, but I'm not entirely sure if the issue is net related or another panic to be honest now (didn't build kernel with debug symbols until now ><). -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 10:42:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE65016A400; Tue, 27 Mar 2007 10:42:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A050E13C45B; Tue, 27 Mar 2007 10:42:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A8FEC472DB; Tue, 27 Mar 2007 05:42:26 -0500 (EST) Date: Tue, 27 Mar 2007 11:42:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4608DC71.9080001@freebsd.org> Message-ID: <20070327114125.V42335@fledge.watson.org> References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <4608DC71.9080001@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 10:42:27 -0000 On Tue, 27 Mar 2007, Andre Oppermann wrote: > Andrey Chernov wrote: >> On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: >>> On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: >>>>> The problem is deeper than that ((( >>>>> I still got the same lockup, just with more net activity. >>>>> I even try to completely disable sack, with the same result, so probem >>>>> is somewhere else. Last working kernel still from Mar 22. >>>> I'll give a CVSup / upgrade a try and see what happens. >>> Additional non-default details from my machine which may (or may not) >>> affect the thing: >> >> Yet one detail about lockup: external pings to the machine works in the >> lockup situation, but no any TCP services is available. > > I can only think of a TCP_INFO_LOCK() leak here blocking any further > progress. When I'm back in the office in about an hour I'll prepare a test > patch. If the tcbinfo lock were being leaked, then the netisr or ithread would remain permanently wedged preventing any IP services from working, and rapidly hosing the machine as the ithread wouldn't be doing its thing. I think another sort of problem is more likely. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 12:00:03 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CA4D16A404 for ; Tue, 27 Mar 2007 12:00:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 67FC313C45B for ; Tue, 27 Mar 2007 12:00:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4C57520D111; Tue, 27 Mar 2007 08:00:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 27 Mar 2007 08:00:03 -0400 X-Sasl-enc: 7osUSkPz2QejxgM7CYlhOY9ysYl4ug/vYSjA3Ikxj031 1174996802 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C31471A0BB; Tue, 27 Mar 2007 08:00:02 -0400 (EDT) Message-ID: <46090741.1060007@FreeBSD.org> Date: Tue, 27 Mar 2007 13:00:01 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Tom Uffner References: <4607893B.3080409@uffner.com> <4607F3EA.30902@FreeBSD.org> <46083AE6.2020600@uffner.com> <46086850.1060505@FreeBSD.org> <46087A8F.9000606@uffner.com> In-Reply-To: <46087A8F.9000606@uffner.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: current panics when Netgear WG511T ejected (and other NICs too) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 12:00:03 -0000 Tom Uffner wrote: > > thank you very much. You're welcome. > that appears to have fixed it for the Netgear card, and presumably any > other well-behaved cardbus NIC that had the same problem. Thanks. This fix should go in to -current shortly; it looks like rt_newmaddrmsg() does not check NULL pointers for situations where ifp has been nulled out. Andre reported a problem with multi refcounting on an SMP machine. The ifma instances in that case are protocol, not link layer, ifma instances. I am currently investigating. > > my Linksys Etherfast card which previously had the same panic, no longer > panics on eject, but it still does some weird stuff when inserted & > ejected: I think this may be related to the recent cardbus / pci / bus_alloc_resource changes. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 12:18:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E1E716A404 for ; Tue, 27 Mar 2007 12:18:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E12F213C489 for ; Tue, 27 Mar 2007 12:18:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 8222 invoked from network); 27 Mar 2007 11:46:42 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Mar 2007 11:46:42 -0000 Message-ID: <46090BA6.5060206@freebsd.org> Date: Tue, 27 Mar 2007 14:18:46 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrey Chernov References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> In-Reply-To: <20070327054501.GA1026@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 12:18:48 -0000 Andrey Chernov wrote: > On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: > >>On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: >> >>>>The problem is deeper than that ((( >>>>I still got the same lockup, just with more net activity. >>>>I even try to completely disable sack, with the same result, so probem is >>>>somewhere else. Last working kernel still from Mar 22. >>> >>>I'll give a CVSup / upgrade a try and see what happens. >> >>Additional non-default details from my machine which may (or may not) >>affect the thing: > > > Yet one detail about lockup: external pings to the machine works in the > lockup situation, but no any TCP services is available. > Attempting to press power button to initiate soft reboot says that "acpi > ... not ready yet". This bug is really strange and there is no direct and obvious explanation. A leaked TCP_INFO lock can't really be the cause of the problem as Robert explained. Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving all others at HEAD and look if the bug can be reproduced? -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 13:11:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69B8316A402 for ; Tue, 27 Mar 2007 13:11:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF5E13C4B9 for ; Tue, 27 Mar 2007 13:11:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F07F.dip.t-dialin.net [84.165.240.127]) by redbull.bpaserver.net (Postfix) with ESMTP id 4C2222E16A; Tue, 27 Mar 2007 15:11:02 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 683525B4817; Tue, 27 Mar 2007 15:10:59 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2RDAwpm046201; Tue, 27 Mar 2007 15:10:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 27 Mar 2007 15:10:58 +0200 Message-ID: <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 27 Mar 2007 15:10:58 +0200 From: Alexander Leidinger To: Giorgos Keramidas References: <4608A5D9.2010902@root.org> <20070327082823.GA2356@kobe.laptop> In-Reply-To: <20070327082823.GA2356@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.71, required 8, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_SN 0.08, TW_XF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 13:11:12 -0000 Quoting Giorgos Keramidas (from Tue, 27 Mar =20 2007 11:28:24 +0300): > On 2007-03-26 22:04, Nate Lawson wrote: >> Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. >> It boots and ad0 is not detected so it can't mount root. >> >> The device is: >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 >> >> PCI config: >> atapci0@pci0:17:1: class=3D0x01018a card=3D0x120a14ff chip=3D0x05711106 >> rev=3D0x06 hdr=3D0x00 > > There are other devices which also have detection problems. snd_ich and > snd_hda are two that I know. > > Can you try updating to a kernel before the latest ACPI import? We seem > to be having various interesting problems with the kernel during the last > 10 days or so, and that's one of the major changes that went in... Another reason may be the change in nexus from jhb. Bye, Alexander. --=20 Getting there is only half as far as getting there and back. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 13:15:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF07416A405 for ; Tue, 27 Mar 2007 13:15:00 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6977013C459 for ; Tue, 27 Mar 2007 13:15:00 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 27 Mar 2007 08:46:24 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id ILK00487; Tue, 27 Mar 2007 08:46:24 -0400 (EDT) Received: from 65-78-26-179.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.26.179]) by smtp01.lnh.mail.rcn.net with ESMTP; 27 Mar 2007 08:46:04 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.4637.601099.334416@jerusalem.litteratus.org> Date: Tue, 27 Mar 2007 08:46:21 -0400 To: freebsd-current@freebsd.org In-Reply-To: <200703261523.09636.jhb@freebsd.org> References: <200703261523.09636.jhb@freebsd.org> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 13:15:00 -0000 John Baldwin writes: > > After updating my -CURRENT box to > > > > FreeBSD 7.0-CURRENT #0: Tue Mar 13 22:38:20 EST 2007 i386 > > > de0: port 0xa000 > > -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 > > de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 > > de0: using obsoleted if_watchdog interface > > de0: Ethernet address: 00:c0:95:f8:17:af > > de0: [GIANT-LOCKED] > > de0: [ITHREAD] > > de(4) hasn't used Giant in a long while now. Do you have really > stale sources or something? Sources are updated every 00:01:00 EST. The build is never more than 18 hours later. > Maybe debug.mpsafenet=0 is set? It is, due to advice given in: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040231.html et seq.. (Specifically, see kern/72294 which is still open 2.5 years later.) Has this been fixed and nobody noticed? Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 14:09:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5543416A400 for ; Tue, 27 Mar 2007 14:09:04 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id BC8D313C468 for ; Tue, 27 Mar 2007 14:09:03 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2RE80Fm006171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2007 17:08:07 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2RE7ggG060478; Tue, 27 Mar 2007 17:07:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2RE7go3060477; Tue, 27 Mar 2007 17:07:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 27 Mar 2007 17:07:42 +0300 From: Giorgos Keramidas To: Alexander Leidinger Message-ID: <20070327140741.GA60454@kobe.laptop> References: <4608A5D9.2010902@root.org> <20070327082823.GA2356@kobe.laptop> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.513, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.69, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:09:04 -0000 On 2007-03-27 15:10, Alexander Leidinger wrote: > Quoting Giorgos Keramidas (from Tue, 27 Mar > 2007 11:28:24 +0300): > > >On 2007-03-26 22:04, Nate Lawson wrote: > >>Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. > >>It boots and ad0 is not detected so it can't mount root. > >> > >>The device is: > >>atapci0: port > >>0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 > >> > >>PCI config: > >>atapci0@pci0:17:1: class=0x01018a card=0x120a14ff chip=0x05711106 > >>rev=0x06 hdr=0x00 > > > >There are other devices which also have detection problems. snd_ich and > >snd_hda are two that I know. > > > >Can you try updating to a kernel before the latest ACPI import? We seem > >to be having various interesting problems with the kernel during the last > >10 days or so, and that's one of the major changes that went in... > > Another reason may be the change in nexus from jhb. Yes. I haven't had the time to do binseach through the changes, to see which was the "one commit" which broke snd_hda here. From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:11:49 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5759716A40A for ; Tue, 27 Mar 2007 16:11:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF5B13C4EA for ; Tue, 27 Mar 2007 16:11:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C9BE6210570; Tue, 27 Mar 2007 12:11:48 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Mar 2007 12:11:49 -0400 X-Sasl-enc: hBYsC2Z30E33+AW6Efq1aO+vc33Krm7jATfmSfjt3CUI 1175011908 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C55AD1D1D9; Tue, 27 Mar 2007 12:11:48 -0400 (EDT) Message-ID: <46094243.2020905@FreeBSD.org> Date: Tue, 27 Mar 2007 17:11:47 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Tom Uffner References: <4607893B.3080409@uffner.com> <4607F3EA.30902@FreeBSD.org> <46083AE6.2020600@uffner.com> <46086850.1060505@FreeBSD.org> <46087A8F.9000606@uffner.com> In-Reply-To: <46087A8F.9000606@uffner.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: current panics when Netgear WG511T ejected (and other NICs too) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:11:49 -0000 Tom Uffner wrote: > > thank you very much. > > that appears to have fixed it for the Netgear card, and presumably any > other well-behaved cardbus NIC that had the same problem. Committed, thanks! From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:19:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48AA816A404 for ; Tue, 27 Mar 2007 16:19:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id D89C013C4D3 for ; Tue, 27 Mar 2007 16:19:35 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id BD7C421068E for ; Tue, 27 Mar 2007 12:19:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Mar 2007 12:19:36 -0400 X-Sasl-enc: 0uY+DolnyhiCZLSpVSWAwzrTvJVllZasu+decs+tH9GC 1175012375 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 639831D344 for ; Tue, 27 Mar 2007 12:19:35 -0400 (EDT) Message-ID: <46094415.3050704@FreeBSD.org> Date: Tue, 27 Mar 2007 17:19:33 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------080000050300080700070504" Subject: [Fwd: Panic: if_freemulti: protospec not NULL] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:19:36 -0000 This is a multi-part message in MIME format. --------------080000050300080700070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Patch for this condition is attached. This particular bug is irritating: the IPv4 stack joins 224.0.0.1 once for every IPv4 unicast address configured in the stack. This is incorrect behaviour. The implementation of refcounting has exposed this bug. The fix is not particularly elegant. It is most likely a left-over from the FreeBSD 2.x/3.x era when IPv4 'aliases' were first introduced. At that point in time the IGMP code in FreeBSD would allow groups to be joined on a per-IPv4-address basis, which is inconsistent with the IGMPv2/v3 specified behaviour (and indeed that addressed in future multicast RFCs). It seems that there are other situations where the stack is not adequately equipped to deal with interfaces going away unexpectedly. We can't afford to be complacent about multicast code on the basis of 'it's not the critical path', because it is an integral component of IPv6, and many ideas which people are trying to implement in IPv4 also require that the multicast code is fit for purpose. We would do well to have more people available to help on reviewing and possibly rewriting parts of the network stack from a perspective of correctness, not just performance. If this interests you please consider signing up to the Wiki and updating the page at http://wiki.freebsd.org/NetworkRFCCompliance. Regards, BMS --------------080000050300080700070504 Content-Type: text/x-patch; name="ifa_detach.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifa_detach.diff" ==== //depot/user/bms/netdev/sys/netinet/in.c#11 - /home/bms/p4/netdev/sys/netinet/in.c ==== --- /tmp/tmp.1127.0 Tue Mar 27 16:43:56 2007 +++ /home/bms/p4/netdev/sys/netinet/in.c Tue Mar 27 16:40:04 2007 @@ -212,6 +212,11 @@ /* * Generic internet control operations (ioctl's). * Ifp is 0 if not an interface-specific ioctl. + * + * XXX: This code has some nice big juicy bugs related to interface + * attach and detach. Specifically, the 224.0.0.1 group is now only + * joined on the first IPv4 address configured on an interface, and + * only left when all IPv4 state is torn down for an interface. */ /* ARGSUSED */ int @@ -230,7 +235,9 @@ struct in_aliasreq *ifra = (struct in_aliasreq *)data; struct sockaddr_in oldaddr; int error, hostIsNew, iaIsNew, maskIsNew, s; + int iaIsFirst; + iaIsFirst = 0; iaIsNew = 0; switch (cmd) { @@ -282,6 +289,8 @@ break; } } + if (ia == NULL) + iaIsFirst = 1; } switch (cmd) { @@ -423,8 +432,20 @@ (struct sockaddr_in *) &ifr->ifr_addr, 1); if (error != 0 && iaIsNew) break; - if (error == 0) + if (error == 0) { + /* + * Only join 224.0.0.1 if this is the very first + * IPv4 unicast address which has been configured + * on this ifnet. + */ + if (iaIsFirst && (ifp->if_flags & IFF_MULTICAST) != 0) { + struct in_addr addr; + + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); + in_addmulti(&addr, ifp); + } EVENTHANDLER_INVOKE(ifaddr_event, ifp); + } return (0); case SIOCSIFNETMASK: @@ -467,8 +488,20 @@ if ((ifp->if_flags & IFF_BROADCAST) && (ifra->ifra_broadaddr.sin_family == AF_INET)) ia->ia_broadaddr = ifra->ifra_broadaddr; - if (error == 0) + if (error == 0) { + /* + * Only join 224.0.0.1 if this is the very first + * IPv4 unicast address which has been configured + * on this ifnet. + */ + if (iaIsFirst && (ifp->if_flags & IFF_MULTICAST) != 0) { + struct in_addr addr; + + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); + in_addmulti(&addr, ifp); + } EVENTHANDLER_INVOKE(ifaddr_event, ifp); + } return (error); case SIOCDIFADDR: @@ -503,8 +536,33 @@ s = splnet(); TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); TAILQ_REMOVE(&in_ifaddrhead, ia, ia_link); - if (ia->ia_addr.sin_family == AF_INET) + if (ia->ia_addr.sin_family == AF_INET) { + struct in_ifaddr *pia; + LIST_REMOVE(ia, ia_hash); + /* + * Only purge the 224.0.0.1 membership if the last IPv4 + * unicast address configured on this ifnet is removed. + * + * XXX: This currently involves trawling through the + * in_ifaddrhead list looking for a match, which is + * inefficient, though this is only done when an interface + * address goes away. This could be done much more elegantly. + */ + pia = NULL; + IFP_TO_IA(ifp, pia); + if (pia == NULL) { + struct in_multi *inm; + struct in_addr addr; + + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); + IN_MULTI_LOCK(); + IN_LOOKUP_MULTI(addr, ifp, inm); + if (inm != NULL) + in_delmulti(inm); + IN_MULTI_UNLOCK(); + } + } IFAFREE(&ia->ia_ifa); splx(s); @@ -793,16 +851,6 @@ if ((error = in_addprefix(ia, flags)) != 0) return (error); - /* - * If the interface supports multicast, join the "all hosts" - * multicast group on that interface. - */ - if (ifp->if_flags & IFF_MULTICAST) { - struct in_addr addr; - - addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); - in_addmulti(&addr, ifp); - } return (error); } @@ -1114,6 +1162,9 @@ igmp_leavegroup(inm); ifma = inm->inm_ifma; +#ifdef DIAGNOSTIC + printf("%s: purging ifma %p\n", __func__, ifma); +#endif KASSERT(ifma->ifma_protospec == inm, ("%s: ifma_protospec != inm", __func__)); ifma->ifma_protospec = NULL; @@ -1135,6 +1186,9 @@ struct in_multi *inm; struct in_multi *oinm; +#ifdef DIAGNOSTIC + printf("%s: purging ifp %p\n", __func__, ifp); +#endif IFF_LOCKGIANT(ifp); IN_MULTI_LOCK(); LIST_FOREACH_SAFE(inm, &in_multihead, inm_link, oinm) { --------------080000050300080700070504 Content-Type: message/rfc822; name="Panic: if_freemulti: protospec not NULL" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="Panic: if_freemulti: protospec not NULL" Received: from compute1.internal (compute1.internal [10.202.2.41]) by store23m.internal (Cyrus v2.3.8-fmsvn11108) with LMTPA; Tue, 27 Mar 2007 07:43:01 -0400 X-Sieve: CMU Sieve 2.3 X-Spam-score: 0.0 X-Spam-source: IP='69.147.83.53', Country='US', FromHeader='org', MailFrom='org' X-Delivered-to: bms@fastmail.net Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mx2.messagingengine.com (Postfix) with ESMTP id 404E91E04EE for ; Tue, 27 Mar 2007 07:42:58 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id 1855019D60 for ; Tue, 27 Mar 2007 11:40:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: by hub.freebsd.org (Postfix) id 1469A16A404; Tue, 27 Mar 2007 11:40:16 +0000 (UTC) Delivered-To: bms@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEBA816A403 for ; Tue, 27 Mar 2007 11:40:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2057413C457 for ; Tue, 27 Mar 2007 11:40:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 7080 invoked from network); 27 Mar 2007 11:08:10 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Mar 2007 11:08:10 -0000 Message-ID: <4609029E.8070604@freebsd.org> Date: Tue, 27 Mar 2007 13:40:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: bms@freebsd.org Subject: Panic: if_freemulti: protospec not NULL Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit fxp0: 62.48.0.50/24 sysctl net.link. ifconfig lo1 create ifconfig lo1 inet 62.48.0.39/32 ifconfig lo1 inet 62.48.0.38/32 alias # ping tests etc. ifconfig lo1 delete 62.48.0.39 ifconfig lo1 delete 62.48.0.38 ifconfig lo1 destroy # panic Unread portion of the kernel message buffer: panic: if_freemulti: protospec not NULL cpuid = 1 KDB: enter: panic Physical memory: 2035 MB Dumping 103 MB: 88 72 56 40 24 8 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc0477a3f in db_fncall (dummy1=-406202100, dummy2=0, dummy3=-1062950496, dummy4=0xe7c9d8e8 "\200DЮ") at ../../../ddb/db_command.c:486 #2 0xc047784b in db_command (last_cmdp=0xc0a23244, cmd_table=0x0) at ../../../ddb/db_command.c:401 #3 0xc0477906 in db_command_loop () at ../../../ddb/db_command.c:453 #4 0xc0479551 in db_trap (type=3, code=0) at ../../../ddb/db_main.c:222 #5 0xc06e1f0c in kdb_trap (type=3, code=0, tf=0xe7c9da80) at ../../../kern/subr_kdb.c:502 #6 0xc08c0529 in trap (frame=0xe7c9da80) at ../../../i386/i386/trap.c:621 #7 0xc08aa47b in calltrap () at ../../../i386/i386/exception.s:139 #8 0xc06e1c33 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc06c2fc0 in panic (fmt=0xc0956e98 "if_freemulti: protospec not NULL") at ../../../kern/kern_shutdown.c:547 #10 0xc073aa18 in if_freemulti (ifma=0xc548f360) at ../../../net/if.c:2251 #11 0xc073b036 in if_delmulti_locked (ifp=0xc50fd000, ifma=0xc548f360, detaching=1) at ../../../net/if.c:2552 #12 0xc0737dd7 in if_purgemaddrs (ifp=0xc50fd000) at ../../../net/if.c:636 #13 0xc0737f0b in if_detach (ifp=0xc50fd000) at ../../../net/if.c:701 #14 0xc073e939 in lo_clone_destroy (ifp=0xc50fd000) at ../../../net/if_loop.c:131 #15 0xc073c1aa in ifc_simple_destroy (ifc=0xc0a015e0, ifp=0xc1433000) at ../../../net/if_clone.c:560 #16 0xc073b753 in if_clone_destroyif (ifc=0xc0a015e0, ifp=0xc50fd000) at ../../../net/if_clone.c:218 #17 0xc073b685 in if_clone_destroy (name=0xc548f9e0 "lo1") at ../../../net/if_clone.c:196 #18 0xc073a370 in ifioctl (so=0xc558ec3c, cmd=2149607801, data=0xc548f9e0 "lo1", td=0xc5529a20) at ../../../net/if.c:1849 #19 0xc06f4b2f in soo_ioctl (fp=0x12, cmd=2149607801, data=0xc548f9e0, active_cred=0xc5899880, td=0xc5529a20) at ../../../kern/sys_socket.c:202 #20 0xc06ef872 in kern_ioctl (td=0xc5529a20, fd=3, com=2149607801, data=0xc548f9e0 "lo1") at file.h:266 #21 0xc06ef595 in ioctl (td=0xc5529a20, uap=0xe7c9dd00) at ../../../kern/sys_generic.c:544 #22 0xc08c0d72 in syscall (frame=0xe7c9dd38) at ../../../i386/i386/trap.c:1010 #23 0xc08aa4e0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xc073aa18 in if_freemulti (ifma=0xc548f360) at ../../../net/if.c:2251 2251 KASSERT(ifma->ifma_protospec == NULL, (kgdb) list 2246 if_freemulti(struct ifmultiaddr *ifma) 2247 { 2248 2249 KASSERT(ifma->ifma_refcount == 0, ("if_freemulti: refcount %d", 2250 ifma->ifma_refcount)); 2251 KASSERT(ifma->ifma_protospec == NULL, 2252 ("if_freemulti: protospec not NULL")); 2253 2254 if (ifma->ifma_lladdr != NULL) 2255 FREE(ifma->ifma_lladdr, M_IFMADDR); (kgdb) inspect *ifma $2 = {ifma_link = {tqe_next = 0x0, tqe_prev = 0xc50fd0bc}, ifma_addr = 0xc53210d0, ifma_lladdr = 0x0, ifma_ifp = 0x0, ifma_refcount = 0, ifma_protospec = 0xc5716180, ifma_llifma = 0x0} (kgdb) up #11 0xc073b036 in if_delmulti_locked (ifp=0xc50fd000, ifma=0xc548f360, detaching=1) at ../../../net/if.c:2552 2552 if_freemulti(ifma); (kgdb) inspect *ifp $3 = {if_softc = 0xc548c990, if_l2com = 0x0, if_link = {tqe_next = 0x0, tqe_prev = 0xc530b808}, if_xname = "lo1", '\0' , if_dname = 0xc0909303 "lo", if_dunit = 1, if_addrhead = { tqh_first = 0xc59b7600, tqh_last = 0xc59b7660}, if_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc06a8d78 , kl_unlock = 0xc06a8d94 , kl_locked = 0xc06a8db0 , kl_lockarg = 0xc0a4d7f8}, if_pcount = 0, if_carp = 0x0, if_bpf = 0xc5716b80, if_index = 8, if_timer = 0, if_vlantrunk = 0x0, if_flags = 32776, if_capabilities = 0, if_capenable = 0, if_linkmib = 0x0, if_linkmiblen = 0, if_data = {ifi_type = 24 '\030', ifi_physical = 0 '\0', ifi_addrlen = 0 '\0', ifi_hdrlen = 0 '\0', ifi_link_state = 0 '\0', ifi_recvquota = 0 '\0', ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 16384, ifi_metric = 0, ifi_baudrate = 0, ifi_ipackets = 0, ifi_ierrors = 0, ifi_opackets = 0, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 0, ifi_obytes = 0, ifi_imcasts = 0, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 7771, ifi_lastchange = {tv_sec = 1174954038, tv_usec = 187825}}, if_multiaddrs = {tqh_first = 0x0, tqh_last = 0xc50fd0bc}, if_amcount = 0, if_output = 0xc073eadc , if_input = 0, if_start = 0, if_ioctl = 0xc073ed14 , if_watchdog = 0, if_init = 0, if_resolvemulti = 0, if_addr = 0xc59b7600, if_spare2 = 0x0, if_spare3 = 0x0, if_drv_flags = 64, if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50, ifq_drops = 0, ifq_mtx = {lock_object = {lo_name = 0xc50fd010 "lo1", lo_type = 0xc0956c03 "if send queue", lo_flags = 16973824, lo_witness_data = {lod_list = { stqe_next = 0xc0a5de98}, lod_witness = 0xc0a5de98}}, mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = 0, altq_flags = 0, altq_disc = 0x0, altq_ifp = 0xc50fd000, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0x0, if_bridge = 0x0, lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc50fd170}, if_afdata = {0x0 , 0xc548c720, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 2, if_afdata_mtx = { lock_object = {lo_name = 0xc0956bf9 "if_afdata", lo_type = 0xc0956bf9 "if_afdata", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0xc0a5dec0}, lod_witness = 0xc0a5dec0}}, mtx_lock = 4, mtx_recurse = 0}, if_starttask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc073b2b0 , ta_context = 0xc50fd000}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc07393f8 , ta_context = 0xc50fd000}, if_addr_mtx = {lock_object = {lo_name = 0xc094f3db "if_addr_mtx", lo_type = 0xc094f3db "if_addr_mtx", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0xc0a5f388}, lod_witness = 0xc0a5f388}}, mtx_lock = 3310524960, mtx_recurse = 0}, if_clones = {le_next = 0xc530b800, le_prev = 0xc0a01628}, if_groups = { tqh_first = 0xc548c6f0, tqh_last = 0xc548c6f4}, if_pf_kif = 0x0} kgdb) inspect *ifma $4 = {ifma_link = {tqe_next = 0x0, tqe_prev = 0xc50fd0bc}, ifma_addr = 0xc53210d0, ifma_lladdr = 0x0, ifma_ifp = 0x0, ifma_refcount = 0, ifma_protospec = 0xc5716180, ifma_llifma = 0x0} (kgdb) up #12 0xc0737dd7 in if_purgemaddrs (ifp=0xc50fd000) at ../../../net/if.c:636 636 if_delmulti_locked(ifp, ifma, 1); (kgdb) up #13 0xc0737f0b in if_detach (ifp=0xc50fd000) at ../../../net/if.c:701 701 if_purgemaddrs(ifp); (kgdb) up #14 0xc073e939 in lo_clone_destroy (ifp=0xc50fd000) at ../../../net/if_loop.c:131 131 if_detach(ifp); (kgdb) up #15 0xc073c1aa in ifc_simple_destroy (ifc=0xc0a015e0, ifp=0xc1433000) at ../../../net/if_clone.c:560 560 ifcs->ifcs_destroy(ifp); (kgdb) inspect *ifc $5 = {ifc_list = {le_next = 0xc0a01400, le_prev = 0xc0a9d034}, ifc_name = 0xc0909303 "lo", ifc_maxunit = 32767, ifc_units = 0xc5316000 "\003", ifc_bmlen = 4096, ifc_data = 0xc0a015c4, ifc_attach = 0xc073bfe4 , ifc_match = 0xc073c070 , ifc_create = 0xc073c0d4 , ifc_destroy = 0xc073c18c , ifc_refcnt = 3, ifc_mtx = {lock_object = {lo_name = 0xc0957019 "if_clone lock", lo_type = 0xc0957019 "if_clone lock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0xc0a5dbc8}, lod_witness = 0xc0a5dbc8}}, mtx_lock = 4, mtx_recurse = 0}, ifc_iflist = {lh_first = 0xc530b800}} (kgdb) up #16 0xc073b753 in if_clone_destroyif (ifc=0xc0a015e0, ifp=0xc50fd000) at ../../../net/if_clone.c:218 218 err = (*ifc->ifc_destroy)(ifc, ifp); (kgdb) up #17 0xc073b685 in if_clone_destroy (name=0xc548f9e0 "lo1") at ../../../net/if_clone.c:196 196 return (if_clone_destroyif(ifc, ifp)); (kgdb) up #18 0xc073a370 in ifioctl (so=0xc558ec3c, cmd=2149607801, data=0xc548f9e0 "lo1", td=0xc5529a20) at ../../../net/if.c:1849 1849 return if_clone_destroy(ifr->ifr_name); --------------080000050300080700070504-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:34:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C951C16A40B for ; Tue, 27 Mar 2007 16:34:49 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5A47D13C469 for ; Tue, 27 Mar 2007 16:34:49 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so3027015nfc for ; Tue, 27 Mar 2007 09:34:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aSQ8bKYfK590FicvQP6pz5OVioZomckkDBEhfL9nNxucoz+/pNAHxfM3L4IfQl2Rr3MiIE+SUC/4iyqKY0V38/HNRY0EoFbTligMLTRfoh1UXQwh+qGPt65VtM+XJ6UHMyKhtt8dE5OiG+knTTmfYvlscQBABcNGIXDmjNhT8KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ltqgFdP2xGYfOzSrT8eHKYwt0nhFoCY6l+E3WN0AW4a14+RjmGa9EYiA3ROMxUVYx/yQ10n7MD22I+hbkagF9u4rLk5yps4z4We78iPMMhWTpQDgsmBcr4eeS/Bdq8qSJmkTtR9RIv+dLsyD3bTQlEKxD+qpGJsxW7huR1BWct4= Received: by 10.78.203.13 with SMTP id a13mr3633407hug.1175011805635; Tue, 27 Mar 2007 09:10:05 -0700 (PDT) Received: by 10.78.29.12 with HTTP; Tue, 27 Mar 2007 09:10:05 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 18:10:05 +0200 From: "Niclas Zeising" To: "Andre Oppermann" In-Reply-To: <46090BA6.5060206@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070324124732.GA767@nagual.pp.ru> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <46090BA6.5060206@freebsd.org> Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:34:49 -0000 On 3/27/07, Andre Oppermann wrote: > Andrey Chernov wrote: > > On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: > > > >>On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: > >> > >>>>The problem is deeper than that ((( > >>>>I still got the same lockup, just with more net activity. > >>>>I even try to completely disable sack, with the same result, so probem is > >>>>somewhere else. Last working kernel still from Mar 22. > >>> > >>>I'll give a CVSup / upgrade a try and see what happens. > >> > >>Additional non-default details from my machine which may (or may not) > >>affect the thing: > > > > > > Yet one detail about lockup: external pings to the machine works in the > > lockup situation, but no any TCP services is available. > > Attempting to press power button to initiate soft reboot says that "acpi > > ... not ready yet". > > This bug is really strange and there is no direct and obvious explanation. > A leaked TCP_INFO lock can't really be the cause of the problem as Robert > explained. > > Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving > all others at HEAD and look if the bug can be reproduced? > > -- > Andre I've had troubles with the recent changes in tcp_sack.c and tcp_imout.c as well. It panics on a "Sleeping while holding non-sleeable lock" I've posted tracebacks earlier on this list (same thread) but I'm at work now and don't have them around to test. The problem might have been solved in the most recent change, but I haven't really confirmed it, only that it takes a longer while for the computer to panic. It was too late last night for any extensive testing. Regards! //Niclas From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:35:38 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6466C16A402 for ; Tue, 27 Mar 2007 16:35:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id BF82413C45E for ; Tue, 27 Mar 2007 16:35:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2RGZY5e007199; Tue, 27 Mar 2007 12:35:34 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 27 Mar 2007 12:35:28 -0400 User-Agent: KMail/1.6.2 References: <910e60e80703262247p152072f7q59a0b7ff4832ad4a@mail.gmail.com> In-Reply-To: <910e60e80703262247p152072f7q59a0b7ff4832ad4a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703271235.31692.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2941/Tue Mar 27 11:24:38 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: dikshie Subject: Re: panic related to ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:35:38 -0000 On Tuesday 27 March 2007 01:47 am, dikshie wrote: > I got panic related to ACPI. > Panic occurs on boot time so I cant do dump to disk so here's: > > http://www.sfc.wide.ad.jp/~dikshie/panic/03270001.jpg > http://www.sfc.wide.ad.jp/~dikshie/panic/03270002.jpg When did you sync your source? Can you check whether you have sys/dev/acpica/Osd/OsdSynch.c 1.32? Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:54:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B2DC16A401 for ; Tue, 27 Mar 2007 16:54:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id BB1F213C469 for ; Tue, 27 Mar 2007 16:54:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2RGsDtq024616; Tue, 27 Mar 2007 11:54:19 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 27 Mar 2007 12:24:30 -0400 User-Agent: KMail/1.9.6 References: <200703261523.09636.jhb@freebsd.org> <17929.4637.601099.334416@jerusalem.litteratus.org> In-Reply-To: <17929.4637.601099.334416@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271224.30697.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 27 Mar 2007 11:54:19 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2940/Tue Mar 27 09:26:39 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Huff Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:54:23 -0000 On Tuesday 27 March 2007 08:46:21 am Robert Huff wrote: > > John Baldwin writes: > > > > After updating my -CURRENT box to > > > > > > FreeBSD 7.0-CURRENT #0: Tue Mar 13 22:38:20 EST 2007 i386 > > > > > de0: port 0xa000 > > > -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 > > > de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 > > > de0: using obsoleted if_watchdog interface > > > de0: Ethernet address: 00:c0:95:f8:17:af > > > de0: [GIANT-LOCKED] > > > de0: [ITHREAD] > > > > de(4) hasn't used Giant in a long while now. Do you have really > > stale sources or something? > > Sources are updated every 00:01:00 EST. The build is never > more than 18 hours later. > > > Maybe debug.mpsafenet=0 is set? > > It is, due to advice given in: > > http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040231.html > > et seq.. (Specifically, see kern/72294 which is still open 2.5 > years later.) > Has this been fixed and nobody noticed? Probably, the driver has been locked and reworked significantly since October of 2004. I would try it w/o the flag. That PR number maps to a ports PR, I can't find the PR easily, so if you can find it I'd appreciate it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:54:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5350716A409 for ; Tue, 27 Mar 2007 16:54:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id F06B213C46E for ; Tue, 27 Mar 2007 16:54:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2RGsDts024616; Tue, 27 Mar 2007 11:54:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 27 Mar 2007 12:28:46 -0400 User-Agent: KMail/1.9.6 References: <910e60e80703262247p152072f7q59a0b7ff4832ad4a@mail.gmail.com> In-Reply-To: <910e60e80703262247p152072f7q59a0b7ff4832ad4a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271228.46659.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 27 Mar 2007 11:54:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2940/Tue Mar 27 09:26:39 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: dikshie Subject: Re: panic related to ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:54:33 -0000 On Tuesday 27 March 2007 01:47:52 am dikshie wrote: > I got panic related to ACPI. > Panic occurs on boot time so I cant do dump to disk so here's: > > http://www.sfc.wide.ad.jp/~dikshie/panic/03270001.jpg > http://www.sfc.wide.ad.jp/~dikshie/panic/03270002.jpg It's trying to sleep to get a mutex from an interrupt handler. If ACPI-CA mutexes were backed by real mutexes this would work fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:54:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 119D416A46C; Tue, 27 Mar 2007 16:54:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 91B0113C487; Tue, 27 Mar 2007 16:54:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2RGsDtr024616; Tue, 27 Mar 2007 11:54:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 27 Mar 2007 12:27:13 -0400 User-Agent: KMail/1.9.6 References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> In-Reply-To: <20070327140741.GA60454@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271227.14308.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 27 Mar 2007 11:54:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2940/Tue Mar 27 09:26:39 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Giorgos Keramidas , Alexander Leidinger , current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:54:45 -0000 On Tuesday 27 March 2007 10:07:42 am Giorgos Keramidas wrote: > On 2007-03-27 15:10, Alexander Leidinger wrote: > > Quoting Giorgos Keramidas (from Tue, 27 Mar > > 2007 11:28:24 +0300): > > > > >On 2007-03-26 22:04, Nate Lawson wrote: > > >>Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. > > >>It boots and ad0 is not detected so it can't mount root. > > >> > > >>The device is: > > >>atapci0: port > > >>0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 > > >> > > >>PCI config: > > >>atapci0@pci0:17:1: class=0x01018a card=0x120a14ff chip=0x05711106 > > >>rev=0x06 hdr=0x00 > > > > > >There are other devices which also have detection problems. snd_ich and > > >snd_hda are two that I know. > > > > > >Can you try updating to a kernel before the latest ACPI import? We seem > > >to be having various interesting problems with the kernel during the last > > >10 days or so, and that's one of the major changes that went in... > > > > Another reason may be the change in nexus from jhb. > > Yes. I haven't had the time to do binseach through the changes, to see > which was the "one commit" which broke snd_hda here. If that is the case it's because code was using rman_get_bus(handle|tag) on a resource that wasn't activated yet which wouldn't have worked before the nexus changes either. Well, the bus tag might have been right, but the handle for SYS_RES_MEMORY would have been wrong. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 16:54:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 119D416A46C; Tue, 27 Mar 2007 16:54:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 91B0113C487; Tue, 27 Mar 2007 16:54:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2RGsDtr024616; Tue, 27 Mar 2007 11:54:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 27 Mar 2007 12:27:13 -0400 User-Agent: KMail/1.9.6 References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> In-Reply-To: <20070327140741.GA60454@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271227.14308.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 27 Mar 2007 11:54:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2940/Tue Mar 27 09:26:39 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Giorgos Keramidas , Alexander Leidinger , current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:54:45 -0000 On Tuesday 27 March 2007 10:07:42 am Giorgos Keramidas wrote: > On 2007-03-27 15:10, Alexander Leidinger wrote: > > Quoting Giorgos Keramidas (from Tue, 27 Mar > > 2007 11:28:24 +0300): > > > > >On 2007-03-26 22:04, Nate Lawson wrote: > > >>Something between 2007/2/19 and 2007/3/25 breaks ata on my VIA laptop. > > >>It boots and ad0 is not detected so it can't mount root. > > >> > > >>The device is: > > >>atapci0: port > > >>0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 > > >> > > >>PCI config: > > >>atapci0@pci0:17:1: class=0x01018a card=0x120a14ff chip=0x05711106 > > >>rev=0x06 hdr=0x00 > > > > > >There are other devices which also have detection problems. snd_ich and > > >snd_hda are two that I know. > > > > > >Can you try updating to a kernel before the latest ACPI import? We seem > > >to be having various interesting problems with the kernel during the last > > >10 days or so, and that's one of the major changes that went in... > > > > Another reason may be the change in nexus from jhb. > > Yes. I haven't had the time to do binseach through the changes, to see > which was the "one commit" which broke snd_hda here. If that is the case it's because code was using rman_get_bus(handle|tag) on a resource that wasn't activated yet which wouldn't have worked before the nexus changes either. Well, the bus tag might have been right, but the handle for SYS_RES_MEMORY would have been wrong. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 17:03:05 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D0E016A402; Tue, 27 Mar 2007 17:03:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id E9CE513C448; Tue, 27 Mar 2007 17:03:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mzsxer@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l2RH2wXh017243; Tue, 27 Mar 2007 19:03:03 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l2RH2vmC017242; Tue, 27 Mar 2007 19:02:58 +0200 (CEST) (envelope-from olli) Date: Tue, 27 Mar 2007 19:02:58 +0200 (CEST) Message-Id: <200703271702.l2RH2vmC017242@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, wkoszek@FreeBSD.ORG In-Reply-To: <20070326171016.GA16746@FreeBSD.czest.pl> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 27 Mar 2007 19:03:03 +0200 (CEST) X-Mailman-Approved-At: Tue, 27 Mar 2007 17:09:18 +0000 Cc: Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, wkoszek@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 17:03:05 -0000 Wojciech A. Koszek wrote: > Oliver Fromme wrote: > > No objection from me, but please fix it so include files > > are also included in the kernel. > > > > Many of my kernel config files have only few lines (e.g. > > "options SMP" and "include MYKERNEL"). Currently, the > > INCLUDE_CONFIG_FILE feature only includes those two lines, > > rendering that feature useless (and even potentially > > dangerous if someone relies on his config to be in the > > kernel). > > You'll get full configuration file, no matter what you include. After > redirecting it to file, you'll be able to compile the kernel with no > additional modifications. That sounds OK. Will that fix be MFCed back to RELENG_6? I could really use it, because I often use include files in kernel configurations. By the way, it would be cool to have an ELF section in the kernel that contains a .tar.gz with the kernel config and all included files. No, just kidding. Couldn't resist. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch�ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M�n- chen, HRB 125758, Gesch�ftsf�hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 19:03:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7310416A401 for ; Tue, 27 Mar 2007 19:03:22 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id 419E713C459 for ; Tue, 27 Mar 2007 19:03:22 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HWFxP-0000sc-Ql for freebsd-current@freebsd.org; Tue, 27 Mar 2007 13:59:44 -0400 Message-ID: <46095BFA.7030408@metricsystems.com> Date: Tue, 27 Mar 2007 10:01:30 -0800 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Subject: 6.2 Release install CD crashes at BTX loader on a VIA Eden processor. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 19:03:22 -0000 I have a need to set up a FreeBSD bases system. However, the install disk crashes in the BTX loader. I don't have the ability to capture the output exactly, however, the final lines before the register dump is: BTX Loader 1.00 BTX version is 1.01 console: internal video/keyboard -------- The BIOS supports either a integrated video/ps2-keyboard or a serial port for a consol. However, for this activity I have the video/keyboard setup for the console, and have disabled the serial port option in the BIOS. On searching I saw some reference to setting up PIO in the BIOS, and I have tried all 'modes' that were available for the PIO option in the board's BIOS. All have the same effect. A couple of questions come to mind. 1) Is there a known work around or later snapshot that has corrected this problem. 2) Is there a cross development/build setup similar to NetBSD so I can recompile the world on a Linux platform. Thanks, John Clark. From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 19:54:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9F5C16A400 for ; Tue, 27 Mar 2007 19:54:07 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDCB13C457 for ; Tue, 27 Mar 2007 19:54:05 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HWHju-0006mR-Fz; Tue, 27 Mar 2007 15:53:56 -0400 Message-ID: <460976B9.6050901@metricsystems.com> Date: Tue, 27 Mar 2007 11:55:37 -0800 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Kurt Jaeger References: <46095BFA.7030408@metricsystems.com> <20070327191340.GG26839@home.c0mplx.org> In-Reply-To: <20070327191340.GG26839@home.c0mplx.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: 6.2 Release install CD crashes at BTX loader on a VIA Eden processor. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 19:54:07 -0000 Kurt Jaeger schrieb: > > And: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032446.html > The btx code can't deal with BIOSes which want to enter > protected mode to service the I/Os. USB support in most BIOSen generally > does this. I see the same issue with FreeBSD's pxeboot and the PXE > client in Etherboot. > Yes, well... I am using a USB device, and I was so brain dead as to be changing the IDE setup... Unfortunately this PC board I don't think as an official IDE interface. It has the mini for a laptop disk, and I don't have a converter handy... I think I may install the system on the disk with another machine, older, more IDE interfaces, etc. then bring the disk back to my target. Thanks, John Clark. From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 19:57:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4BDA16A404 for ; Tue, 27 Mar 2007 19:57:01 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.c0mplx.org (home.c0mplx.org [213.178.180.1]) by mx1.freebsd.org (Postfix) with ESMTP id 539E313C448 for ; Tue, 27 Mar 2007 19:57:01 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.c0mplx.org with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HWH6y-000OzW-Sa for freebsd-current@freebsd.org; Tue, 27 Mar 2007 21:13:40 +0200 Date: Tue, 27 Mar 2007 21:13:40 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Message-ID: <20070327191340.GG26839@home.c0mplx.org> References: <46095BFA.7030408@metricsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46095BFA.7030408@metricsystems.com> Subject: Re: 6.2 Release install CD crashes at BTX loader on a VIA Eden processor. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 19:57:01 -0000 Hi! > I have a need to set up a FreeBSD bases system. However, the install > disk crashes > in the BTX loader. > > I don't have the ability to capture the output exactly, however, the > final lines before > the register dump is: > > BTX Loader 1.00 BTX version is 1.01 > console: internal video/keyboard [...] > 1) Is there a known work around or later snapshot that has corrected this > problem. I had this once and found the following hints: Error report: http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032425.html Some discussion about it: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030897.html http://lists.freebsd.org/pipermail/freebsd-qa/2006-September/000783.html Partial fix could be to use GRUB (it helps me on Sun, but does not help on HP servers) And: http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032446.html The btx code can't deal with BIOSes which want to enter protected mode to service the I/Os. USB support in most BIOSen generally does this. I see the same issue with FreeBSD's pxeboot and the PXE client in Etherboot. -- pi@c0mplx.org +49 171 3101372 13 years to go ! From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 20:10:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFF5616A404 for ; Tue, 27 Mar 2007 20:10:40 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4B013C4D3 for ; Tue, 27 Mar 2007 20:10:40 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 27 Mar 2007 16:10:40 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id ILN58548; Tue, 27 Mar 2007 16:10:39 -0400 (EDT) Received: from 65-78-26-179.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.26.179]) by smtp01.lnh.mail.rcn.net with ESMTP; 27 Mar 2007 16:10:19 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.31293.688893.65186@jerusalem.litteratus.org> Date: Tue, 27 Mar 2007 16:10:37 -0400 To: freebsd-current@freebsd.org In-Reply-To: <200703271224.30697.jhb@freebsd.org> References: <200703261523.09636.jhb@freebsd.org> <17929.4637.601099.334416@jerusalem.litteratus.org> <200703271224.30697.jhb@freebsd.org> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 20:10:41 -0000 John Baldwin writes: > > et seq.. (Specifically, see kern/72294 which is still open 2.5 > > years later.) > > That PR number maps to a ports PR, My typo: make it kern/72293. Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 20:16:57 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D77E416A404; Tue, 27 Mar 2007 20:16:57 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id 5102E13C489; Tue, 27 Mar 2007 20:16:56 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([85.172.12.131]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l2RKGaCS049416; Wed, 28 Mar 2007 00:16:46 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HWI5t-0000KC-Up; Wed, 28 Mar 2007 00:16:37 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Wed, 28 Mar 2007 00:16:37 +0400 Message-ID: <33186202@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: freebsd-emulation@FreeBSD.org Subject: [HEADS UP] a new EXPERIMENTAL port emulators/linux_base-fc6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 20:16:57 -0000 Hi! I've just committed a new EXPERIMENTAL port emulators/linux_base-fc6. ATTENTION! The port is experimental for now. Use it at your own risk. This port may be used only with 7-CURRENT and compat.linux.osrelease=2.6.16. Said that I should admit that I've been using this port with FC4 infrastructure ports successfully at -CURRENT for about several months with following applications: - print/acroread7 - www/linux-opera - www/linux-firefox - www/linux-flashplugin7 - mail/linux-thunderbird - multimedia/linux-realplayer - net/skype (works fine but coredumps when exitting -- under investigation) - www/linux-mozilla -- doesn't run (some new... or old libraries are needed) To use/test the port (along with linux FC4 infrastructure ports) you should do: 0. Backup all your vital information! 1. Remove the current linux base port. 2. Add to your /etc/make.conf "OVERRIDE_LINUX_BASE_PORT=fc6". 3. Make sure no linux application is running. 4. Set apropriate sysctl (compat.linux.osrelease=2.6.16). 5. Install emulation/linux_base-fc6. 5a. Those who use linux ports with automatic plist building should apply the following patch: ftp://mail.ipt.ru/pub/FreeBSD/patches/bsd.linux-rpm.mk-autoplist.diff That should be enough at most circumstances. If you have difficulties, please be sure to expand item 1 to: 1a. Remove all ports which depends on linux base port. 1b. Remove linux base port. 1c. Clean /compat/linux/ directory. In case you want to get rid of the port, deinstall it, then return back compat.linux.osrelease to 2.4.2 (as usual make sure that no linux application is running) and remove from /etc/make.conf the line containing the OVERRIDE_LINUX_BASE_PORT variable. All questions, reports, suggestions etc. please route to freebsd-emulation@. Fedora Core 6 ports (FC6 infrastructure ports) are coming soon... ;-) This port wouldn't appear without netchild's help. Thank you, Alexander! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 20:54:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9323416A404; Tue, 27 Mar 2007 20:54:44 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4B83B13C4C6; Tue, 27 Mar 2007 20:54:44 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 3BB7A8BCD2E; Tue, 27 Mar 2007 22:27:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihim8z63e2qP; Tue, 27 Mar 2007 22:27:16 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C55538BCD1E; Tue, 27 Mar 2007 22:27:16 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l2RKRGwS025872; Tue, 27 Mar 2007 22:27:16 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Mar 2007 22:27:15 +0200 From: Roman Divacky To: Boris Samorodov Message-ID: <20070327202715.GA25822@freebsd.org> References: <33186202@bsam.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33186202@bsam.ru> User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Tue, 27 Mar 2007 21:49:58 +0000 Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [HEADS UP] a new EXPERIMENTAL port emulators/linux_base-fc6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 20:54:44 -0000 On Wed, Mar 28, 2007 at 12:16:37AM +0400, Boris Samorodov wrote: > Hi! > > > I've just committed a new EXPERIMENTAL port emulators/linux_base-fc6. > > ATTENTION! The port is experimental for now. Use it at your own risk. This > port may be used only with 7-CURRENT and compat.linux.osrelease=2.6.16. > > Said that I should admit that I've been using this port with FC4 > infrastructure ports successfully at -CURRENT for about several months > with following applications: > - print/acroread7 > - www/linux-opera > - www/linux-firefox > - www/linux-flashplugin7 > - mail/linux-thunderbird > - multimedia/linux-realplayer > - net/skype (works fine but coredumps when exitting -- under investigation) > - www/linux-mozilla -- doesn't run (some new... or old libraries are needed) > > To use/test the port (along with linux FC4 infrastructure ports) you > should do: > > 0. Backup all your vital information! > 1. Remove the current linux base port. > 2. Add to your /etc/make.conf "OVERRIDE_LINUX_BASE_PORT=fc6". > 3. Make sure no linux application is running. > 4. Set apropriate sysctl (compat.linux.osrelease=2.6.16). as far as I am informed fc6@2.6.16 will try to use openat() which does not exist in -CURRENT yet (it's in perforce) so I'd suggest set the osrelease to 2.6.15 instead... I hope to get openat() commited soon to src.. anyone willing to commit it? :) roman From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 22:08:07 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E24CD16A401; Tue, 27 Mar 2007 22:08:07 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id 59E7C13C44B; Tue, 27 Mar 2007 22:08:07 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([85.172.12.131]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l2RM7gM2059934; Wed, 28 Mar 2007 02:07:52 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HWJpQ-0000ET-8t; Wed, 28 Mar 2007 02:07:44 +0400 To: Roman Divacky References: <33186202@bsam.ru> <20070327202715.GA25822@freebsd.org> From: Boris Samorodov Date: Wed, 28 Mar 2007 02:07:44 +0400 In-Reply-To: <20070327202715.GA25822@freebsd.org> (Roman Divacky's message of "Tue, 27 Mar 2007 22:27:15 +0200") Message-ID: <43903999@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [HEADS UP] a new EXPERIMENTAL port emulators/linux_base-fc6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 22:08:08 -0000 On Tue, 27 Mar 2007 22:27:15 +0200 Roman Divacky wrote: > On Wed, Mar 28, 2007 at 12:16:37AM +0400, Boris Samorodov wrote: > > I've just committed a new EXPERIMENTAL port emulators/linux_base-fc6. > > > > ATTENTION! The port is experimental for now. Use it at your own risk. This > > port may be used only with 7-CURRENT and compat.linux.osrelease=2.6.16. > > > > Said that I should admit that I've been using this port with FC4 > > infrastructure ports successfully at -CURRENT for about several months > > with following applications: > > - print/acroread7 > > - www/linux-opera > > - www/linux-firefox > > - www/linux-flashplugin7 > > - mail/linux-thunderbird > > - multimedia/linux-realplayer > > - net/skype (works fine but coredumps when exitting -- under investigation) > > - www/linux-mozilla -- doesn't run (some new... or old libraries are needed) > > > > To use/test the port (along with linux FC4 infrastructure ports) you > > should do: > > > > 0. Backup all your vital information! > > 1. Remove the current linux base port. > > 2. Add to your /etc/make.conf "OVERRIDE_LINUX_BASE_PORT=fc6". > > 3. Make sure no linux application is running. > > 4. Set apropriate sysctl (compat.linux.osrelease=2.6.16). > as far as I am informed fc6@2.6.16 will try to use openat() which > does not exist in -CURRENT yet (it's in perforce) so I'd suggest My experience shows that it's not a big deal -- only exitting from skype has an effect. Well, having the port at the ports tree, you may test it yourself. ;-) > set the osrelease to 2.6.15 instead... Unfortunately I somehow messed up my i386-current, xorg and NVIDIA and can't test it right now. But as I recall from my tests (before the mess) even when I set 2.6.15, ktrace shows that openat calls were present... > I hope to get openat() commited soon to src.. anyone willing to commit it? :) +1 WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 22:11:09 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AF6516A401 for ; Tue, 27 Mar 2007 22:11:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 27A5913C48C for ; Tue, 27 Mar 2007 22:11:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 27 Mar 2007 14:42:17 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 43DB9125AF7; Tue, 27 Mar 2007 15:11:08 -0700 (PDT) Message-ID: <4609967B.3040708@elischer.org> Date: Tue, 27 Mar 2007 15:11:07 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Boris Samorodov References: <33186202@bsam.ru> <20070327202715.GA25822@freebsd.org> <43903999@bsam.ru> In-Reply-To: <43903999@bsam.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Roman Divacky Subject: Re: [HEADS UP] a new EXPERIMENTAL port emulators/linux_base-fc6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 22:11:09 -0000 Boris Samorodov wrote: > On Tue, 27 Mar 2007 22:27:15 +0200 Roman Divacky wrote: >> On Wed, Mar 28, 2007 at 12:16:37AM +0400, Boris Samorodov wrote: > [...] >> I hope to get openat() commited soon to src.. anyone willing to commit it? :) > > +1 > > > WBR I can do it if you tell me where the diff is and guarantee that it is tested. From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 22:18:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AB2916A400 for ; Tue, 27 Mar 2007 22:18:15 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id 23C2013C44B for ; Tue, 27 Mar 2007 22:18:15 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from darklight.abyss.local (darklight.abyss.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 3A74862D456 for ; Wed, 28 Mar 2007 02:18:13 +0400 (MSD) Received: from darklight.abyss.local (yuri@localhost [127.0.0.1]) by darklight.abyss.local (8.13.8/8.13.8) with ESMTP id l2RMI5IQ003709 for ; Wed, 28 Mar 2007 02:18:05 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) Received: (from yuri@localhost) by darklight.abyss.local (8.13.8/8.13.8/Submit) id l2RMI3YG003708 for freebsd-current@freebsd.org; Wed, 28 Mar 2007 02:18:03 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) X-Authentication-Warning: darklight.abyss.local: yuri set sender to y.pankov@irbis.net.ru using -f Date: Wed, 28 Mar 2007 02:18:02 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20070327221801.GA957@darklight.abyss.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: ClamAV 0.90.1/2944/Tue Mar 27 23:36:49 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Wed, 28 Mar 2007 02:18:13 +0400 (MSD) Subject: [nfe] NVIDIA nForce4 CK804 MCP9 isn't working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 22:18:15 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've tried to use if_nfe with NVIDIA nForce4 CK804 MCP9 NIC (was using if_nve before without issues). FreeBSD 7.0-CURRENT #3: Wed Mar 28 00:44:12 MSD 2007 amd64 almost GENERIC kernel, only changes are SCHED_ULE and nodevice nve. dmesg: nfe0: port 0xe800-0xe807 mem 0xf5102000-0xf5102fff irq 23 at device 10.0 on pci0 nfe0: using obsoleted if_watchdog interface nfe0: bpf attached nfe0: Ethernet address: 00:0f:ea:7d:f3:20 nfe0: [MPSAFE] nfe0: [ITHREAD] miibus1: on nfe0 ciphy0: PHY 7 on miibus1 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: link state changed to DOWN nfe0: gigabit link up nfe0: link state changed to UP pciconf: nfe0@pci0:10:0: class=3D0x068000 card=3D0xe0001458 chip=3D0x005710de rev=3D= 0xa3 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'nForce4 Ultra NVidia Network Bus Enumerator' class =3D bridge ifconfig: nfe0: flags=3D8843 metric 0 mtu 1500 options=3D2b ether 00:0f:ea:7d:f3:20 inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (1000baseTX ) status: active ping 10.10.10.2 gives following tcpdump output: 01:45:37.304300 arp who-has 10.10.10.2 tell 10.10.10.1 01:45:38.305363 arp who-has 10.10.10.2 tell 10.10.10.1 01:45:39.306300 arp who-has 10.10.10.2 tell 10.10.10.1 and so on... arp -a: ? (10.10.10.2) at (incomplete) on nfe0 [ethernet] Manually changing media options, -rxcsum, -txcsum, adding static ARP entry for 10.10.10.2 doesn't help. (and to mention once more, exactly the same setup, including ethernet media options, works with if_nve). --=20 Yuri --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGCZgY8hBlB0qMSXYRAtnoAKDeeZ4M2+94Pl6lznSEVyjqKGoSMgCgsL6l yjjJ7FqH6PSPTvOxlbw7RYM= =L/ch -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 23:09:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5B4216A401; Tue, 27 Mar 2007 23:09:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7597E13C468; Tue, 27 Mar 2007 23:09:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2RN985C010619; Tue, 27 Mar 2007 19:09:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2RN988m059769; Tue, 27 Mar 2007 19:09:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 77AD773039; Tue, 27 Mar 2007 18:09:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070327230908.77AD773039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 18:09:08 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 23:09:09 -0000 TB --- 2007-03-27 22:09:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-27 22:09:26 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-03-27 22:09:26 - cleaning the object tree TB --- 2007-03-27 22:09:57 - checking out the source tree TB --- 2007-03-27 22:09:57 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-03-27 22:09:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-27 22:21:19 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-27 22:21:19 - cd /src TB --- 2007-03-27 22:21:19 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 22:21:20 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-27 23:09:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-27 23:09:08 - ERROR: failed to build world TB --- 2007-03-27 23:09:08 - tinderbox aborted TB --- 0.74 user 2.34 system 3581.68 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 23:12:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77B8416A405; Tue, 27 Mar 2007 23:12:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1D23713C46A; Tue, 27 Mar 2007 23:12:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2RNCTfP010899; Tue, 27 Mar 2007 19:12:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2RNCTBo061505; Tue, 27 Mar 2007 19:12:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7858773039; Tue, 27 Mar 2007 18:12:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070327231229.7858773039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 18:12:29 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 23:12:35 -0000 TB --- 2007-03-27 22:15:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-27 22:15:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-03-27 22:15:59 - cleaning the object tree TB --- 2007-03-27 22:16:26 - checking out the source tree TB --- 2007-03-27 22:16:26 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-03-27 22:16:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-27 22:25:52 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-27 22:25:52 - cd /src TB --- 2007-03-27 22:25:52 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 22:25:53 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-27 23:12:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-27 23:12:29 - ERROR: failed to build world TB --- 2007-03-27 23:12:29 - tinderbox aborted TB --- 0.51 user 2.12 system 3389.87 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 27 23:34:26 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3303216A401 for ; Tue, 27 Mar 2007 23:34:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F196C13C45A for ; Tue, 27 Mar 2007 23:34:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7A10E4719C; Tue, 27 Mar 2007 18:34:25 -0500 (EST) Date: Wed, 28 Mar 2007 00:34:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org, stable@FreeBSD.org Message-ID: <20070328003340.L98103@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Looking for users of IPX over IP tunneling (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rwatson@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 23:34:26 -0000 Please reply privately to this e-mail if you are using IPX over IP tunneling. See below for details. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Tue, 27 Mar 2007 09:08:30 +0100 (BST) From: Robert Watson To: net@FreeBSD.org Subject: Re: Looking for users of IPX over IP tunneling On Mon, 26 Feb 2007, Robert Watson wrote: > Over the next couple of weeks, I will be reviewing the set of non-MPSAFE > network stack components in preparation for a status update to the arch@ > mailing list. One of the remaining components that requires Giant is the IPX > over IP tunneling facility (ipx_ip). I'd like to solicit users of this > facility, if any, to work with me in testing locking patches I'm currently > developing against FreeBSD 7.x. > > I'm actually not entirely convinced this feature works, so would also like to > hear from users of IPX over IP tunneling for this reason. I've found a > couple of bugs that would result in improper error messages being returned, > etc. There's also a comment in the NOTES file that this feature is "not > available". Still looking for IPX over IP users. Please let me know if you use IPX over IP tunneling support, and/or if you would be able to test MPSAFEty patches on 6.x or 7.x. The other easy route here is to remove IPX over IP tunnel support from 7.0 and then reintroduce it if testers are found in the future, but such scenarios generally don't lead to feature re-introduction, so if this is a feature you care about, then please get in touch with me. :-) Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 00:14:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 024D616A40B; Wed, 28 Mar 2007 00:14:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BED8E13C4B0; Wed, 28 Mar 2007 00:14:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S0Er1n015159; Tue, 27 Mar 2007 20:14:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S0ErWl023648; Tue, 27 Mar 2007 20:14:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6605C73039; Tue, 27 Mar 2007 19:14:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328001452.6605C73039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 19:14:52 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 00:14:54 -0000 TB --- 2007-03-27 23:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-27 23:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-03-27 23:15:00 - cleaning the object tree TB --- 2007-03-27 23:15:45 - checking out the source tree TB --- 2007-03-27 23:15:45 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-03-27 23:15:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-27 23:25:17 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-27 23:25:17 - cd /src TB --- 2007-03-27 23:25:17 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 23:25:20 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 00:14:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 00:14:51 - ERROR: failed to build world TB --- 2007-03-28 00:14:51 - tinderbox aborted TB --- 0.90 user 3.62 system 3591.23 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 00:15:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAF9616A47B; Wed, 28 Mar 2007 00:15:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 843F413C459; Wed, 28 Mar 2007 00:15:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S0F1qQ015172; Tue, 27 Mar 2007 20:15: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.13.8/8.13.8) with ESMTP id l2S0F1dX023734; Tue, 27 Mar 2007 20:15:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E017F7303E; Tue, 27 Mar 2007 19:15:00 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328001500.E017F7303E@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 19:15:00 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 00:15:02 -0000 TB --- 2007-03-27 23:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-27 23:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2007-03-27 23:15:00 - cleaning the object tree TB --- 2007-03-27 23:15:30 - checking out the source tree TB --- 2007-03-27 23:15:30 - cd /tinderbox/HEAD/arm/arm TB --- 2007-03-27 23:15:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-27 23:25:17 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-27 23:25:17 - cd /src TB --- 2007-03-27 23:25:17 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 23:25:20 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 00:15:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 00:15:00 - ERROR: failed to build world TB --- 2007-03-28 00:15:00 - tinderbox aborted TB --- 0.49 user 1.69 system 3600.11 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 01:13:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A47516A403; Wed, 28 Mar 2007 01:13:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D682613C465; Wed, 28 Mar 2007 01:13:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S1D1pC018559; Tue, 27 Mar 2007 21:13:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S1D1L5030189; Tue, 27 Mar 2007 21:13:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A26A973039; Tue, 27 Mar 2007 20:13:00 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328011300.A26A973039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 20:13:00 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 01:13:02 -0000 TB --- 2007-03-28 00:14:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 00:14:52 - starting HEAD tinderbox run for i386/i386 TB --- 2007-03-28 00:14:52 - cleaning the object tree TB --- 2007-03-28 00:15:42 - checking out the source tree TB --- 2007-03-28 00:15:42 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-03-28 00:15:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 00:24:41 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 00:24:41 - cd /src TB --- 2007-03-28 00:24:41 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 00:24:42 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 01:13:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 01:13:00 - ERROR: failed to build world TB --- 2007-03-28 01:13:00 - tinderbox aborted TB --- 0.88 user 2.93 system 3487.30 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 01:13:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B19316A402; Wed, 28 Mar 2007 01:13:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4882113C46A; Wed, 28 Mar 2007 01:13:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S1D9QO018577; Tue, 27 Mar 2007 21:13:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S1D9Lh030258; Tue, 27 Mar 2007 21:13:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A91057303E; Tue, 27 Mar 2007 20:13:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328011309.A91057303E@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 20:13:09 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 01:13:10 -0000 TB --- 2007-03-28 00:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 00:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-03-28 00:15:00 - cleaning the object tree TB --- 2007-03-28 00:15:44 - checking out the source tree TB --- 2007-03-28 00:15:44 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-03-28 00:15:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 00:24:41 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 00:24:41 - cd /src TB --- 2007-03-28 00:24:41 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 00:24:42 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 01:13:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 01:13:09 - ERROR: failed to build world TB --- 2007-03-28 01:13:09 - tinderbox aborted TB --- 0.73 user 2.86 system 3488.64 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 02:19:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E172C16A404; Wed, 28 Mar 2007 02:19:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9165213C4C3; Wed, 28 Mar 2007 02:19:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S2JaGR022934; Tue, 27 Mar 2007 22:19:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S2JZB2068995; Tue, 27 Mar 2007 22:19:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B56C673039; Tue, 27 Mar 2007 21:19:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328021935.B56C673039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 21:19:35 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 02:19:37 -0000 TB --- 2007-03-28 01:13:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 01:13:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-03-28 01:13:09 - cleaning the object tree TB --- 2007-03-28 01:14:15 - checking out the source tree TB --- 2007-03-28 01:14:15 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-03-28 01:14:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 01:26:23 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 01:26:23 - cd /src TB --- 2007-03-28 01:26:23 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 01:26:24 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 02:19:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 02:19:35 - ERROR: failed to build world TB --- 2007-03-28 02:19:35 - tinderbox aborted TB --- 0.65 user 2.52 system 3985.34 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 02:34:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDDF916A401; Wed, 28 Mar 2007 02:34:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC6E13C489; Wed, 28 Mar 2007 02:34:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S2YWCi024018; Tue, 27 Mar 2007 22:34:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S2YVmb090474; Tue, 27 Mar 2007 22:34:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B049573039; Tue, 27 Mar 2007 21:34:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328023431.B049573039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 21:34:31 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 02:34:33 -0000 TB --- 2007-03-28 01:13:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 01:13:01 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-03-28 01:13:01 - cleaning the object tree TB --- 2007-03-28 01:14:09 - checking out the source tree TB --- 2007-03-28 01:14:09 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-03-28 01:14:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 01:26:23 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 01:26:23 - cd /src TB --- 2007-03-28 01:26:23 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 01:26:24 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 02:34:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 02:34:31 - ERROR: failed to build world TB --- 2007-03-28 02:34:31 - tinderbox aborted TB --- 0.76 user 2.69 system 4890.29 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 03:05:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E01D816A402 for ; Wed, 28 Mar 2007 03:05:17 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id BA03213C43E for ; Wed, 28 Mar 2007 03:05:17 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2S35Hvx010405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Mar 2007 20:05:17 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2S35GaC002525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Mar 2007 20:05:16 -0700 Message-ID: <460B2CFA.6000605@u.washington.edu> Date: Wed, 28 Mar 2007 20:05:30 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070324124732.GA767@nagual.pp.ru> <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <4608DC71.9080001@freebsd.org> <4609CF8B.5090306@u.washington.edu> In-Reply-To: <4609CF8B.5090306@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.27.195334 X-Uwash-Spam: Gauge=XXXI, Probability=31%, Report='DATE_IN_FUTURE_24_48 3.4, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 03:05:18 -0000 Garrett Cooper wrote: > Andre Oppermann wrote: >> Andrey Chernov wrote: >>> On Tue, Mar 27, 2007 at 09:28:10AM +0400, Andrey Chernov wrote: >>>> On Tue, Mar 27, 2007 at 10:11:01PM +0000, Garrett Cooper wrote: >>>>>> The problem is deeper than that ((( >>>>>> I still got the same lockup, just with more net activity. >>>>>> I even try to completely disable sack, with the same result, so >>>>>> probem is somewhere else. Last working kernel still from Mar 22. >>>>> I'll give a CVSup / upgrade a try and see what happens. >>>> Additional non-default details from my machine which may (or may not) >>>> affect the thing: >>> Yet one detail about lockup: external pings to the machine works in >>> the lockup situation, but no any TCP services is available. >> I can only think of a TCP_INFO_LOCK() leak here blocking any further >> progress. When I'm back in the office in about an hour I'll prepare >> a test patch. >> >>> Attempting to press power button to initiate soft reboot says that >>> "acpi ... not ready yet". > > I noticed that my machine's been locking up a bit lately (kernel core > dumps in /var/crash), so I'll investigate a bit more if this situation > persists (did a clean rebuild with world and kernel this evening). > > If you want some of my info, please let me know, but I'm not entirely > sure if the issue is net related or another panic to be honest now > (didn't build kernel with debug symbols until now ><). > -Garrett Nevermind my comments about the kernel panic and possible TCP involvement. The issues are probably all related to my SCSI card in the PC (which may or may not be failing). -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 03:15:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B10416A400; Wed, 28 Mar 2007 03:15:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DF3BD13C4C1; Wed, 28 Mar 2007 03:15:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S3F4PE026595; Tue, 27 Mar 2007 23:15:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S3F4QW001163; Tue, 27 Mar 2007 23:15:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 44C9573039; Tue, 27 Mar 2007 22:15:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328031504.44C9573039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 22:15:04 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 03:15:05 -0000 TB --- 2007-03-28 02:19:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 02:19:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-03-28 02:19:35 - cleaning the object tree TB --- 2007-03-28 02:19:57 - checking out the source tree TB --- 2007-03-28 02:19:57 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-03-28 02:19:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 02:27:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 02:27:50 - cd /src TB --- 2007-03-28 02:27:50 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 02:27:51 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 03:15:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 03:15:03 - ERROR: failed to build world TB --- 2007-03-28 03:15:03 - tinderbox aborted TB --- 0.41 user 1.45 system 3328.10 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 03:27:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81B9016A40E; Wed, 28 Mar 2007 03:27:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 31C3913C43E; Wed, 28 Mar 2007 03:27:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S3RPkx027332; Tue, 27 Mar 2007 23:27:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S3RPdQ095439; Tue, 27 Mar 2007 23:27:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 20CA473039; Tue, 27 Mar 2007 22:27:25 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328032725.20CA473039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 22:27:25 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 03:27:26 -0000 TB --- 2007-03-28 02:34:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 02:34:31 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-03-28 02:34:31 - cleaning the object tree TB --- 2007-03-28 02:34:48 - checking out the source tree TB --- 2007-03-28 02:34:48 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-03-28 02:34:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 02:41:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 02:41:56 - cd /src TB --- 2007-03-28 02:41:56 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 02:41:57 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 03:27:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 03:27:25 - ERROR: failed to build world TB --- 2007-03-28 03:27:25 - tinderbox aborted TB --- 0.48 user 1.45 system 3173.26 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 04:01:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BC7016A400 for ; Wed, 28 Mar 2007 04:01:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDE813C448 for ; Wed, 28 Mar 2007 04:01:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2491033wxc for ; Tue, 27 Mar 2007 21:01:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=oS+BrRqEGp2Mb9zAwSFzVdlGy5kVkxYYqiAXBbcexCpgM02kYQxQ5x/LZ0lg/PHEFzeXnc5WGExxxmdE4W1b+lW81GtbXEwE6TfaiV80LOuaf7diHgEw210OSjqL+PvuVXoZeB/epXznqZgNtvNQ2CEbvgXZXNy3MAYIvwteF2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=XWgvA1KTpvxOmp4Ii2mgKnw+Xcku+Wei/xHHqooxJdY3Ixbjtm2Y/mvx0z3HpNNM8B5l3r8b7lYC7k1BVkavV5PgvTxT9OuMuH4bHDsmdKTHSXwV8MYtptZ9PoPyBcpwaFDT2fJHvfY9pSTonTN5z3PBUFm3QnH2ILv5szYcLuc= Received: by 10.70.118.4 with SMTP id q4mr898650wxc.1175054511441; Tue, 27 Mar 2007 21:01:51 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 12sm46251667nzn.2007.03.27.21.01.48; Tue, 27 Mar 2007 21:01:49 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l2S47LXx056885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 13:07:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2S47HMp056884; Wed, 28 Mar 2007 13:07:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 28 Mar 2007 13:07:17 +0900 From: Pyun YongHyeon To: Yuri Pankov Message-ID: <20070328040717.GA56450@cdnetworks.co.kr> References: <20070327221801.GA957@darklight.abyss.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20070327221801.GA957@darklight.abyss.local> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: [nfe] NVIDIA nForce4 CK804 MCP9 isn't working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 04:01:52 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 28, 2007 at 02:18:02AM +0400, Yuri Pankov wrote: > Hi, > > I've tried to use if_nfe with NVIDIA nForce4 CK804 MCP9 NIC (was > using if_nve before without issues). > > FreeBSD 7.0-CURRENT #3: Wed Mar 28 00:44:12 MSD 2007 amd64 > > almost GENERIC kernel, only changes are SCHED_ULE and nodevice nve. > > dmesg: > nfe0: port 0xe800-0xe807 > mem 0xf5102000-0xf5102fff irq 23 at device 10.0 on pci0 > nfe0: using obsoleted if_watchdog interface > nfe0: bpf attached > nfe0: Ethernet address: 00:0f:ea:7d:f3:20 > nfe0: [MPSAFE] > nfe0: [ITHREAD] > miibus1: on nfe0 > ciphy0: PHY 7 on miibus1 > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: link state changed to DOWN > nfe0: gigabit link up > nfe0: link state changed to UP > > pciconf: > nfe0@pci0:10:0: class=0x068000 card=0xe0001458 chip=0x005710de rev=0xa3 > hdr=0x00 > vendor = 'Nvidia Corp' > device = 'nForce4 Ultra NVidia Network Bus Enumerator' > class = bridge > > ifconfig: > nfe0: flags=8843 metric 0 mtu > 1500 > options=2b > ether 00:0f:ea:7d:f3:20 > inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > ping 10.10.10.2 gives following tcpdump output: > 01:45:37.304300 arp who-has 10.10.10.2 tell 10.10.10.1 > 01:45:38.305363 arp who-has 10.10.10.2 tell 10.10.10.1 > 01:45:39.306300 arp who-has 10.10.10.2 tell 10.10.10.1 > and so on... > > arp -a: > ? (10.10.10.2) at (incomplete) on nfe0 [ethernet] > > Manually changing media options, -rxcsum, -txcsum, adding static ARP > entry for 10.10.10.2 doesn't help. > > (and to mention once more, exactly the same setup, including ethernet > media options, works with if_nve). > How about new nfe(4) in the following URL? http://people.freebsd.org/~yongari/nfe/if_nfe.c http://people.freebsd.org/~yongari/nfe/if_nfereg.h http://people.freebsd.org/~yongari/nfe/if_nfevar.h I'm not sure but you may also need to apply attached ciphy(4) patch. > -- > Yuri -- Regards, Pyun YongHyeon --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ciphy.patch" Index: ciphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/ciphy.c,v retrieving revision 1.8 diff -u -r1.8 ciphy.c --- ciphy.c 2 Dec 2006 19:36:25 -0000 1.8 +++ ciphy.c 28 Mar 2007 03:58:10 -0000 @@ -91,6 +91,7 @@ MII_PHY_DESC(CICADA, CS8201), MII_PHY_DESC(CICADA, CS8201A), MII_PHY_DESC(CICADA, CS8201B), + MII_PHY_DESC(VITESSE, VSC8601), MII_PHY_END }; @@ -339,7 +340,25 @@ static void ciphy_reset(struct mii_softc *sc) { + struct mii_data *mii; + uint16_t val; + mii = sc->mii_pdata; + if (strcmp(device_get_name(device_get_parent(sc->mii_dev)), + "nfe") == 0) { + /* need to set for 2.5V RGMII for NVIDIA adapters */ + val = PHY_READ(sc, CIPHY_MII_ECTL1); + val &= ~(CIPHY_ECTL1_IOVOL | CIPHY_ECTL1_INTSEL); + val |= (CIPHY_IOVOL_2500MV | CIPHY_INTSEL_RGMII); + PHY_WRITE(sc, CIPHY_MII_ECTL1, val); + /* From Linux. */ + val = PHY_READ(sc, CIPHY_MII_AUXCSR); + val |= CIPHY_AUXCSR_MDPPS; + PHY_WRITE(sc, CIPHY_MII_AUXCSR, val); + val = PHY_READ(sc, CIPHY_MII_10BTCSR); + val |= CIPHY_10BTCSR_ECHO; + PHY_WRITE(sc, CIPHY_MII_10BTCSR, val); + } mii_phy_reset(sc); DELAY(1000); } @@ -396,6 +415,8 @@ } break; + case MII_MODEL_VITESSE_VSC8601: + break; default: device_printf(sc->mii_dev, "unknown CICADA PHY model %x\n", model); Index: ciphyreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/ciphyreg.h,v retrieving revision 1.2 diff -u -r1.2 ciphyreg.h --- ciphyreg.h 6 Jan 2005 01:42:55 -0000 1.2 +++ ciphyreg.h 28 Mar 2007 03:58:11 -0000 @@ -251,6 +251,16 @@ /* Extended PHY control register #1 */ #define CIPHY_MII_ECTL1 0x17 #define CIPHY_ECTL1_ACTIPHY 0x0020 /* Enable ActiPHY power saving */ +#define CIPHY_ECTL1_IOVOL 0x0e00 /* MAC interface and I/O voltage select */ +#define CIPHY_ECTL1_INTSEL 0xf000 /* select MAC interface */ + +#define CIPHY_IOVOL_3300MV 0x0000 /* 3.3V for I/O pins */ +#define CIPHY_IOVOL_2500MV 0x0200 /* 2.5V for I/O pins */ + +#define CIPHY_INTSEL_GMII 0x0000 /* GMII/MII */ +#define CIPHY_INTSEL_RGMII 0x1000 +#define CIPHY_INTSEL_TBI 0x2000 +#define CIPHY_INTSEL_RTBI 0x3000 /* Extended PHY control register #2 */ #define CIPHY_MII_ECTL2 0x18 Index: miidevs =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v retrieving revision 1.41 diff -u -r1.41 miidevs --- miidevs 21 Feb 2007 18:17:44 -0000 1.41 +++ miidevs 28 Mar 2007 03:58:11 -0000 @@ -66,6 +66,7 @@ oui SIS 0x00e006 Silicon Integrated Systems oui TDK 0x00c039 TDK oui TI 0x080028 Texas Instruments +oui VITESSE 0x0001c1 Vitesse Semiconductor oui XAQTI 0x00e0ae XaQti Corp. oui MARVELL 0x005043 Marvell Semiconductor oui xxMARVELL 0x000ac2 Marvell Semiconductor @@ -135,6 +136,7 @@ /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY +model VITESSE VSC8601 0x0002 VSC8601 10/100/1000TX PHY model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY --FCuugMFkClbJLl1L-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 04:29:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80E5B16A400; Wed, 28 Mar 2007 04:29:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4904913C46E; Wed, 28 Mar 2007 04:29:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S4T6xu030321; Wed, 28 Mar 2007 00:29:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S4T6TH020153; Wed, 28 Mar 2007 00:29:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1AB7673039; Tue, 27 Mar 2007 23:29:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328042906.1AB7673039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 23:29:05 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 04:29:07 -0000 TB --- 2007-03-28 03:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 03:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-03-28 03:30:00 - cleaning the object tree TB --- 2007-03-28 03:30:26 - checking out the source tree TB --- 2007-03-28 03:30:26 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-03-28 03:30:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 03:39:44 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 03:39:44 - cd /src TB --- 2007-03-28 03:39:44 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 03:39:45 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 04:29:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 04:29:05 - ERROR: failed to build world TB --- 2007-03-28 04:29:05 - tinderbox aborted TB --- 0.38 user 1.58 system 3545.20 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 04:29:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63C2416A400; Wed, 28 Mar 2007 04:29:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1498513C46A; Wed, 28 Mar 2007 04:29:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S4TWYl030351; Wed, 28 Mar 2007 00:29:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S4TWBU020346; Wed, 28 Mar 2007 00:29:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F40FF73039; Tue, 27 Mar 2007 23:29:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328042931.F40FF73039@freebsd-current.sentex.ca> Date: Tue, 27 Mar 2007 23:29:31 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 04:29:33 -0000 TB --- 2007-03-28 03:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 03:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2007-03-28 03:30:00 - cleaning the object tree TB --- 2007-03-28 03:30:27 - checking out the source tree TB --- 2007-03-28 03:30:27 - cd /tinderbox/HEAD/arm/arm TB --- 2007-03-28 03:30:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 03:39:44 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 03:39:44 - cd /src TB --- 2007-03-28 03:39:44 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 03:39:45 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 04:29:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 04:29:31 - ERROR: failed to build world TB --- 2007-03-28 04:29:31 - tinderbox aborted TB --- 0.47 user 1.46 system 3571.33 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 05:26:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7417D16A401; Wed, 28 Mar 2007 05:26:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2513513C45B; Wed, 28 Mar 2007 05:26:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S5QUfj032486; Wed, 28 Mar 2007 01:26:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S5QUXL024155; Wed, 28 Mar 2007 01:26:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 656CE73039; Wed, 28 Mar 2007 00:26:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328052630.656CE73039@freebsd-current.sentex.ca> Date: Wed, 28 Mar 2007 00:26:30 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 05:26:31 -0000 TB --- 2007-03-28 04:29:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 04:29:06 - starting HEAD tinderbox run for i386/i386 TB --- 2007-03-28 04:29:06 - cleaning the object tree TB --- 2007-03-28 04:29:23 - checking out the source tree TB --- 2007-03-28 04:29:23 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-03-28 04:29:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 04:38:13 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 04:38:13 - cd /src TB --- 2007-03-28 04:38:13 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 04:38:15 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 05:26:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 05:26:30 - ERROR: failed to build world TB --- 2007-03-28 05:26:30 - tinderbox aborted TB --- 0.43 user 1.53 system 3443.79 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 05:26:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B094016A401; Wed, 28 Mar 2007 05:26:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 79AB113C448; Wed, 28 Mar 2007 05:26:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S5QewD032493; Wed, 28 Mar 2007 01:26:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2S5Qel1024241; Wed, 28 Mar 2007 01:26:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E54D47303E; Wed, 28 Mar 2007 00:26:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070328052639.E54D47303E@freebsd-current.sentex.ca> Date: Wed, 28 Mar 2007 00:26:39 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 05:26:40 -0000 TB --- 2007-03-28 04:29:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-28 04:29:32 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-03-28 04:29:32 - cleaning the object tree TB --- 2007-03-28 04:29:54 - checking out the source tree TB --- 2007-03-28 04:29:54 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-03-28 04:29:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-28 04:38:13 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-28 04:38:13 - cd /src TB --- 2007-03-28 04:38:13 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 04:38:15 UTC 2007 >>> 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 [...] gzip -cn /src/share/man/man9/pmap_release.9 > pmap_release.9.gz gzip -cn /src/share/man/man9/pmap_remove.9 > pmap_remove.9.gz gzip -cn /src/share/man/man9/pmap_resident_count.9 > pmap_resident_count.9.gz gzip -cn /src/share/man/man9/pmap_zero_page.9 > pmap_zero_page.9.gz gzip -cn /src/share/man/man9/printf.9 > printf.9.gz gzip -cn /src/share/man/man9/prison_check.9 > prison_check.9.gz gzip -cn /src/share/man/man9/priv.9 > priv.9.gz make: don't know how to make priv_check.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-28 05:26:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-28 05:26:39 - ERROR: failed to build world TB --- 2007-03-28 05:26:39 - tinderbox aborted TB --- 0.34 user 1.43 system 3427.84 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 07:46:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B7B216A405; Wed, 28 Mar 2007 07:46:14 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0F62413C468; Wed, 28 Mar 2007 07:46:13 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2S7kCgT019843; Wed, 28 Mar 2007 11:46:12 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2S7kBmp019842; Wed, 28 Mar 2007 11:46:11 +0400 (MSD) (envelope-from ache) Date: Wed, 28 Mar 2007 11:46:11 +0400 From: Andrey Chernov To: Andre Oppermann Message-ID: <20070328074611.GA19740@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Andre Oppermann , Garrett Cooper , freebsd-current@freebsd.org References: <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <46090BA6.5060206@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46090BA6.5060206@freebsd.org> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 07:46:14 -0000 On Tue, Mar 27, 2007 at 02:18:46PM +0200, Andre Oppermann wrote: > Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving > all others at HEAD and look if the bug can be reproduced? Yes! Reverting to 1.327 really helps, lockup is gone! Thanx! -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 08:08:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3783716A401 for ; Wed, 28 Mar 2007 08:08:32 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id B78D513C459 for ; Wed, 28 Mar 2007 08:08:31 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2S88U8W020282 for ; Wed, 28 Mar 2007 12:08:30 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2S88U1t020281 for current@freebsd.org; Wed, 28 Mar 2007 12:08:30 +0400 (MSD) (envelope-from ache) Date: Wed, 28 Mar 2007 12:08:30 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20070328080830.GA20223@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: acpi: reservation ... failed (what is for?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 08:08:32 -0000 I got "reservation ... failed" messages with recent acpi. What they are for? Is the harmless? I notice no bad effects so far. See underlined ones in the output below. Motherboard: ASUS P5AD2-E Deluxe ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI: RSDP @ 0x0xfaf60/0x0024 (v 2 ACPIAM) ACPI: XSDT @ 0x0x3ffa0100/0x0044 (v 1 A M I OEMXSDT 0x01000619 MSFT 0x00000097) ACPI: FACP @ 0x0x3ffa0290/0x00F4 (v 3 A M I OEMFACP 0x01000619 MSFT 0x00000097) ACPI: DSDT @ 0x0x3ffa0400/0x68F4 (v 1 A0144 A0144000 0x00000000 INTL 0x02002026) ACPI: FACS @ 0x0x3ffae000/0x0040 ACPI: APIC @ 0x0x3ffa0390/0x0070 (v 1 A M I OEMAPIC 0x01000619 MSFT 0x00000097) ACPI: OEMB @ 0x0x3ffae040/0x0046 (v 1 A M I AMI_OEM 0x01000619 MSFT 0x00000097) ACPI: MCFG @ 0x0x3ffa6d00/0x003C (v 1 A M I OEMMCFG 0x01000619 MSFT 0x00000097) ioapic0 irqs 0-23 on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acpi0: reservation of 100000, 3ff00000 (3) failed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 08:10:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9396516A400 for ; Wed, 28 Mar 2007 08:10:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE5113C468 for ; Wed, 28 Mar 2007 08:10:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 39B64EB2CFE for ; Wed, 28 Mar 2007 16:09:59 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id VDPugsuhkSN1 for ; Wed, 28 Mar 2007 16:09:52 +0800 (CST) Received: from [10.217.12.249] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 129A6EB0C0E for ; Wed, 28 Mar 2007 16:09:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:x-enigmail-version:content-type; b=j6Bz+qswl+JIBw5qc54by6iCXPzCDoGEFVCVw+F/p3UgOCTkmfBWsnNiZuCWt2f79 IbwbFBkLVh2EziW9Vwe3A== Message-ID: <460A22C9.2040303@delphij.net> Date: Wed, 28 Mar 2007 16:09:45 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1411E34A29262617DF13A753" Subject: (minor) HEADSUP: bzip2 1.0.4 imported X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 08:10:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1411E34A29262617DF13A753 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have just imported bzip2 1.0.4. This is a maintaence release and brings some bugfixes, etc., according to my own and pointyhat, this does not bring any regression. Please keep me informed if anything weird happens. Thanks to the portmgr team (especially kris) for a pointyhat test, and Simon for taking time for SA-05:14.bzip2 reconfirm. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig1411E34A29262617DF13A753 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCiLJOfuToMruuMARCn44AJ9TjVjTKk5Ddi+a3376Zk3NsFTdWwCeP3QT +MttKNjkHruWNSIkDBn2ML4= =987B -----END PGP SIGNATURE----- --------------enig1411E34A29262617DF13A753-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 08:47:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EECF416A405 for ; Wed, 28 Mar 2007 08:47:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D11E13C483 for ; Wed, 28 Mar 2007 08:47:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 16436 invoked from network); 28 Mar 2007 08:15:05 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Mar 2007 08:15:05 -0000 Message-ID: <460A2B97.9040404@freebsd.org> Date: Wed, 28 Mar 2007 10:47:19 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrey Chernov References: <200703251348.58972.nb_root@videotron.ca> <20070325194946.GC79938@kobe.laptop> <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <46090BA6.5060206@freebsd.org> <20070328074611.GA19740@nagual.pp.ru> In-Reply-To: <20070328074611.GA19740@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 08:47:21 -0000 Andrey Chernov wrote: > On Tue, Mar 27, 2007 at 02:18:46PM +0200, Andre Oppermann wrote: > >>Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving >>all others at HEAD and look if the bug can be reproduced? > > > Yes! Reverting to 1.327 really helps, lockup is gone! Thanx! You tried with a fully updated system before the backout as well? There was a time window where TCP was indeed broken. It panic'ed though. I'm looking at the tcp_input() split to find a case where it may go wrong. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 08:51:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BFD516A402; Wed, 28 Mar 2007 08:51:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0003B13C465; Wed, 28 Mar 2007 08:51:05 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2S8p45G020730; Wed, 28 Mar 2007 12:51:04 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2S8p4Je020729; Wed, 28 Mar 2007 12:51:04 +0400 (MSD) (envelope-from ache) Date: Wed, 28 Mar 2007 12:51:04 +0400 From: Andrey Chernov To: Andre Oppermann Message-ID: <20070328085104.GA20674@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Andre Oppermann , Garrett Cooper , freebsd-current@freebsd.org References: <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <46090BA6.5060206@freebsd.org> <20070328074611.GA19740@nagual.pp.ru> <460A2B97.9040404@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460A2B97.9040404@freebsd.org> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 08:51:06 -0000 On Wed, Mar 28, 2007 at 10:47:19AM +0200, Andre Oppermann wrote: > Andrey Chernov wrote: > >On Tue, Mar 27, 2007 at 02:18:46PM +0200, Andre Oppermann wrote: > > > >>Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving > >>all others at HEAD and look if the bug can be reproduced? > > > > > >Yes! Reverting to 1.327 really helps, lockup is gone! Thanx! > > You tried with a fully updated system before the backout as well? > There was a time window where TCP was indeed broken. It panic'ed > though. Yes. My case is not related to SACK options KASSERT - my kernel even not go so far to get that panic and I get lockup even when disable SACK by sysctl. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 10:03:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04D8216A402 for ; Wed, 28 Mar 2007 10:03:16 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8224513C448 for ; Wed, 28 Mar 2007 10:03:15 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so3395805muf for ; Wed, 28 Mar 2007 03:03:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YWkUYdvkNxep1lXvZYkLNjtUebqT+VOohspHDt/hL4DjapczzA3XIRlOXIIZbgt21wMt18vdjbeP2AMf7Qne9VHeQFHV9Cp9e0OPETVL3GEumf1KkVT/B92967RJbOUoXbvevBs4ChTUI7C4031E3ZOVO99h9r4dOwuU3l5/WT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K6iS9TRtyWf0h6Jy7dod+Eaqn4TWRy+F8QexG4PmEp9SV3ExTMmlKCl4C8toq7/A0JfPi964G2+7OMwEiTL7cGJeweygbG/KkDIv9wD/RuOrfZqtOcBWRqsDTXa5E2+zkUyZht3uaCX3qvpGy0ISsFz3CuWcF6h9B+Q1Wkuyg9w= Received: by 10.82.134.12 with SMTP id h12mr18493694bud.1175074724905; Wed, 28 Mar 2007 02:38:44 -0700 (PDT) Received: by 10.82.187.19 with HTTP; Wed, 28 Mar 2007 02:38:44 -0700 (PDT) Message-ID: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Date: Wed, 28 Mar 2007 11:38:44 +0200 From: "Ulrich Spoerlein" To: current@freebsd.org, net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 10:03:16 -0000 Hi, I observe a strange effect, when using the following setup: Three FreeBSD 6.2[1] machines on Gigabit Ethernet using em(4) interfaces. HostC is the NFS server, HostB has /net/share mounted from HostC. I will use HostA and HostB to demonstrate the issue. Picture this: hostA # scp 500MB hostB:/net/share/ Iff the file "500MB" does not yet exist on the NFS share, I can see X MB/s going out of HostA, X MB/s coming in on HostB, X MB/s going out on hostB again and finally X MB/s coming in on HostC. If I run the scp again, I can see X MB/s going out from HostA, 2*X MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's happening is, that HostB issues one NFS READ call for every WRITE call. The traffic flows like this: -----> -----> A B C <----- If I rm(1) the file on the NFS share, then the first scp(1) will not show this behaviour. It is only when overwritting files, that this happens. The real weirdness comes into play, when I simply cp(1) from HostB itself like this: hostB # cp 500MB /net/share/ I can do this over and over again, and _never_ get any noteworthy amount of NFS READ calls, only WRITE. The network traffic is also, as you would expect. Then I tested using ssh(1) instead of scp(1), like this: hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" This works, too. Probably, because sh(1) is truncating the file? So, can someone please explain to me, what is happening and if/how it can be avoided? Cheers, Uli [1] I know this is current, but on stable@ nobody picked up the thread, so I'll try my luck here. From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 10:11:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C708416A403 for ; Wed, 28 Mar 2007 10:11:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF0613C44C for ; Wed, 28 Mar 2007 10:11:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6F6AF2088; Wed, 28 Mar 2007 12:11:54 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 5B70D2086; Wed, 28 Mar 2007 12:11:53 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id D34C3A1073; Wed, 28 Mar 2007 12:11:53 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Scott Long References: <20070323212254.54F7D73039@freebsd-current.sentex.ca> <20070323214145.GA3822@krapfengeist> <46044D6C.1070304@samsco.org> Date: Wed, 28 Mar 2007 12:11:53 +0200 In-Reply-To: <46044D6C.1070304@samsco.org> (Scott Long's message of "Fri, 23 Mar 2007 15:58:04 -0600") Message-ID: <86648lsmmu.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Matteo Riondato , FreeBSD Tinderbox , i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 10:11:58 -0000 Scott Long writes: > The tinderboxes have stricter compile flags than the normal buildworld > environment. The hope is that we'll be able to go to -O2 as the default > optimization someday, which requires the stricter flags. I think what > you're missing here is the -fstrict-aliasing flag. No, the tinderbox just uses -O2 (which implies -fno-strict-aliasing). I highly recommend compiling with -O2, not just for the performance advantages, and not just for the additional warnings it enables, but also because of the additional coverage analysis (required for better optimization) which results in more accurate warnings. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 10:17:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 522C316A405 for ; Wed, 28 Mar 2007 10:17:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA0A13C465 for ; Wed, 28 Mar 2007 10:17:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HWVDI-0003Dn-4Q for freebsd-current@freebsd.org; Wed, 28 Mar 2007 12:17:08 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 12:17:08 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 12:17:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 28 Mar 2007 12:16:53 +0200 Lines: 45 Message-ID: References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFA75766647B18FBF604C509" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 10:17:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFA75766647B18FBF604C509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ulrich Spoerlein wrote: > If I run the scp again, I can see X MB/s going out from HostA, 2*X > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > happening is, that HostB issues one NFS READ call for every WRITE > call. The traffic flows like this: >=20 > -----> -----> > A B C > <----- >=20 > The real weirdness comes into play, when I simply cp(1) from HostB > itself like this: >=20 > hostB # cp 500MB /net/share/ >=20 > I can do this over and over again, and _never_ get any noteworthy > amount of NFS READ calls, only WRITE. The network traffic is also, as > you would expect. Have you tested with a small C program or a script to see if it's the=20 rewriting that's causing reads or is it some weird artifact of scp? --------------enigBFA75766647B18FBF604C509 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGCkCcldnAQVacBcgRAv96AJsHvLGyoNbrhPl3aH3Pc4HJ7XmaXgCdGCnb XDdTho8tei7BT84dJvVQrxM= =bXtr -----END PGP SIGNATURE----- --------------enigBFA75766647B18FBF604C509-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 12:05:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D5616A405 for ; Wed, 28 Mar 2007 12:05:42 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E68513C480 for ; Wed, 28 Mar 2007 12:05:42 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from darklight.abyss.local (darklight.abyss.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 8F52962D455; Wed, 28 Mar 2007 16:05:40 +0400 (MSD) Received: from darklight.abyss.local (yuri@localhost [127.0.0.1]) by darklight.abyss.local (8.13.8/8.13.8) with ESMTP id l2SC5aNt003978; Wed, 28 Mar 2007 16:05:37 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) Received: (from yuri@localhost) by darklight.abyss.local (8.13.8/8.13.8/Submit) id l2SC5XpN003961; Wed, 28 Mar 2007 16:05:33 +0400 (MSD) (envelope-from y.pankov@irbis.net.ru) X-Authentication-Warning: darklight.abyss.local: yuri set sender to y.pankov@irbis.net.ru using -f Date: Wed, 28 Mar 2007 16:05:33 +0400 From: Yuri Pankov To: Pyun YongHyeon Message-ID: <20070328120531.GA732@darklight.abyss.local> References: <20070327221801.GA957@darklight.abyss.local> <20070328040717.GA56450@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20070328040717.GA56450@cdnetworks.co.kr> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: ClamAV 0.90.1/2946/Wed Mar 28 13:36:58 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Wed, 28 Mar 2007 16:05:41 +0400 (MSD) Cc: freebsd-current@freebsd.org Subject: Re: [nfe] NVIDIA nForce4 CK804 MCP9 isn't working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 12:05:42 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2007 at 01:07:17PM +0900, Pyun YongHyeon wrote: > On Wed, Mar 28, 2007 at 02:18:02AM +0400, Yuri Pankov wrote: > > Hi, > >=20 > > I've tried to use if_nfe with NVIDIA nForce4 CK804 MCP9 NIC (was > > using if_nve before without issues). > >=20 > > FreeBSD 7.0-CURRENT #3: Wed Mar 28 00:44:12 MSD 2007 amd64 > >=20 > > almost GENERIC kernel, only changes are SCHED_ULE and nodevice nve. > >=20 > > dmesg: > > nfe0: port 0xe800-0xe807 > > mem 0xf5102000-0xf5102fff irq 23 at device 10.0 on pci0 > > nfe0: using obsoleted if_watchdog interface > > nfe0: bpf attached > > nfe0: Ethernet address: 00:0f:ea:7d:f3:20 > > nfe0: [MPSAFE] > > nfe0: [ITHREAD] > > miibus1: on nfe0 > > ciphy0: PHY 7 on miibus1 > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > nfe0: link state changed to DOWN > > nfe0: gigabit link up > > nfe0: link state changed to UP > >=20 > > pciconf: > > nfe0@pci0:10:0: class=3D0x068000 card=3D0xe0001458 chip=3D0x005710de r= ev=3D0xa3 > > hdr=3D0x00 > > vendor =3D 'Nvidia Corp' > > device =3D 'nForce4 Ultra NVidia Network Bus Enumerator' > > class =3D bridge > >=20 > > ifconfig: > > nfe0: flags=3D8843 metric 0 mtu > > 1500 > > options=3D2b > > ether 00:0f:ea:7d:f3:20 > > inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255 > > media: Ethernet autoselect (1000baseTX ) > > status: active > >=20 > > ping 10.10.10.2 gives following tcpdump output: > > 01:45:37.304300 arp who-has 10.10.10.2 tell 10.10.10.1 > > 01:45:38.305363 arp who-has 10.10.10.2 tell 10.10.10.1 > > 01:45:39.306300 arp who-has 10.10.10.2 tell 10.10.10.1 > > and so on... > >=20 > > arp -a: > > ? (10.10.10.2) at (incomplete) on nfe0 [ethernet] > >=20 > > Manually changing media options, -rxcsum, -txcsum, adding static ARP > > entry for 10.10.10.2 doesn't help. > >=20 > > (and to mention once more, exactly the same setup, including ethernet > > media options, works with if_nve). > >=20 >=20 > How about new nfe(4) in the following URL? > http://people.freebsd.org/~yongari/nfe/if_nfe.c > http://people.freebsd.org/~yongari/nfe/if_nfereg.h > http://people.freebsd.org/~yongari/nfe/if_nfevar.h >=20 > I'm not sure but you may also need to apply attached ciphy(4) patch. >=20 > > --=20 > > Yuri >=20 >=20 >=20 > --=20 > Regards, > Pyun YongHyeon I've tried nfe driver from http://people.freebsd.org/~yongari/nfe/, with and without ciphy patch, still no joy. nfe0: port 0xe800-0xe807 mem 0xf5102000-0xf5102fff irq 23 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf5102000 nfe0: bpf attached nfe0: Ethernet address: 00:0f:ea:7d:f3:20 nfe0: [MPSAFE] nfe0: [FILTER] miibus0: on nfe0 ciphy0: PHY 7 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: link state changed to DOWN nfe0: link state changed to UP nfe0: flags=3D8843 metric 0 mtu 1500 options=3D10b ether 00:0f:ea:7d:f3:20 inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (1000baseTX ) status: active -- Yuri --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGCloL8hBlB0qMSXYRAjJdAJ9nUZcqU7ssTtlX1an6ItOCJJ/qRgCgsS8b glHt9/j9JEEjzJVfyvkEcPA= =DzZ4 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 13:00:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9577316A409 for ; Wed, 28 Mar 2007 13:00:42 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E932C13C468 for ; Wed, 28 Mar 2007 13:00:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 18065 invoked from network); 28 Mar 2007 12:28:25 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Mar 2007 12:28:25 -0000 Message-ID: <460A66F9.7000005@freebsd.org> Date: Wed, 28 Mar 2007 15:00:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrey Chernov , Andre Oppermann , Garrett Cooper , freebsd-current@freebsd.org References: <200703251620.20879.nb_root@videotron.ca> <20070325202749.GA1503@kobe.laptop> <460705AE.5040107@freebsd.org> <20070327045252.GA3256@nagual.pp.ru> <46099675.3040609@u.washington.edu> <20070327052810.GA772@nagual.pp.ru> <20070327054501.GA1026@nagual.pp.ru> <46090BA6.5060206@freebsd.org> <20070328074611.GA19740@nagual.pp.ru> <460A2B97.9040404@freebsd.org> <20070328085104.GA20674@nagual.pp.ru> In-Reply-To: <20070328085104.GA20674@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Latest -current complete lockup (tcp changes?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 13:00:42 -0000 Andrey Chernov wrote: > On Wed, Mar 28, 2007 at 10:47:19AM +0200, Andre Oppermann wrote: >> Andrey Chernov wrote: >>> On Tue, Mar 27, 2007 at 02:18:46PM +0200, Andre Oppermann wrote: >>> >>>> Could you revert sys/netinet/tcp_input.c back to rev. 1.327 while leaving >>>> all others at HEAD and look if the bug can be reproduced? >>> >>> Yes! Reverting to 1.327 really helps, lockup is gone! Thanx! >> You tried with a fully updated system before the backout as well? >> There was a time window where TCP was indeed broken. It panic'ed >> though. > > Yes. My case is not related to SACK options KASSERT - my kernel even not > go so far to get that panic and I get lockup even when disable SACK by > sysctl. The problem is fixed in rev. 1.330 of tcp_input.c. Thanks to Robert for finding the bug. It was a INP_INFO_LOCK leak in the blackhole case that I missed during the tcp_input() split. There was a slight change in semantics. Sorry for the trouble. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 13:11:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9341B16A404 for ; Wed, 28 Mar 2007 13:11:10 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1865113C4BE for ; Wed, 28 Mar 2007 13:11:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so3303166nfc for ; Wed, 28 Mar 2007 06:11:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tZ4+2ZLIdrA84MoQf2fcoUTsvEIFXMD6JtImMQ0WICcowukz9MxejEMLDswORhtRC0g8MJsOYAFjZ27zS9Mc01qMbTMUy5SlQVBzipf0iWdFeKvBdJdPNVtAxFMCzj7IL3kX54My6wazsgF7ivSI4ioljPgH2mjzqGZz2CgJL3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XsCOMvlgyvivtsLue/uESxF136dnDyaqe39pECLSrjoDiVcjBxcNFwXz0Q64abfJQXack6kyTBv00Sqvxz0UQNBIf+UbpDa2UYdmxRgiiepKYx62YqxTB8nOLZzEBtBK147PfqHFUWiaaQ3iDLUNOQlcQk7y9m89/o8Y5nubpeE= Received: by 10.82.178.11 with SMTP id a11mr18794805buf.1175087467552; Wed, 28 Mar 2007 06:11:07 -0700 (PDT) Received: by 10.82.187.19 with HTTP; Wed, 28 Mar 2007 06:11:07 -0700 (PDT) Message-ID: <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> Date: Wed, 28 Mar 2007 15:11:07 +0200 From: "Ulrich Spoerlein" To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 13:11:10 -0000 On 3/28/07, Ivan Voras wrote: > > The traffic flows like this: > > > > -----> -----> > > A B C > > <----- > > Have you tested with a small C program or a script to see if it's the > rewriting that's causing reads or is it some weird artifact of scp? I'm not a big user of scp(1), the reason this problem came up is because Samba has the same problem too. If our Windows Terminal server (over)writes onto the Samba-Export (which in turn is NFS mounted from the fileserver) then we get WRITE *and* READ calls. nfsstat -s shows that the READ column is increasing just as fast/slow as the WRITE column. So while I could work around scp anytime (tar|ssh is better in almost all cases) there is probably no way to work around Samba. What kind of C program or script did you have in mind? My C-foo is very weak ... Cheers, Uli From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 13:02:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 941DE16A404; Wed, 28 Mar 2007 13:02:41 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: from darkircop.org (tapir.cs.ucl.ac.uk [128.16.66.93]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB4913C4BB; Wed, 28 Mar 2007 13:02:41 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: by darkircop.org (Postfix, from userid 0) id B83C46EFB6; Wed, 28 Mar 2007 13:55:42 +0100 (BST) Date: Wed, 28 Mar 2007 13:55:42 +0100 From: Andrea Bittau To: freebsd-current@freebsd.org Message-ID: <20070328125542.GA5457@shorty.sorbonet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Echelon: Bush Bomb War KGB X-Mailman-Approved-At: Wed, 28 Mar 2007 13:55:32 +0000 Cc: sos@freebsd.org Subject: attempt to fix suspend/resume of AHCI SATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 13:02:41 -0000 I have a rough patch for fixing suspend/resume of AHCI SATA. Perhaps someone with more knowledge could write a proper patch. In short, this needs fixing: 1) Restore controller registers 2) Restore channel registers 3) Do-not reattach stuff [e.g. HDD] when receiving a phy-change/attach interrupt on resume. --- Index: ata-all.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.279 diff -u -p -r1.279 ata-all.c --- ata-all.c 23 Feb 2007 16:25:08 -0000 1.279 +++ ata-all.c 28 Mar 2007 12:55:03 -0000 @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD: src/sys/dev/ata/ata- #include #include #include +#include /* device structure */ static d_ioctl_t ata_ioctl; @@ -293,11 +294,16 @@ int ata_resume(device_t dev) { struct ata_channel *ch; + struct ata_pci_controller *ctlr; int error; /* check for valid device */ if (!dev || !(ch = device_get_softc(dev))) return ENXIO; + + ctlr = device_get_softc(device_get_parent(dev)); + if ((error = ctlr->allocate(dev))) + return error; /* reinit the devices, we dont know what mode/state they are in */ error = ata_reinit(dev); Index: ata-chipset.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.192 diff -u -p -r1.192 ata-chipset.c --- ata-chipset.c 12 Mar 2007 15:34:08 -0000 1.192 +++ ata-chipset.c 28 Mar 2007 12:55:05 -0000 @@ -286,6 +286,11 @@ ata_sata_phy_event(void *context, int du mtx_lock(&Giant); /* newbus suckage it needs Giant */ if (tp->action == ATA_C_ATTACH) { + /* XXX */ + if (!device_get_children(tp->dev, &children, &nchildren)) { + device_printf(tp->dev, "Assuming resume attach skipped\n"); + goto out; + } if (bootverbose) device_printf(tp->dev, "CONNECTED\n"); ATA_RESET(tp->dev); @@ -304,6 +309,7 @@ ata_sata_phy_event(void *context, int du if (bootverbose) device_printf(tp->dev, "DISCONNECTED\n"); } +out: mtx_unlock(&Giant); /* suckage code dealt with, release Giant */ free(tp, M_ATA); } Index: ata-pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.c,v retrieving revision 1.121 diff -u -p -r1.121 ata-pci.c --- ata-pci.c 23 Feb 2007 12:18:33 -0000 1.121 +++ ata-pci.c 28 Mar 2007 12:55:05 -0000 @@ -251,6 +251,19 @@ ata_pci_detach(device_t dev) return 0; } +static int +ata_pci_resume(device_t dev) +{ + struct ata_pci_controller *ctlr = device_get_softc(dev); + int rc; + + rc = ctlr->chipinit(dev); + if (rc) + return rc; + + return bus_generic_resume(dev); +} + struct resource * ata_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) @@ -510,7 +523,7 @@ static device_method_t ata_pci_methods[] DEVMETHOD(device_detach, ata_pci_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_resume, ata_pci_resume), /* bus methods */ DEVMETHOD(bus_alloc_resource, ata_pci_alloc_resource), From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 14:30:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F9F016A408 for ; Wed, 28 Mar 2007 14:30:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C15E013C4C9 for ; Wed, 28 Mar 2007 14:30:07 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 18630 invoked from network); 28 Mar 2007 13:57:50 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Mar 2007 13:57:50 -0000 Message-ID: <460A7BEE.9010508@freebsd.org> Date: Wed, 28 Mar 2007 16:30:06 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46094415.3050704@FreeBSD.org> In-Reply-To: <46094415.3050704@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [Fwd: Panic: if_freemulti: protospec not NULL] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 14:30:08 -0000 Bruce M. Simpson wrote: > Patch for this condition is attached. This patch fixes the panic for me. -- Andre > This particular bug is irritating: the IPv4 stack joins 224.0.0.1 once > for every IPv4 unicast address configured in the stack. This is > incorrect behaviour. The implementation of refcounting has exposed this > bug. The fix is not particularly elegant. > > It is most likely a left-over from the FreeBSD 2.x/3.x era when IPv4 > 'aliases' were first introduced. At that point in time the IGMP code in > FreeBSD would allow groups to be joined on a per-IPv4-address basis, > which is inconsistent with the IGMPv2/v3 specified behaviour (and indeed > that addressed in future multicast RFCs). > > It seems that there are other situations where the stack is not > adequately equipped to deal with interfaces going away unexpectedly. We > can't afford to be complacent about multicast code on the basis of 'it's > not the critical path', because it is an integral component of IPv6, and > many ideas which people are trying to implement in IPv4 also require > that the multicast code is fit for purpose. > > We would do well to have more people available to help on reviewing and > possibly rewriting parts of the network stack from a perspective of > correctness, not just performance. If this interests you please consider > signing up to the Wiki and updating the page at > http://wiki.freebsd.org/NetworkRFCCompliance. > > Regards, > BMS > > > ------------------------------------------------------------------------ > > ==== //depot/user/bms/netdev/sys/netinet/in.c#11 - /home/bms/p4/netdev/sys/netinet/in.c ==== > --- /tmp/tmp.1127.0 Tue Mar 27 16:43:56 2007 > +++ /home/bms/p4/netdev/sys/netinet/in.c Tue Mar 27 16:40:04 2007 > @@ -212,6 +212,11 @@ > /* > * Generic internet control operations (ioctl's). > * Ifp is 0 if not an interface-specific ioctl. > + * > + * XXX: This code has some nice big juicy bugs related to interface > + * attach and detach. Specifically, the 224.0.0.1 group is now only > + * joined on the first IPv4 address configured on an interface, and > + * only left when all IPv4 state is torn down for an interface. > */ > /* ARGSUSED */ > int > @@ -230,7 +235,9 @@ > struct in_aliasreq *ifra = (struct in_aliasreq *)data; > struct sockaddr_in oldaddr; > int error, hostIsNew, iaIsNew, maskIsNew, s; > + int iaIsFirst; > > + iaIsFirst = 0; > iaIsNew = 0; > > switch (cmd) { > @@ -282,6 +289,8 @@ > break; > } > } > + if (ia == NULL) > + iaIsFirst = 1; > } > > switch (cmd) { > @@ -423,8 +432,20 @@ > (struct sockaddr_in *) &ifr->ifr_addr, 1); > if (error != 0 && iaIsNew) > break; > - if (error == 0) > + if (error == 0) { > + /* > + * Only join 224.0.0.1 if this is the very first > + * IPv4 unicast address which has been configured > + * on this ifnet. > + */ > + if (iaIsFirst && (ifp->if_flags & IFF_MULTICAST) != 0) { > + struct in_addr addr; > + > + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); > + in_addmulti(&addr, ifp); > + } > EVENTHANDLER_INVOKE(ifaddr_event, ifp); > + } > return (0); > > case SIOCSIFNETMASK: > @@ -467,8 +488,20 @@ > if ((ifp->if_flags & IFF_BROADCAST) && > (ifra->ifra_broadaddr.sin_family == AF_INET)) > ia->ia_broadaddr = ifra->ifra_broadaddr; > - if (error == 0) > + if (error == 0) { > + /* > + * Only join 224.0.0.1 if this is the very first > + * IPv4 unicast address which has been configured > + * on this ifnet. > + */ > + if (iaIsFirst && (ifp->if_flags & IFF_MULTICAST) != 0) { > + struct in_addr addr; > + > + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); > + in_addmulti(&addr, ifp); > + } > EVENTHANDLER_INVOKE(ifaddr_event, ifp); > + } > return (error); > > case SIOCDIFADDR: > @@ -503,8 +536,33 @@ > s = splnet(); > TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); > TAILQ_REMOVE(&in_ifaddrhead, ia, ia_link); > - if (ia->ia_addr.sin_family == AF_INET) > + if (ia->ia_addr.sin_family == AF_INET) { > + struct in_ifaddr *pia; > + > LIST_REMOVE(ia, ia_hash); > + /* > + * Only purge the 224.0.0.1 membership if the last IPv4 > + * unicast address configured on this ifnet is removed. > + * > + * XXX: This currently involves trawling through the > + * in_ifaddrhead list looking for a match, which is > + * inefficient, though this is only done when an interface > + * address goes away. This could be done much more elegantly. > + */ > + pia = NULL; > + IFP_TO_IA(ifp, pia); > + if (pia == NULL) { > + struct in_multi *inm; > + struct in_addr addr; > + > + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); > + IN_MULTI_LOCK(); > + IN_LOOKUP_MULTI(addr, ifp, inm); > + if (inm != NULL) > + in_delmulti(inm); > + IN_MULTI_UNLOCK(); > + } > + } > IFAFREE(&ia->ia_ifa); > splx(s); > > @@ -793,16 +851,6 @@ > if ((error = in_addprefix(ia, flags)) != 0) > return (error); > > - /* > - * If the interface supports multicast, join the "all hosts" > - * multicast group on that interface. > - */ > - if (ifp->if_flags & IFF_MULTICAST) { > - struct in_addr addr; > - > - addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); > - in_addmulti(&addr, ifp); > - } > return (error); > } > > @@ -1114,6 +1162,9 @@ > igmp_leavegroup(inm); > > ifma = inm->inm_ifma; > +#ifdef DIAGNOSTIC > + printf("%s: purging ifma %p\n", __func__, ifma); > +#endif > KASSERT(ifma->ifma_protospec == inm, > ("%s: ifma_protospec != inm", __func__)); > ifma->ifma_protospec = NULL; > @@ -1135,6 +1186,9 @@ > struct in_multi *inm; > struct in_multi *oinm; > > +#ifdef DIAGNOSTIC > + printf("%s: purging ifp %p\n", __func__, ifp); > +#endif > IFF_LOCKGIANT(ifp); > IN_MULTI_LOCK(); > LIST_FOREACH_SAFE(inm, &in_multihead, inm_link, oinm) { From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 15:00:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34F1216A407 for ; Wed, 28 Mar 2007 15:00:20 +0000 (UTC) (envelope-from dtarasov@bk.ru) Received: from droopy.homeftp.org (145.dial-up.2day.kz [80.241.32.145]) by mx1.freebsd.org (Postfix) with ESMTP id 726DE13C46C for ; Wed, 28 Mar 2007 15:00:17 +0000 (UTC) (envelope-from dtarasov@bk.ru) Received: from droopy.homeftp.org (localhost [127.0.0.1]) by droopy.homeftp.org (8.13.8/8.13.8) with ESMTP id l2QLc3pm088993 for ; Tue, 27 Mar 2007 03:38:11 +0600 (ALMT) (envelope-from dtarasov@bk.ru) Received: from localhost (localhost [[UNIX: localhost]]) by droopy.homeftp.org (8.13.8/8.13.8/Submit) id l2QLbsNp088992 for freebsd-current@freebsd.org; Tue, 27 Mar 2007 03:37:54 +0600 (ALMT) (envelope-from dtarasov@bk.ru) X-Authentication-Warning: droopy.homeftp.org: droopy set sender to dtarasov@bk.ru using -f From: =?koi8-r?b?5M3J1NLJyiD0wdLB08/X?= To: freebsd-current@freebsd.org Date: Tue, 27 Mar 2007 03:37:20 +0600 User-Agent: KMail/1.9.6 References: <20070326201715.GA49208@nibiru.b1tt3r.org> In-Reply-To: <20070326201715.GA49208@nibiru.b1tt3r.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1506425.S3Ff6QMHsS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703270337.53976.dtarasov@bk.ru> X-Mailman-Approved-At: Wed, 28 Mar 2007 15:53:52 +0000 Subject: Re: X wont start after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 15:00:20 -0000 --nextPart1506425.S3Ff6QMHsS Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 Tuesday 27 March 2007 02:17:15 Sam S= tein =CE=C1=D0=C9=D3=C1=CC(=C1): > I'm sure this is probably my fault.. but I figure I might as well post th= is > in case someone else had the same problem. I just upgraded, the same way I > always do (the instructions in /usr/src/Makefile) and now X hangs, I think > it has something to do with either the delete-old or delete-old-libs > target, and I'm wondering if I should recompile X, but in that case... its > probably not just X that's having problems... and just so you know, this = is > a -CURRENT system I am talking about... i'm just emailing from a -STABLE > system. Thanks. Recompile your nvidia driver from port ;) --nextPart1506425.S3Ff6QMHsS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGCD0QkAXmF0orEEQRApkwAKCJdSp/u4bceb+6IGeZ70nSUenr3gCcCZ6d OxTC+C7utInZ+BTY4LqDlJQ= =gfVH -----END PGP SIGNATURE----- --nextPart1506425.S3Ff6QMHsS-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 15:54:23 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0867F16A484 for ; Wed, 28 Mar 2007 15:54:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7996E13C46E for ; Wed, 28 Mar 2007 15:54:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2SFsK7r071806; Wed, 28 Mar 2007 11:54:21 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 28 Mar 2007 11:54:15 -0400 User-Agent: KMail/1.6.2 References: <20070328080830.GA20223@nagual.pp.ru> In-Reply-To: <20070328080830.GA20223@nagual.pp.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703281154.17132.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2951/Wed Mar 28 10:51:38 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Andrey Chernov Subject: Re: acpi: reservation ... failed (what is for?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 15:54:23 -0000 On Wednesday 28 March 2007 04:08 am, Andrey Chernov wrote: > I got "reservation ... failed" messages with recent acpi. What they > are for? Is the harmless? I notice no bad effects so far. See > underlined ones in the output below. Motherboard: ASUS P5AD2-E > Deluxe --- >8 --- SKIP --- >8 --- They are harmless. It was introduced by jhb's nexus changes, not by ACPI import. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 16:04:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3790016A407 for ; Wed, 28 Mar 2007 16:04:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E60EE13C458 for ; Wed, 28 Mar 2007 16:04:02 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HWacs-0002W7-2k for freebsd-current@freebsd.org; Wed, 28 Mar 2007 18:03:54 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 18:03:54 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 18:03:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 28 Mar 2007 18:03:35 +0200 Lines: 49 Message-ID: References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4440D018218B49FB64200F8" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 16:04:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4440D018218B49FB64200F8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ulrich Spoerlein wrote: > What kind of C program or script did you have in mind? My C-foo is very= =20 > weak ... If you have python installed, this is a simple way: ---- print "writing" f =3D file("a_file", "w") for x in xrange(1024): # write 1024 MB f.write(' '*1024*1024) f.close() raw_input("press enter to rewrite") print "rewriting" f =3D file("a_file", "r+") for x in xrange(1024): # write 1024 MB again f.write(' '*1024*1024) f.close() ---- save it to a file, run the file with python interpreter. If you don't=20 observe the weird read-before-write effect, then it's not a problem in=20 FreeBSD / NFS. --------------enigD4440D018218B49FB64200F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGCpHeldnAQVacBcgRAhMOAKCSJeFj5s91ez30c8a9to0AWOLiKgCgpv/6 qq8onPrO+FCXNTWY9zSJrpM= =FEUB -----END PGP SIGNATURE----- --------------enigD4440D018218B49FB64200F8-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 17:59:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67B3B16A412 for ; Wed, 28 Mar 2007 17:59:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id DABBC13C44C for ; Wed, 28 Mar 2007 17:59:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9906B47300; Wed, 28 Mar 2007 12:59:34 -0500 (EST) Date: Wed, 28 Mar 2007 18:59:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: <20070328185815.I1185@fledge.watson.org> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 17:59:39 -0000 On Wed, 28 Mar 2007, Ivan Voras wrote: > Ulrich Spoerlein wrote: > >> What kind of C program or script did you have in mind? My C-foo is very >> weak ... > > If you have python installed, this is a simple way: Also good is dd between the file system and /dev/null. Something worth remembering is that some tools (cp(1) in particular) use memory-mapped I/O, which may behave differently than raw I/O operations. Robert N M Watson Computer Laboratory University of Cambridge > > ---- > print "writing" > f = file("a_file", "w") > for x in xrange(1024): # write 1024 MB > f.write(' '*1024*1024) > f.close() > > raw_input("press enter to rewrite") > > print "rewriting" > f = file("a_file", "r+") > for x in xrange(1024): # write 1024 MB again > f.write(' '*1024*1024) > f.close() > ---- > > save it to a file, run the file with python interpreter. If you don't observe > the weird read-before-write effect, then it's not a problem in FreeBSD / NFS. > > From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 18:07:31 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B399B16A400 for ; Wed, 28 Mar 2007 18:07:31 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3CAF113C4B8 for ; Wed, 28 Mar 2007 18:07:30 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id B7FAA14A2D3; Wed, 28 Mar 2007 20:07:29 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id B5B6DD50051; Wed, 28 Mar 2007 20:07:29 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id A0AE5D50047; Wed, 28 Mar 2007 20:07:29 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rNuQaJ1XeUXDGXe2uQ/CMC86StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (89-172-36-1.adsl.net.t-com.hr [89.172.36.1]) by ls248.t-com.hr (Qmali) with ESMTP id 4F8715E00E2; Wed, 28 Mar 2007 20:07:29 +0200 (CEST) Message-ID: <460AAED3.9030903@fer.hr> Date: Wed, 28 Mar 2007 20:07:15 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robert Watson References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> <20070328185815.I1185@fledge.watson.org> In-Reply-To: <20070328185815.I1185@fledge.watson.org> X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDF4A7AAFFD11B6D97ABE44C" Cc: freebsd-current@FreeBSD.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 18:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDF4A7AAFFD11B6D97ABE44C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Watson wrote: > On Wed, 28 Mar 2007, Ivan Voras wrote: >=20 >> Ulrich Spoerlein wrote: >> >>> What kind of C program or script did you have in mind? My C-foo is >>> very weak ... >> >> If you have python installed, this is a simple way: >=20 > Also good is dd between the file system and /dev/null. Something worth= > remembering is that some tools (cp(1) in particular) use memory-mapped > I/O, which may behave differently than raw I/O operations. You mean /dev/zero and dd with notrunc option? Yes, I didn't know about notrunc until now :) --------------enigEDF4A7AAFFD11B6D97ABE44C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCq7hldnAQVacBcgRAtZgAJ9ygoywyrv2zMFL5Lrr8LurIq8WWgCfe5g2 sGZrDbfGAldwbkXLX/pf2UY= =HO8E -----END PGP SIGNATURE----- --------------enigEDF4A7AAFFD11B6D97ABE44C-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 18:13:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8302216A402; Wed, 28 Mar 2007 18:13:36 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 701B813C455; Wed, 28 Mar 2007 18:13:36 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 4C6D21A4D8E; Wed, 28 Mar 2007 11:13:36 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 908E0513EB; Wed, 28 Mar 2007 14:13:35 -0400 (EDT) Date: Wed, 28 Mar 2007 14:13:35 -0400 From: Kris Kennaway To: Dag-Erling Sm?rgrav Message-ID: <20070328181335.GA24652@xor.obsecurity.org> References: <20070323212254.54F7D73039@freebsd-current.sentex.ca> <20070323214145.GA3822@krapfengeist> <46044D6C.1070304@samsco.org> <86648lsmmu.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86648lsmmu.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.2i Cc: Matteo Riondato , i386@freebsd.org, current@freebsd.org, FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 18:13:36 -0000 On Wed, Mar 28, 2007 at 12:11:53PM +0200, Dag-Erling Sm?rgrav wrote: > Scott Long writes: > > The tinderboxes have stricter compile flags than the normal buildworld > > environment. The hope is that we'll be able to go to -O2 as the default > > optimization someday, which requires the stricter flags. I think what > > you're missing here is the -fstrict-aliasing flag. > > No, the tinderbox just uses -O2 (which implies -fno-strict-aliasing). No, it implies -fstrict-aliasing, which is why the tinderbox often breaks on code that was tested 100% correctly by the committer prior to running with your nonstandard flags ;) Kris From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 18:17:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19B6016A405; Wed, 28 Mar 2007 18:17:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id BCF2513C4BB; Wed, 28 Mar 2007 18:17:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2SIHdvB035973; Wed, 28 Mar 2007 13:17:43 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 28 Mar 2007 14:03:25 -0400 User-Agent: KMail/1.9.6 References: <20070328080830.GA20223@nagual.pp.ru> <200703281154.17132.jkim@FreeBSD.org> In-Reply-To: <200703281154.17132.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703281403.26493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Mar 2007 13:17:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2952/Wed Mar 28 11:26:48 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jung-uk Kim Subject: Re: acpi: reservation ... failed (what is for?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 18:17:50 -0000 On Wednesday 28 March 2007 11:54:15 am Jung-uk Kim wrote: > On Wednesday 28 March 2007 04:08 am, Andrey Chernov wrote: > > I got "reservation ... failed" messages with recent acpi. What they > > are for? Is the harmless? I notice no bad effects so far. See > > underlined ones in the output below. Motherboard: ASUS P5AD2-E > > Deluxe > --- >8 --- SKIP --- >8 --- > > They are harmless. It was introduced by jhb's nexus changes, not by > ACPI import. It's due to the ram0 driver in this case. It seems this BIOS wants to reserve system RAM as a system resource. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 19:21:01 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4B1416A403 for ; Wed, 28 Mar 2007 19:21:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 96D9113C4C8 for ; Wed, 28 Mar 2007 19:21:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 063924787B; Wed, 28 Mar 2007 14:20:59 -0500 (EST) Date: Wed, 28 Mar 2007 20:20:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: <460AAED3.9030903@fer.hr> Message-ID: <20070328202038.V1185@fledge.watson.org> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <7ad7ddd90703280611p5c0ca4e1y600315551391a813@mail.gmail.com> <20070328185815.I1185@fledge.watson.org> <460AAED3.9030903@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 19:21:02 -0000 On Wed, 28 Mar 2007, Ivan Voras wrote: > Robert Watson wrote: >> On Wed, 28 Mar 2007, Ivan Voras wrote: >> >>> Ulrich Spoerlein wrote: >>> >>>> What kind of C program or script did you have in mind? My C-foo is very >>>> weak ... >>> >>> If you have python installed, this is a simple way: >> >> Also good is dd between the file system and /dev/null. Something worth >> remembering is that some tools (cp(1) in particular) use memory-mapped I/O, >> which may behave differently than raw I/O operations. > > You mean /dev/zero and dd with notrunc option? Yes, I didn't know about > notrunc until now :) Yes, precisely what you said. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 00:11:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C83A16A402; Thu, 29 Mar 2007 00:11:53 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF4C13C45A; Thu, 29 Mar 2007 00:11:51 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2T0Bne3063747; Thu, 29 Mar 2007 04:11:49 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2T0BmQ7063746; Thu, 29 Mar 2007 04:11:48 +0400 (MSD) (envelope-from yar) Date: Thu, 29 Mar 2007 04:11:48 +0400 From: Yar Tikhiy To: Ulrich Spoerlein Message-ID: <20070329001148.GB59685@comp.chem.msu.su> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 00:11:53 -0000 Greetings, On Wed, Mar 28, 2007 at 11:38:44AM +0200, Ulrich Spoerlein wrote: > > I observe a strange effect, when using the following setup: Three > FreeBSD 6.2[1] machines on Gigabit Ethernet using em(4) interfaces. > > HostC is the NFS server, HostB has /net/share mounted from HostC. I > will use HostA and HostB to demonstrate the issue. Picture this: > > hostA # scp 500MB hostB:/net/share/ > > Iff the file "500MB" does not yet exist on the NFS share, I can see X > MB/s going out of HostA, X MB/s coming in on HostB, X MB/s going out > on hostB again and finally X MB/s coming in on HostC. > > If I run the scp again, I can see X MB/s going out from HostA, 2*X > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > happening is, that HostB issues one NFS READ call for every WRITE > call. The traffic flows like this: > > -----> -----> > A B C > <----- > > If I rm(1) the file on the NFS share, then the first scp(1) will not > show this behaviour. It is only when overwritting files, that this > happens. > > The real weirdness comes into play, when I simply cp(1) from HostB > itself like this: > > hostB # cp 500MB /net/share/ > > I can do this over and over again, and _never_ get any noteworthy > amount of NFS READ calls, only WRITE. The network traffic is also, as > you would expect. > > Then I tested using ssh(1) instead of scp(1), like this: > > hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" > > This works, too. Probably, because sh(1) is truncating the file? > > So, can someone please explain to me, what is happening and if/how it > can be avoided? My first guess is that scp and Samba use too small an I/O block size. Forget NFS and simply imagine that an application issues writes in 128-byte blocks while the disc block size is 512 bytes. If the OS is simple, like MS-DOS :-), then it will read the whole disc block each time and replace just 128 bytes in it on every application's write. If the OS is a bit more sophisticated, say FreeBSD ;-), it will use a buffer cache to alleviate the disc churn. However, it still will have to read the disc block once on the first small write to it because it has no way to know that the application is going to overwrite the whole of the disc block in a moment. So each disc block is read once and written once; but the OS still has to read it due to the poor choice of the write block size. Of course, my scenario implies that the file already contains data and the writes go over them, not beyond the end of file. Something similar (but maybe a bit more complex) should be going on in your case. -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 00:17:37 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 640CD16A400 for ; Thu, 29 Mar 2007 00:17:37 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFCF13C43E for ; Thu, 29 Mar 2007 00:17:37 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 18546 invoked from network); 28 Mar 2007 21:52:31 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 28 Mar 2007 21:52:31 -0000 Message-ID: <460AE39B.4070706@root.org> Date: Wed, 28 Mar 2007 14:52:27 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/mixed; boundary="------------070508040504000902030504" Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 00:17:37 -0000 This is a multi-part message in MIME format. --------------070508040504000902030504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To speed up pkg_add and other ftp command channel performance over slow links, change this: >>> PWD <<< 257 "/" >>> CWD pub <<< 250 Directory successfully changed. >>> CWD FreeBSD <<< 250 Directory successfully changed. >>> CWD ports <<< 250 Directory successfully changed. >>> CWD amd64 <<< 250 Directory successfully changed. >>> CWD packages-6-stable <<< 250 Directory successfully changed. >>> CWD Latest <<< 250 Directory successfully changed. >>> MODE S Into this: >>> PWD <<< 257 "/" >>> CWD pub/FreeBSD/ports/amd64/packages-6-stable/Latest <<< 250 Directory successfully changed. All ftp servers I've ever seen support a full path when changing down dirs. This might be a DOS ftp server thing however. In any case, if there is an error to the all-in-one CWD, the code reverts back to legacy behavior of multiple CWDs. -- Nate --------------070508040504000902030504 Content-Type: text/x-patch; name="ftp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ftp.diff" =================================================================== RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v --- ftp.c 22 Jul 2006 06:01:58 -0000 1.91.2.1 +++ ftp.c 28 Mar 2007 20:42:58 -0000 @@ -267,6 +267,7 @@ char pwd[PATH_MAX]; int e, i, len; + /* If no slashes in name, no need to change dirs. */ if ((end = strrchr(file, '/')) == NULL) return (0); if ((e = _ftp_cmd(conn, "PWD")) != FTP_WORKING_DIRECTORY || @@ -276,7 +277,8 @@ } for (;;) { len = strlen(pwd); - /* look for a common prefix */ + + /* Look for a common prefix between PWD and dir to fetch. */ for (i = 0; i <= len && i <= end - file; ++i) if (pwd[i] != file[i]) break; @@ -284,6 +286,7 @@ DEBUG(fprintf(stderr, "have: [%.*s|%s]\n", i, pwd, pwd + i)); DEBUG(fprintf(stderr, "want: [%.*s|%s]\n", i, file, file + i)); #endif + /* Keep going up a dir until we have a matching prefix. */ if (pwd[i] == '\0' && (file[i - 1] == '/' || file[i] == '/')) break; if ((e = _ftp_cmd(conn, "CDUP")) != FTP_FILE_ACTION_OK || @@ -293,6 +296,21 @@ return (-1); } } + + /* Skip leading slashes, even "////". */ + for (beg = file + i; beg < end && *beg == '/'; ++beg, ++i) + /* nothing */ ; + + /* If there is no trailing dir, we're already there. */ + if (beg >= end) + return (0); + + /* Change to the directory all in one chunk (e.g., foo/bar/baz). */ + e = _ftp_cmd(conn, "CWD %.*s", (int)(end - beg), beg); + if (e == FTP_FILE_ACTION_OK) + return (0); + + /* That didn't work so go back to legacy behavior (multiple CWDs). */ for (beg = file + i; beg < end; beg = file + i + 1) { while (*beg == '/') ++beg, ++i; --------------070508040504000902030504-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 22:36:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 206FC16A401 for ; Wed, 28 Mar 2007 22:36:38 +0000 (UTC) (envelope-from jasone@frebsd.org) Received: from canonware.com (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9240C13C4D9 for ; Wed, 28 Mar 2007 22:36:37 +0000 (UTC) (envelope-from jasone@frebsd.org) Received: from [10.0.0.2] (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) by canonware.com (Postfix) with ESMTP id 470E01298DC for ; Wed, 28 Mar 2007 15:08:59 -0700 (PDT) Message-ID: <460AE766.6050409@frebsd.org> Date: Wed, 28 Mar 2007 15:08:38 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> In-Reply-To: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Mar 2007 00:52:35 +0000 Subject: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 22:36:38 -0000 === Introduction === Those of you who watch the cvs commit logs may have noticed several rather significant changes to malloc over the past few weeks. I took a fresh look at malloc after letting the details fade over the past year, and saw some significant opportunities for improvement. I appreciate the FreeBSD community's tolerance of these changes, which were perhaps of questionable wisdom given that we are now in code slush. =) Since these changes obsolete several aspects of the paper I presented last year at BSDcan, it seems like a good idea to provide a public summary of these changes and their rationale. The changes focus on two main issues: 1) mapped page reduction during low memory usage phases of application execution, and 2) fragmentation reduction. === 1) Mapped page reduction === First, here is a bit of relevant background. jemalloc breaks memory into 1MB chunks that are aligned at multiples of the chunk size. This makes it possible to find metadata for small and large user objects in constant time. (For huge objects, it takes lg(n) time, where n is the number of huge allocations.) The point is that chunks are a fundamental aspect of what makes jemalloc tick. However, there is a downside to managing memory in chunks: unless we use madvise(2), every page of a chunk that is touched remains physically backed until the entire chunk can be unmapped. Thus, even a single in-use page can cause retention of up to 1MB of memory. This is a bit of a catch-22, since madvise(2) is too expensive to enable by default, but if we really need it, then we really should be using it for all applications, since paging is a system-wide issue. There is no simple way out of this conundrum, which is why I have been working to reduce the number of chunks that remain mapped for programs that typically operate at well below their peak memory usage. In order to reduce the number of mapped pages, we need some way to preferentially pack data into certain chunks, so that others can drain. There is a simple allocation policy that in practice had been demonstrated to work very well: prefer low addresses. jemalloc already did this where convenient (a lesson learned from phkmalloc), but the recent changes push this policy throughout the allocator, almost to the maximum extreme possible. Each arena manages a set of chunks that are carved into runs. These runs back small and large allocations. jemalloc now uses the lowest fit for run allocation. Equal-sized small allocations are grouped together into runs since it is possible to fit multiple small objects in a single run. This means that such a run may have very low utilization, so we try to keep runs as full as possible in order to reduce the total number of runs in use for any given size class. Previously, jemalloc used an overly complicated run promotion/demotion system that was intended to place several consecutive allocation requests in the same run, reduce the overhead of switching between runs, and try to keep the runs moderately full. However, experiments demonstrated that run switching overhead has at most a small impact on allocator performance, and furthermore that the promotion/demotion algorithms were not very effective at decreasing run switching anyway. That being the case, I experimented with increasingly expensive run switching policies. Finally, I tried always switching to the lowest run with any unused space, which was the ideal layout policy given my goals. This change had the intended effect of tending to let high chunks drain. Much to my surprise though, there was no significant impact on runtime. I put this last experiment off a long time, because my intuition was that it would be far too expensive to add so many red-black tree modifications. I think there are two contributing factors to why I was wrong: 1) the highest run switching rate I saw for any application was ~1% of the total allocation rate (though carefully crafted code could push that up to nearly 50%), and 2) cache locality improvements tend to help a bit. My initial expectation would be for such a layout policy to *decrease* locality, since we have the potential to spread consecutive allocations across a large number of independent runs. However, in the steady state of a long-running application, we have a hard time dealing with this problem anyway, and by packing objects as low as possible in memory, we actually tend to do better than if we were to use non-full runs in MRU order. Anyway, the reason I dedicate so much space to this issue is that it still makes me uneasy, but I have been unable to find any application for which the layout policy causes significant performance degradation. If you think you may have found such a case, you will be able to gain some insight by looking at the statistics output from setting MALLOC_OPTIONS=P. Look at the 'reruns' column (# of run switches) versus the 'requests' column in order to determine what percentage of requests suffer the overhead of run switching. If you see very high run switch rates for a particular application (say, >5%), please tell me so that I can run further experiments. === 2) Fragmentation reduction === We want to fit user objects in memory as tightly as possible. jemalloc was doing a substandard job in a couple of regards. First, it used a binary buddy scheme to manage runs within chunks, meaning that runs were constrained to be 2^n pages, for 0 < n < 20. This caused significant internal fragmentation for, say, 20kB objects. To improve the situation, I switched to using a straightforward extent-based system. This was initially intended only as a fix for the problem just described, but it turned out to also be useful for runs that back small allocations. Small allocation runs can now be more precisely sized such that the run header overhead is barely below some threshold. This allows the bitmaps that track which small objects are in use to be as short as possible while still keeping metadata overhead under control. Previously, all run headers for small object runs were the same size, regardless of how many bits were actually needed in the header bitmap to track the run's objects. This was clearly wasteful. My memory is fuzzy regarding the original rationale for fixed-size run headers, but I think it had to do with the complexity of calculating run header size, number of runs, and run size all at the same time. Indeed, this proved to be tricky, but well worth the effort. === Summary === With these changes in place, all of my experiments indicate substantial improvements in memory usage, as well as overall speed improvements. We still have several months before the 7.0 release to verify that I didn't miss anything important. Even so, I tested these changes more thoroughly than any previous changes (excepting Kris Kennaway's testing before jemalloc entered cvs), so I think the risk of major problems is reasonably low. Other than bug fixes, I do not intend to make any more changes before 7.0. I have developed some novel algorithms for essentially eliminating thread contention on SMP systems, but it is too late in the development cycle to introduce such changes (not to mention that I lack the hardware to evaluate the algorithms). Thanks again for your patience and support. Please let me know if I can be of help in diagnosing suspected malloc issues. Jason From owner-freebsd-current@FreeBSD.ORG Wed Mar 28 23:51:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C07316A401; Wed, 28 Mar 2007 23:51:37 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0F23813C459; Wed, 28 Mar 2007 23:51:37 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id DE1A2129096; Thu, 29 Mar 2007 09:51:30 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 208B38C26; Thu, 29 Mar 2007 09:51:34 +1000 (EST) Date: Thu, 29 Mar 2007 09:51:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ulrich Spoerlein In-Reply-To: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Message-ID: <20070329080917.B3626@besplex.bde.org> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 29 Mar 2007 00:52:48 +0000 Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 23:51:37 -0000 On Wed, 28 Mar 2007, Ulrich Spoerlein wrote: > hostA # scp 500MB hostB:/net/share/ > ... > If I run the scp again, I can see X MB/s going out from HostA, 2*X > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > happening is, that HostB issues one NFS READ call for every WRITE > call. The traffic flows like this: > > -----> -----> > A B C > <----- > > If I rm(1) the file on the NFS share, then the first scp(1) will not > show this behaviour. It is only when overwritting files, that this > happens. At least under FreeBSD-~5.2 with an old version of scp, this is caused by blocksize bugs in the kernel and/or scp, and an open mode bug or feature in scp. The blocksize used by scp is 4K. This is smaller than the nfs block size of 8K, so nfs has to read-ahead 1 8K block for each pair of 4K- blocks written so as to have non-garbage in the top half of each 8K- block after writing 4K to the bottom half. It only has to read-ahead if there is something there, but repeated scp's ensure this by not truncating the file on open (open mode (O_WRONLY | O_CREAT) without O_TRUNC according to truss(1)). > The real weirdness comes into play, when I simply cp(1) from HostB > itself like this: > > hostB # cp 500MB /net/share/ > > I can do this over and over again, and _never_ get any noteworthy > amount of NFS READ calls, only WRITE. The network traffic is also, as > you would expect. > > Then I tested using ssh(1) instead of scp(1), like this: > > hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" > > This works, too. Probably, because sh(1) is truncating the file? cp truncates the file on open (open mode (O_WRONLY | O_TRUNC_ without O_CREAT according to truss(1)). cp also uses a block size of 64K, so it wouldn't cause read-ahead even if it didn't truncate. There are many possible wrong block sizes: - on my server, the block size according to st_blksize is 16K (ffs default). - on my client, the block size according to st_blksize is 512 due to bugs in nfs. There is an open PR or two about this. In nfs2, the file system's block size on the server is passed to the client for each file and used for st_blksize but nothing else, but in nfs3, the block size that is put in st_blksize by the client is hard-coded to the arbitrary (usually bad) value NFS_FABLKSIZE = 512. The correct block size to put in st_blksize in both cases seems to be the least common multiple of the nfs buffer size and the server block size, since if the application's i/o size is smaller than the nfs buffer size then there will be excessive block size conversions in the nfs client, and if the i/o size is smaller than the server's block size then there will be excessive block size conversions in the server's file system. nfs's buffer size is the maximum of the read size, the write size and the page size. This is usually 8K, so it is mismatched with the usual ffs server block size of 16K. The inefficiencies from this are less noticeable than the inefficiencies from a mismatch with the nfs buffer size. - scp for some reason doesn't use the advertised best blocksize of st_blksize = 512. It uses 4K, which is almost as bad since it is smaller than the nfs buffer size. - cp doesn't use the advertised best block size. It uses mmap() for regular files smaller than 8M and a hard-coded block size of MAXBSIZE = 64K for large regular files and all non-regular files. - the above is in FreeBSD-~5.2 (and FreeBSD-[1-4]). st_blksize is much more bogus and broken in -current. In -current, the value in va_blocksize that is carefully initialized for regular files by ffs and not so carefully initialized by nfs or for non-regular files, is not actually used even for regular files. vn_stat() now uses the hard-coded (usually bad) value of PAGE_SIZE. Thus st_blksize is useless, and ignoring it and using a larger hard-coded value in cp is a feature -- MAXBSIZE is too large in many cases, but a too-large value normally only wastes a little space while a too-small value normally wastes a lot of time. MAXBSIZE is a good value for large files (e.g., large regular files and raw disks). OTOH, even PAGE_SIZE is a waste of space for slow devices like keyboards. - stdio is the main thing that is naive enough to believe that st_blksize is still useful. The block size of BUFSIZ = 1024 in stdio.h is another way to get a pessimal block size, but stdio itself mainly uses it for strings and for what it thinks are. It misclassifies all cdevs as ttys and thus uses a better block size than st_blksize = for cdevs that are actually ttys and a slightly worse block size than st_blksize = and a much worse block size than cp's MAXBSIZE for cdevs that are actually disks. Not truncating the file in scp might be a feature for avoiding clobbering the whole file when the copying fails early, but it doesn't seem to be documented. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 01:47:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B116216A405 for ; Thu, 29 Mar 2007 01:47:50 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5521C13C45D for ; Thu, 29 Mar 2007 01:47:42 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l2T1cq5d024991 for ; Thu, 29 Mar 2007 11:08:52 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.5) with ESMTP id for ; Thu, 29 Mar 2007 11:17:35 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 11:17:35 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.13.8/8.13.8) with ESMTP id l2T1lYfJ001654 for ; Thu, 29 Mar 2007 09:47:34 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.13.8/8.13.8/Submit) id l2T1lY2m001653 for freebsd-current@freebsd.org; Thu, 29 Mar 2007 09:47:34 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 29 Mar 2007 09:47:34 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070329014733.GA1556@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) X-OriginalArrivalTime: 29 Mar 2007 01:47:35.0602 (UTC) FILETIME=[3976F120:01C771A4] Content-Transfer-Encoding: 7bit Subject: [PANIC] 7.0-CURRENT #0: Wed Mar 14 ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 01:47:50 -0000 FreeBSD 7.0-CURRENT #0: Wed Mar 14 I have no clue what casued this. db> tr Tracing pid 11068 tid 100224 td 0xc55dfa20 kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at sbflush_internal sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ 0x2d sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int ernal+0x15 sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f 7d95,d2,0) at fdrop_locked+0xe4 closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 syscall(e8145d38) at syscall+0x155 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = 0xbfbfebf8 --- db> db> panic Startin panic: from debugger. M cpuid = 10:36 obel KDB: stack backtrace:/28 09:10:36, 0] prin db_trace_self_wrapper(c0afcbb0,0,c09f95a1,187,c09f8dd0,...) at db_trace_self_wra/etc/rc: WARNING :cups_cache_reload(85)set properly - see rc. Mar 28 09:10:36 ob pper+0x37901]: U mi_switch(1,0,c09f8dd0,10e,e8145848,...) at mi_switch+0x3235)sedvmcore.2.gz trap(e8145a74) at trap+0x2bc calltrap() at calltrap+0x6 --- trap 0x3, eip = 0xc074c76b, esp = 0xe8145ab4, ebp = 0xe8145abc --- kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at sbflush_interna l sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ 0x2d sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int ernal+0x15 sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f 7d95,d2,0) at fdrop_locked+0xe4 closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 syscall(e8145d38) at syscall+0x155 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = 0xbfbfebf8 --- db> b> call doadump Physical memory: 1003 MB Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 Dump complete = 0xf db> db> reset cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 #sudo kgdb kernel.debug vmcore.4 Unread portion of the kernel message buffer: panic: sbdrop cpuid = 1 KDB: enter: panic panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: panic: from debugger cpuid = 1 KDB: stack backtrace: Physical memory: 1003 MB Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 04:51:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C5EB16A400 for ; Thu, 29 Mar 2007 04:51:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6EB13C480 for ; Thu, 29 Mar 2007 04:51:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2T4pR8L000759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2007 21:51:27 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2T4pPug004591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2007 21:51:26 -0700 Message-ID: <460B4590.9010801@u.washington.edu> Date: Wed, 28 Mar 2007 21:50:24 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: "Wilkinson, Alex" References: <20070329014733.GA1556@obelix.dsto.defence.gov.au> In-Reply-To: <20070329014733.GA1556@obelix.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.28.214033 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-current@freebsd.org Subject: Re: [PANIC] 7.0-CURRENT #0: Wed Mar 14 ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 04:51:30 -0000 Wilkinson, Alex wrote: > FreeBSD 7.0-CURRENT #0: Wed Mar 14 > I have no clue what casued this. > > db> tr > Tracing pid 11068 tid 100224 td 0xc55dfa20 > kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 > panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 > sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at > sbflush_internal > sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ > 0x2d > sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int > ernal+0x15 > sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c > soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 > soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 > fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 > 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f > 7d95,d2,0) at fdrop_locked+0xe4 > closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 > kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 > syscall(e8145d38) at syscall+0x155 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = > 0xbfbfebf8 --- > db> > > db> panic > Startin > panic: from debugger. > M > cpuid = 10:36 obel > KDB: stack backtrace:/28 09:10:36, 0] prin > db_trace_self_wrapper(c0afcbb0,0,c09f95a1,187,c09f8dd0,...) at > db_trace_self_wra/etc/rc: WARNING > :cups_cache_reload(85)set properly - see rc. > Mar 28 09:10:36 ob > pper+0x37901]: U > mi_switch(1,0,c09f8dd0,10e,e8145848,...) at mi_switch+0x3235)sedvmcore.2.gz > trap(e8145a74) at trap+0x2bc > calltrap() at calltrap+0x6 > --- trap 0x3, eip = 0xc074c76b, esp = 0xe8145ab4, ebp = 0xe8145abc --- > kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 > panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 > sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at sbflush_interna > l > sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ > 0x2d > sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int > ernal+0x15 > sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c > soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 > soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 > fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 > 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f > 7d95,d2,0) at fdrop_locked+0xe4 > closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 > kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 > syscall(e8145d38) at syscall+0x155 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = > 0xbfbfebf8 --- > db> > > b> call doadump > Physical memory: 1003 MB > Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 > Dump complete > = 0xf > db> > > db> reset > cpu_reset: Restarting BSP > cpu_reset_proxy: Stopped CPU 1 > > #sudo kgdb kernel.debug vmcore.4 > Unread portion of the kernel message buffer: > panic: sbdrop > cpuid = 1 > KDB: enter: panic > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > Physical memory: 1003 MB > Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) > > -aW > > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. Try upgrading your sources and building your kernel (and maybe world?) again. The panic that you're experiencing is related to a sockets change made recently in -CURRENT (which fixed in a later version of tcp_input.c). -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 05:49:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D3816A401 for ; Thu, 29 Mar 2007 05:49:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED6B13C46E for ; Thu, 29 Mar 2007 05:49:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 5311D17383; Thu, 29 Mar 2007 05:49:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l2T5ndpR012206; Thu, 29 Mar 2007 05:49:40 GMT (envelope-from phk@critter.freebsd.dk) To: Jason Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Mar 2007 15:08:38 MST." <460AE766.6050409@frebsd.org> Date: Thu, 29 Mar 2007 05:49:39 +0000 Message-ID: <12205.1175147379@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 05:49:43 -0000 In message <460AE766.6050409@frebsd.org>, Jason Evans writes: >However, there is a downside to >managing memory in chunks: unless we use madvise(2), every page of a >chunk that is touched remains physically backed until the entire chunk >can be unmapped. Thus, even a single in-use page can cause retention of >up to 1MB of memory. This is a bit of a catch-22, since madvise(2) is >too expensive to enable by default, but if we really need it, then we >really should be using it for all applications, since paging is a >system-wide issue. The solution I have been advocating for years, is that the VM system tell us a green/yellow/red status of memory availability, and send a SIGVM to all processes when it gets worse. malloc() could hook SIGVM and act intelligently based on it, and really smart applications (a browser for instance) could hook SIGVM and ditch the cache. The actual flag color could be a free discovery, if we had a system-wide mapped page in all processes. That way, in all likelyhood, instead of starting to page out, the processes would free enough "wasted" space, that we can avoid paging out, at least for a fair bit longer. Thanks for the good work on jemalloc :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 06:54:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C02216A401 for ; Thu, 29 Mar 2007 06:54:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CD7CA13C44B for ; Thu, 29 Mar 2007 06:54:08 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe05.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 350986382 for freebsd-current@freebsd.org; Thu, 29 Mar 2007 08:54:07 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 08:53:47 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703290853.47940.hselasky@c2i.net> Subject: Panic in devfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 06:54:09 -0000 Hi, I initially forwarded this to PHK, but got no reply so I'm posting it here. I have caught a panic related to devfs while working on the new USB stack. Backtrace: uma_zalloc_arg() malloc() free_unr() devfs_free() destroy_devl() destroy_dev() ttyfree() ... ... The problem is that the lock, "devmtx", see "kern_conf.c" line 61, is locked when allocating memory. Maybe you have to call this "free_unr()" out of order? void devfs_free(struct cdev *cdev) { struct cdev_priv *cdp; cdp = cdev->si_priv; if (cdev->si_cred != NULL) crfree(cdev->si_cred); if (cdp->cdp_inode > 0) free_unr(devfs_inos, cdp->cdp_inode); XXX cannot call this here because this function allocates memory XXX if (cdp->cdp_maxdirent > 0) free(cdp->cdp_dirents, M_DEVFS2); free(cdp, M_CDEVP); } Can someone fix this and commit a patch to head, or should I make a PR out of this? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 07:45:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA7E916A401; Thu, 29 Mar 2007 07:45:32 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8546C13C46C; Thu, 29 Mar 2007 07:45:32 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 99A452100; Thu, 29 Mar 2007 09:45:28 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 081E3207E; Thu, 29 Mar 2007 09:45:28 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id F0F50A1073; Thu, 29 Mar 2007 09:45:27 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Kris Kennaway References: <20070323212254.54F7D73039@freebsd-current.sentex.ca> <20070323214145.GA3822@krapfengeist> <46044D6C.1070304@samsco.org> <86648lsmmu.fsf@dwp.des.no> <20070328181335.GA24652@xor.obsecurity.org> Date: Thu, 29 Mar 2007 09:45:27 +0200 In-Reply-To: <20070328181335.GA24652@xor.obsecurity.org> (Kris Kennaway's message of "Wed, 28 Mar 2007 14:13:35 -0400") Message-ID: <86wt10qyqw.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Matteo Riondato , i386@freebsd.org, current@freebsd.org, FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 07:45:32 -0000 Kris Kennaway writes: > On Wed, Mar 28, 2007 at 12:11:53PM +0200, Dag-Erling Sm?rgrav wrote: > > No, the tinderbox just uses -O2 (which implies -fno-strict-aliasing). > No, it implies -fstrict-aliasing, Sorry, typo on my part. I meant what you said. > which is why the tinderbox often breaks on code that was tested 100% > correctly by the committer prior to running with your nonstandard > flags ;) The code was obviously not tested 100% correctly, as the C standard forbids aliasing. Unfortunately, there are people in this project who systematically oppose any attempt to improve code quality, especially when it comes to their own code, and they have succeeded to the extent that not only is -O2 not the default, but the kernel build system is even instrumented to prevent its full use. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 07:48:31 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1760516A402 for ; Thu, 29 Mar 2007 07:48:31 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id CED4B13C4BA for ; Thu, 29 Mar 2007 07:48:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 89FCE2100; Thu, 29 Mar 2007 09:48:26 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7B210207E; Thu, 29 Mar 2007 09:48:26 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 3EFC6A1073; Thu, 29 Mar 2007 09:48:26 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Nate Lawson References: <460AE39B.4070706@root.org> Date: Thu, 29 Mar 2007 09:48:26 +0200 In-Reply-To: <460AE39B.4070706@root.org> (Nate Lawson's message of "Wed, 28 Mar 2007 14:52:27 -0700") Message-ID: <86odmcqylx.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 07:48:31 -0000 Nate Lawson writes: > To speed up pkg_add and other ftp command channel performance over slow > links, change this: > >>>> PWD > <<< 257 "/" >>>> CWD pub > <<< 250 Directory successfully changed. >>>> CWD FreeBSD > <<< 250 Directory successfully changed. >>>> CWD ports > <<< 250 Directory successfully changed. >>>> CWD amd64 > <<< 250 Directory successfully changed. >>>> CWD packages-6-stable > <<< 250 Directory successfully changed. >>>> CWD Latest > <<< 250 Directory successfully changed. >>>> MODE S > > Into this: > >>>> PWD > <<< 257 "/" >>>> CWD pub/FreeBSD/ports/amd64/packages-6-stable/Latest > <<< 250 Directory successfully changed. No. This is a violation of the FTP protocol. > All ftp servers I've ever seen support a full path when changing down > dirs. This might be a DOS ftp server thing however. In any case, if > there is an error to the all-in-one CWD, the code reverts back to legacy > behavior of multiple CWDs. When the all-in-one CWD fails, you're SOL. You have no idea what state the server is in, and you have to start over. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 08:19:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 055C216A404 for ; Thu, 29 Mar 2007 08:19:37 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9D113C459 for ; Thu, 29 Mar 2007 08:19:36 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so98709nfc for ; Thu, 29 Mar 2007 01:19:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EX0QeltM3FumVn335cZ9oUIz0Pahb4uigLFmM/UmgJe9YPICDVs1rLuu+L7PhvSb8GP7rE8wz4g1jIuKeDYNFVaBWZPsoTDJCNkOH/KMG2Y35K+Hkba3EPfG3x3fUZxe/4hwqK1w3EzLuAzZrHLrYT/VzNM3zxu8MN/DOR0keKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XD7m+S9QJkqL+sJghHZjVnl+6sXEmIe8TM9N8C4yQg6Jofs+dFfuM9bXogV2Z2rjske1DqNou+9ykcDCZ7MhxZ21hSYQ0rY4JyozONeeesDai2NkrDHqa961dZkx6FZI1dpn2nmMT3rXINtb5FlG1kOqsaHxoMvQQp5MP47m/eI= Received: by 10.82.104.18 with SMTP id b18mr918304buc.1175156374237; Thu, 29 Mar 2007 01:19:34 -0700 (PDT) Received: by 10.82.187.19 with HTTP; Thu, 29 Mar 2007 01:19:34 -0700 (PDT) Message-ID: <7ad7ddd90703290119i34b78d45s807659527d14478@mail.gmail.com> Date: Thu, 29 Mar 2007 10:19:34 +0200 From: "Ulrich Spoerlein" To: "Bruce Evans" In-Reply-To: <20070329080917.B3626@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <20070329080917.B3626@besplex.bde.org> Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 08:19:37 -0000 On 3/29/07, Bruce Evans wrote: > On Wed, 28 Mar 2007, Ulrich Spoerlein wrote: > > > hostA # scp 500MB hostB:/net/share/ > > ... > > If I run the scp again, I can see X MB/s going out from HostA, 2*X > > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > > happening is, that HostB issues one NFS READ call for every WRITE > > call. The traffic flows like this: > > > > -----> -----> > > A B C > > <----- > > At least under FreeBSD-~5.2 with an old version of scp, this is caused > by blocksize bugs in the kernel and/or scp, and an open mode bug or > feature in scp. The blocksize used by scp is 4K. This is smaller > than the nfs block size of 8K, so nfs has to read-ahead 1 8K block for > each pair of 4K- blocks written so as to have non-garbage in the top > half of each 8K- block after writing 4K to the bottom half. It only > has to read-ahead if there is something there, but repeated scp's > ensure this by not truncating the file on open (open mode (O_WRONLY | > O_CREAT) without O_TRUNC according to truss(1)). > > [snip - all you ever wanted to know about block sizes] Thanks for the in-depth answer, Bruce. Greatly appreciated. I can now tweak all kinds of block sizes to make the final combination of Windows 2003, Samba and NFS work well. I hope that samba can be adjusted in the right places for this task. I'll post a summary, once I have it working. It seems that other people don't have these problems (as they are not running SMB+NFS) Uli From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 09:38:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B152816A405 for ; Thu, 29 Mar 2007 09:38:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 664A713C465 for ; Thu, 29 Mar 2007 09:38:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0E7BE475EF; Thu, 29 Mar 2007 04:38:09 -0500 (EST) Date: Thu, 29 Mar 2007 10:38:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Wilkinson, Alex" In-Reply-To: <20070329014733.GA1556@obelix.dsto.defence.gov.au> Message-ID: <20070329103632.N51007@fledge.watson.org> References: <20070329014733.GA1556@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: [PANIC] 7.0-CURRENT #0: Wed Mar 14 ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 09:38:09 -0000 On Thu, 29 Mar 2007, Wilkinson, Alex wrote: > FreeBSD 7.0-CURRENT #0: Wed Mar 14 > I have no clue what casued this. > > db> tr > Tracing pid 11068 tid 100224 td 0xc55dfa20 > kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 > panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 > sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at > sbflush_internal > sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ > 0x2d > sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int > ernal+0x15 > sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c > soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 > soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 > fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 > 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f > 7d95,d2,0) at fdrop_locked+0xe4 > closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 > kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 > syscall(e8145d38) at syscall+0x155 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = > 0xbfbfebf8 --- > db> There have a been a few such issues floating around, in which races between protocol teardown of a socket and socket layer teardown result in a panic during simultaneous access to the socket buffer. Udate to at least 20070323, as glebius committed a fix for a class of these problems as uipc_socket.c:1.295 on 20070322. If it recurs, please let us know. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > db> panic > Startin > panic: from debugger. > M > cpuid = 10:36 obel > KDB: stack backtrace:/28 09:10:36, 0] prin > db_trace_self_wrapper(c0afcbb0,0,c09f95a1,187,c09f8dd0,...) at > db_trace_self_wra/etc/rc: WARNING > :cups_cache_reload(85)set properly - see rc. > Mar 28 09:10:36 ob > pper+0x37901]: U > mi_switch(1,0,c09f8dd0,10e,e8145848,...) at mi_switch+0x3235)sedvmcore.2.gz > trap(e8145a74) at trap+0x2bc > calltrap() at calltrap+0x6 > --- trap 0x3, eip = 0xc074c76b, esp = 0xe8145ab4, ebp = 0xe8145abc --- > kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 > panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 > sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at sbflush_interna > l > sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+ > 0x2d > sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int > ernal+0x15 > sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c > soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 > soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37 > fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 > 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f > 7d95,d2,0) at fdrop_locked+0xe4 > closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 > kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 > syscall(e8145d38) at syscall+0x155 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp = > 0xbfbfebf8 --- > db> > > b> call doadump > Physical memory: 1003 MB > Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 > Dump complete > = 0xf > db> > > db> reset > cpu_reset: Restarting BSP > cpu_reset_proxy: Stopped CPU 1 > > #sudo kgdb kernel.debug vmcore.4 > Unread portion of the kernel message buffer: > panic: sbdrop > cpuid = 1 > KDB: enter: panic > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > Physical memory: 1003 MB > Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) > > -aW > > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 14:28:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7709C16A403; Thu, 29 Mar 2007 14:28:43 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 26F3013C457; Thu, 29 Mar 2007 14:28:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l2TESTTp059326; Thu, 29 Mar 2007 08:28:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <460BCD09.9030409@samsco.org> Date: Thu, 29 Mar 2007 08:28:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20070323212254.54F7D73039@freebsd-current.sentex.ca> <20070323214145.GA3822@krapfengeist> <46044D6C.1070304@samsco.org> <86648lsmmu.fsf@dwp.des.no> <20070328181335.GA24652@xor.obsecurity.org> <86wt10qyqw.fsf@dwp.des.no> In-Reply-To: <86wt10qyqw.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 29 Mar 2007 07:28:36 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Tinderbox , Matteo Riondato , i386@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 14:28:43 -0000 Dag-Erling Sm�rgrav wrote: > Kris Kennaway writes: >> On Wed, Mar 28, 2007 at 12:11:53PM +0200, Dag-Erling Sm?rgrav wrote: >>> No, the tinderbox just uses -O2 (which implies -fno-strict-aliasing). >> No, it implies -fstrict-aliasing, > > Sorry, typo on my part. I meant what you said. > >> which is why the tinderbox often breaks on code that was tested 100% >> correctly by the committer prior to running with your nonstandard >> flags ;) > > The code was obviously not tested 100% correctly, as the C standard > forbids aliasing. Unfortunately, there are people in this project who > systematically oppose any attempt to improve code quality, especially > when it comes to their own code, and they have succeeded to the extent > that not only is -O2 not the default, but the kernel build system is > even instrumented to prevent its full use. > > DES I think you need to chill out quite a bit and stop assuming that people are incompetent and out to get you. Scott From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 14:51:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C17416A402; Thu, 29 Mar 2007 14:51:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D93E013C468; Thu, 29 Mar 2007 14:51:29 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 7ACC9208E; Thu, 29 Mar 2007 16:51:25 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 57FAC208D; Thu, 29 Mar 2007 16:51:25 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 56A48A1073; Thu, 29 Mar 2007 16:51:25 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Scott Long References: <20070323212254.54F7D73039@freebsd-current.sentex.ca> <20070323214145.GA3822@krapfengeist> <46044D6C.1070304@samsco.org> <86648lsmmu.fsf@dwp.des.no> <20070328181335.GA24652@xor.obsecurity.org> <86wt10qyqw.fsf@dwp.des.no> <460BCD09.9030409@samsco.org> Date: Thu, 29 Mar 2007 16:51:25 +0200 In-Reply-To: <460BCD09.9030409@samsco.org> (Scott Long's message of "Thu, 29 Mar 2007 08:28:25 -0600") Message-ID: <86tzw42jde.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Tinderbox , Matteo Riondato , i386@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 14:51:30 -0000 Scott Long writes: > I think you need to chill out quite a bit and stop assuming that people > are incompetent and out to get you. I don't usually assume that people are incompetent and out to get me, but like they say - once is an accident, twice is a coincidence, three times is enemy action. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:31:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DFFD16A407; Thu, 29 Mar 2007 17:31:50 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id B7F3513C45A; Thu, 29 Mar 2007 17:31:49 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l2TH50Lr014037; Thu, 29 Mar 2007 19:05:00 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 19:04:59 +0200 User-Agent: KMail/1.9.6 References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> In-Reply-To: <86odmcqylx.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703291905.00192.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:31:50 -0000 On donderdag 29 maart 2007, Dag-Erling Sm=F8rgrav wrote: > Nate Lawson writes: > > To speed up pkg_add and other ftp command channel performance over slow > > > > links, change this: > >>>> PWD > > > > <<< 257 "/" > > > >>>> CWD pub > > > > <<< 250 Directory successfully changed. > > > >>>> CWD FreeBSD > > > > <<< 250 Directory successfully changed. > > > >>>> CWD ports > > > > <<< 250 Directory successfully changed. > > > >>>> CWD amd64 > > > > <<< 250 Directory successfully changed. > > > >>>> CWD packages-6-stable > > > > <<< 250 Directory successfully changed. > > > >>>> CWD Latest > > > > <<< 250 Directory successfully changed. > > > >>>> MODE S > > > > Into this: > >>>> PWD > > > > <<< 257 "/" > > > >>>> CWD pub/FreeBSD/ports/amd64/packages-6-stable/Latest Why not put the / before the path? That way you don't need to 'PWD' first. > > > > <<< 250 Directory successfully changed. > > No. This is a violation of the FTP protocol. I'm reading rfc 959 right now, and it include examples of CWD with full=20 pathname (multiple directories). Actually the rfc is kinda vague about this. > > > All ftp servers I've ever seen support a full path when changing down > > dirs. This might be a DOS ftp server thing however. In any case, if > > there is an error to the all-in-one CWD, the code reverts back to legacy > > behavior of multiple CWDs. > > When the all-in-one CWD fails, you're SOL. You have no idea what > state the server is in, and you have to start over. Agreed. > > DES Regards, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:31:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DFFD16A407; Thu, 29 Mar 2007 17:31:50 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id B7F3513C45A; Thu, 29 Mar 2007 17:31:49 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l2TH50Lr014037; Thu, 29 Mar 2007 19:05:00 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 19:04:59 +0200 User-Agent: KMail/1.9.6 References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> In-Reply-To: <86odmcqylx.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703291905.00192.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:31:50 -0000 On donderdag 29 maart 2007, Dag-Erling Sm=F8rgrav wrote: > Nate Lawson writes: > > To speed up pkg_add and other ftp command channel performance over slow > > > > links, change this: > >>>> PWD > > > > <<< 257 "/" > > > >>>> CWD pub > > > > <<< 250 Directory successfully changed. > > > >>>> CWD FreeBSD > > > > <<< 250 Directory successfully changed. > > > >>>> CWD ports > > > > <<< 250 Directory successfully changed. > > > >>>> CWD amd64 > > > > <<< 250 Directory successfully changed. > > > >>>> CWD packages-6-stable > > > > <<< 250 Directory successfully changed. > > > >>>> CWD Latest > > > > <<< 250 Directory successfully changed. > > > >>>> MODE S > > > > Into this: > >>>> PWD > > > > <<< 257 "/" > > > >>>> CWD pub/FreeBSD/ports/amd64/packages-6-stable/Latest Why not put the / before the path? That way you don't need to 'PWD' first. > > > > <<< 250 Directory successfully changed. > > No. This is a violation of the FTP protocol. I'm reading rfc 959 right now, and it include examples of CWD with full=20 pathname (multiple directories). Actually the rfc is kinda vague about this. > > > All ftp servers I've ever seen support a full path when changing down > > dirs. This might be a DOS ftp server thing however. In any case, if > > there is an error to the all-in-one CWD, the code reverts back to legacy > > behavior of multiple CWDs. > > When the all-in-one CWD fails, you're SOL. You have no idea what > state the server is in, and you have to start over. Agreed. > > DES Regards, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:52:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F33A616A405 for ; Thu, 29 Mar 2007 17:52:33 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 81BDC13C4D1 for ; Thu, 29 Mar 2007 17:52:33 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HWynL-0006kq-CK for freebsd-current@freebsd.org; Thu, 29 Mar 2007 19:52:19 +0200 Received: from 83-131-175-241.adsl.net.t-com.hr ([83.131.175.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Mar 2007 19:52:19 +0200 Received: from ivoras by 83-131-175-241.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Mar 2007 19:52:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 29 Mar 2007 19:51:56 +0200 Lines: 55 Message-ID: References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA1A6D9267EEBBABC55DEB589" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-175-241.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <460AE766.6050409@frebsd.org> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:52:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA1A6D9267EEBBABC55DEB589 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jason Evans wrote: > I have developed some novel algorithms for essentially eliminating > thread contention on SMP systems, but it is too late in the development= > cycle to introduce such changes (not to mention that I lack the hardwar= e > to evaluate the algorithms). Thanks again for your patience and > support. Please let me know if I can be of help in diagnosing suspecte= d > malloc issues. First, thanks :) Second, as a user, I'd really like if you could manage to implement those ideas before 7.0, and here's why: - The standard for new servers here is 4 cores (in various socket arrangements), and we're not at all high-tech. This is likely to go up. - If you include hyperthreading, even all *desktops* are SMPs! In short, even including desktops, I haven't installed a UP kernel in about a year.= - It's too long to wait for 8.0 for something as important as this. As far as I can see, 7.0 will be one of the "break as many things as you need" releases (in the "good" sense, of course), so why not go for it. Judging from past releases, "even" releases (4.x, 6.x) have been the ones people trusted the most, so if you do get a glitch in 7.0 it won't be as bad :) (of course, you can fix it in 7.1 :) ) Maybe you could borrow the 8CPU machine used for MySQL / filedesc tuning jeffr and others have been using (of course, once they've finished...)? --------------enigA1A6D9267EEBBABC55DEB589 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGC/y8ldnAQVacBcgRAvxiAJ49H3y7Vnlj7ysYJXAsnbrkbgiRdgCfdhhh h0XhPbsT6Mpg7RPVYUH+Xgg= =40K8 -----END PGP SIGNATURE----- --------------enigA1A6D9267EEBBABC55DEB589-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:53:36 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09A4016A403 for ; Thu, 29 Mar 2007 17:53:36 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 915DB13C4D0 for ; Thu, 29 Mar 2007 17:53:35 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id E2E88690730; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id AF26F690812; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-29-248.net.novis.pt [87.196.29.248]) by core.fnop.net (Postfix) with ESMTP id 33D3A690730; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) Message-ID: <460BFD1D.9000402@fnop.net> Date: Thu, 29 Mar 2007 18:53:33 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Nate Lawson , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <460AE39B.4070706@root.org> In-Reply-To: <460AE39B.4070706@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@FreeBSD.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:53:36 -0000 Nate Lawson wrote: > To speed up pkg_add and other ftp command channel performance over slow > links, change this: > [...] > All ftp servers I've ever seen support a full path when changing down > dirs. This might be a DOS ftp server thing however. In any case, if > there is an error to the all-in-one CWD, the code reverts back to legacy > behavior of multiple CWDs. Yes, I think this behavior is acceptable. If the pathname fails it only adds one more CWD, but reduces the time on the successful cases (which are many if you consider the Ports collection). Dag-Erling Sm�rgrav wrote: > No. This is a violation of the FTP protocol. > [...] > When the all-in-one CWD fails, you're SOL. You have no idea what > state the server is in, and you have to start over. About the possible violation of the RFC, I quote: pathname Pathname is defined to be the character string which must be input to a file system by a user in order to identify a file. Pathname normally contains device and/or directory names, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ file name specification. FTP does not yet specify a standard ^^^^^^^^^^^^^^^^^^^^^^^ pathname convention. Each user must follow the file naming conventions of the file systems involved in the transfer. CHANGE WORKING DIRECTORY (CWD) This command allows the user to work with a different directory or dataset for file storage or retrieval without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent ^^^^^^^^ file group designator. I'm not sure why you consider this a violation of the protocol. Also, considering the reply codes to the CWD command, only 421 seems to change the server state. Have you seen servers that change their state by issuing giving invalid arguments to the CWD command ? Regards, -- Rui Paulo | PGP: F0E4 C7C7 1653 79B7 78DC DD73 64FA B2C6 CF45 1F84 From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:11:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06D6216A404 for ; Thu, 29 Mar 2007 18:11:37 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id C771613C4AD for ; Thu, 29 Mar 2007 18:11:36 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 88807 invoked from network); 29 Mar 2007 18:11:37 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 29 Mar 2007 18:11:37 -0000 Message-ID: <460C0152.4070009@root.org> Date: Thu, 29 Mar 2007 11:11:30 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Thomas David Rivers References: <200703291805.l2TI5Vt63613@lakes.dignus.com> In-Reply-To: <200703291805.l2TI5Vt63613@lakes.dignus.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rpaulo@fnop.net, des@des.no, current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:11:37 -0000 Thomas David Rivers wrote: > The mainframe (z/OS) FTP server does not allow multiple > "directories" in CWD command. > > This is due to the mapping of "directories" to flat file names > in the z/OS dataset-name convention. > > So - while I can say: > > ftp> cd RIVERS > ftp> cd TEST > ftp> cd OBJ > > which results in the current working "directory" being > RIVERS.TEST.OBJ. I cannot say > > ftp> cd RIVERS/TEST/OBJ > > But, I _could_ say: > > ftp> cd RIVERS.TEST.OBJ > > > So - on "different" systems where the idea of "directory" has to > be mapped onto a foreign filesystem, you can get interesting > results. > > This may or may-not matter... I was just citing an example. The important thing is not whether that fails. I'm fine with it failing, as long as it 1) returns an error code and 2) doesn't change the current directory. An ftpd that 1) returned success or 2) changed to some random directory while returning an error must be buggy. Could you check your server? It should return some error code and PWD should not change. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:14:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7A2E16A402; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2A38513C44B; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2TIEc4q046603; Thu, 29 Mar 2007 13:14:38 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 14:14:14 -0400 User-Agent: KMail/1.9.6 References: <460AE39B.4070706@root.org> <460BFD1D.9000402@fnop.net> In-Reply-To: <460BFD1D.9000402@fnop.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703291414.15452.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 29 Mar 2007 13:14:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2961/Thu Mar 29 09:06:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Rui Paulo , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:14:47 -0000 On Thursday 29 March 2007 01:53:33 pm Rui Paulo wrote: > Nate Lawson wrote: > > To speed up pkg_add and other ftp command channel performance over slow > > links, change this: > > [...] > > All ftp servers I've ever seen support a full path when changing down > > dirs. This might be a DOS ftp server thing however. In any case, if > > there is an error to the all-in-one CWD, the code reverts back to legacy > > behavior of multiple CWDs. >=20 > Yes, I think this behavior is acceptable. If the pathname fails it only=20 > adds one more CWD, but reduces the time on the successful cases (which=20 > are many if you consider the Ports collection). >=20 > Dag-Erling Sm=F8rgrav wrote: > > No. This is a violation of the FTP protocol. > > [...] > > When the all-in-one CWD fails, you're SOL. You have no idea what > > state the server is in, and you have to start over. >=20 > About the possible violation of the RFC, I quote: >=20 > pathname >=20 > Pathname is defined to be the character string which must be > input to a file system by a user in order to identify a file. > Pathname normally contains device and/or directory names, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > file name specification. FTP does not yet specify a standard > ^^^^^^^^^^^^^^^^^^^^^^^ > pathname convention. Each user must follow the file naming > conventions of the file systems involved in the transfer. >=20 >=20 > CHANGE WORKING DIRECTORY (CWD) >=20 > This command allows the user to work with a different > directory or dataset for file storage or retrieval without > altering his login or accounting information. Transfer > parameters are similarly unchanged. The argument is a > pathname specifying a directory or other system dependent > ^^^^^^^^ > file group designator. >=20 >=20 > I'm not sure why you consider this a violation of the protocol. > Also, considering the reply codes to the CWD command, only 421 seems to=20 > change the server state. >=20 > Have you seen servers that change their state by issuing giving invalid=20 > arguments to the CWD command ? http://www.freebsd.org/cgi/query-pr.cgi?pr=3D83278 In this case IIRC, the problem was the leading / as the path fetched was=20 supposed to be relative to the user's home directory, but instead fetch sen= t=20 an absolute path and failed. See also http://www.ietf.org/rfc/rfc1738.txt which is the RFC for URLs and= =20 explains exactly how the for ftp URLs should be interpreted: 3.2.2. FTP url-path The url-path of a FTP URL has the following syntax: //...//;type=3D Where through and are (possibly encoded) strings and is one of the characters "a", "i", or "d". The part ";type=3D" may be omitted. The and parts may be empty. The whole url-path may be omitted, including the "/" delimiting it from the prefix containing user, password, host, and port. The url-path is interpreted as a series of FTP commands as follows: Each of the elements is to be supplied, sequentially, as the argument to a CWD (change working directory) command. If the typecode is "d", perform a NLST (name list) command with as the argument, and interpret the results as a file directory listing. Otherwise, perform a TYPE command with as the argument, and then access the file whose name is (for example, using the RETR command.) Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, , would "CWD " with a null argument, then "CWD etc", and then "RETR motd". =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:14:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7A2E16A402; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2A38513C44B; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2TIEc4q046603; Thu, 29 Mar 2007 13:14:38 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 14:14:14 -0400 User-Agent: KMail/1.9.6 References: <460AE39B.4070706@root.org> <460BFD1D.9000402@fnop.net> In-Reply-To: <460BFD1D.9000402@fnop.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703291414.15452.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 29 Mar 2007 13:14:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2961/Thu Mar 29 09:06:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Rui Paulo , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:14:47 -0000 On Thursday 29 March 2007 01:53:33 pm Rui Paulo wrote: > Nate Lawson wrote: > > To speed up pkg_add and other ftp command channel performance over slow > > links, change this: > > [...] > > All ftp servers I've ever seen support a full path when changing down > > dirs. This might be a DOS ftp server thing however. In any case, if > > there is an error to the all-in-one CWD, the code reverts back to legacy > > behavior of multiple CWDs. >=20 > Yes, I think this behavior is acceptable. If the pathname fails it only=20 > adds one more CWD, but reduces the time on the successful cases (which=20 > are many if you consider the Ports collection). >=20 > Dag-Erling Sm=F8rgrav wrote: > > No. This is a violation of the FTP protocol. > > [...] > > When the all-in-one CWD fails, you're SOL. You have no idea what > > state the server is in, and you have to start over. >=20 > About the possible violation of the RFC, I quote: >=20 > pathname >=20 > Pathname is defined to be the character string which must be > input to a file system by a user in order to identify a file. > Pathname normally contains device and/or directory names, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > file name specification. FTP does not yet specify a standard > ^^^^^^^^^^^^^^^^^^^^^^^ > pathname convention. Each user must follow the file naming > conventions of the file systems involved in the transfer. >=20 >=20 > CHANGE WORKING DIRECTORY (CWD) >=20 > This command allows the user to work with a different > directory or dataset for file storage or retrieval without > altering his login or accounting information. Transfer > parameters are similarly unchanged. The argument is a > pathname specifying a directory or other system dependent > ^^^^^^^^ > file group designator. >=20 >=20 > I'm not sure why you consider this a violation of the protocol. > Also, considering the reply codes to the CWD command, only 421 seems to=20 > change the server state. >=20 > Have you seen servers that change their state by issuing giving invalid=20 > arguments to the CWD command ? http://www.freebsd.org/cgi/query-pr.cgi?pr=3D83278 In this case IIRC, the problem was the leading / as the path fetched was=20 supposed to be relative to the user's home directory, but instead fetch sen= t=20 an absolute path and failed. See also http://www.ietf.org/rfc/rfc1738.txt which is the RFC for URLs and= =20 explains exactly how the for ftp URLs should be interpreted: 3.2.2. FTP url-path The url-path of a FTP URL has the following syntax: //...//;type=3D Where through and are (possibly encoded) strings and is one of the characters "a", "i", or "d". The part ";type=3D" may be omitted. The and parts may be empty. The whole url-path may be omitted, including the "/" delimiting it from the prefix containing user, password, host, and port. The url-path is interpreted as a series of FTP commands as follows: Each of the elements is to be supplied, sequentially, as the argument to a CWD (change working directory) command. If the typecode is "d", perform a NLST (name list) command with as the argument, and interpret the results as a file directory listing. Otherwise, perform a TYPE command with as the argument, and then access the file whose name is (for example, using the RETR command.) Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, , would "CWD " with a null argument, then "CWD etc", and then "RETR motd". =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:18:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E25516A402 for ; Thu, 29 Mar 2007 18:18:23 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (mail.dignus.com [209.42.196.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2591E13C4B7 for ; Thu, 29 Mar 2007 18:18:23 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.1.0.3]) by dignus.com (8.13.1/8.13.1) with ESMTP id l2TIH8Ot086813; Thu, 29 Mar 2007 14:17:08 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id l2TIIfV63662; Thu, 29 Mar 2007 14:18:41 -0400 (EDT) (envelope-from rivers) Date: Thu, 29 Mar 2007 14:18:41 -0400 (EDT) From: Thomas David Rivers Message-Id: <200703291818.l2TIIfV63662@lakes.dignus.com> To: nate@root.org, rivers@dignus.com In-Reply-To: <460C0152.4070009@root.org> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on office.dignus.com Cc: rpaulo@fnop.net, des@des.no, current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:18:23 -0000 > > The important thing is not whether that fails. I'm fine with it > failing, as long as it 1) returns an error code and 2) doesn't change > the current directory. > > An ftpd that 1) returned success or 2) changed to some random directory > while returning an error must be buggy. Could you check your server? > It should return some error code and PWD should not change. > > -- > Nate > Hi Nate, Here's what it did: Connected to zos.dignus.com. 220-FTPD1 IBM FTP CS V1R5 at P390.dignus.com, 18:17:50 on 2007-03-29. 220 Connection will close if idle for more than 5 minutes. Name (flexes:rivers): rivers 331 Send password please. Password: 230 RIVERS is logged on. Working directory is "RIVERS.". Remote system type is MVS. ftp> pwd Remote directory: 'RIVERS.' ftp> cd test/obj 501 A qualifier in "test/obj" contains an invalid character ftp> pwd Remote directory: 'RIVERS.' ftp> quit - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:30:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B75A116A403 for ; Thu, 29 Mar 2007 18:30:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFFE13C45B for ; Thu, 29 Mar 2007 18:30:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 923452081; Thu, 29 Mar 2007 20:30:27 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7FDCB207E; Thu, 29 Mar 2007 20:30:27 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id D5247A1075; Thu, 29 Mar 2007 20:30:26 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Pieter de Goeje References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> Date: Thu, 29 Mar 2007 20:30:26 +0200 In-Reply-To: <200703291905.00192.pieter@degoeje.nl> (Pieter de Goeje's message of "Thu, 29 Mar 2007 19:04:59 +0200") Message-ID: <86k5wzq4vx.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:30:34 -0000 Pieter de Goeje writes: > Dag-Erling Sm=F8rgrav writes: > > No. This is a violation of the FTP protocol. > I'm reading rfc 959 right now, and it include examples of CWD with > full pathname (multiple directories). Actually the rfc is kinda > vague about this. RFC959 does not require or guarantee that the path separator is /, nor that "CD ../foo" does what you expect. There are also issues when the initial CWD is not / (the document part in an FTP URL is relative to the initial CWD, not absolute) Libfetch used to do what Nate suggests, and it was changed to the current behaviour because we encountered servers in the field with which it didn't work. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:34:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 099F216A400 for ; Thu, 29 Mar 2007 18:34:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B488413C448 for ; Thu, 29 Mar 2007 18:34:05 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 846382085; Thu, 29 Mar 2007 20:33:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 0BAB2207E; Thu, 29 Mar 2007 20:33:59 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E9519A1075; Thu, 29 Mar 2007 20:33:58 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Pieter de Goeje References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> Date: Thu, 29 Mar 2007 20:33:58 +0200 In-Reply-To: <86k5wzq4vx.fsf@dwp.des.no> (Dag-Erling =?iso-8859-1?Q?Sm=F8r?= =?iso-8859-1?Q?grav's?= message of "Thu, 29 Mar 2007 20:30:26 +0200") Message-ID: <86fy7nq4q1.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:34:06 -0000 Dag-Erling Sm=F8rgrav writes: > Pieter de Goeje writes: > > Dag-Erling Sm=F8rgrav writes: > > > No. This is a violation of the FTP protocol. > > I'm reading rfc 959 right now, and it include examples of CWD with > > full pathname (multiple directories). Actually the rfc is kinda > > vague about this. > RFC959 does not require or guarantee that the path separator is /, nor > that "CD ../foo" does what you expect. There are also issues when the > initial CWD is not / (the document part in an FTP URL is relative to > the initial CWD, not absolute) I guess I should amend "this is a violation of the FTP protocol" to "this relies on assumptions which the FTP RFC does not allow us to make, and is a violation of RFC1738" DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:36:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C31C16A403 for ; Thu, 29 Mar 2007 18:36:18 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (mail.dignus.com [209.42.196.2]) by mx1.freebsd.org (Postfix) with ESMTP id D87FD13C4BB for ; Thu, 29 Mar 2007 18:36:17 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.1.0.3]) by dignus.com (8.13.1/8.13.1) with ESMTP id l2TI3waG086767; Thu, 29 Mar 2007 14:03:58 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id l2TI5Vt63613; Thu, 29 Mar 2007 14:05:31 -0400 (EDT) (envelope-from rivers) Date: Thu, 29 Mar 2007 14:05:31 -0400 (EDT) From: Thomas David Rivers Message-Id: <200703291805.l2TI5Vt63613@lakes.dignus.com> To: des@des.no, nate@root.org, rpaulo@fnop.net In-Reply-To: <460BFD1D.9000402@fnop.net> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on office.dignus.com Cc: current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:36:18 -0000 The mainframe (z/OS) FTP server does not allow multiple "directories" in CWD command. This is due to the mapping of "directories" to flat file names in the z/OS dataset-name convention. So - while I can say: ftp> cd RIVERS ftp> cd TEST ftp> cd OBJ which results in the current working "directory" being RIVERS.TEST.OBJ. I cannot say ftp> cd RIVERS/TEST/OBJ But, I _could_ say: ftp> cd RIVERS.TEST.OBJ So - on "different" systems where the idea of "directory" has to be mapped onto a foreign filesystem, you can get interesting results. This may or may-not matter... I was just citing an example. - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:57:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE7D016A404 for ; Thu, 29 Mar 2007 18:57:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6D15613C489 for ; Thu, 29 Mar 2007 18:57:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 923452081; Thu, 29 Mar 2007 20:30:27 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7FDCB207E; Thu, 29 Mar 2007 20:30:27 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id D5247A1075; Thu, 29 Mar 2007 20:30:26 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Pieter de Goeje References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> Date: Thu, 29 Mar 2007 20:30:26 +0200 In-Reply-To: <200703291905.00192.pieter@degoeje.nl> (Pieter de Goeje's message of "Thu, 29 Mar 2007 19:04:59 +0200") Message-ID: <86k5wzq4vx.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:57:22 -0000 Pieter de Goeje writes: > Dag-Erling Sm=F8rgrav writes: > > No. This is a violation of the FTP protocol. > I'm reading rfc 959 right now, and it include examples of CWD with > full pathname (multiple directories). Actually the rfc is kinda > vague about this. RFC959 does not require or guarantee that the path separator is /, nor that "CD ../foo" does what you expect. There are also issues when the initial CWD is not / (the document part in an FTP URL is relative to the initial CWD, not absolute) Libfetch used to do what Nate suggests, and it was changed to the current behaviour because we encountered servers in the field with which it didn't work. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:57:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF40516A408 for ; Thu, 29 Mar 2007 18:57:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3E413C484 for ; Thu, 29 Mar 2007 18:57:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 846382085; Thu, 29 Mar 2007 20:33:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 0BAB2207E; Thu, 29 Mar 2007 20:33:59 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E9519A1075; Thu, 29 Mar 2007 20:33:58 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Pieter de Goeje References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> Date: Thu, 29 Mar 2007 20:33:58 +0200 In-Reply-To: <86k5wzq4vx.fsf@dwp.des.no> (Dag-Erling =?iso-8859-1?Q?Sm=F8r?= =?iso-8859-1?Q?grav's?= message of "Thu, 29 Mar 2007 20:30:26 +0200") Message-ID: <86fy7nq4q1.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:57:22 -0000 Dag-Erling Sm=F8rgrav writes: > Pieter de Goeje writes: > > Dag-Erling Sm=F8rgrav writes: > > > No. This is a violation of the FTP protocol. > > I'm reading rfc 959 right now, and it include examples of CWD with > > full pathname (multiple directories). Actually the rfc is kinda > > vague about this. > RFC959 does not require or guarantee that the path separator is /, nor > that "CD ../foo" does what you expect. There are also issues when the > initial CWD is not / (the document part in an FTP URL is relative to > the initial CWD, not absolute) I guess I should amend "this is a violation of the FTP protocol" to "this relies on assumptions which the FTP RFC does not allow us to make, and is a violation of RFC1738" DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 19:16:22 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 113CE16A404 for ; Thu, 29 Mar 2007 19:16:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 9355213C4C3 for ; Thu, 29 Mar 2007 19:16:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l2TJGDgN003219; Fri, 30 Mar 2007 05:16:13 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l2TJGDvd003218; Fri, 30 Mar 2007 05:16:13 +1000 (EST) (envelope-from peter) Date: Fri, 30 Mar 2007 05:16:13 +1000 From: Peter Jeremy To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070329191613.GB827@turion.vk2pj.dyndns.org> References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <86k5wzq4vx.fsf@dwp.des.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 19:16:22 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Mar-29 20:30:26 +0200, Dag-Erling Smrgrav wrote: >Libfetch used to do what Nate suggests, and it was changed to the >current behaviour because we encountered servers in the field with >which it didn't work. At first glance, the current behaviour does seem unnecessary and Nate's patch seems an "obvious" improvement. Having a comment near _ftp_cwd() explaining the current behaviour and why it isn't possible to pass a pathname to CWD would have saved Nate some effort and removed the need for this thread. Sometimes, it is as important to document why an alternative algorithm was not chosen as it is to document what the code is doing. --=20 Peter Jeremy --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGDBB9/opHv/APuIcRAhS2AKDAGVeajrhKsPQ2u9uQtdhmS125TgCggJUm WlgIGnSjwOh6S1wGvklxT3g= =bfz4 -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:11:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF6C416A402 for ; Thu, 29 Mar 2007 17:11:30 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4F34913C458 for ; Thu, 29 Mar 2007 17:11:30 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id EF63B2BAA0B for ; Thu, 29 Mar 2007 17:46:58 +0100 (BST) Received: (qmail 90341 invoked by uid 2223); 29 Mar 2007 16:47:01 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Mar 2007 16:47:01 -0000 Date: Thu, 29 Mar 2007 17:47:01 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: freebsd-current@freebsd.org Message-ID: <20070329174620.Q90308@nux.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 29 Mar 2007 19:20:21 +0000 Subject: ggated, gmirror + zfs panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:11:31 -0000 Hi, I am experimenting with ggate, gmirror and zfs to create a redundant file system using 2 machines. I currently do not have 10 spare drives so i have been using md devices to test the setup with. If I run through the below commands i am able to crash the machine every time. I have a vmcore available but think this should be easy to reproduce. On Secondary Machine # dd if=/dev/zero of=/home/mike-play/file0 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file1 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file2 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file3 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file4 bs=1k count=1000k # mdconfig -a -t vnode -f /home/mike-play/file0 -u 0 # mdconfig -a -t vnode -f /home/mike-play/file1 -u 1 # mdconfig -a -t vnode -f /home/mike-play/file2 -u 2 # mdconfig -a -t vnode -f /home/mike-play/file3 -u 3 # mdconfig -a -t vnode -f /home/mike-play/file4 -u 4 edit /etc/gg.exports 192.168.5.0/24 RW /dev/md0 192.168.5.0/24 RW /dev/md1 192.168.5.0/24 RW /dev/md2 192.168.5.0/24 RW /dev/md3 192.168.5.0/24 RW /dev/md4 Start ggated # ggated -v On Primary Machine # dd if=/dev/zero of=/home/mike-play/file0 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file1 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file2 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file3 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file4 bs=1k count=1000k # mdconfig -a -t vnode -f /home/mike-play/file0 -u 0 # mdconfig -a -t vnode -f /home/mike-play/file1 -u 1 # mdconfig -a -t vnode -f /home/mike-play/file2 -u 2 # mdconfig -a -t vnode -f /home/mike-play/file3 -u 3 # mdconfig -a -t vnode -f /home/mike-play/file4 -u 4 connect up the ggated exports: # ggatec create -u 0 192.168.5.212 /dev/md0 # ggatec create -u 1 192.168.5.212 /dev/md1 # ggatec create -u 2 192.168.5.212 /dev/md2 # ggatec create -u 3 192.168.5.212 /dev/md3 # ggatec create -u 4 192.168.5.212 /dev/md4 Setup the individual mirrors for each device: # gmirror label -v -b prefer zmirror0 /dev/ggate0 # gmirror insert -p90 zmirror0 /dev/md0 # gmirror label -v -b prefer zmirror1 /dev/ggate1 # gmirror insert -p90 zmirror1 /dev/md1 # gmirror label -v -b prefer zmirror2 /dev/ggate2 # gmirror insert -p90 zmirror2 /dev/md2 # gmirror label -v -b prefer zmirror3 /dev/ggate3 # gmirror insert -p90 zmirror3 /dev/md3 # gmirror label -v -b prefer zmirror4 /dev/ggate4 # gmirror insert -p90 zmirror4 /dev/md4 Create zfs pool from these mirrors: # zpool create tank raidz2 \ /dev/mirror/zmirror0 \ /dev/mirror/zmirror1 \ /dev/mirror/zmirror2 \ /dev/mirror/zmirror3 \ /dev/mirror/zmirror4 At this point the primary machine panics and enters the kernel debugger. If i exclude gmirror from the setup and only use the secondary machines md devices the zpool create works as expected: On Secondary machine: # dd if=/dev/zero of=/home/mike-play/file0 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file1 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file2 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file3 bs=1k count=1000k # dd if=/dev/zero of=/home/mike-play/file4 bs=1k count=1000k # mdconfig -a -t vnode -f /home/mike-play/file0 -u 0 # mdconfig -a -t vnode -f /home/mike-play/file1 -u 1 # mdconfig -a -t vnode -f /home/mike-play/file2 -u 2 # mdconfig -a -t vnode -f /home/mike-play/file3 -u 3 # mdconfig -a -t vnode -f /home/mike-play/file4 -u 4 edit /etc/gg.exports 192.168.5.0/24 RW /dev/md0 192.168.5.0/24 RW /dev/md1 192.168.5.0/24 RW /dev/md2 192.168.5.0/24 RW /dev/md3 192.168.5.0/24 RW /dev/md4 Start ggated # ggated -v On Primary machine: # ggatec create -u 0 192.168.5.212 /dev/md0 # ggatec create -u 1 192.168.5.212 /dev/md1 # ggatec create -u 2 192.168.5.212 /dev/md2 # ggatec create -u 3 192.168.5.212 /dev/md3 # ggatec create -u 4 192.168.5.212 /dev/md4 # zpool create tank raidz2 \ /dev/ggate0 \ /dev/ggate1 \ /dev/ggate2 \ /dev/ggate3 \ /dev/ggate4 # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 4.84G 206K 4.84G 0% ONLINE - f7# dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT-200703 #0: Wed Mar 28 12:34:58 BST 2007 mike@f7.eros.office:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3200+ (2194.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 1056899072 (1007 MB) avail memory = 1024897024 (977 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xd8000000-0xdbffffff,0xdc000000-0xdcffffff irq 16 at device 0.0 on pci1 re0: port 0x9000-0x90ff mem 0xde010000-0xde0100ff irq 16 at device 8.0 on pci0 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:0e:2e:92:7d:0a re0: [FILTER] fwohci0: port 0x9400-0x947f mem 0xde011000-0xde0117ff irq 17 at device 9.0 on pci0 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:30:67:00:00:04:c4:15 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:30:67:04:c4:15 fwe0: Ethernet address: 02:30:67:04:c4:15 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci0: port 0x9800-0x9807,0x9c00-0x9c03,0xa000-0xa007,0xa400-0xa403,0xa800-0xa80f,0xac00-0xacff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb000-0xb00f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xb400-0xb41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb800-0xb81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbc00-0xbc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc000-0xc01f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xde012000-0xde0120ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) vr0: port 0xc800-0xc8ff mem 0xde013000-0xde0130ff irq 23 at device 18.0 on pci0 miibus1: on vr0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: using obsoleted if_watchdog interface vr0: Ethernet address: 00:e0:4c:d5:10:a5 vr0: [ITHREAD] acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc8000-0xcffff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2194511372 Hz quality 800 Timecounters tick every 1.000 msec ad0: 39205MB at ata0-master UDMA133 acd0: CDROM at ata1-slave UDMA33 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ZFS filesystem version 3 ZFS storage pool version 3 From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 19:43:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C5CB16A400 for ; Thu, 29 Mar 2007 19:43:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id DEC1713C4AE for ; Thu, 29 Mar 2007 19:43:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5DD82208D; Thu, 29 Mar 2007 21:43:46 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4CC5F208A; Thu, 29 Mar 2007 21:43:45 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 9D6D9A1075; Thu, 29 Mar 2007 21:43:45 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Peter Jeremy References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <20070329191613.GB827@turion.vk2pj.dyndns.org> Date: Thu, 29 Mar 2007 21:43:45 +0200 In-Reply-To: <20070329191613.GB827@turion.vk2pj.dyndns.org> (Peter Jeremy's message of "Fri, 30 Mar 2007 05:16:13 +1000") Message-ID: <86y7lfomxa.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 19:43:52 -0000 Peter Jeremy writes: > At first glance, the current behaviour does seem unnecessary and > Nate's patch seems an "obvious" improvement. Having a comment near > _ftp_cwd() explaining the current behaviour and why it isn't possible > to pass a pathname to CWD would have saved Nate some effort and > removed the need for this thread. > > Sometimes, it is as important to document why an alternative algorithm > was not chosen as it is to document what the code is doing. Isn't that why we have CVS logs? ---------------------------- revision 1.92 date: 2005/08/12 12:48:50; author: des; state: Exp; lines: +152 -29 Change directory one level at a time, and use CDUP to back out. This is a work in progress; it partially fixed bin/83278 and is a prerequisite to fixing bin/83277. PR: bin/83277, bin/83278 ---------------------------- DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 20:11:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 978C016A407 for ; Thu, 29 Mar 2007 20:11:34 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from config.solomo.org (kasimir.com [85.214.51.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1588E13C468 for ; Thu, 29 Mar 2007 20:11:33 +0000 (UTC) (envelope-from flo@kasimir.com) Received: (qmail 33887 invoked from network); 29 Mar 2007 22:11:32 +0200 Received: from i53879947.versanet.de (HELO nibbler-osx.local) (83.135.153.71) by greenplay.de with SMTP; 29 Mar 2007 22:11:32 +0200 Message-ID: <460C1D4F.7090005@kasimir.com> Date: Thu, 29 Mar 2007 22:10:55 +0200 From: "Florian C. Smeets" User-Agent: Thunderbird 2.0.0.0pre (Macintosh/20070329) MIME-Version: 1.0 To: Robert Watson References: <20070329014733.GA1556@obelix.dsto.defence.gov.au> <20070329103632.N51007@fledge.watson.org> In-Reply-To: <20070329103632.N51007@fledge.watson.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: [PANIC] 7.0-CURRENT #0: Wed Mar 14 ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 20:11:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > > On Thu, 29 Mar 2007, Wilkinson, Alex wrote: > >> FreeBSD 7.0-CURRENT #0: Wed Mar 14 >> I have no clue what casued this. >> >> db> tr >> Tracing pid 11068 tid 100224 td 0xc55dfa20 >> kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32 >> panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191 >> sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at >> sbflush_internal >> sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at >> sbflush_internal+ >> 0x2d >> sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at >> sbrelease_int >> ernal+0x15 >> sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c >> soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247 >> soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at >> soo_close+0x37 >> >> fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814 >> >> >> 5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f >> >> 7d95,d2,0) at fdrop_locked+0xe4 >> closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4 >> kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188 >> syscall(e8145d38) at syscall+0x155 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = >> 0xbfbfebec, ebp = >> 0xbfbfebf8 --- >> db> > > There have a been a few such issues floating around, in which races > between protocol teardown of a socket and socket layer teardown result > in a panic during simultaneous access to the socket buffer. Udate to at > least 20070323, as glebius committed a fix for a class of these problems > as uipc_socket.c:1.295 on 20070322. If it recurs, please let us know. > Hi Robert, i can still reproduce this quite easily with latest current. panic: sbdrop KDB: enter: panic [thread pid 1116 tid 100075 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 1116 tid 100075 td 0xc122c910 kdb_enter(c06b33e2) at kdb_enter+0x2b panic(c06b76f3,0,c13aa464,c137bcb0,c1413540,...) at panic+0xbb sbdrop_internal(c13aa464,8260) at sbdrop_internal+0x40 sbflush_internal(c13aa464,c807cb54,c05559ee,c13aa464,c13aa414,...) at sbflush_internal+0x3e sbflush_locked(c13aa464) at sbflush_locked+0xb sbflush(c13aa464,c13aa414,c1413540,0,c13aa414,...) at sbflush+0x3a tcp_disconnect(c137bcb0) at tcp_disconnect+0x4b tcp_usr_disconnect(c13aa414,c807cbac,c0556aad,c13aa414,0,...) at tcp_usr_disconnect+0x88 sodisconnect(c13aa414,0,c135f510,0,0,...) at sodisconnect+0x26 soclose(c13aa414) at soclose+0x31 soo_close(c135f510,c122c910) at soo_close+0x5f fdrop_locked(c135f510,c122c910,c1230700,c807cc58,c04f2727,...) at fdrop_locked+0xc8 fdrop(c135f510,c122c910,895e004f,c8076047,c05c4cd9,...) at fdrop+0x3d closef(c135f510,c122c910,0,c122eb40,c122c910,...) at closef+0x407 kern_close(c122c910,a0,c807cd2c,c06866c6,c122c910,...) at kern_close+0x205 close(c122c910,c807cd00) at close+0x10 syscall(c807cd38) at syscall+0x29e Xint0x80_syscall() at Xint0x80_syscall+0x20 - --- syscall (6, FreeBSD ELF32, close), eip = 0x286bd907, esp = 0xbfbfec08, ebp = 0xbfbfec34 --- db> FreeBSD zoidberg.lan 7.0-CURRENT FreeBSD 7.0-CURRENT #6: Thu Mar 29 21:12:57 CEST 2007 root@zoidberg.lan:/usr/obj/usr/src/sys/SOEKRIS7 i386 Alex did you by any chance run mldonkey ? As i can only trigger this when running mldonkey... Regards, Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGDB1PA+1tjUZ1YScRAq1iAKCdaLF6vBXvX7B00BKbEYyeKE0S7gCdHKkg HspPNJZYOxYJDeOmtyBdFEU= =Gdtd -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 19:29:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C8C716A403 for ; Thu, 29 Mar 2007 19:29:16 +0000 (UTC) (envelope-from jasone@frebsd.org) Received: from canonware.com (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8065D13C455 for ; Thu, 29 Mar 2007 19:29:16 +0000 (UTC) (envelope-from jasone@frebsd.org) Received: from [10.0.0.2] (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) by canonware.com (Postfix) with ESMTP id E35501298E3; Thu, 29 Mar 2007 12:29:38 -0700 (PDT) Message-ID: <460C138B.7010802@frebsd.org> Date: Thu, 29 Mar 2007 12:29:15 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Ivan Voras References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Mar 2007 20:25:56 +0000 Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 19:29:16 -0000 Ivan Voras wrote: > [...] I'd really like if you could manage to implement > those ideas before 7.0, and here's why: > > - The standard for new servers here is 4 cores (in various socket > arrangements), and we're not at all high-tech. This is likely to go up. > - If you include hyperthreading, even all *desktops* are SMPs! In short, > even including desktops, I haven't installed a UP kernel in about a year. > - It's too long to wait for 8.0 for something as important as this. I already implemented features in malloc that greatly _reduce_ malloc-related contention, so I don't think it is necessary to rush further enhancements that would nearly _eliminate_ contention. We are already in pretty good shape. Also, of the enhancements I have in mind, those with highest (predicted) payoff are self-contained enough that backporting to RELENG_7 might be feasible. Jason From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 20:33:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C13A16A40E for ; Thu, 29 Mar 2007 20:33:55 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2600F13C4BA for ; Thu, 29 Mar 2007 20:33:55 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C25C41A4D89; Thu, 29 Mar 2007 13:33:54 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 99B2D51E4D; Thu, 29 Mar 2007 16:33:53 -0400 (EDT) Date: Thu, 29 Mar 2007 16:33:52 -0400 From: Kris Kennaway To: Ivan Voras Message-ID: <20070329203352.GA73837@xor.obsecurity.org> References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 20:33:55 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 07:51:56PM +0200, Ivan Voras wrote: > Jason Evans wrote: >=20 > > I have developed some novel algorithms for essentially eliminating > > thread contention on SMP systems, but it is too late in the development > > cycle to introduce such changes (not to mention that I lack the hardware > > to evaluate the algorithms). Thanks again for your patience and > > support. Please let me know if I can be of help in diagnosing suspected > > malloc issues. >=20 > First, thanks :) >=20 > Second, as a user, I'd really like if you could manage to implement > those ideas before 7.0, and here's why: >=20 > - The standard for new servers here is 4 cores (in various socket > arrangements), and we're not at all high-tech. This is likely to go up. > - If you include hyperthreading, even all *desktops* are SMPs! In short, > even including desktops, I haven't installed a UP kernel in about a year. > - It's too long to wait for 8.0 for something as important as this. As > far as I can see, 7.0 will be one of the "break as many things as you > need" releases (in the "good" sense, of course), so why not go for it. > Judging from past releases, "even" releases (4.x, 6.x) have been the > ones people trusted the most, so if you do get a glitch in 7.0 it won't > be as bad :) (of course, you can fix it in 7.1 :) ) >=20 > Maybe you could borrow the 8CPU machine used for MySQL / filedesc tuning > jeffr and others have been using (of course, once they've finished...)? I will be happy to (continue to) work with Jason on testing his changes, but there appears to be no urgent need for this: the mysql benchmark specifically shows that jemalloc scales well on 8 CPUs. In fact, the scalability problem seen on Linux turned out to be precisely because of poor scaling of glibc malloc http://ozlabs.org/~anton/linux/sysbench/ Kris --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGDCKwWry0BWjoQKURAnDJAJ9PIV8V3Bx0C1/Ce7sUU1UGvSvEpQCfYOoq 2GACt/d46rO1BurjbozXnOA= =KXtm -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 20:40:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36E2216A402 for ; Thu, 29 Mar 2007 20:40:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id E30F613C4C2 for ; Thu, 29 Mar 2007 20:40:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so287715ana for ; Thu, 29 Mar 2007 13:40:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dZZodnruKG8p8DChALJ/Ie0hyV53cHpShsOFCMjYZw8C6962QKf6AZw/B4R7jgebfG+MnNFvPHFouSpT4kt7iKjLjBTaww/aUyLlLd5in5c/zwNUHcUWz53RAJzO3b3KCa0eeKhLnAmVC5I1oEDs9lHMrmr7ZzH00INLaFs5G7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eX0Nc4KC0A5yhLZqKvCvMFMOC3gTXYDO5xg9w7XoLmtti0YN/FBwNwrClBXH2XsIkDwM4+QwOvuVfnYigRm4pQw4G/foaWN6L3DjiJeLDQZK4Q0oGy83fxJw2lbguYMQq/ZAAZ31SlRB2JAwmlRU/L23HRrDjnAN4MnZ3OvcCdM= Received: by 10.100.10.20 with SMTP id 20mr823302anj.1175200853656; Thu, 29 Mar 2007 13:40:53 -0700 (PDT) Received: by 10.100.191.1 with HTTP; Thu, 29 Mar 2007 13:40:53 -0700 (PDT) Message-ID: <3bbf2fe10703291340s2e58396k254f5c2671a605aa@mail.gmail.com> Date: Thu, 29 Mar 2007 22:40:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kris Kennaway" In-Reply-To: <20070329203352.GA73837@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> <20070329203352.GA73837@xor.obsecurity.org> X-Google-Sender-Auth: 54e1f340f6a29101 Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 20:40:55 -0000 2007/3/29, Kris Kennaway : > On Thu, Mar 29, 2007 at 07:51:56PM +0200, Ivan Voras wrote: > > Jason Evans wrote: > > > > > I have developed some novel algorithms for essentially eliminating > > > thread contention on SMP systems, but it is too late in the development > > > cycle to introduce such changes (not to mention that I lack the hardware > > > to evaluate the algorithms). Thanks again for your patience and > > > support. Please let me know if I can be of help in diagnosing suspected > > > malloc issues. > > > > First, thanks :) > > > > Second, as a user, I'd really like if you could manage to implement > > those ideas before 7.0, and here's why: > > > > - The standard for new servers here is 4 cores (in various socket > > arrangements), and we're not at all high-tech. This is likely to go up. > > - If you include hyperthreading, even all *desktops* are SMPs! In short, > > even including desktops, I haven't installed a UP kernel in about a year. > > - It's too long to wait for 8.0 for something as important as this. As > > far as I can see, 7.0 will be one of the "break as many things as you > > need" releases (in the "good" sense, of course), so why not go for it. > > Judging from past releases, "even" releases (4.x, 6.x) have been the > > ones people trusted the most, so if you do get a glitch in 7.0 it won't > > be as bad :) (of course, you can fix it in 7.1 :) ) > > > > Maybe you could borrow the 8CPU machine used for MySQL / filedesc tuning > > jeffr and others have been using (of course, once they've finished...)? > > I will be happy to (continue to) work with Jason on testing his > changes, but there appears to be no urgent need for this: the mysql > benchmark specifically shows that jemalloc scales well on 8 CPUs. In > fact, the scalability problem seen on Linux turned out to be precisely > because of poor scaling of glibc malloc > > http://ozlabs.org/~anton/linux/sysbench/ Well, I'm not sure, since this test refers to core=4 while your tests were using a lot of more threads... Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 20:46:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51BA616A401; Thu, 29 Mar 2007 20:46:20 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3912313C459; Thu, 29 Mar 2007 20:46:20 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C20BC1A4D86; Thu, 29 Mar 2007 13:46:19 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0ED785166B; Thu, 29 Mar 2007 16:46:19 -0400 (EDT) Date: Thu, 29 Mar 2007 16:46:18 -0400 From: Kris Kennaway To: Attilio Rao Message-ID: <20070329204618.GA74123@xor.obsecurity.org> References: <200703281955.l2SJt7Ua086062@repoman.freebsd.org> <460AE766.6050409@frebsd.org> <20070329203352.GA73837@xor.obsecurity.org> <3bbf2fe10703291340s2e58396k254f5c2671a605aa@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <3bbf2fe10703291340s2e58396k254f5c2671a605aa@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org, Ivan Voras , Kris Kennaway Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 20:46:20 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 10:40:53PM +0200, Attilio Rao wrote: > 2007/3/29, Kris Kennaway : > >On Thu, Mar 29, 2007 at 07:51:56PM +0200, Ivan Voras wrote: > >> Jason Evans wrote: > >> > >> > I have developed some novel algorithms for essentially eliminating > >> > thread contention on SMP systems, but it is too late in the developm= ent > >> > cycle to introduce such changes (not to mention that I lack the=20 > >hardware > >> > to evaluate the algorithms). Thanks again for your patience and > >> > support. Please let me know if I can be of help in diagnosing=20 > >suspected > >> > malloc issues. > >> > >> First, thanks :) > >> > >> Second, as a user, I'd really like if you could manage to implement > >> those ideas before 7.0, and here's why: > >> > >> - The standard for new servers here is 4 cores (in various socket > >> arrangements), and we're not at all high-tech. This is likely to go up. > >> - If you include hyperthreading, even all *desktops* are SMPs! In shor= t, > >> even including desktops, I haven't installed a UP kernel in about a ye= ar. > >> - It's too long to wait for 8.0 for something as important as this. As > >> far as I can see, 7.0 will be one of the "break as many things as you > >> need" releases (in the "good" sense, of course), so why not go for it. > >> Judging from past releases, "even" releases (4.x, 6.x) have been the > >> ones people trusted the most, so if you do get a glitch in 7.0 it won't > >> be as bad :) (of course, you can fix it in 7.1 :) ) > >> > >> Maybe you could borrow the 8CPU machine used for MySQL / filedesc tuni= ng > >> jeffr and others have been using (of course, once they've finished...)? > > > >I will be happy to (continue to) work with Jason on testing his > >changes, but there appears to be no urgent need for this: the mysql > >benchmark specifically shows that jemalloc scales well on 8 CPUs. In > >fact, the scalability problem seen on Linux turned out to be precisely > >because of poor scaling of glibc malloc > > > > http://ozlabs.org/~anton/linux/sysbench/ >=20 > Well, I'm not sure, since this test refers to core=3D4 while your tests > were using a lot of more threads... Well, it at least fixed *a* serious problem and it looks like it was probably the main one. Jeff hasn't been available to retest it on his linux machine to see where we stand now though. Kris --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGDCWaWry0BWjoQKURAj9GAKC0u+A1/VwaV6tqEsG4ooAhi/yACgCgi1in dcB4uYzn2lFwVJt/sv68WC4= =wr8Q -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 01:26:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EADE16A401 for ; Fri, 30 Mar 2007 01:26:26 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id BBEA613C459 for ; Fri, 30 Mar 2007 01:26:25 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 27DE41CC58; Fri, 30 Mar 2007 13:13:54 +1200 (NZST) Date: Fri, 30 Mar 2007 13:13:54 +1200 From: Andrew Thompson To: freebsd-current@freebsd.org Message-ID: <20070330011354.GE97061@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: CFT: new trunk(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 01:26:26 -0000 Hi, Here is a patch to add OpenBSD's trunk(4) interface, and also includes LACP support which came from agr(4) on NetBSD. Im interested in anyone who wants to test this and in particular lacp mode if you have a switch that supports it. http://people.freebsd.org/~thompsa/if_trunk-20070330b.diff The procedure to build this is (on an recent current) cd /usr/src patch -p0 < if_trunk-20070330b.diff build kernel and world... install kernel and world... To create a lacp trunk ifconfig trunk0 create ifconfig trunk0 up ifconfig trunk0 trunkproto lacp ifconfig trunk0 trunkport fxp0 ifconfig trunk0 trunkport fxp1 ifconfig will show you the status of the trunk, for lacp the port will be forwarding when it reaches COLLECTING and DISTRIBUTING. There are other trunk modes failover,loadbalance and roundrobin (see the man page). Any feedback would be great. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 16:56:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AE8416A400 for ; Fri, 30 Mar 2007 16:56:57 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id C552E13C45A for ; Fri, 30 Mar 2007 16:56:56 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so885353ugh for ; Fri, 30 Mar 2007 09:56:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition; b=cGksXeRI8+IXq+7LOik6iaTCeiwXAYMWBD2fTXmJNRQDycKJwZSlxS7jgA+qSxWBMY9EQyHujJWsyY9je1SVpuiMqZdQ37NkXS9/PTHu6uYfbzPt+GpWsksS35ZXpigwnX8s0+D6B9tYlbt/Q4HpXZqZ49VuDlARkYVdXjyDaRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition; b=B6RqU6/38GADQzYwf6Z4BCb5BTzB6i1x6bRaU4lPBaLaEAh4J1ChpOlE2oFMTIzXkMqWMECijs3eaJ0AGYr5Pb89BmYLo2hXo+ega724Yq77Ro/HMvLPvgF3I/LRtm3G7jpzCYqbDElPagqZLc96Rx9wcd7gU+fNPggiGxK0P44= Received: by 10.67.10.12 with SMTP id n12mr2107249ugi.1175273812381; Fri, 30 Mar 2007 09:56:52 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.153.240]) by mx.google.com with ESMTP id b23sm3494228ugd.2007.03.30.09.56.50; Fri, 30 Mar 2007 09:56:51 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l2TLuweJ006517 for ; Thu, 29 Mar 2007 23:56:58 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l2TLurDm006516 for current@freebsd.org; Thu, 29 Mar 2007 23:56:53 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 29 Mar 2007 23:56:52 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070329215652.GD1524@roadrunner.q.local> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 16:56:57 -0000 Hi, there hasn't been much news about several features that were once said to arrive Real Soon[TM]. I just wanted to gather some news about their status and if they can/will/should make it into 7.0. - Superpages - HPS USB stack - DTrace - ZFS - Xorg 7.1 (7.2?) I understand that there has been put _a_lot_ of work into each of these features and it would be sad if they didn't make it into a release soon. Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 17:04:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2BC516A403 for ; Fri, 30 Mar 2007 17:04:20 +0000 (UTC) (envelope-from taras@elantech.ru) Received: from mail2.elantech.ru (mail2.elantech.ru [87.245.154.206]) by mx1.freebsd.org (Postfix) with ESMTP id D89A913C4B0 for ; Fri, 30 Mar 2007 17:04:19 +0000 (UTC) (envelope-from taras@elantech.ru) Received: from [10.10.10.13] (unknown [88.84.198.2]) by mail2.elantech.ru (Postfix) with ESMTP id E92E534045; Fri, 30 Mar 2007 20:42:27 +0400 (MSD) Message-ID: <460D3E52.2030004@elantech.ru> Date: Fri, 30 Mar 2007 20:44:02 +0400 From: Taras Savchuk Organization: Elantech Ltd. (http://www.elantech.ru) User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------040403060402010301010901" Cc: freebsd-stable@freebsd.org Subject: pam_group modification X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: taras@elantech.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 17:04:20 -0000 This is a multi-part message in MIME format. --------------040403060402010301010901 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit I tried to use pam_group to grant access to imap(dovecot) only for users in certain group (users/groups stored in AD and checked out via LDAP/Kerberos), but pam_group is checking applicant's group membership. I'm sure, that in many cases is more useful to check group membership of target (authenticating) user, but not applicant. I added check_target option to pam_group to allow checks for authenticating user if needed. I'm very bad with diff, so it's modified/original pam_group.c and pam_group.8 (FreeBSD 6.2). Can it be included in the system? -- � 兩주턱�터, 竄梨瑯 賤怒� 程� "晃죔旽�" : 屬憧菊譚曠 郁, WEB-怒撲좌鞫個 http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 779 07 05 --------------040403060402010301010901 Content-Type: text/plain; name="pam_group.8" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pam_group.8" .\" Copyright (c) 2003 Networks Associates Technology, Inc. .\" All rights reserved. .\" .\" Portions of this software were developed for the FreeBSD Project by .\" ThinkSec AS and NAI Labs, the Security Research Division of Network .\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 .\" ("CBOSS"), as part of the DARPA CHATS research program. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. The name of the author may not be used to endorse or promote .\" products derived from this software without specific prior written .\" permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $FreeBSD: src/lib/libpam/modules/pam_group/pam_group.8,v 1.31 2004/07/02 23:52:17 ru Exp $ .\" .Dd March 30, 2007 .Dt PAM_GROUP 8 .Os .Sh NAME .Nm pam_group .Nd Group PAM module .Sh SYNOPSIS .Op Ar service-name .Ar module-type .Ar control-flag .Pa pam_group .Op Ar arguments .Sh DESCRIPTION The group service module for PAM accepts or rejects users based on their membership in a particular file group. .Pp The following options may be passed to the .Nm module: .Bl -tag -width ".Cm check_target" .It Cm check_target By default module checks applicat's membership in certain group. With this option all checks are made for target user. .It Cm deny Reverse the meaning of the test, i.e., reject the user if and only if he or she is a member of the specified group. This can be useful to exclude certain groups of users from certain services. .It Cm fail_safe If the specified group does not exist, or has no members, act as if it does exist and the user is a member. .It Cm group Ns = Ns Ar groupname Specify the name of the group to check. The default is .Dq Li wheel . .It Cm root_only Skip this module entirely if user is not the superuser account. .El .Sh SEE ALSO .Xr pam.conf 5 , .Xr pam 8 .Sh AUTHORS The .Nm module and this manual page were developed for the .Fx Project by ThinkSec AS and NAI Labs, the Security Research Division of Network Associates, Inc.\& under DARPA/SPAWAR contract N66001-01-C-8035 .Pq Dq CBOSS , as part of the DARPA CHATS research program. --------------040403060402010301010901 Content-Type: text/plain; name="pam_group.8.orig" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pam_group.8.orig" .\" Copyright (c) 2003 Networks Associates Technology, Inc. .\" All rights reserved. .\" .\" Portions of this software were developed for the FreeBSD Project by .\" ThinkSec AS and NAI Labs, the Security Research Division of Network .\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 .\" ("CBOSS"), as part of the DARPA CHATS research program. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. The name of the author may not be used to endorse or promote .\" products derived from this software without specific prior written .\" permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $FreeBSD: src/lib/libpam/modules/pam_group/pam_group.8,v 1.3 2004/07/02 23:52:17 ru Exp $ .\" .Dd February 6, 2003 .Dt PAM_GROUP 8 .Os .Sh NAME .Nm pam_group .Nd Group PAM module .Sh SYNOPSIS .Op Ar service-name .Ar module-type .Ar control-flag .Pa pam_group .Op Ar arguments .Sh DESCRIPTION The group service module for PAM accepts or rejects users based on their membership in a particular file group. .Pp The following options may be passed to the .Nm module: .Bl -tag -width ".Cm fail_safe" .It Cm deny Reverse the meaning of the test, i.e., reject the applicant if and only if he or she is a member of the specified group. This can be useful to exclude certain groups of users from certain services. .It Cm fail_safe If the specified group does not exist, or has no members, act as if it does exist and the applicant is a member. .It Cm group Ns = Ns Ar groupname Specify the name of the group to check. The default is .Dq Li wheel . .It Cm root_only Skip this module entirely if the target account is not the superuser account. .El .Sh SEE ALSO .Xr pam.conf 5 , .Xr pam 8 .Sh AUTHORS The .Nm module and this manual page were developed for the .Fx Project by ThinkSec AS and NAI Labs, the Security Research Division of Network Associates, Inc.\& under DARPA/SPAWAR contract N66001-01-C-8035 .Pq Dq CBOSS , as part of the DARPA CHATS research program. --------------040403060402010301010901 Content-Type: text/plain; name="pam_group.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pam_group.c" /*- * Copyright (c) 2003 Networks Associates Technology, Inc. * All rights reserved. * * Portions of this software were developed for the FreeBSD Project by * ThinkSec AS and NAI Labs, the Security Research Division of Network * Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 * ("CBOSS"), as part of the DARPA CHATS research program. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote * products derived from this software without specific prior written * permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include __FBSDID("$FreeBSD: src/lib/libpam/modules/pam_group/pam_group.c,v 1.41 2003/12/11 13:55:15 des Exp $"); #include #include #include #include #include #include #include #include #define PAM_SM_AUTH #include #include #include PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags __unused, int argc __unused, const char *argv[] __unused) { const char *group, *user; const void *ruser; char *const *list; struct passwd *pwd; struct group *grp; /* get target account */ if (pam_get_user(pamh, &user, NULL) != PAM_SUCCESS || user == NULL || (pwd = getpwnam(user)) == NULL) return (PAM_AUTH_ERR); if(!openpam_get_option(pamh, "check_target")) { /* get applicant */ if (pam_get_item(pamh, PAM_RUSER, &ruser) != PAM_SUCCESS || ruser == NULL || (pwd = getpwnam(ruser)) == NULL) return (PAM_AUTH_ERR); } if (pwd->pw_uid != 0 && openpam_get_option(pamh, "root_only")) return (PAM_IGNORE); /* get regulating group */ if ((group = openpam_get_option(pamh, "group")) == NULL) group = "wheel"; if ((grp = getgrnam(group)) == NULL || grp->gr_mem == NULL) goto failed; /* check if the group is empty */ if (*grp->gr_mem == NULL) goto failed; /* check membership */ if (pwd->pw_gid == grp->gr_gid) goto found; for (list = grp->gr_mem; *list != NULL; ++list) if (strcmp(*list, pwd->pw_name) == 0) goto found; not_found: if (openpam_get_option(pamh, "deny")) return (PAM_SUCCESS); return (PAM_AUTH_ERR); found: if (openpam_get_option(pamh, "deny")) return (PAM_AUTH_ERR); return (PAM_SUCCESS); failed: if (openpam_get_option(pamh, "fail_safe")) goto found; else goto not_found; } PAM_EXTERN int pam_sm_setcred(pam_handle_t * pamh __unused, int flags __unused, int argc __unused, const char *argv[] __unused) { return (PAM_SUCCESS); } PAM_MODULE_ENTRY("pam_group"); --------------040403060402010301010901 Content-Type: text/plain; name="pam_group.c.orig" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pam_group.c.orig" /*- * Copyright (c) 2003 Networks Associates Technology, Inc. * All rights reserved. * * Portions of this software were developed for the FreeBSD Project by * ThinkSec AS and NAI Labs, the Security Research Division of Network * Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 * ("CBOSS"), as part of the DARPA CHATS research program. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote * products derived from this software without specific prior written * permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include __FBSDID("$FreeBSD: src/lib/libpam/modules/pam_group/pam_group.c,v 1.4 2003/12/11 13:55:15 des Exp $"); #include #include #include #include #include #include #include #include #define PAM_SM_AUTH #include #include #include PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags __unused, int argc __unused, const char *argv[] __unused) { const char *group, *user; const void *ruser; char *const *list; struct passwd *pwd; struct group *grp; /* get target account */ if (pam_get_user(pamh, &user, NULL) != PAM_SUCCESS || user == NULL || (pwd = getpwnam(user)) == NULL) return (PAM_AUTH_ERR); if (pwd->pw_uid != 0 && openpam_get_option(pamh, "root_only")) return (PAM_IGNORE); /* get applicant */ if (pam_get_item(pamh, PAM_RUSER, &ruser) != PAM_SUCCESS || ruser == NULL || (pwd = getpwnam(ruser)) == NULL) return (PAM_AUTH_ERR); /* get regulating group */ if ((group = openpam_get_option(pamh, "group")) == NULL) group = "wheel"; if ((grp = getgrnam(group)) == NULL || grp->gr_mem == NULL) goto failed; /* check if the group is empty */ if (*grp->gr_mem == NULL) goto failed; /* check membership */ if (pwd->pw_gid == grp->gr_gid) goto found; for (list = grp->gr_mem; *list != NULL; ++list) if (strcmp(*list, pwd->pw_name) == 0) goto found; not_found: if (openpam_get_option(pamh, "deny")) return (PAM_SUCCESS); return (PAM_AUTH_ERR); found: if (openpam_get_option(pamh, "deny")) return (PAM_AUTH_ERR); return (PAM_SUCCESS); failed: if (openpam_get_option(pamh, "fail_safe")) goto found; else goto not_found; } PAM_EXTERN int pam_sm_setcred(pam_handle_t * pamh __unused, int flags __unused, int argc __unused, const char *argv[] __unused) { return (PAM_SUCCESS); } PAM_MODULE_ENTRY("pam_group"); --------------040403060402010301010901-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 19:16:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F023E16A404 for ; Fri, 30 Mar 2007 19:16:37 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from email.aon.at (nat-warsl417-01.aon.at [195.3.96.119]) by mx1.freebsd.org (Postfix) with ESMTP id 178CA13C44C for ; Fri, 30 Mar 2007 19:16:36 +0000 (UTC) (envelope-from c47g@gmx.at) Received: (qmail 10099 invoked from network); 30 Mar 2007 18:49:56 -0000 Received: from unknown (HELO email.aon.at) ([172.18.5.238]) (envelope-sender ) by fallback02.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 30 Mar 2007 18:49:56 -0000 Received: (qmail 7422 invoked from network); 30 Mar 2007 18:49:54 -0000 Received: from m3669p016.adsl.highway.telekom.at (HELO bones) ([88.117.106.144]) (envelope-sender ) by smarthub74.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 30 Mar 2007 18:49:54 -0000 From: Christian Gusenbauer Date: Fri, 30 Mar 2007 20:50:24 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/signed; boundary="nextPart2931704.5ktb0q4XXM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703302050.31758.c47g@gmx.at> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems burning CDs with ASUS P5B-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 19:16:38 -0000 --nextPart2931704.5ktb0q4XXM Content-Type: multipart/mixed; boundary="Boundary-01=_wvVDGcVer+9vTrK" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_wvVDGcVer+9vTrK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! I'm having some problems burning CDs and DVDs with -current on a=20 new ASUS P5B-E board with an Intel Core 2 Duo. The IDE DVD drive, a Plextor= =20 PX708A is connected to the JMicron JMB363 controller. =46irst of all, there's a problem detecting the atapicam based cd0 device. = As=20 long as hw.ata.atapi_dma is set to 1, the boot hangs while the kernel=20 searches for the device. Many commands time out like: (probe0:ata4:0:0:0): xpt_schedule (probe0:ata4:0:0:0): xpt_setup_ccb (probe0:ata4:0:0:0): probestart (probe0:ata4:0:0:0): xpt_action (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 atapi_action: hcb@0xc4a47c80: 12 1 80 0 ff 0 (noperiph:ata4:0:-1:-1): xpt_async (noperiph:ata4:0:0:0): xpt_compile_path (noperiph:ata4:0:0:0): xpt_release_path acd0: FAILURE - INQUIRY timed out atapi_cb: hcb@0xc4a47c80 sense =3D 00: sk =3D 0 acd0: cmd INQUIRY status 00 result 05 error 00 (probe0:ata4:0:0:0): xpt_done (probe0:ata4:0:0:0): camisr (probe0:ata4:0:0:0): probedone (probe0:ata4:0:0:0): xpt_action (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 atapi_action: hcb@0xc4a47c40: 12 1 80 0 ff 0 acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request=20 directly (noperiph:ata4:0:-1:-1): xpt_async (noperiph:ata4:0:0:0): xpt_compile_path (noperiph:ata4:0:0:0): xpt_release_path acd0: FAILURE - INQUIRY timed out atapi_cb: hcb@0xc4a47c40 sense =3D 00: sk =3D 0 acd0: cmd INQUIRY status 00 result 05 error 00 (probe0:ata4:0:0:0): xpt_done Nevertheless, after about 20 minutes both devices, an acd0 and a cd0 are=20 recognized. I can mount a CD using both acd0 and cd0 and reading from the C= D=20 is no problem. But when I try to burn a CD or DVD with burncd or cdrecord,= =20 after a while the drive's LED stops blinking and the process then hangs=20 indefinitly. If I turn dma off (hw.ata.atapi_dma=3D"0" setting in loader.conf), the driv= es=20 are correctly detected and there are no hangs (no timeouts) during boot.=20 Mounting and reading from the CD is no problem, but burning doesn't work=20 either :-(. Any ideas? Thanks in advance, Christian. --Boundary-01=_wvVDGcVer+9vTrK-- --nextPart2931704.5ktb0q4XXM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQBGDVv373Wh/GTgh8wRArhdAJ9wD4oLDXM4P44872IpQxmdjTFvmwCfZv2h wYI394XFiWz3KitTFesNe1Y= =umbT -----END PGP SIGNATURE----- --nextPart2931704.5ktb0q4XXM-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 19:24:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6381B16A400 for ; Fri, 30 Mar 2007 19:24:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 544D713C43E for ; Fri, 30 Mar 2007 19:24:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 307AE1A4DA4 for ; Fri, 30 Mar 2007 12:24:08 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 78EC0515AC; Fri, 30 Mar 2007 15:24:07 -0400 (EDT) Date: Fri, 30 Mar 2007 15:24:07 -0400 From: Kris Kennaway To: current@freebsd.org Message-ID: <20070330192406.GA17536@xor.obsecurity.org> References: <20070329215652.GD1524@roadrunner.q.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070329215652.GD1524@roadrunner.q.local> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 19:24:08 -0000 On Thu, Mar 29, 2007 at 11:56:52PM +0200, Ulrich Spoerlein wrote: > Hi, > > there hasn't been much news about several features that were once said > to arrive Real Soon[TM]. I just wanted to gather some news about their > status and if they can/will/should make it into 7.0. > > - Superpages Don't know, I hope so. > - HPS USB stack It seems unlikely. > - DTrace Suspended due to non-technical reasons. > - ZFS Maybe. > - Xorg 7.1 (7.2?) Yes. Kris From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 22:43:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13E6716A401 for ; Fri, 30 Mar 2007 22:43:43 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id E1C4313C4C4 for ; Fri, 30 Mar 2007 22:43:42 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HXPoh-0003ZY-Dm for freebsd-current@freebsd.org; Fri, 30 Mar 2007 18:43:31 -0400 Message-ID: <460D930B.1090309@metricsystems.com> Date: Fri, 30 Mar 2007 14:45:31 -0800 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Subject: Building an /etc from scratch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 22:43:43 -0000 The doc for building the world indicate that the kernel and /etc are not build in the 'world' process. How does one create an /etc from src/etc. There does not seem to be a make target in the main Makefile at the top of the hierarchy. A couple of points here... I don't have a 'working' FreeBSD system at the moment, and because of failures to boot off of a USB CDROM device, I don't have the usual 'installer' running. I was able to use the pxeboot via BOOTP to get a diskless system up and running and was able to compile the world, and GENERIC kernel via this mode. However, building the /etc directory seems to not have much support in terms of Makefile references. Thanks John Clark. From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 23:30:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84E0416A401 for ; Fri, 30 Mar 2007 23:30:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF5A13C458 for ; Fri, 30 Mar 2007 23:30:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l2UMqAFa028595; Fri, 30 Mar 2007 15:52:10 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 92DB5100E4; Fri, 30 Mar 2007 15:52:10 -0700 (PDT) X-AuditID: 11807124-aee86bb000001b9e-c5-460d949a4035 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id 8163910092; Fri, 30 Mar 2007 15:52:10 -0700 (PDT) In-Reply-To: <460D930B.1090309@metricsystems.com> References: <460D930B.1090309@metricsystems.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A767421-261E-4EF2-824B-B0290C17C62E@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 30 Mar 2007 15:52:09 -0700 To: John Clark X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@freebsd.org Subject: Re: Building an /etc from scratch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 23:30:59 -0000 On Mar 30, 2007, at 3:45 PM, John Clark wrote: > The doc for building the world indicate that the kernel and /etc > are not build in the 'world' > process. > > How does one create an /etc from src/etc. There does not seem to be > a make target in > the main Makefile at the top of the hierarchy. You might find mergemaster helpful, or similar tools in ports (sysutils/etcmerge?). You might also take a look at the "make release" manpage, which discusses additional targets used to create a fully-populated system under a filesystem location suitable for turning into an ISO image. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 00:12:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7CC716A473 for ; Sat, 31 Mar 2007 00:12:58 +0000 (UTC) (envelope-from Lucas.James@ldjcs.com.au) Received: from vscan02.westnet.com.au (vscan02.westnet.com.au [203.10.1.132]) by mx1.freebsd.org (Postfix) with ESMTP id 19E8113C44B for ; Sat, 31 Mar 2007 00:12:58 +0000 (UTC) (envelope-from Lucas.James@ldjcs.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 733F411D8DC; Sat, 31 Mar 2007 07:40:10 +0800 (WST) Received: from vscan02.westnet.com.au ([127.0.0.1]) by localhost (vscan02.westnet.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22765-01; Sat, 31 Mar 2007 07:38:21 +0800 (WST) Received: from mail.ldjcs.com.au (gw.ldjcs.com.au [58.6.71.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vscan02.westnet.com.au (Postfix) with ESMTP id D1B8611EFFF; Sat, 31 Mar 2007 07:38:20 +0800 (WST) Received: from mail.ldjcs.com.au (mail.ldjcs.com.au [IPv6:2001:388:c069::4]) by mail.ldjcs.com.au (8.13.8/8.13.6) with ESMTP id l2UNcUsR039344; Sat, 31 Mar 2007 09:38:31 +1000 (EST) (envelope-from Lucas.James@ldjcs.com.au) From: Lucas James Organization: LDJ Computer Services To: freebsd-current@freebsd.org Date: Sat, 31 Mar 2007 09:38:29 +1000 User-Agent: KMail/1.9.5 References: <460D930B.1090309@metricsystems.com> In-Reply-To: <460D930B.1090309@metricsystems.com> X-Face: e#5HTm!2AOnnlvY27|AK6.`J(ChPFkY3HW!e4V4wR['1cgNGkM]jcez{.k&'BU<=?utf-8?q?9PXMyZV=0A=09I=5DY6?=(=?utf-8?q?=3B=7Bf4=3BJ=24YOdl4=2E72fZ7j=5D=5FFLF=5EmMP=25V4=5Du=2E=3FX?= =?utf-8?q?U=5CTEgmbQ=23Xz=3BNpIa=3DGa=25z=7BvzRD=3A=5Da=0A=09ag5GR3cU3Amx?=>{B~V]n#Ost[Y2G+%5, KIt%?Bl6+nV55<6D> =?utf-8?q?=3AUJde!=23a=25Qq=7DAjbLUF13P/=0A=099e+eKK?=)bHSAwJub}Kw80RW&i$lZ[e{%uSGh{3%?eq#YghK|y8r.N, ~6@'_#, =?utf-8?q?MC-w=7DJB-5W=0A=09=3A/w?=,dDT'sHeU{nws)>E; 3Tk@Tm38Ju~)VhS; FSDz*VbetRLV{ MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703310938.29856.Lucas.James@ldjcs.com.au> X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DK_POLICY_SIGNSOME,NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail.ldjcs.com.au Cc: John Clark Subject: Re: Building an /etc from scratch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2007 00:12:58 -0000 On Saturday 31 March 2007 08:45, John Clark wrote: G'Day John, > How does one create an /etc from src/etc. There does not seem to be a > make target in > the main Makefile at the top of the hierarchy. > A couple of points here... I don't have a 'working' FreeBSD system at > the moment, and > because of failures to boot off of a USB CDROM device, I don't have the > usual 'installer' > running. I was able to use the pxeboot via BOOTP to get a diskless > system up and running > and was able to compile the world, and GENERIC kernel via this mode. > However, building the /etc directory seems to not have much support in > terms of Makefile > references. once you have installed world+kernel, you can: make distribute DESTDIR=/path/to/your/broken/system/root from /usr/src (gleaned from the how to setup a jail directory tree in jail(8) regards, Lucas -- I think... I think it's in my basement... Let me go upstairs and check. -- Escher From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 00:30:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3D7B16A40E for ; Sat, 31 Mar 2007 00:30:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id A9E8E13C43E for ; Sat, 31 Mar 2007 00:30:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so836004wra for ; Fri, 30 Mar 2007 17:30:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=bZXT/MTvaSZxJeYnwKQe+2LZuIW5lWG177I3qgaie1fh31XhZ2RJX6CJG2rn0PxPJB7zPsq1LoStd1wVdubZT8WjEQaRgnIe8DNyLMd3tAnmqZAVLIJkIBYhOBvVnd8939oVrKzNxvSsgUJP1w5NolqfZ5ZGXytFhVgXPz/QFZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=udXE8OQYRGdBbjOZAi/tRNK344On3Ew7vJcRC3Knx9cISNU3S48SkZvtKRMcgaoV4jeObCoNaC/Nl6HvyzXuyQ5QEtBEaVc0dn5Ck1/7XGjqlZfU6MJvABFJMf3WB+tRhrloPCtKhRwIsuCxBMch6CpKq1iU7bGuLkJ1Wlhml78= Received: by 10.114.156.1 with SMTP id d1mr948864wae.1175301031457; Fri, 30 Mar 2007 17:30:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id m29sm2373747poh.2007.03.30.17.30.28; Fri, 30 Mar 2007 17:30:29 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l2V0UXGv069042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Mar 2007 09:30:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2V0UVPl069041; Sat, 31 Mar 2007 09:30:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 31 Mar 2007 09:30:31 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070331003031.GB68853@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070313070153.GD87608@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 00:30:33 -0000 On Tue, Mar 13, 2007 at 04:01:53PM +0900, To Rainer Hurling wrote: > On Tue, Mar 13, 2007 at 06:29:25AM +0100, Rainer Hurling wrote: > > Over night my systems works well, only one message from network came up: > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > I'm not sure this watchdog is related with VSC8601 PHY. > However Mr. Darren also reported watchdog errors on MCP55 so I have > to think again what makes MCP55 different. > > > In the morning I tried your patch for mii and PHY. Bootingverbose again > > gives me: > > > > nfe0: port 0xb000-0xb007 mem > > 0xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > > nfe0: bpf attached > > nfe0: Ethernet address: 00:16:17:95:d9:7c > > miibus0: on nfe0 > > ciphy0: PHY 1 on miibus0 > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > nfe0: [MPSAFE] > > nfe0: [FILTER] > > > > > > First, all seems to be ok. Network was up and connected. After a minute > > I lost connection and the following messages appeared: > > > > miibus0: unknown CICADA PHY model 2 > > miibus0: unknown CICADA PHY model 2 > > miibus0: unknown CICADA PHY model 2 > > Sorry, you can ignore this. I've ommitted a code needed in fixup code > for VSC8601. > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > ... > > > > This is real problem. I guess ciphy(4) failed to report correct link > state so watchdog handler was activated. Apparently we **NEED** a copy > of the documentation for the PHY. :-( > You can revert the PHY changes and use ukphy(4) until the issue is > resolved. > Would you try updated ciphy(4) patch? I've got a successful report from nfe(4)/CS8201 user. > > > > Probably a little more work on the patches is needed? > > > > Yes, ciphy(4) should be educated to access magic registers. > > > I am offline for the next ten hours. After that I could test any new > > version ;-) > > > > I'll let you know if I have a patch for the watchdog errors. In these > days I have little time to focus on FreeBSD stuff so don't expect > quick reply. > Thank you very much for testing and your time. > > > Thank you very much, > > Rainer > > > -- > Regards, > Pyun YongHyeon -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 00:49:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66C1A16A400 for ; Sat, 31 Mar 2007 00:49:50 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE4213C44C for ; Sat, 31 Mar 2007 00:49:50 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HXRmj-0001vz-Ge; Fri, 30 Mar 2007 20:49:37 -0400 Message-ID: <460DB09A.7010609@metricsystems.com> Date: Fri, 30 Mar 2007 16:51:38 -0800 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Chuck Swiger References: <460D930B.1090309@metricsystems.com> <7A767421-261E-4EF2-824B-B0290C17C62E@mac.com> In-Reply-To: <7A767421-261E-4EF2-824B-B0290C17C62E@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: Building an /etc from scratch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2007 00:49:50 -0000 Chuck Swiger schrieb: > On Mar 30, 2007, at 3:45 PM, John Clark wrote: >> The doc for building the world indicate that the kernel and /etc are >> not build in the 'world' >> process. >> >> How does one create an /etc from src/etc. There does not seem to be a >> make target in >> the main Makefile at the top of the hierarchy. > > You might find mergemaster helpful 'mergemaster' seems to have gotten most of the things in the right place. The other wyrd problem I had was since I was booting off of a linux box using an nfs mounted root, there seems to be a problem with 'file locking' and 'pidfile_open'. In looking into it the linux box should have handled nfs file locking, but perhaps not. Also, as I'm using an nfs mounted file system for my 'root', there seems to be a problem with flock for the calls to 'pidfile_open' and perhaps other calls. Using 'rc.initdiskless' doesn't seem to over come these problems. Thanks, John Clark. From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 03:30:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 003EC16A402 for ; Sat, 31 Mar 2007 03:29:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id A801613C469 for ; Sat, 31 Mar 2007 03:29:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so583340nza for ; Fri, 30 Mar 2007 20:29:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Gxt2OU+mJ8LSURTPTwUrrJlQlFE/DvZLe3aAiSIpPBGkmNZzdWUNRWmiFWvkFFT9kKvuhmurDP74G/0yJAgmoioGow/qfocfOwkgfBEKBoXtl+/ZVvRoNmU4e9YhI4qWBYvJGYWMVP18XgKTwqeu95FyEP2ryWwXnRo/ThosRMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=eYAW94uHlIn/SIRiAKjG8rCLltnA2z8O/Un2su5Djy9r5V/cs3Dd0WIW4jH/GTGqdVhVR2+40uE3dHUOeNr8HtTQv0OLadlsQlyIQLX1BuAqXjBmet934Ij6Je283OA0nIBlMvtilUSkoY7pOFkLXSUp0mUjfG0yZo1YXdXp0Ko= Received: by 10.65.234.2 with SMTP id l2mr5310109qbr.1175311420043; Fri, 30 Mar 2007 20:23:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id c12sm12881343nzc.2007.03.30.20.23.37; Fri, 30 Mar 2007 20:23:39 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l2V3Nh6i069530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Mar 2007 12:23:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2V3NhIQ069529; Sat, 31 Mar 2007 12:23:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 31 Mar 2007 12:23:43 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070331032343.GC68853@cdnetworks.co.kr> References: <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070331003031.GB68853@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 03:30:00 -0000 [...] > > Would you try updated ciphy(4) patch? > I've got a successful report from nfe(4)/CS8201 user. > Oops, you can get the patch at the following URL. http://people.freebsd.org/~yongari/nfe/ciphy.patch -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 09:38:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BECB16A40B for ; Sat, 31 Mar 2007 09:38:09 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DEEF213C4C4 for ; Sat, 31 Mar 2007 09:38:08 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 31 Mar 2007 09:38:07 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp004) with SMTP; 31 Mar 2007 11:38:07 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1/bBq46KofbkoGSNf2YS6L5kY1INkr67fE5AKf0Pa u5pZt2Rz+VG+74 From: Stefan Ehmann To: Bruce Evans Date: Sat, 31 Mar 2007 11:37:57 +0200 User-Agent: KMail/1.9.6 References: <200703011612.07110.shoesoft@gmx.net> <200703021619.33755.shoesoft@gmx.net> <20070304230346.O7298@besplex.bde.org> In-Reply-To: <20070304230346.O7298@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311137.59128.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: notebook freezes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2007 09:38:09 -0000 On Sunday 04 March 2007 13:27:48 Bruce Evans wrote: > On Fri, 2 Mar 2007, Stefan Ehmann wrote: > > On Thursday 01 March 2007 16:12, Stefan Ehmann wrote: > >> My few days old -current freezes if I press Fn-F6 (this is the > >> combination to adjust display brightness) if I've done a suspend/resume > >> before. Directly after boot it works fine. > > > > ... > > So I did a binary search. > > > > src/sys/i386/isa/clock.c r1.231 causes my notebook to freeze. > > > > Reverting this change in a CURRENT from today fixes the problem. > > > > The notebook is still pingable in this state. I experienced some other > > random hangs recently but don't know yet if those are related. > > Oops. If suspend/resume clobbers the RTC state (which we already have code > to restore), then it can clobber the RTC index (which even the restoral > code assumes is unclobbered). Try this fix. > > %%% > Index: clock.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v > retrieving revision 1.234 > diff -u -2 -r1.234 clock.c > --- clock.c 4 Mar 2007 04:55:19 -0000 1.234 > +++ clock.c 4 Mar 2007 11:58:00 -0000 > @@ -580,4 +582,5 @@ > /* Restore all of the RTC's "status" (actually, control) registers. */ > /* XXX locking is needed for RTC access. */ > + rtc_reg = -1; > writertc(RTC_STATUSB, RTCSB_24HR); > writertc(RTC_STATUSA, rtc_statusa); > %%% For some odd reason, the problem has returned. I'm pretty sure that I've built a kernel shortly after your commit and it just worked fine. Now the problem persists when I build a kernel with sources from that date. I'm not aware of any big changes I made to my configuration. I checked that rtc_restore() gets called. Either I screwed up something last time or some changes in the userland expose a race (I only rebuilt kernel from older sources, not world). Backing out the changes made in 1.231 still fixes the problem. Stefan From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 15:06:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E5F16A404 for ; Sat, 31 Mar 2007 15:06:25 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACDB13C45A for ; Sat, 31 Mar 2007 15:06:25 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HXf50-0000WX-7c; Sat, 31 Mar 2007 17:01:22 +0200 Message-ID: <460E77BE.9090503@gwdg.de> Date: Sat, 31 Mar 2007 17:01:18 +0200 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070318) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> In-Reply-To: <20070331003031.GB68853@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 15:06:26 -0000 Thank you Pyun YongHyeon for the newest patch. I am running it with if_nfe.c and if_nfereg.h from 03/21/2007 and if_nfevar.h from 03/19/2007 on FreeBSD 7.0-CURRENT (i386) from today. boot -v gives me: nfe0: port 0xb000-0xb007 mem xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 miibus0: on nfe0 ciphy0: PHY 1 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:16:17:95:d9:7c nfe0: [MPSAFE] nfe0: [FILTER] Now there are no more warning from miibus0 :-) Unfortunately at bigger network transfers I still observe the previously described watchdog timeouts: nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering ... During these timeouts I am not able to use my network ;-( I would be happy if I could help solving this problem. Let me know if I can test anything. Thank you so long, Rainer Pyun YongHyeon schrieb: > On Tue, Mar 13, 2007 at 04:01:53PM +0900, To Rainer Hurling wrote: > > On Tue, Mar 13, 2007 at 06:29:25AM +0100, Rainer Hurling wrote: > > > Over night my systems works well, only one message from network came up: > > > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > > > > I'm not sure this watchdog is related with VSC8601 PHY. > > However Mr. Darren also reported watchdog errors on MCP55 so I have > > to think again what makes MCP55 different. > > > > > In the morning I tried your patch for mii and PHY. Bootingverbose again > > > gives me: > > > > > > nfe0: port 0xb000-0xb007 mem > > > 0xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > > > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > > > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > > > nfe0: bpf attached > > > nfe0: Ethernet address: 00:16:17:95:d9:7c > > > miibus0: on nfe0 > > > ciphy0: PHY 1 on miibus0 > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto > > > nfe0: [MPSAFE] > > > nfe0: [FILTER] > > > > > > > > > First, all seems to be ok. Network was up and connected. After a minute > > > I lost connection and the following messages appeared: > > > > > > miibus0: unknown CICADA PHY model 2 > > > miibus0: unknown CICADA PHY model 2 > > > miibus0: unknown CICADA PHY model 2 > > > > Sorry, you can ignore this. I've ommitted a code needed in fixup code > > for VSC8601. > > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > ... > > > > > > > This is real problem. I guess ciphy(4) failed to report correct link > > state so watchdog handler was activated. Apparently we **NEED** a copy > > of the documentation for the PHY. :-( > > You can revert the PHY changes and use ukphy(4) until the issue is > > resolved. > > > > Would you try updated ciphy(4) patch? > I've got a successful report from nfe(4)/CS8201 user. > > > > > > > Probably a little more work on the patches is needed? > > > > > > > Yes, ciphy(4) should be educated to access magic registers. > > > > > I am offline for the next ten hours. After that I could test any new > > > version ;-) > > > > > > > I'll let you know if I have a patch for the watchdog errors. In these > > days I have little time to focus on FreeBSD stuff so don't expect > > quick reply. > > Thank you very much for testing and your time. > > > > > Thank you very much, > > > Rainer > > > > > -- > > Regards, > > Pyun YongHyeon > From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 16:06:32 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8309316A40A for ; Sat, 31 Mar 2007 16:06:32 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCEF13C4C8 for ; Sat, 31 Mar 2007 16:06:31 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id B4F4338252 for ; Sat, 31 Mar 2007 18:06:30 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id E810B9CCB9 for ; Sat, 31 Mar 2007 16:06:27 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id C7ACA4065; Sat, 31 Mar 2007 18:06:27 +0200 (CEST) Date: Sat, 31 Mar 2007 18:06:27 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20070331160627.GC5704@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2007 16:06:32 -0000 Hi, I've set legal.intel_iwi.license_ack=1 in loader.conf(5) and tried to load if_iwi but I get the following message: % iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 % iwi0: using obsoleted if_watchdog interface % iwi0: Ethernet address: 00:12:f0:2c:f3:6e % iwi0: [ITHREAD] % iwi0: timeout waiting for iwi_bss firmware initialization to complete % iwi0: could not load boot firmware iwi_bss % iwi0: timeout waiting for iwi_bss firmware initialization to complete % iwi0: could not load boot firmware iwi_bss % iwi0: timeout waiting for iwi_bss firmware initialization to complete % iwi0: could not load boot firmware iwi_bss % in_delmulti_locked: purging ifma 0xc3caf420 % iwi0: timeout waiting for iwi_bss firmware initialization to complete % iwi0: could not load boot firmware iwi_bss jarjarbinks:~:105# kldstat | grep iwi 5 1 0xc4158000 30000 iwi_bss.ko 10 1 0xc4188000 e000 if_iwi.ko Help would be welcome. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 22:09:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BA6516A401; Sat, 31 Mar 2007 22:09:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E148A13C4B8; Sat, 31 Mar 2007 22:09:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l2VM6IiJ009348; Sat, 31 Mar 2007 16:06:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 31 Mar 2007 16:06:22 -0600 (MDT) Message-Id: <20070331.160622.-30982624.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20070324153108.P4956@fledge.watson.org> References: <20070324113739.GA41119@ravenloft.kiev.ua> <20070324135333.GA86105@FreeBSD.czest.pl> <20070324153108.P4956@fledge.watson.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) 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-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 31 Mar 2007 16:06:21 -0600 (MDT) Cc: spam@rm-rf.kiev.ua, freebsd-current@freebsd.org, wkoszek@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2007 22:09:08 -0000 In message: <20070324153108.P4956@fledge.watson.org> Robert Watson writes: : >> By the way, any plan to include INCLUDE_CONFIG_FILE in GENERIC? : > : > I'd like to have this enabled by default, and I know there should be no : > strong objections. : : I agree -- the memory used by it is very small compared to the amount of : memory in modern systems, and the potential administrative benefit is very : large. As long as it remains an option, the embedded folk can turn it off : easily. Agreed, with both my large system and embedded hats on :-) Warner From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 23:46:03 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4F5616A403; Sat, 31 Mar 2007 23:46:03 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 908E013C484; Sat, 31 Mar 2007 23:46:03 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 6F89D1A4DAC; Sat, 31 Mar 2007 16:46:03 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B9697515BC; Sat, 31 Mar 2007 19:46:02 -0400 (EDT) Date: Sat, 31 Mar 2007 19:46:02 -0400 From: Kris Kennaway To: John Baldwin Message-ID: <20070331234602.GB77982@xor.obsecurity.org> References: <200703312323.l2VNNgPb006391@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <200703312323.l2VNNgPb006391@repoman.freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: smp@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src/share/man/man9 Makefile sx.9 src/sys/conf NOTES options src/sys/dev/acpica acpi_ec.c src/sys/dev/mxge if_mxge.c src/sys/dev/usb if_aue.c if_axe.c src/sys/gnu/fs/xfs/FreeBSD/support mrlock.c mrlock.h ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 23:46:03 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable eOn Sat, Mar 31, 2007 at 11:23:42PM +0000, John Baldwin wrote: > jhb 2007-03-31 23:23:42 UTC >=20 > FreeBSD src repository >=20 > Modified files: > share/man/man9 Makefile sx.9=20 > sys/conf NOTES options=20 > sys/dev/acpica acpi_ec.c=20 > sys/dev/mxge if_mxge.c=20 > sys/dev/usb if_aue.c if_axe.c=20 > sys/gnu/fs/xfs/FreeBSD/support mrlock.c mrlock.h=20 > sys/i386/acpica acpi_machdep.c=20 > sys/kern kern_sx.c=20 > sys/netinet6 in6_src.c=20 > sys/sys sleepqueue.h sx.h=20 > Added files: > sys/sys _sx.h=20 > Log: > Optimize sx locks to use simple atomic operations for the common cases = of > obtaining and releasing shared and exclusive locks. The algorithms for > manipulating the lock cookie are very similar to that rwlocks. This pa= tch > also adds support for exclusive locks using the same algorithm as mutex= es. Thanks to Attilio for doing this work and to John for committing it. This is a significant step forward for 7.0 and will be the basis for some major performance optimizations to be committed in the near future (e.g. filedesc locking from rwatson, which gives even better mysql performance than the "tophalf" mutexes Jeff and I recently benchmarked). Kris --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGDvK6Wry0BWjoQKURAnsqAJ9TWPTb7EZP/OYHtF4om3oh+3RNPgCgoPlB a9jLMmS4wE0THGYG/i7vyMM= =8fSS -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--