From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 07:22:57 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F6B106566B; Sun, 13 Jul 2008 07:22:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 305088FC18; Sun, 13 Jul 2008 07:22:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 376B91CCA9; Sun, 13 Jul 2008 09:22:54 +0200 (CEST) Date: Sun, 13 Jul 2008 09:22:54 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Arch Message-ID: <20080713072254.GX14567@hoeg.nl> References: <20080702190901.GS14567@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/jamoCVtoCI0aYZY" Content-Disposition: inline In-Reply-To: <20080702190901.GS14567@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Marcel Moolenaar , Philip Paeps Subject: Re: MPSAFE TTY schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2008 07:22:57 -0000 --/jamoCVtoCI0aYZY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, * Ed Schouten wrote: > July 13 2008: > Make uart(4) the default serial port driver, instead of sio(4). > sio(4) has not been ported to the new TTY layer and is very hard > to do so. uart(4) has been proven to be more portable than > sio(4) and already supports the hardware we need. Just a small message to inform that I've just changed the default serial port driver on amd64 and i386 to uart(4) (see SVN commit 180487). I've decided to leave pc98 as it is now, because I'd rather let the respective maintainers look into this. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --/jamoCVtoCI0aYZY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh5rU4ACgkQ52SDGA2eCwX46QCfakX8RJ4yK4ruWLSlgswPxi5C vgUAnjFKJ0Sati8+XcaJ9Hydzqzo1asT =+8SM -----END PGP SIGNATURE----- --/jamoCVtoCI0aYZY-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 09:29:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B88C1065679; Sun, 13 Jul 2008 09:29:47 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0EABB8FC20; Sun, 13 Jul 2008 09:29:46 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m6D9TiJT061961; Sun, 13 Jul 2008 13:29:44 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 13 Jul 2008 13:29:44 +0400 (MSD) From: Dmitry Morozovsky To: Hans Petter Selasky In-Reply-To: <200807122249.03951.hselasky@c2i.net> Message-ID: <20080713132638.S58331@woozle.rinet.ru> References: <20080712204239.I58331@woozle.rinet.ru> <200807122249.03951.hselasky@c2i.net> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Sun, 13 Jul 2008 13:29:45 +0400 (MSD) Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: A bit of offtopic: msdosfs recovery tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2008 09:29:47 -0000 On Sat, 12 Jul 2008, Hans Petter Selasky wrote: HPS> > I have CF card which failed somewhere very close to the beginning; I did HPS> > copy by recoverdisk, and can find start of at least one of FAT copies HPS> > (though can't be sure of its consistency); I can't find root directory yet, HPS> > neither subdirs. HPS> > HPS> > So - it there any tool to automate/speed up such a process? HPS> HPS> You are fortunately not the first one into that water ;-) HPS> http://www.cgsecurity.org/wiki/PhotoRec HPS> HPS> We should have this in ports. It is a pretty good utility! Yes, it is bundled with sysutils/disktest. Actually, it recovers most of images perfectly - but only on second run, when I put cf image on tmpfs (!) On the first run, when image resides on ZFS, it locks up in zfs:lock somewhere in the middle, stumbling the whole machine :( I did not tried to reproduce the problem yet, though. Thank you for the tip! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 09:29:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B88C1065679; Sun, 13 Jul 2008 09:29:47 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0EABB8FC20; Sun, 13 Jul 2008 09:29:46 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m6D9TiJT061961; Sun, 13 Jul 2008 13:29:44 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 13 Jul 2008 13:29:44 +0400 (MSD) From: Dmitry Morozovsky To: Hans Petter Selasky In-Reply-To: <200807122249.03951.hselasky@c2i.net> Message-ID: <20080713132638.S58331@woozle.rinet.ru> References: <20080712204239.I58331@woozle.rinet.ru> <200807122249.03951.hselasky@c2i.net> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Sun, 13 Jul 2008 13:29:45 +0400 (MSD) Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: A bit of offtopic: msdosfs recovery tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2008 09:29:47 -0000 On Sat, 12 Jul 2008, Hans Petter Selasky wrote: HPS> > I have CF card which failed somewhere very close to the beginning; I did HPS> > copy by recoverdisk, and can find start of at least one of FAT copies HPS> > (though can't be sure of its consistency); I can't find root directory yet, HPS> > neither subdirs. HPS> > HPS> > So - it there any tool to automate/speed up such a process? HPS> HPS> You are fortunately not the first one into that water ;-) HPS> http://www.cgsecurity.org/wiki/PhotoRec HPS> HPS> We should have this in ports. It is a pretty good utility! Yes, it is bundled with sysutils/disktest. Actually, it recovers most of images perfectly - but only on second run, when I put cf image on tmpfs (!) On the first run, when image resides on ZFS, it locks up in zfs:lock somewhere in the middle, stumbling the whole machine :( I did not tried to reproduce the problem yet, though. Thank you for the tip! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 19:28:27 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 145BE106564A for ; Sun, 13 Jul 2008 19:28:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id C71FC8FC1A for ; Sun, 13 Jul 2008 19:28:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 0C32C1CC90; Sun, 13 Jul 2008 21:28:26 +0200 (CEST) Date: Sun, 13 Jul 2008 21:28:26 +0200 From: Ed Schouten To: FreeBSD Current Message-ID: <20080713192826.GA14567@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DNkN4mkbZBLvViAv" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: HEADS UP: sio(4) -> uart(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: Sun, 13 Jul 2008 19:28:27 -0000 --DNkN4mkbZBLvViAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello folks, This morning I sent the following message to this list. Unfortunately, I didn't put a big `HEADS UP' in the subject, so I'm resending this to make sure nobody misses: ----- Forwarded message from Ed Schouten ----- > Date: Sun, 13 Jul 2008 09:22:54 +0200 > From: Ed Schouten > To: FreeBSD Current , FreeBSD Arch > Cc: Philip Paeps , > Marcel Moolenaar > Subject: Re: MPSAFE TTY schedule >=20 > Hello all, >=20 > * Ed Schouten wrote: > > July 13 2008: > > Make uart(4) the default serial port driver, instead of sio(4). > > sio(4) has not been ported to the new TTY layer and is very hard > > to do so. uart(4) has been proven to be more portable than > > sio(4) and already supports the hardware we need. >=20 > Just a small message to inform that I've just changed the default serial > port driver on amd64 and i386 to uart(4) (see SVN commit 180487). I've > decided to leave pc98 as it is now, because I'd rather let the > respective maintainers look into this. >=20 > Thanks! >=20 > --=20 > Ed Schouten > WWW: http://80386.nl/ ----- End forwarded message ----- The commit in question: http://lists.freebsd.org/pipermail/cvs-src/2008-July/092923.html As you can see, I've changed the hints in /boot/device.hints to refer to uart(4) instead of sio(4). This means you may want to change sio to uart in your kernel configuration file. This is what I've added to /usr/src/UPDATING: | The sio(4) driver has been removed from the i386 and amd64 | kernel configuration files. This means uart(4) is now the | default serial port driver on those platforms as well. |=20 | To prevent collisions with the sio(4) driver, the uart(4) driver | uses different names for its device nodes. This means the | onboard serial port will now most likely be called "ttyu0" | instead of "ttyd0". You may need to reconfigure applications to | use the new device names. Even though I've got much confidence uart(4) works like it's supposed to do: if any problems arise, feel free to send us (Marcel and I) a message. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --DNkN4mkbZBLvViAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh6V1kACgkQ52SDGA2eCwUHbwCfcrMLFZv5OlcvgV3gp2wYlFlE WNgAnil80UHQibwyxmOHG83uGXaORxSh =GWf5 -----END PGP SIGNATURE----- --DNkN4mkbZBLvViAv-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 22:17:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50DD1065676 for ; Sun, 13 Jul 2008 22:17:47 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3E68FC08 for ; Sun, 13 Jul 2008 22:17:47 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.2/8.14.2) with ESMTP id m6DLtjog001741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Jul 2008 14:55:45 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200807132155.m6DLtjog001741@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Jul 2008 14:55:40 -0700 To: Ed Schouten , FreeBSD Current From: Manfred Antar In-Reply-To: <20080713192826.GA14567@hoeg.nl> References: <20080713192826.GA14567@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on pozo.com X-Virus-Status: Clean Cc: Subject: Re: HEADS UP: sio(4) -> uart(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: Sun, 13 Jul 2008 22:17:48 -0000 At 12:28 PM 7/13/2008, Ed Schouten wrote: >*** PGP SIGNATURE VERIFICATION *** >*** Status: Good Signature from Invalid Key >*** Alert: Please verify signer's key before trusting signature. >*** Signer: Ed Schouten (0x0D9E0B05) >*** Signed: 7/13/2008 12:28:25 PM >*** Verified: 7/13/2008 12:39:57 PM >*** BEGIN PGP VERIFIED MESSAGE *** > >Hello folks, > >This morning I sent the following message to this list. Unfortunately, I >didn't put a big `HEADS UP' in the subject, so I'm resending this to >make sure nobody misses: > >----- Forwarded message from Ed Schouten ----- >> Date: Sun, 13 Jul 2008 09:22:54 +0200 >> From: Ed Schouten >> To: FreeBSD Current , FreeBSD Arch >> Cc: Philip Paeps , >> Marcel Moolenaar >> Subject: Re: MPSAFE TTY schedule >> >> Hello all, >> >> * Ed Schouten wrote: >> > July 13 2008: >> > Make uart(4) the default serial port driver, instead of sio(4). >> > sio(4) has not been ported to the new TTY layer and is very hard >> > to do so. uart(4) has been proven to be more portable than >> > sio(4) and already supports the hardware we need. >> >> Just a small message to inform that I've just changed the default serial >> port driver on amd64 and i386 to uart(4) (see SVN commit 180487). I've >> decided to leave pc98 as it is now, because I'd rather let the >> respective maintainers look into this. >> >> Thanks! >> >> -- >> Ed Schouten >> WWW: http://80386.nl/ >----- End forwarded message ----- > >The commit in question: > > http://lists.freebsd.org/pipermail/cvs-src/2008-July/092923.html > >As you can see, I've changed the hints in /boot/device.hints to refer to >uart(4) instead of sio(4). This means you may want to change sio to uart >in your kernel configuration file. This is what I've added to >/usr/src/UPDATING: > >| The sio(4) driver has been removed from the i386 and amd64 >| kernel configuration files. This means uart(4) is now the >| default serial port driver on those platforms as well. >| >| To prevent collisions with the sio(4) driver, the uart(4) driver >| uses different names for its device nodes. This means the >| onboard serial port will now most likely be called "ttyu0" >| instead of "ttyd0". You may need to reconfigure applications to >| use the new device names. > >Even though I've got much confidence uart(4) works like it's supposed to >do: if any problems arise, feel free to send us (Marcel and I) a >message. Thanks! Machine is i386 pentium 4 I'm using a terminal off of com port 1 I changed the ttyd0 to ttyu0 in /etc/ttys rebuilt /sys/boot and kernel. But now I have no comconsole When the machine boots I get : the loader message, but no more I also use the console for the kernel debugger Don't even get a login prompt on it Any Ideas Thanks Manfred ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 22:54:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71EAD106564A for ; Sun, 13 Jul 2008 22:54:57 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id 5925D8FC20 for ; Sun, 13 Jul 2008 22:54:57 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.102] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K3Y003OXVN4FK20@asmtp013.mac.com> for current@freebsd.org; Sun, 13 Jul 2008 15:54:42 -0700 (PDT) Sender: xcllnt@mac.com Message-id: <9839B5B3-9568-4B64-8CC0-05B64F66A2C0@mac.com> From: Marcel Moolenaar To: Manfred Antar In-reply-to: <200807132155.m6DLtjog001741@pozo.com> Date: Sun, 13 Jul 2008 15:54:40 -0700 References: <20080713192826.GA14567@hoeg.nl> <200807132155.m6DLtjog001741@pozo.com> X-Mailer: Apple Mail (2.928.1) Cc: Ed Schouten , FreeBSD Current Subject: Re: HEADS UP: sio(4) -> uart(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: Sun, 13 Jul 2008 22:54:57 -0000 On Jul 13, 2008, at 2:55 PM, Manfred Antar wrote: > Machine is i386 pentium 4 > I'm using a terminal off of com port 1 > I changed the ttyd0 to ttyu0 in /etc/ttys > rebuilt /sys/boot and kernel. > But now I have no comconsole > When the machine boots I get : > the loader message, but no more > I also use the console for the kernel debugger > Don't even get a login prompt on it > Any Ideas Did you change /boot/device.hints? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 23:24:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554DF106567B; Sun, 13 Jul 2008 23:24:40 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA3C8FC14; Sun, 13 Jul 2008 23:24:39 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id A9B6E2DA40E; Sun, 13 Jul 2008 23:06:03 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id D993A114C4; Mon, 14 Jul 2008 01:06:35 +0200 (CEST) Date: Mon, 14 Jul 2008 01:06:35 +0200 From: "Simon L. Nielsen" To: Stefan Farfeleder , freebsd-current@freebsd.org Message-ID: <20080713230635.GC15766@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: [patch] segfault in sh for bogus redirection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2008 23:24:40 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Stefan (and other people familiar with the sh(1) code), I stumbled on a corner case bug in sh(1) where it segfaults instead of giving a proper error message. This only happens when you do something stupid, but I thought it should be fixed anyway. When you redirect to an unset or empty variable things fail: $ sh -c 'echo 1 >&$a' Segmentation fault (core dumped) With patch: $ sh -c 'echo 1 >&$a' Syntax error: Bad fd number I have made a patch which fixes the issue (attached) so it fails normally with an error, but I'm not sure if it's the right way of fixing it. Do you think this fix is OK, or is there a better way to do this? I also included a regression test to check for the problem. -- Simon L. Nielsen --VbJkn9YxBvnuCH5J Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sh-redir-segv-0.patch" Index: bin/sh/parser.c =================================================================== --- bin/sh/parser.c (revision 180502) +++ bin/sh/parser.c (working copy) @@ -620,9 +620,9 @@ if (!err) n->ndup.vname = NULL; - if (is_digit(text[0]) && text[1] == '\0') + if (text != NULL && is_digit(text[0]) && text[1] == '\0') n->ndup.dupfd = digit_val(text[0]); - else if (text[0] == '-' && text[1] == '\0') + else if (text != NULL && text[0] == '-' && text[1] == '\0') n->ndup.dupfd = -1; else { Index: tools/regression/bin/sh/errors/redirection-error.2 =================================================================== --- tools/regression/bin/sh/errors/redirection-error.2 (revision 0) +++ tools/regression/bin/sh/errors/redirection-error.2 (revision 0) @@ -0,0 +1,4 @@ +# $FreeBSD$ + +# sh should fail gracefully on this bad redirect +sh -c 'echo 1 >&$a' 2>/dev/null --VbJkn9YxBvnuCH5J-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 13 23:58:54 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 488A51065671 for ; Sun, 13 Jul 2008 23:58:54 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3FE8FC08 for ; Sun, 13 Jul 2008 23:58:53 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.2/8.14.2) with ESMTP id m6DNwXmm007928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Jul 2008 16:58:33 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200807132358.m6DNwXmm007928@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Jul 2008 16:58:28 -0700 To: Marcel Moolenaar From: Manfred Antar In-Reply-To: <9839B5B3-9568-4B64-8CC0-05B64F66A2C0@mac.com> References: <20080713192826.GA14567@hoeg.nl> <200807132155.m6DLtjog001741@pozo.com> <9839B5B3-9568-4B64-8CC0-05B64F66A2C0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on pozo.com X-Virus-Status: Clean Cc: Ed Schouten , FreeBSD Current Subject: Re: HEADS UP: sio(4) -> uart(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: Sun, 13 Jul 2008 23:58:54 -0000 At 03:54 PM 7/13/2008, Marcel Moolenaar wrote: >On Jul 13, 2008, at 2:55 PM, Manfred Antar wrote: > >>Machine is i386 pentium 4 >>I'm using a terminal off of com port 1 >>I changed the ttyd0 to ttyu0 in /etc/ttys >>rebuilt /sys/boot and kernel. >>But now I have no comconsole >>When the machine boots I get : >>the loader message, but no more >>I also use the console for the kernel debugger >>Don't even get a login prompt on it >>Any Ideas > >Did you change /boot/device.hints? > >-- >Marcel Moolenaar >xcllnt@mac.com > Yes, and it's working now . Thanks ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 01:37:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA8B0106566B for ; Mon, 14 Jul 2008 01:37:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA048FC1C for ; Mon, 14 Jul 2008 01:37:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5679903rvf.43 for ; Sun, 13 Jul 2008 18:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=q68BACj1oIH9XVsuDSAzwwJLLk1yZ0lJMqvdtE4W1Z8=; b=dsKv5fkz+zkBtfDwagGhY8lVNx7VhqA8enxjHPLsTw26d27w7rgmzXfu+uoi/CJVOY iILCJT9rQ8VqTsbaAw6a6tkzrUEW6pnTg2ibA53EJsMMSoWn1Stuwil1L7LpUpB5+m1H 2lbjupqvCqM13ro1SCo7Oc6OrTJmiHoidUAjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fStb/p8e6bDA7JEMzT5fKjzurypMThXv0AUcaCF+wji81CQtN/dzcvxWetLlZ7wpmP bR8TKTW1H/rmysQ94zw4CD/e4sDD/tvzcEkqsdDjqAhJMXldtR4KGbI/OBlifPw9H7fv 51GdwIIy+FFNFHfLb9pVnIjBB6yIJKh1sWDuk= Received: by 10.141.161.6 with SMTP id n6mr6206094rvo.41.1215999451083; Sun, 13 Jul 2008 18:37:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b8sm7158724rvf.9.2008.07.13.18.37.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Jul 2008 18:37: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 m6E1ZKho036746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 10:35:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m6E1ZJkG036745; Mon, 14 Jul 2008 10:35:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 14 Jul 2008 10:35:19 +0900 From: Pyun YongHyeon To: Dimitry Andric Message-ID: <20080714013519.GE36245@cdnetworks.co.kr> References: <484BC9FB.2040605@andric.com> <20080609012657.GD12521@cdnetworks.co.kr> <484D215A.7050700@andric.com> <20080609123206.GF12521@cdnetworks.co.kr> <484D25CC.9050106@andric.com> <20080610050550.GB17874@cdnetworks.co.kr> <484E9377.2050609@andric.com> <20080611005814.GA3529@cdnetworks.co.kr> <48666CD7.9020706@andric.com> <20080630043156.GB79537@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630043156.GB79537@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: re(4) and RTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2008 01:37:32 -0000 On Mon, Jun 30, 2008 at 01:31:56PM +0900, To Dimitry Andric wrote: > On Sat, Jun 28, 2008 at 06:54:47PM +0200, Dimitry Andric wrote: > > On 2008-06-11 02:58, Pyun YongHyeon wrote: > > > > This seems to work better, although it still takes quite some time > > > > (~10s) for the interfaces to go up at boot time. I haven't yet been > > > > able to get them "stuck", however, so that's good. :) > > > Hmm, that's interesting. Can you spot where re(4) spends its time? > > > Did RELENG_7 also have this issue? > > > > Apparently it's experiencing timeouts, I usually get these: > > > > re0: link state changed to DOWN > > re0: watchdog timeout > ^^^^^^^^^^^^^^^^ > Because link state changed to DOWN re(4) should not queue > transmitting packets anymore until it get a valid link. Trying to > send further packets would cause watchdong timeouts as above. > This indicates re(4) failed to detect link loss event. > What makes me wonder is why the link state was changed to DOWN. > Do you have a clue(e.g. switching hub down etc)? > > > re0: 3 link states coalesced > ^^^^^^^^^^^^^^^^^^^^^^^ > > Hmm, I guess you've encountered another bug. The link states > coalescing message indicates a bug in PHY driver and link state > handling of re(4). ATM the link state handling of re(4) is in very > bad state and it doesn't correctly drive MII_TICK. re(4) just relys > on link status change interrupt of controller but re(4) failed to > determine what's current link event is for (The event could be link > up or down or auto-negotiation complete etc). In addition, all > RealTek controllers lack proper programming interface to tell MAC > negotiated speed/duplex/flow-controls which in turn taking proper > action to the event very hard. > > I guess re(4) should not rely on link status change interrupt but > it should fall back to traditional polling mechanism which will > enable correct tracking of link establishment. Also the link up/ > down handling should be changed to process mii(4) posted events. > All these change requires a lot of code change and needs more > testing. I think I may have to commit accumulated patches for newer > RTL8168 family before going to that direction. The patch is not > perfect to address all issues for RTL8168 family but it allows > recognition of the new hardware and make it usable in most cases. > > > re0: link state changed to UP > > re1: link state changed to DOWN > > > > I've been running all tests under RELENG_7, btw. Note also, these > > delays don't always happen, in some cases the interfaces react very > > quickly. In rare cases, they don't work at all, until you manually > > ifconfig down and up them a few times. > > > > What's funny though, is that the interfaces seem to start in DOWN mode: > > > > [...booting...] > > Mounting local file systems:. > > Setting hostname: tensor.andric.com. > > re0: link state changed to DOWN > > re1: link state changed to DOWN > > lo0: flags=8049 metric 0 mtu 16384 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet 127.0.0.1 netmask 0xff000000 > > re0: flags=8843 metric 0 mtu 1500 > > options=399b > > ether 00:30:18:a6:f1:a8 > > inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1 > > inet 87.251.56.140 netmask 0xffffffc0 broadcast 87.251.56.191 > > media: Ethernet autoselect (none) > > status: no carrier > > re1: flags=8843 metric 0 mtu 1500 > > options=399b > > ether 00:30:18:a6:f1:a9 > > inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2 > > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect (none) > > status: no carrier > > [...more initialization...] > > net.inet6.ip6.forwarding: 0 -> 1 > > net.inet6.ip6.accept_rtadv: 0 -> 0 > > re0: link state changed to UP > > re1: link state changed to UP > > > > and only then do they "really" go up... :) > > > > I can't sure due to bugs in link state handling in driver but > generally it's normal. Establishing a link with link partner takes > time and sometimes it would even take 10 seconds or more. > > > Do you have any good suggestions on where I could put some debug > > printfs in re to find out what it's timing out on? > > > > Before doing that it would be more appropriate to fix link state > handing in driver. I'll let you know when I have a patch for link > handling clean-up. > Here is patch for re(4) link handling. Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply attached one. If you still see watchdog timeouts, please turn off TSO and let me know how it goes. One user reported TSO issues on 8169 family controllers but I can't reproduce this on my 8169 hardware so it could be related with silicon bug of sepecific revision of the hardware. > > > > > Plugging/unplugging UTP cable to ethernet controller during boot > > > change the long delay? How about disabling WOL before system > > > shutdown?(e.g. ifconfig re0 -wol) > > > > Plugging/unplugging the cable doesn't seem to make much difference, and > > neither does disabling WOL before shutdown (or altogether)... > > > > Ok. > > Thanks for reporting. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 01:38:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12ADD1065670 for ; Mon, 14 Jul 2008 01:38:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id C6A618FC1E for ; Mon, 14 Jul 2008 01:38:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5680303rvf.43 for ; Sun, 13 Jul 2008 18:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=g+chVkL4q1cMiOFIy6VapaBATN00baYn2HAEHunftRI=; b=Tz9zCzYJBB02/UHl3AvbjWqUyz7rGoRRpTJZ+wU7NQW12810txqfraSOpkdcMo3eGJ EjA7khPQ5vApWz8xgIRQ03WjIq5hQVbEt2KYTa1a1l1jM5opUQdXz7rbi7qMN0r2rgxH A83zsFUMGCds5Nr9PPvhQ7cJaNO82wLH7rFRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=n2pbuNhGQGchqrjEZJYJK/E5ChVDHAEKo1Po7cGJSTPDdJRPVgYM9aG2u3X5MJ0Vta BE9rPsblF7YQEP32Skamg4C6Q1gbqgIfm34xzP7OA3hRnzmFq/NDvpG4L9XFZfMxvAoB Z7gQt1OXNjJO45Dcd4oEAOMpHKggNGXDIAhak= Received: by 10.140.203.9 with SMTP id a9mr6208895rvg.288.1215999532854; Sun, 13 Jul 2008 18:38:52 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b39sm6980131rvf.8.2008.07.13.18.38.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Jul 2008 18:38:51 -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 m6E1agHP036762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 10:36:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m6E1agj5036761; Mon, 14 Jul 2008 10:36:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 14 Jul 2008 10:36:42 +0900 From: Pyun YongHyeon To: Dimitry Andric Message-ID: <20080714013642.GF36245@cdnetworks.co.kr> References: <20080609012657.GD12521@cdnetworks.co.kr> <484D215A.7050700@andric.com> <20080609123206.GF12521@cdnetworks.co.kr> <484D25CC.9050106@andric.com> <20080610050550.GB17874@cdnetworks.co.kr> <484E9377.2050609@andric.com> <20080611005814.GA3529@cdnetworks.co.kr> <48666CD7.9020706@andric.com> <20080630043156.GB79537@cdnetworks.co.kr> <20080714013519.GE36245@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20080714013519.GE36245@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: re(4) and RTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2008 01:38:54 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 14, 2008 at 10:35:19AM +0900, To Dimitry Andric wrote: > On Mon, Jun 30, 2008 at 01:31:56PM +0900, To Dimitry Andric wrote: > > On Sat, Jun 28, 2008 at 06:54:47PM +0200, Dimitry Andric wrote: > > > On 2008-06-11 02:58, Pyun YongHyeon wrote: > > > > > This seems to work better, although it still takes quite some time > > > > > (~10s) for the interfaces to go up at boot time. I haven't yet been > > > > > able to get them "stuck", however, so that's good. :) > > > > Hmm, that's interesting. Can you spot where re(4) spends its time? > > > > Did RELENG_7 also have this issue? > > > > > > Apparently it's experiencing timeouts, I usually get these: > > > > > > re0: link state changed to DOWN > > > re0: watchdog timeout > > ^^^^^^^^^^^^^^^^ > > Because link state changed to DOWN re(4) should not queue > > transmitting packets anymore until it get a valid link. Trying to > > send further packets would cause watchdong timeouts as above. > > This indicates re(4) failed to detect link loss event. > > What makes me wonder is why the link state was changed to DOWN. > > Do you have a clue(e.g. switching hub down etc)? > > > > > re0: 3 link states coalesced > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > > Hmm, I guess you've encountered another bug. The link states > > coalescing message indicates a bug in PHY driver and link state > > handling of re(4). ATM the link state handling of re(4) is in very > > bad state and it doesn't correctly drive MII_TICK. re(4) just relys > > on link status change interrupt of controller but re(4) failed to > > determine what's current link event is for (The event could be link > > up or down or auto-negotiation complete etc). In addition, all > > RealTek controllers lack proper programming interface to tell MAC > > negotiated speed/duplex/flow-controls which in turn taking proper > > action to the event very hard. > > > > I guess re(4) should not rely on link status change interrupt but > > it should fall back to traditional polling mechanism which will > > enable correct tracking of link establishment. Also the link up/ > > down handling should be changed to process mii(4) posted events. > > All these change requires a lot of code change and needs more > > testing. I think I may have to commit accumulated patches for newer > > RTL8168 family before going to that direction. The patch is not > > perfect to address all issues for RTL8168 family but it allows > > recognition of the new hardware and make it usable in most cases. > > > > > re0: link state changed to UP > > > re1: link state changed to DOWN > > > > > > I've been running all tests under RELENG_7, btw. Note also, these > > > delays don't always happen, in some cases the interfaces react very > > > quickly. In rare cases, they don't work at all, until you manually > > > ifconfig down and up them a few times. > > > > > > What's funny though, is that the interfaces seem to start in DOWN mode: > > > > > > [...booting...] > > > Mounting local file systems:. > > > Setting hostname: tensor.andric.com. > > > re0: link state changed to DOWN > > > re1: link state changed to DOWN > > > lo0: flags=8049 metric 0 mtu 16384 > > > inet6 ::1 prefixlen 128 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > > inet 127.0.0.1 netmask 0xff000000 > > > re0: flags=8843 metric 0 mtu 1500 > > > options=399b > > > ether 00:30:18:a6:f1:a8 > > > inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1 > > > inet 87.251.56.140 netmask 0xffffffc0 broadcast 87.251.56.191 > > > media: Ethernet autoselect (none) > > > status: no carrier > > > re1: flags=8843 metric 0 mtu 1500 > > > options=399b > > > ether 00:30:18:a6:f1:a9 > > > inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2 > > > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > > > media: Ethernet autoselect (none) > > > status: no carrier > > > [...more initialization...] > > > net.inet6.ip6.forwarding: 0 -> 1 > > > net.inet6.ip6.accept_rtadv: 0 -> 0 > > > re0: link state changed to UP > > > re1: link state changed to UP > > > > > > and only then do they "really" go up... :) > > > > > > > I can't sure due to bugs in link state handling in driver but > > generally it's normal. Establishing a link with link partner takes > > time and sometimes it would even take 10 seconds or more. > > > > > Do you have any good suggestions on where I could put some debug > > > printfs in re to find out what it's timing out on? > > > > > > > Before doing that it would be more appropriate to fix link state > > handing in driver. I'll let you know when I have a patch for link > > handling clean-up. > > > > Here is patch for re(4) link handling. > Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply > attached one. If you still see watchdog timeouts, please turn off > TSO and let me know how it goes. > One user reported TSO issues on 8169 family controllers but I > can't reproduce this on my 8169 hardware so it could be related > with silicon bug of sepecific revision of the hardware. Forgot to attach patch. Here we go. > > > > > > > > Plugging/unplugging UTP cable to ethernet controller during boot > > > > change the long delay? How about disabling WOL before system > > > > shutdown?(e.g. ifconfig re0 -wol) > > > > > > Plugging/unplugging the cable doesn't seem to make much difference, and > > > neither does disabling WOL before shutdown (or altogether)... > > > > > > > Ok. > > > > Thanks for reporting. -- Regards, Pyun YongHyeon --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.link.patch3" Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 180504) +++ sys/pci/if_rlreg.h (working copy) @@ -839,6 +839,7 @@ #define RL_FLAG_PAR 0x0020 #define RL_FLAG_DESCV2 0x0040 #define RL_FLAG_MACSTAT 0x0080 +#define RL_FLAG_FASTETHER 0x0100 #define RL_FLAG_LINK 0x8000 }; Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 180504) +++ sys/dev/re/if_re.c (working copy) @@ -596,7 +596,38 @@ re_miibus_statchg(dev) device_t dev; { + struct rl_softc *sc; + struct ifnet *ifp; + struct mii_data *mii; + sc = device_get_softc(dev); + mii = device_get_softc(sc->rl_miibus); + ifp = sc->rl_ifp; + if (mii == NULL || ifp == NULL || + (ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; + + sc->rl_flags &= ~RL_FLAG_LINK; + if ((mii->mii_media_status & IFM_AVALID) != 0) { + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_10_T: + case IFM_100_TX: + sc->rl_flags |= RL_FLAG_LINK; + break; + case IFM_1000_T: + if ((sc->rl_flags & RL_FLAG_FASTETHER) != 0) + break; + sc->rl_flags |= RL_FLAG_LINK; + break; + default: + break; + } + } + /* + * RealTek controllers does not provide any interface to + * Tx/Rx MACs for resolved speed, duplex and flow-control + * parameters. + */ } /* @@ -1238,17 +1269,18 @@ switch (hw_rev->rl_rev) { case RL_HWREV_8139CPLUS: - sc->rl_flags |= RL_FLAG_NOJUMBO; + sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_FASTETHER; break; case RL_HWREV_8100E: case RL_HWREV_8101E: sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | - RL_FLAG_PHYWAKE; + RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER; break; case RL_HWREV_8102E: case RL_HWREV_8102EL: sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | - RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; + RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | + RL_FLAG_FASTETHER; break; case RL_HWREV_8168_SPIN1: case RL_HWREV_8168_SPIN2: @@ -2049,30 +2081,14 @@ { struct rl_softc *sc; struct mii_data *mii; - struct ifnet *ifp; sc = xsc; - ifp = sc->rl_ifp; RL_LOCK_ASSERT(sc); - re_watchdog(sc); - mii = device_get_softc(sc->rl_miibus); mii_tick(mii); - if ((sc->rl_flags & RL_FLAG_LINK) != 0) { - if (!(mii->mii_media_status & IFM_ACTIVE)) - sc->rl_flags &= ~RL_FLAG_LINK; - } else { - if (mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->rl_flags |= RL_FLAG_LINK; - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - taskqueue_enqueue_fast(taskqueue_fast, - &sc->rl_txtask); - } - } - + re_watchdog(sc); callout_reset(&sc->rl_stat_callout, hz, re_tick, sc); } @@ -2189,11 +2205,6 @@ re_init_locked(sc); } - if (status & RL_ISR_LINKCHG) { - callout_stop(&sc->rl_stat_callout); - re_tick(sc); - } - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask); @@ -2698,14 +2709,15 @@ { struct rl_softc *sc; struct mii_data *mii; + int error; sc = ifp->if_softc; mii = device_get_softc(sc->rl_miibus); RL_LOCK(sc); - mii_mediachg(mii); + error = mii_mediachg(mii); RL_UNLOCK(sc); - return (0); + return (error); } /* @@ -2856,6 +2868,7 @@ re_watchdog(sc) struct rl_softc *sc; { + struct ifnet *ifp; RL_LOCK_ASSERT(sc); @@ -2863,11 +2876,14 @@ return; device_printf(sc->rl_dev, "watchdog timeout\n"); - sc->rl_ifp->if_oerrors++; + ifp = sc->rl_ifp; + ifp->if_oerrors++; re_txeof(sc); re_rxeof(sc); re_init_locked(sc); + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + taskqueue_enqueue_fast(taskqueue_fast, &sc->rl_txtask); } /* --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 10:33:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2AF8106564A; Mon, 14 Jul 2008 10:33:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id 602C28FC1D; Mon, 14 Jul 2008 10:33:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id A228543BB1B; Mon, 14 Jul 2008 12:34:22 +0200 (CEST) Received: from localhost (unknown [192.168.1.157]) by mail.m-online.net (Postfix) with ESMTP id A9EC2907A8; Mon, 14 Jul 2008 12:33:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from localhost ([192.168.3.149]) by localhost (scanner1.m-online.net [192.168.1.157]) (amavisd-new, port 10024) with ESMTP id kIz+9vI7P1LK; Mon, 14 Jul 2008 12:33:46 +0200 (CEST) Received: from mail.reifenberger.com (ppp-88-217-69-59.dynamic.mnet-online.de [88.217.69.59]) by mail.mnet-online.de (Postfix) with ESMTP; Mon, 14 Jul 2008 12:33:46 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 0DED12751; Mon, 14 Jul 2008 12:33:46 +0200 (CEST) Date: Mon, 14 Jul 2008 12:33:45 +0200 From: Michael Reifenberger To: Pawel Jakub Dawidek Message-ID: <20080714103345.GA11903@gw.reifenberger.com> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080706115414.GA20076@gw.reifenberger.com> <20080706234231.3d18e15a@baby-jane-lamaiziere-net.local> <20080714070622.GB13560@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080714070622.GB13560@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i Priority: normal Cc: Patrick Lamaizi?re , current@freebsd.org Subject: Re: AMD Geode LX crypto accelerator (glxsb) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2008 10:33:49 -0000 On Mon, Jul 14, 2008 at 09:06:22AM +0200, Pawel Jakub Dawidek wrote: > On Sun, Jul 06, 2008 at 11:42:31PM +0200, Patrick Lamaizi?re wrote: > > Le Sun, 6 Jul 2008 13:54:14 +0200, > > Michael Reifenberger a crit : > > > > Hi, > > ... > > Pawel Jakub Dawidek proposed to look and commit it when it will be > > ready. A lot of code comes from padlock(4) so may be it's better if the > > author can rewiew the code. > > > > I think that the driver is ready and works fine, i didn't change > > anything since the latest version "22/06/08" > > http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz > > > > It is not clear if i shall provide a patch against HEAD or > > do something else ? ... > I'm afraid I won't be able to commit it as my Soekris box died... > Have you looked at the sources allready? -- Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 23:40:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30544106567F; Mon, 14 Jul 2008 23:40:57 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 097A38FC13; Mon, 14 Jul 2008 23:40:56 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m6ENDY6T009468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 19:13:34 -0400 (EDT) (envelope-from rnoland@2hip.net) From: Robert Noland To: d@delphij.net In-Reply-To: <4872703B.9060408@delphij.net> References: <4872703B.9060408@delphij.net> Content-Type: text/plain Organization: 2Hip Networks Date: Mon, 14 Jul 2008 19:13:28 -0400 Message-Id: <1216077208.10267.17.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: FreeBSD Current , ariff@FreeBSD.org Subject: Re: [PATCH] Support for Dell D630 sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2008 23:40:57 -0000 On Mon, 2008-07-07 at 12:36 -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Ariff, > > A friend of mine recently bought a Dell D630 and found that the audio > part does not work. I have put together this patch which allows the > audio to work. Could you or may I commit against -HEAD? (A MFC of hda > related stuff would be required for RELENG_7 to work with it) I've also confirmed that this works for me on my D630. If we don't hear from Ariff soon, would someone please commit. robert. -- Robert Noland 2Hip Networks From owner-freebsd-current@FreeBSD.ORG Mon Jul 14 23:57:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BEF6106568E for ; Mon, 14 Jul 2008 23:57:59 +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 CA1B98FC1C for ; Mon, 14 Jul 2008 23:57:58 +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 (DSTO/DSTO) with ESMTP id m6ENvCCj021931 for ; Tue, 15 Jul 2008 09:27:12 +0930 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Tue, 15 Jul 2008 09:27:54 +0930 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 09:57:52 +1000 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by stlex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 07:57:50 +0800 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.2/8.14.2) with ESMTP id m6ENug0E060764 for ; Tue, 15 Jul 2008 07:56:42 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.2/8.14.2/Submit) id m6ENugwn060763 for freebsd-current@freebsd.org; Tue, 15 Jul 2008 07:56:42 +0800 (WST) (envelope-from wilkinsa) Date: Tue, 15 Jul 2008 07:56:42 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20080714235642.GP53741@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20080712204239.I58331@woozle.rinet.ru> <200807122249.03951.hselasky@c2i.net> <20080713132638.S58331@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20080713132638.S58331@woozle.rinet.ru> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 14 Jul 2008 23:57:50.0894 (UTC) FILETIME=[6C79BCE0:01C8E60D] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.5.1027-16030.007 X-TM-AS-Result: No--3.298000-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: A bit of offtopic: msdosfs recovery tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2008 23:57:59 -0000 0n Sun, Jul 13, 2008 at 01:29:44PM +0400, Dmitry Morozovsky wrote: >Yes, it is bundled with sysutils/disktest. sysutils/disktest/ ? According to http://www.freshports.org/ sysutils/disktest/ doesn't exist ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 02:36:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D570E1065675; Tue, 15 Jul 2008 02:36:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 854AB8FC14; Tue, 15 Jul 2008 02:36:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 77A0C28448; Tue, 15 Jul 2008 10:36:33 +0800 (CST) Received: from localhost (unknown [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3F644EB58CF; Tue, 15 Jul 2008 10:36:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 7J1EMWKmbYvI; Tue, 15 Jul 2008 10:36:21 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 389D8EB58CD; Tue, 15 Jul 2008 10:36:19 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=X0SREZG9UKvGdlPh3douSYCm2uqh45OKut9kbAwPWjeK0nXVnFKweOP4+Ng80xszY KTDiv3jrdGsB9IlafxsVw== Message-ID: <487C0D22.6050903@delphij.net> Date: Mon, 14 Jul 2008 19:36:18 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Robert Noland References: <4872703B.9060408@delphij.net> <1216077208.10267.17.camel@squirrel.corp.cox.com> In-Reply-To: <1216077208.10267.17.camel@squirrel.corp.cox.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , d@delphij.net, ariff@FreeBSD.org Subject: Re: [PATCH] Support for Dell D630 sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2008 02:36:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Noland wrote: | On Mon, 2008-07-07 at 12:36 -0700, Xin LI wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Hi, Ariff, |> |> A friend of mine recently bought a Dell D630 and found that the audio |> part does not work. I have put together this patch which allows the |> audio to work. Could you or may I commit against -HEAD? (A MFC of hda |> related stuff would be required for RELENG_7 to work with it) | | I've also confirmed that this works for me on my D630. If we don't hear | from Ariff soon, would someone please commit. I have received Ariff's approval and has just committed the changeset as 180532, FYI. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh8DSEACgkQi+vbBBjt66AQzACfTa6qLZIOTJ2bJG1cw7PO1mpP 64UAnignbX3rEBrFYiKsAev84d8Reoq3 =2nER -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 03:09:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09B50106564A for ; Tue, 15 Jul 2008 03:09:23 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtai105.cox.net (eastrmmtai105.cox.net [68.230.240.12]) by mx1.freebsd.org (Postfix) with ESMTP id 98C368FC23 for ; Tue, 15 Jul 2008 03:09:22 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080715025623.MHUZ2096.eastrmmtao104.cox.net@eastrmimpo02.cox.net>; Mon, 14 Jul 2008 22:56:23 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo02.cox.net with bizsmtp id q2wN1Z00E4iy4EG022wNpb; Mon, 14 Jul 2008 22:56:22 -0400 Date: Mon, 14 Jul 2008 21:56:26 -0500 To: "Wilkinson, Alex" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <20080712204239.I58331@woozle.rinet.ru> <200807122249.03951.hselasky@c2i.net> <20080713132638.S58331@woozle.rinet.ru> <20080714235642.GP53741@stlux503.dsto.defence.gov.au> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20080714235642.GP53741@stlux503.dsto.defence.gov.au> User-Agent: Opera Mail/9.51 (Linux) Cc: freebsd-current@freebsd.org Subject: Re: A bit of offtopic: msdosfs recovery tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 03:09:23 -0000 On Mon, 14 Jul 2008 18:56:42 -0500, Wilkinson, Alex wrote: > 0n Sun, Jul 13, 2008 at 01:29:44PM +0400, Dmitry Morozovsky wrote: > > >Yes, it is bundled with sysutils/disktest. > > sysutils/disktest/ ? > > According to http://www.freshports.org/ sysutils/disktest/ doesn't exist > ? sysutils/testdisk Cheers, Mezz > -aW -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 03:26:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059561065676 for ; Tue, 15 Jul 2008 03:26:46 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id ED2CC8FC15 for ; Tue, 15 Jul 2008 03:26:45 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) MIME-version: 1.0 Received: from [192.168.1.106] (87.64.99.122.cable.dyn.bal.ncable.com.au [122.99.64.87]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4000DFNZZNLP80@asmtp021.mac.com> for freebsd-current@freebsd.org; Mon, 14 Jul 2008 19:23:49 -0700 (PDT) Sender: jeff.dowsley@mac.com To: freebsd-current@freebsd.org Message-id: From: Jeff Dowsley Date: Tue, 15 Jul 2008 12:23:47 +1000 X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 03:26:46 -0000 Greetings Installed freeBSD current from ISO images, seems OK. However, any attempt to rebuild the kernel or any ports results in a segmentation fault 11 (gcc 4.2.1). Any clues/advice? JeffD From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 03:32:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E89FA1065677 for ; Tue, 15 Jul 2008 03:32:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B7C158FC16 for ; Tue, 15 Jul 2008 03:32:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m6F3WDYF074655; Mon, 14 Jul 2008 20:32:13 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m6F3WDa4074654; Mon, 14 Jul 2008 20:32:13 -0700 (PDT) (envelope-from sgk) Date: Mon, 14 Jul 2008 20:32:13 -0700 From: Steve Kargl To: Jeff Dowsley Message-ID: <20080715033213.GA74636@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 03:32:14 -0000 On Tue, Jul 15, 2008 at 12:23:47PM +1000, Jeff Dowsley wrote: > Greetings > > Installed freeBSD current from ISO images, seems OK. > > However, any attempt to rebuild the kernel or any ports results in a > segmentation fault 11 (gcc 4.2.1). > > Any clues/advice? > Try testing the memory. A segfault is often associated with failing memory. /usr/ports/sysutils/memtest86 -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 07:47:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCAF1065674 for ; Tue, 15 Jul 2008 07:47:02 +0000 (UTC) (envelope-from SNasonov@BCC.RU) Received: from extmx.bcc.ru (extmx.bcc.ru [217.170.85.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4883D8FC1D for ; Tue, 15 Jul 2008 07:47:01 +0000 (UTC) (envelope-from SNasonov@BCC.RU) Received: from localhost (localhost.bcc.ru [127.0.0.1]) by extmx.bcc.ru (Postfix) with ESMTP id 0C21B147113 for ; Tue, 15 Jul 2008 10:54:29 +0400 (MSD) Received: from extmx.bcc.ru ([127.0.0.1]) by localhost (extmx.bcc.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxezN1fRbLR7 for ; Tue, 15 Jul 2008 10:54:25 +0400 (MSD) Received: from mail.bcc (unknown [192.168.200.208]) by extmx.bcc.ru (Postfix) with SMTP for ; Tue, 15 Jul 2008 10:54:25 +0400 (MSD) Received: from snasonovnbwxp.bcc ([192.168.201.205]) by mail.bcc over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 11:24:37 +0400 From: Sergey G Nasonov Organization: BCC Date: Tue, 15 Jul 2008 11:24:35 +0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline X-Length: 3609 X-UID: 684 To: freebsd-current@freebsd.org Content-Type: Multipart/Mixed; boundary="Boundary-00=_0CFfI8Kngt7vqOP" Message-Id: <200807151124.36621.snasonov@bcc.ru> X-OriginalArrivalTime: 15 Jul 2008 07:24:37.0397 (UTC) FILETIME=[D6657C50:01C8E64B] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ATA subsystem lost drive after resume process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 07:47:02 -0000 --Boundary-00=_0CFfI8Kngt7vqOP Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello all. I have a laptop Lenovo T61 with a FreeBSD current installed on it. uname -a FreeBSD snasonovnbwxp.bcc 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Mon Jul 14 17:00:33 MSD 2008 snasonov@snasonovnbwxp.bcc:/usr/current/src/sys/i386/compile/CUSTOM i386 I want to understand why suspend/resume does not work. Suspend process works fine, but resume lead to hang. LCD screen after resume process remains black. At first I compile minimal CUSTOM kernel without USB support. And disabled SMP support through sysctl variable kern.smp.disabled=1 Also hw.acpi.reset_video was set to 1 to properly initialise LCD screen. After resume I can view folowing: ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=80 ostat=00 ata0: stat0=0x00 er=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices 0x10000 ata0: reinit done .. ata1: reiniting channel .. ata1: reset tp1 mask =00 ostat0=ff ostat1=ff ata1: reiniting done .. ata2: reiniting channel .. ata2: SATA connect time=0ms ata2: BUSY wait time =1ms ata2: SIGNATURE:ffffffff ata2: No signature, assuming disk device ata2: ahci_reset devices=00000001 em0: Link is up 100 Mbps Full duplex ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ata2: reinit done ata3: reiniting channel .. ata3: port not implemented ata3: reinit done .. ata4: reiniting channel .. ata4: SATA connect status=00000000 ata4: phy reset found no device ata4: reinit done .. atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) battery0: battery initialization start battery0: battery initialization done, tried 1 times ata2: reiniting channel .. ata2: SATA connect time=0ms ata2: BUSY wait time =1ms ata2: SIGNATURE:00000101 ata2: ahci_reset devices=00000001 ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ... I disabled DMA and cache write but problem remains. sysctl hw.ata hw.ata.setmax: 0 hw.ata.wc: 0 hw.ata.atapi_dma: 0 hw.ata.ata_dma: 0 I wrote this log from a screen, because disk subsystem does not save any data to disk. So the basic issue preventing normal suspend/resume process on modern Lenovo laptops is ata subsystem. Does anyone can help with this problem? I can test any path or provide additional info. verbose dmesg and pciconf -lv is attached Thanks, Sergey --Boundary-00=_0CFfI8Kngt7vqOP Content-Type: text/plain; charset="koi8-r"; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg" Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #9: Mon Jul 14 17:00:33 MSD 2008 snasonov@snasonovnbwxp.bcc:/usr/current/src/sys/i386/compile/CUSTOM WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e09000. Preloaded elf module "/boot/kernel/acpi_video.ko" at 0xc0e09250. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e09300. Preloaded elf module "/boot/kernel/ichwd.ko" at 0xc0e093ac. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1795516668 Hz CPU: Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz (1795.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 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 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 = 1030422528 (982 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001025000 - 0x000000003c613fff, 996077568 bytes (243183 pages) avail memory = 995643392 (949 MB) Table 'FACP' at 0x3d6bb900 Table 'SSDT' at 0x3d6bbab4 Table 'ECDT' at 0x3d6cbbee Table 'TCPA' at 0x3d6cbc40 Table 'APIC' at 0x3d6cbc72 MADT: Found table at 0x3d6cbc72 MP Configuration Table version 1.4 found at 0xc009dda1 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: bios32: Found BIOS32 Service Directory header at 0xc00f6880 bios32: Entry = 0xfdc60 (c00fdc60) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfdbf0+0x1b7 pnpbios: Found PnP BIOS data at 0xc00f6920 pnpbios: Entry = f0000:b821 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 WARNING: Non-uniform processors. WARNING: Using suboptimal topology. ULE: setup cpu 0 ACPI: RSDP @ 0x0xf68d0/0x0024 (v 2 LENOVO) ACPI: XSDT @ 0x0x3d6bb77f/0x0094 (v 1 LENOVO TP-7L 0x00002170 LTP 0x00000000) ACPI: FACP @ 0x0x3d6bb900/0x00F4 (v 3 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ACPI: DSDT @ 0x0x3d6bbd1d/0xFED1 (v 1 LENOVO TP-7L 0x00002170 MSFT 0x03000000) ACPI: FACS @ 0x0x3d6e4000/0x0040 ACPI: SSDT @ 0x0x3d6bbab4/0x0269 (v 1 LENOVO TP-7L 0x00002170 MSFT 0x03000000) ACPI: ECDT @ 0x0x3d6cbbee/0x0052 (v 1 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI: TCPA @ 0x0x3d6cbc40/0x0032 (v 2 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI: APIC @ 0x0x3d6cbc72/0x0068 (v 1 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI: MCFG @ 0x0x3d6cbcda/0x003C (v 1 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI: HPET @ 0x0x3d6cbd16/0x0038 (v 1 LENOVO TP-7L 0x00002170 LNVO 0x00000001) ACPI: SLIC @ 0x0x3d6cbdf0/0x0176 (v 1 LENOVO TP-7L 0x00002170 LTP 0x00000000) ACPI: BOOT @ 0x0x3d6cbf66/0x0028 (v 1 LENOVO TP-7L 0x00002170 LTP 0x00000001) ACPI: ASF! @ 0x0x3d6cbf8e/0x0072 (v 16 LENOVO TP-7L 0x00002170 PTL 0x00000001) ACPI: SSDT @ 0x0x3d6e2697/0x025F (v 1 LENOVO TP-7L 0x00002170 INTL 0x20050513) ACPI: SSDT @ 0x0x3d6e28f6/0x00A6 (v 1 LENOVO TP-7L 0x00002170 INTL 0x20050513) ACPI: SSDT @ 0x0x3d6e299c/0x04F7 (v 1 LENOVO TP-7L 0x00002170 INTL 0x20050513) ACPI: SSDT @ 0x0x3d6e2e93/0x01D8 (v 1 LENOVO TP-7L 0x00002170 INTL 0x20050513) 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: 0x00010000 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: io: random: ichwd module loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jul 11 2008 17:39:52) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa04 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=2a008086) pcibios: BIOS version 3.00 AcpiOsDerivePciId: \\_SB_.PCI0.MHCS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.EHC0.U7CS -> bus 0 dev 29 func 7 AcpiOsDerivePciId: \\_SB_.PCI0.EHC1.U8CS -> bus 0 dev 26 func 7 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc3ce7000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.LPCS -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3df00000 (3) failed ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 Validation 0 10 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x0c domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a02, revid=0x0c domain=0, 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 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf8100000, size 20, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2a03, revid=0x0c domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xf8200000, size 20, enabled found-> vendor=0x8086, dev=0x1049, revid=0x03 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, 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 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfe000000, size 17, enabled map[14]: type Memory, range 32, base 0xfe025000, size 12, enabled map[18]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2834, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2835, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe226c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x284b, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe020000, size 14, enabled pcib0: matched entry for 0.27.INTB pcib0: slot 27 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x283f, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 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 20 found-> vendor=0x8086, dev=0x2841, revid=0x03 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2843, revid=0x03 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 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 22 found-> vendor=0x8086, dev=0x2845, revid=0x03 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2847, revid=0x03 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 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 20 found-> vendor=0x8086, dev=0x2830, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2831, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2832, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe227000, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2448, revid=0xf3 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0005, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2811, revid=0x03 domain=0, 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=0x2850, revid=0x03 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 map[20]: type I/O Port, range 32, base 0x1c00, size 4, enabled found-> vendor=0x8086, dev=0x2829, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 4 messages map[10]: type I/O Port, range 32, base 0x1c50, size 3, enabled map[14]: type I/O Port, range 32, base 0x1c44, size 2, enabled map[18]: type I/O Port, range 32, base 0x1c48, size 3, enabled map[1c]: type I/O Port, range 32, base 0x1c40, size 2, enabled map[20]: type I/O Port, range 32, base 0x1c20, size 5, enabled map[24]: type Memory, range 32, base 0xfe226000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x283e, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe227400, size 8, enabled map[20]: type I/O Port, range 32, base 0x1c60, size 5, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 23 vgapci0: port 0x1800-0x1807 mem 0xf8100000-0xf81fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf8100000 agp0: detected 7676k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 found VGA CRT or VESA Compatible Analog Monitor(100), idx#0, port#0, head #0 found External Digital Monitor(300), idx#0, port#0, head #0 vgapci1: mem 0xf8200000-0xf82fffff at device 2.1 on pci0 em0: port 0x1840-0x185f mem 0xfe000000-0xfe01ffff,0xfe025000-0xfe025fff irq 20 at device 25.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xfe025000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1a:6b:36:6d:49 pci0: at device 26.0 (no driver attached) pci0: at device 26.1 (no driver attached) pci0: at device 26.7 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: irq 20 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xf8000000-0xf80fffff pci2: on pcib1 pci2: domain=0, physical bus=2 pcib2: irq 21 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 3 pcib2: subordinate bus 3 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xdc000000-0xdf3fffff pcib2: prefetched decode 0xdfe00000-0xdfefffff pci3: on pcib2 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x4227, revid=0x02 domain=0, bus=3, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xdf3ff000, size 12, enabled pcib2: requested memory range 0xdf3ff000-0xdf3fffff: good pcib2: matched entry for 3.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 pci3: at device 0.0 (no driver attached) pcib3: irq 22 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 4 pcib3: subordinate bus 4 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xd8000000-0xd9ffffff pcib3: prefetched decode 0xdfb00000-0xdfbfffff pci4: on pcib3 pci4: domain=0, physical bus=4 pcib4: irq 23 at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 5 pcib4: subordinate bus 12 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xd4000000-0xd5ffffff pcib4: prefetched decode 0xdf800000-0xdf8fffff pci5: on pcib4 pci5: domain=0, physical bus=5 pcib5: irq 20 at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 13 pcib5: subordinate bus 20 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xd0000000-0xd1ffffff pcib5: prefetched decode 0xdf500000-0xdf5fffff pci13: on pcib5 pci13: domain=0, physical bus=13 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 21 pcib6: subordinate bus 24 pcib6: I/O decode 0x7000-0xafff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci21: on pcib6 pci21: domain=0, physical bus=21 found-> vendor=0x1180, dev=0x0476, revid=0xb6 domain=0, bus=21, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf8300000, size 12, enabled pcib6: requested memory range 0xf8300000-0xf8300fff: good pcib6: matched entry for 21.0.INTA pcib6: slot 0 INTA hardwired to IRQ 16 cbb0: mem 0xf8300000-0xf8300fff irq 16 at device 0.0 on pci21 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf8300000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x04761180 0x02100007 0x060700b6 0x00822000 0x10: 0xf8300000 0x020000dc 0xb0181615 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07000110 0x40: 0x20c417aa 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x04a00001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x01000000 0x00f00000 0x00000000 0xb0: 0x00000000 0xfe000000 0x00003000 0x00000000 0xc0: 0x20c417aa 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c00-0x1c0f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c00 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 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=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x1c20-0x1c3f mem 0xfe226000-0xfe2267ff irq 16 at device 31.2 on pci0 atapci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c20 atapci1: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfe226000 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 3 ports PM not supported ata2: on atapci1 ata2: SATA connect time=0ms ata2: BUSY wait time=1ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci1 ata4: SATA connect status=00000000 ata4: phy reset found no device ata4: [MPSAFE] ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 ACPI: SSDT @ 0x0x3d6e1b32/0x0282 (v 1 PmRef Cpu0Ist 0x00000100 INTL 0x20050513) ACPI: SSDT @ 0x0x3d6e1e39/0x085E (v 1 PmRef Cpu0Cst 0x00000100 INTL 0x20050513) est0: on cpu0 p4tcc0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 53 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 54 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 battery0: on acpi0 acpi_acad0: on acpi0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 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 ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xe0000-0xeffff pnpid ORM0000 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 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x3bc ppc0: using extended I/O port range ppc0: failed to probe at port 0x3bc-0x3c3 irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 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: 0x4e01 0x4e01 0x4e01 0x4e01 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 55 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 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) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750936 hz Timecounter "TSC" frequency 1795516668 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0: identify ch->devices=00010000 battery0: battery initialization start acpi_acad0: acline initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH8M chip battery0: battery initialization done, tried 1 times acd0: DVDR drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, PIO4 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 ata1: identify ch->devices=00000000 ata2: identify ch->devices=00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad4: 114473MB at ata2-master SATA150 ad4: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: identify ch->devices=00000000 ata4: identify ch->devices=00000000 ATA PseudoRAID loaded WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad4s1 is ntfs/Preload. GEOM_LABEL: Label for provider ad4s2 is msdosfs/SERVICEV001. lock order reversal: (sleepable after non-sleepable) 1st 0xc43ed01c struct mount mtx (struct mount mtx) @ kern/vfs_subr.c:343 2nd 0xc43ed000 vfslock (vfslock) @ kern/vfs_subr.c:370 KDB: stack backtrace: db_trace_self_wrapper(c0acfd21,c3cefb64,c07693ee,c0ad255e,c43ed000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ad255e,c43ed000,c0ad8340,c0ad8340,c0ad88ee,...) at kdb_backtrace+0x29 witness_checkorder(c43ed000,1,c0ad88e5,172,c0c0acb4,...) at witness_checkorder+0x6de __lockmgr_args(c43ed000,200100,c43ed01c,0,0,...) at __lockmgr_args+0x230 vfs_busy(c43ed000,200,0,c40a4d20,1,...) at vfs_busy+0x1bc vfs_mount_alloc(0,c0b92020,c0ad868b,c40a4d20,c07a6f80,...) at vfs_mount_alloc+0x78 vfs_mountroot(c0bfddf0,4,c0ac7874,264,0,...) at vfs_mountroot+0x26c start_init(0,c3cefd38,c0ac9207,322,c40a2d0c,...) at start_init+0x65 fork_exit(c06f1df0,0,c3cefd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3cefd70, ebp = 0 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc4297e10 vnode interlock (vnode interlock) @ fs/devfs/devfs_vnops.c:288 2nd 0xc4297df4 devfs (devfs) @ kern/vfs_subr.c:2044 KDB: stack backtrace: db_trace_self_wrapper(c0acfd21,c3cefa8c,c07693ee,c0ad255e,c4297df4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ad255e,c4297df4,c0ac3252,c0ac3252,c0ad88ee,...) at kdb_backtrace+0x29 witness_checkorder(c4297df4,9,c0ad88e5,7fc,c4297df4,...) at witness_checkorder+0x6de __lockmgr_args(c4297df4,80100,c4297e10,0,0,...) at __lockmgr_args+0x777 vop_stdlock(c3cefb8c,c0ac3409,c0ac6555,80100,c4297d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0b92100,c3cefb8c,c0bd0ce0,c4297d9c,80100,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4297d9c,80100,c0ad88e5,7fc,c0ac3400,...) at _vn_lock+0x5e vget(c4297d9c,80100,c40a4d20,121,c0ac33a1,...) at vget+0x9c devfs_allocv(c43c4980,c43ed000,c3cefc20,c40a4d20,c40a4dc4,...) at devfs_allocv+0x11a devfs_root(c43ed000,80000,c0c52a74,c40a4d20,4,...) at devfs_root+0x51 set_rootvnode(c0c52a60,0,c0ad8246,5f1,c07a6f80,...) at set_rootvnode+0x2d vfs_mountroot(c0bfddf0,4,c0ac7874,264,0,...) at vfs_mountroot+0x34c start_init(0,c3cefd38,c0ac9207,322,c40a2d0c,...) at start_init+0x65 fork_exit(c06f1df0,0,c3cefd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3cefd70, ebp = 0 --- Trying to mount root from ufs:/dev/ad4s3a ct_to_ts([2008-07-15 11:10:03]) = 1216120203.000000000 lock order reversal: (sleepable after non-sleepable) 1st 0xc4297b20 bufobj interlock (bufobj interlock) @ kern/vfs_bio.c:2442 2nd 0xd7ebec80 bufwait (bufwait) @ kern/vfs_bio.c:2456 KDB: stack backtrace: db_trace_self_wrapper(c0acfd21,c3cef784,c07693ee,c0ad255e,d7ebec80,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ad255e,d7ebec80,c0ad722b,c0ad722b,c0ad67e7,...) at kdb_backtrace+0x29 witness_checkorder(d7ebec80,9,c0ad67de,998,c0c0acb4,...) at witness_checkorder+0x6de __lockmgr_args(d7ebec80,81900,c4297b20,c0ad7187,50,...) at __lockmgr_args+0x777 getblk(c4297a78,0,0,800,0,...) at getblk+0x153 breadn(c4297a78,0,0,800,0,...) at breadn+0x44 bread(c4297a78,0,0,800,0,...) at bread+0x4c ffs_blkatoff(c4297a78,0,0,0,c3cef9a4,...) at ffs_blkatoff+0xd1 ufs_lookup(c3cef9e8,c4297a78,c3cefb38,c4297a78,c3cefa08,...) at ufs_lookup+0x2e6 VOP_CACHEDLOOKUP_APV(c0bb8e60,c3cef9e8,c3cefb38,c3cefb24,c406f500,...) at VOP_CACHEDLOOKUP_APV+0xa5 vfs_cache_lookup(c3cefa68,c3cefa68,500000c,80000,c4297a78,...) at vfs_cache_lookup+0xd0 VOP_LOOKUP_APV(c0bb8e60,c3cefa68,c0ad7ff8,1b0,c3cefb24,...) at VOP_LOOKUP_APV+0xa5 lookup(c3cefb0c,c0ad7ff8,d8,c0,c406f62c,...) at lookup+0x57e namei(c3cefb0c,c3cefb24,c0768bcc,c0ad8340,c0ad8687,...) at namei+0x44b kern_unlinkat(c40a4d20,ffffff9c,c0ad8687,1,c3cefc5c,...) at kern_unlinkat+0x46 kern_unlink(c40a4d20,c0ad8687,1,62c,0,...) at kern_unlink+0x27 vfs_mountroot_try(c0ad8841,c0ac6557,c0ad868c,1,c07a6f80,...) at vfs_mountroot_try+0x482 vfs_mountroot(c0bfddf0,4,c0ac7874,264,0,...) at vfs_mountroot+0x40e start_init(0,c3cefd38,c0ac9207,322,c40a2d0c,...) at start_init+0x65 fork_exit(c06f1df0,0,c3cefd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3cefd70, ebp = 0 --- start_init: trying /sbin/init ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled em0: Link is up 100 Mbps Full Duplex lock order reversal: 1st 0xc48237ac ufs (ufs) @ kern/vfs_subr.c:2044 2nd 0xc0bfca7c kernel linker (kernel linker) @ kern/kern_linker.c:693 KDB: stack backtrace: db_trace_self_wrapper(c0acfd21,e634d6c8,c07693ee,c0ad255e,c0bfca7c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ad255e,c0bfca7c,c0ac9be0,c0ac9be0,c0ac9c2d,...) at kdb_backtrace+0x29 witness_checkorder(c0bfca7c,9,c0ac9c24,2b5,e634d718,...) at witness_checkorder+0x6de _sx_xlock(c0bfca7c,0,c0ac9c24,2b5,c0ac9c2d,...) at _sx_xlock+0x7d linker_file_lookup_set(c47c1700,c0ac9c72,e634d734,e634d730,0,...) at linker_file_lookup_set+0x4a linker_file_register_sysctls(c0bfca7c,c0ac9c24,19d,17c,0,...) at linker_file_register_sysctls+0x2d linker_load_module(c4833d70,0,e634d940,e634d93c,e634d938,...) at linker_load_module+0x92f linker_load_dependencies(c47f8400,0,c4833bc0,2a4,4bc0,...) at linker_load_dependencies+0x194 link_elf_load_file(c0b9e4e0,c4244ca0,e634dc24,17c,0,...) at link_elf_load_file+0x4f0 linker_load_module(0,e634dc4c,c0ac9c24,3cd,81d67cc,...) at linker_load_module+0x8cb kern_kldload(c43d8460,c4206000,e634dc70,0,1,...) at kern_kldload+0xc8 kldload(c43d8460,e634dcf8,4,c0ad2c79,c0b97340,...) at kldload+0x74 syscall(e634dd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (304, FreeBSD ELF32, kldload), eip = 0x28409c6b, esp = 0xbfbfe93c, ebp = 0xbfbfe948 --- drm0: on vgapci0 info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.5.0 20060119 drm0: [MPSAFE] drm0: [ITHREAD] lock order reversal: 1st 0xc45a132c filedesc structure (filedesc structure) @ kern/kern_descrip.c:1075 2nd 0xc4a09ce8 ufs (ufs) @ kern/vfs_subr.c:4022 KDB: stack backtrace: db_trace_self_wrapper(c0acfd21,e641ca94,c07693ee,c0ad255e,c4a09ce8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ad255e,c4a09ce8,c0ac6e23,c0ac6e23,c0ad88ee,...) at kdb_backtrace+0x29 witness_checkorder(c4a09ce8,9,c0ad88e5,fb6,c07afd37,...) at witness_checkorder+0x6de __lockmgr_args(c4a09ce8,80400,c4a09d04,0,0,...) at __lockmgr_args+0x777 ffs_lock(e641cb9c,e641cb88,246,80400,c4a09c90,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0bb8e60,e641cb9c,c0bd0ce0,c4a09c90,80400,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4a09c90,80400,c0ad88e5,fb6,e641cbf8,...) at _vn_lock+0x5e vfs_knllock(c4a09c90,0,c0ac8ca3,68e,c4ae261c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e641cc18,c07abd49,c4ac255c,c4ae261c,...) at knlist_remove_kq+0xad knlist_remove(c4ac255c,c4ae261c,0,e641cc44,c0704b85,...) at knlist_remove+0x1b filt_vfsdetach(c4ae261c,0,c0ac8ca3,75e,11,...) at filt_vfsdetach+0x39 knote_fdclose(c47f3af0,6b1,c0ac87dc,433,c4ae1540,...) at knote_fdclose+0xf5 kern_close(c47f3af0,6b1,e641cd2c,c0a4a353,c47f3af0,...) at kern_close+0xd5 close(c47f3af0,e641ccf8,4,c0ad2c65,c0b95750,...) at close+0x1a syscall(e641cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x284b9893, esp = 0xbfbfe81c, ebp = 0xbfbfe838 --- > --Boundary-00=_0CFfI8Kngt7vqOP-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 09:14:59 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A2421065676; Tue, 15 Jul 2008 09:14:59 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D07338FC1E; Tue, 15 Jul 2008 09:14:58 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.40] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m6F9EuX7054884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 02:14:57 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <487C6A86.20508@FreeBSD.org> Date: Tue, 15 Jul 2008 02:14:46 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Remko Lodder References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> In-Reply-To: <200807131153.m6DBrDkX067657@repoman.freebsd.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , "current@freebsd.org" Subject: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 09:14:59 -0000 Remko Lodder wrote: > MFC r180345 > > Add missing information for geom_mirror metadata. > > PR: 124434 > Submitted by: Philip M. Golluci > MFC after: 3 days Not really relevant to the change in question, but I think that the whole idea of geom_mirror updating on-disk metadata automagically is not very well thought out. For example one could try booting 7.x kernel on 6.x system just to see how well it goes with the intention to revert back if it doesn't work out well. We have excellent tool called nextboot (8) that really helps doing it safely or semi-safely even remotely over ssh. In the worst case you just need to cycle the power to return to the previous configuration. Automatic conversion makes it impossible to go back without some heavy manual intervention at console necessary to boot off the disk directly and re-creating/re-syncing the mirror after that. I've run into exactly this issue today, with the target machine stuck in unbootable state on another continent many thousand miles away. Another possible common scenarios where automatic updates can do harm are: booting 7.0 recovery CD on 6.x system or multi-boot system with several FreeBSD versions installed on the same machine and sharing mirrored disk(s). IMHO metadata update should be performed if and only if explicitly requested by the administrator. In all other cases the driver should do conversion from old format to the new one in memory when reading metadata and convert back when saving it. Printing big warning about the need to update metadata mentioning the fact that using mirror with old kernels won't be possible afterwards is OK, though. At least this has to be done for the cases when the difference is reasonable, such as just one generation in my case. If the difference is beyond any reasonable limits (i.e. v3 on-disk metadata and v6 module), the driver should present console prompt and let admin make a decision explicitly. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 09:43:13 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD88106566C; Tue, 15 Jul 2008 09:43:13 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 507698FC18; Tue, 15 Jul 2008 09:43:13 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 19A9839B11; Tue, 15 Jul 2008 11:43:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDEgJ0pzKA6X; Tue, 15 Jul 2008 11:43:10 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id B084639ACB; Tue, 15 Jul 2008 11:43:10 +0200 (CEST) Date: Tue, 15 Jul 2008 11:43:10 +0200 From: Ollivier Robert To: src-committers@FreeBSD.org, "current@freebsd.org" Message-ID: <20080715094310.GA70666@keltia.freenix.fr> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487C6A86.20508@FreeBSD.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 09:43:13 -0000 According to Maxim Sobolev: > Not really relevant to the change in question, but I think that the whole > idea of geom_mirror updating on-disk metadata automagically is not very > well thought out. For example one could try booting 7.x kernel on 6.x > system just to see how well it goes with the intention to revert back if it > doesn't work out well. We have excellent tool called nextboot (8) that > really helps doing it safely or semi-safely even remotely over ssh. In the > worst case you just need to cycle the power to return to the previous > configuration. > > Automatic conversion makes it impossible to go back without some heavy > manual intervention at console necessary to boot off the disk directly and > re-creating/re-syncing the mirror after that. I've run into exactly this > issue today, with the target machine stuck in unbootable state on another > continent many thousand miles away. I completely agree on that one, I got bitten by this during my upgrade from 6.1-STABLE to 7.0-RELEASE on a gmirror-ed machine. That is a complete violation from POLA and harmful to say the least. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; i386 From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 17:59:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FAFC106564A for ; Tue, 15 Jul 2008 17:59:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 49AF18FC13 for ; Tue, 15 Jul 2008 17:59:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m6FHxjO7081068 for ; Tue, 15 Jul 2008 10:59:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m6FHxiMl081067 for freebsd-current@freebsd.org; Tue, 15 Jul 2008 10:59:44 -0700 (PDT) (envelope-from sgk) Date: Tue, 15 Jul 2008 10:59:44 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20080715175944.GA80901@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 17:59:45 -0000 It appears that the ULE scheduler is not providing a fair slice to running processes. I have a dual-cpu, quad-core opteron based system with node21:kargl[229] uname -a FreeBSD node21.cimu.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Wed Jun 4 16:22:49 PDT 2008 kargl@node10.cimu.org:src/sys/HPC amd64 If I start exactly 8 processes, each gets 100% WCPU according to top. If I add to additional processes, then I observe last pid: 3874; load averages: 9.99, 9.76, 9.43 up 0+19:54:44 10:51:18 41 processes: 11 running, 30 sleeping CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 5706M Active, 8816K Inact, 169M Wired, 84K Cache, 108M Buf, 25G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 3836 kargl 1 118 0 577M 572M CPU7 7 6:37 100.00% kzk90 3839 kargl 1 118 0 577M 572M CPU2 2 6:36 100.00% kzk90 3849 kargl 1 118 0 577M 572M CPU3 3 6:33 100.00% kzk90 3852 kargl 1 118 0 577M 572M CPU0 0 6:25 100.00% kzk90 3864 kargl 1 118 0 577M 572M RUN 1 6:24 100.00% kzk90 3858 kargl 1 112 0 577M 572M RUN 5 4:10 78.47% kzk90 3855 kargl 1 110 0 577M 572M CPU5 5 4:29 67.97% kzk90 3842 kargl 1 110 0 577M 572M CPU4 4 4:24 66.70% kzk90 3846 kargl 1 107 0 577M 572M RUN 6 3:22 53.96% kzk90 3861 kargl 1 107 0 577M 572M CPU6 6 3:15 53.37% kzk90 I would have expected to see a more evenly distributed WCPU of around 80% for each process. So, do I need to tune one or more of the following sysctl values? Is this a side effect of cpu affinity being a tad too aggressive? node21:kargl[231] sysctl -a | grep sched | more kern.sched.preemption: 1 kern.sched.steal_thresh: 3 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 4 kern.sched.idlespins: 10000 kern.sched.static_boost: 160 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 18:11:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D81F1065671 for ; Tue, 15 Jul 2008 18:11:07 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2268FC0A for ; Tue, 15 Jul 2008 18:11:07 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m6FIA4sR007338; Tue, 15 Jul 2008 13:10:04 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <487CE839.3080507@math.missouri.edu> Date: Tue, 15 Jul 2008 13:11:05 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.15) Gecko/20080713 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Steve Kargl References: <20080715175944.GA80901@troutmask.apl.washington.edu> In-Reply-To: <20080715175944.GA80901@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 18:11:07 -0000 Steve Kargl wrote: > It appears that the ULE scheduler is not providing a fair > slice to running processes. > > I have a dual-cpu, quad-core opteron based system with > node21:kargl[229] uname -a > FreeBSD node21.cimu.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3: > Wed Jun 4 16:22:49 PDT 2008 kargl@node10.cimu.org:src/sys/HPC amd64 > > If I start exactly 8 processes, each gets 100% WCPU according to > top. If I add to additional processes, then I observe > > last pid: 3874; load averages: 9.99, 9.76, 9.43 up 0+19:54:44 10:51:18 > 41 processes: 11 running, 30 sleeping > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle > Mem: 5706M Active, 8816K Inact, 169M Wired, 84K Cache, 108M Buf, 25G Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 3836 kargl 1 118 0 577M 572M CPU7 7 6:37 100.00% kzk90 > 3839 kargl 1 118 0 577M 572M CPU2 2 6:36 100.00% kzk90 > 3849 kargl 1 118 0 577M 572M CPU3 3 6:33 100.00% kzk90 > 3852 kargl 1 118 0 577M 572M CPU0 0 6:25 100.00% kzk90 > 3864 kargl 1 118 0 577M 572M RUN 1 6:24 100.00% kzk90 > 3858 kargl 1 112 0 577M 572M RUN 5 4:10 78.47% kzk90 > 3855 kargl 1 110 0 577M 572M CPU5 5 4:29 67.97% kzk90 > 3842 kargl 1 110 0 577M 572M CPU4 4 4:24 66.70% kzk90 > 3846 kargl 1 107 0 577M 572M RUN 6 3:22 53.96% kzk90 > 3861 kargl 1 107 0 577M 572M CPU6 6 3:15 53.37% kzk90 My personal experience is that WCPU is not that accurate a measure of what is really going on. It is some kind of weighted CPU time, and according to the man page you have to wait for up to a minute to get an accurate sense. What I tend to do is to look at the TIME's, and see how fast they tick. Also, you can run the programs thus: time ./kargl and the times produced at the end tend to be a rather good measure of actual percentage cpu time. Although I can see that in your situation that this might be tricky to use. There is also a -C option with top that gives "raw CPU" time. I have never tried it, so I cannot speak to how good it really is. Stephen From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 18:35:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F9A510656F5 for ; Tue, 15 Jul 2008 18:35:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 65ECC8FC18 for ; Tue, 15 Jul 2008 18:35:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m6FIZ91D081351; Tue, 15 Jul 2008 11:35:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m6FIZ9B9081350; Tue, 15 Jul 2008 11:35:09 -0700 (PDT) (envelope-from sgk) Date: Tue, 15 Jul 2008 11:35:09 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20080715183509.GA81210@troutmask.apl.washington.edu> References: <20080715175944.GA80901@troutmask.apl.washington.edu> <487CE839.3080507@math.missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487CE839.3080507@math.missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 18:35:09 -0000 On Tue, Jul 15, 2008 at 01:11:05PM -0500, Stephen Montgomery-Smith wrote: > Steve Kargl wrote: > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 3836 kargl 1 118 0 577M 572M CPU7 7 6:37 100.00% kzk90 > > 3839 kargl 1 118 0 577M 572M CPU2 2 6:36 100.00% kzk90 > > 3849 kargl 1 118 0 577M 572M CPU3 3 6:33 100.00% kzk90 > > 3852 kargl 1 118 0 577M 572M CPU0 0 6:25 100.00% kzk90 > > 3864 kargl 1 118 0 577M 572M RUN 1 6:24 100.00% kzk90 > > 3858 kargl 1 112 0 577M 572M RUN 5 4:10 78.47% kzk90 > > 3855 kargl 1 110 0 577M 572M CPU5 5 4:29 67.97% kzk90 > > 3842 kargl 1 110 0 577M 572M CPU4 4 4:24 66.70% kzk90 > > 3846 kargl 1 107 0 577M 572M RUN 6 3:22 53.96% kzk90 > > 3861 kargl 1 107 0 577M 572M CPU6 6 3:15 53.37% kzk90 > > My personal experience is that WCPU is not that accurate a measure of > what is really going on. It is some kind of weighted CPU time, and > according to the man page you have to wait for up to a minute to get an > accurate sense. WCPU may indeed be misleading, but there appears to be a problem with migrating a process to an otherwise idle cpu. If I kill the process on CPU0 and one of the processes on CPU6, I then see last pid: 65293; load averages: 8.00, 8.33, 8.91 up 19+21:43:26 11:14:21 39 processes: 9 running, 30 sleeping CPU: 87.5% user, 0.0% nice, 0.0% system, 0.0% interrupt, 12.5% idle Mem: 4569M Active, 64M Inact, 163M Wired, 304K Cache, 202M Buf, 26G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 65035 kargl 1 118 0 577M 572M CPU7 7 62:15 100.00% kzk90 65038 kargl 1 118 0 577M 572M CPU3 3 62:11 100.00% kzk90 65023 kargl 1 118 0 577M 572M CPU1 1 58:44 100.00% kzk90 65032 kargl 1 118 0 577M 572M CPU6 6 55:36 100.00% kzk90 65026 kargl 1 118 0 577M 572M CPU2 2 53:32 100.00% kzk90 65029 kargl 1 112 0 577M 572M CPU5 5 42:16 73.29% kzk90 65041 kargl 1 110 0 577M 572M RUN 5 41:37 66.80% kzk90 65020 kargl 1 110 0 577M 572M CPU4 4 43:45 64.36% kzk90 The 3 processes with less than 100% WCPU bounce between CPU4 and CPU5. Nothing is ever scheduled for CPU0. > What I tend to do is to look at the TIME's, and see how fast they tick. > > Also, you can run the programs thus: > > time ./kargl > > and the times produced at the end tend to be a rather good measure of > actual percentage cpu time. Although I can see that in your situation > that this might be tricky to use. I'd expect the output from time to be nearly identical for each process in that each is running with the exact same input parameters. > There is also a -C option with top that gives "raw CPU" time. I have > never tried it, so I cannot speak to how good it really is. -C doesn't appear to give anything different. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 19:17:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F7361065670 for ; Tue, 15 Jul 2008 19:17:57 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id D19FB8FC20 for ; Tue, 15 Jul 2008 19:17:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so4384578wfg.7 for ; Tue, 15 Jul 2008 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=60tZa3Rzwg0qhwV25u6M5IQ9ACUzBWG6OtYquk5xc0o=; b=A1ljJCRAKm2BqZ13AfjL8NmCqYklvewK/YZOfmusCote/sOlrQBLbpXIOQs7PqvOJD oLwTqMhOdmg6HB0J0SIzkVIgIibk995ByUSvo84eIXkCfzwxe9EjCIZ2Gf/20MRdZ1ak PhbSy9uJjWRPcpYxa7PjZNzQTj66KkycoVe8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=mU6S22t6lpKP/NzX0t2iJagxd5kJjc8YKCI8cBLx9ICMYz9RBTIAMKUsRIfnCmFikH 2FkqNQRoINp+eQKCV8Y1FN+6u+9vdU6edTXcJ1Lw936wJC0DExjEscLe2zBHa+4kY3LX ZrV9zuGqe6L17RknTrw+lU0ZBJrJlZEiExvxg= Received: by 10.142.72.4 with SMTP id u4mr4798271wfa.269.1216149476459; Tue, 15 Jul 2008 12:17:56 -0700 (PDT) Received: from ?192.168.10.42? ( [76.254.4.131]) by mx.google.com with ESMTPS id 32sm6225997wfc.12.2008.07.15.12.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 12:17:55 -0700 (PDT) Message-Id: From: Garrett Cooper To: Steve Kargl In-Reply-To: <20080715183509.GA81210@troutmask.apl.washington.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 12:15:21 -0700 References: <20080715175944.GA80901@troutmask.apl.washington.edu> <487CE839.3080507@math.missouri.edu> <20080715183509.GA81210@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.926) Cc: Stephen Montgomery-Smith , freebsd-current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 19:17:57 -0000 On Jul 15, 2008, at 11:35 AM, Steve Kargl wrote: > On Tue, Jul 15, 2008 at 01:11:05PM -0500, Stephen Montgomery-Smith > wrote: >> Steve Kargl wrote: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>> COMMAND >>> 3836 kargl 1 118 0 577M 572M CPU7 7 6:37 >>> 100.00% kzk90 >>> 3839 kargl 1 118 0 577M 572M CPU2 2 6:36 >>> 100.00% kzk90 >>> 3849 kargl 1 118 0 577M 572M CPU3 3 6:33 >>> 100.00% kzk90 >>> 3852 kargl 1 118 0 577M 572M CPU0 0 6:25 >>> 100.00% kzk90 >>> 3864 kargl 1 118 0 577M 572M RUN 1 6:24 >>> 100.00% kzk90 >>> 3858 kargl 1 112 0 577M 572M RUN 5 4:10 78.47% >>> kzk90 >>> 3855 kargl 1 110 0 577M 572M CPU5 5 4:29 67.97% >>> kzk90 >>> 3842 kargl 1 110 0 577M 572M CPU4 4 4:24 66.70% >>> kzk90 >>> 3846 kargl 1 107 0 577M 572M RUN 6 3:22 53.96% >>> kzk90 >>> 3861 kargl 1 107 0 577M 572M CPU6 6 3:15 53.37% >>> kzk90 >> >> My personal experience is that WCPU is not that accurate a measure of >> what is really going on. It is some kind of weighted CPU time, and >> according to the man page you have to wait for up to a minute to >> get an >> accurate sense. > > WCPU may indeed be misleading, but there appears to be a problem > with migrating a process to an otherwise idle cpu. If I kill > the process on CPU0 and one of the processes on CPU6, I then see > > last pid: 65293; load averages: 8.00, 8.33, 8.91 up > 19+21:43:26 11:14:21 > 39 processes: 9 running, 30 sleeping > CPU: 87.5% user, 0.0% nice, 0.0% system, 0.0% interrupt, 12.5% idle > Mem: 4569M Active, 64M Inact, 163M Wired, 304K Cache, 202M Buf, 26G > Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 65035 kargl 1 118 0 577M 572M CPU7 7 62:15 100.00% > kzk90 > 65038 kargl 1 118 0 577M 572M CPU3 3 62:11 100.00% > kzk90 > 65023 kargl 1 118 0 577M 572M CPU1 1 58:44 100.00% > kzk90 > 65032 kargl 1 118 0 577M 572M CPU6 6 55:36 100.00% > kzk90 > 65026 kargl 1 118 0 577M 572M CPU2 2 53:32 100.00% > kzk90 > 65029 kargl 1 112 0 577M 572M CPU5 5 42:16 73.29% > kzk90 > 65041 kargl 1 110 0 577M 572M RUN 5 41:37 66.80% > kzk90 > 65020 kargl 1 110 0 577M 572M CPU4 4 43:45 64.36% > kzk90 > > The 3 processes with less than 100% WCPU bounce between CPU4 and CPU5. > Nothing is ever scheduled for CPU0. > >> What I tend to do is to look at the TIME's, and see how fast they >> tick. >> >> Also, you can run the programs thus: >> >> time ./kargl >> >> and the times produced at the end tend to be a rather good measure of >> actual percentage cpu time. Although I can see that in your >> situation >> that this might be tricky to use. > > I'd expect the output from time to be nearly identical for > each process in that each is running with the exact same > input parameters. > >> There is also a -C option with top that gives "raw CPU" time. I have >> never tried it, so I cannot speak to how good it really is. > > -C doesn't appear to give anything different. FWIW it appears that OSX has migrated away from traditional [n?]top available in FreeBSD and they no longer include WCPU. Maybe there were some other improvements made, because it consistently appears to be reporting the correct CPU usage percentage... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 20:46:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B91211065674 for ; Tue, 15 Jul 2008 20:46:05 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep33-int.chello.at (viefep18-int.chello.at [213.46.255.22]) by mx1.freebsd.org (Postfix) with ESMTP id F04448FC28 for ; Tue, 15 Jul 2008 20:46:04 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from lizard.fafoe.narf.at ([213.47.85.26]) by viefep32-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080715202912.FOTS10340.viefep32-int.chello.at@lizard.fafoe.narf.at>; Tue, 15 Jul 2008 22:29:12 +0200 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 926B9BB64; Tue, 15 Jul 2008 22:28:52 +0200 (CEST) Date: Tue, 15 Jul 2008 22:28:52 +0200 From: Stefan Farfeleder To: "Simon L. Nielsen" Message-ID: <20080715202852.GB1366@lizard.fafoe.narf.at> Mail-Followup-To: "Simon L. Nielsen" , freebsd-current@freebsd.org References: <20080713230635.GC15766@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20080713230635.GC15766@zaphod.nitro.dk> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [patch] segfault in sh for bogus redirection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2008 20:46:05 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 14, 2008 at 01:06:35AM +0200, Simon L. Nielsen wrote: > Hey Stefan (and other people familiar with the sh(1) code), > > I stumbled on a corner case bug in sh(1) where it segfaults instead of > giving a proper error message. This only happens when you do > something stupid, but I thought it should be fixed anyway. > > When you redirect to an unset or empty variable things fail: > > $ sh -c 'echo 1 >&$a' > Segmentation fault (core dumped) > > With patch: > > $ sh -c 'echo 1 >&$a' > Syntax error: Bad fd number > > I have made a patch which fixes the issue (attached) so it fails > normally with an error, but I'm not sure if it's the right way of > fixing it. Do you think this fix is OK, or is there a better way to > do this? > > I also included a regression test to check for the problem. Hi, I don't think your patch is correct. The value of 'fn.list->text' is not properly initialised in eval.c:441 and only NULL by chance. Try this patch instead. I still need to test it properly though. --sdtB3X0nJg68CQEu Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="redir.diff" Index: eval.c =================================================================== --- eval.c (revision 180476) +++ eval.c (working copy) @@ -437,7 +437,7 @@ case NFROMFD: case NTOFD: if (redir->ndup.vname) { - expandarg(redir->ndup.vname, &fn, EXP_FULL | EXP_TILDE); + expandarg(redir->ndup.vname, &fn, EXP_TILDE | EXP_REDIR); fixredir(redir, fn.list->text, 1); } break; --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 00:45:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4C51065671; Wed, 16 Jul 2008 00:45:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0508FC22; Wed, 16 Jul 2008 00:45:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m6F9piSY005997; Tue, 15 Jul 2008 19:51:44 +1000 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m6F9pelR028371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 19:51:40 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m6F9pdIm093292; Tue, 15 Jul 2008 19:51:39 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m6F9pdAf093291; Tue, 15 Jul 2008 19:51:39 +1000 (EST) (envelope-from peter) Date: Tue, 15 Jul 2008 19:51:39 +1000 From: Peter Jeremy To: Maxim Sobolev Message-ID: <20080715095139.GA62764@server.vk2pj.dyndns.org> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VZEZlOQeSr/zV9d3" Content-Disposition: inline In-Reply-To: <487C6A86.20508@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Remko Lodder , src-committers@freebsd.org, Pawel Jakub Dawidek , "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 00:45:34 -0000 --VZEZlOQeSr/zV9d3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jul-15 02:14:46 -0700, Maxim Sobolev wrote: >Not really relevant to the change in question, but I think that the=20 >whole idea of geom_mirror updating on-disk metadata automagically is not= =20 > very well thought out. For example one could try booting 7.x kernel on= =20 >6.x system just to see how well it goes with the intention to revert=20 >back if it doesn't work out well. Agreed. I raised the same issue on -stable in late June. >and re-creating/re-syncing the mirror after that. I've run into exactly=20 >this issue today, with the target machine stuck in unbootable state on=20 >another continent many thousand miles away. I was lucky that I didn't need to revert. >IMHO metadata update should be performed if and only if explicitly=20 >requested by the administrator. Agreed. It's especially worrying that there's absolutely no warning that a particular version of geom_mirror has a different metadata format and loading it will make your gmirror unusable with an older gmirror. IMHO, any geom changes changes that prevent reversion should be noted in UPDATING (at the very least). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --VZEZlOQeSr/zV9d3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh8cysACgkQ/opHv/APuId+jgCeMXoS9EoKz9RPzsILimbAJgEo MO0AoJHoei1lQNh9dS8SDx/RkuOdRtIq =5MlO -----END PGP SIGNATURE----- --VZEZlOQeSr/zV9d3-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 02:46:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30F4106564A for ; Wed, 16 Jul 2008 02:46:19 +0000 (UTC) (envelope-from thinker@branda.to) Received: from msr20.hinet.net (msr20.hinet.net [168.95.4.120]) by mx1.freebsd.org (Postfix) with ESMTP id 580AC8FC12 for ; Wed, 16 Jul 2008 02:46:18 +0000 (UTC) (envelope-from thinker@branda.to) Received: from cowboy.branda.to (122-120-5-211.dynamic.hinet.net [122.120.5.211]) by msr20.hinet.net (8.9.3/8.9.3) with ESMTP id KAA14954 for ; Wed, 16 Jul 2008 10:30:54 +0800 (CST) Received: from cowboy.branda.to (localhost [127.0.0.1]) by cowboy.branda.to (8.14.2/8.14.2) with ESMTP id m6G2UvH2010430 for ; Wed, 16 Jul 2008 10:30:57 +0800 (CST) (envelope-from thinker@branda.to) Message-ID: <487D5D60.1010102@branda.to> Date: Wed, 16 Jul 2008 10:30:56 +0800 From: Thinker User-Agent: Thunderbird 2.0.0.14 (X11/20080701) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Jul 2008 03:02:35 +0000 Subject: A patch of MBR for Vortex86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 02:46:20 -0000 Hi all, DM&P is the vendor of Vortex86 series SoCs. As I know, most Vortex86 SoC chips have a hardware watchdog timer included. It can be configured to trigger PCIRST signal to reset the system. I have a driver for Vortex86 watchdog timer, it is here, http://www.freebsd.org/cgi/query-pr.cgi?pr=125409 The driver is compatible with watchdog(9). Although the driver seems work, but sometimes, for some reason, the system was hanged when kernel is still booting. So, I have a patch for mbr boot code to initialize the watchdog timer to reset the system if it is not been cleared in 20 minutes. It provides capability and chance to recover the system from hanging when booting. Following is the patch. If you have a Vortex86 board, maybe you can help me to test it. Thanks you! begin 644 mbr-vortex86-watchdog.diff M9&EF9B`M#@P"0DC($9L862!%1$0*(`H@"0DN#0W-0D)(R!.=6UB97(@;V8@:&%R9"!D"!I;FET:6%L('9A;'5E M(')E9RX**PD)+G-E="!65%A?5$E-14]55"PP>#4*(`H@"0DN9VQO8FP@0H@(R!O;F4@<&%R=&ET:6]N(&ES(&UA M&]R=R`E`HK"0EM;W9B("165%A?5$E-14]55"PE86P**PD);W5T8B`E86PL)61X"0D) M(R!65%A?5$E-14]55"`J(#0@;6EN`HK"0EM;W9B("0P M>&%C+"5A;`HK"0EO=71B("5A;"PE9'@**PHK"0EX;W)W("5S:2PE`D)(R!0 M87)T:71I;VX@=&%B;&4*(`D);6]V8B`D,'@T+"5C;`D)"2,@3G5M8F5R(&]F M(&5N=')I97,*(&UA:6XN,3H@"6-M<&(@)6-H+"@E8G@I"0D)(R!.=6QL(&5N %=')Y/PH` ` end From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 05:37:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B351065674; Wed, 16 Jul 2008 05:37:18 +0000 (UTC) (envelope-from mark@legios.org) Received: from bade.legios.org (ppp198-172.static.internode.on.net [59.167.198.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF058FC13; Wed, 16 Jul 2008 05:37:18 +0000 (UTC) (envelope-from mark@legios.org) Received: from localhost (unknown [192.168.0.17]) by bade.legios.org (Postfix) with ESMTP id C49D31A9CC0; Wed, 16 Jul 2008 15:11:35 +1000 (EST) X-Virus-Scanned: amavisd-new at legios.org Received: from bade.legios.org ([192.168.0.17]) by localhost (legios.org [192.168.0.17]) (amavisd-new, port 10024) with ESMTP id 3E1-LQstT6UY; Wed, 16 Jul 2008 15:11:18 +1000 (EST) Received: from www.legios.org (unknown [192.168.0.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bade.legios.org (Postfix) with ESMTP id 56DE31A9C92; Wed, 16 Jul 2008 15:11:18 +1000 (EST) Received: from 210.11.57.37 (SquirrelMail authenticated user mark) by www.legios.org with HTTP; Wed, 16 Jul 2008 15:11:18 +1000 (EST) Message-ID: In-Reply-To: <20080715095139.GA62764@server.vk2pj.dyndns.org> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> Date: Wed, 16 Jul 2008 15:11:18 +1000 (EST) From: mark@legios.org To: "Peter Jeremy" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Remko Lodder , src-committers@freebsd.org, Pawel Jakub Dawidek , "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 05:37:19 -0000 > >>IMHO metadata update should be performed if and only if explicitly >>requested by the administrator. > > Agreed. It's especially worrying that there's absolutely no warning > that a particular version of geom_mirror has a different metadata > format and loading it will make your gmirror unusable with an older > gmirror. IMHO, any geom changes changes that prevent reversion > should be noted in UPDATING (at the very least). > Seconded. ZFS appears to have functionality similar to this whereby you can perform an upgrade using zpool upgrade to update the metadata. (Also, on loading zfs.ko it notifies you of the ZFS version it is/supports) From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 07:20:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26A41065675 for ; Wed, 16 Jul 2008 07:20:59 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5CEC58FC12 for ; Wed, 16 Jul 2008 07:20:59 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m6G7KVlE010287; Wed, 16 Jul 2008 11:20:33 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 16 Jul 2008 11:20:31 +0400 (MSD) From: Dmitry Morozovsky To: "Wilkinson, Alex" In-Reply-To: <20080714235642.GP53741@stlux503.dsto.defence.gov.au> Message-ID: <20080716112012.S82974@woozle.rinet.ru> References: <20080712204239.I58331@woozle.rinet.ru> <200807122249.03951.hselasky@c2i.net> <20080713132638.S58331@woozle.rinet.ru> <20080714235642.GP53741@stlux503.dsto.defence.gov.au> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Wed, 16 Jul 2008 11:20:33 +0400 (MSD) Cc: freebsd-current@freebsd.org Subject: Re: A bit of offtopic: msdosfs recovery tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 07:20:59 -0000 On Tue, 15 Jul 2008, Wilkinson, Alex wrote: WA> 0n Sun, Jul 13, 2008 at 01:29:44PM +0400, Dmitry Morozovsky wrote: WA> WA> >Yes, it is bundled with sysutils/disktest. WA> WA> sysutils/disktest/ ? WA> WA> According to http://www.freshports.org/ sysutils/disktest/ doesn't exist ? Swap the parts ;-) sysutils/testdisk Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 07:27:35 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A886E106566B for ; Wed, 16 Jul 2008 07:27:35 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFC58FC14 for ; Wed, 16 Jul 2008 07:27:35 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04] (unknown [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9606D3F; Wed, 16 Jul 2008 09:27:33 +0200 (CEST) Message-ID: <487DA2E5.3080201@andric.com> Date: Wed, 16 Jul 2008 09:27:33 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.17pre (Windows/20080712) MIME-Version: 1.0 To: pyunyh@gmail.com References: <484BC9FB.2040605@andric.com> <20080609012657.GD12521@cdnetworks.co.kr> <484D215A.7050700@andric.com> <20080609123206.GF12521@cdnetworks.co.kr> <484D25CC.9050106@andric.com> <20080610050550.GB17874@cdnetworks.co.kr> <484E9377.2050609@andric.com> <20080611005814.GA3529@cdnetworks.co.kr> <48666CD7.9020706@andric.com> <20080630043156.GB79537@cdnetworks.co.kr> <20080714013519.GE36245@cdnetworks.co.kr> In-Reply-To: <20080714013519.GE36245@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: re(4) and RTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 07:27:35 -0000 On 2008-07-14 03:35, Pyun YongHyeon wrote: > Here is patch for re(4) link handling. > Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply > attached one. If you still see watchdog timeouts, please turn off > TSO and let me know how it goes. I've tested this trough several reboots, and I haven't been bitten by any watchdogs yet. :) I'll run some stress tests today, to see if it handles that too. > One user reported TSO issues on 8169 family controllers but I > can't reproduce this on my 8169 hardware so it could be related > with silicon bug of sepecific revision of the hardware. I'm using re's default settings, which seem to be: re0: flags=8843 metric 0 mtu 1500 options=399b So TSO for IPv4 but not IPv6, right? I haven't yet seen any problems because of it. What would be a good way to "exercise" TSO? From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 08:05:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A6BF1065671 for ; Wed, 16 Jul 2008 08:05:39 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 159938FC1E for ; Wed, 16 Jul 2008 08:05:38 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [80.126.205.144]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id m6G7jWn5084709; Wed, 16 Jul 2008 09:45:35 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Jul 2008 09:45:33 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP Thread-Index: AcjnFfCVhrBL1g30RcKXrL4CgnyBewAANvUg References: <484BC9FB.2040605@andric.com><20080609012657.GD12521@cdnetworks.co.kr><484D215A.7050700@andric.com><20080609123206.GF12521@cdnetworks.co.kr><484D25CC.9050106@andric.com><20080610050550.GB17874@cdnetworks.co.kr><484E9377.2050609@andric.com><20080611005814.GA3529@cdnetworks.co.kr><48666CD7.9020706@andric.com><20080630043156.GB79537@cdnetworks.co.kr><20080714013519.GE36245@cdnetworks.co.kr> <487DA2E5.3080201@andric.com> From: "Johan Hendriks" To: "Dimitry Andric" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: RE: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 08:05:39 -0000 >Aan: pyunyh@gmail.com >CC: freebsd-current@FreeBSD.org >Onderwerp: Re: Call for testers: re(4) = >andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP >On 2008-07-14 03:35, Pyun YongHyeon wrote: >> Here is patch for re(4) link handling. >> Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply >> attached one. If you still see watchdog timeouts, please turn off >> TSO and let me know how it goes. >I've tested this trough several reboots, and I haven't been bitten by >any watchdogs yet. :) I'll run some stress tests today, to see if it >handles that too. >> One user reported TSO issues on 8169 family controllers but I >> can't reproduce this on my 8169 hardware so it could be related >> with silicon bug of sepecific revision of the hardware. >I'm using re's default settings, which seem to be: >re0: flags=3D8843 metric 0 mtu = 1500 = >options=3D399bST,WOL_MCAST,WOL_MAGIC> >So TSO for IPv4 but not IPv6, right? I haven't yet seen any problems >because of it. What would be a good way to "exercise" TSO? I had a re(4) card that did crash 7-stable now i cvsuped to 15-07-2008 = and did a rebuild The system is now in "production" and I see the following in = /var/log/messages. Jul 15 18:24:40 intranet kernel: re0: watchdog timeout Jul 15 18:24:40 intranet kernel: re0: link state changed to DOWN Jul 15 18:24:43 intranet kernel: re0: link state changed to UP Jul 15 19:28:03 intranet ntpd[883]: kernel time sync enabled 6001 Jul 15 19:45:08 intranet ntpd[883]: kernel time sync enabled 2001 Jul 15 20:04:41 intranet kernel: re0: watchdog timeout Jul 15 20:04:41 intranet kernel: re0: link state changed to DOWN Jul 15 20:04:43 intranet kernel: re0: link state changed to UP Jul 15 21:14:40 intranet kernel: re0: watchdog timeout Jul 15 21:14:40 intranet kernel: re0: link state changed to DOWN Jul 15 21:14:43 intranet kernel: re0: link state changed to UP Jul 15 21:19:41 intranet kernel: re0: watchdog timeout Jul 15 21:19:41 intranet kernel: re0: link state changed to DOWN Jul 15 21:19:43 intranet kernel: re0: link state changed to UP Jul 15 21:24:40 intranet kernel: re0: watchdog timeout Jul 15 21:24:40 intranet kernel: re0: link state changed to DOWN Jul 15 21:24:43 intranet kernel: re0: link state changed to UP Jul 15 22:14:40 intranet kernel: re0: watchdog timeout Jul 15 22:14:40 intranet kernel: re0: link state changed to DOWN Jul 15 22:14:43 intranet kernel: re0: link state changed to UP Jul 16 03:20:53 intranet kernel: re0: watchdog timeout Jul 16 03:20:53 intranet kernel: re0: link state changed to DOWN Jul 16 03:20:56 intranet kernel: re0: link state changed to UP Jul 16 03:24:41 intranet kernel: re0: watchdog timeout Jul 16 03:24:41 intranet kernel: re0: link state changed to DOWN Jul 16 03:24:43 intranet kernel: re0: link state changed to UP Jul 16 03:25:53 intranet kernel: re0: watchdog timeout Jul 16 03:25:53 intranet kernel: re0: link state changed to DOWN Jul 16 03:25:56 intranet kernel: re0: link state changed to UP Jul 16 03:44:40 intranet kernel: re0: watchdog timeout Jul 16 03:44:40 intranet kernel: re0: link state changed to DOWN Jul 16 03:44:43 intranet kernel: re0: link state changed to UP Jul 16 04:23:32 intranet ntpd[883]: kernel time sync enabled 6001 Jul 16 04:40:38 intranet ntpd[883]: kernel time sync enabled 2001 Jul 16 05:19:41 intranet kernel: re0: watchdog timeout Jul 16 05:19:41 intranet kernel: re0: link state changed to DOWN Jul 16 05:19:44 intranet kernel: re0: link state changed to UP Jul 16 06:19:40 intranet kernel: re0: watchdog timeout Jul 16 06:19:40 intranet kernel: re0: link state changed to DOWN Jul 16 06:19:43 intranet kernel: re0: link state changed to UP Jul 16 08:14:40 intranet kernel: re0: watchdog timeout Jul 16 08:14:40 intranet kernel: re0: link state changed to DOWN Jul 16 08:14:43 intranet kernel: re0: link state changed to UP Jul 16 08:44:41 intranet kernel: re0: watchdog timeout Jul 16 08:44:41 intranet kernel: re0: link state changed to DOWN Jul 16 08:44:44 intranet kernel: re0: link state changed to UP It is a small intranet webserver and does cacti and nagios things and = mirror cvs for the other machines. #pciconf -lv re0@pci0:2:0:0: class=3D0x020000 card=3D0x2a73103c chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class =3D network subclass =3D Ethernet # dmesg re0: port 0xe800-0xe8ff mem = 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto re0: Ethernet address: 00:1e:0b:a7:cc:38 re0: [FILTER] It also not always load ok on a reboot ! Sometimes it complains about something with PHY A reboot than fix this and loads the re0 driver. Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.138 / Virus Database: 270.4.11/1554 - Release Date: = 15-7-2008 18:03 From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 08:05:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F52A1065673 for ; Wed, 16 Jul 2008 08:05:46 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id 920B38FC25 for ; Wed, 16 Jul 2008 08:05:45 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.14.2) with ESMTP id m6FHkU4H096896; Tue, 15 Jul 2008 12:46:32 -0500 (CDT) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080715124429.024a1990@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 15 Jul 2008 12:46:11 -0500 To: Jeff Dowsley , freebsd-current@freebsd.org From: Derek Ragona In-Reply-To: References: Mime-Version: 1.0 X-Antivirus: avast! (VPS 080715-0, 07/15/2008), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV 0.93/6806/Wed Apr 16 15:50:16 2008 on betty.computinginnovations.com X-Virus-Status: Clean X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m6FHkU4H096896 X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 08:05:46 -0000 At 09:23 PM 7/14/2008, Jeff Dowsley wrote: >Greetings > >Installed freeBSD current from ISO images, seems OK. > >However, any attempt to rebuild the kernel or any ports results in a >segmentation fault 11 (gcc 4.2.1). > >Any clues/advice? > >JeffD Could be lots of things while a segv is a memory fault. Could be bad memory, flaky power supply, etc. You can try your make again using the -DNO_CLEAN option to have the make start where it left off. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 08:55:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 264321065671 for ; Wed, 16 Jul 2008 08:55:23 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9E8D8FC19 for ; Wed, 16 Jul 2008 08:55:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04] (unknown [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C20923F; Wed, 16 Jul 2008 10:55:21 +0200 (CEST) Message-ID: <487DB779.50609@andric.com> Date: Wed, 16 Jul 2008 10:55:21 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.17pre (Windows/20080712) MIME-Version: 1.0 To: Johan Hendriks References: <484BC9FB.2040605@andric.com><20080609012657.GD12521@cdnetworks.co.kr><484D215A.7050700@andric.com><20080609123206.GF12521@cdnetworks.co.kr><484D25CC.9050106@andric.com><20080610050550.GB17874@cdnetworks.co.kr><484E9377.2050609@andric.com><20080611005814.GA3529@cdnetworks.co.kr><48666CD7.9020706@andric.com><20080630043156.GB79537@cdnetworks.co.kr><20080714013519.GE36245@cdnetworks.co.kr> <487DA2E5.3080201@andric.com> <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 08:55:23 -0000 On 2008-07-16 09:45, Johan Hendriks wrote: > I had a re(4) card that did crash 7-stable now i cvsuped to 15-07-2008 and did a rebuild > > The system is now in "production" and I see the following in /var/log/messages. > > Jul 15 18:24:40 intranet kernel: re0: watchdog timeout > Jul 15 18:24:40 intranet kernel: re0: link state changed to DOWN > Jul 15 18:24:43 intranet kernel: re0: link state changed to UP ... > re0: port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00200000 If it's not too much trouble, can you please try out the patch Pyun posted earlier in this thread? From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 09:57:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008101065671 for ; Wed, 16 Jul 2008 09:57:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD228FC19; Wed, 16 Jul 2008 09:57:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <487DC60B.6020209@FreeBSD.org> Date: Wed, 16 Jul 2008 11:57:31 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Derek Ragona References: <6.0.0.22.2.20080715124429.024a1990@mail.computinginnovations.com> In-Reply-To: <6.0.0.22.2.20080715124429.024a1990@mail.computinginnovations.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 09:57:32 -0000 Derek Ragona wrote: > At 09:23 PM 7/14/2008, Jeff Dowsley wrote: >> Greetings >> >> Installed freeBSD current from ISO images, seems OK. >> >> However, any attempt to rebuild the kernel or any ports results in a >> segmentation fault 11 (gcc 4.2.1). >> >> Any clues/advice? >> >> JeffD > > Could be lots of things while a segv is a memory fault. Could be bad > memory, flaky power supply, etc. You can try your make again using the > -DNO_CLEAN option to have the make start where it left off. Pretty dangerous advice since it is likely that some of the memory corruption will have been written to disk :) Kris From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 13:40:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42421106569A for ; Wed, 16 Jul 2008 13:40:04 +0000 (UTC) (envelope-from jan6146@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3858FC1E for ; Wed, 16 Jul 2008 13:40:03 +0000 (UTC) (envelope-from jan6146@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so4537838wfg.7 for ; Wed, 16 Jul 2008 06:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=jau5RpR6xhyCMIZA2Pza+glpMV7EfyZg6h0BW+J+JLU=; b=nEYAkR65/fuV+VOSgwrsRaNf7UwoXKWXsQbSc8IudqmGdz0raUmJZ1msgPEnFQXY5C Lqf1fhJtWzY6JgogUSDCzEAg2sO23mWfioKa2rz2ss25BnA3X2DgMgughcuJOw96ArvG WhBnRaHhrmQbY043+DGLNajIJsJGsSBxIxvcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=P8S0UoL1qfECCsAXoJYcKYypkS1iiFRo462GpNUnXekf5G3qpTlAHjR2nrjRExYP2W 1hJV2eYn7EiBkwCfaoNx3tf5fnYLW1Ogi571gSDtrRBjAc66kPeyf/6+5lLQiSMC1XH/ Tx38FNge6ROjdhLnsze9WWXxI62c4VtqUY80Y= Received: by 10.142.44.11 with SMTP id r11mr10404wfr.285.1216215603544; Wed, 16 Jul 2008 06:40:03 -0700 (PDT) Received: by 10.142.114.20 with HTTP; Wed, 16 Jul 2008 06:40:03 -0700 (PDT) Message-ID: <784966050807160640q31f13160t91702a150bd5b152@mail.gmail.com> Date: Wed, 16 Jul 2008 06:40:03 -0700 From: Rob To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 16 Jul 2008 13:45:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: I'm sorry about being a jerk regarding Sysinstall a week or so ago X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 13:40:04 -0000 Hi, I've very sorry about being such a jerk about my complaint regarding Sysinstall a week or so ago. It was a week where I was getting 2 hours of sleep per day. Finally my PCP had to intervene and knock me out with big doses of sleeping pills. :) It occasionally happens, then I have half a dozen apologies to make. I promise I will never mention Sysinstall again! I continue to use FreeBSD as I have for the last 10 years and I guess my biggest contribution has been making it known to people and evangelizing it, as it really does blow away Linux in performance. Sincerely, Rob -- ---------------------------------------------------------- http://www.youtube.com/user/whiteflluffyclouds (Ham radio videos) From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 14:26:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C6B1065683 for ; Wed, 16 Jul 2008 14:26:18 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3508FC1C for ; Wed, 16 Jul 2008 14:26:18 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 5CF701CC098; Wed, 16 Jul 2008 07:10:56 -0700 (PDT) Date: Wed, 16 Jul 2008 07:10:56 -0700 From: Jeremy Chadwick To: Rob Message-ID: <20080716141056.GA9656@eos.sc1.parodius.com> References: <784966050807160640q31f13160t91702a150bd5b152@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <784966050807160640q31f13160t91702a150bd5b152@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: I'm sorry about being a jerk regarding Sysinstall a week or so ago X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 14:26:18 -0000 On Wed, Jul 16, 2008 at 06:40:03AM -0700, Rob wrote: > I've very sorry about being such a jerk about my complaint regarding > Sysinstall a week or so ago. It was a week where I was getting 2 hours of > sleep per day. Finally my PCP had to intervene and knock me out with big > doses of sleeping pills. :) It occasionally happens, then I have half a > dozen apologies to make. I promise I will never mention Sysinstall again! > > I continue to use FreeBSD as I have for the last 10 years and I guess my > biggest contribution has been making it known to people and evangelizing it, > as it really does blow away Linux in performance. For what it's worth, I found the discussion interesting. I appreciate insights of users (not purely SAs), because it gives me a better idea of how people use tools differently than I do, and if they find the same quirks annoying that I do (which seems to be the case). I don't think you should be sorry, but your humbleness is noted. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 14:49:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79BB41065672 for ; Wed, 16 Jul 2008 14:49:04 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63915.mail.re1.yahoo.com (web63915.mail.re1.yahoo.com [69.147.97.130]) by mx1.freebsd.org (Postfix) with SMTP id 43D0A8FC08 for ; Wed, 16 Jul 2008 14:49:04 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 13889 invoked by uid 60001); 16 Jul 2008 14:49:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=QkY9/pxYniKN3mMBJ2n9M5tGx+hDvsd1iI+w3lyzfH/gP5+nqllCoHAcFVFdF8ArqRkq2tKq2+B5pY7gdClseRNp3B9PqbcuopFhzUpY2th0Jrqm6tJQ+YA1V+vkT34sZEBv2bljnx8m0TcHLjGNLqhZBNKfbxncedhJPfWbcBQ=; Received: from [98.203.28.38] by web63915.mail.re1.yahoo.com via HTTP; Wed, 16 Jul 2008 07:49:03 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Wed, 16 Jul 2008 07:49:03 -0700 (PDT) From: Barney Cordoba To: Steve Kargl In-Reply-To: <20080715175944.GA80901@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <565436.13205.qm@web63915.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2008 14:49:04 -0000 --- On Tue, 7/15/08, Steve Kargl wrote: > From: Steve Kargl > Subject: ULE scheduling oddity > To: freebsd-current@freebsd.org > Date: Tuesday, July 15, 2008, 1:59 PM > It appears that the ULE scheduler is not providing a fair > slice to running processes. > > I have a dual-cpu, quad-core opteron based system with > node21:kargl[229] uname -a > FreeBSD node21.cimu.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3: > Wed Jun 4 16:22:49 PDT 2008 > kargl@node10.cimu.org:src/sys/HPC amd64 > > If I start exactly 8 processes, each gets 100% WCPU > according to > top. If I add to additional processes, then I observe > > last pid: 3874; load averages: 9.99, 9.76, 9.43 up > 0+19:54:44 10:51:18 > 41 processes: 11 running, 30 sleeping > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, > 0.0% idle > Mem: 5706M Active, 8816K Inact, 169M Wired, 84K Cache, 108M > Buf, 25G Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C > TIME WCPU COMMAND > 3836 kargl 1 118 0 577M 572M CPU7 7 > 6:37 100.00% kzk90 > 3839 kargl 1 118 0 577M 572M CPU2 2 > 6:36 100.00% kzk90 > 3849 kargl 1 118 0 577M 572M CPU3 3 > 6:33 100.00% kzk90 > 3852 kargl 1 118 0 577M 572M CPU0 0 > 6:25 100.00% kzk90 > 3864 kargl 1 118 0 577M 572M RUN 1 > 6:24 100.00% kzk90 > 3858 kargl 1 112 0 577M 572M RUN 5 > 4:10 78.47% kzk90 > 3855 kargl 1 110 0 577M 572M CPU5 5 > 4:29 67.97% kzk90 > 3842 kargl 1 110 0 577M 572M CPU4 4 > 4:24 66.70% kzk90 > 3846 kargl 1 107 0 577M 572M RUN 6 > 3:22 53.96% kzk90 > 3861 kargl 1 107 0 577M 572M CPU6 6 > 3:15 53.37% kzk90 > > I would have expected to see a more evenly distributed WCPU > of around > 80% for each process. So, do I need to tune one or more of > the > following sysctl values? Is this a side effect of cpu > affinity > being a tad too aggressive? > > node21:kargl[231] sysctl -a | grep sched | more > kern.sched.preemption: 1 > kern.sched.steal_thresh: 3 > kern.sched.steal_idle: 1 > kern.sched.steal_htt: 1 > kern.sched.balance_interval: 133 > kern.sched.balance: 1 > kern.sched.affinity: 1 > kern.sched.idlespinthresh: 4 > kern.sched.idlespins: 10000 > kern.sched.static_boost: 160 > kern.sched.preempt_thresh: 64 > kern.sched.interact: 30 > kern.sched.slice: 13 > kern.sched.name: ULE > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I don't see why "equal" distribution is or should be a goal, as that does not guarantee optimization. Given that the cache is shared between only 2 cpus, it might very well be more efficient to run on 2 CPUs when the 3rd or 4th isn't needed. It works pretty darn well, IMO. Its not like your little app is the only thing going on in the system From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 14:53:42 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 435F7106566C for ; Wed, 16 Jul 2008 14:53:42 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id CF5558FC16 for ; Wed, 16 Jul 2008 14:53:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 57682 invoked by uid 60001); 16 Jul 2008 14:27:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=dX2FAU9xYT8Xfdz3BMVSzfrYpeowSkaarusY0oMNYjlayKj8tnO9Ru6Gms68xoCAQP2/Ou7rxKvCDumbLffcnYal5F3NNYvo7kN1JWz0pzzqbFZplRhMTUBPvHYImjgkPgYsWrMq+JO2afCeOVAfO2KwTUqF5nQABI3TrY9Tj8Y=; Received: from [98.203.28.38] by web63908.mail.re1.yahoo.com via HTTP; Wed, 16 Jul 2008 07:26:59 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Wed, 16 Jul 2008 07:26:59 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <334863.57605.qm@web63908.mail.re1.yahoo.com> Cc: sos@freebsd.org Subject: DVD-ROM problem with Freebsd 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2008 14:53:42 -0000 I'm debugging a problem with an Intel Bigby chipset and a DVD-ROM drive. We've swapped it out with a regular CD-ROM and have the same problem, so its likely not the drive. It gets probed as ATA_I82801IB_AH6. The problem is that certain types of media don't work. Some work, some don't. We're going to build a LINUX system to try to see if its the driver or some physical thing, but the media works on our other systems so it appears to be the driver. In pouring over the drivers, I've noticed that the setmode function never seems to get called, and I'm wondering what the point of the setup variables are if they're never called. What should be the sequence of calls to properly set up the controller? Barney From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 20:00:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4B1C1065677 for ; Wed, 16 Jul 2008 20:00:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 28E768FC17 for ; Wed, 16 Jul 2008 20:00:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 4023 invoked by uid 399); 16 Jul 2008 20:00:01 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Jul 2008 20:00:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <487E533F.7050303@FreeBSD.org> Date: Wed, 16 Jul 2008 12:59:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 20:00:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 FYI. If you are familiar with kerberos stuff and want to add shutdown there, please feel free. Same goes with the network stuff if you feel strongly it should be added. By the same token, if adding shutdown breaks something please feel free to revert it. The only thing I ask is that you clarify the reasons in the commit message for posterity. I've run with this locally for quite a while and just haven't had a chance to commit it. OTOH I don't use most of the stuff covered by this, so I'd like to get it tested in real world conditions for a while before it's MFC'ed. Regards, Doug - -------- Original Message -------- Subject: svn commit: r180564 - head/etc/rc.d Date: Wed, 16 Jul 2008 19:50:29 +0000 (UTC) From: Doug Barton To: src-committers@freebsd.org Author: dougb Date: Wed Jul 16 19:50:29 2008 New Revision: 180564 URL: http://svn.freebsd.org/changeset/base/180564 Log: ~ Add the shutdown KEYWORD to those scripts that start persistent ~ services to allow them to do a "clean" shutdown. ~ I purposely avoided making changes to network-related stuff since ~ the system shutting down is pretty conclusive, and there may be ~ complicated dependencies on the network that I would rather not try ~ to unravel. ~ I also skipped kerberos-related stuff for the reasons above, and ~ because I have no way to test it. - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkh+Uz8ACgkQyIakK9Wy8PsgwQCgkhGTv4eIfbyEUOjckuh0J+jV 6LsAn1Q1r/RzqrIwfTWbEXrKyh+TyEz3 =vsrN -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 20:35:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92521065766 for ; Wed, 16 Jul 2008 20:35:07 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6398FC2B for ; Wed, 16 Jul 2008 20:35:07 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.2) with ESMTP id m6GKIL2T008428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Jul 2008 15:18:21 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.2/Submit) id m6GKIKBU008392; Wed, 16 Jul 2008 15:18:20 -0500 (CDT) (envelope-from dan) Date: Wed, 16 Jul 2008 15:18:20 -0500 From: Dan Nelson To: Doug Barton Message-ID: <20080716201819.GB19044@dan.emsphone.com> References: <487E533F.7050303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487E533F.7050303@FreeBSD.org> X-OS: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 20:35:07 -0000 In the last episode (Jul 16), Doug Barton said: > I've run with this locally for quite a while and just haven't had a > chance to commit it. OTOH I don't use most of the stuff covered by > this, so I'd like to get it tested in real world conditions for a > while before it's MFC'ed. > > URL: http://svn.freebsd.org/changeset/base/180564 > Log: > ~ Add the shutdown KEYWORD to those scripts that start persistent > ~ services to allow them to do a "clean" shutdown. > > ~ I purposely avoided making changes to network-related stuff since > ~ the system shutting down is pretty conclusive, and there may be > ~ complicated dependencies on the network that I would rather not try > ~ to unravel. I think shutdown should be reserved for programs that save state between instances or otherwise would cause a "cleanup" operation to run then next time they are started after an unclean shutdown. Adding shutdown to things like amd, mountd, moused, etc. simply forces what would be done in init's final SIGTERM sweep to be done sequentially instead of in parallel. Also, if any of those daemons doesn't want to immediately exit for some reason (amd hanging on a stuck mountpoint, for example), it increases the likelyhood of the global shutdown timer expiring and force-killing other daemons that might have wanted the chance to shut down cleanly. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 20:45:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B5BE1065674 for ; Wed, 16 Jul 2008 20:45:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 02CBE8FC20 for ; Wed, 16 Jul 2008 20:45:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 18061 invoked by uid 399); 16 Jul 2008 20:45:03 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Jul 2008 20:45:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <487E5DCD.3010206@FreeBSD.org> Date: Wed, 16 Jul 2008 13:45:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Dan Nelson References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> In-Reply-To: <20080716201819.GB19044@dan.emsphone.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 20:45:04 -0000 Dan Nelson wrote: > In the last episode (Jul 16), Doug Barton said: >> I've run with this locally for quite a while and just haven't had a >> chance to commit it. OTOH I don't use most of the stuff covered by >> this, so I'd like to get it tested in real world conditions for a >> while before it's MFC'ed. >> >> URL: http://svn.freebsd.org/changeset/base/180564 >> Log: >> ~ Add the shutdown KEYWORD to those scripts that start persistent >> ~ services to allow them to do a "clean" shutdown. >> >> ~ I purposely avoided making changes to network-related stuff since >> ~ the system shutting down is pretty conclusive, and there may be >> ~ complicated dependencies on the network that I would rather not try >> ~ to unravel. > > I think shutdown should be reserved for programs that save state > between instances or otherwise would cause a "cleanup" operation to run > then next time they are started after an unclean shutdown. That's not an unreasonable argument, however IMO it's better to be safe than sorry. > Adding > shutdown to things like amd, mountd, moused, etc. simply forces what > would be done in init's final SIGTERM sweep to be done sequentially > instead of in parallel. The ability to do things sequentially is a key benefit of the rc.d system. The fact that we have not been taking full advantage of that to date is (once again IMO) an oversight. > Also, if any of those daemons doesn't want to > immediately exit for some reason (amd hanging on a stuck mountpoint, > for example), it increases the likelyhood of the global shutdown timer > expiring and force-killing other daemons that might have wanted the > chance to shut down cleanly. That's a valid concern, which is why I want this to get real world testing before we consider MFC'ing it. As I said above, if this change causes real problems then those problems can easily be fixed. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 20:51:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C206106564A for ; Wed, 16 Jul 2008 20:51:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id E7A118FC0C for ; Wed, 16 Jul 2008 20:51:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 28112 invoked by uid 399); 16 Jul 2008 20:51:03 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Jul 2008 20:51:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <487E5F36.201@FreeBSD.org> Date: Wed, 16 Jul 2008 13:51:02 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Dan Nelson References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> In-Reply-To: <487E5DCD.3010206@FreeBSD.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 20:51:04 -0000 Doug Barton wrote: > Dan Nelson wrote: >> I think shutdown should be reserved for programs that save state >> between instances or otherwise would cause a "cleanup" operation to run >> then next time they are started after an unclean shutdown. > > That's not an unreasonable argument, however IMO it's better to be safe > than sorry. I forgot to add that (as you pointed out) init is going to be sending SIGTERM to the process anyway, so the only real difference here in most cases is the order in which the shutdown will happen. Thus this change will either do good, or do no harm. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 21:03:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52FCC1065679; Wed, 16 Jul 2008 21:03:23 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:d8:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0AEFA8FC1A; Wed, 16 Jul 2008 21:03:23 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: by pinus.izb.knu.ac.kr (Postfix, from userid 59) id B080F3EA4; Thu, 17 Jul 2008 06:03:19 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pinus.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-48.6 required=15.1 tests=DKIM_SIGNED,DKIM_VERIFIED autolearn=disabled version=3.2.3 Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 5EC303EA3; Thu, 17 Jul 2008 06:03:18 +0900 (KST) Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=izb.knu.ac.kr; h= subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:content-transfer-encoding; q=dns/txt; s= s1024; bh=znzz/tOGDPazbfSX5lE6djsoC81QJuG9mU8XLsEuAuY=; b=Fu7iBj iSyjG48trPgqt82lSAG95wNCBttndvNNw+Iywxv7DxlKWs+d68RAb+eboZSYWEmZ CFSOYNt5HsO3xexlEi3me08DX73Qy1OAPXeb40vWSxqIe+kta7p7wx04ff8MrP0p YJdSWUTrzW1lQA8tfKPw62/nNtla4aOFklzjI= Received: from [IPv6:2001:470:1f05:d8:3::2] (jihad.izb.knu.ac.kr [IPv6:2001:470:1f05:d8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 40BF63EA0; Thu, 17 Jul 2008 06:03:18 +0900 (KST) From: Byung-Hee HWANG To: Ken Smith In-Reply-To: <1215119650.75067.10.camel@neo.cse.buffalo.edu> References: <1215119650.75067.10.camel@neo.cse.buffalo.edu> Content-Type: text/plain Organization: InZealBomb Date: Thu, 17 Jul 2008 06:02:55 +0900 Message-Id: <1216242176.34454.7.camel@jihad.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: cvsup server reachable via IPv6... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 21:03:23 -0000 On Thu, 2008-07-03 at 17:14 -0400, Ken Smith wrote: > If any of you have been wishing there was an IPv6-capable cvsup server > you could use (with csup as the client obviously since cvsup doesn't do > IPv6...) give cvsup18.freebsd.org a try. With the help of a few other > folks I got nudged into giving inetd/netcat a try as a means to feed > IPv6 connections to the cvsupd server process. > > If you try it and have problems let me know. cvsup18 is my "little > server" (handles between 200 and 300 connects a day) but if this seems > to work OK I can give it a try on my "big server" (handles between 3000 > and 4000 connects a day...). > also i checked the speed of cvsup18.freebsd.org by csup(1) a few minutes ago ;; now i want to say that's good! bh -- "But aside from that let me swear by the souls of my grandchildren that I will never break the peace we have made." -- Vito Corleone, "Chapter 20", page 292 From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 21:13:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DCA6106566C for ; Wed, 16 Jul 2008 21:13:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id C7A788FC15 for ; Wed, 16 Jul 2008 21:13:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m6GLDH3M092562; Wed, 16 Jul 2008 14:13:17 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m6GLDHeF092561; Wed, 16 Jul 2008 14:13:17 -0700 (PDT) (envelope-from sgk) Date: Wed, 16 Jul 2008 14:13:17 -0700 From: Steve Kargl To: Barney Cordoba Message-ID: <20080716211317.GA92354@troutmask.apl.washington.edu> References: <20080715175944.GA80901@troutmask.apl.washington.edu> <565436.13205.qm@web63915.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565436.13205.qm@web63915.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 21:13:18 -0000 On Wed, Jul 16, 2008 at 07:49:03AM -0700, Barney Cordoba wrote: > --- On Tue, 7/15/08, Steve Kargl wrote: > > last pid: 3874; load averages: 9.99, 9.76, 9.43 up 0+19:54:44 10:51:18 > > 41 processes: 11 running, 30 sleeping > > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle > > Mem: 5706M Active, 8816K Inact, 169M Wired, 84K Cache, 108M > > Buf, 25G Free > > Swap: 4096M Total, 4096M Free > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 3836 kargl 1 118 0 577M 572M CPU7 7 6:37 100.00% kzk90 > > 3839 kargl 1 118 0 577M 572M CPU2 2 6:36 100.00% kzk90 > > 3849 kargl 1 118 0 577M 572M CPU3 3 6:33 100.00% kzk90 > > 3852 kargl 1 118 0 577M 572M CPU0 0 6:25 100.00% kzk90 > > 3864 kargl 1 118 0 577M 572M RUN 1 6:24 100.00% kzk90 > > 3858 kargl 1 112 0 577M 572M RUN 5 4:10 78.47% kzk90 > > 3855 kargl 1 110 0 577M 572M CPU5 5 4:29 67.97% kzk90 > > 3842 kargl 1 110 0 577M 572M CPU4 4 4:24 66.70% kzk90 > > 3846 kargl 1 107 0 577M 572M RUN 6 3:22 53.96% kzk90 > > 3861 kargl 1 107 0 577M 572M CPU6 6 3:15 53.37% kzk90 > > > > I would have expected to see a more evenly distributed WCPU > > of around 80% for each process. > > I don't see why "equal" distribution is or should be a goal, as that > does not guarantee optimization. The above images may be parts of an MPI application. Synchronization problems simply kill performance. The PIDs with 100% WCPU could be spinning in a loop waiting for PID 3861 to send a message after completing a computation. The factor of 2 difference in TIME for PID 3836 and 3861 was still observed after more than an hour of accumulated time for 3836. It appears as if the algorithm for cpu affinity is punishing 3846 and 3861. > Given that the cache is shared between only 2 cpus, it might very well > be more efficient to run on 2 CPUs when the 3rd or 4th isn't needed. > > It works pretty darn well, IMO. Its not like your little app is the > only thing going on in the system Actually, 10 copies of the little app are the only things running except top(1) and few sleeping system services (e.g., nfsd and sshd). Apparently, you missed the "41 processes: 11 running, 30 sleeping" line above. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 21:27:15 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107DE106566C; Wed, 16 Jul 2008 21:27:15 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id C28808FC18; Wed, 16 Jul 2008 21:27:14 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m6GL36Wb020806; Wed, 16 Jul 2008 17:03:06 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m6GL36PO020805; Wed, 16 Jul 2008 17:03:06 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 16 Jul 2008 17:03:06 -0400 From: David Schultz To: Doug Barton Message-ID: <20080716210306.GA20758@zim.MIT.EDU> Mail-Followup-To: Doug Barton , Dan Nelson , freebsd-current@FreeBSD.ORG References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487E5DCD.3010206@FreeBSD.org> Cc: freebsd-current@FreeBSD.ORG, Dan Nelson Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 21:27:15 -0000 On Wed, Jul 16, 2008, Doug Barton wrote: > Dan Nelson wrote: > >Adding > >shutdown to things like amd, mountd, moused, etc. simply forces what > >would be done in init's final SIGTERM sweep to be done sequentially > >instead of in parallel. > > The ability to do things sequentially is a key benefit of the rc.d > system. The fact that we have not been taking full advantage of that > to date is (once again IMO) an oversight. A niftier trick would be to actually denote the shutdown dependencies between apps. Then SIGTERM (or whatever the appropriate shutdown operation is) can happen in parallel as much as possible, without accidentally shutting down a service before dependent services have had a chance to clean up. There's probably not as many interesting deps for shutdown as there are for startup... From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 22:09:59 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F3E01065674; Wed, 16 Jul 2008 22:09:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC118FC1F; Wed, 16 Jul 2008 22:09:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04] (unknown [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 22B983C; Thu, 17 Jul 2008 00:09:58 +0200 (CEST) Message-ID: <487E71B4.305@andric.com> Date: Thu, 17 Jul 2008 00:09:56 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.17pre (Windows/20080712) MIME-Version: 1.0 To: Doug Barton , Dan Nelson , freebsd-current@FreeBSD.ORG References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> <20080716210306.GA20758@zim.MIT.EDU> In-Reply-To: <20080716210306.GA20758@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 22:09:59 -0000 On 2008-07-16 23:03, David Schultz wrote: > A niftier trick would be to actually denote the shutdown > dependencies between apps. Then SIGTERM (or whatever the > appropriate shutdown operation is) can happen in parallel as much > as possible, without accidentally shutting down a service before > dependent services have had a chance to clean up. There's probably > not as many interesting deps for shutdown as there are for > startup... Possibly just the "reverse" of the startup deps? For example, if baz is dependent on foo and bar, the startup order is: 1. foo & bar (possibly parallel) 2. baz at shutdown, we'd get the reverse: 1. baz 2. foo & bar (possibly parallel) However, this may not be so easy for the total dependency graph of everything under /etc/rc.d (not to forget /usr/local/etc/rc.d). ;) From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 22:17:10 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BAEC106566B; Wed, 16 Jul 2008 22:17:10 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id CEA568FC14; Wed, 16 Jul 2008 22:17:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04] (unknown [IPv6:2001:7b8:3a7:0:4889:afda:a548:e04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2347A3C; Thu, 17 Jul 2008 00:17:09 +0200 (CEST) Message-ID: <487E7364.2040909@andric.com> Date: Thu, 17 Jul 2008 00:17:08 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.17pre (Windows/20080712) MIME-Version: 1.0 To: Doug Barton , Dan Nelson , freebsd-current@FreeBSD.ORG References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> <20080716210306.GA20758@zim.MIT.EDU> <487E71B4.305@andric.com> In-Reply-To: <487E71B4.305@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2008 22:17:10 -0000 On 2008-07-17 00:09, Dimitry Andric wrote: > Possibly just the "reverse" of the startup deps? Ah, I just see this in rc(8): Operation of rc.shutdown ... 3. Invoke rcorder(8) to order the files in /etc/rc.d/ and the $local_startup directories that have a ``shutdown'' KEYWORD (refer to rcorder(8)'s -k flag), reverse that order, and assign the result to a variable. e.g. it's already taken care of, apparently. :) Sorry for the noise. From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 01:44:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7828E1065672 for ; Thu, 17 Jul 2008 01:44:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 008D98FC26 for ; Thu, 17 Jul 2008 01:44:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so7136831rvf.43 for ; Wed, 16 Jul 2008 18:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NL2dp6QGJu5AtLXiWatM9c3DuDMwIwvhbCNs/NC0gck=; b=SvPHjWcKuW9ebFfGMGjrEJirUatMvUZHuOgAjcxNabvkm4+sBZec7lXWpvqV7FIlkx oj2blWuZInxeU6t8lawzTlVNfzuLLje8f1nTXfLUUSH/+v4H1NmNtcuR7iaTiIV6ZntD +KUz7dSNkTd9UIjfp+3XlqCovGAevSRU1SbgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RPTZak83MPbFKNfVXMw7Mo5sqjXkAvBCqYYBpoG2iU4qelyr68mySRwd+s65NEKGB1 xfGUI2jSWIQOTnaaC/penciAYCquaauMhMYuFuKpSglG/5M53DKRdrwuxGsfB5Pi+Ta0 ZsXHYpQ9RS38j6iNIFGm5W69GPxqvhJkyNF2g= Received: by 10.140.202.12 with SMTP id z12mr806496rvf.186.1216259066827; Wed, 16 Jul 2008 18:44:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id f21sm15077889rvb.0.2008.07.16.18.44.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jul 2008 18:44:25 -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 m6H1gFxU049139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 10:42:15 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m6H1gEmb049138; Thu, 17 Jul 2008 10:42:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 17 Jul 2008 10:42:14 +0900 From: Pyun YongHyeon To: Dimitry Andric Message-ID: <20080717014214.GB48743@cdnetworks.co.kr> References: <484D215A.7050700@andric.com> <20080609123206.GF12521@cdnetworks.co.kr> <484D25CC.9050106@andric.com> <20080610050550.GB17874@cdnetworks.co.kr> <484E9377.2050609@andric.com> <20080611005814.GA3529@cdnetworks.co.kr> <48666CD7.9020706@andric.com> <20080630043156.GB79537@cdnetworks.co.kr> <20080714013519.GE36245@cdnetworks.co.kr> <487DA2E5.3080201@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487DA2E5.3080201@andric.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: re(4) and RTL8168C/RTL8168CP/RTL8111C/RTL8111CP 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: Thu, 17 Jul 2008 01:44:27 -0000 On Wed, Jul 16, 2008 at 09:27:33AM +0200, Dimitry Andric wrote: > On 2008-07-14 03:35, Pyun YongHyeon wrote: > > Here is patch for re(4) link handling. > > Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply > > attached one. If you still see watchdog timeouts, please turn off > > TSO and let me know how it goes. > > I've tested this trough several reboots, and I haven't been bitten by > any watchdogs yet. :) I'll run some stress tests today, to see if it > handles that too. > > > > One user reported TSO issues on 8169 family controllers but I > > can't reproduce this on my 8169 hardware so it could be related > > with silicon bug of sepecific revision of the hardware. > > I'm using re's default settings, which seem to be: > > re0: flags=8843 metric 0 mtu 1500 > options=399b > > So TSO for IPv4 but not IPv6, right? I haven't yet seen any problems Yes. > because of it. What would be a good way to "exercise" TSO? One developer reported TSO breakage on 8169 controller but I couldn't reproduce it on my hardware. It seems that the TSO breakage also resulted in watchdog timeouts for his case. Just plain bulk-transfers of large files(ftp, scp etc) will automatically take advantage of TSO feature. You can easily check them with tcpdump on Tx side as TCP segment size is larger than interface MTU. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 01:50:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A08A106564A for ; Thu, 17 Jul 2008 01:50:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id D46CF8FC20 for ; Thu, 17 Jul 2008 01:50:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so3533656pyb.10 for ; Wed, 16 Jul 2008 18:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MTXdBdR4wV/oxOIbHbc5CxhSquXb673LevyrDB0VOHc=; b=hOwzZdX4qEc0edo0zmhgitFGVvzifQ6CXAPAm17dnarxoUz+uxzuNDwzO4nizGtVlG rKuiSrbP24zi6dgPmC0E92YnlZ1JE6eXAAHAqMyG5E+ZgPjlcVAtV+wwrri312wmvA/u SNY1iW0e7229iKNdiJ08I7+dhN270OmLOhWxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=D1VrLo7paEsFZ6TVxYAsyFHyBckzhrbz8B0v8/uTvJ8VpC+47hTlNi8fZJbh0XHl/m vOqM3yRWxAAm5TvAlENVw4mMmiqdDebCZhXla+5tn/wjbY6uqMsDHypbzLkflQRAWpII hbdwVsmcpAfuROu0FzRFl8AeSUZymn0Ljj/2Y= Received: by 10.141.152.8 with SMTP id e8mr848965rvo.19.1216259433781; Wed, 16 Jul 2008 18:50:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b8sm5485899rvf.8.2008.07.16.18.50.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jul 2008 18:50:32 -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 m6H1mMU2049167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 10:48:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m6H1mJuj049166; Thu, 17 Jul 2008 10:48:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 17 Jul 2008 10:48:18 +0900 From: Pyun YongHyeon To: Johan Hendriks Message-ID: <20080717014818.GC48743@cdnetworks.co.kr> References: <487DA2E5.3080201@andric.com> <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> User-Agent: Mutt/1.4.2.1i Cc: Dimitry Andric , freebsd-current@freebsd.org Subject: Re: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP 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: Thu, 17 Jul 2008 01:50:35 -0000 On Wed, Jul 16, 2008 at 09:45:33AM +0200, Johan Hendriks wrote: > > > >Aan: pyunyh@gmail.com > >CC: freebsd-current@FreeBSD.org > >Onderwerp: Re: Call for testers: re(4) >andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP > > >On 2008-07-14 03:35, Pyun YongHyeon wrote: > >> Here is patch for re(4) link handling. > >> Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply > >> attached one. If you still see watchdog timeouts, please turn off > >> TSO and let me know how it goes. > > >I've tested this trough several reboots, and I haven't been bitten by > >any watchdogs yet. :) I'll run some stress tests today, to see if it > >handles that too. > > > >> One user reported TSO issues on 8169 family controllers but I > >> can't reproduce this on my 8169 hardware so it could be related > >> with silicon bug of sepecific revision of the hardware. > > >I'm using re's default settings, which seem to be: > > >re0: flags=8843 metric 0 mtu 1500 > >options=399bST,WOL_MCAST,WOL_MAGIC> > > >So TSO for IPv4 but not IPv6, right? I haven't yet seen any problems > >because of it. What would be a good way to "exercise" TSO? > > > I had a re(4) card that did crash 7-stable now i cvsuped to 15-07-2008 and did a rebuild > > The system is now in "production" and I see the following in /var/log/messages. > > Jul 15 18:24:40 intranet kernel: re0: watchdog timeout > Jul 15 18:24:40 intranet kernel: re0: link state changed to DOWN > Jul 15 18:24:43 intranet kernel: re0: link state changed to UP > Jul 15 19:28:03 intranet ntpd[883]: kernel time sync enabled 6001 > Jul 15 19:45:08 intranet ntpd[883]: kernel time sync enabled 2001 > Jul 15 20:04:41 intranet kernel: re0: watchdog timeout > Jul 15 20:04:41 intranet kernel: re0: link state changed to DOWN > Jul 15 20:04:43 intranet kernel: re0: link state changed to UP > Jul 15 21:14:40 intranet kernel: re0: watchdog timeout > Jul 15 21:14:40 intranet kernel: re0: link state changed to DOWN > Jul 15 21:14:43 intranet kernel: re0: link state changed to UP > Jul 15 21:19:41 intranet kernel: re0: watchdog timeout > Jul 15 21:19:41 intranet kernel: re0: link state changed to DOWN > Jul 15 21:19:43 intranet kernel: re0: link state changed to UP > Jul 15 21:24:40 intranet kernel: re0: watchdog timeout > Jul 15 21:24:40 intranet kernel: re0: link state changed to DOWN > Jul 15 21:24:43 intranet kernel: re0: link state changed to UP > Jul 15 22:14:40 intranet kernel: re0: watchdog timeout > Jul 15 22:14:40 intranet kernel: re0: link state changed to DOWN > Jul 15 22:14:43 intranet kernel: re0: link state changed to UP > Jul 16 03:20:53 intranet kernel: re0: watchdog timeout > Jul 16 03:20:53 intranet kernel: re0: link state changed to DOWN > Jul 16 03:20:56 intranet kernel: re0: link state changed to UP > Jul 16 03:24:41 intranet kernel: re0: watchdog timeout > Jul 16 03:24:41 intranet kernel: re0: link state changed to DOWN > Jul 16 03:24:43 intranet kernel: re0: link state changed to UP > Jul 16 03:25:53 intranet kernel: re0: watchdog timeout > Jul 16 03:25:53 intranet kernel: re0: link state changed to DOWN > Jul 16 03:25:56 intranet kernel: re0: link state changed to UP > Jul 16 03:44:40 intranet kernel: re0: watchdog timeout > Jul 16 03:44:40 intranet kernel: re0: link state changed to DOWN > Jul 16 03:44:43 intranet kernel: re0: link state changed to UP > Jul 16 04:23:32 intranet ntpd[883]: kernel time sync enabled 6001 > Jul 16 04:40:38 intranet ntpd[883]: kernel time sync enabled 2001 > Jul 16 05:19:41 intranet kernel: re0: watchdog timeout > Jul 16 05:19:41 intranet kernel: re0: link state changed to DOWN > Jul 16 05:19:44 intranet kernel: re0: link state changed to UP > Jul 16 06:19:40 intranet kernel: re0: watchdog timeout > Jul 16 06:19:40 intranet kernel: re0: link state changed to DOWN > Jul 16 06:19:43 intranet kernel: re0: link state changed to UP > Jul 16 08:14:40 intranet kernel: re0: watchdog timeout > Jul 16 08:14:40 intranet kernel: re0: link state changed to DOWN > Jul 16 08:14:43 intranet kernel: re0: link state changed to UP > Jul 16 08:44:41 intranet kernel: re0: watchdog timeout > Jul 16 08:44:41 intranet kernel: re0: link state changed to DOWN > Jul 16 08:44:44 intranet kernel: re0: link state changed to UP > > It is a small intranet webserver and does cacti and nagios things and mirror cvs for the other machines. > > #pciconf -lv > re0@pci0:2:0:0: class=0x020000 card=0x2a73103c chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = Ethernet > > # dmesg > re0: port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 > re0: Chip rev. 0x3c000000 It's RealTek 8139C controller. > re0: MAC rev. 0x00200000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:1e:0b:a7:cc:38 > re0: [FILTER] > > It also not always load ok on a reboot ! > Sometimes it complains about something with PHY I know this issue on second generation of PCIe controllers but have no clue yet. I vaguely guess it's related with power-saving or initial hardware reset related stuff. > A reboot than fix this and loads the re0 driver. > It would be even better if you can try patch I posted earlier in this thread. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 02:08:11 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6170D1065681; Thu, 17 Jul 2008 02:08:11 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 18D698FC13; Thu, 17 Jul 2008 02:08:10 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m6H28Jau022174; Wed, 16 Jul 2008 22:08:19 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m6H28Jmn022173; Wed, 16 Jul 2008 22:08:19 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 16 Jul 2008 22:08:19 -0400 From: David Schultz To: Dimitry Andric Message-ID: <20080717020819.GA22145@zim.MIT.EDU> Mail-Followup-To: Dimitry Andric , Doug Barton , Dan Nelson , freebsd-current@FreeBSD.ORG References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> <20080716210306.GA20758@zim.MIT.EDU> <487E71B4.305@andric.com> <487E7364.2040909@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487E7364.2040909@andric.com> Cc: Doug Barton , Dan Nelson , freebsd-current@FreeBSD.ORG Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 02:08:11 -0000 On Thu, Jul 17, 2008, Dimitry Andric wrote: > On 2008-07-17 00:09, Dimitry Andric wrote: > > Possibly just the "reverse" of the startup deps? > > Ah, I just see this in rc(8): > > Operation of rc.shutdown > ... > 3. Invoke rcorder(8) to order the files in /etc/rc.d/ and the > $local_startup directories that have a ``shutdown'' KEYWORD (refer > to rcorder(8)'s -k flag), reverse that order, and assign the result > to a variable. > > e.g. it's already taken care of, apparently. :) This just reverses the startup deps, as you suggested earlier. I seem to recall that there was at least one example from Solaris where that was the wrong thing to do. (Clearly it's also overly conservative in some cases.) But they were trying to do more sophistocated things as well, such as automatically restart failed services. (This isn't trivial because when services depend on each other, it's hard to tell which one failed, and it may even take some trial and error.) Maybe we just haven't run into any situations where it matters. From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 11:41:06 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F201065679 for ; Thu, 17 Jul 2008 11:41:06 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2D18FC2B for ; Thu, 17 Jul 2008 11:41:05 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [80.126.205.144]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id m6HBf3TY053755; Thu, 17 Jul 2008 13:41:03 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 Jul 2008 13:41:03 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DDFB7@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP Thread-Index: AcjnNHt7SHCxtuAPSSKSHn2k041HywAzHrAg References: <484BC9FB.2040605@andric.com><20080609012657.GD12521@cdnetworks.co.kr><484D215A.7050700@andric.com><20080609123206.GF12521@cdnetworks.co.kr><484D25CC.9050106@andric.com><20080610050550.GB17874@cdnetworks.co.kr><484E9377.2050609@andric.com><20080611005814.GA3529@cdnetworks.co.kr><48666CD7.9020706@andric.com><20080630043156.GB79537@cdnetworks.co.kr><20080714013519.GE36245@cdnetworks.co.kr> <487DA2E5.3080201@andric.com> <57200BF94E69E54880C9BB1AF714BBCB5DDFA7@w2003s01.double-l.local> <487DB779.50609@andric.com> <57200BF94E69E54880C9BB1AF714BBCB5DDFAB@w2003s01.double-l.local> <487DD663.7050906@andric.com> From: "Johan Hendriks" To: "Dimitry Andric" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: pyunyh@gmail.com, freebsd-current@FreeBSD.org Subject: RE: Call for testers: re(4) andRTL8168C/RTL8168CP/RTL8111C/RTL8111CP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 11:41:06 -0000 On 2008-07-16 12:46, Johan Hendriks wrote: > Ok rebuild done, and all looks OK >=20 > I will watch it through the day and report tomorrow! This is what i see now. Much less watchdog timeouts. Jul 16 12:42:58 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 16 17:08:16 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 16 17:25:21 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 16 17:59:31 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 16 18:16:34 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 16 19:41:58 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 16 19:59:03 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 16 20:35:53 intranet kernel: re0: watchdog timeout=20 Jul 16 20:35:53 intranet kernel: re0: link state changed to DOWN=20 Jul 16 20:35:56 intranet kernel: re0: link state changed to UP=20 Jul 16 20:55:53 intranet kernel: re0: watchdog timeout=20 Jul 16 20:55:53 intranet kernel: re0: link state changed to DOWN Jul 16 = 20:55:56 intranet kernel: re0: link state changed to UP=20 Jul 16 22:49:47 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 16 23:06:51 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 17 00:32:15 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 17 00:49:18 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 17 01:30:53 intranet kernel: re0: watchdog timeout=20 Jul 17 01:30:53 intranet kernel: re0: link state changed to DOWN=20 Jul 17 01:30:56 intranet kernel: re0: link state changed to UP=20 Jul 17 03:23:00 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 17 03:40:03 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 17 05:05:23 intranet ntpd[911]: kernel time sync enabled 6001=20 Jul 17 05:56:35 intranet ntpd[911]: kernel time sync enabled 2001=20 Jul 17 09:15:12 intranet su: beheer to root on /dev/ttyp0 It is a basic FreeBSD 7-stable amd64 intel core2 box If I can do something else let me now. Regards, Johan Hendriks =20 No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.138 / Virus Database: 270.5.0/1557 - Release Date: = 17-7-2008 5:36 From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 11:53:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC69A106566C for ; Thu, 17 Jul 2008 11:53:53 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1328FC12 for ; Thu, 17 Jul 2008 11:53:52 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from honshu.net.informatik.tu-muenchen.de ([131.159.14.60]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJS3R-0001py-VR for freebsd-current@freebsd.org; Thu, 17 Jul 2008 13:53:50 +0200 Message-ID: <487F32C6.5030502@lobraun.de> Date: Thu, 17 Jul 2008 13:53:42 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 11:53:53 -0000 Hi, I'm getting a kernel panic, whenever I try to work with an XFS file system with todays sources. I created the filesystem, mounted it and created a directory on it. The crash occurred when I tried to chown the directory. 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: panic: __lockmgr_args: unknown lockmgr request 0x0 cpuid = 1 Uptime: 25m36s Physical memory: 3314 MB Dumping 95 MB: 80 (CTRL-C to abort) 64 48 32 16 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/xfs.ko...Reading symbols from /boot/kernel/xfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/xfs.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc078f1cc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc078f489 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc077b83c in __lockmgr_args (lk=0xc6eecce8, flags=256, ilk=0xc6eecd04, wmesg=0x0, pri=0, timo=0, file=0xc0b2b883 "/usr/src/sys/kern/vfs_subr.c", line=2044) at /usr/src/sys/kern/kern_lock.c:848 #4 0xc0801cf2 in vop_stdlock (ap=0xe8fa7810) at lockmgr.h:93 #5 0xc0aac906 in VOP_LOCK1_APV (vop=0xc0bf5400, a=0xe8fa7810) at vnode_if.c:1618 #6 0xc081e64d in _vn_lock (vp=0xc6eecc90, flags=256, file=0xc0b2b883 "/usr/src/sys/kern/vfs_subr.c", line=2044) at vnode_if.h:845 #7 0xc080ea29 in vget (vp=0xc6eecc90, flags=0, td=0xc6a50460) at /usr/src/sys/kern/vfs_subr.c:2044 #8 0xc6e2f6a6 in vn_get (xfs_vp=0xc692d780, vmap=0xe8fa78c0) at /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_vnode.c:107 #9 0xc6df4cb2 in xfs_iget (mp=0xc6776800, tp=0x0, ino=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_freebsd_iget.c:164 #10 0xc6e160fc in xfs_dir_lookup_int (dir_bdp=0xc6ee9020, lock_mode=8, dentry=0xe8fa7bb0, inum=0xe8fa7938, ipp=0xe8fa7940) at /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_utils.c:97 #11 0xc6e1a75e in xfs_lookup (dir_bdp=0xc6ee9020, dentry=0xe8fa7bb0, vpp=0xe8fa79a8, flags=0, rdir=0x0, credp=0xc698e500) at /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_vnodeops.c:1828 #12 0xc6e2a973 in _xfs_cachedlookup (ap=0xe8fa79e0) at /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_vnops.c:1275 #13 0xc0aab322 in VOP_CACHEDLOOKUP_APV (vop=0xc6e367e0, a=0xe8fa79e0) at vnode_if.c:153 #14 0xc07ff8c0 in vfs_cache_lookup (ap=0xe8fa7a64) at vnode_if.h:80 #15 0xc0aacfe6 in VOP_LOOKUP_APV (vop=0xc6e367e0, a=0xe8fa7a64) at vnode_if.c:99 #16 0xc0806371 in lookup (ndp=0xe8fa7b84) at vnode_if.h:54 #17 0xc08071bb in namei (ndp=0xe8fa7b84) at /usr/src/sys/kern/vfs_lookup.c:239 #18 0xc0814a64 in kern_statat (td=0xc6a50460, flag=0, fd=-100, path=0x8104928
, pathseg=UIO_USERSPACE, sbp=0xe8fa7c18) at /usr/src/sys/kern/vfs_syscalls.c:2331 #19 0xc0814cf6 in kern_stat (td=0xc6a50460, path=0x8104928
, pathseg=UIO_USERSPACE, sbp=0xe8fa7c18) at /usr/src/sys/kern/vfs_syscalls.c:2313 #20 0xc0814d9f in stat (td=0xc6a50460, uap=0xe8fa7cf8) at /usr/src/sys/kern/vfs_syscalls.c:2282 #21 0xc0aa1075 in syscall (frame=0xe8fa7d38) at /usr/src/sys/i386/i386/trap.c:1081 #22 0xc0a86a90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Can I provide any additional information that could help to debug the problem? Best regards, Lothar From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 14:25:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35D8C1065680; Thu, 17 Jul 2008 14:25:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AC5178FC27; Thu, 17 Jul 2008 14:25:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6HEOvFW032292; Thu, 17 Jul 2008 10:25:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Jul 2008 09:19:49 -0400 User-Agent: KMail/1.9.7 References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <486F8C57.9050908@wubethiopia.com> <20080705161614.O19209@fledge.watson.org> In-Reply-To: <20080705161614.O19209@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807170919.49756.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 17 Jul 2008 10:25:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7736/Thu Jul 17 09:11:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mike Makonnen , Lothar Braun , Robert Watson , freebsd-hackers@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 14:25:17 -0000 On Saturday 05 July 2008 11:22:09 am Robert Watson wrote: > On Sat, 5 Jul 2008, Mike Makonnen wrote: > > > The installer can already install a basic FreeBSD system (including the > > ports collection) from CD, UFS, or DOS partition. I'm currently working on > > getting FTP/HTTP/NFS installation to work. Next on my list after that is > > setting Date and Time Zone. At that stage the installer will be more or less > > feature-complete, and I can start code cleanup, getting it to work on > > additional architectures, etc. I had initially intended to include package > > installation as one of the criteria for feature-completeness, but after > > reading through this thread I've decided not to use sysinstall's package > > installation code and instead write one from scratch once I'm happy with the > > rest of the installer. > > Sounds pretty much in line with what I was looking for. However, I think I > would like to see it be a bit more complete than sysinstall in the area of > geom partition labeling (concat/strip/raid/encryption), and perhaps also ZFS > support. I realize that adds complexity a fair amount, but one of the biggest > areas of feature lack in sysinstall today is that you are basically stuck with > the original BSD partition structure and UFS, whereas we expect increasing > numbers of users to deploy ZFS. We don't have boot support currently, but > being able to set up /data as a ZFS file system would be great. Today, people > have to do an initial install on, say, a small boot partition and then > relabel/deal with the rest of the disk, boot a live CD, or worse, discover > they have to repartition, which really fails to expose some of the excellent > ease-of-use, auto-configuration, etc, features that we otherwise have in this > area. I think the best route to that is to have a separate utility for managing disk partitioning. The installer can then use that utility, and sysadmins can also use it later after the system is installed. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 14:25:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D0131065680; Thu, 17 Jul 2008 14:25:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8854E8FC13; Thu, 17 Jul 2008 14:25:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6HEOvFX032292; Thu, 17 Jul 2008 10:25:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Jul 2008 09:23:52 -0400 User-Agent: KMail/1.9.7 References: <486FD2BA.8050505@telenix.org> <20080705220254.I51796@fledge.watson.org> <48701AA2.3010907@telenix.org> In-Reply-To: <48701AA2.3010907@telenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807170923.52408.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 17 Jul 2008 10:25:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7736/Thu Jul 17 09:11:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Watson , Chuck Robey Subject: Re: kernel modules wont load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 14:25:23 -0000 On Saturday 05 July 2008 09:06:42 pm Chuck Robey wrote: > Robert Watson wrote: > > > > On Sat, 5 Jul 2008, Chuck Robey wrote: > > > >> I can't get my oss sound to load, and the first error I get is this: > >> > >> osscore.ko: depends on kernel - not available > >> > >> That came from both the oss logging file and dmesg. I don't > >> understand what "depends on kernel" means, could I get a hint on > >> that? I think it's the reason that later oss modules don't load > >> correctly. > >> > >> Thanks for any help on this, I'd like to get my sound working again. > > > > In HEAD, we're currently building all modules with an automatic version > > dependency on the version of the kernel they are intended to run in. > > The error message should be telling you need version X but it found > > version Y, but doesn't, unfortunately. Rebuilding the module should get > > it working. I seem to recall printing the error better is awkward > > because the dependency failure is generated somewhere deep in the > > linker, and the error is printed on the surface, but should be fixable. > > Umm. OK, I'm pleased to hear about it, but just a touch skeptical that's my > problem, because I recompiled the osscore 2 hours ago, and the kernel is less > than 2 weeks old. It is possible, though, and I really appreciate the answer > (I'd never have tracked that one down, from your description). It probably means your world is newer than your kernel somehow as the osscore module build will use the __FreeBSD_version from /usr/include/sys/param.h while the kernel will support 800000 - the version in it's build tree's -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 14:25:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7CE1065722 for ; Thu, 17 Jul 2008 14:25:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 59F508FC2A for ; Thu, 17 Jul 2008 14:25:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6HEOvFY032292 for ; Thu, 17 Jul 2008 10:25:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Jul 2008 09:48:11 -0400 User-Agent: KMail/1.9.7 References: <232537.6371.qm@web57008.mail.re3.yahoo.com> In-Reply-To: <232537.6371.qm@web57008.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807170948.12039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 17 Jul 2008 10:25:22 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7736/Thu Jul 17 09:11:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Subject: Re: [PATCH] Fix /usr/src/usr.sbin/pw/pwupd.c - pw_update() return success on failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 14:25:28 -0000 On Monday 07 July 2008 12:03:23 am Unga wrote: > Hi all > > In the present implementation even if the pwdb() fails, pw_update() still return rc=0, therefore, subsequent functions still continue to proceed without passwd and master.passwd been updated. The attached patch fixes this issue. If this patch is acceptable, appreciate if it could be applied to both current and RELENG_7. Fix committed to HEAD, thanks! -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 15:11:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B051065676; Thu, 17 Jul 2008 15:11:26 +0000 (UTC) (envelope-from mbhavsar@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id AB1C88FC21; Thu, 17 Jul 2008 15:11:24 +0000 (UTC) (envelope-from mbhavsar@niksun.com) Received: from TecraA2195H (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id m6HEd26M012586; Thu, 17 Jul 2008 10:39:06 -0400 (EDT) (envelope-from mbhavsar@niksun.com) Message-Id: <200807171439.m6HEd26M012586@anuket.mj.niksun.com> From: "Mihir Bhavsar" To: Date: Thu, 17 Jul 2008 10:43:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1216242176.34454.7.camel@jihad.izb.knu.ac.kr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Acjnh4sTZMmMKnZtSHujopqdTEt1ogAkKMYQ X-Virus-Scanned: ClamAV 0.92/7736/Thu Jul 17 09:11:09 2008 on anuket.mj.niksun.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 17 Jul 2008 15:33:36 +0000 Cc: 'Byung-Hee HWANG' , 'Ken Smith' , 'freebsd-stable' Subject: iLO virtual Drive setup help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 15:11:26 -0000 Hi, I was trying to mount virtual CDROM using Intel RMM module. RMM module is capable of redirecting four iso images or drives, and looking in to /dev my filesystem FreeBSD has labeled those as /cd0, /cd1, /cd2, /cd3. Once I boot the system connecting virtual drive, it boots from that drive and after that it's asking about to select drive to boot from (here cd0, cd1, cd2, acd0), after that it is not going further. My "camcontrol devlist" output reflects following. at scbus0 target 0 lun 0 (cd0,pass0) at scbus1 target 0 lun 0 (cd1,pass1) at scbus2 target 0 lun 0 (cd2,pass2) at scbus3 target 0 lun 0 (cd3,pass3) When I try to mount cdrom with "mount_cd9660 /dev/cd0 /cdrom" it gives me following error G_vfs_done():cd0[READ(offset=32768, length-2048)]error = 5 Mount_cd9660: /dev/cd0: Input/output error My part of /etc/fstab file reads like following ********** ******** ****** **** /dev/cd0 /cdrom4 cd9660 ro,noauto 0 0 /dev/cd1 /cdrom1 cd9660 ro,noauto 0 0 /dev/cd2 /cdrom2 cd9660 ro,noauto 0 0 /dev/cd3 /cdrom3 cd9660 ro,noauto 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 ****** ***** ****** I am a newbie to FreeBSD, so any help really appreciated. Sincerely yours, M. Bhavsar From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 16:12:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C32C4106567C for ; Thu, 17 Jul 2008 16:12:46 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 8E81B8FC19 for ; Thu, 17 Jul 2008 16:12:46 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 38983 invoked by uid 60001); 17 Jul 2008 16:12:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=n9QhO8RmygwJbOSMI4tIft4OzqdD4Nd1XQ7C0DS4KGYPy9WjgEuBw5Nrs1PvSGmfHjlIgz7GCGrXlkdDRAWkZ2wrv2YAuTl7S1Z7Rcbhoil0TZ/8NH2sfxOJHo18n0qmR3gHm3yLmHecZ4tyibIbzzo+JHZKjhpEVA2KwJdXa/o=; Received: from [98.203.28.38] by web63902.mail.re1.yahoo.com via HTTP; Thu, 17 Jul 2008 09:12:45 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 17 Jul 2008 09:12:45 -0700 (PDT) From: Barney Cordoba To: Steve Kargl In-Reply-To: <20080716211317.GA92354@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <452221.38826.qm@web63902.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2008 16:12:46 -0000 --- On Wed, 7/16/08, Steve Kargl wrote: > From: Steve Kargl > Subject: Re: ULE scheduling oddity > To: "Barney Cordoba" > Cc: current@freebsd.org > Date: Wednesday, July 16, 2008, 5:13 PM > On Wed, Jul 16, 2008 at 07:49:03AM -0700, Barney Cordoba > wrote: > > --- On Tue, 7/15/08, Steve Kargl > wrote: > > > last pid: 3874; load averages: 9.99, 9.76, > 9.43 up 0+19:54:44 10:51:18 > > > 41 processes: 11 running, 30 sleeping > > > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% > interrupt, 0.0% idle > > > Mem: 5706M Active, 8816K Inact, 169M Wired, 84K > Cache, 108M > > > Buf, 25G Free > > > Swap: 4096M Total, 4096M Free > > > > > > PID USERNAME THR PRI NICE SIZE RES > STATE C TIME WCPU COMMAND > > > 3836 kargl 1 118 0 577M 572M CPU7 > 7 6:37 100.00% kzk90 > > > 3839 kargl 1 118 0 577M 572M CPU2 > 2 6:36 100.00% kzk90 > > > 3849 kargl 1 118 0 577M 572M CPU3 > 3 6:33 100.00% kzk90 > > > 3852 kargl 1 118 0 577M 572M CPU0 > 0 6:25 100.00% kzk90 > > > 3864 kargl 1 118 0 577M 572M RUN > 1 6:24 100.00% kzk90 > > > 3858 kargl 1 112 0 577M 572M RUN > 5 4:10 78.47% kzk90 > > > 3855 kargl 1 110 0 577M 572M CPU5 > 5 4:29 67.97% kzk90 > > > 3842 kargl 1 110 0 577M 572M CPU4 > 4 4:24 66.70% kzk90 > > > 3846 kargl 1 107 0 577M 572M RUN > 6 3:22 53.96% kzk90 > > > 3861 kargl 1 107 0 577M 572M CPU6 > 6 3:15 53.37% kzk90 > > > > > > I would have expected to see a more evenly > distributed WCPU > > > of around 80% for each process. > > > > I don't see why "equal" distribution is > or should be a goal, as that > > does not guarantee optimization. > > The above images may be parts of an MPI application. > Synchronization > problems simply kill performance. The PIDs with 100% WCPU > could be > spinning in a loop waiting for PID 3861 to send a message > after > completing a computation. The factor of 2 difference in > TIME for > PID 3836 and 3861 was still observed after more than an > hour of > accumulated time for 3836. It appears as if the algorithm > for > cpu affinity is punishing 3846 and 3861. > > > Given that the cache is shared between only 2 cpus, it > might very well > > be more efficient to run on 2 CPUs when the 3rd or 4th > isn't needed. > > > > It works pretty darn well, IMO. Its not like your > little app is the > > only thing going on in the system > > Actually, 10 copies of the little app are the only things > running except > top(1) and few sleeping system services (e.g., nfsd and > sshd). Apparently, > you missed the "41 processes: 11 running, 30 > sleeping" line above. > > -- > Steve Your apparent argument that somehow every cpu cycle can be sliced equally and automagically is as silly as the expectation that a first generation scheduler will exhibit 100% efficiency across 8 cpus. Its just as likely an inefficiency in the application as in the kernel. From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 16:30:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0BC1065682; Thu, 17 Jul 2008 16:30:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id C83D28FC28; Thu, 17 Jul 2008 16:30:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJWN0-000Pyk-5T; Thu, 17 Jul 2008 16:30:18 +0000 Message-ID: <487F7399.6040805@psg.com> Date: Thu, 17 Jul 2008 09:30:17 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: John Baldwin References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <486F8C57.9050908@wubethiopia.com> <20080705161614.O19209@fledge.watson.org> <200807170919.49756.jhb@freebsd.org> In-Reply-To: <200807170919.49756.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-current@freebsd.org, Robert Watson , Lothar Braun , freebsd-hackers@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 16:30:20 -0000 > I think the best route to that is to have a separate utility for managing disk > partitioning. The installer can then use that utility, and sysadmins can > also use it later after the system is installed. i often invoke sysinstall on a running system to slice/partition/etc a new drive randy From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 17:57:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 638B3106567E for ; Thu, 17 Jul 2008 17:57:31 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63915.mail.re1.yahoo.com (web63915.mail.re1.yahoo.com [69.147.97.130]) by mx1.freebsd.org (Postfix) with SMTP id EE1E18FC13 for ; Thu, 17 Jul 2008 17:57:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 89592 invoked by uid 60001); 17 Jul 2008 17:57:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=o256pWGKzJ6jG6GEBiRGh5D20uquRTFdb35rHyYlJYUNen3ap9Xmvc5szQw+8kRNfEVrnPu/dSfVVesy+mBVtAb98R2Pu5WxLYGg6l2s32uu/h83lLctgqmv81vcSKl82I8IUwX9Bt72EPSzbdoDMIQuir1kByjcxq9ojGkD++A=; Received: from [98.203.28.38] by web63915.mail.re1.yahoo.com via HTTP; Thu, 17 Jul 2008 10:57:29 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 17 Jul 2008 10:57:29 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org In-Reply-To: <334863.57605.qm@web63908.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <76237.89115.qm@web63915.mail.re1.yahoo.com> Cc: sos@freebsd.org Subject: Re: DVD-ROM problem with Freebsd 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2008 17:57:31 -0000 --- On Wed, 7/16/08, Barney Cordoba wrote: > From: Barney Cordoba > Subject: DVD-ROM problem with Freebsd 7 > To: current@freebsd.org > Cc: sos@freebsd.org > Date: Wednesday, July 16, 2008, 10:26 AM > I'm debugging a problem with an Intel Bigby chipset and > a DVD-ROM drive. We've swapped it out with a regular > CD-ROM and have the same problem, so its likely not the > drive. It gets probed as ATA_I82801IB_AH6. > > The problem is that certain types of media don't work. > Some work, some don't. We're going to build a > LINUX system to try to see if its the driver or some > physical thing, but the media works on our other systems so > it appears to be the driver. > > In pouring over the drivers, I've noticed that the > setmode function never seems to get called, and I'm > wondering what the point of the setup variables are if > they're never called. What should be the sequence of > calls to properly set up the controller? > > Barney As an update to this, we fired up the latest linux kernel and the drive works flawlessly with all media. So there is a problem with FreeBSD and not the hardware. Barney From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 18:29:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2971A1065672 for ; Thu, 17 Jul 2008 18:29:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E0E8B8FC1D for ; Thu, 17 Jul 2008 18:29:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m6HITOJe000850; Thu, 17 Jul 2008 11:29:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m6HITOSu000849; Thu, 17 Jul 2008 11:29:24 -0700 (PDT) (envelope-from sgk) Date: Thu, 17 Jul 2008 11:29:24 -0700 From: Steve Kargl To: Barney Cordoba Message-ID: <20080717182924.GA417@troutmask.apl.washington.edu> References: <20080716211317.GA92354@troutmask.apl.washington.edu> <452221.38826.qm@web63902.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452221.38826.qm@web63902.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 18:29:25 -0000 On Thu, Jul 17, 2008 at 09:12:45AM -0700, Barney Cordoba wrote: > > > Actually, 10 copies of the little app are the only things > > running except > > top(1) and few sleeping system services (e.g., nfsd and > > sshd). Apparently, > > you missed the "41 processes: 11 running, 30 > > sleeping" line above. > > > > Your apparent argument that somehow every cpu cycle can be > sliced equally and automagically is as silly I do not expect a single cpu cycle to be split evenly between the running processes. I do however expect that 8e12 cpu cycles to be split in a better distribution. > as the expectation that a first generation scheduler will > exhibit 100% efficiency across 8 cpus. ULE in -current is no longer 1st generation. I tested the original ULE when jeffr committed and reported a few panics and provided some of the first feedback of interactivity problems. Perhaps, I should have sent my original email directly to jeffr instead of the freebsd-current list where others might find the observation of interest. If one expects to see future improvements in ULE, then providing feedback is crucial. Apparently, you have a different opinion. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 18:56:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37E7106564A; Thu, 17 Jul 2008 18:56:31 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 681AB8FC12; Thu, 17 Jul 2008 18:56:31 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.13] (helo=3.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #19) id 1KJYeU-0002o0-0k; Thu, 17 Jul 2008 20:56:30 +0200 Received: from m9017.m.pppool.de ([89.49.144.23]:55902 helo=peedub.jennejohn.org) by 3.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #12) id 1KJYeT-0002Te-NU; Thu, 17 Jul 2008 20:56:29 +0200 Date: Thu, 17 Jul 2008 20:56:28 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20080717205628.237ce4a4@peedub.jennejohn.org> In-Reply-To: <487F7399.6040805@psg.com> References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <486F8C57.9050908@wubethiopia.com> <20080705161614.O19209@fledge.watson.org> <200807170919.49756.jhb@freebsd.org> <487F7399.6040805@psg.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2008 18:56:31 -0000 On Thu, 17 Jul 2008 09:30:17 -0700 Randy Bush wrote: > > I think the best route to that is to have a separate utility for managing disk > > partitioning. The installer can then use that utility, and sysadmins can > > also use it later after the system is installed. > > i often invoke sysinstall on a running system to slice/partition/etc a > new drive > [radically trimmed Cc list] sade(8) is supposed to take the place of sysinstall for disk operations. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 19:25:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76E91065670 for ; Thu, 17 Jul 2008 19:25:20 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBC48FC22 for ; Thu, 17 Jul 2008 19:25:20 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so55178fkk.11 for ; Thu, 17 Jul 2008 12:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=Od/uhHN2oNDkWV3EhSToXXkLXa0j/08CQNqPODKgNIk=; b=ktWHOczW/bGRvgs8KJk40eM93vFVGzV6NKjZTRVX6dFgenrgBql6NJ8tpdlyaepQEX WEiVrVzlZEO2a3UVjJoSJFDyQw9SY+y7SOgCqkmi5KAHRta8TOK+3QFrckl3dXl0RI3I nYO+4JUSLT9b+n91AWhODzNVEYwsPyrwuNXWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=UKtebXSffWriRQdjRkdP9OPHsMustAGNf+eU8oskpGaHgXouk/7dxe2jKohZaPLH50 vVgOD82ly8BuvcdgUVabBtp7SQGDTAFMXW1MhDPSq6y+Jvc6iPZ2p/qfMQR8kICYM2qI fQ3Ub4/e/YLSf3baaEGmg6snbMLnFX7UF3dew= Received: by 10.187.194.7 with SMTP id w7mr1123616fap.75.1216322719446; Thu, 17 Jul 2008 12:25:19 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id p25sm1711085hub.32.2008.07.17.12.25.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jul 2008 12:25:18 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Thu, 17 Jul 2008 20:56:04 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11160469.VydgZtgdq0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200807172056.08835.naylor.b.david@gmail.com> X-Mailman-Approved-At: Thu, 17 Jul 2008 19:35:33 +0000 Subject: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 19:25:21 -0000 --nextPart11160469.VydgZtgdq0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, A while back I worked on an "improvement" for rc. Most of the work was in= =20 recoding rcorder. =20 The 'improvements' in rcorder: * Add -e -i commands (allows simplification of rc by removing need for=20 early_late checks) * Add stagnation or parallel support (all scripts in a stage can be execute= d=20 concurrently without conflict) * Marginal speed increase (irrelevant since previous version is fast enough= =20 [unless one is worried about milliseconds on start-up time]) The main reason for this work was to increase start-up time (on the userlan= d=20 side) by running as many scripts concurrently as possible. This approach=20 allows only a minimal change in the rc scripts (there is a more efficient=20 method but that would mean moving most of the controlling logic into a=20 binary). =20 I am eager to continue with developing the above if the FreeBSD project (an= d=20 developers) want such a change? Or alternatively I could pass on the work= =20 already done to someone interested. =20 [[Side note: I stopped short of actually field testing the concurrent chan= ges=20 to rc (rcorder and the simplifications to rc scripts works]] Regards David --nextPart11160469.VydgZtgdq0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBIf5XIUaaFgP9pFrIRAtgLAKCLJYResjdDc+zSovJzYh7TPl1y5ACeK+3c Wjo2BJbQQREmBOisJpIMwuo= =fB3D -----END PGP SIGNATURE----- --nextPart11160469.VydgZtgdq0-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 19:49:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AE92106564A for ; Thu, 17 Jul 2008 19:49:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id 19CB28FC0C for ; Thu, 17 Jul 2008 19:49:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJZTM-0000W2-Ai; Thu, 17 Jul 2008 19:49:04 +0000 Message-ID: <487FA22F.8060102@psg.com> Date: Thu, 17 Jul 2008 12:49:03 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Gary Jennejohn References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <486F8C57.9050908@wubethiopia.com> <20080705161614.O19209@fledge.watson.org> <200807170919.49756.jhb@freebsd.org> <487F7399.6040805@psg.com> <20080717205628.237ce4a4@peedub.jennejohn.org> In-Reply-To: <20080717205628.237ce4a4@peedub.jennejohn.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 19:49:05 -0000 > sade(8) is supposed to take the place of sysinstall for disk operations. doh. thank you. randy From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 20:32:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4EF1106564A for ; Thu, 17 Jul 2008 20:32:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0D58FC0C for ; Thu, 17 Jul 2008 20:32:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so46580fgb.35 for ; Thu, 17 Jul 2008 13:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=1YESDj/qO86e9Kw9HFsUvtjZ3l4OCSajHE5LHYLWv+E=; b=k33/NrW4zTxRcZgtSwhfeuEqyu0Z8okubRwk3K+Vx6rPKY/vFs7/vT6iEcFPiZIyAA B6DwilmDkPbdIom6COcxvm80QiGEansiogaqyiwHO2IkNqvaAjCx+PWYAtC1gqc5awzA op8jN9nS9zqSKKEEXV5sn/QbPBevcSkR3IavE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=vsi90XJczIeEg5qeS+86uHkFJ1d4ppDbZJE6SE6ncp4EiNURDQnOhOKbX7tXdnNMRr LaUS+9Z78bEblLEwC44JW7hBm1SmEdh6dj/4UIO90eV6hE/FH0eLUXx0PnbMIUKnoY2G LYjahqOLSTP2BYScF0oTK1aTjE7aiimPXiDfc= Received: by 10.86.33.19 with SMTP id g19mr4625307fgg.67.1216325217646; Thu, 17 Jul 2008 13:06:57 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Thu, 17 Jul 2008 13:06:57 -0700 (PDT) Message-ID: <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> Date: Thu, 17 Jul 2008 22:06:57 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Lothar Braun" In-Reply-To: <487F32C6.5030502@lobraun.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> X-Google-Sender-Auth: a6997c57309c7e53 Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 20:32:51 -0000 2008/7/17, Lothar Braun : > Hi, > > I'm getting a kernel panic, whenever I try to work with an XFS file system > with todays sources. > > I created the filesystem, mounted it and created a directory on it. The > crash occurred when I tried to chown the directory. > > 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: > panic: __lockmgr_args: unknown lockmgr request 0x0 > > cpuid = 1 > Uptime: 25m36s > Physical memory: 3314 MB > Dumping 95 MB: 80 (CTRL-C to abort) 64 48 32 16 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/xfs.ko...Reading symbols from > /boot/kernel/xfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/xfs.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc078f1cc in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc078f489 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc077b83c in __lockmgr_args (lk=0xc6eecce8, flags=256, ilk=0xc6eecd04, > wmesg=0x0, pri=0, timo=0, file=0xc0b2b883 > "/usr/src/sys/kern/vfs_subr.c", > line=2044) at /usr/src/sys/kern/kern_lock.c:848 > #4 0xc0801cf2 in vop_stdlock (ap=0xe8fa7810) at lockmgr.h:93 > #5 0xc0aac906 in VOP_LOCK1_APV (vop=0xc0bf5400, a=0xe8fa7810) > at vnode_if.c:1618 > #6 0xc081e64d in _vn_lock (vp=0xc6eecc90, flags=256, > file=0xc0b2b883 "/usr/src/sys/kern/vfs_subr.c", > line=2044) > at vnode_if.h:845 > #7 0xc080ea29 in vget (vp=0xc6eecc90, flags=0, td=0xc6a50460) > at /usr/src/sys/kern/vfs_subr.c:2044 > #8 0xc6e2f6a6 in vn_get (xfs_vp=0xc692d780, vmap=0xe8fa78c0) > at > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_vnode.c:107 > #9 0xc6df4cb2 in xfs_iget (mp=0xc6776800, tp=0x0, ino=Unhandled dwarf > expression opcode 0x93 > ) > at > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_freebsd_iget.c:164 > #10 0xc6e160fc in xfs_dir_lookup_int (dir_bdp=0xc6ee9020, lock_mode=8, > dentry=0xe8fa7bb0, inum=0xe8fa7938, ipp=0xe8fa7940) > at > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_utils.c:97 > #11 0xc6e1a75e in xfs_lookup (dir_bdp=0xc6ee9020, dentry=0xe8fa7bb0, > vpp=0xe8fa79a8, flags=0, rdir=0x0, credp=0xc698e500) > at > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_vnodeops.c:1828 > #12 0xc6e2a973 in _xfs_cachedlookup (ap=0xe8fa79e0) > at > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_vnops.c:1275 > #13 0xc0aab322 in VOP_CACHEDLOOKUP_APV (vop=0xc6e367e0, a=0xe8fa79e0) > at vnode_if.c:153 > #14 0xc07ff8c0 in vfs_cache_lookup (ap=0xe8fa7a64) at vnode_if.h:80 > #15 0xc0aacfe6 in VOP_LOOKUP_APV (vop=0xc6e367e0, a=0xe8fa7a64) > at vnode_if.c:99 > #16 0xc0806371 in lookup (ndp=0xe8fa7b84) at vnode_if.h:54 > #17 0xc08071bb in namei (ndp=0xe8fa7b84) at > /usr/src/sys/kern/vfs_lookup.c:239 > #18 0xc0814a64 in kern_statat (td=0xc6a50460, flag=0, fd=-100, > path=0x8104928
, pathseg=UIO_USERSPACE, > sbp=0xe8fa7c18) at > /usr/src/sys/kern/vfs_syscalls.c:2331 > #19 0xc0814cf6 in kern_stat (td=0xc6a50460, > path=0x8104928
, pathseg=UIO_USERSPACE, > sbp=0xe8fa7c18) at > /usr/src/sys/kern/vfs_syscalls.c:2313 > #20 0xc0814d9f in stat (td=0xc6a50460, uap=0xe8fa7cf8) > at /usr/src/sys/kern/vfs_syscalls.c:2282 > #21 0xc0aa1075 in syscall (frame=0xe8fa7d38) > at /usr/src/sys/i386/i386/trap.c:1081 > #22 0xc0a86a90 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #23 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) Hello, can you try the following patch: http://www.freebsd.org/~attilio/xfs.diff Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 20:38:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93116106566B for ; Thu, 17 Jul 2008 20:38:13 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5558FC17 for ; Thu, 17 Jul 2008 20:38:07 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id AAEF32DC08C for ; Thu, 17 Jul 2008 20:37:32 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id B7EB111EB9; Thu, 17 Jul 2008 22:38:05 +0200 (CEST) Date: Thu, 17 Jul 2008 22:38:05 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20080717203804.GC1437@zaphod.nitro.dk> References: <20080713230635.GC15766@zaphod.nitro.dk> <20080715202852.GB1366@lizard.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080715202852.GB1366@lizard.fafoe.narf.at> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [patch] segfault in sh for bogus redirection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 20:38:13 -0000 On 2008.07.15 22:28:52 +0200, Stefan Farfeleder wrote: > On Mon, Jul 14, 2008 at 01:06:35AM +0200, Simon L. Nielsen wrote: > > Hey Stefan (and other people familiar with the sh(1) code), > > > > I stumbled on a corner case bug in sh(1) where it segfaults instead of > > giving a proper error message. This only happens when you do > > something stupid, but I thought it should be fixed anyway. > > > > When you redirect to an unset or empty variable things fail: > > > > $ sh -c 'echo 1 >&$a' > > Segmentation fault (core dumped) [...] > I don't think your patch is correct. The value of 'fn.list->text' is > not properly initialised in eval.c:441 and only NULL by chance. Try Ah, ok. I tried to follow the code some, but it wasn't really obvious to me what was going on :-). > this patch instead. I still need to test it properly though. Yes, your patch also makes sh fail gracefully. -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 21:26:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 345D81065673 for ; Thu, 17 Jul 2008 21:26:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id AFE688FC14 for ; Thu, 17 Jul 2008 21:26:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m6HLQ2Rx026597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 07:26:02 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m6HLQ1mB056974; Fri, 18 Jul 2008 07:26:01 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m6HLQ12I056973; Fri, 18 Jul 2008 07:26:01 +1000 (EST) (envelope-from peter) Date: Fri, 18 Jul 2008 07:26:01 +1000 From: Peter Jeremy To: David Naylor Message-ID: <20080717212601.GZ62764@server.vk2pj.dyndns.org> References: <200807172056.08835.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qicHaSekiYEWE95x" Content-Disposition: inline In-Reply-To: <200807172056.08835.naylor.b.david@gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 21:26:05 -0000 --qicHaSekiYEWE95x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jul-17 20:56:04 +0200, David Naylor wrot= e: >* Add stagnation or parallel support (all scripts in a stage can be execut= ed=20 >concurrently without conflict) This sounds like a worthwhile improvement for most cases. Note that it probably needs some degree of rate limiting - just forking off dozens of startup scripts may be counter-productive - especially if they are I/O bound. >The main reason for this work was to increase start-up time (on the userla= nd=20 >side) by running as many scripts concurrently as possible. 'Reduce' maybe... >method but that would mean moving most of the controlling logic into a=20 >binary). =20 I don't see how to safely do all the parallelisation using scripting tools that are available in the base system >[[Side note: I stopped short of actually field testing the concurrent >changes to rc (rcorder and the simplifications to rc scripts works]] Ummm,.. Unless I've misunderstood something, you have just said that your main driver for this was implementing concurrency but you haven't actually tested that. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --qicHaSekiYEWE95x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh/uOkACgkQ/opHv/APuIcR+ACeJBNjPdKm0u/puJ4aGI4lGQI5 SNsAnA8qCuI/hpa9beQQTpbsmrqYN8Jt =nZlk -----END PGP SIGNATURE----- --qicHaSekiYEWE95x-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 17 22:41:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86161065672 for ; Thu, 17 Jul 2008 22:41:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB248FC14 for ; Thu, 17 Jul 2008 22:41:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9780 invoked by uid 399); 17 Jul 2008 22:41:15 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2008 22:41:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <487FCA89.2010308@FreeBSD.org> Date: Thu, 17 Jul 2008 15:41:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: David Naylor References: <200807172056.08835.naylor.b.david@gmail.com> In-Reply-To: <200807172056.08835.naylor.b.david@gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2008 22:41:20 -0000 There is a list specifically for discussing rc-related stuff, freebsd-rc@freebsd.org, FYI. I have a lot of questions which are not intended to be critical in anyway, it's just important to think about stuff carefully before making changes to the boot stuff. You might want to reformulate a post that has the answers to the questions below and start again on the -rc list, but that's your choice. David Naylor wrote: > Hi, > > A while back I worked on an "improvement" for rc. Most of the work was in > recoding rcorder. > > The 'improvements' in rcorder: > * Add -e -i commands (allows simplification of rc by removing need for > early_late checks) Can you explain how you accomplished this? > * Add stagnation or parallel support (all scripts in a stage can be executed > concurrently without conflict) How are you defining stages? Is this the "minimal change in the rc scripts" you're referring to below? > * Marginal speed increase (irrelevant since previous version is fast enough > [unless one is worried about milliseconds on start-up time]) Faster is better. > The main reason for this work was to increase start-up time (on the userland > side) by running as many scripts concurrently as possible. How are you running the scripts concurrently, and the key question, have you actually benchmarked your changes to demonstrate that they result in statistically significant changes. > This approach > allows only a minimal change in the rc scripts (there is a more efficient > method but that would mean moving most of the controlling logic into a > binary). When you say "controlling logic" are you referring to what /etc/rc does currently? Replacing rc with a binary is not out of the question, but we'd need pretty clear evidence that it's the right thing to do first. > I am eager to continue with developing the above if the FreeBSD project (and > developers) want such a change? Or alternatively I could pass on the work > already done to someone interested. Posting a URL where people could examine your work would be useful. > [[Side note: I stopped short of actually field testing the concurrent changes > to rc (rcorder and the simplifications to rc scripts works]] Ok, that answers one of my questions. The last question I had off the top of my head is whether or not you've tested all this stuff on shutdown too. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 00:13:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744B4106566C for ; Fri, 18 Jul 2008 00:13:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC7C8FC1D for ; Fri, 18 Jul 2008 00:13:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 2C6532BDA5; Fri, 18 Jul 2008 11:56:38 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfZj-itjrHtr; Fri, 18 Jul 2008 11:56:34 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 18 Jul 2008 11:56:31 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 9B09911431; Fri, 18 Jul 2008 11:56:30 +1200 (NZST) Date: Thu, 17 Jul 2008 16:56:30 -0700 From: Andrew Thompson To: Pyun YongHyeon Message-ID: <20080717235630.GL33414@citylink.fud.org.nz> References: <200805190140.m4J1e0YW001168@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805190140.m4J1e0YW001168@repoman.freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/dev/age if_age.c if_agereg.h if_agevar.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: Fri, 18 Jul 2008 00:13:35 -0000 On Mon, May 19, 2008 at 01:39:59AM +0000, Pyun YongHyeon wrote: > yongari 2008-05-19 01:39:59 UTC > > FreeBSD src repository > > Added files: > sys/dev/age if_age.c if_agereg.h if_agevar.h > Log: > Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet > controller. +static void +age_phy_reset(struct age_softc *sc) +{ + + /* Reset PHY. */ + CSR_WRITE_4(sc, AGE_GPHY_CTRL, GPHY_CTRL_RST); + pause("agephy", hz / 1000); + CSR_WRITE_4(sc, AGE_GPHY_CTRL, GPHY_CTRL_CLR); + pause("agephy", hz / 1000); +} This will panic if hz < 1000, perhaps a DELAY(1) is better? Andrew From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 00:18:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F1B106566C; Fri, 18 Jul 2008 00:18:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3990A8FC1F; Fri, 18 Jul 2008 00:18:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6I0HuYR038965; Thu, 17 Jul 2008 20:17:56 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Randy Bush Date: Thu, 17 Jul 2008 20:13:18 -0400 User-Agent: KMail/1.9.7 References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <200807170919.49756.jhb@freebsd.org> <487F7399.6040805@psg.com> In-Reply-To: <487F7399.6040805@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807172013.18535.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Thu, 17 Jul 2008 20:17:57 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7742/Thu Jul 17 19:22:26 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mike Makonnen , freebsd-current@freebsd.org, Robert Watson , Lothar Braun , freebsd-hackers@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 00:18:03 -0000 On Thursday 17 July 2008 12:30:17 pm Randy Bush wrote: > > I think the best route to that is to have a separate utility for managing > > disk partitioning. The installer can then use that utility, and > > sysadmins can also use it later after the system is installed. > > i often invoke sysinstall on a running system to slice/partition/etc a > new drive Yes, I have found it nicer than raw bsdlabel in the past, but I think it should be a standalone tool (diskpart or some such) that manages that and that the installer should use that tool rather than the installer having a disk partitioning sub-personality. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 00:21:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8F21065671; Fri, 18 Jul 2008 00:21:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id CABEC8FC19; Fri, 18 Jul 2008 00:21:18 +0000 (UTC) (envelope-from randy@psg.com) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJdin-0001wf-Kj; Fri, 18 Jul 2008 00:21:17 +0000 Message-ID: <487FE1FC.7020600@psg.com> Date: Thu, 17 Jul 2008 17:21:16 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: John Baldwin References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <200807170919.49756.jhb@freebsd.org> <487F7399.6040805@psg.com> <200807172013.18535.jhb@freebsd.org> In-Reply-To: <200807172013.18535.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-current@freebsd.org, Robert Watson , Lothar Braun , freebsd-hackers@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 00:21:19 -0000 John Baldwin wrote: > On Thursday 17 July 2008 12:30:17 pm Randy Bush wrote: >>> I think the best route to that is to have a separate utility for managing >>> disk partitioning. The installer can then use that utility, and >>> sysadmins can also use it later after the system is installed. >> i often invoke sysinstall on a running system to slice/partition/etc a >> new drive > Yes, I have found it nicer than raw bsdlabel in the past, but I think it > should be a standalone tool (diskpart or some such) that manages that and > that the installer should use that tool rather than the installer having a > disk partitioning sub-personality. oh, i agree completely. my point was that i seem to invoke sysinstall when standalone would be more 'normal.' and then i was pointed to sade(8) :) . randy From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 00:58:22 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3731065672 for ; Fri, 18 Jul 2008 00:58:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5188FC1C for ; Fri, 18 Jul 2008 00:58:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so188171rvf.43 for ; Thu, 17 Jul 2008 17:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+wzORL2sHvD390Tbn6ulebBJgt0h6cjQzGVobMHhb0Y=; b=UwXAwxyB9E25Bj+rWly2lfgWlgktKvcdM58kC4EeqQloSELhEU2mnMcPWLNINQ+jJ4 5UBj6Me9kZB52qbpoLN2qARgn3oIYKYOHx3zNwM1Ye2c8RIcP/y4NpXZ3GNzYOlrW1jy +XYo/vIJ9FqrTuTP64cQ3nYoGLaPtvM9Xzl2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=t0SrCGA3/s7O7JVZ2AJ+MLkuTrwqZzWLDcVBwr36eEgDxuWuTq1fmkBSxQmQL9S/FD hV3ja6XLMbj/wXhvS94GEwXHXMeVttQG3U8kMNnh3ZoAtnPbS8ae4RMV8ZF+xEMHOF+S 7vjPb6ci4+k15bJbnOuH3l/v72xuFftmXrnyY= Received: by 10.141.41.12 with SMTP id t12mr1494982rvj.282.1216341204184; Thu, 17 Jul 2008 17:33:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id f21sm321148rvb.0.2008.07.17.17.33.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jul 2008 17:33:23 -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 m6I0VD96053051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 09:31:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m6I0VDTZ053050; Fri, 18 Jul 2008 09:31:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 18 Jul 2008 09:31:13 +0900 From: Pyun YongHyeon To: Andrew Thompson Message-ID: <20080718003112.GA52865@cdnetworks.co.kr> References: <200805190140.m4J1e0YW001168@repoman.freebsd.org> <20080717235630.GL33414@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080717235630.GL33414@citylink.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org, Pyun YongHyeon Subject: Re: cvs commit: src/sys/dev/age if_age.c if_agereg.h if_agevar.h 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: Fri, 18 Jul 2008 00:58:22 -0000 On Thu, Jul 17, 2008 at 04:56:30PM -0700, Andrew Thompson wrote: > On Mon, May 19, 2008 at 01:39:59AM +0000, Pyun YongHyeon wrote: > > yongari 2008-05-19 01:39:59 UTC > > > > FreeBSD src repository > > > > Added files: > > sys/dev/age if_age.c if_agereg.h if_agevar.h > > Log: > > Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet > > controller. > > +static void > +age_phy_reset(struct age_softc *sc) > +{ > + > + /* Reset PHY. */ > + CSR_WRITE_4(sc, AGE_GPHY_CTRL, GPHY_CTRL_RST); > + pause("agephy", hz / 1000); > + CSR_WRITE_4(sc, AGE_GPHY_CTRL, GPHY_CTRL_CLR); > + pause("agephy", hz / 1000); > +} > > This will panic if hz < 1000, perhaps a DELAY(1) is better? Ah, yes. I'll fix that. Thanks a lot! > > > Andrew -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 04:26:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4431065681 for ; Fri, 18 Jul 2008 04:26:48 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id A706B8FC16 for ; Fri, 18 Jul 2008 04:26:48 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so244316rvf.43 for ; Thu, 17 Jul 2008 21:26:48 -0700 (PDT) Received: by 10.141.161.6 with SMTP id n6mr1615683rvo.155.1216353600389; Thu, 17 Jul 2008 21:00:00 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Thu, 17 Jul 2008 21:00:00 -0700 (PDT) Message-ID: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> Date: Fri, 18 Jul 2008 00:00:00 -0400 From: "Edward Ruggeri" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 04:26:49 -0000 Hi, I am getting a kernel panic (page fault) caused by the FreeBSD kernel's ath driver shortly after I begin using the internet. I use FreeBSD 7.0 CURRENT. I used cvs a few days ago to update the source tree (7/10/08) and rebuilt the world as well as the kernel (just got a brand new computer). There is very little software installed (ports only, also built 7/10/08), and no data. But let me describe the configuration and problem. I have recently purchased a Lenovo ThinkPad, with a ThinkPad 11a/b/g Wi-Fi wireless LAN Mini-PCIe card (Lenovo part #41W1685). My Lenovo representative claims this uses a Atheros Ar5006ex chipset (she's not an expert, though), but FreeBSD's dmesg detects an Atheros 5212 chipset. The Linux oriented thinkwiki.org claims this card may use either chipset. I don't know who to trust; maybe someone knows the answer, but Google hasn't seemed to clear things up. In particular, from dmesg: ath0: mem 0xdf2f0000-0xdf2fffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: [Numbers] ath0: mac 10.3 phy 6.1 radio 10.2 I don't know if the obsoleted statement should worry me. Google seemed to indicate some posts that it wasn't a big deal. I've built driver support into the kernel. I should note that I compile SMP support for the kernel. In particular, in my kernel configuration: device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath If I add "ifconfig_ath0="DHCP"" to /etc/rc.conf or run "dhclient ath0," the card connects and acquires an ip address from the router (mine is unsecured at home). This is what I get: DHCPREQUEST on ath0 to 255.255.255.255 port 67 ip length 281 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPNAK from 192.168.1.1 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 3 ip length 314 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPOFFER from 192.168.1.1 DHCPREQUEST on ath0 to 255.255.255.255 port 67 ip length 314 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPACK from 192.168.1.1 bound to 192.168.1.8 -- renewal in 43200 seconds. I don't know what to make of those ip lengths disagreeing with bytes received... I can launch lynx (my favorite non-graphical browser) or firefox and load google. I can make a search and get results, but the kernel always panics by the time I try to load a third webpage (or earlier). This is what I get: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0484aa6 stack pointer = 0x28:0xe7ffe8bc frame pointer = 0x28:0xe7ffe928 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 = 1427 (lynx) [I've also seen this from ath0 taskq] trap number = 12 panic: page fault cpuid = 1 Uptime: 51m37s Physical memory: 2014 MB Dumping 109 MB: Snyncing disks, vndoes remaining...[Zeros] I'm pretty much a freeBSD novice, so I don't know what to do as it prints out line after line of zeros (slowly). Normally I just shut the sucker down, because it seems content to print the zeros forever... But as FreeBSD starts up, it says "savecore: no dumps found." But I have compiled the kernel with debugging symbols (makeoptions DEBUG=-g), so maybe you can advise. I hope someone is able to help. Do you think I should file a problem report? Thanks for reading. Good night! Sincerely, -- Ned Ruggeri From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 06:56:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 551C81065671; Fri, 18 Jul 2008 06:56:54 +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 DD7EA8FC15; Fri, 18 Jul 2008 06:56:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55AA5.dip.t-dialin.net [84.165.90.165]) by redbull.bpaserver.net (Postfix) with ESMTP id A3CA22E323; Fri, 18 Jul 2008 08:37:37 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BD1F037BBD; Fri, 18 Jul 2008 08:37:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1216363045; bh=QjXSbXQ0zHkbjZDFDA+p5eEYdotGQFv1G yVyCQ27YW0=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=otakoZRpOlkqEU7jxH7cecx0h0cxbtq48548EmLcJNOUOUEsY9nsFwYV0oDhecrbi CwQQehc4YXtIUGgonJMkJ3d4144Zbz+76f6BtcOwzeIl5Wn3hk29E25SgztfkjYfcPb 0Yspw8bge1KVd9jqBgln+5uXE+SU3VXbWLY9z5pe/WTMAFGRG/uZMq4GIkjS9tc/4sM tqqYJLDzBNWTmyqEzyPBGWJXT2CKVtdqpZ9Iou/m51EIKxSquFG8vLZoeoKWnmZs0vA iR/5NY55LcO8QOysKWR+P/Eu5OmOhtssoerrbu7ej7IehqGs8xlHbXxxNTQDMgNAi9I CZpXsDB+w== Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m6I6bPjV099174; Fri, 18 Jul 2008 08:37:25 +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 Framework) with HTTP; Fri, 18 Jul 2008 08:37:25 +0200 Message-ID: <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 18 Jul 2008 08:37:25 +0200 From: Alexander Leidinger To: Doug Barton References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> In-Reply-To: <487FCA89.2010308@FreeBSD.org> 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.2-RC2) / FreeBSD-8.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, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@FreeBSD.org, David Naylor Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 06:56:54 -0000 Quoting Doug Barton (from Thu, 17 Jul 2008 15:41:13 -0700): >> The main reason for this work was to increase start-up time (on the >> userland side) by running as many scripts concurrently as possible. > > How are you running the scripts concurrently, and the key question, > have you actually benchmarked your changes to demonstrate that they > result in statistically significant changes. Are you aware that the parallel starting in Solaris 10 reduced the booting time by a nice percentage? If yes, do you expect that FreeBSD behaves significantly different or do you "just" want to see numbers? Sidenote: Even if there's no significant speedup, the possibility to start things in parallel should be provided, this would allow more experimentation (at all respectively later). Bye, Alexander. -- 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 Fri Jul 18 07:18:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A4E8106564A; Fri, 18 Jul 2008 07:18:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id EC3BF8FC16; Fri, 18 Jul 2008 07:18:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m6I7I7wU023676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 17:18:08 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m6I7I7rt058833; Fri, 18 Jul 2008 17:18:07 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m6I7I74k058832; Fri, 18 Jul 2008 17:18:07 +1000 (EST) (envelope-from peter) Date: Fri, 18 Jul 2008 17:18:07 +1000 From: Peter Jeremy To: Alexander Leidinger Message-ID: <20080718071806.GV62764@server.vk2pj.dyndns.org> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQFJYnjHKDAbJRTQ" Content-Disposition: inline In-Reply-To: <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 07:18:11 -0000 --LQFJYnjHKDAbJRTQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger wrote: >Are you aware that the parallel starting in Solaris 10 reduced the =20 >booting time by a nice percentage? Given that Solaris boots in geologic time, this probably wouldn't be difficult. > If yes, do you expect that FreeBSD =20 >behaves significantly different or do you "just" want to see numbers? Parallel starting is not guaranteed to be an improvement. Starting a whole pile of processes that are I/O bound during initialisation (think squid or some databases) may be worse than starting them one at a time. Likewise, a whole pile of processes that are CPU bound will just thrash the scheduler. (Though parallel starting of I/O and CPU bound processes should be a win). >Sidenote: Even if there's no significant speedup, the possibility to =20 >start things in parallel should be provided, this would allow more =20 >experimentation (at all respectively later). Agreed. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --LQFJYnjHKDAbJRTQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiAQ64ACgkQ/opHv/APuIcxYgCfQfaalhQt85CKO7e38VAL7OT0 zt8AnRBVrZEo4+OK6+P2wwvOvxrlGG4g =Ih8d -----END PGP SIGNATURE----- --LQFJYnjHKDAbJRTQ-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 08:22:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EA1E106566B; Fri, 18 Jul 2008 08:22:30 +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 15AB38FC18; Fri, 18 Jul 2008 08:22:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6I8MReE022888; Fri, 18 Jul 2008 04:22:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6I8MRnu000633; Fri, 18 Jul 2008 04:22:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1DD4673039; Fri, 18 Jul 2008 04:22:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080718082227.1DD4673039@freebsd-current.sentex.ca> Date: Fri, 18 Jul 2008 04:22:27 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Fri, 18 Jul 2008 08:22:30 -0000 TB --- 2008-07-18 07:12:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-18 07:12:32 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-07-18 07:12:32 - cleaning the object tree TB --- 2008-07-18 07:13:25 - cvsupping the source tree TB --- 2008-07-18 07:13:25 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-07-18 07:13:37 - building world (CFLAGS=-O -pipe) TB --- 2008-07-18 07:13:37 - cd /src TB --- 2008-07-18 07:13:37 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 18 07:13:40 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jul 18 08:20:20 UTC 2008 TB --- 2008-07-18 08:20:20 - generating LINT kernel config TB --- 2008-07-18 08:20:20 - cd /src/sys/pc98/conf TB --- 2008-07-18 08:20:20 - /usr/bin/make -B LINT TB --- 2008-07-18 08:20:20 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-18 08:20:20 - cd /src TB --- 2008-07-18 08:20:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 18 08:20:20 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector cc: /src/sys/dev/cxgb/common/cxgb_tn1010.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-18 08:22:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-18 08:22:26 - ERROR: failed to build lint kernel TB --- 2008-07-18 08:22:26 - tinderbox aborted TB --- 3085.42 user 381.03 system 4194.12 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:14:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A4BD1065674; Fri, 18 Jul 2008 09:14:24 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA928FC13; Fri, 18 Jul 2008 09:14:23 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from vpn2797.extern.uni-tuebingen.de ([134.2.187.47] helo=admins-macbook.local) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJm2h-0002VW-2D; Fri, 18 Jul 2008 11:14:23 +0200 Message-ID: <48805EEE.90109@lobraun.de> Date: Fri, 18 Jul 2008 11:14:22 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Attilio Rao References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> In-Reply-To: <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:14:24 -0000 Hi, Attilio Rao wrote: > 2008/7/17, Lothar Braun : > can you try the following patch: > http://www.freebsd.org/~attilio/xfs.diff The patch makes the panic disappear. But there seems to be a deadlock instead. Every access on the partition does block. I did mkfs.xfs /dev/ad8s4 mount -t xfs /dev/ad8s4 /home mkdir /home/lothar chown lothar:lothar /home/lothar -> blocks dmesg says: SGI XFS with large block numbers, tracing, no debug enabled fsname '/dev/ad8s4' logname '' rtname '' flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 xfs_setsize_buftarg NI 0xc692d420 XFS mounting filesystem /dev/ad8s4 Ending clean XFS mount for filesystem: /dev/ad8s4 xfs_iunpin: REC RECABLE ip 0xc6f89d38 xfs_iunpin: REC RECABLE ip 0xc6f8a000 xfs_iflush: ip 0xc6f89d38 i_ino 131 I'll recompile the kernel with INVARIANTS and WITNESS enabled in order to get more information about the problem. Regards, Lothar From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:46:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE997106566C; Fri, 18 Jul 2008 09:46:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DBBA78FC21; Fri, 18 Jul 2008 09:46:43 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48806684.4000908@FreeBSD.org> Date: Fri, 18 Jul 2008 11:46:44 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Lothar Braun References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> In-Reply-To: <48805EEE.90109@lobraun.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:46:45 -0000 Lothar Braun wrote: > Hi, > > Attilio Rao wrote: >> 2008/7/17, Lothar Braun : > >> can you try the following patch: >> http://www.freebsd.org/~attilio/xfs.diff > > The patch makes the panic disappear. But there seems to be a deadlock > instead. Every access on the partition does block. I did > > mkfs.xfs /dev/ad8s4 > mount -t xfs /dev/ad8s4 /home > mkdir /home/lothar > chown lothar:lothar /home/lothar -> blocks > > dmesg says: > > SGI XFS with large block numbers, tracing, no debug enabled > fsname '/dev/ad8s4' logname '' rtname '' > flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 > xfs_setsize_buftarg NI 0xc692d420 > XFS mounting filesystem /dev/ad8s4 > Ending clean XFS mount for filesystem: /dev/ad8s4 > xfs_iunpin: REC RECABLE ip 0xc6f89d38 > xfs_iunpin: REC RECABLE ip 0xc6f8a000 > xfs_iflush: ip 0xc6f89d38 i_ino 131 > > > I'll recompile the kernel with INVARIANTS and WITNESS enabled in order > to get more information about the problem. And DEBUG_LOCKS and DEBUG_VFS_LOCKS please :) Kris From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:50:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DC1E1065677 for ; Fri, 18 Jul 2008 09:50:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 439558FC20 for ; Fri, 18 Jul 2008 09:50:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E721145CA6; Mon, 14 Jul 2008 09:06:26 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 49D4845C89; Mon, 14 Jul 2008 09:06:22 +0200 (CEST) Date: Mon, 14 Jul 2008 09:06:22 +0200 From: Pawel Jakub Dawidek To: Patrick Lamaizi?re Message-ID: <20080714070622.GB13560@garage.freebsd.pl> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080706115414.GA20076@gw.reifenberger.com> <20080706234231.3d18e15a@baby-jane-lamaiziere-net.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <20080706234231.3d18e15a@baby-jane-lamaiziere-net.local> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: AMD Geode LX crypto accelerator (glxsb) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:50:21 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2008 at 11:42:31PM +0200, Patrick Lamaizi?re wrote: > Le Sun, 6 Jul 2008 13:54:14 +0200, > Michael Reifenberger a =E9crit : >=20 > Hi, >=20 > > On Fri, Jun 06, 2008 at 11:41:35PM +0200, Patrick Lamaizi?re wrote: > > > Dears, > > >=20 > > > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > > > (via the NetBSD port). > > > " The glxsb driver supports the security block of the Geode LX > > > series processors. The Geode LX is a member of the AMD Geode family > > > of integrated x86 system chips. > > > =20 > > Is allready one of the FreeBSD developers working on integrating > > your ported driver into HEAD? >=20 > Pawel Jakub Dawidek proposed to look and commit it when it will be > ready. A lot of code comes from padlock(4) so may be it's better if the > author can rewiew the code. >=20 > I think that the driver is ready and works fine, i didn't change > anything since the latest version "22/06/08" > http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz >=20 > It is not clear if i shall provide a patch against HEAD or > do something else ? I'm afraid I won't be able to commit it as my Soekris box died... --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIevruForvXbEpPzQRAmygAJ9yMMZxF37dwmorbA7NJ/Yf7ug6WwCgoxa5 x/gwZQn9XrBVcEnLr2By/v4= =H49v -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:50:21 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517C71065678 for ; Fri, 18 Jul 2008 09:50:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3FCDB8FC1E for ; Fri, 18 Jul 2008 09:50:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0433245DD8; Mon, 14 Jul 2008 09:16:22 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2CDF945C9C; Mon, 14 Jul 2008 09:16:18 +0200 (CEST) Date: Mon, 14 Jul 2008 09:16:18 +0200 From: Pawel Jakub Dawidek To: aslam_mohamed@wordbank.com Message-ID: <20080714071618.GC13560@garage.freebsd.pl> References: <48749087.4070802@FreeBSD.org> <20080709145010.Q58331@woozle.rinet.ru> <48749EA7.40702@FreeBSD.org> <20080709152739.Q58331@woozle.rinet.ru> <4874A453.7060406@FreeBSD.org> <4874A981.7080106@wordbank.com> <4874B58B.7000108@FreeBSD.org> <4874BEFF.20202@wordbank.com> <4874C38F.9040706@FreeBSD.org> <4874C9E9.1050206@wordbank.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: <4874C9E9.1050206@wordbank.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Kris Kennaway , Dmitry Morozovsky , current@FreeBSD.org Subject: Re: Thinking of using ZFS/FBSD for a backup system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:50:21 -0000 --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 09, 2008 at 03:23:37PM +0100, aslam_mohamed@wordbank.com wrote: > Something interesting, I just slot couple of 1TB SATA in to the same=20 > FreeBSD machine and re-created the zfs pool (this is just to make sure=20 > that without firewire the ZFS can work well in FeeBSD) . When I reboot= =20 > the machine I see the following appears on booting... This is the same=20 > thing appeared before with Firewire!! >=20 > ad4: 76324MB at ata2-master SATA150 > ad8: 953869MB at ata4-master SATA150 > ad10: 953869MB at ata5-master SATA150 > **GEOM: ad8: corrupt or invalid GPT detected.** > **GEOM: ad8: GPT rejected -- may not be recoverable.** > **GEOM: ad10: corrupt or invalid GPT detected.** > **GEOM: ad10: GPT rejected -- may not be recoverable.** > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad4s1a > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 >=20 > Now I am running Rsync to backup all the file servers and it had done up= =20 > to 1TB without complaining.. Currently, the Zpool status looks pretty OK.. >=20 > pool: backup > state: ONLINE > scrub: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > backup ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > ad10 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > I don't know in the future there will be any issue because of this Geom= =20 > messages... is there any known problem like zfs/geom/gpt=20 > incompatibility?.. is it the ZFS causing this error(!) messages?..any=20 > thoughts?... Those: GEOM: ad10: corrupt or invalid GPT detected.** GEOM: ad10: GPT rejected -- may not be recoverable.** messages are probably because you moved disks from Solaris and Solaris creates GPT labels that are treated that way by FreeBSD. I've heard about problems with using disks connected via firewire. Not sure if you tried to connect them directly already or not, but if you didn't, please try it. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIev1CForvXbEpPzQRArQ0AKC+r4B/AXTGxXL69+2IkUtnOIOqDgCgnDpM DJBgbiVje//Fmmoh8B26i9s= =e24W -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:50:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C746A106566B; Fri, 18 Jul 2008 09:50:24 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 409518FC28; Fri, 18 Jul 2008 09:50:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E3FC045CD8; Fri, 18 Jul 2008 09:06:27 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id ACFED45683; Fri, 18 Jul 2008 09:06:22 +0200 (CEST) Date: Fri, 18 Jul 2008 09:06:24 +0200 From: Pawel Jakub Dawidek To: Peter Jeremy Message-ID: <20080718070624.GC1976@garage.freebsd.pl> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <20080715095139.GA62764@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Remko Lodder , src-committers@freebsd.org, "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:50:24 -0000 --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2008 at 07:51:39PM +1000, Peter Jeremy wrote: > On 2008-Jul-15 02:14:46 -0700, Maxim Sobolev wrote: > >Not really relevant to the change in question, but I think that the=20 > >whole idea of geom_mirror updating on-disk metadata automagically is not= =20 > > very well thought out. For example one could try booting 7.x kernel on= =20 > >6.x system just to see how well it goes with the intention to revert=20 > >back if it doesn't work out well. >=20 > Agreed. I raised the same issue on -stable in late June. >=20 > >and re-creating/re-syncing the mirror after that. I've run into exactly= =20 > >this issue today, with the target machine stuck in unbootable state on= =20 > >another continent many thousand miles away. >=20 > I was lucky that I didn't need to revert. >=20 > >IMHO metadata update should be performed if and only if explicitly=20 > >requested by the administrator. >=20 > Agreed. It's especially worrying that there's absolutely no warning > that a particular version of geom_mirror has a different metadata > format and loading it will make your gmirror unusable with an older > gmirror. IMHO, any geom changes changes that prevent reversion > should be noted in UPDATING (at the very least). Just to be clear. I fully agree with you guys. What I could do about that when I was working on gmirror (starting from the simplest solution): 1. Skip disks which have version lower then what we have in the kernel. 2. Upgrade the on-disk metadata automatically. 3. Make gmirror kernel module to work with all the previous versions and add 'gmirror upgrade' command, so one can upgrade on-disk metadata. Keep in mind that unlike gconcat/gstripe, gmirror (or graid3) metadata is updated all the time to keep track of what's going on, so to be able to support older versions I've to have also conversion from the most recent version to the older ones, which may not be always straight-forward. Of course the only right solution is the 3rd one, but it is also the least trivial to implement. I implemented the 2nd one as a "good enough" alternative. Don't get me wrong, it's not super-hard to implement, so if there is a volunteer willing to code it, I can provide guidelines, if there isn't one, I'll get back to it, but be sure there is a PR assigned to me. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIgEDwForvXbEpPzQRAtFaAJ0ctgnwHqRsVRB/2hR5MDfbgN3KHwCgoBPU 4UKioV8Bg9ndmRCfzX5g2As= =Oaym -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 10:36:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56997106564A for ; Fri, 18 Jul 2008 10:36:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id C93A98FC14 for ; Fri, 18 Jul 2008 10:36:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so170336fgb.35 for ; Fri, 18 Jul 2008 03:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JOuhRR3TvNkvtLnQljSBc7ja1EgLwyWzWwQ7We+2pIw=; b=vQ8TnXDH+CayNt0HHBWNzHwB2pBZHtW1FzGB0FdPTjG0C+WlHOxeuiQsr3KA+PParz /IN2r3AqFDJXW7NRlW88106ltHMjrqwspL/Faip6u2LX3TgV36HR0DgfaGahFS4hNeRE 5MnmRnrsf3Ky/37C2MjP6xy/wnMDCiwQkKFV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ldBHBdxif18q6GXUqvd9apgU5AIEYkQDfu9jAhBHoJ6Oma8jg6Ue5LznTvukrzyOqx 9Or5CKRV0kIo+n0z0TxKczHetibFNVYq1W0LGvzIA+g0hbfT8k19PzBy6xoHLSXo3ZJk u4ZwWGxjbQ+0TTyDK3T+o9BU1udb1V3xW1/bg= Received: by 10.86.98.14 with SMTP id v14mr64142fgb.74.1216377376614; Fri, 18 Jul 2008 03:36:16 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Fri, 18 Jul 2008 03:36:16 -0700 (PDT) Message-ID: <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> Date: Fri, 18 Jul 2008 03:36:16 -0700 From: "Garrett Cooper" To: "Edward Ruggeri" In-Reply-To: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 10:36:18 -0000 On Thu, Jul 17, 2008 at 9:00 PM, Edward Ruggeri wrote: > Hi, > > I am getting a kernel panic (page fault) caused by the FreeBSD > kernel's ath driver shortly after I begin using the internet. I use > FreeBSD 7.0 CURRENT. I used cvs a few days ago to update the source > tree (7/10/08) and rebuilt the world as well as the kernel (just got a > brand new computer). There is very little software installed (ports > only, also built 7/10/08), and no data. But let me describe the > configuration and problem. > > I have recently purchased a Lenovo ThinkPad, with a ThinkPad 11a/b/g > Wi-Fi wireless LAN Mini-PCIe card (Lenovo part #41W1685). My Lenovo > representative claims this uses a Atheros Ar5006ex chipset (she's not > an expert, though), but FreeBSD's dmesg detects an Atheros 5212 > chipset. The Linux oriented thinkwiki.org claims this card may use > either chipset. I don't know who to trust; maybe someone knows the > answer, but Google hasn't seemed to clear things up. In particular, > from dmesg: Some notes: 1. *blinks*... I hope you mean 8-CURRENT, not 7-CURRENT. 7 hasn't been CURRENT for some months now (~6 months IIRC). 2. pciconf -lv might help with the PCI ID info. Then someone might be able to tie your card back to the appropriate chipset. 3. KDB, DDB, WITNESS and INVARIANTS support compiled into the kernel would be extremely helpful, if not required to debug your issue. As for the actual debug process, there's a spot in the dev handbook about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html), but when I tried debugging my issue with NTFS and SMB I didn't really find it helpful to be honest... You may also have to compile without SMP and with the 4BSD scheduler just to see whether or not it's an issue reproducible with the ULE scheduler, the driver, or something else... Hopefully this gets you started on the right path... -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 11:13:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6B49106568C for ; Fri, 18 Jul 2008 11:13:46 +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 6CDE88FC12 for ; Fri, 18 Jul 2008 11:13:46 +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 E479046C65; Fri, 18 Jul 2008 07:13:45 -0400 (EDT) Date: Fri, 18 Jul 2008 12:13:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Edward Ruggeri In-Reply-To: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> Message-ID: <20080718121102.D69806@fledge.watson.org> References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 11:13:46 -0000 On Fri, 18 Jul 2008, Edward Ruggeri wrote: > I can launch lynx (my favorite non-graphical browser) or firefox and load > google. I can make a search and get results, but the kernel always panics > by the time I try to load a third webpage (or earlier). This is what I get: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0484aa6 > stack pointer = 0x28:0xe7ffe8bc > frame pointer = 0x28:0xe7ffe928 > 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 = 1427 (lynx) [I've also seen this from ath0 taskq] > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 51m37s > Physical memory: 2014 MB > Dumping 109 MB: > Snyncing disks, vndoes remaining...[Zeros] > > I'm pretty much a freeBSD novice, so I don't know what to do as it prints > out line after line of zeros (slowly). Normally I just shut the sucker > down, because it seems content to print the zeros forever... But as FreeBSD > starts up, it says "savecore: no dumps found." But I have compiled the > kernel with debugging symbols (makeoptions DEBUG=-g), so maybe you can > advise. This is a NULL pointer dereference in the kernel, which almost certainly means a kernel bug. Per e-mail you've already received from Garrett Cooper, we need some further debugging information, such as a kernel astack trace. If you're unable to get a dump, a DDB stack trace would probably help quite a bit (options DDB, when it drops into the debugger, save the results of the command "trace"). Please do a file a PR with those results. I'm a bit puzzled that your box is syncing after a panic -- normally the kernel is configured not to do that -- could kern.sync_on_panic be set in your loader.conf or sysctl.conf? Robert N M Watson Computer Laboratory University of Cambridge > > I hope someone is able to help. Do you think I should file a problem report? > > Thanks for reading. Good night! > > Sincerely, > > -- Ned Ruggeri > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 09:46:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59ADF1065674; Fri, 18 Jul 2008 09:46:21 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id C06408FC14; Fri, 18 Jul 2008 09:46:20 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vincent-hoffmans-macbook-pro-15.local ([195.7.254.52]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m6I9ka8l065328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 10:46:38 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4880666A.6020501@unsane.co.uk> Date: Fri, 18 Jul 2008 10:46:18 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <486F8C57.9050908@wubethiopia.com> <20080705161614.O19209@fledge.watson.org> <200807170919.49756.jhb@freebsd.org> <487F7399.6040805@psg.com> <20080717205628.237ce4a4@peedub.jennejohn.org> In-Reply-To: <20080717205628.237ce4a4@peedub.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Jul 2008 11:18:42 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 09:46:21 -0000 Gary Jennejohn wrote: > On Thu, 17 Jul 2008 09:30:17 -0700 > Randy Bush wrote: > > >>> I think the best route to that is to have a separate utility for managing disk >>> partitioning. The installer can then use that utility, and sysadmins can >>> also use it later after the system is installed. >>> >> i often invoke sysinstall on a running system to slice/partition/etc a >> new drive >> >> > > [radically trimmed Cc list] > > sade(8) is supposed to take the place of sysinstall for disk operations. > > Ahh thats nice to know, might be worth adding to the handbook, I used to use /usr/ports/sysutils/sfdisk but somethng in base beats it. Vince > --- > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 11:58:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A606106568B; Fri, 18 Jul 2008 11:58:20 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id E20AB8FC0A; Fri, 18 Jul 2008 11:58:19 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m6IBJ1Br030958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2008 13:19:01 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <525E8FF6-307E-4DC9-B730-21435A2C2D2C@lassitu.de> From: Stefan Bethke To: Peter Jeremy In-Reply-To: <20080718071806.GV62764@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 18 Jul 2008 13:19:00 +0200 References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.928.1) Cc: Alexander Leidinger , Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 11:58:20 -0000 Am 18.07.2008 um 09:18 schrieb Peter Jeremy: > On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger > wrote: >> Are you aware that the parallel starting in Solaris 10 reduced the >> booting time by a nice percentage? > > Given that Solaris boots in geologic time, this probably wouldn't > be difficult. > >> If yes, do you expect that FreeBSD >> behaves significantly different or do you "just" want to see numbers? > > Parallel starting is not guaranteed to be an improvement. Starting a > whole pile of processes that are I/O bound during initialisation > (think squid or some databases) may be worse than starting them one > at a time. Likewise, a whole pile of processes that are CPU bound > will just thrash the scheduler. (Though parallel starting of I/O and > CPU bound processes should be a win). Just as a simple counter-example: it's very annoying when a startup script for a non-essential service is blocking startup for an essential one. (A Smokeping config of mine takes about 5 minutes to finish, and it's blocking sshd, as I found out the other day when I had to reboot the server.) Also see the repeated annoyances caused by dhclient on this list and elsewhere. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 12:12:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E1A11065674; Fri, 18 Jul 2008 12:12:30 +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 89D788FC1D; Fri, 18 Jul 2008 12:12:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55AA5.dip.t-dialin.net [84.165.90.165]) by redbull.bpaserver.net (Postfix) with ESMTP id 834032E264; Fri, 18 Jul 2008 14:12:23 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 9009A145440; Fri, 18 Jul 2008 14:12:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1216383130; bh=lYpikqQsIpoB5HfSC3NIZU04Yrje28G9+ LLpU+31wfw=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ILRBYQHWauDDxoDXEe+9rS7cZ/NsRWz7JpkpgjdVKTKnMlMjxKn7CgTP1eqht9Pef xDJPLxwFANXgj2uadpmfasESgKfipoyDsWgX5FIVoM906Gn5VUNmn0yrSrOeD+fF7Ha IExhilzwjMKjXC/ypJC38oiJbWbIhkHY/2192l4/dmm4s84Wi6CFV1Sze0WKc1LqW+C rFUPEzbjgy79R2EZmpk8WF4BdZvof00bkSS/9DLwSqlRxM5a/mbF/f3Io82KlxbJVLG wgLepyyqcV0ZZCP2ddGUT4N3SX7a0ef3Y07EntrgOdwgHRDQ4eYU+m5M3IcZ4EwN6CU RLab4/SiQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m6ICC9Sk056056; Fri, 18 Jul 2008 14:12:09 +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 Framework) with HTTP; Fri, 18 Jul 2008 14:12:08 +0200 Message-ID: <20080718141208.21091i4jkh44jc74@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 18 Jul 2008 14:12:08 +0200 From: Alexander Leidinger To: Peter Jeremy References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> In-Reply-To: <20080718071806.GV62764@server.vk2pj.dyndns.org> 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.2-RC2) / FreeBSD-8.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, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 12:12:30 -0000 Quoting Peter Jeremy (from Fri, 18 Jul =20 2008 17:18:07 +1000): > On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger =20 > wrote: >> Are you aware that the parallel starting in Solaris 10 reduced the >> booting time by a nice percentage? > > Given that Solaris boots in geologic time, this probably wouldn't > be difficult. How do you define "booting Solaris"? Do you include the extensive =20 tests prior to loading the kernel into this? I'm not talking about the =20 time a 25k needs (even when you reducing the amount of testing on the =20 system controller, it takes a long while until it reaches a state =20 which I would call the start of the boot of the OS). We are talking =20 about the pure userland part of booting. What is done during the =20 startup of important programs in Solaris is not unreasonable (and =20 similar/comparable between Solaris versions), and still, there's a =20 nice difference between Solaris 9 and 10 if you count the time until =20 you can start to do useful stuff. >> If yes, do you expect that FreeBSD >> behaves significantly different or do you "just" want to see numbers? > > Parallel starting is not guaranteed to be an improvement. Starting a > whole pile of processes that are I/O bound during initialisation > (think squid or some databases) may be worse than starting them one > at a time. Likewise, a whole pile of processes that are CPU bound It depends, think about independent disks and or keeping the squid =20 data in RAM (e.g. tmpfs). But this doesn't matter, we will always be able to come up with =20 situations where the parallel start is not a good idea. We don't come =20 by default with such a situation and I'm sure a lot of configs out =20 there that don't fall into this class. Based upon your argument we =20 could say we can not enable parallel starting even if we see it is an =20 improvement for the reboot after the installation. What I wanted to know is if there's an substantial argument (it can =20 not behave similar to Solaris, because of A and B), or if he "just" =20 wants to know what the difference on FreeBSD is. > will just thrash the scheduler. (Though parallel starting of I/O and > CPU bound processes should be a win). You forgot about round-trip-time bound processes (basically processes =20 which wait for an event to occur before they say they are successfully =20 started), and we have several of them. Bye, Alexander. --=20 Those who hate and fight must stop themselves -- otherwise it is not stopped. =09=09-- Spock, "Day of the Dove", stardate unknown 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 Fri Jul 18 12:29:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E405B1065678 for ; Fri, 18 Jul 2008 12:29:37 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 595318FC0C for ; Fri, 18 Jul 2008 12:29:36 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6ICTYoQ025370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jul 2008 14:29:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6ICTU4b024226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 14:29:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6ICTU9d047833; Fri, 18 Jul 2008 14:29:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6ICTSE2047832; Fri, 18 Jul 2008 14:29:28 +0200 (CEST) (envelope-from ticso) Date: Fri, 18 Jul 2008 14:29:28 +0200 From: Bernd Walter To: Peter Jeremy Message-ID: <20080718122928.GD35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080718071806.GV62764@server.vk2pj.dyndns.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.150, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Alexander Leidinger , Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 12:29:38 -0000 On Fri, Jul 18, 2008 at 05:18:07PM +1000, Peter Jeremy wrote: > On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger wrote: > >Are you aware that the parallel starting in Solaris 10 reduced the > >booting time by a nice percentage? > > Given that Solaris boots in geologic time, this probably wouldn't > be difficult. > > > If yes, do you expect that FreeBSD > >behaves significantly different or do you "just" want to see numbers? > > Parallel starting is not guaranteed to be an improvement. Starting a > whole pile of processes that are I/O bound during initialisation > (think squid or some databases) may be worse than starting them one > at a time. Likewise, a whole pile of processes that are CPU bound > will just thrash the scheduler. (Though parallel starting of I/O and > CPU bound processes should be a win). Speaking about small systems, where startup time is more a problem than on 08/15 desktop and server systems. What I would love to see is that scripts like moused, ypserv, lpt, etc are not started if the services are disabled. So far each script is started, sucks in routines plus rc.conf then possibly does nothing reasonable after wasting some seconds boottime. Of course I can remove the scripts, but you'll never know if you need one of them at a later time and having the right set of scripts can become tricky. Parallel however doesn't sound interesting for me, since those systems are CPU and memory bound, so I don't see a possible win, maybe even a degration if memory restricts. > >Sidenote: Even if there's no significant speedup, the possibility to > >start things in parallel should be provided, this would allow more > >experimentation (at all respectively later). > > Agreed. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 12:52:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18221065678; Fri, 18 Jul 2008 12:52:45 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id 350098FC19; Fri, 18 Jul 2008 12:52:45 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from vpn2764.extern.uni-tuebingen.de ([134.2.187.14] helo=admins-macbook.local) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJpS1-0002ck-5A; Fri, 18 Jul 2008 14:52:45 +0200 Message-ID: <4880921C.10700@lobraun.de> Date: Fri, 18 Jul 2008 14:52:44 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Kris Kennaway References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> In-Reply-To: <48806684.4000908@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 12:52:45 -0000 Hi, Kris Kennaway wrote: >> dmesg says: >> >> SGI XFS with large block numbers, tracing, no debug enabled >> fsname '/dev/ad8s4' logname '' rtname '' >> flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 >> xfs_setsize_buftarg NI 0xc692d420 >> XFS mounting filesystem /dev/ad8s4 >> Ending clean XFS mount for filesystem: /dev/ad8s4 >> xfs_iunpin: REC RECABLE ip 0xc6f89d38 >> xfs_iunpin: REC RECABLE ip 0xc6f8a000 >> xfs_iflush: ip 0xc6f89d38 i_ino 131 >> >> >> I'll recompile the kernel with INVARIANTS and WITNESS enabled in order >> to get more information about the problem. > > And DEBUG_LOCKS and DEBUG_VFS_LOCKS please :) I now have makeoptions DEBUG=-g options KDB # Enable kernel debugger support. options KDB_UNATTENDED options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options DEBUG_LOCKS options DEBUG_VFS_LOCKS enabled and got the following output in /var/log/messages: Jul 18 12:28:14 finch kernel: SGI XFS with large block numbers, tracing, no debug enabled Jul 18 12:28:14 finch kernel: fsname '/dev/ad8s4' logname '' rtname '' Jul 18 12:28:14 finch kernel: flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 Jul 18 12:28:14 finch kernel: xfs_setsize_buftarg NI 0xc6773a60 Jul 18 12:28:14 finch kernel: XFS mounting filesystem /dev/ad8s4 Jul 18 12:28:15 finch kernel: Ending clean XFS mount for filesystem: /dev/ad8s4 Jul 18 12:28:20 finch kernel: lock order reversal: Jul 18 12:28:20 finch kernel: 1st 0xc6dd95b8 xfs (xfs) @ /usr/src/sys/kern/vfs_lookup.c:432 Jul 18 12:28:20 finch kernel: 2nd 0xc6f9e090 xfsino (xfsino) @ /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_iget.c:881 Jul 18 12:28:20 finch kernel: 3rd 0xc6fa1058 xfs (xfs) @ /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_freebsd_iget.c:393 Jul 18 12:28:20 finch kernel: KDB: stack backtrace: Jul 18 12:28:20 finch kernel: db_trace_self_wrapper(c0b2f902,e8fc2760,c07ce8ee,c0b32188,c6fa1058,...) at db_trace_self_wrapper+0x26 Jul 18 12:28:20 finch kernel: kdb_backtrace(c0b32188,c6fa1058,c6ee0df9,c6ee0df9,c6ee0d4e,...) at kdb_backtrace+0x29 Jul 18 12:28:20 finch kernel: witness_checkorder(c6fa1058,9,c6ee0d4e,189,4,...) at witness_checkorder+0x6de Jul 18 12:28:20 finch kernel: __lockmgr_args(c6fa1058,80400,c6fa10c0,0,0,...) at __lockmgr_args+0x777 Jul 18 12:28:20 finch kernel: vop_stdlock(e8fc2860,c6fa10f4,c6fa1000,80400,c6fa1000,...) at vop_stdlock+0x65 Jul 18 12:28:20 finch kernel: VOP_LOCK1_APV(c6eea5c0,e8fc2860,c0c3a2a0,c6fa1000,80400,...) at VOP_LOCK1_APV+0xa5 Jul 18 12:28:20 finch kernel: _vn_lock(c6fa1000,80400,c6ee0d4e,189,e8fc28dc,...) at _vn_lock+0x5e Jul 18 12:28:20 finch kernel: xfs_iget(c6926800,c6fa3000,83,0,1,...) at xfs_iget+0x27b Jul 18 12:28:20 finch kernel: xfs_trans_iget(c6926800,c6fa3000,83,0,1,...) at xfs_trans_iget+0x256 Jul 18 12:28:20 finch kernel: xfs_ialloc(c6fa3000,c6f9e000,41ed,2,0,...) at xfs_ialloc+0xda Jul 18 12:28:20 finch kernel: xfs_dir_ialloc(e8fc2a78,c6f9e000,41ed,2,0,...) at xfs_dir_ialloc+0x82 Jul 18 12:28:20 finch kernel: xfs_mkdir(c6f9e020,e8fc2c04,e8fc2ab4,e8fc2b28,c69dd700,...) at xfs_mkdir+0x457 Jul 18 12:28:20 finch kernel: _xfs_mkdir(e8fc2c28,c0b6262e,0,e8fc2c28,e8fc2bd8,...) at _xfs_mkdir+0xb0 Jul 18 12:28:20 finch kernel: VOP_MKDIR_APV(c6eea5c0,e8fc2c28,e97,e95,1,...) at VOP_MKDIR_APV+0xc5 Jul 18 12:28:20 finch kernel: kern_mkdirat(c67778c0,ffffff9c,bfbfee32,0,1ff,...) at kern_mkdirat+0x276 Jul 18 12:28:20 finch kernel: kern_mkdir(c67778c0,bfbfee32,0,1ff,e8fc2d2c,...) at kern_mkdir+0x2e Jul 18 12:28:20 finch kernel: mkdir(c67778c0,e8fc2cf8,8,c,c0c003e0,...) at mkdir+0x29 Jul 18 12:28:20 finch kernel: syscall(e8fc2d38) at syscall+0x2a3 Jul 18 12:28:20 finch kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 18 12:28:20 finch kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x28159cd3, esp = 0xbfbfec5c, ebp = 0xbfbfed28 --- Jul 18 12:28:23 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f9dd80 Jul 18 12:28:23 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f9e000 Jul 18 12:28:25 finch kernel: System call stat returning with the following locks held: Jul 18 12:28:25 finch kernel: exclusive lockmgr xfs r = 0 (0xc6fa1058) locked @ /usr/src/sys/modules/xfs/../. Can I provide any additional information? Regards, Lothar From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 14:25:46 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56985106564A; Fri, 18 Jul 2008 14:25:46 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 027AA8FC15; Fri, 18 Jul 2008 14:25:45 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m6IEQHDg032469; Fri, 18 Jul 2008 10:26:17 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m6IEQGgn032468; Fri, 18 Jul 2008 10:26:16 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 18 Jul 2008 10:26:16 -0400 From: David Schultz To: Peter Jeremy Message-ID: <20080718142616.GA32265@zim.MIT.EDU> Mail-Followup-To: Peter Jeremy , Alexander Leidinger , Doug Barton , David Naylor , freebsd-current@FreeBSD.ORG References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080718071806.GV62764@server.vk2pj.dyndns.org> Cc: Alexander Leidinger , Doug Barton , David Naylor , freebsd-current@FreeBSD.ORG Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 14:25:46 -0000 On Fri, Jul 18, 2008, Peter Jeremy wrote: > On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger wrote: > >Are you aware that the parallel starting in Solaris 10 reduced the > >booting time by a nice percentage? > > Given that Solaris boots in geologic time, this probably wouldn't > be difficult. Solaris actually boots significantly faster than FreeBSD on my desktops, but that's not because of the parallel rc startup--- it's mainly for the completely orthogonal reason that the USB stack and the ata(4) driver in FreeBSD take an eternity to probe. So I suspect that people interested in making FreeBSD boot faster could find lots of low-hanging fruit even without touching rc. > Parallel starting is not guaranteed to be an improvement. Starting a > whole pile of processes that are I/O bound during initialisation > (think squid or some databases) may be worse than starting them one > at a time. Likewise, a whole pile of processes that are CPU bound > will just thrash the scheduler. (Though parallel starting of I/O and > CPU bound processes should be a win). Parallel service startup in Solaris does seem to save time (although this is on a dual core; I haven't tried a UP system). Keep in mind also that many rc scripts spend a few seconds waiting on the network, and that time could be better spent starting something else. That said, parallel startup doesn't make an enormous difference, and that wasn't the main reason Sun wrote SMF. The main motivation was to be able to automatically restart failed services and their dependencies, and provide better administrative tools. If you can find a way to decrease the boot time considerably, many people won't care, but I'm sure some will greatly appreciate it. There are two ways to cut downtime in half: make the system crash half as often, or make it recover twice as fast. The latter is probably an easier task. :) From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 16:16:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3E3106566B for ; Fri, 18 Jul 2008 16:16:23 +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 68C6D8FC17 for ; Fri, 18 Jul 2008 16:16:22 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl13-149.kln.forthnet.gr [77.49.140.149]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6IFwPYb004159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Jul 2008 18:58:30 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6IFwOmA002127 for ; Fri, 18 Jul 2008 18:58:24 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6IFwOUO002126; Fri, 18 Jul 2008 18:58:24 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: freebsd-current@freebsd.org Date: Thu, 17 Jul 2008 21:20:59 +0300 Message-ID: <87prpcjrsk.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-MailScanner-ID: m6IFwPYb004159 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.762, required 5, ALL_TRUSTED -1.80, AWL -0.35, BAYES_00 -2.60, DATE_IN_PAST_12_24 0.99) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Subject: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 16:16:23 -0000 --=-=-= I recently had to replace my dead laptop, and I bought a replacement relatively fast, but something is broken with APIC on this one. FreeSBIE 2.0.1 (based on 6.2-RELEASE) seems to automatically disable the APIC, using hint.apic.0.disabled="1", so I didn't realize APIC failed to work properly until I dump(8) and restore(8)'d my backup to the new laptop. After booting with the APIC enabled, I found out that: * In single user mode, after `boot -sv', I can keep working without any major slow down. * When I exit single user mode, and a few of the rc.d startup scripts run, the laptop becomes progressively slower, and eventually crawls to an unusable state. I can almost complete logging in as `root' in ttyv0 but only if I keep furiously moving the mouse around. If I don't move the mouse at all, the typed characters may never actually appear on ttyv0. I tried booting with APIC enabled and disabled, and grabbed most of the output of `dmesg'. I think I can also grab `vmstat -i' output with the APIC enabled, but I don't have a serial console, so it may take a few iterations. Attached are the two dmesg files with and without the APIC. Any ideas if this is a bug in FreeBSD or a completely bogus APIC? --=-=-= Content-Disposition: inline; filename=dmesg.apic Content-Description: dmesg output with APIC enabled Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Tue Jul 8 09:10:21 EEST 2008 build@kobe:/home/build/obj/home/build/src/sys/KOBE WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b2f000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b2f25c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2094760227 Hz CPU: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz (2094.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3bd> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 3072 kbytes, 8-way associative, 64 bytes/line real memory = 2137849856 (2038 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000007d4a1fff, 2089275392 bytes (510077 pages) avail memory = 2088751104 (1991 MB) Table 'FACP' at 0x7f6dbd48 Table 'APIC' at 0x7f6dbe3c MADT: Found table at 0x7f6dbe3c MP Configuration Table version 1.4 found at 0xc009fd71 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 0xc00f7c30 bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfdb80+0x221 pnpbios: Found PnP BIOS data at 0xc00f7ca0 pnpbios: Entry = f0000:c0bc Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf7c00/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0x7f6d4062/0x008C (v 1 PTLTD XSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x7f6dbd48/0x00F4 (v 3 INTEL CRESTLNE 0x06040000 ALAN 0x00000001) ACPI: DSDT @ 0x0x7f6d5e3b/0x5E99 (v 2 INTEL CRESTLNE 0x06040000 INTL 0x20050624) ACPI: FACS @ 0x0x7f6defc0/0x0040 ACPI: APIC @ 0x0x7f6dbe3c/0x0068 (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: HPET @ 0x0x7f6dbea4/0x0038 (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: MCFG @ 0x0x7f6dbedc/0x003C (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: TCPA @ 0x0x7f6dbf18/0x0032 (v 1 Intel CRESTLN 0x06040000 0x00005A52) ACPI: TMOR @ 0x0x7f6dbf4a/0x0026 (v 1 PTLTD 0x06040000 PTL 0x00000003) ACPI: APIC @ 0x0x7f6dbf70/0x0068 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x7f6dbfd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SSDT @ 0x0x7f6d57ec/0x064F (v 1 SataRe SataPri 0x00001000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d515a/0x0692 (v 1 SataRe SataSec 0x00001000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d467a/0x0258 (v 1 PmRef Cpu0Tst 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d45d4/0x00A6 (v 1 PmRef Cpu1Tst 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d40ee/0x04E6 (v 1 PmRef CpuPm 0x00003000 INTL 0x20050624) 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 ath_rate: version 1.2 wlan: <802.11 Link Layer> random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: nfslock: pseudo-device 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 0xc4a79000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa04 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=2a008086) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.MCHC.HBUS -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 ACPI timer: 0/3 0/3 1/2 0/3 1/2 1/2 0/3 0/3 1/2 1/2 -> 5 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a02, revid=0x03 domain=0, 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=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0c00000, size 20, enabled map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2a03, revid=0x03 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xf0d00000, size 20, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2835, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf1204000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x284b, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf1200000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x283f, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 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=0x2841, revid=0x03 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2843, revid=0x03 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 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=0x2845, revid=0x03 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2847, revid=0x03 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 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=0x2849, revid=0x03 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2830, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf1204400, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2828, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 3 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x18e0, size 4, enabled map[24]: type I/O Port, range 32, base 0x18d0, size 4, enabled found-> vendor=0x8086, dev=0x283e, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0, size 8, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xf0c00000-0xf0cfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf0c00000 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf0d00000-0xf0dfffff at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf1204000-0xf12043ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf1204000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered ugen0: on uhub2 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 3 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf0e00000-0xf0efffff pcib1: no prefetched decode pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x4229, revid=0x61 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf0e00000, size 13, enabled pcib1: requested memory range 0xf0e00000-0xf0e01fff: good pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 4 pcib2: subordinate bus 5 pcib2: I/O decode 0x2000-0x2fff pcib2: memory decode 0xf0600000-0xf07fffff pcib2: prefetched decode 0xf0000000-0xf01fffff pci4: on pcib2 pci4: domain=0, physical bus=4 pcib3: irq 18 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 6 pcib3: subordinate bus 7 pcib3: I/O decode 0x3000-0x3fff pcib3: memory decode 0xf0800000-0xf09fffff pcib3: prefetched decode 0xf0200000-0xf03fffff pci6: on pcib3 pci6: domain=0, physical bus=6 pcib4: irq 19 at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 8 pcib4: subordinate bus 9 pcib4: I/O decode 0x4000-0x4fff pcib4: memory decode 0xf0a00000-0xf0bfffff pcib4: prefetched decode 0xf0400000-0xf05fffff pci8: on pcib4 pci8: domain=0, physical bus=8 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib4: requested I/O range 0x4000-0x40ff: in range map[18]: type Memory, range 64, base 0xf0a00000, size 12, enabled pcib4: requested memory range 0xf0a00000-0xf0a00fff: good pcib4: matched entry for 8.0.INTA pcib4: slot 0 INTA hardwired to IRQ 19 pci8: at device 0.0 (no driver attached) pcib5: irq 17 at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0xf000-0xfff pcib5: no prefetched decode pci10: on pcib5 pci10: domain=0, physical bus=10 pcib6: irq 16 at device 28.5 on pci0 pcib6: domain 0 pcib6: secondary bus 11 pcib6: subordinate bus 11 pcib6: I/O decode 0xf000-0xfff pcib6: no prefetched decode pci11: on pcib6 pci11: domain=0, physical bus=11 uhci2: port 0x1860-0x187f irq 23 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 19 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xf1204400-0xf12047ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf1204400 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pcib7: domain 0 pcib7: secondary bus 12 pcib7: subordinate bus 12 pcib7: I/O decode 0x5000-0x5fff pcib7: memory decode 0xf0f00000-0xf0ffffff pcib7: no prefetched decode pcib7: Subtractively decoded bridge. pci12: on pcib7 pci12: domain=0, physical bus=12 found-> vendor=0x1524, dev=0x0730, revid=0x00 domain=0, bus=12, slot=7, func=0 class=05-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x04 (1000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00000, size 7, enabled pcib7: requested memory range 0xf0f00000-0xf0f0007f: good pcib7: matched entry for 12.7.INTA pcib7: slot 7 INTA hardwired to IRQ 16 found-> vendor=0x1524, dev=0x0750, revid=0x00 domain=0, bus=12, slot=7, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00400, size 8, enabled pcib7: requested memory range 0xf0f00400-0xf0f004ff: good pcib7: matched entry for 12.7.INTA pcib7: slot 7 INTA hardwired to IRQ 16 found-> vendor=0x1524, dev=0x0751, revid=0x00 domain=0, bus=12, slot=7, func=3 class=05-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 8, memory disabled found-> vendor=0x1106, dev=0x3044, revid=0xc0 domain=0, bus=12, slot=9, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=10 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00800, size 11, enabled pcib7: requested memory range 0xf0f00800-0xf0f00fff: good map[14]: type I/O Port, range 32, base 0x5000, size 7, enabled pcib7: requested I/O range 0x5000-0x507f: in range pcib7: matched entry for 12.9.INTA pcib7: slot 9 INTA hardwired to IRQ 19 pci12: at device 7.0 (no driver attached) pci12: at device 7.1 (no driver attached) pci12: at device 7.3 (no driver attached) fwohci0: port 0x5000-0x507f mem 0xf0f00800-0xf0f00fff irq 19 at device 9.0 on pci12 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xf0f00800 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:43:35 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d474000 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:00:43:35 fwe0: bpf attached fwe0: Ethernet address: 02:00:00:00:43:35 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:00:00:00:00:00:43:35 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18e0-0x18ef,0x18d0-0x18df at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x18e0 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 54 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=01 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=10 stat1=01 devices=0x10000 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) cpu0: on acpi0 ACPI: SSDT @ 0x0x7f6d4e01/0x02A8 (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d48d2/0x04AA (v 1 PmRef Cpu0Cst 0x00003001 INTL 0x20050624) est0: on cpu0 est0: Invalid id16 (set, cur) = (19240, 18978) est0: Invalid freq 2101, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x7f6d50a9/0x00B1 (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d4d7c/0x0085 (v 1 PmRef Cpu1Cst 0x00003000 INTL 0x20050624) est1: on cpu1 est1: Invalid id16 (set, cur) = (19240, 18978) est1: Invalid freq 2101, ignored. p4tcc1: on cpu1 battery0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) 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 56 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 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 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 0xcf000-0xcffff,0xe0000-0xe17ff 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: 0x8ea1 0x8ea1 0x8ea1 0x8ea1 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: 0x8ea1 0x8ea1 0x8ea1 0x8ea1 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 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8ea1 0x8ea1 0x8ea1 0x8ea1 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) isa_probe_children: probing PnP devices ums0: on uhub3 ums0: 16 buttons and Z dir. uhid0: on uhub3 ugen1: on uhub5 Device configuration finished. Reducing kern.maxvnodes 133914 -> 100000 procfs registered lapic: Divisor 2, Frequency 99750489 hz Timecounter "TSC" frequency 2094760227 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pflog0: bpf attached pfsync0: bpf attached ata0: identify ch->devices=00000001 battery0: battery initialization start acpi_acad0: acline initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire atapicam: atapicam0 already exists; skipping it ad0: 238475MB at ata0-master UDMA33 ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ata1: identify ch->devices=00010000 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire battery0: battery initialization done, tried 1 times acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 172KB/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 acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM_LABEL: Label for provider ad0s1a is ufs/GKEROOT. GEOM_LABEL: Label for provider ad0s1e is ufs/GKERHOME. 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): error 6 (probe0:ata1:0:0:0): Unretryable Error 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 (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 - tray closed 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 21 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 WARNING: WITNESS option enabled, expect reduced performance. (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 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error lock order reversal: (sleepable after non-sleepable) 1st 0xc510a01c struct mount mtx (struct mount mtx) @ /home/build/src/sys/kern/vfs_subr.c:343 2nd 0xc510a000 vfslock (vfslock) @ /home/build/src/sys/kern/vfs_subr.c:370 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a83b64,c061992e,c08ce22a,c510a000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,c510a000,c08d4159,c08d4159,c08d46fe,...) at kdb_backtrace+0x29 witness_checkorder(c510a000,1,c08d46fe,172,c097cff4,...) at witness_checkorder+0x6de __lockmgr_args(c510a000,200100,c510a01c,0,0,...) at __lockmgr_args+0x230 vfs_busy(c510a000,200,0,c4c97d20,1,...) at vfs_busy+0x1bc vfs_mount_alloc(0,c09149e0,c08d44a4,c4c97d20,c06574c0,...) at vfs_mount_alloc+0x78 vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x26c start_init(0,c4a83d38,c08c4c0f,322,c4c95d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a83d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a83d70, ebp = 0 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc4f84e10 vnode interlock (vnode interlock) @ /home/build/src/sys/fs/devfs/devfs_vnops.c:288 2nd 0xc4f84df4 devfs (devfs) @ /home/build/src/sys/kern/vfs_subr.c:2044 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a83a8c,c061992e,c08ce22a,c4f84df4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,c4f84df4,c08be913,c08be913,c08d46fe,...) at kdb_backtrace+0x29 witness_checkorder(c4f84df4,9,c08d46fe,7fc,c4f84df4,...) at witness_checkorder+0x6de __lockmgr_args(c4f84df4,80100,c4f84e10,0,0,...) at __lockmgr_args+0x777 vop_stdlock(c4a83b8c,c08bead7,c08c1e97,80100,c4f84d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0914ac0,c4a83b8c,c0951ea0,c4f84d9c,80100,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4f84d9c,80100,c08d46fe,7fc,c08bead7,...) at _vn_lock+0x5e vget(c4f84d9c,80100,c4c97d20,121,c08bea6d,...) at vget+0x9c devfs_allocv(c50cd900,c510a000,c4a83c20,c4c97d20,c4c97dc4,...) at devfs_allocv+0x11a devfs_root(c510a000,80000,c09c4db4,c4c97d20,4,...) at devfs_root+0x51 set_rootvnode(c09c4da0,0,c08d4054,5f1,c06574c0,...) at set_rootvnode+0x2d vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x34c start_init(0,c4a83d38,c08c4c0f,322,c4c95d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a83d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a83d70, ebp = 0 --- Trying to mount root from ufs:/dev/ad0s1a ct_to_ts([2008-07-17 05:40:08]) = 1216273208.000000000 lock order reversal: (sleepable after non-sleepable) 1st 0xc4f84b20 bufobj interlock (bufobj interlock) @ /home/build/src/sys/kern/vfs_bio.c:2442 2nd 0xd8ce5c80 bufwait (bufwait) @ /home/build/src/sys/kern/vfs_bio.c:2456 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a83784,c061992e,c08ce22a,d8ce5c80,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,d8ce5c80,c08d2fec,c08d2fec,c08d2594,...) at kdb_backtrace+0x29 witness_checkorder(d8ce5c80,9,c08d2594,998,c097cff4,...) at witness_checkorder+0x6de __lockmgr_args(d8ce5c80,81900,c4f84b20,c08d2f48,50,...) at __lockmgr_args+0x777 getblk(c4f84a78,0,0,800,0,...) at getblk+0x153 breadn(c4f84a78,0,0,800,0,...) at breadn+0x44 bread(c4f84a78,0,0,800,0,...) at bread+0x4c ffs_blkatoff(c4f84a78,0,0,0,c4a839a4,...) at ffs_blkatoff+0xd1 ufs_lookup(c4a839e8,c4f84a78,c4a83b38,c4f84a78,c4a83a08,...) at ufs_lookup+0x2e6 VOP_CACHEDLOOKUP_APV(c093b4c0,c4a839e8,c4a83b38,c4a83b24,c4c9c800,...) at VOP_CACHEDLOOKUP_APV+0xa5 vfs_cache_lookup(c4a83a68,c4a83a68,500000c,80000,c4f84a78,...) at vfs_cache_lookup+0xd0 VOP_LOOKUP_APV(c093b4c0,c4a83a68,c08d3dfb,1b0,c4a83b24,...) at VOP_LOOKUP_APV+0xa5 lookup(c4a83b0c,c08d3dfb,d8,c0,c4c6922c,...) at lookup+0x57e namei(c4a83b0c,c4a83b24,c061910c,c08d4159,c08d44a0,...) at namei+0x44b kern_unlinkat(c4c97d20,ffffff9c,c08d44a0,1,c4a83c5c,...) at kern_unlinkat+0x46 kern_unlink(c4c97d20,c08d44a0,1,62c,0,...) at kern_unlink+0x27 vfs_mountroot_try(c08d465a,c08c1e99,c08bc8a9,1,c06574c0,...) at vfs_mountroot_try+0x482 vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x40e start_init(0,c4a83d38,c08c4c0f,322,c4c95d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a83d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a83d70, ebp = 0 --- start_init: trying /sbin/init GEOM_LABEL: Label ufs/GKEROOT removed. GEOM_LABEL: Label for provider ad0s1a is ufs/GKEROOT. GEOM_LABEL: Label ufs/GKERHOME removed. GEOM_LABEL: Label for provider ad0s1e is ufs/GKERHOME. GEOM_LABEL: Label ufs/GKEROOT removed. GEOM_LABEL: Label ufs/GKERHOME removed. --=-=-= Content-Disposition: inline; filename=dmesg.noapic Content-Description: dmesg output without APIC Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Tue Jul 8 09:10:21 EEST 2008 build@kobe:/home/build/obj/home/build/src/sys/KOBE WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b3a000. Preloaded elf module "/boot/kernel/if_re.ko" at 0xc0b3a25c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b3a308. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2094763555 Hz CPU: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz (2094.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3bd> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 3072 kbytes, 8-way associative, 64 bytes/line real memory = 2137849856 (2038 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000007d4a1fff, 2089275392 bytes (510077 pages) avail memory = 2088747008 (1991 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7c30 bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfdb80+0x221 pnpbios: Found PnP BIOS data at 0xc00f7ca0 pnpbios: Entry = f0000:c0bc Rev = 1.0 Other BIOS signatures found: WARNING: Non-uniform processors. WARNING: Using suboptimal topology. ULE: setup cpu 0 ath_rate: version 1.2 wlan: <802.11 Link Layer> random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: nfslock: pseudo-device ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI: RSDP @ 0x0xf7c00/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0x7f6d4062/0x008C (v 1 PTLTD XSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x7f6dbd48/0x00F4 (v 3 INTEL CRESTLNE 0x06040000 ALAN 0x00000001) ACPI: DSDT @ 0x0x7f6d5e3b/0x5E99 (v 2 INTEL CRESTLNE 0x06040000 INTL 0x20050624) ACPI: FACS @ 0x0x7f6defc0/0x0040 ACPI: APIC @ 0x0x7f6dbe3c/0x0068 (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: HPET @ 0x0x7f6dbea4/0x0038 (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: MCFG @ 0x0x7f6dbedc/0x003C (v 1 INTEL CRESTLNE 0x06040000 LOHR 0x0000005A) ACPI: TCPA @ 0x0x7f6dbf18/0x0032 (v 1 Intel CRESTLN 0x06040000 0x00005A52) ACPI: TMOR @ 0x0x7f6dbf4a/0x0026 (v 1 PTLTD 0x06040000 PTL 0x00000003) ACPI: APIC @ 0x0x7f6dbf70/0x0068 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x7f6dbfd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SSDT @ 0x0x7f6d57ec/0x064F (v 1 SataRe SataPri 0x00001000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d515a/0x0692 (v 1 SataRe SataSec 0x00001000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d467a/0x0258 (v 1 PmRef Cpu0Tst 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d45d4/0x00A6 (v 1 PmRef Cpu1Tst 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d40ee/0x04E6 (v 1 PmRef CpuPm 0x00003000 INTL 0x20050624) npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4a79000 pa 0x1000 atpic: Programming IRQ9 as level/low pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa04 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=2a008086) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.MCHC.HBUS -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 ACPI timer: 0/3 1/2 1/2 1/2 0/3 0/3 1/2 1/2 0/3 1/2 -> 6 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.2.INTA at func 0: 5 ACPI: Found matching pin for 0.26.INTA at func 0: 5 ACPI: Found matching pin for 0.26.INTB at func 1: 11 ACPI: Found matching pin for 0.26.INTC at func 7: 7 ACPI: Found matching pin for 0.27.INTA at func 0: 11 pci_link6: BIOS IRQ 11 for 0.27.INTA is invalid ACPI: Found matching pin for 0.28.INTA at func 0: 10 pci_link1: BIOS IRQ 10 for 0.28.INTA is invalid ACPI: Found matching pin for 0.28.INTB at func 1: 5 ACPI: Found matching pin for 0.28.INTC at func 2: 7 ACPI: Found matching pin for 0.28.INTD at func 3: 10 pci_link3: BIOS IRQ 10 for 0.28.INTD is invalid ACPI: Found matching pin for 0.29.INTA at func 0: 10 pci_link7: BIOS IRQ 10 for 0.29.INTA is invalid ACPI: Found matching pin for 0.29.INTB at func 1: 10 pci_link3: BIOS IRQ 10 for 0.29.INTB is invalid ACPI: Found matching pin for 0.29.INTC at func 2: 7 ACPI: Found matching pin for 0.31.INTB at func 2: 255 ACPI: Found matching pin for 0.31.INTC at func 3: 10 pci_link3: BIOS IRQ 10 for 0.31.INTC is invalid pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a02, revid=0x03 domain=0, 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=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0c00000, size 20, enabled map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.LPCB.LNKA:0) pcib0: slot 2 INTA routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x8086, dev=0x2a03, revid=0x03 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xf0d00000, size 20, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA (src \\_SB_.PCI0.LPCB.LNKA:0) pcib0: slot 26 INTA routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x8086, dev=0x2835, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB (src \\_SB_.PCI0.LPCB.LNKF:0) pcib0: slot 26 INTB routed to irq 11 via \\_SB_.PCI0.LPCB.LNKF found-> vendor=0x8086, dev=0x283a, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf1204000, size 10, enabled pcib0: matched entry for 0.26.INTC (src \\_SB_.PCI0.LPCB.LNKC:0) pcib0: slot 26 INTC routed to irq 7 via \\_SB_.PCI0.LPCB.LNKC found-> vendor=0x8086, dev=0x284b, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf1200000, size 14, enabled pcib0: matched entry for 0.27.INTA (src \\_SB_.PCI0.LPCB.LNKG:0) pci_link6: Picked IRQ 9 with weight 0 pcib0: slot 27 INTA routed to irq 9 via \\_SB_.PCI0.LPCB.LNKG found-> vendor=0x8086, dev=0x283f, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA (src \\_SB_.PCI0.LPCB.LNKB:0) pci_link1: Picked IRQ 11 with weight 1 pcib0: slot 28 INTA routed to irq 11 via \\_SB_.PCI0.LPCB.LNKB found-> vendor=0x8086, dev=0x2841, revid=0x03 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB (src \\_SB_.PCI0.LPCB.LNKA:0) pcib0: slot 28 INTB routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x8086, dev=0x2843, revid=0x03 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC (src \\_SB_.PCI0.LPCB.LNKC:0) pcib0: slot 28 INTC routed to irq 7 via \\_SB_.PCI0.LPCB.LNKC found-> vendor=0x8086, dev=0x2845, revid=0x03 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD (src \\_SB_.PCI0.LPCB.LNKD:0) pci_link3: Picked IRQ 9 with weight 1 pcib0: slot 28 INTD routed to irq 9 via \\_SB_.PCI0.LPCB.LNKD found-> vendor=0x8086, dev=0x2847, revid=0x03 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA (src \\_SB_.PCI0.LPCB.LNKB:0) pcib0: slot 28 INTA routed to irq 11 via \\_SB_.PCI0.LPCB.LNKB found-> vendor=0x8086, dev=0x2849, revid=0x03 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB (src \\_SB_.PCI0.LPCB.LNKA:0) pcib0: slot 28 INTB routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x8086, dev=0x2830, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPCB.LNKH:0) pci_link7: Picked IRQ 11 with weight 3 pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LPCB.LNKH found-> vendor=0x8086, dev=0x2831, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.PCI0.LPCB.LNKD:0) pcib0: slot 29 INTB routed to irq 9 via \\_SB_.PCI0.LPCB.LNKD found-> vendor=0x8086, dev=0x2832, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.PCI0.LPCB.LNKC:0) pcib0: slot 29 INTC routed to irq 7 via \\_SB_.PCI0.LPCB.LNKC found-> vendor=0x8086, dev=0x2836, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf1204400, size 10, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPCB.LNKH:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LPCB.LNKH found-> vendor=0x8086, dev=0x2448, revid=0xf3 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2828, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 3 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x18e0, size 4, enabled map[24]: type I/O Port, range 32, base 0x18d0, size 4, enabled found-> vendor=0x8086, dev=0x283e, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0, size 8, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 5, enabled pcib0: matched entry for 0.31.INTC (src \\_SB_.PCI0.LPCB.LNKD:0) pcib0: slot 31 INTC routed to irq 9 via \\_SB_.PCI0.LPCB.LNKD vgapci0: port 0x1800-0x1807 mem 0xf0c00000-0xf0cfffff,0xd0000000-0xdfffffff irq 5 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf0c00000 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf0d00000-0xf0dfffff at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 5 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 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 0x1840-0x185f irq 11 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf1204000-0xf12043ff irq 7 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf1204000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered ugen0: on uhub2 pci0: at device 27.0 (no driver attached) pcib1: irq 11 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 3 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf0e00000-0xf0efffff pcib1: no prefetched decode ACPI: Found matching pin for 2.0.INTA at func 0: 5 pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x4229, revid=0x61 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf0e00000, size 13, enabled pcib1: requested memory range 0xf0e00000-0xf0e01fff: good pcib1: matched entry for 2.0.INTA (src \\_SB_.PCI0.LPCB.LNKA:0) pcib1: slot 0 INTA routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA pci2: at device 0.0 (no driver attached) pcib2: irq 5 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 4 pcib2: subordinate bus 5 pcib2: I/O decode 0x2000-0x2fff pcib2: memory decode 0xf0600000-0xf07fffff pcib2: prefetched decode 0xf0000000-0xf01fffff pci4: on pcib2 pci4: domain=0, physical bus=4 pcib3: irq 7 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 6 pcib3: subordinate bus 7 pcib3: I/O decode 0x3000-0x3fff pcib3: memory decode 0xf0800000-0xf09fffff pcib3: prefetched decode 0xf0200000-0xf03fffff pci6: on pcib3 pci6: domain=0, physical bus=6 pcib4: irq 9 at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 8 pcib4: subordinate bus 9 pcib4: I/O decode 0x4000-0x4fff pcib4: memory decode 0xf0a00000-0xf0bfffff pcib4: prefetched decode 0xf0400000-0xf05fffff ACPI: Found matching pin for 8.0.INTA at func 0: 10 pci_link3: BIOS IRQ 10 for 8.0.INTA is invalid pci8: on pcib4 pci8: domain=0, physical bus=8 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib4: requested I/O range 0x4000-0x40ff: in range map[18]: type Memory, range 64, base 0xf0a00000, size 12, enabled pcib4: requested memory range 0xf0a00000-0xf0a00fff: good pcib4: matched entry for 8.0.INTA (src \\_SB_.PCI0.LPCB.LNKD:0) pcib4: slot 0 INTA routed to irq 9 via \\_SB_.PCI0.LPCB.LNKD re0: port 0x4000-0x40ff mem 0xf0a00000-0xf0a00fff irq 9 at device 0.0 on pci8 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf0a00000 re0: MSI count : 2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:90:f5:6e:05:32 re0: [MPSAFE] re0: [FILTER] pcib5: irq 11 at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0xf000-0xfff pcib5: no prefetched decode pci10: on pcib5 pci10: domain=0, physical bus=10 pcib6: irq 5 at device 28.5 on pci0 pcib6: domain 0 pcib6: secondary bus 11 pcib6: subordinate bus 11 pcib6: I/O decode 0xf000-0xfff pcib6: no prefetched decode pci11: on pcib6 pci11: domain=0, physical bus=11 uhci2: port 0x1860-0x187f irq 11 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 9 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 7 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xf1204400-0xf12047ff irq 11 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf1204400 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered umass0: on uhub6 umass0:0:0:-1: Attached to scbus0 pcib7: at device 30.0 on pci0 pcib7: domain 0 pcib7: secondary bus 12 pcib7: subordinate bus 12 pcib7: I/O decode 0x5000-0x5fff pcib7: memory decode 0xf0f00000-0xf0ffffff pcib7: no prefetched decode pcib7: Subtractively decoded bridge. ACPI: Found matching pin for 12.7.INTA at func 0: 5 ACPI: Found matching pin for 12.9.INTA at func 0: 10 pci_link3: BIOS IRQ 10 for 12.9.INTA is invalid pci12: on pcib7 pci12: domain=0, physical bus=12 found-> vendor=0x1524, dev=0x0730, revid=0x00 domain=0, bus=12, slot=7, func=0 class=05-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x04 (1000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00000, size 7, enabled pcib7: requested memory range 0xf0f00000-0xf0f0007f: good pcib7: matched entry for 12.7.INTA (src \\_SB_.PCI0.LPCB.LNKA:0) pcib7: slot 7 INTA routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x1524, dev=0x0750, revid=0x00 domain=0, bus=12, slot=7, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00400, size 8, enabled pcib7: requested memory range 0xf0f00400-0xf0f004ff: good pcib7: matched entry for 12.7.INTA (src \\_SB_.PCI0.LPCB.LNKA:0) pcib7: slot 7 INTA routed to irq 5 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x1524, dev=0x0751, revid=0x00 domain=0, bus=12, slot=7, func=3 class=05-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 8, memory disabled found-> vendor=0x1106, dev=0x3044, revid=0xc0 domain=0, bus=12, slot=9, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=10 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0f00800, size 11, enabled pcib7: requested memory range 0xf0f00800-0xf0f00fff: good map[14]: type I/O Port, range 32, base 0x5000, size 7, enabled pcib7: requested I/O range 0x5000-0x507f: in range pcib7: matched entry for 12.9.INTA (src \\_SB_.PCI0.LPCB.LNKD:0) pcib7: slot 9 INTA routed to irq 9 via \\_SB_.PCI0.LPCB.LNKD pci12: at device 7.0 (no driver attached) pci12: at device 7.1 (no driver attached) pci12: at device 7.3 (no driver attached) fwohci0: port 0x5000-0x507f mem 0xf0f00800-0xf0f00fff irq 9 at device 9.0 on pci12 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xf0f00800 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:43:35 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d46c000 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:00:43:35 fwe0: bpf attached fwe0: Ethernet address: 02:00:00:00:43:35 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:00:00:00:00:00:43:35 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18e0-0x18ef,0x18d0-0x18df at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x18e0 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 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=01 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=10 stat1=01 devices=0x10000 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) cpu0: on acpi0 ACPI: SSDT @ 0x0x7f6d4e01/0x02A8 (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f6d48d2/0x04AA (v 1 PmRef Cpu0Cst 0x00003001 INTL 0x20050624) est0: on cpu0 p4tcc0: on cpu0 battery0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) 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, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 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 0xcf000-0xcffff,0xe0000-0xe17ff 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: 0xe01 0xe01 0xe01 0xe01 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: 0xe01 0xe01 0xe01 0xe01 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 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xe01 0xe01 0xe01 0xe01 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) isa_probe_children: probing PnP devices ums0: on uhub3 ums0: 16 buttons and Z dir. uhid0: on uhub3 ugen1: on uhub5 Device configuration finished. Reducing kern.maxvnodes 133914 -> 100000 procfs registered Timecounter "TSC" frequency 2094763555 Hz quality 800 Timecounters tick every 1.000 msec pflog0: bpf attached pfsync0: bpf attached lo0: bpf attachedfirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ata0: identify ch->devices=00000001 battery0: battery initialization start acpi_acad0: acline initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire atapicam: atapicam0 already exists; skipping it ad0: 238475MB at ata0-master UDMA33 ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue ata1: identify ch->devices=00010000 GEOM: new disk ad0 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire battery0: battery initialization done, tried 1 times acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 172KB/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 acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM_LABEL: Label for provider ad0s1a is ufs/GKEROOT. GEOM_LABEL: Label for provider ad0s1e is ufs/GKERHOME. 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): error 6 (probe0:ata1:0:0:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe2:sbp0:0:0:0): error 22 (probe2:sbp0:0:0:0): Unretryable Error (probe8:sbp0:0:6:0): error 22 (probe8:sbp0:0:6:0): Unretryable Error (probe3:sbp0:0:1:0): error 22 (probe3:sbp0:0:1:0): Unretryable Error (probe4:sbp0:0:2:0): error 22 (probe4:sbp0:0:2:0): Unretryable Error (probe5:sbp0:0:3:0): error 22 (probe5:sbp0:0:3:0): Unretryable Error (probe6:sbp0:0:4:0): error 22 (probe6:sbp0:0:4:0): Unretryable Error (probe7:sbp0:0:5:0): error 22 (probe7:sbp0:0:5:0): Unretryable Error pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-0 device pass0: 40.000MB/s transfers pass1 at ata1 bus 0 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 33.000MB/s transfers GEOM: new disk da0 WARNING: WITNESS option enabled, expect reduced performance. da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) (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 - tray closed GEOM: new disk cd0 (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 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error lock order reversal: (sleepable after non-sleepable) 1st 0xc50c301c struct mount mtx (struct mount mtx) @ /home/build/src/sys/kern/vfs_subr.c:343 2nd 0xc50c3000 vfslock (vfslock) @ /home/build/src/sys/kern/vfs_subr.c:370 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a7fb64,c061992e,c08ce22a,c50c3000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,c50c3000,c08d4159,c08d4159,c08d46fe,...) at kdb_backtrace+0x29 witness_checkorder(c50c3000,1,c08d46fe,172,c097cff4,...) at witness_checkorder+0x6de __lockmgr_args(c50c3000,200100,c50c301c,0,0,...) at __lockmgr_args+0x230 vfs_busy(c50c3000,200,0,c4c99d20,1,...) at vfs_busy+0x1bc vfs_mount_alloc(0,c09149e0,c08d44a4,c4c99d20,c06574c0,...) at vfs_mount_alloc+0x78 vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x26c start_init(0,c4a7fd38,c08c4c0f,322,c4c97d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a7fd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a7fd70, ebp = 0 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc4f1ce10 vnode interlock (vnode interlock) @ /home/build/src/sys/fs/devfs/devfs_vnops.c:288 2nd 0xc4f1cdf4 devfs (devfs) @ /home/build/src/sys/kern/vfs_subr.c:2044 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a7fa8c,c061992e,c08ce22a,c4f1cdf4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,c4f1cdf4,c08be913,c08be913,c08d46fe,...) at kdb_backtrace+0x29 witness_checkorder(c4f1cdf4,9,c08d46fe,7fc,c4f1cdf4,...) at witness_checkorder+0x6de __lockmgr_args(c4f1cdf4,80100,c4f1ce10,0,0,...) at __lockmgr_args+0x777 vop_stdlock(c4a7fb8c,c08bead7,c08c1e97,80100,c4f1cd9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0914ac0,c4a7fb8c,c0951ea0,c4f1cd9c,80100,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4f1cd9c,80100,c08d46fe,7fc,c08bead7,...) at _vn_lock+0x5e vget(c4f1cd9c,80100,c4c99d20,121,c08bea6d,...) at vget+0x9c devfs_allocv(c50a7480,c50c3000,c4a7fc20,c4c99d20,c4c99dc4,...) at devfs_allocv+0x11a devfs_root(c50c3000,80000,c09c4db4,c4c99d20,4,...) at devfs_root+0x51 set_rootvnode(c09c4da0,0,c08d4054,5f1,c06574c0,...) at set_rootvnode+0x2d vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x34c start_init(0,c4a7fd38,c08c4c0f,322,c4c97d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a7fd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a7fd70, ebp = 0 --- Trying to mount root from ufs:/dev/ad0s1a ct_to_ts([2008-07-17 06:04:43]) = 1216274683.000000000 lock order reversal: (sleepable after non-sleepable) 1st 0xc4f1cb20 bufobj interlock (bufobj interlock) @ /home/build/src/sys/kern/vfs_bio.c:2442 2nd 0xd8ce5c80 bufwait (bufwait) @ /home/build/src/sys/kern/vfs_bio.c:2456 KDB: stack backtrace: db_trace_self_wrapper(c08cb92a,c4a7f784,c061992e,c08ce22a,d8ce5c80,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ce22a,d8ce5c80,c08d2fec,c08d2fec,c08d2594,...) at kdb_backtrace+0x29 witness_checkorder(d8ce5c80,9,c08d2594,998,c097cff4,...) at witness_checkorder+0x6de __lockmgr_args(d8ce5c80,81900,c4f1cb20,c08d2f48,50,...) at __lockmgr_args+0x777 getblk(c4f1ca78,0,0,800,0,...) at getblk+0x153 breadn(c4f1ca78,0,0,800,0,...) at breadn+0x44 bread(c4f1ca78,0,0,800,0,...) at bread+0x4c ffs_blkatoff(c4f1ca78,0,0,0,c4a7f9a4,...) at ffs_blkatoff+0xd1 ufs_lookup(c4a7f9e8,c4f1ca78,c4a7fb38,c4f1ca78,c4a7fa08,...) at ufs_lookup+0x2e6 VOP_CACHEDLOOKUP_APV(c093b4c0,c4a7f9e8,c4a7fb38,c4a7fb24,c4c69300,...) at VOP_CACHEDLOOKUP_APV+0xa5 vfs_cache_lookup(c4a7fa68,c4a7fa68,500000c,80000,c4f1ca78,...) at vfs_cache_lookup+0xd0 VOP_LOOKUP_APV(c093b4c0,c4a7fa68,c08d3dfb,1b0,c4a7fb24,...) at VOP_LOOKUP_APV+0xa5 lookup(c4a7fb0c,c08d3dfb,d8,c0,c4c6942c,...) at lookup+0x57e namei(c4a7fb0c,c4a7fb24,c061910c,c08d4159,c08d44a0,...) at namei+0x44b kern_unlinkat(c4c99d20,ffffff9c,c08d44a0,1,c4a7fc5c,...) at kern_unlinkat+0x46 kern_unlink(c4c99d20,c08d44a0,1,62c,0,...) at kern_unlink+0x27 vfs_mountroot_try(c08d465a,c08c1e99,c08bc8a9,1,c06574c0,...) at vfs_mountroot_try+0x482 vfs_mountroot(c0970130,4,c08c3243,264,0,...) at vfs_mountroot+0x40e start_init(0,c4a7fd38,c08c4c0f,322,c4c97d0c,...) at start_init+0x65 fork_exit(c05a16c0,0,c4a7fd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a7fd70, ebp = 0 --- start_init: trying /sbin/init GEOM_LABEL: Label ufs/GKEROOT removed. GEOM_LABEL: Label for provider ad0s1a is ufs/GKEROOT. GEOM_LABEL: Label ufs/GKERHOME removed. GEOM_LABEL: Label for provider ad0s1e is ufs/GKERHOME. GEOM_LABEL: Label ufs/GKEROOT removed. --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 16:38:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB1F1065681 for ; Fri, 18 Jul 2008 16:38:18 +0000 (UTC) (envelope-from mvolaski@aecom.yu.edu) Received: from mx1.aecom.yu.edu (mx1.aecom.yu.edu [129.98.1.51]) by mx1.freebsd.org (Postfix) with ESMTP id E6EC98FC0C for ; Fri, 18 Jul 2008 16:38:17 +0000 (UTC) (envelope-from mvolaski@aecom.yu.edu) Received: from draco.aecom.yu.edu (draco.aecom.yu.edu [129.98.1.160]) by mx1.aecom.yu.edu (Postfix) with ESMTP id 70E689F00E0; Fri, 18 Jul 2008 12:06:46 -0400 (EDT) X-AuditID: 816201a0-ab8c9bb0000015ac-f8-4880bf961803 Received: from smtp1.aecom.yu.edu (smtp1.aecom.yu.edu [129.98.1.61]) by draco.aecom.yu.edu (Symantec Mail Security) with ESMTP id 06B83718002; Fri, 18 Jul 2008 12:06:46 -0400 (EDT) Received: from [129.98.90.227] (usseinstein.aecom.yu.edu [129.98.90.227]) by smtp1.aecom.yu.edu (Postfix) with ESMTP id B30AFB6CD; Fri, 18 Jul 2008 12:06:45 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Fri, 18 Jul 2008 12:06:15 -0400 To: freebsd-current@freebsd.org From: Maurice Volaski Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: pjd@FreeBSD.org Subject: Would ZFS and gmirror work well together in a two-node failover cluster? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 16:38:18 -0000 I am looking to put together a two-node high-availability cluster where each node has identical data storage consisting of a set of internal data drives (separate from the boot drive). I want ZFS to manage the drives as a JDBOD in a RAIDZ2 configuration. Thus, if an individual drive misbehaves or fails, ZFS detects and handles the fault. But I'm also looking to mirror this entire setup in real time to a second identical server. Basically, my question is can this work well on FreeBSD while taking full advantage of ZFS? Specifically, my understanding is that the only way to handle the real time mirror is with gmirror and ggated, but it's not clear how gmirror would interact with ZFS. I am assuming that gmirror operates only on individual drives, so if I had a set of 24 drives on each server, there would be 24 mirrored drive pairs. One concern I have is that this setup could run into trouble with gmirror's potentially sabotaging ZFS's RAIDZ2. For example, when a drive starts failing, won't gmirror see it before ZFS does and take the unfavorable action of substituting the corresponding drive in the failover server in subsequent I/O, leaving ZFS's RAIDZ2 out of the loop? This is just one particular scenario, but in general, it's not entirely clear that it's possible to have fine-grained control of when, how much and in what direction gmirror manages synchronization among drive pairs. -Maurice -- Maurice Volaski, mvolaski@aecom.yu.edu Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 17:00:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A9B81065672 for ; Fri, 18 Jul 2008 17:00:39 +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 6D0258FC27 for ; Fri, 18 Jul 2008 17:00:38 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl13-149.kln.forthnet.gr [77.49.140.149]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6IH0Mcx008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Jul 2008 20:00:28 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6IH0MIK003007 for ; Fri, 18 Jul 2008 20:00:22 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6IH0LJr003006; Fri, 18 Jul 2008 20:00:21 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: freebsd-current@freebsd.org References: <87prpcjrsk.fsf@kobe.laptop> Date: Fri, 18 Jul 2008 20:00:21 +0300 In-Reply-To: <87prpcjrsk.fsf@kobe.laptop> (Giorgos Keramidas's message of "Thu, 17 Jul 2008 21:20:59 +0300") Message-ID: <87k5fj86vu.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6IH0Mcx008663 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.778, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.62, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 17:00:39 -0000 On Thu, 17 Jul 2008 21:20:59 +0300, Giorgos Keramidas wrote: > Attached are the two dmesg files with and without the APIC. Any ideas > if this is a bug in FreeBSD or a completely bogus APIC? I managed to append two dmesg outputs inline, which may be confusing. If you try to parse the 1700+ line inline attachments below, look for 'Copyright '. The dmesg output which contains: > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. is the dmesg output with apic.0.disabled="1". From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 17:52:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFB61065676 for ; Fri, 18 Jul 2008 17:52:43 +0000 (UTC) (envelope-from jonathan@onegoodidea.com) Received: from mailhost.significant-whitespace.com (mailhost.significant-whitespace.com [217.155.157.131]) by mx1.freebsd.org (Postfix) with ESMTP id A6D3F8FC18 for ; Fri, 18 Jul 2008 17:52:43 +0000 (UTC) (envelope-from jonathan@onegoodidea.com) Received: from [10.0.1.199] (wifi.significant-whitespace.com [217.155.157.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.significant-whitespace.com (Postfix) with ESMTP id 808B87FC1F6; Fri, 18 Jul 2008 18:35:53 +0100 (BST) Message-Id: From: Jonathan Hogg To: Maurice Volaski In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 18 Jul 2008 18:35:52 +0100 References: X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org Subject: Re: Would ZFS and gmirror work well together in a two-node failover cluster? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 17:52:44 -0000 On 18 Jul 2008, at 17:06, Maurice Volaski wrote: > I am looking to put together a two-node high-availability cluster > where each node has identical data storage consisting of a set of > internal data drives (separate from the boot drive). I want ZFS to > manage the drives as a JDBOD in a RAIDZ2 configuration. Thus, if an > individual drive misbehaves or fails, ZFS detects and handles the > fault. > > But I'm also looking to mirror this entire setup in real time to a > second identical server. > > Basically, my question is can this work well on FreeBSD while taking > full advantage of ZFS? Have you considered ZFS snapshots and send/receive? This would allow you to maintain a consistent (from ZFS' perspective) replica in near real-time (depending on how frequently the snapshots are taken). If you can afford to lose a small window of data then this would seem the ideal solution and possibly more efficient as the synchronisation of the backup system would occur out-of-line with writing to the main system. This would allow bursts of full-speed writing to the main array followed by a more leisurely synchronisation to the backup. (Apologies if you have already considered and dismissed this option.) Jonathan From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 18:17:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DAD81065681; Fri, 18 Jul 2008 18:17:26 +0000 (UTC) (envelope-from mvolaski@aecom.yu.edu) Received: from mx1.aecom.yu.edu (mx1.aecom.yu.edu [129.98.1.51]) by mx1.freebsd.org (Postfix) with ESMTP id 489CD8FC19; Fri, 18 Jul 2008 18:17:26 +0000 (UTC) (envelope-from mvolaski@aecom.yu.edu) Received: from draco.aecom.yu.edu (draco.aecom.yu.edu [129.98.1.160]) by mx1.aecom.yu.edu (Postfix) with ESMTP id D49EE9F013A; Fri, 18 Jul 2008 14:17:25 -0400 (EDT) X-AuditID: 816201a0-a629cbb0000015ac-48-4880de35839c Received: from smtp2.aecom.yu.edu (smtp2.aecom.yu.edu [129.98.1.62]) by draco.aecom.yu.edu (Symantec Mail Security) with ESMTP id 5D65F718002; Fri, 18 Jul 2008 14:17:25 -0400 (EDT) Received: from [129.98.90.227] (usseinstein.aecom.yu.edu [129.98.90.227]) by smtp2.aecom.yu.edu (Postfix) with ESMTP id 3170DB714; Fri, 18 Jul 2008 14:17:25 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 18 Jul 2008 14:16:55 -0400 To: Jonathan Hogg From: Maurice Volaski Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org Subject: Re: Would ZFS and gmirror work well together in a two-node failover cluster? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 18:17:26 -0000 >Have you considered ZFS snapshots and send/receive? This would allow >you to maintain a consistent (from ZFS' perspective) replica in near >real-time (depending on how frequently the snapshots are taken). Thanks for your suggestion. I'm not sure how that would work in practice either, but is potentially interesting to consider. For one thing, how small can small window of data be, something measured in minutes or hours? And this would be a system that could be moving 100 MB+ per second, so the data could get outdated quickly. Plus, I'm looking for the failover to be automatic and near instantaneous. That is, if I pull the power cord on the primary, could the secondary go hot in under a minute? That's the way it works with heartbeat and DRBD on Linux. Solaris on x86 has a mechanism very similar to DRBD called AVS, although it's only a little more complex, it's Solaris itself that is so different (and perhaps more complex) than Linux that I was thinking FreeBSD might be an alternative. -- Maurice Volaski, mvolaski@aecom.yu.edu Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 18:58:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04D81106566B for ; Fri, 18 Jul 2008 18:58:28 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id D5A898FC14 for ; Fri, 18 Jul 2008 18:58:27 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 57DBB79E30A for ; Fri, 18 Jul 2008 13:28:04 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 77944-02 for ; Fri, 18 Jul 2008 18:28:04 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id CC2AF79E26A for ; Fri, 18 Jul 2008 13:28:03 -0500 (CDT) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m6IIRx0U045727 for ; Fri, 18 Jul 2008 13:27:59 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <4880E0AD.7020508@shrew.net> Date: Fri, 18 Jul 2008 13:27:57 -0500 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Jul 2008 19:14:04 +0000 Subject: panic on tap device close ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 18:58:28 -0000 All, I have seen this panic twice today with the kernel sources being just a few days old. The kdb output is in the form of a screen shot which was the best I could do at the time ... http://hole.shrew.net/~mgrooms/files/tap-crash.jpg This occurred doing some tests with the following code. It just creates a tap device, configures it with an address/netmask/mtu and holds the file descriptor open until is pressed. I ran it in one terminal and started fiddling with ifconfig and netstat in another terminal. The panic happens eventually when the taptest program exits ... http://hole.shrew.net/~mgrooms/files/taptest.cpp Thanks, -Matthew From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 20:09:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E99E71065694; Fri, 18 Jul 2008 20:09:47 +0000 (UTC) (envelope-from jonathan@onegoodidea.com) Received: from mailhost.significant-whitespace.com (mailhost.significant-whitespace.com [217.155.157.131]) by mx1.freebsd.org (Postfix) with ESMTP id A3C8E8FC1E; Fri, 18 Jul 2008 20:09:47 +0000 (UTC) (envelope-from jonathan@onegoodidea.com) Received: from [10.0.1.199] (wifi.significant-whitespace.com [217.155.157.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.significant-whitespace.com (Postfix) with ESMTP id 6D0E87FC1F6; Fri, 18 Jul 2008 21:09:46 +0100 (BST) Message-Id: <439EEA62-06C6-4FF9-8848-2558574E6A75@onegoodidea.com> From: Jonathan Hogg To: Maurice Volaski In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 18 Jul 2008 21:09:45 +0100 References: X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org Subject: Re: Would ZFS and gmirror work well together in a two-node failover cluster? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2008 20:09:48 -0000 On 18 Jul 2008, at 19:16, Maurice Volaski wrote: > For one thing, how small can small window of data be, something > measured in minutes or hours? And this would be a system that could > be moving 100 MB+ per second, so the data could get outdated quickly. As I understand it (although I've not attempted this myself) there's no reason not to take snapshots at minute intervals or less - snapshots are pretty low cost. How far behind it gets depends on how much data you write to the main system and how fast you can sync it to the backup. The rough principal is that you take an initial snapshot and send/ receive that to the backup system. Then you take a second snapshot and send a "diff" stream to the backup. Then you can drop the initial snapshot and take a third and do the same. You drop the second, take a fourth, etc., etc. You have to avoid there being too many existent snapshots as the utilities become very slow when you have a lot. If you have a couple of spare machines, I'd give it a whirl and get some feeling for how well it works. > Plus, I'm looking for the failover to be automatic and near > instantaneous. That is, if I pull the power cord on the primary, > could the secondary go hot in under a minute? The ZFS filesystem(s) on the backup machine would be live at all times. You can even immediately start writing to them - though at that point you can't receive any more snapshots to the backup obviously. Failover of whatever systems were on top of these would be another question. Presumably this is a file server or something? Are you going to failover the IP address(es)? Jonathan From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 23:27:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34ABA1065677 for ; Fri, 18 Jul 2008 23:27:06 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 219E08FC1C for ; Fri, 18 Jul 2008 23:27:06 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so617008rvf.43 for ; Fri, 18 Jul 2008 16:27:05 -0700 (PDT) Received: by 10.141.170.9 with SMTP id x9mr396536rvo.90.1216423625880; Fri, 18 Jul 2008 16:27:05 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Fri, 18 Jul 2008 16:27:05 -0700 (PDT) Message-ID: <919383240807181627y6b198e5bx160af1df9229181@mail.gmail.com> Date: Fri, 18 Jul 2008 19:27:05 -0400 From: "Edward Ruggeri" To: "Robert Watson" In-Reply-To: <20080718121102.D69806@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <20080718121102.D69806@fledge.watson.org> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 23:27:06 -0000 On Fri, Jul 18, 2008 at 7:25 PM, Edward Ruggeri wrote: > On Fri, Jul 18, 2008 at 7:13 AM, Robert Watson wrote: >> This is a NULL pointer dereference in the kernel, which almost certainly >> means a kernel bug. Per e-mail you've already received from Garrett Cooper, >> we need some further debugging information, such as a kernel astack trace. >> If you're unable to get a dump, a DDB stack trace would probably help quite >> a bit (options DDB, when it drops into the debugger, save the results of the >> command "trace"). Please do a file a PR with those results. > > Will do. I'll recompile the kernel tonight with the options Garrett's > recommended, get a trace, and file a PR. Thanks! > >> I'm a bit puzzled that your box is syncing after a panic -- normally the >> kernel is configured not to do that -- could kern.sync_on_panic be set in >> your loader.conf or sysctl.conf? > > Ah, I wondered if it was supposed to do that. There's nothing in > /etc/sysctl.conf, and only nvidia_load="YES" in /boot/loader.conf. I > ran sysctl -a subsequently, and it indicates that kern.sync_on_panic > is (currently) zero. I sent this to Robert Watson only, by mistake. My apologies for sending this twice to you now, Robert. Thank you very much for your help! -- Ned Ruggeri From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 00:29:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 926F5106566C for ; Sat, 19 Jul 2008 00:29:16 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1F78FC0A for ; Sat, 19 Jul 2008 00:29:16 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so638360rvf.43 for ; Fri, 18 Jul 2008 17:29:16 -0700 (PDT) Received: by 10.141.161.6 with SMTP id n6mr420982rvo.41.1216427355998; Fri, 18 Jul 2008 17:29:15 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Fri, 18 Jul 2008 17:29:15 -0700 (PDT) Message-ID: <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> Date: Fri, 18 Jul 2008 20:29:15 -0400 From: "Edward Ruggeri" To: "Garrett Cooper" In-Reply-To: <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 00:29:16 -0000 On Fri, Jul 18, 2008 at 6:36 AM, Garrett Cooper wrote: > Some notes: > > 1. *blinks*... I hope you mean 8-CURRENT, not 7-CURRENT. 7 hasn't been > CURRENT for some months now (~6 months IIRC). Oh my, I am an idiot. I'm using 7-STABLE, making this the wrong list to ask; sorry. I guess I could repost to freebsd-stable in addition to filing a PR. Would that be wise? > 2. pciconf -lv might help with the PCI ID info. Then someone might be > able to tie your card back to the appropriate chipset. This gives me: ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet class = base peripheral I get 167 pages on google that contain ar5212 and 0x1014168c and 0x058a1014. I only get one with ar5006ex instead of ar5212. I'm inclined to believe my Lenovo representative was wrong; she's just a sales rep and asked around about the part... > 3. KDB, DDB, WITNESS and INVARIANTS support compiled into the kernel > would be extremely helpful, if not required to debug your issue. I'm currently recompiling the kernel with these debug options: makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB options DDB options INVARIANTS options WITNESS As soon as it's done compiling, I'll try reproducing the error. I've added "set dumpdev="/var/crash" in /etc/rc.conf. > As for the actual debug process, there's a spot in the dev handbook > about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html), > but when I tried debugging my issue with NTFS and SMB I didn't really > find it helpful to be honest... Once I have a core dump, how should I proceed? Use kdb, and execute "list *[instruction pointer]" to find out what (NULL) pointer is being dereferenced? Run backtrace? If I post a PR, is it likely that someone can guide me through this? I'm fairly familiar with C, but my experience using debuggers is very limited... > You may also have to compile without SMP and with the 4BSD scheduler > just to see whether or not it's an issue reproducible with the ULE > scheduler, the driver, or something else... After I get the dump with the current options (+ debug options), I'll try w/o SMP and ULE... > Hopefully this gets you started on the right path... > -Garrett Thanks so much, Garrett! From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 05:01:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7DEC1065671 for ; Sat, 19 Jul 2008 05:01:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFFF8FC08 for ; Sat, 19 Jul 2008 05:01:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 27239 invoked by uid 399); 19 Jul 2008 05:01:39 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jul 2008 05:01:39 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48817532.4060704@FreeBSD.org> Date: Fri, 18 Jul 2008 22:01:38 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Stefan Bethke References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <525E8FF6-307E-4DC9-B730-21435A2C2D2C@lassitu.de> In-Reply-To: <525E8FF6-307E-4DC9-B730-21435A2C2D2C@lassitu.de> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, lth@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 05:01:41 -0000 Stefan Bethke wrote: > Just as a simple counter-example: it's very annoying when a startup > script for a non-essential service is blocking startup for an essential > one. (A Smokeping config of mine takes about 5 minutes to finish, and > it's blocking sshd, as I found out the other day when I had to reboot > the server.) I took at look at that rc.d script, and it seems to have duplicated the same old script that a lot of ports scripts did before they were included in the base rcorder (so the before/require stuff didn't matter). Specifically it has: # REQUIRE: DAEMON # BEFORE: LOGIN where it probably should just have REQUIRE: LOGIN. That would generally place it after sshd (although obviously it would miss some traffic that happens before it's started up). Of course, you can always change the order yourself (e.g., add sshd to the REQUIRE line), and/or investigate a way to get smokeping to do its startup process in the background and yield to the next script in line. I've cc'ed lth so that hopefully he can give this stuff some thought. > Also see the repeated annoyances caused by dhclient on this > list and elsewhere. Well, two groups of categories that I think would be useful are "depends on the network" and "does not depend on the network" which would help deal with the delay you're talking about here. The problems with that ensue when you start talking about NFS-mounted /usr/local, diskless boot, etc. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 05:19:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 725DC1065670 for ; Sat, 19 Jul 2008 05:19:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 176EA8FC1C for ; Sat, 19 Jul 2008 05:19:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 14502 invoked by uid 399); 19 Jul 2008 05:19:24 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jul 2008 05:19:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4881795A.4070604@FreeBSD.org> Date: Fri, 18 Jul 2008 22:19:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: ticso@cicely.de References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> In-Reply-To: <20080718122928.GD35340@cicely7.cicely.de> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 05:19:25 -0000 Bernd Walter wrote: > Speaking about small systems, where startup time is more a problem than > on 08/15 desktop and server systems. > What I would love to see is that scripts like moused, ypserv, lpt, etc > are not started if the services are disabled. That wold be a neat trick, how do you propose we accomplish it? (no, I'm not being snide.) There are 144 scripts in /etc/rc.d/ on HEAD right now. Out of those I count roughly 40 that I actually need, so let's round off to 100 unnecessary scripts to make the math easy. On my system (a pretty fast C2D) it takes roughly .3 seconds of wall clock time to run one script that is not enabled. Now cut that roughly in half since each of those scripts will not have to suck in /etc/rc.subr and /etc/rc.conf* when run at boot time, and that's 15 seconds of boot time that I could save on average, let's say +/- 5 seconds. That's worth giving some thought to. One way you could do this is to have /etc/rc.d/active and /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical stuff that most people shouldn't touch). Then you could have a vipw-like system to allow users to edit rc.conf that would move the scripts to the right directory. Of course, this would be fraught with potential for problems. :) Another thing that would work for systems that a more sophisticated admin/user updates with mergemaster would be to write a pre-compare script that removes all the scripts you know you don't need from the temproot/etc/rc.d so that they don't get installed. Of course the benefit of that would not be nearly as wide spread, but it would also not result in so much foot-shooting. > So far each script is started, sucks in routines plus rc.conf We're actually a little smarter than that. :) rc.subr and rc.conf[.local] are loaded once by rc, then each script that runs inherits those values. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 05:24:07 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D90106566B for ; Sat, 19 Jul 2008 05:24:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id F26818FC1B for ; Sat, 19 Jul 2008 05:24:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19666 invoked by uid 399); 19 Jul 2008 05:24:06 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jul 2008 05:24:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48817A75.7080206@FreeBSD.org> Date: Fri, 18 Jul 2008 22:24:05 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Alexander Leidinger References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> In-Reply-To: <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 05:24:07 -0000 Alexander Leidinger wrote: > Quoting Doug Barton (from Thu, 17 Jul 2008 > 15:41:13 -0700): > >>> The main reason for this work was to increase start-up time (on >>> the userland side) by running as many scripts concurrently as >>> possible. >> >> How are you running the scripts concurrently, and the key >> question, have you actually benchmarked your changes to >> demonstrate that they result in statistically significant >> changes. > > Are you aware that the parallel starting in Solaris 10 reduced the > booting time by a nice percentage? If I say yes, do I get a cookie? > If yes, do you expect that FreeBSD behaves significantly different > or do you "just" want to see numbers? Don't rule out "all of the above." :) More to the point: 1. I'm pretty familiar with how the current system works, and I also know that we've already plucked all the low hanging fruit. 2. I know that the existing system is not exactly what I'd call "fragile," but it's not exactly what I'd call "bulletproof" either, and therefore anything that proposes to change it dramatically needs to have a serious cost/benefit analysis performed before we go down that road. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 07:01:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A85106564A for ; Sat, 19 Jul 2008 07:01:24 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9FD8FC08 for ; Sat, 19 Jul 2008 07:01:24 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so741646rvf.43 for ; Sat, 19 Jul 2008 00:01:24 -0700 (PDT) Received: by 10.141.79.12 with SMTP id g12mr559097rvl.126.1216449131893; Fri, 18 Jul 2008 23:32:11 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id f21sm3326031rvb.0.2008.07.18.23.32.09 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 23:32:10 -0700 (PDT) Date: Fri, 18 Jul 2008 20:31:55 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Steve Kargl In-Reply-To: <20080717182924.GA417@troutmask.apl.washington.edu> Message-ID: <20080718202730.W954@desktop> References: <20080716211317.GA92354@troutmask.apl.washington.edu> <452221.38826.qm@web63902.mail.re1.yahoo.com> <20080717182924.GA417@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Barney Cordoba , current@freebsd.org Subject: Re: ULE scheduling oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 07:01:25 -0000 On Thu, 17 Jul 2008, Steve Kargl wrote: > On Thu, Jul 17, 2008 at 09:12:45AM -0700, Barney Cordoba wrote: >> >>> Actually, 10 copies of the little app are the only things >>> running except >>> top(1) and few sleeping system services (e.g., nfsd and >>> sshd). Apparently, >>> you missed the "41 processes: 11 running, 30 >>> sleeping" line above. >>> >> >> Your apparent argument that somehow every cpu cycle can be >> sliced equally and automagically is as silly > > I do not expect a single cpu cycle to be split evenly > between the running processes. I do however expect that > 8e12 cpu cycles to be split in a better distribution. > >> as the expectation that a first generation scheduler will >> exhibit 100% efficiency across 8 cpus. > > ULE in -current is no longer 1st generation. I tested the > original ULE when jeffr committed and reported a few panics > and provided some of the first feedback of interactivity > problems. > > Perhaps, I should have sent my original email directly to > jeffr instead of the freebsd-current list where others > might find the observation of interest. If one expects to > see future improvements in ULE, then providing feedback > is crucial. Apparently, you have a different opinion. Hey Steve, Thanks again for providing valuable feedback. The new cpu topology aware load balancing could've disturbed the ever delicate balancing algorithm. Do you know if this is better in 7.0 than current? I know at one time I had examined this very workload. Can you try increasing the balance frequency? (lessening the interval value in sysctl) I haven't been reading current much lately, I must confess. Please contact me directly if I don't respond here in a timely fashion. Thanks! Jeff > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 07:55:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48C8E106566B; Sat, 19 Jul 2008 07:55:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id DB15B8FC12; Sat, 19 Jul 2008 07:55:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KK6uh-000Cdi-2L; Sat, 19 Jul 2008 10:31:31 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Doug Barton In-reply-to: <4881795A.4070604@FreeBSD.org> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> Comments: In-reply-to Doug Barton message dated "Fri, 18 Jul 2008 22:19:22 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 2008 10:31:31 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 07:55:17 -0000 > Bernd Walter wrote: > > Speaking about small systems, where startup time is more a problem than > > on 08/15 desktop and server systems. > > What I would love to see is that scripts like moused, ypserv, lpt, etc > > are not started if the services are disabled. > > That wold be a neat trick, how do you propose we accomplish it? (no, > I'm not being snide.) > > There are 144 scripts in /etc/rc.d/ on HEAD right now. Out of those I > count roughly 40 that I actually need, so let's round off to 100 > unnecessary scripts to make the math easy. On my system (a pretty fast > C2D) it takes roughly .3 seconds of wall clock time to run one script > that is not enabled. Now cut that roughly in half since each of those > scripts will not have to suck in /etc/rc.subr and /etc/rc.conf* when > run at boot time, and that's 15 seconds of boot time that I could save > on average, let's say +/- 5 seconds. That's worth giving some thought to. > what if rcorder could provide the list of only those scripts that have 'script_enable="yEs", thus reducing the number of execs? > One way you could do this is to have /etc/rc.d/active and > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical > stuff that most people shouldn't touch). Then you could have a > vipw-like system to allow users to edit rc.conf that would move the > scripts to the right directory. Of course, this would be fraught with > potential for problems. :) > > Another thing that would work for systems that a more sophisticated > admin/user updates with mergemaster would be to write a pre-compare > script that removes all the scripts you know you don't need from the > temproot/etc/rc.d so that they don't get installed. Of course the > benefit of that would not be nearly as wide spread, but it would also > not result in so much foot-shooting. > > > So far each script is started, sucks in routines plus rc.conf > > We're actually a little smarter than that. :) rc.subr and > rc.conf[.local] are loaded once by rc, then each script that runs > inherits those values. > > hth, > > Doug > > -- > > This .signature sanitized for your protection > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 13:19:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7454A1065672 for ; Sat, 19 Jul 2008 13:19:12 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 2149D8FC13 for ; Sat, 19 Jul 2008 13:19:11 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from [192.168.2.69] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m6JDJ1dE036272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 09:19:01 -0400 (EDT) (envelope-from rnoland@2hip.net) From: Robert Noland To: Doug Barton In-Reply-To: <4881795A.4070604@FreeBSD.org> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JDedLAgO1kyzS16oDn3h" Organization: 2Hip Networks Date: Sat, 19 Jul 2008 09:18:55 -0400 Message-Id: <1216473536.1991.5.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 13:19:12 -0000 --=-JDedLAgO1kyzS16oDn3h Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote: > Bernd Walter wrote: > > Speaking about small systems, where startup time is more a problem than > > on 08/15 desktop and server systems. > > What I would love to see is that scripts like moused, ypserv, lpt, etc > > are not started if the services are disabled. >=20 > That wold be a neat trick, how do you propose we accomplish it? (no,=20 > I'm not being snide.) >=20 > There are 144 scripts in /etc/rc.d/ on HEAD right now. Out of those I=20 > count roughly 40 that I actually need, so let's round off to 100=20 > unnecessary scripts to make the math easy. On my system (a pretty fast=20 > C2D) it takes roughly .3 seconds of wall clock time to run one script=20 > that is not enabled. Now cut that roughly in half since each of those=20 > scripts will not have to suck in /etc/rc.subr and /etc/rc.conf* when=20 > run at boot time, and that's 15 seconds of boot time that I could save=20 > on average, let's say +/- 5 seconds. That's worth giving some thought to. >=20 > One way you could do this is to have /etc/rc.d/active and=20 > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical=20 > stuff that most people shouldn't touch). Then you could have a=20 > vipw-like system to allow users to edit rc.conf that would move the=20 > scripts to the right directory. Of course, this would be fraught with=20 > potential for problems. :) I almost hate to toss this out there, but what about a sys v type rc? You could have the big directory where all of the scripts live, and then a directory where you symlink to all of the scripts that you actually need. Not exactly run levels, but... I'm also quite curious what happened to the project of porting launchd from osx. robert. > Another thing that would work for systems that a more sophisticated=20 > admin/user updates with mergemaster would be to write a pre-compare=20 > script that removes all the scripts you know you don't need from the=20 > temproot/etc/rc.d so that they don't get installed. Of course the=20 > benefit of that would not be nearly as wide spread, but it would also=20 > not result in so much foot-shooting. >=20 > > So far each script is started, sucks in routines plus rc.conf >=20 > We're actually a little smarter than that. :) rc.subr and=20 > rc.conf[.local] are loaded once by rc, then each script that runs=20 > inherits those values. >=20 > hth, >=20 > Doug >=20 --=-JDedLAgO1kyzS16oDn3h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkiB6b8ACgkQM4TrQ4qfRONNvwCeK3/Tp24wXFFoOwGDFqZUayaT IvgAn1grwGpSCDjo5bzu7JQjWYbAwYeM =AeC4 -----END PGP SIGNATURE----- --=-JDedLAgO1kyzS16oDn3h-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 15:27:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3031065672 for ; Sat, 19 Jul 2008 15:27:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id E3C248FC14 for ; Sat, 19 Jul 2008 15:27:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so448516fgb.35 for ; Sat, 19 Jul 2008 08:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=QR36NlU19ukYElUvimXpzfWtsq8chmvsKexR6SC8azw=; b=KGa3iBmLB1OpH90GL4cjhTfBeII7TlSGrvYSn9A/1F13KHCfRnzHLtZHoEjilqJhpO GZo77gdsebXu6k3KYNkZjZZZijCjHo9BYnAkOu6nGCbUulAU9QLi4/wTdfoj5ZoH/TWm QZXjA2kuELZoUQOFZY71Kby/VE5bZ0mHgbkCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=EI0G70GKafq1n23MrxIvRmJHxVKxlYXbBwUxLjdgOp3P4LLIZm0sOMqahwGVWHXMtD b/KxZ1hWJssbuvUtWoQQO74XoFQnlxLCHRXLUHS4tOS5Vw6VkWknlHuu7oknJkKuGf6k qySIiR+EY8YuSTsRXZ85MILnYoONmqk6K1EC0= Received: by 10.86.70.8 with SMTP id s8mr2116865fga.79.1216481236480; Sat, 19 Jul 2008 08:27:16 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sat, 19 Jul 2008 08:27:16 -0700 (PDT) Message-ID: <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> Date: Sat, 19 Jul 2008 17:27:16 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Lothar Braun" In-Reply-To: <4880921C.10700@lobraun.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> X-Google-Sender-Auth: e0f685470ae4cb51 Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 15:27:18 -0000 2008/7/18, Lothar Braun : > Hi, > > Kris Kennaway wrote: > > > > > > dmesg says: > > > > > > SGI XFS with large block numbers, tracing, no debug enabled > > > fsname '/dev/ad8s4' logname '' rtname '' > > > flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 > > > xfs_setsize_buftarg NI 0xc692d420 > > > XFS mounting filesystem /dev/ad8s4 > > > Ending clean XFS mount for filesystem: /dev/ad8s4 > > > xfs_iunpin: REC RECABLE ip 0xc6f89d38 > > > xfs_iunpin: REC RECABLE ip 0xc6f8a000 > > > xfs_iflush: ip 0xc6f89d38 i_ino 131 > > > > > > > > > I'll recompile the kernel with INVARIANTS and WITNESS enabled in order > to get more information about the problem. > > > > > > > And DEBUG_LOCKS and DEBUG_VFS_LOCKS please :) > > > > I now have > > makeoptions DEBUG=-g > options KDB # Enable kernel debugger support. > options KDB_UNATTENDED > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity > checking > options INVARIANT_SUPPORT # Extra sanity checks of internal > structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks > and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks > for speed > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > > enabled and got the following output in /var/log/messages: > > Jul 18 12:28:14 finch kernel: SGI XFS with large block numbers, tracing, no > debug enabled > Jul 18 12:28:14 finch kernel: fsname '/dev/ad8s4' logname '' rtname '' > Jul 18 12:28:14 finch kernel: flags 0x200000 sunit 0 swidth 0 logbufs -1 > logbufsize -1 > Jul 18 12:28:14 finch kernel: xfs_setsize_buftarg NI 0xc6773a60 > Jul 18 12:28:14 finch kernel: XFS mounting filesystem /dev/ad8s4 > Jul 18 12:28:15 finch kernel: Ending clean XFS mount for filesystem: > /dev/ad8s4 > Jul 18 12:28:20 finch kernel: lock order reversal: > Jul 18 12:28:20 finch kernel: 1st 0xc6dd95b8 xfs (xfs) @ > /usr/src/sys/kern/vfs_lookup.c:432 > Jul 18 12:28:20 finch kernel: 2nd 0xc6f9e090 xfsino (xfsino) @ > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_iget.c:881 > Jul 18 12:28:20 finch kernel: 3rd 0xc6fa1058 xfs (xfs) @ > /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_freebsd_iget.c:393 > Jul 18 12:28:20 finch kernel: KDB: stack backtrace: > Jul 18 12:28:20 finch kernel: > db_trace_self_wrapper(c0b2f902,e8fc2760,c07ce8ee,c0b32188,c6fa1058,...) > at db_trace_self_wrapper+0x26 > Jul 18 12:28:20 finch kernel: > kdb_backtrace(c0b32188,c6fa1058,c6ee0df9,c6ee0df9,c6ee0d4e,...) > at kdb_backtrace+0x29 > Jul 18 12:28:20 finch kernel: > witness_checkorder(c6fa1058,9,c6ee0d4e,189,4,...) at > witness_checkorder+0x6de > Jul 18 12:28:20 finch kernel: > __lockmgr_args(c6fa1058,80400,c6fa10c0,0,0,...) at > __lockmgr_args+0x777 > Jul 18 12:28:20 finch kernel: > vop_stdlock(e8fc2860,c6fa10f4,c6fa1000,80400,c6fa1000,...) > at vop_stdlock+0x65 > Jul 18 12:28:20 finch kernel: > VOP_LOCK1_APV(c6eea5c0,e8fc2860,c0c3a2a0,c6fa1000,80400,...) > at VOP_LOCK1_APV+0xa5 > Jul 18 12:28:20 finch kernel: > _vn_lock(c6fa1000,80400,c6ee0d4e,189,e8fc28dc,...) at > _vn_lock+0x5e > Jul 18 12:28:20 finch kernel: > xfs_iget(c6926800,c6fa3000,83,0,1,...) at xfs_iget+0x27b > Jul 18 12:28:20 finch kernel: > xfs_trans_iget(c6926800,c6fa3000,83,0,1,...) at > xfs_trans_iget+0x256 > Jul 18 12:28:20 finch kernel: > xfs_ialloc(c6fa3000,c6f9e000,41ed,2,0,...) at > xfs_ialloc+0xda > Jul 18 12:28:20 finch kernel: > xfs_dir_ialloc(e8fc2a78,c6f9e000,41ed,2,0,...) at > xfs_dir_ialloc+0x82 > Jul 18 12:28:20 finch kernel: > xfs_mkdir(c6f9e020,e8fc2c04,e8fc2ab4,e8fc2b28,c69dd700,...) > at xfs_mkdir+0x457 > Jul 18 12:28:20 finch kernel: > _xfs_mkdir(e8fc2c28,c0b6262e,0,e8fc2c28,e8fc2bd8,...) at > _xfs_mkdir+0xb0 > Jul 18 12:28:20 finch kernel: > VOP_MKDIR_APV(c6eea5c0,e8fc2c28,e97,e95,1,...) at > VOP_MKDIR_APV+0xc5 > Jul 18 12:28:20 finch kernel: > kern_mkdirat(c67778c0,ffffff9c,bfbfee32,0,1ff,...) at > kern_mkdirat+0x276 > Jul 18 12:28:20 finch kernel: > kern_mkdir(c67778c0,bfbfee32,0,1ff,e8fc2d2c,...) at > kern_mkdir+0x2e > Jul 18 12:28:20 finch kernel: > mkdir(c67778c0,e8fc2cf8,8,c,c0c003e0,...) at mkdir+0x29 > Jul 18 12:28:20 finch kernel: syscall(e8fc2d38) at syscall+0x2a3 > Jul 18 12:28:20 finch kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 > Jul 18 12:28:20 finch kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip > = 0x28159cd3, esp = 0xbfbfec5c, ebp = 0xbfbfed28 --- > Jul 18 12:28:23 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f9dd80 > Jul 18 12:28:23 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f9e000 > Jul 18 12:28:25 finch kernel: System call stat returning with the following > locks held: > Jul 18 12:28:25 finch kernel: exclusive lockmgr xfs r = 0 (0xc6fa1058) > locked @ /usr/src/sys/modules/xfs/../. Hello Lothar, can you please try this on the top of -CURRENT: http://www.freebsd.org/~attilio/xfs2.diff (it is a perforce patch, so just use -p6 as patching level). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 15:28:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB28106564A; Sat, 19 Jul 2008 15:28:23 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 37A8E8FC18; Sat, 19 Jul 2008 15:28:23 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E81D219E023; Sat, 19 Jul 2008 17:03:32 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id BA58819E019; Sat, 19 Jul 2008 17:03:30 +0200 (CEST) Message-ID: <48820259.3060007@quip.cz> Date: Sat, 19 Jul 2008 17:03:53 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: ticso@cicely.de References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> In-Reply-To: <20080718122928.GD35340@cicely7.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 15:28:23 -0000 Bernd Walter wrote: [...] > Speaking about small systems, where startup time is more a problem than > on 08/15 desktop and server systems. > What I would love to see is that scripts like moused, ypserv, lpt, etc > are not started if the services are disabled. > So far each script is started, sucks in routines plus rc.conf then > possibly does nothing reasonable after wasting some seconds boottime. > Of course I can remove the scripts, but you'll never know if you need > one of them at a later time and having the right set of scripts can > become tricky. And what about just chmod unneeded scripts to become not executable / readable instead of removing? (I like the current "one directory" layout instead of some linuxism with many directories and symlinks) Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 15:35:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B911065680; Sat, 19 Jul 2008 15:35:40 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 59DAC8FC12; Sat, 19 Jul 2008 15:35:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6JFZaBC070798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Jul 2008 17:35:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6JFZWqi058812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 17:35:32 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6JFZWR5051800; Sat, 19 Jul 2008 17:35:32 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6JFZVRk051799; Sat, 19 Jul 2008 17:35:31 +0200 (CEST) (envelope-from ticso) Date: Sat, 19 Jul 2008 17:35:31 +0200 From: Bernd Walter To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080719153530.GL35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <48820259.3060007@quip.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48820259.3060007@quip.cz> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.141, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Doug Barton , David Naylor , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 15:35:40 -0000 On Sat, Jul 19, 2008 at 05:03:53PM +0200, Miroslav Lachman wrote: > Bernd Walter wrote: > > [...] > > >Speaking about small systems, where startup time is more a problem than > >on 08/15 desktop and server systems. > >What I would love to see is that scripts like moused, ypserv, lpt, etc > >are not started if the services are disabled. > >So far each script is started, sucks in routines plus rc.conf then > >possibly does nothing reasonable after wasting some seconds boottime. > >Of course I can remove the scripts, but you'll never know if you need > >one of them at a later time and having the right set of scripts can > >become tricky. > > And what about just chmod unneeded scripts to become not executable / > readable instead of removing? > (I like the current "one directory" layout instead of some linuxism with > many directories and symlinks) This and all the ideas about using enable/disable directories or softlinks share a major problem: They requires configuring outside of rc.conf, which is not what I want. Of course I can do: mkdir /etc/rc.d/disabled ; mv /etc/rc.d/moused /etc/rc.d/disabled But then I would loose the ability to configure everything with rc.conf. A tool, which parses rc.conf and automatically relocates might be an option, but it would be better if it can be done without. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 15:57:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D814C106564A for ; Sat, 19 Jul 2008 15:57:26 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id A5CA78FC0C for ; Sat, 19 Jul 2008 15:57:26 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so871440rvf.43 for ; Sat, 19 Jul 2008 08:57:26 -0700 (PDT) Received: by 10.141.141.3 with SMTP id t3mr790493rvn.124.1216483046489; Sat, 19 Jul 2008 08:57:26 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Sat, 19 Jul 2008 08:57:26 -0700 (PDT) Message-ID: <919383240807190857x6352a004x37943642399242fa@mail.gmail.com> Date: Sat, 19 Jul 2008 10:57:26 -0500 From: "Edward Ruggeri" To: "Garrett Cooper" In-Reply-To: <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 15:57:26 -0000 On Fri, Jul 18, 2008 at 7:29 PM, Edward Ruggeri wrote: >> As for the actual debug process, there's a spot in the dev handbook >> about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html), >> but when I tried debugging my issue with NTFS and SMB I didn't really >> find it helpful to be honest... AND >> You may also have to compile without SMP and with the 4BSD scheduler >> just to see whether or not it's an issue reproducible with the ULE >> scheduler, the driver, or something else... I have a couple dumps now, with different kernel configurations. In addition to the debugging options Garrett has recommended, I've switched from the ULE to the 4BSD scheduler and removed SMP support. The error persists. The backtrace in kgdb says that panic is called from the function ath_start at line 1748 in ath_start.c. Here is a snippet: bf = STAILQ_FIRST(&frags); KASSERT(bf != NULL, ("no buf for txfrag")); Does that sound like enough to file a problem report with? What other information would be desired? -- Ned Ruggeri From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 18:37:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED87F1065677; Sat, 19 Jul 2008 18:37:12 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from imlil.netoyen.net (imlil.netoyen.net [91.121.103.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAF18FC16; Sat, 19 Jul 2008 18:37:12 +0000 (UTC) (envelope-from mouss@netoyen.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=netoyen.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=msa; bh=6FxPh5ILcVAe9 27kz30z9aU4ga4=; b=rXizgiOhgWSAFIxwBpXVS++oZXjnog+uTjUHmWCjcU4Gy Eu0iHp3TIWW6qOOLy47DNAo3hBV74UqP1dp39gWrc8wPHezgfgJJZk30Z5w5U8Af /d+i92GXqQmq5+J92i7CrK4oAl9qGwmrSseZHfjIrEouQfBxv7FaMgtH6ICMyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=netoyen.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=msa; b=pyIHwlh ZzyGM/lwUXSVToc9dKAjKapjyqHQ9nK3ovgw1xb6znQVCJW5OA+IbyA2xHi4Q2nJ YRlJNJfJYxOat13O9435Z4ab2vzzh8gvT95JxfL7mMh9gT6Yti9Qx0q+su5QMazR nPWjzw5ZB2c63DeRL4VpcT3XTuIt/QCbLgwA= X-Virus-Scanned: amavisd-new at netoyen.net Received: from [192.168.1.65] (ouzoud.netoyen.net [82.239.111.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mouss@netoyen.net) by imlil.netoyen.net (Postfix) with ESMTPSA id 4B98BE5481C; Sat, 19 Jul 2008 20:22:21 +0200 (CEST) Message-ID: <488230CD.6000906@netoyen.net> Date: Sat, 19 Jul 2008 20:22:05 +0200 From: mouss User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ticso@cicely.de References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <48820259.3060007@quip.cz> <20080719153530.GL35340@cicely7.cicely.de> In-Reply-To: <20080719153530.GL35340@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , David Naylor , Miroslav Lachman <000.fbsd@quip.cz>, freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 18:37:13 -0000 Bernd Walter wrote: > On Sat, Jul 19, 2008 at 05:03:53PM +0200, Miroslav Lachman wrote: >> Bernd Walter wrote: >> >> [...] >> >>> Speaking about small systems, where startup time is more a problem than >>> on 08/15 desktop and server systems. >>> What I would love to see is that scripts like moused, ypserv, lpt, etc >>> are not started if the services are disabled. >>> So far each script is started, sucks in routines plus rc.conf then >>> possibly does nothing reasonable after wasting some seconds boottime. >>> Of course I can remove the scripts, but you'll never know if you need >>> one of them at a later time and having the right set of scripts can >>> become tricky. >> And what about just chmod unneeded scripts to become not executable / >> readable instead of removing? >> (I like the current "one directory" layout instead of some linuxism with >> many directories and symlinks) > > This and all the ideas about using enable/disable directories or > softlinks share a major problem: > They requires configuring outside of rc.conf, which is not what I want. > Of course I can do: > mkdir /etc/rc.d/disabled ; mv /etc/rc.d/moused /etc/rc.d/disabled > But then I would loose the ability to configure everything with rc.conf. > A tool, which parses rc.conf and automatically relocates might be an > option, but it would be better if it can be done without. > how about a cache mechanism: rcorder/rc would use a previously determined order unless something changed in rc.conf or rc.d. this way you don't need to determine which scripts need to run and in which order every time the system boots. this also removes the need for an "active.d" directory. From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 19:40:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2419D1065686 for ; Sat, 19 Jul 2008 19:40:03 +0000 (UTC) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 89C278FC25 for ; Sat, 19 Jul 2008 19:40:02 +0000 (UTC) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from nschwotgx01p.mx.bigpond.com ([124.176.185.159]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20080719163136.OQNI357.nschwmtas02p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Sat, 19 Jul 2008 16:31:36 +0000 Received: from oldie.bigpond.com ([124.176.185.159]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20080719163134.VKUE19251.nschwotgx01p.mx.bigpond.com@oldie.bigpond.com> for ; Sat, 19 Jul 2008 16:31:34 +0000 Received: from oldie.bigpond.com (localhost [127.0.0.1]) by oldie.bigpond.com (8.14.2/8.14.2) with ESMTP id m6JGWCQC024640 for ; Sun, 20 Jul 2008 02:32:12 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from localhost (petros@localhost) by oldie.bigpond.com (8.14.2/8.14.2/Submit) with ESMTP id m6JGWA53024637 for ; Sun, 20 Jul 2008 02:32:12 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) X-Authentication-Warning: oldie.bigpond.com: petros owned process doing -bs Date: Sun, 20 Jul 2008 02:32:09 +1000 (EST) From: Peter Ross X-X-Sender: petros@oldie.bigpond.com To: freebsd-current@freebsd.org Message-ID: <20080720022644.H23554@oldie.bigpond.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.488216E7.006D,ss=1,fgs=0 Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 19:40:03 -0000 [Resending - maybe I used the wrong mail address which is not subscribed to -current? Does it matter? Anyway, the message did not make it to the list, it seems, and I did not get a notice.. strange] ---------- Forwarded message ---------- Date: Sun, 20 Jul 2008 01:07:32 +1000 (EST) On Sat, 19 Jul 2008, Robert Noland wrote: > On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote: > > Bernd Walter wrote: > > > Speaking about small systems, where startup time is more a problem than > > > on 08/15 desktop and server systems. > > > What I would love to see is that scripts like moused, ypserv, lpt, etc > > > are not started if the services are disabled. > > > > That wold be a neat trick, how do you propose we accomplish it? (no, > > I'm not being snide.) > > .. > > One way you could do this is to have /etc/rc.d/active and > > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical > > stuff that most people shouldn't touch). Then you could have a > > vipw-like system to allow users to edit rc.conf that would move the > > scripts to the right directory. Of course, this would be fraught with > > potential for problems. :) > > I almost hate to toss this out there, but what about a sys v type rc? Usually the scripts are running run_rc_command. This does a checkyesno for the rcvar variable which is usually ${name}_enable. In most of the cases it uses set_rcvar to achieve this. If so, /etc/rc could evaluate ${name}_enable (it already knows them via /etc/rc.conf) before actually calling a script. There are some irregular names amongst the name of the rcvar variable. I am not 100% sure whether same of the scripts set ${name}_enable vaiables implicitly. That could complicate things. I could not find evidence by browsing through them. I also do not know whether there are scripts that actually do something valuable before calling run_rc_command. At the moment it looks to me that these excemptions could be dealt with by adapting the scripts so they meet the standard (running only when ${name}_enable is set). I only looked through some of the /etc/rc.d scripts en detail (+ some greps for rcvar etc. in the directory) so it needs some more investigation. If it works it avoids messing around with symlinks or moving scripts around, and it reduces the scripts that actually run. As a sys admin I really like the BSD way of having everything relevant to my system in one /etc/rc.conf. It is very convenient. Regards Peter From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 19:42:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDAE106566C for ; Sat, 19 Jul 2008 19:42:10 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 048E48FC14 for ; Sat, 19 Jul 2008 19:42:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so491781fgb.35 for ; Sat, 19 Jul 2008 12:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oCBwROUfgJW4C0LIKs18SJLh+WsCzXjFGlm1bz1t74Q=; b=hCU+fjyjlGL9C35CHjwjFNtWHd2OUMftKFzR1QEp/lhQk/TzbkZfyZMxHmLpKAKF84 JXOjcyPToYfFt3kDkN3vnmAyIibPQUnZuluIE1QW8BQdnKq8y3JwqDXHGb/cQOo2IH9y 1EQmLjbkgs3OqGistz94MzobJJYC/EgfNV4no= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sGjuopL3PwWRr8xPiyGQOJ5aNfhm/r27/SPrxBtLMG2plAXSBBtje2FnGQZxhuM6Ek v7TDirAFWgTUafma6YU3KvwABpTdCZapFVUvnG3QzR/SN88GE7tcv2g8MY9Fuq2JBCUF 3gFmV+WKCzXKV/yUbWDW2ipb26WlXPe2NV5s0= Received: by 10.86.63.19 with SMTP id l19mr2436435fga.60.1216496528970; Sat, 19 Jul 2008 12:42:08 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Sat, 19 Jul 2008 12:42:08 -0700 (PDT) Message-ID: <7d6fde3d0807191242o49ad60adu7a4099c2e2e92692@mail.gmail.com> Date: Sat, 19 Jul 2008 12:42:08 -0700 From: "Garrett Cooper" To: "Edward Ruggeri" In-Reply-To: <919383240807190857x6352a004x37943642399242fa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> <919383240807190857x6352a004x37943642399242fa@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 19:42:10 -0000 On Sat, Jul 19, 2008 at 8:57 AM, Edward Ruggeri wrote: > On Fri, Jul 18, 2008 at 7:29 PM, Edward Ruggeri wrote: >>> As for the actual debug process, there's a spot in the dev handbook >>> about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html), >>> but when I tried debugging my issue with NTFS and SMB I didn't really >>> find it helpful to be honest... > > AND > >>> You may also have to compile without SMP and with the 4BSD scheduler >>> just to see whether or not it's an issue reproducible with the ULE >>> scheduler, the driver, or something else... > > I have a couple dumps now, with different kernel configurations. In > addition to the debugging options Garrett has recommended, I've > switched from the ULE to the 4BSD scheduler and removed SMP support. > The error persists. > > The backtrace in kgdb says that panic is called from the function > ath_start at line 1748 in ath_start.c. Here is a snippet: > > bf = STAILQ_FIRST(&frags); > KASSERT(bf != NULL, ("no buf for txfrag")); > > Does that sound like enough to file a problem report with? What other > information would be desired? You might want to first update the kernel and userland to 7-RELENG first. If the issue persists in 7-RELENG, I'd file a PR. Regardless of whether or not the issue persists I would contact the maintainer to let them know about the bug. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 19:45:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AFC1065672 for ; Sat, 19 Jul 2008 19:45:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id B74658FC0A for ; Sat, 19 Jul 2008 19:45:34 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so492362fgb.35 for ; Sat, 19 Jul 2008 12:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Xcodbzsq8VbVTzMp9BoAw8D/IuBMZN+lDWUjZqO/X54=; b=Y5H2bWYQLG6Il7rtrmgYhPx0SqPpLbiBPJb7Gu3IN6xxtqN9U4zSII23QjX6wuV5gz M8z2N+9xunAqq9e9dGNZUSmNf0FkVxyr/lhfidCsWC7waaeVjMK2KcP/tPw1S5Z6PlpZ ExgXjTOgy9ppu8C4tdhRZGxGfTpmXGQcLTxfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QGFio+rduvxQTZlAEOPTTTZvBmaSsNF5bduOOtiPx4LlSznPT4gnJ5x0rkqMQiUpvA zx2/loRN5JFOs+4TTcA5+6E2/qJmoSv9vcs21UTSjlUtXsXh0XaYKf4xfy64svdiAXek 7EYiFfFeSNcjxYuiPojwR6KzLctb1Y7wSvqo8= Received: by 10.86.49.13 with SMTP id w13mr2497992fgw.8.1216496733462; Sat, 19 Jul 2008 12:45:33 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Sat, 19 Jul 2008 12:45:33 -0700 (PDT) Message-ID: <7d6fde3d0807191245g748c6823udf6c187cdfad1b9a@mail.gmail.com> Date: Sat, 19 Jul 2008 12:45:33 -0700 From: "Garrett Cooper" To: "Edward Ruggeri" In-Reply-To: <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 19:45:35 -0000 On Fri, Jul 18, 2008 at 5:29 PM, Edward Ruggeri wrote: > On Fri, Jul 18, 2008 at 6:36 AM, Garrett Cooper wrote: >> Some notes: >> >> 1. *blinks*... I hope you mean 8-CURRENT, not 7-CURRENT. 7 hasn't been >> CURRENT for some months now (~6 months IIRC). > > Oh my, I am an idiot. I'm using 7-STABLE, making this the wrong list > to ask; sorry. I guess I could repost to freebsd-stable in addition > to filing a PR. Would that be wise? > >> 2. pciconf -lv might help with the PCI ID info. Then someone might be >> able to tie your card back to the appropriate chipset. > > This gives me: > ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5212 Atheros AR5212 802.11abg wireless' > class = network > subclass = ethernet > class = base peripheral > > I get 167 pages on google that contain ar5212 and 0x1014168c and > 0x058a1014. I only get one with ar5006ex instead of ar5212. I'm > inclined to believe my Lenovo representative was wrong; she's just a > sales rep and asked around about the part... > >> 3. KDB, DDB, WITNESS and INVARIANTS support compiled into the kernel >> would be extremely helpful, if not required to debug your issue. > > I'm currently recompiling the kernel with these debug options: > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > options KDB > options DDB > options INVARIANTS > options WITNESS > > As soon as it's done compiling, I'll try reproducing the error. I've > added "set dumpdev="/var/crash" in /etc/rc.conf. > >> As for the actual debug process, there's a spot in the dev handbook >> about it (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html), >> but when I tried debugging my issue with NTFS and SMB I didn't really >> find it helpful to be honest... > > Once I have a core dump, how should I proceed? Use kdb, and execute > "list *[instruction pointer]" to find out what (NULL) pointer is being > dereferenced? Run backtrace? If I post a PR, is it likely that > someone can guide me through this? I'm fairly familiar with C, but my > experience using debuggers is very limited... > >> You may also have to compile without SMP and with the 4BSD scheduler >> just to see whether or not it's an issue reproducible with the ULE >> scheduler, the driver, or something else... > > After I get the dump with the current options (+ debug options), I'll > try w/o SMP and ULE... > >> Hopefully this gets you started on the right path... >> -Garrett > > Thanks so much, Garrett! No problem :). The steps I just had you go through were to rule out the kernel scheduler and multiprocessing -- 2 points that make debugging issues like these difficult. With all of the locking changes in 7-RELEASE, it's harder to track down driver bugs to some extent. The error seems straightforward (albeit it may not sound like it) though: it's an issue with how your card is interfacing with the driver. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 20:32:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DB22106566C; Sat, 19 Jul 2008 20:32:00 +0000 (UTC) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) by mx1.freebsd.org (Postfix) with ESMTP id 679068FC08; Sat, 19 Jul 2008 20:31:59 +0000 (UTC) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from nschwotgx03p.mx.bigpond.com ([124.176.185.159]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20080719150659.HZUY17148.nschwmtas06p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Sat, 19 Jul 2008 15:06:59 +0000 Received: from oldie.bigpond.com ([124.176.185.159]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20080719150658.MAGT3962.nschwotgx03p.mx.bigpond.com@oldie.bigpond.com>; Sat, 19 Jul 2008 15:06:58 +0000 Received: from oldie.bigpond.com (localhost [127.0.0.1]) by oldie.bigpond.com (8.14.2/8.14.2) with ESMTP id m6JF7Zif024118; Sun, 20 Jul 2008 01:07:35 +1000 (EST) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from localhost (petros@localhost) by oldie.bigpond.com (8.14.2/8.14.2/Submit) with ESMTP id m6JF7Weg024115; Sun, 20 Jul 2008 01:07:33 +1000 (EST) (envelope-from Peter.Ross@bogen.in-berlin.de) X-Authentication-Warning: oldie.bigpond.com: petros owned process doing -bs Date: Sun, 20 Jul 2008 01:07:32 +1000 (EST) From: Peter Ross X-X-Sender: petros@oldie.bigpond.com To: Robert Noland In-Reply-To: <1216473536.1991.5.camel@wombat.2hip.net> Message-ID: <20080720003343.S23554@oldie.bigpond.com> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> <1216473536.1991.5.camel@wombat.2hip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.48820313.004C,ss=1,fgs=0 X-Mailman-Approved-At: Sat, 19 Jul 2008 21:03:19 +0000 Cc: freebsd-current@FreeBSD.org, Doug Barton , ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 20:32:00 -0000 On Sat, 19 Jul 2008, Robert Noland wrote: > On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote: > > Bernd Walter wrote: > > > Speaking about small systems, where startup time is more a problem than > > > on 08/15 desktop and server systems. > > > What I would love to see is that scripts like moused, ypserv, lpt, etc > > > are not started if the services are disabled. > > > > That wold be a neat trick, how do you propose we accomplish it? (no, > > I'm not being snide.) > > .. > > One way you could do this is to have /etc/rc.d/active and > > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical > > stuff that most people shouldn't touch). Then you could have a > > vipw-like system to allow users to edit rc.conf that would move the > > scripts to the right directory. Of course, this would be fraught with > > potential for problems. :) > > I almost hate to toss this out there, but what about a sys v type rc? Usually the scripts are running run_rc_command. This does a checkyesno for the rcvar variable which is usually ${name}_enable. In most of the cases it uses set_rcvar to achieve this. If so, /etc/rc could evaluate ${name}_enable (it already knows them via /etc/rc.conf) before actually calling a script. There are some irregular names amongst the name of the rcvar variable. I am not 100% sure whether same of the scripts set ${name}_enable vaiables implicitly. That could complicate things. I could not find evidence by browsing through them. I also do not know whether there are scripts that actually do something valuable before calling run_rc_command. At the moment it looks to me that these excemptions could be dealt with by adapting the scripts so they meet the standard (running only when ${name}_enable is set). I only looked through some of the /etc/rc.d scripts en detail (+ some greps for rcvar etc. in the directory) so it needs some more investigation. If it works it avoids messing around with symlinks or moving scripts around, and it reduces the scripts that actually run. As a sys admin I really like the BSD way of having everything relevant to my system in one /etc/rc.conf. It is very convenient. Regards Peter From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 21:36:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C745C1065672 for ; Sat, 19 Jul 2008 21:36:43 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB6B8FC1A for ; Sat, 19 Jul 2008 21:36:43 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so258655ywe.13 for ; Sat, 19 Jul 2008 14:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Flo/LDMRGzvqZhrqEDv5B3tP6y3S2jp99LJ9eIO4IL0=; b=XWx3mjdaQOJT8p7Nj+RkcetAxAu4qmyGJUcIkmNhAlCwEYRwiEqONMi1VsSxU3ZkxQ H8/fWyucX3GpCHUgmPVUupa7j4zLsZJcewunxDvjxnFv7BCsJXXvwQgzc2Bk4cZda3yX f2ZpW9mW+fAQT4Mc8rBWXlbAXie1ikXALp1k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ACmGc6XiHmtJcueOm0hGCvsBzVpRu0GvvTsDgdVLDqdLDfh6s19pMXiKLe4jxqdmBv 9DuS8dmN/RBIK5Oi2QKisobk0ThgoieyPO7BPFzmRz8EQS+EoUpHLrUyOYXPyiUTdtyr fsN43zhYSCsm4/1ph0fJSWmsO5U00pOVFHW6Y= Received: by 10.150.149.19 with SMTP id w19mr1818880ybd.50.1216501758078; Sat, 19 Jul 2008 14:09:18 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.22.162]) by mx.google.com with ESMTPS id 30sm3062554yxk.4.2008.07.19.14.09.17 (version=SSLv3 cipher=RC4-MD5); Sat, 19 Jul 2008 14:09:17 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Giorgos Keramidas In-Reply-To: <87prpcjrsk.fsf@kobe.laptop> References: <87prpcjrsk.fsf@kobe.laptop> Content-Type: text/plain; charset=utf-8 Date: Sat, 19 Jul 2008 17:03:08 -0400 Message-Id: <1216501388.971.6.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 21:36:43 -0000 On Thu, 2008-07-17 at 21:20 +0300, Giorgos Keramidas wrote: > I recently had to replace my dead laptop, and I bought a replacement > relatively fast, but something is broken with APIC on this one. > > FreeSBIE 2.0.1 (based on 6.2-RELEASE) seems to automatically disable the > APIC, using hint.apic.0.disabled="1", so I didn't realize APIC failed to > work properly until I dump(8) and restore(8)'d my backup to the new > laptop. > > After booting with the APIC enabled, I found out that: > > * In single user mode, after `boot -sv', I can keep working without > any major slow down. > > * When I exit single user mode, and a few of the rc.d startup scripts > run, the laptop becomes progressively slower, and eventually crawls > to an unusable state. I can almost complete logging in as `root' in > ttyv0 but only if I keep furiously moving the mouse around. If I > don't move the mouse at all, the typed characters may never actually > appear on ttyv0. > Are you by any chance using cx_lowest="C3" (or "LOW") in your rc.conf? I have seen these symptoms (including mouse inducement of the typed characters) when cpu0 on my laptop went to C3. Nowadays I have C3 on cpu1 and C2 on cpu0 and life is good. Then again, I am running RELENG_7 (which AFAICR was 7-CURRENT at the time), so YMMV. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:15:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F9E106564A for ; Sat, 19 Jul 2008 22:15:50 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 27FAD8FC13 for ; Sat, 19 Jul 2008 22:15:50 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so975825rvf.43 for ; Sat, 19 Jul 2008 15:15:49 -0700 (PDT) Received: by 10.141.132.8 with SMTP id j8mr918947rvn.297.1216505749845; Sat, 19 Jul 2008 15:15:49 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Sat, 19 Jul 2008 15:15:49 -0700 (PDT) Message-ID: <919383240807191515o28cdac6eu176f72a062f89087@mail.gmail.com> Date: Sat, 19 Jul 2008 17:15:49 -0500 From: "Edward Ruggeri" To: "Garrett Cooper" In-Reply-To: <7d6fde3d0807191242o49ad60adu7a4099c2e2e92692@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807172100j35e1c796q513fa34d83f8e8e0@mail.gmail.com> <7d6fde3d0807180336h61f13a73pcc433be16a732c7e@mail.gmail.com> <919383240807181729n210402a5r5095f8b1554e9891@mail.gmail.com> <919383240807190857x6352a004x37943642399242fa@mail.gmail.com> <7d6fde3d0807191242o49ad60adu7a4099c2e2e92692@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT kernel's ath driver causes page fault, kernel panic (debugging kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:15:50 -0000 On Sat, Jul 19, 2008 at 2:42 PM, Garrett Cooper wrote: > You might want to first update the kernel and userland to 7-RELENG > first. If the issue persists in 7-RELENG, I'd file a PR. Regardless of > whether or not the issue persists I would contact the maintainer to > let them know about the bug. I'm a little unclear on what you mean, or perhaps I wasn't clear earlier. July 10 (or so), I synced my source tree to RELENG_7 and built/installed world/kernel (do you know if there's a way I could check the day of the source?). Do you want me to "downgrade" and use the RELENG_7_0 or RELENG_7_0_0_RELEASE branch tags? That sounds like it could be a good idea, but I wanted to check first before going ahead. Is it generally necessary to rebuild ports after updating the source tree? It's not a big deal -- I don't have any work on here currently anyway, but I'm just curious for the future. Since it seems we've dodged a bullet with ULE & SMP, I'm optimistic the debug information will help us! Thanks again so much, Garrett! Have a great weekend! Sincerely, -- Ned Ruggeri From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:32:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07899106564A for ; Sat, 19 Jul 2008 22:32:05 +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 8099D8FC0A for ; Sat, 19 Jul 2008 22:32:04 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl133-207.kln.forthnet.gr [77.49.252.207]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6JMVaHP025756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 01:31:43 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6JMVau3064190; Sun, 20 Jul 2008 01:31:36 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6JMVZiD064189; Sun, 20 Jul 2008 01:31:35 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Alexandre \"Sunny\" Kovalenko" References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> Date: Sun, 20 Jul 2008 01:31:34 +0300 In-Reply-To: <1216501388.971.6.camel@RabbitsDen> (Alexandre Kovalenko's message of "Sat, 19 Jul 2008 17:03:08 -0400") Message-ID: <87od4t5wvt.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6JMVaHP025756 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.785, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:32:05 -0000 On Sat, 19 Jul 2008 17:03:08 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > On Thu, 2008-07-17 at 21:20 +0300, Giorgos Keramidas wrote: >> I recently had to replace my dead laptop, and I bought a replacement >> relatively fast, but something is broken with APIC on this one. >> >> FreeSBIE 2.0.1 (based on 6.2-RELEASE) seems to automatically disable the >> APIC, using hint.apic.0.disabled="1", so I didn't realize APIC failed to >> work properly until I dump(8) and restore(8)'d my backup to the new >> laptop. >> >> After booting with the APIC enabled, I found out that: >> >> * In single user mode, after `boot -sv', I can keep working without >> any major slow down. >> >> * When I exit single user mode, and a few of the rc.d startup scripts >> run, the laptop becomes progressively slower, and eventually crawls >> to an unusable state. I can almost complete logging in as `root' in >> ttyv0 but only if I keep furiously moving the mouse around. If I >> don't move the mouse at all, the typed characters may never actually >> appear on ttyv0. >> > Are you by any chance using cx_lowest="C3" (or "LOW") in your rc.conf? I > have seen these symptoms (including mouse inducement of the typed > characters) when cpu0 on my laptop went to C3. Nowadays I have C3 on > cpu1 and C2 on cpu0 and life is good. Then again, I am running RELENG_7 > (which AFAICR was 7-CURRENT at the time), so YMMV. -- From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:34:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854A9106566C for ; Sat, 19 Jul 2008 22:34:07 +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 0ADD98FC1A for ; Sat, 19 Jul 2008 22:34:06 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl133-207.kln.forthnet.gr [77.49.252.207]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6JMXVJx025898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 01:33:38 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6JMXVY1064212; Sun, 20 Jul 2008 01:33:31 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6JMXUvE064211; Sun, 20 Jul 2008 01:33:30 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1216501388.971.6.camel@RabbitsDen> (Alexandre Kovalenko's message of "Sat, 19 Jul 2008 17:03:08 -0400") References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) Date: Sun, 20 Jul 2008 01:33:30 +0300 Message-ID: <87mykd5wsl.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6JMXVJx025898 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.786, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:34:07 -0000 On Sat, 19 Jul 2008 17:03:08 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > On Thu, 2008-07-17 at 21:20 +0300, Giorgos Keramidas wrote: >> After booting with the APIC enabled, I found out that: >> >> * In single user mode, after `boot -sv', I can keep working without >> any major slow down. >> >> * When I exit single user mode, and a few of the rc.d startup scripts >> run, the laptop becomes progressively slower, and eventually crawls >> to an unusable state. I can almost complete logging in as `root' in >> ttyv0 but only if I keep furiously moving the mouse around. If I >> don't move the mouse at all, the typed characters may never actually >> appear on ttyv0. > > Are you by any chance using cx_lowest="C3" (or "LOW") in your rc.conf? I > have seen these symptoms (including mouse inducement of the typed > characters) when cpu0 on my laptop went to C3. Nowadays I have C3 on > cpu1 and C2 on cpu0 and life is good. Then again, I am running RELENG_7 > (which AFAICR was 7-CURRENT at the time), so YMMV. Ah, good point. I have indeed performance_cx_lowest="LOW" in rc.conf. I'll remove that and try again with the APIC enabled... From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:49:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512B2106564A; Sat, 19 Jul 2008 22:49:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 02C5A8FC0C; Sat, 19 Jul 2008 22:49:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6JMn0Zp079933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Jul 2008 00:49:01 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMmu9M068226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 00:48:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMmu05052740; Sun, 20 Jul 2008 00:48:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6JMmuSf052739; Sun, 20 Jul 2008 00:48:56 +0200 (CEST) (envelope-from ticso) Date: Sun, 20 Jul 2008 00:48:55 +0200 From: Bernd Walter To: Doug Barton Message-ID: <20080719224855.GM35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4881795A.4070604@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.140, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:49:03 -0000 On Fri, Jul 18, 2008 at 10:19:22PM -0700, Doug Barton wrote: > Bernd Walter wrote: > >Speaking about small systems, where startup time is more a problem than > >on 08/15 desktop and server systems. > >What I would love to see is that scripts like moused, ypserv, lpt, etc > >are not started if the services are disabled. > > That wold be a neat trick, how do you propose we accomplish it? (no, > I'm not being snide.) Sorry - I have no proposal - just a few ideas, of which I know none is perfect. I think it would be great if rcorder can honour the settings somehow, but I'm aware that rc.conf is a shell script and that some files are not depended on any kind of _enable variable. But if we can teach rcorder at least to read the foo_enable variables and drop the script that provide foo. Nevertheless I don't asume it to be a simple task. I'm not familar enough with all the details on how to implement it nor do I request it. All I wanted to do is spread an idea and hope that someone can do something with it. > There are 144 scripts in /etc/rc.d/ on HEAD right now. Out of those I > count roughly 40 that I actually need, so let's round off to 100 > unnecessary scripts to make the math easy. On my system (a pretty fast > C2D) it takes roughly .3 seconds of wall clock time to run one script > that is not enabled. Now cut that roughly in half since each of those > scripts will not have to suck in /etc/rc.subr and /etc/rc.conf* when > run at boot time, and that's 15 seconds of boot time that I could save > on average, let's say +/- 5 seconds. That's worth giving some thought to. Well - my problem about this is more problematic: [217]arm9# time /etc/rc.d/moused start 0.000u 0.000s 0:01.73 44.5% 1196+13491k 1+0io 2pf+0w Ok - you wrote below that rc.subr and Co are loaded only once, so the time on booting should be better. Also the system is not completely idle right now. But anyway - it's a much longer time for slow embedded systems. rcorder is run only once and fast enough for that: [220]arm9# time rcorder /etc/rc.d/* /usr/local/etc/rc.d/* [...] /etc/rc.d/bluetooth /etc/rc.d/bgfsck 0.000u 0.000s 0:01.04 54.8% 777+17180k 0+0io 0pf+0w > One way you could do this is to have /etc/rc.d/active and > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical > stuff that most people shouldn't touch). Then you could have a > vipw-like system to allow users to edit rc.conf that would move the > scripts to the right directory. Of course, this would be fraught with > potential for problems. :) That's why I'm not doing it manualy, although there are scripts that I will never need to enable. > Another thing that would work for systems that a more sophisticated > admin/user updates with mergemaster would be to write a pre-compare > script that removes all the scripts you know you don't need from the > temproot/etc/rc.d so that they don't get installed. Of course the > benefit of that would not be nearly as wide spread, but it would also > not result in so much foot-shooting. > > >So far each script is started, sucks in routines plus rc.conf > > We're actually a little smarter than that. :) rc.subr and > rc.conf[.local] are loaded once by rc, then each script that runs > inherits those values. That's bad to hear, since that fruit is already taken then ;-) -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 21:35:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B576C1065670 for ; Sat, 19 Jul 2008 21:35:11 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 845CC8FC19 for ; Sat, 19 Jul 2008 21:35:11 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so967360rvf.43 for ; Sat, 19 Jul 2008 14:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6sldsyR3cDMCDT1zGNmGZxiryh3sDZKCnRQn1CY4UWc=; b=QmEyP3rQ0QwVwN6qGNqhTq7QV+XUxVA4wE/vhbcgnkubqNnJ9hGGZGdgFiDWItRBwn cdMVqnaSSXcmWfWPWHMPkKt+wRdZ3GFjG/cfOSCJquT3qqlydprCHIRcud2ZWJRCeqOM 2nzyMJcgbypfUALLs8ngCt+iiHpZmy4r8S70w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jGMBHtBsZTr6VkBfdlCRFVArTE4N06VC9M4uu6lHoyLBt2MryWpmYlGcyaopK3bKJ+ DSM9o2Z63s6gqsP4mlxJUtxWW0L+NhFa/4RNZJ5XRFyDRJ8OTYyZJxcM1JsWqlHrpG7l /ITRlGulLkGFFPMhZu/Oi7qY9A9oRnMR+5z9M= Received: by 10.114.193.1 with SMTP id q1mr1416278waf.70.1216503310874; Sat, 19 Jul 2008 14:35:10 -0700 (PDT) Received: by 10.114.161.7 with HTTP; Sat, 19 Jul 2008 14:35:10 -0700 (PDT) Message-ID: <2e77fc10807191435tdde4f41nf48402bcf157a137@mail.gmail.com> Date: Sun, 20 Jul 2008 00:35:10 +0300 From: "Niki Denev" To: "Stefan Bethke" In-Reply-To: <525E8FF6-307E-4DC9-B730-21435A2C2D2C@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <525E8FF6-307E-4DC9-B730-21435A2C2D2C@lassitu.de> X-Mailman-Approved-At: Sat, 19 Jul 2008 22:50:45 +0000 Cc: FreeBSD Current Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 21:35:11 -0000 On Fri, Jul 18, 2008 at 2:19 PM, Stefan Bethke wrote: > > Am 18.07.2008 um 09:18 schrieb Peter Jeremy: > >> On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger >> wrote: >>> >>> Are you aware that the parallel starting in Solaris 10 reduced the >>> booting time by a nice percentage? >> >> Given that Solaris boots in geologic time, this probably wouldn't >> be difficult. >> >>> If yes, do you expect that FreeBSD >>> behaves significantly different or do you "just" want to see numbers? >> >> Parallel starting is not guaranteed to be an improvement. Starting a >> whole pile of processes that are I/O bound during initialisation >> (think squid or some databases) may be worse than starting them one >> at a time. Likewise, a whole pile of processes that are CPU bound >> will just thrash the scheduler. (Though parallel starting of I/O and >> CPU bound processes should be a win). > > Just as a simple counter-example: it's very annoying when a startup script > for a non-essential service is blocking startup for an essential one. (A > Smokeping config of mine takes about 5 minutes to finish, and it's blocking > sshd, as I found out the other day when I had to reboot the server.) Also > see the repeated annoyances caused by dhclient on this list and elsewhere. > Hi Stefan, I'm a little bit offtopic, but I've fixed my dhclient problems (delays) with the following patch : http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086888.html P.S.: I think that we could benefit from some kind of rc scripts improvement, some years ago I was very happy that my FreeBSD box booted much faster than a Linux one, but today it's the other way around. Some distributions (Ubuntu?) even have new event based startup daemons : http://www.linux.com/feature/125977 https://wiki.ubuntu.com/ReplacementInit HTH, Niki > > Stefan > > -- > Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:52:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C72106566B for ; Sat, 19 Jul 2008 22:52:06 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 825788FC18 for ; Sat, 19 Jul 2008 22:52:05 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl133-207.kln.forthnet.gr [77.49.252.207]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6JMpXPG026696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 01:51:40 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6JMpXwn002114; Sun, 20 Jul 2008 01:51:33 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6JMpWD7002113; Sun, 20 Jul 2008 01:51:32 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Alexandre \"Sunny\" Kovalenko" References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> Date: Sun, 20 Jul 2008 01:51:32 +0300 In-Reply-To: <87mykd5wsl.fsf@kobe.laptop> (Giorgos Keramidas's message of "Sun, 20 Jul 2008 01:33:30 +0300") Message-ID: <87tzelebd7.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6JMpXPG026696 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.786, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:52:06 -0000 On Sun, 20 Jul 2008 01:33:30 +0300, Giorgos Keramidas wrote: > On Sat, 19 Jul 2008 17:03:08 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: >> Are you by any chance using cx_lowest="C3" (or "LOW") in your >> rc.conf? I have seen these symptoms (including mouse inducement of >> the typed characters) when cpu0 on my laptop went to C3. Nowadays I >> have C3 on cpu1 and C2 on cpu0 and life is good. Then again, I am >> running RELENG_7 (which AFAICR was 7-CURRENT at the time), so YMMV. > > Ah, good point. I have indeed performance_cx_lowest="LOW" in rc.conf. > > I'll remove that and try again with the APIC enabled... That was it. Thanks! # sysctl -a | egrep -e 'cx_(usage|support)' dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% With anything except "C1" the CPU is obviously too slow to do anything useful :-) From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:53:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1C721065678 for ; Sat, 19 Jul 2008 22:53:45 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 954B08FC15 for ; Sat, 19 Jul 2008 22:53:45 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so264769ywe.13 for ; Sat, 19 Jul 2008 15:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=XRSTJLnokorizpISwH3bbqHyj3JRZxLj1V0MNIb3Jrc=; b=BNxTw38VMhAbvS0cWaVdVZXPZN4BcaEVUwEdLVa5JU0zZFgd7jr9oMMDomyhtSxwL3 DPqsEEHDWCdLr0ki2LbqMHK6acgyglvcLiHBupboDnQsCFvyVzlWqe5jy5Wlc63vqAlP Y6hjBjP3oMjrzegmT3JbvlCYLfDHkrDFSwBYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=joEsjkC4I4zebO/hV9WpW0tsSdUJ86b6LIrBV6QG9bPvApcGDT86l5/gFAwKh1LLmG iVyOJcSv12c7ib/zH6S82HKTogV3C3d6XUck8QAqt0zer+2Y89+KM5STsM/3VUaRwiUc J/rwKdENMWrlQL8kb6TcZOz4a7KvBwQOxurUw= Received: by 10.151.150.13 with SMTP id c13mr1882670ybo.155.1216508024933; Sat, 19 Jul 2008 15:53:44 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.22.162]) by mx.google.com with ESMTPS id 9sm4052984ywf.2.2008.07.19.15.53.43 (version=SSLv3 cipher=RC4-MD5); Sat, 19 Jul 2008 15:53:44 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Giorgos Keramidas In-Reply-To: <87mykd5wsl.fsf@kobe.laptop> References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> Content-Type: text/plain; charset=utf-8 Date: Sat, 19 Jul 2008 18:53:34 -0400 Message-Id: <1216508014.2172.5.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:53:45 -0000 On Sun, 2008-07-20 at 01:33 +0300, Giorgos Keramidas wrote: > On Sat, 19 Jul 2008 17:03:08 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > > On Thu, 2008-07-17 at 21:20 +0300, Giorgos Keramidas wrote: > >> After booting with the APIC enabled, I found out that: > >> > >> * In single user mode, after `boot -sv', I can keep working without > >> any major slow down. > >> > >> * When I exit single user mode, and a few of the rc.d startup scripts > >> run, the laptop becomes progressively slower, and eventually crawls > >> to an unusable state. I can almost complete logging in as `root' in > >> ttyv0 but only if I keep furiously moving the mouse around. If I > >> don't move the mouse at all, the typed characters may never actually > >> appear on ttyv0. > > > > Are you by any chance using cx_lowest="C3" (or "LOW") in your rc.conf? I > > have seen these symptoms (including mouse inducement of the typed > > characters) when cpu0 on my laptop went to C3. Nowadays I have C3 on > > cpu1 and C2 on cpu0 and life is good. Then again, I am running RELENG_7 > > (which AFAICR was 7-CURRENT at the time), so YMMV. > > Ah, good point. I have indeed performance_cx_lowest="LOW" in rc.conf. > > I'll remove that and try again with the APIC enabled... > And here is more verbose description of what I have experienced, so you can decide for yourself, whether is is similar or not: http://www.freebsd.org/cgi/getmsg.cgi?fetch=90726+93671 +/usr/local/www/db/text/2008/freebsd-acpi/20080224.freebsd-acpi -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:54:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30321065670; Sat, 19 Jul 2008 22:54:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8C48FC0A; Sat, 19 Jul 2008 22:54:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6JMsjg6080066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Jul 2008 00:54:45 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMsbJt068315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 00:54:38 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6JMsb2q052750; Sun, 20 Jul 2008 00:54:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6JMsaCq052749; Sun, 20 Jul 2008 00:54:36 +0200 (CEST) (envelope-from ticso) Date: Sun, 20 Jul 2008 00:54:36 +0200 From: Bernd Walter To: mouss Message-ID: <20080719225435.GN35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <48820259.3060007@quip.cz> <20080719153530.GL35340@cicely7.cicely.de> <488230CD.6000906@netoyen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488230CD.6000906@netoyen.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.139, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Doug Barton , David Naylor , ticso@cicely.de, freebsd-current@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:54:49 -0000 On Sat, Jul 19, 2008 at 08:22:05PM +0200, mouss wrote: > Bernd Walter wrote: > >On Sat, Jul 19, 2008 at 05:03:53PM +0200, Miroslav Lachman wrote: > >>Bernd Walter wrote: > >> > >>[...] > >> > >>>Speaking about small systems, where startup time is more a problem than > >>>on 08/15 desktop and server systems. > >>>What I would love to see is that scripts like moused, ypserv, lpt, etc > >>>are not started if the services are disabled. > >>>So far each script is started, sucks in routines plus rc.conf then > >>>possibly does nothing reasonable after wasting some seconds boottime. > >>>Of course I can remove the scripts, but you'll never know if you need > >>>one of them at a later time and having the right set of scripts can > >>>become tricky. > >>And what about just chmod unneeded scripts to become not executable / > >>readable instead of removing? > >>(I like the current "one directory" layout instead of some linuxism with > >>many directories and symlinks) > > > >This and all the ideas about using enable/disable directories or > >softlinks share a major problem: > >They requires configuring outside of rc.conf, which is not what I want. > >Of course I can do: > >mkdir /etc/rc.d/disabled ; mv /etc/rc.d/moused /etc/rc.d/disabled > >But then I would loose the ability to configure everything with rc.conf. > >A tool, which parses rc.conf and automatically relocates might be an > >option, but it would be better if it can be done without. > > > > > how about a cache mechanism: rcorder/rc would use a previously > determined order unless something changed in rc.conf or rc.d. > > this way you don't need to determine which scripts need to run and in > which order every time the system boots. this also removes the need for > an "active.d" directory. Sounds good, but I think the problem is that rc.conf is a script and that some people do smart rc.conf settings e.g. by loader settings to allow their notebooks to boot differently. That of course also invalidaes my idea with the tool above. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 22:57:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07CD3106567B for ; Sat, 19 Jul 2008 22:57:23 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id C1B0E8FC15 for ; Sat, 19 Jul 2008 22:57:22 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so265070ywe.13 for ; Sat, 19 Jul 2008 15:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=F3YUB/c3FN7d8H0tMn+g8Ltqowm6b46xa96Wlat3Lwk=; b=HaCwce/hyovSuy5JFgRSPWgoWscjGA6XQnoLUj0d6ZYgq5wo1s34n/uKrDhVGpC3Uf u/9C/v7Yu8jbdQabB6maUTaSg2zAImPXslRTzlFBQ6C7F2G64OBwWnseD4Eu9NO0ZcPF 7qHjvglifVXQer62DKqWRpLJOBKIkYOE4dy38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=I38U5tu8o1tdsQgPqDCb8PYFs8x1P5ddhJQPBhbWdPu0ZZpVks+V9rcOuBn2iODVv4 pt0VA26dPnJs00meX2LTZaeibnN0j9ns/KEQDjQqanbOji/cJwAPFAa0aFwbtZvLruF+ iDvXYjmSQoMPDT91OkVWNxfAPg63RX7A0NX/E= Received: by 10.150.134.21 with SMTP id h21mr1887518ybd.135.1216508241146; Sat, 19 Jul 2008 15:57:21 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.22.162]) by mx.google.com with ESMTPS id 4sm634272yxj.7.2008.07.19.15.57.20 (version=SSLv3 cipher=RC4-MD5); Sat, 19 Jul 2008 15:57:20 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Giorgos Keramidas In-Reply-To: <87tzelebd7.fsf@kobe.laptop> References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> <87tzelebd7.fsf@kobe.laptop> Content-Type: text/plain; charset=utf-8 Date: Sat, 19 Jul 2008 18:57:10 -0400 Message-Id: <1216508230.2172.8.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 22:57:23 -0000 On Sun, 2008-07-20 at 01:51 +0300, Giorgos Keramidas wrote: > On Sun, 20 Jul 2008 01:33:30 +0300, Giorgos Keramidas wrote: > > On Sat, 19 Jul 2008 17:03:08 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > >> Are you by any chance using cx_lowest="C3" (or "LOW") in your > >> rc.conf? I have seen these symptoms (including mouse inducement of > >> the typed characters) when cpu0 on my laptop went to C3. Nowadays I > >> have C3 on cpu1 and C2 on cpu0 and life is good. Then again, I am > >> running RELENG_7 (which AFAICR was 7-CURRENT at the time), so YMMV. > > > > Ah, good point. I have indeed performance_cx_lowest="LOW" in rc.conf. > > > > I'll remove that and try again with the APIC enabled... > > That was it. Thanks! > > # sysctl -a | egrep -e 'cx_(usage|support)' > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% > > With anything except "C1" the CPU is obviously too slow to do anything > useful :-) > I guess it got worse in CURRENT: # uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 9 16:52:35 EDT 2008 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 RabbitsDen# sysctl -a | egrep -e 'cx_(usage|support)' dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_usage: 0.00% 4.43% 95.56% -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 23:41:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81393106564A for ; Sat, 19 Jul 2008 23:41:58 +0000 (UTC) (envelope-from snb@moduli.net) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 366D58FC0C for ; Sat, 19 Jul 2008 23:41:57 +0000 (UTC) (envelope-from snb@moduli.net) Received: by fg-out-1718.google.com with SMTP id l26so529967fgb.35 for ; Sat, 19 Jul 2008 16:41:57 -0700 (PDT) Received: by 10.103.239.10 with SMTP id q10mr1360528mur.82.1216509283529; Sat, 19 Jul 2008 16:14:43 -0700 (PDT) Received: by 10.102.228.7 with HTTP; Sat, 19 Jul 2008 16:14:43 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 01:14:43 +0200 From: "Nick Barkas" Sender: snb@moduli.net To: "Rainer Duffner" In-Reply-To: <486CEEF1.9040702@ultra-secure.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <784966050807021123l267aa20en39eb513c12c90ad2@mail.gmail.com> <20080702235800.H47773@fledge.watson.org> <486C8700.5020100@lobraun.de> <486CEEF1.9040702@ultra-secure.de> X-Google-Sender-Auth: e3d1ffdf6705f082 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sysinstall is still inadequate after all of these years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2008 23:41:58 -0000 On Thu, Jul 3, 2008 at 5:23 PM, Rainer Duffner wrote: > Mass-installation via PXE-booting is a mess (how can you have to pack the > install.cfg file into the mfsroot diskimage???). I have done some work on a tool for rapidly imaging many FreeBSD systems and a set of packages using PXE booting: http://code.google.com/p/farbot/. Farbot uses sysinstall, so it does automatically do things like generating an install.cfg file and putting it into an mfsroot. But I'm definitely also looking forward to a new installer, and hoping it will be easy to control programmatically. Nick From owner-freebsd-current@FreeBSD.ORG Sat Jul 19 23:57:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51128106564A for ; Sat, 19 Jul 2008 23:57:43 +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 D4F168FC0A for ; Sat, 19 Jul 2008 23:57:42 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl133-207.kln.forthnet.gr [77.49.252.207]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6JNvTUg030368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 02:57:35 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6JNvT9N002427; Sun, 20 Jul 2008 02:57:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6JNvSYD002426; Sun, 20 Jul 2008 02:57:28 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Alexandre \"Sunny\" Kovalenko" References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> <87tzelebd7.fsf@kobe.laptop> <1216508230.2172.8.camel@RabbitsDen> Date: Sun, 20 Jul 2008 02:57:27 +0300 In-Reply-To: <1216508230.2172.8.camel@RabbitsDen> (Alexandre Kovalenko's message of "Sat, 19 Jul 2008 18:57:10 -0400") Message-ID: <87iqv1h1g8.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6JNvTUg030368 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.787, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 23:57:43 -0000 On Sat, 19 Jul 2008 18:57:10 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > On Sun, 2008-07-20 at 01:51 +0300, Giorgos Keramidas wrote: >> That was it. Thanks! >> >> # sysctl -a | egrep -e 'cx_(usage|support)' >> dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 >> dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% >> dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 >> dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% >> >> With anything except "C1" the CPU is obviously too slow to do >> anything useful :-) > > I guess it got worse in CURRENT: > > # uname -a > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.0-STABLE FreeBSD 7.0-STABLE > #0: Wed Jul 9 16:52:35 EDT 2008 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > RabbitsDen# sysctl -a | egrep -e 'cx_(usage|support)' > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_usage: 0.00% 4.43% 95.56% Now that I know what to look for, I see that what is reported in cx_supported is an array from the `struct acpi_cpu_softc' for each cpu. The initialization of per-cpu dev.cpu.*.cx_xxx values in the softc of the cpu is done in sys/dev/acpica/acpi_cpu.c:acpi_cpu_cx_cst(). I am probably not qualified to say if 'things got worse' in CURRENT, but I wish there was a way to find out *before* entering a state where the CPU is too slow to do basic tasks (i.e. time keeping, and scheduling processes).