From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 00:28:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7811116A4CE for ; Sun, 10 Oct 2004 00:28:26 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 4777443D55 for ; Sun, 10 Oct 2004 00:28:26 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 42378 invoked by uid 113); 9 Oct 2004 17:28:24 -0700 Received: from 64.62.253.84 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(64.62.253.84):SA:0(0.0/6.0):. Processed in 1.596876 secs); 10 Oct 2004 00:28:24 -0000 X-Spam-Status: No, hits=0.0 required=6.0 Received: from unknown (HELO miha.netstream-gh.com) (miha@beer.ux6.net@64.62.253.84) by localhost with SMTP; 9 Oct 2004 17:28:22 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Sun, 10 Oct 2004 00:29:05 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> In-Reply-To: Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410100029.05533.miha@ghuug.org> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 00:28:26 -0000 On Saturday 09 October 2004 20:53, Dag-Erling Sm=F8rgrav wrote: > "Mikhail P." writes: > > Well, there is no pattern. [...] > > Could be bad cables, could be bad drives. Environmental factors are a > more likely cause, though. Are all the failing disks in the same > machine? If they're in separate machines, are those rack-mount, or > are they standing on a table or shelf? If a shelf, what kind? What's > the ambient temperature in the machine room? Could be cables - I will get a replacement to verify that. I'm less sure it= is=20 drives. Yes, all 4 drives were in the same machine. Machine is a regular 2U rackmount chassis (one CPU), with proper airflow. E= ach=20 drive has its individual aluminum fan as well. Chassis sits in a 47U cabine= t,=20 datacenter environment, with lots of free space around. So I'm quite sure i= t=20 is not cooling/dust issues.. Well, unfortunately, I don't have access to hardware myself, so I can't do = any=20 hardware related tasks. As said, I will get those two drives shipped to me,= =20 and will then see myself if it is really hdd issue, or something else.. > > DES regards, M. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 08:59:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0516616A4CE for ; Sun, 10 Oct 2004 08:59:37 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A57343D1F for ; Sun, 10 Oct 2004 08:59:36 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i9A8xVRV063352; Sun, 10 Oct 2004 10:59:34 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4168F9E7.9040408@DeepCore.dk> Date: Sun, 10 Oct 2004 10:59:19 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: miha@ghuug.org References: <200410081937.15068.miha@ghuug.org> <41682D3F.4060902@DeepCore.dk> <200410091843.06854.miha@ghuug.org> In-Reply-To: <200410091843.06854.miha@ghuug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-hackers@freebsd.org Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 08:59:37 -0000 Mikhail P. wrote: > On Saturday 09 October 2004 18:26, S=F8ren Schmidt wrote: >=20 >>Hmm, that means that the drive couldn't find the sector you asked for. >>Now, what has me wondering is that it is the exact sector where we >>switch to 48bit adressing mode. Anyhow, I've just checked on the old >>Maxtor preproduktion 48bit reference drive I have here and it crosses >>the limit with no problems. >>What controller are you using ? not all supports 48bit mode correctly..= >=20 >=20 > There's VIA's motherboard (not sure about the model name). >=20 > Here's info regarding ata controller from dmesg: > atapci0: port 0xac00-0xac0f at device 17.= 1 on=20 > pci0 >=20 > I will be able to test the drives (the ones which I thought of as "fail= ed") on=20 > another board within 10 days or so. There is definitly something fishy here, since I dont have either the=20 disks nor any VIA chips here in the lab I cannot do any testing here. However I dont know of any problems with the VIA chips in this regard,=20 so that leaves the disks for scrutiny. One thing to try is change the=20 tripping point where we switch from 28bit mode to 48 bit mode, could be=20 a 1 off error in the firmware... -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 23:29:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9459716A4CE for ; Sun, 10 Oct 2004 23:29:40 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 64C1943D1F for ; Sun, 10 Oct 2004 23:29:40 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 25690 invoked by uid 113); 10 Oct 2004 16:29:40 -0700 Received: from 64.62.253.84 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(64.62.253.84):SA:0(0.3/6.0):. Processed in 0.562703 secs); 10 Oct 2004 23:29:40 -0000 X-Spam-Status: No, hits=0.3 required=6.0 Received: from unknown (HELO miha.netstream-gh.com) (miha@beer.ux6.net@64.62.253.84) by localhost with SMTP; 10 Oct 2004 16:29:39 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Sun, 10 Oct 2004 23:30:26 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> In-Reply-To: <200410091701.01987.miha@ghuug.org> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410102330.26228.miha@ghuug.org> Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 23:29:40 -0000 On Saturday 09 October 2004 17:01, Mikhail P. wrote: > I also got another message off-list, where author suggested to play with > UDMA values. I switched from UDMA100 to UDMA66. System's uptime is 12 > hours, and no timeouts so far.. but I'm quite sure they will get back in > few days. 1.5 days of uptime, running in UDMA66 changes nothing. Still getting ad0: FAILURE - READ_DMA status=51 error=10 LBA=268435455 ad0: FAILURE - READ_DMA status=51 error=10 LBA=268435455 regards, M. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 10 23:48:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B919416A4CE for ; Sun, 10 Oct 2004 23:48:29 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F9F243D49 for ; Sun, 10 Oct 2004 23:48:29 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id i9ANmHBj020354; Sun, 10 Oct 2004 16:48:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Oct 2004 16:48:17 -0700 Message-ID: <00CDF9AA240E204FA6E923BD35BC643606BF695A@bcs-mail.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bit field definition ? Thread-Index: AcSto0HA7MChXlkPSNiy3UudDGqXrQBfoNag From: "Li, Qing" To: "Dan Nelson" X-Scanned-By: MIMEDefang 2.44 cc: freebsd-hackers@freebsd.org Subject: RE: Bit field definition ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 23:48:29 -0000 >=20 > In the last episode (Oct 08), Li, Qing said: > > The bit fields "th_x2" and "th_off" in "struct tcphdr", > > even though defined as "u_int", actually occupies 1 byte. >=20 > u_int th_x2:4, /* (unused) */ > th_off:4; /* data offset */ >=20 > The :4 after each variable means 4 bits long, so both fields=20 > together take up 8 bits =3D 1 byte. That's the whole purpose=20 > of bitfields :) >=20 =09 D'oh I didn't ask the right question. It seems u_int specifies the packing and alignment size for the bit fields, is that correct ? struct { u_int a:4, =20 b:4; }; is 4 bytes in size. struct { u_int a:4, b:4; short c; }; is 4 bytes in size. struct { u_int a:4, b:4; short c; u_char d; }; is 8 bytes in size; But struct { u_int a:4, b:4; u_char d; short c; }; is 4 bytes in size; -- Qing From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 03:21:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD35716A4CE for ; Mon, 11 Oct 2004 03:21:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F4543D3F for ; Mon, 11 Oct 2004 03:21:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i9B3LKeV007283; Sun, 10 Oct 2004 22:21:20 -0500 (CDT) (envelope-from dan) Date: Sun, 10 Oct 2004 22:21:20 -0500 From: Dan Nelson To: "Li, Qing" Message-ID: <20041011032120.GA10108@dan.emsphone.com> References: <00CDF9AA240E204FA6E923BD35BC643606BF695A@bcs-mail.internal.cacheflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00CDF9AA240E204FA6E923BD35BC643606BF695A@bcs-mail.internal.cacheflow.com> X-OS: FreeBSD 5.3-BETA7 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: Bit field definition ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 03:21:47 -0000 In the last episode (Oct 10), Li, Qing said: > > In the last episode (Oct 08), Li, Qing said: > > > The bit fields "th_x2" and "th_off" in "struct tcphdr", even > > > though defined as "u_int", actually occupies 1 byte. > > > > u_int th_x2:4, /* (unused) */ > > th_off:4; /* data offset */ > > > > The :4 after each variable means 4 bits long, so both fields > > together take up 8 bits = 1 byte. That's the whole purpose of > > bitfields :) > > D'oh > > I didn't ask the right question. > > It seems u_int specifies the packing and alignment size > for the bit fields, is that correct ? I don't think so. C99 only allows bitfields to be of type Bool, signed _int, or unsigned int, so that seems to prevent the use of char/short/int/long to dictate padding or alignment. There must be something in the FreeBSD ABI that says structs must be padded so they are 4-byte aligned, even if none of the members require it. Try putting your 4 structs into a program and compiling them with gcc -Wpadding: > struct { > u_int a:4, > b:4; > }; is 4 bytes in size. a.c:7: warning: padding struct size to alignment boundary > struct { > u_int a:4, > b:4; > short c; > }; is 4 bytes in size. a.c:13: warning: padding struct to align 'c' (1 byte of padding added just before c) > struct { > u_int a:4, > b:4; > short c; > u_char d; > }; is 8 bytes in size; a.c:19: warning: padding struct to align 'c' (1 byte padding just before c, and 3 bytes just after d). I think it should have printed a "padding struct size to alignment boundary" warning also, since if it didn't, the padding after d would have been 1 byte, and struct would have been 6 bytes total. > But > > struct { > u_int a:4, > b:4; > u_char d; > short c; > }; is 4 bytes in size; > a.c:21: warning: padding struct size to alignment boundary This last warning I don't understand, since 1+1+2 is 4 all by itself. No padding is needed or used. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 06:54:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08A5916A4CE for ; Mon, 11 Oct 2004 06:54:21 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B96943D53 for ; Mon, 11 Oct 2004 06:54:20 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i9B6sAU572752; Mon, 11 Oct 2004 08:54:10 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i9B6sAI64452; Mon, 11 Oct 2004 08:54:10 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i9B6s8e07491; Mon, 11 Oct 2004 08:54:08 +0200 (MET DST) Date: Mon, 11 Oct 2004 08:54:13 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Mike Hunter In-Reply-To: <20041008161442.GA9862@ack.Berkeley.EDU> Message-ID: <20041011084925.N25731@beagle.kn.op.dlr.de> References: <20041005054213.GA11770@lesanti.hq.sinectis.com.ar> <20041005202816.GA14973@titan.klemm.apsfilter.org> <20041005205040.GH31397@lesanti.hq.sinectis.com.ar> <20041006060437.GA23364@titan.klemm.apsfilter.org> <416579E1.8050308@nuclearelephant.com> <20041008173138.Y14215@beagle.kn.op.dlr.de> <20041008161442.GA9862@ack.Berkeley.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: please help with: warning: initialization makes integer from pointer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 06:54:21 -0000 On Fri, 8 Oct 2004, Mike Hunter wrote: MH>On Oct 08, "Harti Brandt" wrote: MH> MH>> On Fri, 8 Oct 2004, Dan Nelson wrote: MH>> MH>> Memset is actually not portable if the structure contains pointers because MH>> it would initialize the pointers to 0 values not to 0 pointers. A 0 MH>> pointer not necessarily has a 0 value. A pointer can be portably be MH>> initialize to the 0-pointer only by assigning NULL (or 0) (or by assigning MH>> another pointer that is alreay initialized). MH> MH>Sick! MH> MH>Are there actually systems out there that don't have "all-zero" NULL pointers? If you ask this question on comp.std.c I'm sure you'll get a number of positive answers, but be prepared to start a _long_ thread :-) harti From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 13:10:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A51116A4CE for ; Mon, 11 Oct 2004 13:10:46 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FBE643D39 for ; Mon, 11 Oct 2004 13:10:46 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from imp1-q.free.fr (imp1-q.free.fr [212.27.42.1]) by postfix4-1.free.fr (Postfix) with ESMTP id 8C9F6182794; Mon, 11 Oct 2004 15:10:45 +0200 (CEST) Received: by imp1-q.free.fr (Postfix, from userid 33) id 809EB36F24; Mon, 11 Oct 2004 15:10:45 +0200 (MEST) Received: from ubac.inrialpes.fr (ubac.inrialpes.fr [194.199.23.66]) by imp1-q.free.fr (IMP) with HTTP for ; Mon, 11 Oct 2004 15:10:45 +0200 Message-ID: <1097500245.416a86556c692@imp1-q.free.fr> Date: Mon, 11 Oct 2004 15:10:45 +0200 From: damien.bergamini@free.fr To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 194.199.23.66 cc: damien.bergamini@free.fr Subject: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 13:10:46 -0000 msleep(9) behaves strangely with recursed mutexes. In the attached code, calling foo_f() will make the kernel hang for two seconds. It seems like msleep does not release the mtx mutex completely but simply decrement its reference count by one. When calling msleep, the mtx mutex is still held which prevent the interrupt from happening. msleep will then return error code EWOULDBLOCK after two seconds. If I remove calls to mtx_lock/unlock from function foo_g(), it works without problem but this is not a solution since foo_g() can be called outside of function foo_f(). Of course, the mtx mutex was created with the MTX_RECURSE flag set. Is it an expected behaviour? In msleep(9) it is said: "The msleep() function is a variation on tsleep. The parameter mtx is a mutex which will be released before sleeping and reacquired before msleep() returns." Seems like the mutex is not *really* released if it recurses. Thanks, Damien Bergamini ---- void foo_intr(void *arg) { struct foo_softc *sc = arg; mtx_lock(&sc->mtx); ... wakeup(sc); ... mtx_unlock(&sc->mtx); } void foo_f(struct foo_softc *sc) { mtx_lock(&sc->mtx); ... foo_g(sc); ... mtx_unlock(&sc->mtx); } void foo_g(struct foo_softc *sc) { /* mtx will recurse if called from foo_f() */ mtx_lock(&sc->mtx); ... /* do something that will make hardware raise an interrupt */ ... /* wait at most 2 second for the interrupt */ msleep(sc, &sc->mtx, 0, "foo", 2 * hz); ... mtx_unlock(&sc->mtx); } From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 13:48:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE4FB16A4CE for ; Mon, 11 Oct 2004 13:48:16 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B25C43D49 for ; Mon, 11 Oct 2004 13:48:16 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i9BDlqS2029370; Mon, 11 Oct 2004 09:47:52 -0400 (EDT) Date: Mon, 11 Oct 2004 09:47:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: damien.bergamini@free.fr In-Reply-To: <1097500245.416a86556c692@imp1-q.free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-hackers@freebsd.org Subject: Re: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 13:48:16 -0000 On Mon, 11 Oct 2004 damien.bergamini@free.fr wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its reference count by one. When calling msleep, the > mtx mutex is still held which prevent the interrupt from happening. > msleep will then return error code EWOULDBLOCK after two seconds. > If I remove calls to mtx_lock/unlock from function foo_g(), it works > without problem but this is not a solution since foo_g() can be > called outside of function foo_f(). > Of course, the mtx mutex was created with the MTX_RECURSE flag set. First, don't use recursive mutexes -- they are (for now) a necessary evil. > Is it an expected behaviour? In msleep(9) it is said: > "The msleep() function is a variation on tsleep. The parameter mtx > is a mutex which will be released before sleeping and reacquired > before msleep() returns." > > Seems like the mutex is not *really* released if it recurses. Only one thread can take and own a recursive mutex, not multiple threads. An interrupt occurs in a different thread, so it cannot lock a mutex that it doesn't own. As you suggest, the only way this could work is if msleep() set the recurse count to zero and restored it back to its original value once it was awoken. I think it's great (a feature) that the use of recursive mutexes breaks when used with interrupts! Really, you want to be using condition variables. Use a mutex to protect your data and use cv_{timed}wait{_sig}() to sleep. When the interrupt occurs, you use cv_signal() or cv_broadcast() to wake up any waiters. -- DE From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 15:27:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0C6D16A4CF for ; Mon, 11 Oct 2004 15:27:05 +0000 (GMT) Received: from mailfe03.swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E03A43D48 for ; Mon, 11 Oct 2004 15:27:04 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: VsDWwZe7A/2Wcdm6dSyOxw== Received: from [193.216.43.160] (HELO curly.tele2.no) by mailfe03.swip.net (CommuniGate Pro SMTP 4.2.4) with ESMTP id 190716618; Mon, 11 Oct 2004 17:27:02 +0200 Received: (from root@localhost) by curly.tele2.no (8.12.5/8.12.3) id i9BFUjOg000950; Mon, 11 Oct 2004 17:30:45 +0200 (CEST) (envelope-from hselasky@c2i.net) Date: Mon, 11 Oct 2004 17:30:43 +0200 From: Hans Petter Selasky To: damien.bergamini@free.fr Message-ID: <20041011173042.B744@curly.tele2.no> References: <1097500245.416a86556c692@imp1-q.free.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1097500245.416a86556c692@imp1-q.free.fr>; from damien.bergamini@free.fr on Mon, Oct 11, 2004 at 03:10:45PM +0200 cc: freebsd-hackers@freebsd.org Subject: Re: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 15:27:05 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 11, 2004 at 03:10:45PM +0200, damien.bergamini@free.fr wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its reference count by one. When calling msleep, the > mtx mutex is still held which prevent the interrupt from happening. > msleep will then return error code EWOULDBLOCK after two seconds. > If I remove calls to mtx_lock/unlock from function foo_g(), it works > without problem but this is not a solution since foo_g() can be > called outside of function foo_f(). > Of course, the mtx mutex was created with the MTX_RECURSE flag set. > > Is it an expected behaviour? In msleep(9) it is said: > "The msleep() function is a variation on tsleep. The parameter mtx > is a mutex which will be released before sleeping and reacquired > before msleep() returns." > > Seems like the mutex is not *really* released if it recurses. > Only the "Giant" mutex is released if it recurses. By the way there is a bug in msleep: mtx_lock(&Giant); msleep(xxx, &Giant, 0, "foo", 0); mtx_unlock(&Giant); doesn't work. See attached patch. > > Thanks, > Damien Bergamini > > ---- > > void foo_intr(void *arg) > { > struct foo_softc *sc = arg; > > mtx_lock(&sc->mtx); > ... > wakeup(sc); > ... > mtx_unlock(&sc->mtx); > } > > void foo_f(struct foo_softc *sc) > { > mtx_lock(&sc->mtx); > ... > foo_g(sc); > ... > mtx_unlock(&sc->mtx); > } > > void foo_g(struct foo_softc *sc) > { > /* mtx will recurse if called from foo_f() */ > mtx_lock(&sc->mtx); > ... > /* do something that will make hardware raise an interrupt */ > ... > /* wait at most 2 second for the interrupt */ > msleep(sc, &sc->mtx, 0, "foo", 2 * hz); > ... > mtx_unlock(&sc->mtx); > } -HPS --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern_synch.c.diff" *** src/sys/kern/kern_synch.c.ref Wed Sep 29 14:21:09 2004 --- src/sys/kern/kern_synch.c Wed Sep 29 14:22:25 2004 *************** *** 182,193 **** CTR5(KTR_PROC, "msleep: thread %p (pid %ld, %s) on %s (%p)", (void *)td, (long)p->p_pid, p->p_comm, wmesg, ident); - DROP_GIANT(); if (mtx != NULL) { mtx_assert(mtx, MA_OWNED | MA_NOTRECURSED); WITNESS_SAVE(&mtx->mtx_object, mtx); mtx_unlock(mtx); } /* * We put ourselves on the sleep queue and start our timeout --- 182,194 ---- CTR5(KTR_PROC, "msleep: thread %p (pid %ld, %s) on %s (%p)", (void *)td, (long)p->p_pid, p->p_comm, wmesg, ident); if (mtx != NULL) { mtx_assert(mtx, MA_OWNED | MA_NOTRECURSED); WITNESS_SAVE(&mtx->mtx_object, mtx); mtx_unlock(mtx); } + /* drop Giant after mtx in case mtx == &Giant */ + DROP_GIANT(); /* * We put ourselves on the sleep queue and start our timeout --gBBFr7Ir9EOA20Yy-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 16:57:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8575416A4CE; Mon, 11 Oct 2004 16:57:01 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5050543D2D; Mon, 11 Oct 2004 16:57:01 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from COMETE (pasteur-1-82-67-68-158.fbx.proxad.net [82.67.68.158]) by postfix4-1.free.fr (Postfix) with SMTP id 586151F31FD; Mon, 11 Oct 2004 18:57:00 +0200 (CEST) Message-ID: <008401c4afb3$353f8aa0$9e444352@COMETE> From: "Damien Bergamini" To: "Daniel Eischen" References: Date: Mon, 11 Oct 2004 18:56:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-hackers@freebsd.org Subject: Re: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 16:57:01 -0000 Thanks for your answer. I'll try your solution with condition variables and I'll let you know about the results. What I really want to do is quite simple: avoid wakeup_before_sleep conditions. -- Damien Bergamini | Really, you want to be using condition variables. Use a mutex | to protect your data and use cv_{timed}wait{_sig}() to sleep. | When the interrupt occurs, you use cv_signal() or cv_broadcast() | to wake up any waiters. | | -- | DE From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 18:48:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B409016A4CE for ; Mon, 11 Oct 2004 18:48:06 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A8BE43D1D for ; Mon, 11 Oct 2004 18:48:06 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id 465273A203; Mon, 11 Oct 2004 11:48:06 -0700 (PDT) Date: Mon, 11 Oct 2004 11:48:06 -0700 From: Ulf Zimmermann To: hackers@freebsd.org Message-ID: <20041011184805.GX66377@seven.alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 Subject: openssh problem after going from 5.2.1 to 5.3-beta7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 18:48:06 -0000 I have a HP DL380g3 I was running 5.2.1-REL on (I think it was on -p9). I did a source upgrade to 5.3-beta7, including mergemaster -p, followed by mergemaster which did upgrade /etc/ssh/sshd_config. When I am now trying to connect from SecureCRT, I get: SecureCRT has disconnected from the server. Reason: Unable to authenticate using any of the configured authentication methods. Using ssh from another machine (in this case 4.10-p2) works correctly. Here is a "-d -p 23" output to capture debug: evil root /var/log # sshd -d -p 23 debug1: sshd version OpenSSH_3.8.1p1 FreeBSD-20040419 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: Bind to port 23 on ::. Server listening on :: port 23. debug1: Bind to port 23 on 0.0.0.0. Server listening on 0.0.0.0 port 23. debug1: Server will not fork when running in debugging mode. debug1: res_init() Connection from 172.18.42.241 port 4340 debug1: Client protocol version 2.0; client software version SecureCRT_4.1.7 (build 257) SecureCRT debug1: no match: SecureCRT_4.1.7 (build 257) SecureCRT debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user ulf service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "ulf" Failed none for ulf from 172.18.42.241 port 4340 ssh2 debug1: PAM: setting PAM_RHOST to "172.18.42.241" Received disconnect from 172.18.42.241: 14: Unable to authenticate using any of the configured authentication methods. debug1: do_cleanup debug1: PAM: cleanup debug1: do_cleanup debug1: PAM: cleanup SecureCRT profile is protocol ssh2, authentication password (which was saved, I unsaved it, it never prompts for password). SSH2 config is no compression, Cipher AES-128, AES-192, AES-256, Twofish, Blowfish, 3DES and RC4. MAC is MD5, SHA1, SHA1-96 and MD5-96. SSH server is set to autodetect, selecting another server doesn't change it. Anyone have an idea what the problem might be? -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 18:49:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44DB216A4CE for ; Mon, 11 Oct 2004 18:49:14 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A7543D48 for ; Mon, 11 Oct 2004 18:49:14 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id D521B3A203; Mon, 11 Oct 2004 11:49:10 -0700 (PDT) Date: Mon, 11 Oct 2004 11:49:10 -0700 From: Ulf Zimmermann To: Ulf Zimmermann Message-ID: <20041011184910.GY66377@seven.alameda.net> References: <20041011184805.GX66377@seven.alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041011184805.GX66377@seven.alameda.net> User-Agent: Mutt/1.4.2.1i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 cc: hackers@freebsd.org Subject: Re: openssh problem after going from 5.2.1 to 5.3-beta7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 18:49:14 -0000 Never mind, /usr/src/UPDATING: 20040226: Some sshd configuration defaults have changed: protocol version 1 is no longer enabled by default, and password authentication is disabled by default if PAM is enabled (which it is by default). OpenSSH clients should not be affected by this; other clients may have to be reconfigured, upgraded or replaced. On Mon, Oct 11, 2004 at 11:48:06AM -0700, Ulf Zimmermann wrote: > I have a HP DL380g3 I was running 5.2.1-REL on (I think it was on -p9). > I did a source upgrade to 5.3-beta7, including mergemaster -p, followed > by mergemaster which did upgrade /etc/ssh/sshd_config. > > When I am now trying to connect from SecureCRT, I get: > > SecureCRT has disconnected from the server. Reason: Unable to authenticate > using any of the configured authentication methods. > > Using ssh from another machine (in this case 4.10-p2) works correctly. > Here is a "-d -p 23" output to capture debug: > > evil root /var/log # sshd -d -p 23 > debug1: sshd version OpenSSH_3.8.1p1 FreeBSD-20040419 > debug1: read PEM private key done: type DSA > debug1: private host key: #0 type 2 DSA > debug1: Bind to port 23 on ::. > Server listening on :: port 23. > debug1: Bind to port 23 on 0.0.0.0. > Server listening on 0.0.0.0 port 23. > debug1: Server will not fork when running in debugging mode. > debug1: res_init() > Connection from 172.18.42.241 port 4340 > debug1: Client protocol version 2.0; client software version SecureCRT_4.1.7 (build 257) SecureCRT > debug1: no match: SecureCRT_4.1.7 (build 257) SecureCRT > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419 > debug1: permanently_set_uid: 22/22 > debug1: list_hostkey_types: ssh-dss > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user ulf service ssh-connection method none > debug1: attempt 0 failures 0 > debug1: PAM: initializing for "ulf" > Failed none for ulf from 172.18.42.241 port 4340 ssh2 > debug1: PAM: setting PAM_RHOST to "172.18.42.241" > Received disconnect from 172.18.42.241: 14: Unable to authenticate using any of the configured authentication methods. > debug1: do_cleanup > debug1: PAM: cleanup > debug1: do_cleanup > debug1: PAM: cleanup > > SecureCRT profile is protocol ssh2, authentication password (which > was saved, I unsaved it, it never prompts for password). SSH2 config > is no compression, Cipher AES-128, AES-192, AES-256, Twofish, Blowfish, > 3DES and RC4. MAC is MD5, SHA1, SHA1-96 and MD5-96. SSH server is set > to autodetect, selecting another server doesn't change it. > > Anyone have an idea what the problem might be? > > -- > Regards, Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 > You can find my resume at: http://seven.Alameda.net/~ulf/resume.html > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 21:27:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 318EF16A4CE for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A19743D3F for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20750 invoked from network); 11 Oct 2004 21:27:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Oct 2004 21:27:23 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9BLRH6P042482; Mon, 11 Oct 2004 17:27:19 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 11 Oct 2004 14:57:17 -0400 User-Agent: KMail/1.6.2 References: <1097500245.416a86556c692@imp1-q.free.fr> In-Reply-To: <1097500245.416a86556c692@imp1-q.free.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410111457.17529.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: damien.bergamini@free.fr Subject: Re: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 21:27:24 -0000 On Monday 11 October 2004 09:10 am, damien.bergamini@free.fr wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its reference count by one. When calling msleep, the > mtx mutex is still held which prevent the interrupt from happening. > msleep will then return error code EWOULDBLOCK after two seconds. > If I remove calls to mtx_lock/unlock from function foo_g(), it works > without problem but this is not a solution since foo_g() can be > called outside of function foo_f(). > Of course, the mtx mutex was created with the MTX_RECURSE flag set. This is a feature. If you had INVARIANTS on you would get a panic here: if (mtx != NULL) { mtx_assert(mtx, MA_OWNED | MA_NOTRECURSED); WITNESS_SAVE(&mtx->mtx_object, mtx); mtx_unlock(mtx); } When developing kernel code it is highly recommended that you run with INVARIANTS and INVARIANT_SUPPORT turned on. You should probably have your foo_g() function assert that the lock is held and fix all the callers. Either that or add a wrapper around foo_g() for the callers that don't call with the mutex locked. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 21:27:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBC2916A4CE for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9354043D3F for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19815 invoked from network); 11 Oct 2004 21:27:21 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Oct 2004 21:27:21 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9BLRH6O042482; Mon, 11 Oct 2004 17:27:17 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 11 Oct 2004 14:55:16 -0400 User-Agent: KMail/1.6.2 References: <1097500245.416a86556c692@imp1-q.free.fr> <20041011173042.B744@curly.tele2.no> In-Reply-To: <20041011173042.B744@curly.tele2.no> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410111455.16920.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: damien.bergamini@free.fr cc: Hans Petter Selasky Subject: Re: msleep(9) and recursed mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 21:27:24 -0000 On Monday 11 October 2004 11:30 am, Hans Petter Selasky wrote: > On Mon, Oct 11, 2004 at 03:10:45PM +0200, damien.bergamini@free.fr wrote: > > msleep(9) behaves strangely with recursed mutexes. > > In the attached code, calling foo_f() will make the kernel hang for > > two seconds. > > It seems like msleep does not release the mtx mutex completely but > > simply decrement its reference count by one. When calling msleep, the > > mtx mutex is still held which prevent the interrupt from happening. > > msleep will then return error code EWOULDBLOCK after two seconds. > > If I remove calls to mtx_lock/unlock from function foo_g(), it works > > without problem but this is not a solution since foo_g() can be > > called outside of function foo_f(). > > Of course, the mtx mutex was created with the MTX_RECURSE flag set. > > > > Is it an expected behaviour? In msleep(9) it is said: > > "The msleep() function is a variation on tsleep. The parameter mtx > > is a mutex which will be released before sleeping and reacquired > > before msleep() returns." > > > > Seems like the mutex is not *really* released if it recurses. > > Only the "Giant" mutex is released if it recurses. By the way there is > a bug in msleep: > > mtx_lock(&Giant); > msleep(xxx, &Giant, 0, "foo", 0); > mtx_unlock(&Giant); This is a bug. Giant is a special mutex that should not be used in properly locked code. That is, if you are using msleep() or condition variables you should be using it with your own mutexes rather than Giant. We can add some assertions to ensure that Giant is not passed in and that recursive mutexes are not used though. Actually, we already assert that the mutex is not recursed. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 04:26:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 153BC16A4CE for ; Tue, 12 Oct 2004 04:26:32 +0000 (GMT) Received: from bsdhosting.net (bsdhosting.net [65.39.221.113]) by mx1.FreeBSD.org (Postfix) with SMTP id CF02A43D2F for ; Tue, 12 Oct 2004 04:26:31 +0000 (GMT) (envelope-from jhopper@bsdhosting.net) Received: (qmail 64724 invoked from network); 12 Oct 2004 04:24:57 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhopper@bsdhosting.net@65.39.221.113) by bsdhosting.net with SMTP; 12 Oct 2004 04:24:57 -0000 From: Justin Hopper To: freebsd-hackers@freebsd.org Content-Type: text/plain Message-Id: <1097555190.3836.841.camel@work.gusalmighty.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 11 Oct 2004 21:26:30 -0700 Content-Transfer-Encoding: 7bit Subject: HyperSCSI on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 04:26:32 -0000 Just curious if anyone was working on either a port of HyperSCSI to FreeBSD, or perhaps some other similar project for exported file systems. I'm not a fan of NFS myself, and the idea of iSCSI and HyperSCSI seems pretty intriguing, but there seems to be no FreeBSD support mentioned anywhere. The source code for the HyperSCSI server and client seems to be quite small, though it's Linux kernel code, so a complete rewrite would probably have to happen. Anyways, just curious if anybody had any thoughts about the porting or what FreeBSD might have planned for this sort of functionality. -- Justin Hopper UNIX Systems Engineer BSDHosting.net Hosting Division of Digital Oasys Inc. http://www.bsdhosting.net From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 04:32:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F406F16A4CE for ; Tue, 12 Oct 2004 04:32:57 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD6F43D39 for ; Tue, 12 Oct 2004 04:32:57 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so176252rnk for ; Mon, 11 Oct 2004 21:32:53 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr1477468rnf; Mon, 11 Oct 2004 21:32:53 -0700 (PDT) Received: by 10.38.8.57 with HTTP; Mon, 11 Oct 2004 21:32:53 -0700 (PDT) Message-ID: Date: Tue, 12 Oct 2004 12:32:53 +0800 From: Jiawei Ye To: Justin Hopper In-Reply-To: <1097555190.3836.841.camel@work.gusalmighty.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1097555190.3836.841.camel@work.gusalmighty.com> cc: freebsd-hackers@freebsd.org Subject: Re: HyperSCSI on FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 04:32:58 -0000 On Mon, 11 Oct 2004 21:26:30 -0700, Justin Hopper wrote: > Just curious if anyone was working on either a port of HyperSCSI to > FreeBSD, or perhaps some other similar project for exported file > systems. I'm not a fan of NFS myself, and the idea of iSCSI and > HyperSCSI seems pretty intriguing, but there seems to be no FreeBSD > support mentioned anywhere. The source code for the HyperSCSI server > and client seems to be quite small, though it's Linux kernel code, so a > complete rewrite would probably have to happen. > > Anyways, just curious if anybody had any thoughts about the porting or > what FreeBSD might have planned for this sort of functionality. > > -- > Justin Hopper You might want to check geom_gate for similar if not exact functionalities. Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 06:40:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC88E16A4D9 for ; Tue, 12 Oct 2004 06:40:47 +0000 (GMT) Received: from www.cotse.net (packetderm.com [68.166.125.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B90A43D5F for ; Tue, 12 Oct 2004 06:40:47 +0000 (GMT) (envelope-from miker@cotse.com) Received: from localhost (localhost[127.0.0.1]) (authenticated bits=0) by www.cotse.net (5.7.4/5.7.4) with ESMTP id i9C6eRNp006137; Tue, 12 Oct 2004 02:40:28 -0400 (EDT) (envelope-from miker@cotse.com) From: Michael Ray To: ulf@Alameda.net Date: Tue, 12 Oct 2004 01:40:29 -0500 Organization: Cotse Message-ID: <8rumm0p0hs73ma6no0s5038qn2ol7vlebj@4ax.com> References: <20041011184805.GX66377@seven.alameda.net> In-Reply-To: <20041011184805.GX66377@seven.alameda.net> X-Mailer: Forte Agent 2.0/32.652 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable cc: hackers@freebsd.org Subject: Re: openssh problem after going from 5.2.1 to 5.3-beta7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miker@cotse.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 06:40:48 -0000 On Mon, 11 Oct 2004 11:48:06 -0700, you wrote: >I have a HP DL380g3 I was running 5.2.1-REL on (I think it was on -p9). >I did a source upgrade to 5.3-beta7, including mergemaster -p, followed >by mergemaster which did upgrade /etc/ssh/sshd_config. > >When I am now trying to connect from SecureCRT, I get: > >SecureCRT has disconnected from the server. Reason: Unable to = authenticate >using any of the configured authentication methods. > > >SecureCRT profile is protocol ssh2, authentication password (which=20 >was saved, I unsaved it, it never prompts for password). SSH2 config >is no compression, Cipher AES-128, AES-192, AES-256, Twofish, Blowfish, >3DES and RC4. MAC is MD5, SHA1, SHA1-96 and MD5-96. SSH server is set >to autodetect, selecting another server doesn't change it. > >Anyone have an idea what the problem might be? Under 'Connection' properties use the "Keyboard Interactive" option for the 'Primary Authentication' method. Mike From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 08:29:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05BC716A4CE for ; Tue, 12 Oct 2004 08:29:52 +0000 (GMT) Received: from web17206.mail.tpe.yahoo.com (web17206.mail.tpe.yahoo.com [202.43.200.115]) by mx1.FreeBSD.org (Postfix) with SMTP id 1BD8343D2F for ; Tue, 12 Oct 2004 08:29:52 +0000 (GMT) (envelope-from cuoching@yahoo.com.tw) Message-ID: <20041012082951.98897.qmail@web17206.mail.tpe.yahoo.com> Received: from [210.243.70.93] by web17206.mail.tpe.yahoo.com via HTTP; Tue, 12 Oct 2004 16:29:51 CST Date: Tue, 12 Oct 2004 16:29:51 +0800 (CST) From: Jerry To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Subject: Why present different size and md5 hash between the compiled code and FreeBSD's build-in binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 08:29:53 -0000 Hi~ This is my first time to post question here, and also I am a newbie on FreeBSD. A confusing thing I discover is: Why the binary code I compiled(for example,telnet command)compare with the original one is diffirent, either size or md5 hash value, What's going on? Are the source files differ from the FreeBSD's binary, or something else ? Deeply appreciate your reply, thanks ~ Jerry Chang ----------------------------------------------------------------- Yahoo!©_¼¯¹q¤l«H½c 100MB §K¶O«H½c¡A¹q¤l«H½c·s¬ö¤¸±q³o¶}©l¡I http://mail.yahoo.com.tw/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 08:42:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8626916A4FC for ; Tue, 12 Oct 2004 08:42:38 +0000 (GMT) Received: from mail.unicorn.cz (mail.unicorn.cz [195.250.129.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E4F443D1D for ; Tue, 12 Oct 2004 08:42:37 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail 8739 invoked from network); 12 Oct 2004 08:36:00 -0000 Received: from unknown (HELO gmx.net) (195.250.129.204) by mail.unicorn.cz with SMTP; 12 Oct 2004 08:36:00 -0000 Message-ID: <416B9977.1040203@gmx.net> Date: Tue, 12 Oct 2004 10:44:39 +0200 From: Andreas Kohn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jerry X-Scanned: By Symantec Anti-Virus Scan Engine References: <20041012082951.98897.qmail@web17206.mail.tpe.yahoo.com> In-Reply-To: <20041012082951.98897.qmail@web17206.mail.tpe.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Why present different size and md5 hash between the compiled code and FreeBSD's build-in binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 08:42:38 -0000 Jerry wrote: >Hi~ > >This is my first time to post question here, and also >I am a newbie on FreeBSD. A confusing thing I discover >is: Why the binary code I compiled(for example,telnet >command)compare with the original one is diffirent, >either size or md5 hash value, What's going on? Are >the source files differ from the FreeBSD's binary, or >something else ? >Deeply appreciate your reply, thanks ~ > >Jerry Chang > > > Hi, you might be using different optimization flags than the release building cluster. Also make sure that you have really the correct sources, and not a newer version from CVS. HTH, -- Andreas From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 11:09:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3160C16A4CE for ; Tue, 12 Oct 2004 11:09:08 +0000 (GMT) Received: from mail.unicorn.cz (mail.unicorn.cz [195.250.129.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D24843D31 for ; Tue, 12 Oct 2004 11:09:07 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail 30468 invoked from network); 12 Oct 2004 11:02:30 -0000 Received: from unknown (HELO gmx.net) (195.250.129.204) by mail.unicorn.cz with SMTP; 12 Oct 2004 11:02:30 -0000 Message-ID: <416BBBCD.9050704@gmx.net> Date: Tue, 12 Oct 2004 13:11:09 +0200 From: Andreas Kohn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jerry , freebsd-hackers@freebsd.org X-Scanned: By Symantec Anti-Virus Scan Engine References: <20041012090959.69545.qmail@web17202.mail.tpe.yahoo.com> In-Reply-To: <20041012090959.69545.qmail@web17202.mail.tpe.yahoo.com> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 8bit Subject: Re: Why present different size and md5 hash between the compiled code and FreeBSD's build-in binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 11:09:08 -0000 Jerry wrote: > --- Andreas Kohn wrote¡G > > >>Hi, >> >>you might be using different optimization flags than >>the release >>building cluster. >>Also make sure that you have really the correct >>sources, and not a newer >>version from CVS. >> >> >Hi~ Andreas, > >I just used make command with default Makefile to >build the binary,without change any gcc flag or >option. >And never go through the CVS to get newer source, by >the way, my test platfrom is Release-5.2 on x86, Have >you ever met this kind of situation? Whether >compile "binary command" or "kernel code" ? > >Best Regards. >Jerry > > Hi, if your source files are *exactly* the same versions used as on the building cluster, and you have *exactly* the same compilation options, it would still be possible to have different binaries. For example if the files included some reference to the current time, either in some flags in the generated .o, .a, .so, or perhaps in the source code of auto-generated headers. Some paths referenced could also be different on your system than on the build cluster. In short: don't worry too much. It is normal. -- Andreas [PS: readded freebsd-hackers@ CC: -- please don't drop the list when replying!] From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 04:56:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 237CF16A4CE for ; Tue, 12 Oct 2004 04:56:28 +0000 (GMT) Received: from web17204.mail.tpe.yahoo.com (web17204.mail.tpe.yahoo.com [202.43.200.113]) by mx1.FreeBSD.org (Postfix) with SMTP id 70E5443D1F for ; Tue, 12 Oct 2004 04:56:27 +0000 (GMT) (envelope-from cuoching@yahoo.com.tw) Message-ID: <20041012045626.95067.qmail@web17204.mail.tpe.yahoo.com> Received: from [210.192.14.125] by web17204.mail.tpe.yahoo.com via HTTP; Tue, 12 Oct 2004 12:56:26 CST Date: Tue, 12 Oct 2004 12:56:26 +0800 (CST) From: Jerry To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 12 Oct 2004 14:50:52 +0000 Subject: Why present different size and md5 hash between the compiled code and original binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 04:56:28 -0000 Hi~ All This is my first time to post question here, and also I am a newbie on FreeBSD. A confusing thing I discover is: Why the binary code I compiled(for example,telnet command)compare with the original one is diffirent, either size or md5 hash , What's going on? Are the source files differ from the FreeBSD's binary, or something else ? Deeply appreciate your reply, thanks ~ Jerry Chang ----------------------------------------------------------------- Yahoo!©_¼¯¹q¤l«H½c 100MB §K¶O«H½c¡A¹q¤l«H½c·s¬ö¤¸±q³o¶}©l¡I http://mail.yahoo.com.tw/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 15:42:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A808016A4CF for ; Tue, 12 Oct 2004 15:42:35 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F7EF43D2D for ; Tue, 12 Oct 2004 15:42:35 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CHOnK-0002XV-00; Tue, 12 Oct 2004 17:42:34 +0200 Received: from [217.227.151.167] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CHOnJ-0003Yk-00; Tue, 12 Oct 2004 17:42:34 +0200 From: Max Laier To: freebsd-hackers@freebsd.org Date: Tue, 12 Oct 2004 17:41:58 +0200 User-Agent: KMail/1.7 References: <20041012090959.69545.qmail@web17202.mail.tpe.yahoo.com> <416BBBCD.9050704@gmx.net> In-Reply-To: <416BBBCD.9050704@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3419989.qjQLSyGZFu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410121742.06608.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Andreas Kohn cc: Jerry Subject: Re: Why present different size and md5 hash between the compiled code and FreeBSD's build-in binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:42:35 -0000 --nextPart3419989.qjQLSyGZFu Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 12 October 2004 13:11, Andreas Kohn wrote: > Jerry wrote: > > --- Andreas Kohn wrote=A1G > > > >>Hi, > >> > >>you might be using different optimization flags than > >>the release > >>building cluster. > >>Also make sure that you have really the correct > >>sources, and not a newer > >>version from CVS. > > > >Hi~ Andreas, > > > >I just used make command with default Makefile to > >build the binary,without change any gcc flag or > >option. > >And never go through the CVS to get newer source, by > >the way, my test platfrom is Release-5.2 on x86, Have > >you ever met this kind of situation? Whether > >compile "binary command" or "kernel code" ? > > > >Best Regards. > >Jerry > > Hi, > > if your source files are *exactly* the same versions used as on the > building cluster, and you have *exactly* the same compilation options, > it would still be possible to have different binaries. For example if > the files included some reference to the current time, either in some > flags in the generated .o, .a, .so, or perhaps in the source code of > auto-generated headers. Some paths referenced could also be different on > your system than on the build cluster. > > In short: don't worry too much. It is normal. If you care to know what changed exactly, you might find objdump(1) helpful= =2E=20 You must have some experience with reading assembler, though. $ objdump -d bin.orig > dump.orig $ objdump -d bin | diff -u dump.orig - Also ident(1) is sometimes helpful to determine if you are *really* using t= he=20 same source files. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3419989.qjQLSyGZFu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBa/tOXyyEoT62BG0RAhq5AJ4+Msy4VfgzH7BkRR37QxqZHYmeLACfVG9V /ET/i4xAt5dgsNCzqCGlzho= =KDZD -----END PGP SIGNATURE----- --nextPart3419989.qjQLSyGZFu-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 16:02:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FC5816A4E1 for ; Tue, 12 Oct 2004 16:02:52 +0000 (GMT) Received: from britannica.bec.de (wlan032137.uni-rostock.de [139.30.32.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E4F43D2F for ; Tue, 12 Oct 2004 16:02:52 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id 75BEC532F; Tue, 12 Oct 2004 18:01:39 +0200 (CEST) Date: Tue, 12 Oct 2004 18:01:38 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20041012160138.GA1128@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20041012090959.69545.qmail@web17202.mail.tpe.yahoo.com> <416BBBCD.9050704@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416BBBCD.9050704@gmx.net> User-Agent: Mutt/1.4.2.1i Subject: Re: Why present different size and md5 hash between the compiled code and FreeBSD's build-in binary ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 16:02:52 -0000 On Tue, Oct 12, 2004 at 01:11:09PM +0200, Andreas Kohn wrote: > if your source files are *exactly* the same versions used as on the > building cluster, and you have *exactly* the same compilation options, > it would still be possible to have different binaries. For example if > the files included some reference to the current time, either in some > flags in the generated .o, .a, .so, or perhaps in the source code of > auto-generated headers. Some paths referenced could also be different on > your system than on the build cluster. To be more precisely, GCC/binutils add timestamps under certain circumstances. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 12 19:07:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05F016A4CE for ; Tue, 12 Oct 2004 19:07:26 +0000 (GMT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 6F12043D1D for ; Tue, 12 Oct 2004 19:07:26 +0000 (GMT) (envelope-from shawnwebb@softhome.net) Received: (qmail 1188 invoked by uid 417); 12 Oct 2004 18:56:10 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 12 Oct 2004 18:56:10 -0000 Received: from dialup-4.228.195.28.Dial1.Denver1.Level3.net ([4.228.195.28]) (AUTH: PLAIN shawnwebb@softhome.net) by softhome.net with esmtp; Tue, 12 Oct 2004 12:56:08 -0600 From: Shawn Webb To: freebsd-hackers@freebsd.org Date: Tue, 12 Oct 2004 18:54:45 -0600 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_VzHbB270BbWZQ08" Message-Id: <200410121854.45986.shawnwebb@softhome.net> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 19:07:27 -0000 --Boundary-00=_VzHbB270BbWZQ08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I have stumbled upon a local DoS (non-kernel) while writing a VoIP app for FreeBSD. The DoS exists when two ioctl calls (or less/more?) are followed by a malloc call to malloc a pointer in global scope which is then followed by two more (or less/more?) ioctl calls. The result is a stack smash, and upon return of the function, the program segfaults. gdb output of the core dump: Core was generated by `a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000080 in ?? () I am curently running: FreeBSD 5.3-BETA7 FreeBSD 5.3-BETA7 #2: Sun Oct 10 21:05:53 MDT 2004 shawn@:/usr/obj/usr/src/sys/LATERALUS i386 I have confirmed the same results on multiple FreeBSD machines, each different versions spanning 4.10-RELEASE to 5.2.1-RELEASE (and my 5.3-BETA7 machine). Shawn Webb http://retoros.org:81/ (attached is the source code to the segfaulting application) --Boundary-00=_VzHbB270BbWZQ08-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 02:42:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 693E716A4CE for ; Wed, 13 Oct 2004 02:42:20 +0000 (GMT) Received: from web17206.mail.tpe.yahoo.com (web17206.mail.tpe.yahoo.com [202.43.200.115]) by mx1.FreeBSD.org (Postfix) with SMTP id DF20343D58 for ; Wed, 13 Oct 2004 02:42:19 +0000 (GMT) (envelope-from cuoching@yahoo.com.tw) Message-ID: <20041013024219.82466.qmail@web17206.mail.tpe.yahoo.com> Received: from [210.192.14.125] by web17206.mail.tpe.yahoo.com via HTTP; Wed, 13 Oct 2004 10:42:19 CST Date: Wed, 13 Oct 2004 10:42:19 +0800 (CST) From: Jerry To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Subject: Why present different size and md5 hash between the compiled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 02:42:20 -0000 Thank you all for explaining so patiently, I have somewhat of understanding with this issue ~ very appreciated all who commented. Jerry ----------------------------------------------------------------- Yahoo!©_¼¯¹q¤l«H½c 100MB §K¶O«H½c¡A¹q¤l«H½c·s¬ö¤¸±q³o¶}©l¡I http://mail.yahoo.com.tw/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 07:49:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3687316A4CF for ; Wed, 13 Oct 2004 07:49:13 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AED943D45 for ; Wed, 13 Oct 2004 07:49:12 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9D7lYiR084467; Wed, 13 Oct 2004 03:47:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9D7lYO4084460; Wed, 13 Oct 2004 03:47:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 13 Oct 2004 03:47:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Shawn Webb In-Reply-To: <200410121854.45986.shawnwebb@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 07:49:13 -0000 On Tue, 12 Oct 2004, Shawn Webb wrote: > (attached is the source code to the segfaulting application) Doesn't appear to be -- if it was a large attachment, maybe the mailing list stripped it. Could you give a URL for the source? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 13:02:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9086E16A4CE for ; Wed, 13 Oct 2004 13:02:36 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E2B43D31 for ; Wed, 13 Oct 2004 13:02:36 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=miha.netstream-gh.com) by beer.ux6.net with esmtpa (Exim 4.42 (FreeBSD)) id 1CHim1-0003b1-Fg for freebsd-hackers@freebsd.org; Wed, 13 Oct 2004 06:02:34 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Wed, 13 Oct 2004 13:03:35 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> <200410102330.26228.miha@ghuug.org> In-Reply-To: <200410102330.26228.miha@ghuug.org> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410131303.35695.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details.> On Saturday 09 October 2004 17:01, Mikhail P. wrote: > > I also gotUDMA values. I switched from UDMA100 to UDMA66. System's uptime is 12 > > hours, and no timeouts so far.. but I'm quite sure they will get back in > > few days. > > 1.5 days of uptime, running in UDMA66 changes nothing. Still getting [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 13:02:36 -0000 On Sunday 10 October 2004 23:30, Mikhail P. wrote: > On Saturday 09 October 2004 17:01, Mikhail P. wrote: > > I also got another message off-list, where author suggested to play with > > UDMA values. I switched from UDMA100 to UDMA66. System's uptime is 12 > > hours, and no timeouts so far.. but I'm quite sure they will get back in > > few days. > > 1.5 days of uptime, running in UDMA66 changes nothing. Still getting Well, now those timeouts popped up on 5.3-BETA7 system with 4 IDE drives.. They start appearing with high disk activity. System had FreeBSD-4.7 prior to that, and has been rock solid for almost a year. Drives have no problems, that's for sure (4.7 did not show up any timeouts, with uptime for months).. I don't know what to think - is ATA driver horribly broken in 5.x? regards, M. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 13:52:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDFC16A4CE for ; Wed, 13 Oct 2004 13:52:10 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC7143D45 for ; Wed, 13 Oct 2004 13:52:09 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i9DDq5S1031295; Wed, 13 Oct 2004 15:52:07 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <416D32F5.1090401@DeepCore.dk> Date: Wed, 13 Oct 2004 15:51:49 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: miha@ghuug.org References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> <200410102330.26228.miha@ghuug.org> <200410131303.35695.miha@ghuug.org> In-Reply-To: <200410131303.35695.miha@ghuug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-hackers@freebsd.org Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 13:52:10 -0000 Mikhail P. wrote: > On Sunday 10 October 2004 23:30, Mikhail P. wrote: >=20 >>On Saturday 09 October 2004 17:01, Mikhail P. wrote: >> >>>I also got another message off-list, where author suggested to play wi= th >>>UDMA values. I switched from UDMA100 to UDMA66. System's uptime is 12 >>>hours, and no timeouts so far.. but I'm quite sure they will get back = in >>>few days. >> >>1.5 days of uptime, running in UDMA66 changes nothing. Still getting >=20 >=20 > Well, now those timeouts popped up on 5.3-BETA7 system with 4 IDE drive= s..=20 > They start appearing with high disk activity. > System had FreeBSD-4.7 prior to that, and has been rock solid for almos= t a=20 > year. Drives have no problems, that's for sure (4.7 did not show up any= =20 > timeouts, with uptime for months).. >=20 > I don't know what to think - is ATA driver horribly broken in 5.x? Well, thats not up to me to judge I guess, but have you tried to change=20 the tripping point for using 48Bit addressing as I suggested earlier ? I cant reproduce this problem with any of the shelfmeters of ATA gear I=20 have here, so your help is needed or it will stay horribly broken :) --=20 -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 13:59:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CA1B16A4CE for ; Wed, 13 Oct 2004 13:59:55 +0000 (GMT) Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id B117F43D1D for ; Wed, 13 Oct 2004 13:59:53 +0000 (GMT) (envelope-from martin@gneto.com) Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 5A32637FCF; Wed, 13 Oct 2004 15:59:52 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 482A737E7B; Wed, 13 Oct 2004 15:59:52 +0200 (CEST) Received: from [192.168.2.10] (h118n1fls31o985.telia.com [213.65.16.118]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 251FD37E4B; Wed, 13 Oct 2004 15:59:51 +0200 (CEST) Message-ID: <416D34D8.9050804@gneto.com> Date: Wed, 13 Oct 2004 15:59:52 +0200 From: Martin Nilsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> <200410102330.26228.miha@ghuug.org> <200410131303.35695.miha@ghuug.org> In-Reply-To: <200410131303.35695.miha@ghuug.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: sos@DeepCore.dk Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 13:59:55 -0000 Mikhail P. wrote: > Well, now those timeouts popped up on 5.3-BETA7 system with 4 IDE drives.. > They start appearing with high disk activity. > System had FreeBSD-4.7 prior to that, and has been rock solid for almost a > year. Drives have no problems, that's for sure (4.7 did not show up any > timeouts, with uptime for months).. > > I don't know what to think - is ATA driver horribly broken in 5.x? Something is rotten with ATA on 5.x (or I have a rotten motherboard!) I have an E7320 "Lindenhurst VS ICH5R box" with 2*3GHz EM64T Xeons and 2*80GB Seagate SATA disks. Sometimes when booting the whole ATA/SATA system hangs after two READ_DMA or WRITE_DMA timeout errors. This seems to more common when running as AMD64 than i386. I can't remember any hangs after the machine have been up nicely for a couple of min. The 1U box is so noisy that I can't be in the apartment at the same time without going crazy, this and that I can't reproduce it reliably effectively prevents most debugging attempts. /Martin From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 14:14:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5015416A4CE for ; Wed, 13 Oct 2004 14:14:55 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16F2E43D39 for ; Wed, 13 Oct 2004 14:14:55 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=miha.netstream-gh.com) by beer.ux6.net with esmtpa (Exim 4.42 (FreeBSD)) id 1CHjtq-000BCu-Lg; Wed, 13 Oct 2004 07:14:52 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Wed, 13 Oct 2004 14:15:45 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410131303.35695.miha@ghuug.org> <416D32F5.1090401@DeepCore.dk> In-Reply-To: <416D32F5.1090401@DeepCore.dk> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410131415.45426.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Wednesday 13 October 2004 13:51, Søren Schmidt wrote: > Well, thats not up to me to judge I guess, but have you tried to change > the tripping point for using 48Bit addressing as I suggested earlier ? [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 14:14:55 -0000 On Wednesday 13 October 2004 13:51, S=F8ren Schmidt wrote: > Well, thats not up to me to judge I guess, but have you tried to change > the tripping point for using 48Bit addressing as I suggested earlier ? How one would do it? In BIOS? =46orgive my ignorance. > I cant reproduce this problem with any of the shelfmeters of ATA gear I > have here, so your help is needed or it will stay horribly broken :) The 5.3-BETA7 box I was referring to is a whole different machine from the = one=20 I posted initially (2 x 200GB IDE). This machine has 4 IDE drives - 20GB Seagate 60GB IBM 120GBWDC 200GB WDC and it is P4 (CPU is 1.5Ghz, p4) motherboard. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 18:40:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0653C16A544 for ; Wed, 13 Oct 2004 18:40:55 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48ACE43D53 for ; Wed, 13 Oct 2004 18:40:54 +0000 (GMT) (envelope-from aaron.glenn@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so626383rnk for ; Wed, 13 Oct 2004 11:40:53 -0700 (PDT) Received: by 10.38.162.14 with SMTP id k14mr2568005rne; Wed, 13 Oct 2004 11:40:53 -0700 (PDT) Received: by 10.38.151.56 with HTTP; Wed, 13 Oct 2004 11:40:53 -0700 (PDT) Message-ID: <18f601940410131140c97e44b@mail.gmail.com> Date: Wed, 13 Oct 2004 11:40:53 -0700 From: Aaron Glenn To: freebsd-hackers@freebsd.org In-Reply-To: <200410102330.26228.miha@ghuug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> <200410102330.26228.miha@ghuug.org> Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Glenn List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 18:40:56 -0000 I used to get that error prior to 5.3-BETA3 (5.2.1-RELEASE, and all previous 5.3-BETA's). Randomly after reboot the machine would spew about 100 of these and then hardlock. I've got two identical boxes running BETA3 and BETA7 without any issues. Intel 6300ESB controller and Western Digital "Enterprise" Serial ATA Raptor drives are the hardware. I thought about posting the issue, but decided against it since it was BETA 1 or BETA 2 and 5.2.1 was, honestly, nothing but pure crap. Regards, aaron.glenn On Sun, 10 Oct 2004 23:30:26 +0000, Mikhail P. wrote: > ad0: FAILURE - READ_DMA status=51 error=10 > LBA=268435455 > ad0: FAILURE - READ_DMA status=51 error=10 > LBA=268435455 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 20:15:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA1C316A4CE for ; Wed, 13 Oct 2004 20:15:14 +0000 (GMT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 86AFD43D45 for ; Wed, 13 Oct 2004 20:15:14 +0000 (GMT) (envelope-from shawnwebb@softhome.net) Received: (qmail 4616 invoked by uid 417); 13 Oct 2004 19:37:15 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 13 Oct 2004 19:37:15 -0000 Received: from shawns ([4.228.207.101]) (AUTH: LOGIN shawnwebb@softhome.net) by softhome.net with esmtp; Wed, 13 Oct 2004 13:37:13 -0600 Message-ID: <001201c4b224$fcd68320$65cfe404@shawns> From: "Shawn Webb" To: freebsd-hackers@freebsd.org Date: Thu, 14 Oct 2004 13:35:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: RE: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 20:15:15 -0000 I've got to rewrite the source due to hard disk problems, so I'll just put it in this email: /* dsp_seg.c */ /* If there are any compile errors, forgive me; I'm not on a FreeBSD box */ #include #include #include #include #include #include #include #define FORMAT AFMT_S16_LE #define RATE 8000 #define CHANNELS 1 char *buf; int fd; int buflen; void this_segfaults(void); int main(void) { fd = open("/dev/dsp", O_RDWR); if (fd < 0) { perror("open"); exit(1); } this_segfaults(); printf("m00\n"); exit(0); } void this_segfaults(void) { int arg; arg = FORMAT; if (ioctl(fd, SNDCTL_DSP_SETFMT, &arg) < 0) { perror("ioctl setfmt"); exit(1); } if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &arg) < 0) { perror("ioctl getospace"); exit(1); } printf("arg: %d\n", arg); buf = malloc(arg); if (!buf) { perror("malloc"); exit(1); } arg = CHANNELS; if (ioctl(fd, SNDCTL_DSP_CHANNELS, &arg) < 0) { perror("ioctl channels"); exit(1); } arg = RATE; if (ioctl(fd, SNDCTL_DSP_SETRATE, &arg) < 0) { perror("ioctl setrate"); exit(1); } } /* End of source */ ----- Original Message ----- From: "Robert Watson" To: "Shawn Webb" Cc: Sent: Wednesday, October 13, 2004 1:47 AM Subject: Re: malloc calls and ioctl calls to soundcard cause segfault > > On Tue, 12 Oct 2004, Shawn Webb wrote: > > > (attached is the source code to the segfaulting application) > > Doesn't appear to be -- if it was a large attachment, maybe the mailing > list stripped it. Could you give a URL for the source? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 13 21:00:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6295816A4D2 for ; Wed, 13 Oct 2004 21:00:52 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C355D43D3F for ; Wed, 13 Oct 2004 21:00:36 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i9DL0TYp007455; Wed, 13 Oct 2004 16:00:29 -0500 (CDT) (envelope-from dan) Date: Wed, 13 Oct 2004 16:00:29 -0500 From: Dan Nelson To: Shawn Webb Message-ID: <20041013210029.GA88757@dan.emsphone.com> References: <001201c4b224$fcd68320$65cfe404@shawns> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c4b224$fcd68320$65cfe404@shawns> X-OS: FreeBSD 5.3-BETA7 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 21:00:52 -0000 In the last episode (Oct 14), Shawn Webb said: > I've got to rewrite the source due to hard disk problems, so I'll just put > it in this email: > > arg = FORMAT; > if (ioctl(fd, SNDCTL_DSP_SETFMT, &arg) < 0) > { > perror("ioctl setfmt"); > exit(1); > } > > if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &arg) < 0) > { > perror("ioctl getospace"); > exit(1); > } SNDCTL_DSP_GETOSPACE takes a pointer to an "audio_buf_info" type, so you actually asked it to write sizeof(audio_buf_info) bytes to the location of the "arg" variable, which is... (drumroll) on the stack :) Create another variable "audio_buf_info info;" above main, and change that call to "if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &info) < 0)" and your program will run fine. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 01:50:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E30DB16A4CE for ; Thu, 14 Oct 2004 01:50:50 +0000 (GMT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 730BC43D3F for ; Thu, 14 Oct 2004 01:50:50 +0000 (GMT) (envelope-from shawnwebb@softhome.net) Received: (qmail 32595 invoked by uid 417); 14 Oct 2004 01:37:01 -0000 Received: from mambo-.softhome.net (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 14 Oct 2004 01:37:01 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 13 Oct 2004 19:37:00 -0600 References: <001201c4b224$fcd68320$65cfe404@shawns> <20041013210029.GA88757@dan.emsphone.com> In-Reply-To: <20041013210029.GA88757@dan.emsphone.com> From: shawnwebb@softhome.net To: Dan Nelson Date: Wed, 13 Oct 2004 19:36:59 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: shawnwebb@softhome.net X-Originating-IP: [198.179.147.18] Message-ID: cc: freebsd-hackers@freebsd.org Subject: Re: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 01:50:51 -0000 Thanks for pointing that out. The OSS documentation didn't go into detail about what type of arg was needed for getospace, so I assumed int. Dan Nelson writes: > In the last episode (Oct 14), Shawn Webb said: >> I've got to rewrite the source due to hard disk problems, so I'll just put >> it in this email: >> >> arg = FORMAT; >> if (ioctl(fd, SNDCTL_DSP_SETFMT, &arg) < 0) >> { >> perror("ioctl setfmt"); >> exit(1); >> } >> >> if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &arg) < 0) >> { >> perror("ioctl getospace"); >> exit(1); >> } > > SNDCTL_DSP_GETOSPACE takes a pointer to an "audio_buf_info" type, so > you actually asked it to write sizeof(audio_buf_info) bytes to the > location of the "arg" variable, which is... (drumroll) > > on the stack :) > > Create another variable "audio_buf_info info;" above main, and change > that call to "if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &info) < 0)" and your > program will run fine. > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 01:56:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF19916A4CE for ; Thu, 14 Oct 2004 01:56:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6652743D48 for ; Thu, 14 Oct 2004 01:56:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i9E1uj3G012337; Wed, 13 Oct 2004 20:56:45 -0500 (CDT) (envelope-from dan) Date: Wed, 13 Oct 2004 20:56:45 -0500 From: Dan Nelson To: shawnwebb@softhome.net Message-ID: <20041014015645.GB88757@dan.emsphone.com> References: <001201c4b224$fcd68320$65cfe404@shawns> <20041013210029.GA88757@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-BETA7 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: malloc calls and ioctl calls to soundcard cause segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 01:56:46 -0000 In the last episode (Oct 13), shawnwebb@softhome.net said: > Thanks for pointing that out. The OSS documentation didn't go into > detail about what type of arg was needed for getospace, so I assumed > int. I just looked up SNDCTL_DSP_GETOSPACE in the PDF at http://www.opensound.com/pguide/index.html (it's on page 96 and describes the fields in audio_buf_info as well). -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 07:02:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E268F16A4CE for ; Thu, 14 Oct 2004 07:02:25 +0000 (GMT) Received: from www.hexe.com.pl (www.hexe.com.pl [212.160.230.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB1343D49 for ; Thu, 14 Oct 2004 07:02:24 +0000 (GMT) (envelope-from clamav@www.hexe.com.pl) Received: from www.hexe.com.pl (smmsp@localhost [127.0.0.1]) i9E6VgSN024703; Thu, 14 Oct 2004 08:31:44 +0200 Received: (from clamav@localhost) by www.hexe.com.pl (8.12.3/8.12.3/Debian-6.6) id i9E6QJEb024548; Thu, 14 Oct 2004 08:26:19 +0200 Date: Thu, 14 Oct 2004 08:26:19 +0200 Message-Id: <200410140626.i9E6QJEb024548@www.hexe.com.pl> From: To: Auto-Submitted: auto-submitted (antivirus notify) X-Infected-Received-From: ahx205.neoplus.adsl.tpnet.pl [83.25.205.205] X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.74a on www X-Virus-Status: Clean cc: postmaster@www.hexe.com.pl cc: krakow@hexe.com.pl Subject: Virus intercepted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 07:02:26 -0000 A message you sent to contained Worm.SomeFool.X and has not been delivered. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 08:22:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5752116A4CE for ; Thu, 14 Oct 2004 08:22:00 +0000 (GMT) Received: from crumpler-s1.mel.crumpler.com.au (b20FB.static.pacific.net.au [210.23.137.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BEA43D1F for ; Thu, 14 Oct 2004 08:21:59 +0000 (GMT) (envelope-from listsubs@crippy.mel.crumpler.com.au) Received: from [203.208.117.170] ([203.208.117.170]) by crumpler-s1.mel.crumpler.com.au over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Oct 2004 18:21:56 +1000 Message-ID: <416E3722.9070705@crippy.mel.crumpler.com.au> Date: Thu, 14 Oct 2004 18:21:54 +1000 From: Phillip Crumpler User-Agent: Mozilla Thunderbird 0.7.3 (X11/20041004) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2004 08:21:57.0294 (UTC) FILETIME=[DECE9CE0:01C4B1C6] Subject: can WEP keys be set without resetting a wireless interface? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 08:22:00 -0000 Hi hackers, Can anyone tell me why setting WEP keys on a wireless interface must result in the interface being reset? I have a wireless authenticator that wants to set random WEP keys and send them out to connected stations. Setting a key results in the interface being reset () the ioctl handler return ENETRESET), which kicks off all of the stations and forces them to reassociate. Trying to get around this I just updated the keys directly: wk = &ic->ic_nw_keys[nkidx]; arc4rand(wk->wk_key, wk->wk_len, 0); But the moment this happens everyone goes off the air. Of course, that is the short answer: the interface gets reset because it doesn't work if it's not :-) Can anyone provide a bit more detail or suggest a way around this? Thanks, Phillip Crumpler From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 09:14:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34A2616A4CE for ; Thu, 14 Oct 2004 09:14:54 +0000 (GMT) Received: from virtuaal.ultrasoft.ee (ns2.ultrasoft.ee [194.204.30.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE5343D62 for ; Thu, 14 Oct 2004 09:14:53 +0000 (GMT) (envelope-from asko.t@ultrasoft.ee) Received: from localhost (localhost [127.0.0.1]) by virtuaal.ultrasoft.ee (Postfix) with ESMTP id CF267A3 for ; Thu, 14 Oct 2004 11:53:57 +0300 (EEST) Received: from virtuaal.ultrasoft.ee ([127.0.0.1]) by localhost (ns2.ultrasoft.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41071-02 for ; Thu, 14 Oct 2004 11:53:48 +0300 (EEST) Received: from [62.65.204.188] (ns.ultrasoft.ee [213.35.215.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by virtuaal.ultrasoft.ee (Postfix) with ESMTP id 288797B for ; Thu, 14 Oct 2004 11:53:48 +0300 (EEST) Message-ID: <416E4581.1020508@ultrasoft.ee> Date: Thu, 14 Oct 2004 12:23:13 +0300 From: Asko Tamm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at virtuaal.ultrasoft.ee Subject: Need help debugging kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 09:14:54 -0000 Hi, Please help me with kernel debugging. The situation is the following: system panics and reboots about every 24 hours (24 hours since last reboot), 4.10-STABLE on i386. It shouldn't be a hardware issue, it happens on several different machines, having similar configuration. Systems are running named, postfix, apache, samba, dhcpd, lpd, webmin, mpd, etc. with the similar configuration. Kernel has following additions to GENERIC - options: DUMMYNET, NMBCLUSTERS=8192, NETGRAPH, IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_FORWARD, IPDIVERT, IPSTEALTH, TCPDEBUG $ gdb -k kernel.debug /usr/crash/vmcore.1 GNU gdb 4.18 (FreeBSD) Copyright 1998 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-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf IdlePTD at physical address 0x00591000 initial pcb at physical address 0x004b1120 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address= 0xad243ff3 fault code= supervisor read, page not present instruction pointer= 0x8:0xc027c55b stack pointer = 0x10:0xd2e8ad98 frame pointer = 0x10:0xd2e8ae1c 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= 407 (nmbd) interrupt mask= none trap number= 12 panic: page fault syncing disks... 14 3 done Uptime: 23h53m31s dumping to dev #ad/0x20011, offset 1589376 dump ata1: resetting devices .. done 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 \^@\--- #0 dumpsys () at ../../kern/kern_shutdown.c:487 487if (dumping++) { (kgdb) list *0xc027c55b 0xc027c55b is in ifconf (../../net/if.c:1330). 1325addrs = 0; 1326ifa = ifp->if_addrhead.tqh_first; 1327TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { 1328if (space <= sizeof(ifr)) 1329break; 1330sa = ifa->ifa_addr; 1331if (curproc->p_prison && prison_if(curproc, sa)) 1332continue; 1333addrs++; 1334#ifdef COMPAT_43 (kgdb) backtrace #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc0237c73 in boot (howto=256) at ../../kern/kern_shutdown.c:316 #2 0xc0238098 in poweroff_wait (junk=0xc0447fec, howto=-1069253905) at ../../kern/kern_shutdown.c:595 #3 0xc03b9d9a in trap_fatal (frame=0xd2e8ad58, eva=2904834035) at ../../i386/i386/trap.c:974 #4 0xc03b9a6d in trap_pfault (frame=0xd2e8ad58, usermode=0, eva=2904834035) at ../../i386/i386/trap.c:867 #5 0xc03b962b in trap (frame={tf_fs = -1078001648, tf_es = -756547568, tf_ds = 16, tf_edi = 7708, tf_esi = -1077949100, tf_ebp = -756503012, tf_isp = -756503164, tf_ebx = -1033036164, tf_edx = -756514816, tf_ecx = 0, tf_eax = -1390133261, tf_trapno = 12, tf_err = 0, tf_eip = -1071135397, tf_cs = 8, tf_eflags = 66054, tf_esp = -757485376, tf_ss = -1073190620}) at ../../i386/i386/trap.c:466 #6 0xc027c55b in ifconf (cmd=3221776676, data=0xd2e8aea8 "") at ../../net/if.c:1330 #7 0xc027bd1d in ifioctl (so=0xd197e9c0, cmd=3221776676, data=0xd2e8aea8 "", p=0xd2d9b0c0) at ../../net/if.c:968 #8 0xc024a63a in soo_ioctl (fp=0xc2a49ec0, cmd=3221776676, data=0xd2e8aea8 "", p=0xd2d9b0c0) at ../../kern/sys_socket.c:143 #9 0xc0247536 in ioctl (p=0xd2d9b0c0, uap=0xd2e8af80) at ../../sys/file.h:178 #10 0xc03ba049 in syscall2 (frame={tf_fs = 135069743, tf_es = 47, tf_ds = -1078001617, tf_edi = -1077937824, tf_esi = -1077941280, ---Type to continue, or q to quit--- tf_ebp = -1077941392, tf_isp = -756502572, tf_ebx = 1097604547, tf_edx = -1077949584, tf_ecx = 0, tf_eax = 54, tf_trapno = 7, tf_err = 2, tf_eip = 673566372, tf_cs = 31, tf_eflags = 659, tf_esp = -1077949660, tf_ss = 47}) at ../../i386/i386/trap.c:1175 #11 0xc03ab065 in Xint0x80_syscall () #12 0x80a8aac in ?? () #13 0x80a7a1f in ?? () #14 0x805df08 in ?? () #15 0x805e45c in ?? () #16 0x805ec01 in ?? () #17 0x805d38a in ?? () I am suspecting mpd, because on one machine shutting down mpd helped, but i can't be sure yet. It's takes long time to test, it takes 24 hours to see the result after every configuration change ;-( -- asko From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 08:56:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C560216A4CE for ; Thu, 14 Oct 2004 08:56:53 +0000 (GMT) Received: from virtuaal.ultrasoft.ee (ns2.ultrasoft.ee [194.204.30.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id A328243D2D for ; Thu, 14 Oct 2004 08:56:52 +0000 (GMT) (envelope-from asko.tnospam@ultrasoft.ee) Received: from localhost (localhost [127.0.0.1]) by virtuaal.ultrasoft.ee (Postfix) with ESMTP id 9DD8FA3 for ; Thu, 14 Oct 2004 11:35:57 +0300 (EEST) Received: from virtuaal.ultrasoft.ee ([127.0.0.1]) by localhost (ns2.ultrasoft.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20384-09 for ; Thu, 14 Oct 2004 11:35:50 +0300 (EEST) Received: from [62.65.204.188] (ns.ultrasoft.ee [213.35.215.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by virtuaal.ultrasoft.ee (Postfix) with ESMTP id BBEA67B for ; Thu, 14 Oct 2004 11:35:49 +0300 (EEST) Message-ID: <416E414B.4010603@ultrasoft.ee> Date: Thu, 14 Oct 2004 12:05:15 +0300 From: Asko Tamm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at virtuaal.ultrasoft.ee X-Mailman-Approved-At: Thu, 14 Oct 2004 12:26:37 +0000 Subject: Need help debugging kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 08:56:53 -0000 Hi, Please help me with kernel debugging. The situation is the following: system panics and reboots about every 24 hours (24 hours since last reboot), 4.10-STABLE on i386. It shouldn't be a hardware issue, it happens on several different machines, having similar configuration. Systems are running named, postfix, apache, samba, dhcpd, lpd, webmin, mpd, etc. with the similar configuration. Kernel has following additions to GENERIC - options: DUMMYNET, NMBCLUSTERS=8192, NETGRAPH, IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_FORWARD, IPDIVERT, IPSTEALTH, TCPDEBUG $ gdb -k kernel.debug /usr/crash/vmcore.1 GNU gdb 4.18 (FreeBSD) Copyright 1998 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-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf IdlePTD at physical address 0x00591000 initial pcb at physical address 0x004b1120 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address= 0xad243ff3 fault code= supervisor read, page not present instruction pointer= 0x8:0xc027c55b stack pointer = 0x10:0xd2e8ad98 frame pointer = 0x10:0xd2e8ae1c 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= 407 (nmbd) interrupt mask= none trap number= 12 panic: page fault syncing disks... 14 3 done Uptime: 23h53m31s dumping to dev #ad/0x20011, offset 1589376 dump ata1: resetting devices .. done 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 \^@\--- #0 dumpsys () at ../../kern/kern_shutdown.c:487 487if (dumping++) { (kgdb) list *0xc027c55b 0xc027c55b is in ifconf (../../net/if.c:1330). 1325addrs = 0; 1326ifa = ifp->if_addrhead.tqh_first; 1327TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { 1328if (space <= sizeof(ifr)) 1329break; 1330sa = ifa->ifa_addr; 1331if (curproc->p_prison && prison_if(curproc, sa)) 1332continue; 1333addrs++; 1334#ifdef COMPAT_43 (kgdb) backtrace #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc0237c73 in boot (howto=256) at ../../kern/kern_shutdown.c:316 #2 0xc0238098 in poweroff_wait (junk=0xc0447fec, howto=-1069253905) at ../../kern/kern_shutdown.c:595 #3 0xc03b9d9a in trap_fatal (frame=0xd2e8ad58, eva=2904834035) at ../../i386/i386/trap.c:974 #4 0xc03b9a6d in trap_pfault (frame=0xd2e8ad58, usermode=0, eva=2904834035) at ../../i386/i386/trap.c:867 #5 0xc03b962b in trap (frame={tf_fs = -1078001648, tf_es = -756547568, tf_ds = 16, tf_edi = 7708, tf_esi = -1077949100, tf_ebp = -756503012, tf_isp = -756503164, tf_ebx = -1033036164, tf_edx = -756514816, tf_ecx = 0, tf_eax = -1390133261, tf_trapno = 12, tf_err = 0, tf_eip = -1071135397, tf_cs = 8, tf_eflags = 66054, tf_esp = -757485376, tf_ss = -1073190620}) at ../../i386/i386/trap.c:466 #6 0xc027c55b in ifconf (cmd=3221776676, data=0xd2e8aea8 "") at ../../net/if.c:1330 #7 0xc027bd1d in ifioctl (so=0xd197e9c0, cmd=3221776676, data=0xd2e8aea8 "", p=0xd2d9b0c0) at ../../net/if.c:968 #8 0xc024a63a in soo_ioctl (fp=0xc2a49ec0, cmd=3221776676, data=0xd2e8aea8 "", p=0xd2d9b0c0) at ../../kern/sys_socket.c:143 #9 0xc0247536 in ioctl (p=0xd2d9b0c0, uap=0xd2e8af80) at ../../sys/file.h:178 #10 0xc03ba049 in syscall2 (frame={tf_fs = 135069743, tf_es = 47, tf_ds = -1078001617, tf_edi = -1077937824, tf_esi = -1077941280, ---Type to continue, or q to quit--- tf_ebp = -1077941392, tf_isp = -756502572, tf_ebx = 1097604547, tf_edx = -1077949584, tf_ecx = 0, tf_eax = 54, tf_trapno = 7, tf_err = 2, tf_eip = 673566372, tf_cs = 31, tf_eflags = 659, tf_esp = -1077949660, tf_ss = 47}) at ../../i386/i386/trap.c:1175 #11 0xc03ab065 in Xint0x80_syscall () #12 0x80a8aac in ?? () #13 0x80a7a1f in ?? () #14 0x805df08 in ?? () #15 0x805e45c in ?? () #16 0x805ec01 in ?? () #17 0x805d38a in ?? () I am suspecting mpd, because on one machine shutting down mpd helped, but i can't be sure yet. It's takes long time to test, it takes 24 hours to see the result after every configuration change ;-( -- asko From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 19:59:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED65A16A4CE for ; Thu, 14 Oct 2004 19:59:44 +0000 (GMT) Received: from as6-1-5.kr.m.bonet.se (as6-1-5.kr.m.bonet.se [217.215.84.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 755A743D70 for ; Thu, 14 Oct 2004 19:59:43 +0000 (GMT) (envelope-from martin@gneto.com) Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id A78087441A; Thu, 14 Oct 2004 21:59:41 +0200 (CEST) Message-ID: <416EDA95.8010201@gneto.com> Date: Thu, 14 Oct 2004 21:59:17 +0200 From: Martin Nilsson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; sv-SE; rv:1.7.2) Gecko/20040809 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200410081937.15068.miha@ghuug.org> <200410091701.01987.miha@ghuug.org> <200410102330.26228.miha@ghuug.org> <200410131303.35695.miha@ghuug.org> <416D34D8.9050804@gneto.com> In-Reply-To: <416D34D8.9050804@gneto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: sos@DeepCore.dk Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 19:59:45 -0000 Martin Nilsson wrote / skrev: > Something is rotten with ATA on 5.x (or I have a rotten motherboard!) > I have an E7320 "Lindenhurst VS 6300ESB box" with 2*3GHz EM64T Xeons and > 2*80GB Seagate SATA disks. Sometimes when booting the whole ATA/SATA > system hangs after two READ_DMA or WRITE_DMA timeout errors. This seems > to more common when running as AMD64 than i386. I can't remember any > hangs after the machine have been up nicely for a couple of min. Today when starting the box with i386 RELENG_5 I got the following: ad4: TIMEOUT - WRITE_DMA LBA=4798015 ad4: TIMEOUT - WRITE_DMA LBA=146847331 panic: initiate_write_inodeblock_ufs2: already started After a reboot & fsck it works nice! A verbose dmesg (from a good boot) is here: http://www.gneto.com/FreeBSD/i386-dmesg.boot I really don't know what to with this box, maybe put regular ATA or SCSI disks in it? /Martin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 20:32:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A3C916A4D9 for ; Thu, 14 Oct 2004 20:32:23 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C0043D48 for ; Thu, 14 Oct 2004 20:32:22 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CICGq-000FYm-CH; Thu, 14 Oct 2004 13:32:21 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Thu, 14 Oct 2004 20:33:28 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <416D34D8.9050804@gneto.com> <416EDA95.8010201@gneto.com> In-Reply-To: <416EDA95.8010201@gneto.com> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410142033.28641.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Thursday 14 October 2004 19:59, Martin Nilsson wrote: > I really don't know what to with this box, maybe put regular my knowledge 5.3 and 5.2.1 work well on my SCSI servers.. only the ATA driver.. Would be sad to still have these problems when 5.3 goes as problem, and sending more debugging information, so that problem gets solved quicker. [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] cc: sos@deepcore.dk Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 20:32:23 -0000 On Thursday 14 October 2004 19:59, Martin Nilsson wrote: > I really don't know what to with this box, maybe put regular ATA or SCSI > disks in it? Well, there are no problems with SCSI to my knowledge 5.3 and 5.2.1 work well on my SCSI servers.. only the ATA driver.. Would be sad to still have these problems when 5.3 goes as -STABLE.. on the other hand, I expect more people hitting that problem, and sending more debugging information, so that problem gets solved quicker. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 14:27:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EFD16A4CE for ; Thu, 14 Oct 2004 14:27:41 +0000 (GMT) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7E0A43D2D for ; Thu, 14 Oct 2004 14:27:40 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (sjivid@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.11/8.12.11) with ESMTP id i9EERcqA056741 for ; Thu, 14 Oct 2004 16:27:38 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.11/8.12.11/Submit) id i9EERcTF056740; Thu, 14 Oct 2004 16:27:38 +0200 (CEST) (envelope-from olli) Date: Thu, 14 Oct 2004 16:27:38 +0200 (CEST) Message-Id: <200410141427.i9EERcTF056740@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.10-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 15 Oct 2004 12:14:56 +0000 Subject: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 14:27:41 -0000 Hi, I'm currently trying to optimize some NFS mounts. I have a server machine (which is an NFS client) which contains multiple chroot environments. I'm mounting the same direc- tory from an NFS server multiple times at different mount points (i.e. one per chroot). There are daemons and other programs running from those NFS directories. Now my question is: If the same daemon is running multiple times within those chroot environments, does the FreeBSD kernel recognize that it is actually the same binary on the NFS server, therefore share the executable and libraries in memory? Or will the executable and libs end up duplicated in memory? When running stat(1) on a multiply mounted executable, the inode numbers are the same, but the minor device numbers are different, so maybe they canot be shared: File: "/chroot/one/bin/httpd" Device: 255,33554437 Inode: 2268790 Links: 1 File: "/chroot/two/bin/httpd" Device: 255,33554439 Inode: 2268790 Links: 1 File: "/chroot/one/bin/httpd" Device: 255,33554458 Inode: 2268790 Links: 1 On the other hand, the kernel should know that the mounts come from the same NFS source, so it might actually be able to handle it efficiently (i.e. share). But I really don't know. Any FreeBSD kernel hacker can enlighten me? If the memory isn't shared in this situation, is there a way to change the design so it can be shared? chroot and NFS are "musts", though. Thanks in advance! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 16:21:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCCC16A4CE for ; Thu, 14 Oct 2004 16:21:14 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78F5643D58 for ; Thu, 14 Oct 2004 16:21:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i9EGL6Wi009073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Oct 2004 09:21:07 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <416EA789.2010808@errno.com> Date: Thu, 14 Oct 2004 09:21:29 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Crumpler References: <416E3722.9070705@crippy.mel.crumpler.com.au> In-Reply-To: <416E3722.9070705@crippy.mel.crumpler.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Oct 2004 12:14:56 +0000 cc: hackers@freebsd.org Subject: Re: can WEP keys be set without resetting a wireless interface? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 16:21:14 -0000 Phillip Crumpler wrote: > Hi hackers, > > Can anyone tell me why setting WEP keys on a wireless interface must > result in the interface being reset? > > I have a wireless authenticator that wants to set random WEP keys and > send them out to connected stations. Setting a key results in the > interface being reset () the ioctl handler return ENETRESET), which > kicks off all of the stations and forces them to reassociate. > > Trying to get around this I just updated the keys directly: > > wk = &ic->ic_nw_keys[nkidx]; > arc4rand(wk->wk_key, wk->wk_len, 0); > > But the moment this happens everyone goes off the air. Of course, that > is the short answer: the interface gets reset because it doesn't work if > it's not :-) > > Can anyone provide a bit more detail or suggest a way around this? The existing API takes a coarse-grained approach to pushing state from the net80211 layer into the driver. That is, when you tweak some parameter in the 802.11 state that might require changing the 802.11 state machine the driver is told to "re-init" so that any changes from the 802.11 layer are pushed down into the driver (and possibly the hardware). This is clearly suboptimal and results in problems like what you see. It is possible for drivers to be more selective in how they treat updates to avoid state machine changes but that gets tedious. What I've done instead is introduce an additional notification mechanism from the net80211 layer to drivers that says "reset your hardware state but don't kick the 802.11 state machine". This eliminates a number of gratuitous state machine changes. For keys and some other state I've also added explicit driver callbacks to bypass both mechanisms. As you've found key state in protocols like WPA and 802.1x (w/o WPA) can change frequently so it's just not feasible to use the coarse-grained notification strategy. The above changes are in the patches I posted yesterday. Sam From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 12:50:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06DB916A4CE for ; Fri, 15 Oct 2004 12:50:03 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D0C143D1D for ; Fri, 15 Oct 2004 12:50:02 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Oct 2004 13:49:48 +0100 (BST) Date: Fri, 15 Oct 2004 13:49:48 +0100 From: David Malone To: Oliver Fromme Message-ID: <20041015124948.GA66898@walton.maths.tcd.ie> References: <200410141427.i9EERcTF056740@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410141427.i9EERcTF056740@lurza.secnetix.de> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 12:50:03 -0000 On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > On the other hand, the kernel should know that the mounts > come from the same NFS source, so it might actually be able > to handle it efficiently (i.e. share). But I really don't > know. Any FreeBSD kernel hacker can enlighten me? Since the server could actually hand out different content depending on the mount instance, I don't think the NFS client could make these assumptions. If you try NFS mounting /usr a few times and then time how long it takes to cat a cached file, you'll see this. > If the memory isn't shared in this situation, is there a > way to change the design so it can be shared? chroot and > NFS are "musts", though. I don't think there is an easy way to get this caching to happen, short of using hard links or some kind of union mount instead of NFS. David. > /usr/bin/time cat /usr/X11R6/bin/Xvfb > /dev/null 0.17 real 0.00 user 0.03 sys > /usr/bin/time cat /usr/X11R6/bin/Xvfb > /dev/null 0.02 real 0.00 user 0.02 sys > /usr/bin/time cat /usr/X11R6/bin/Xvfb > /dev/null 0.02 real 0.00 user 0.02 sys > /usr/bin/time cat /mnt1/X11R6/bin/Xvfb > /dev/null 0.21 real 0.00 user 0.04 sys > /usr/bin/time cat /mnt1/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.03 sys > /usr/bin/time cat /mnt1/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.02 sys > /usr/bin/time cat /mnt2/X11R6/bin/Xvfb > /dev/null 0.21 real 0.00 user 0.04 sys > /usr/bin/time cat /mnt2/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.03 sys > /usr/bin/time cat /mnt2/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.03 sys > /usr/bin/time cat /mnt3/X11R6/bin/Xvfb > /dev/null 0.21 real 0.00 user 0.04 sys > /usr/bin/time cat /mnt3/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.03 sys > /usr/bin/time cat /mnt3/X11R6/bin/Xvfb > /dev/null 0.03 real 0.00 user 0.03 sys From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 15:26:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA9A616A4CE for ; Fri, 15 Oct 2004 15:26:51 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id D52A643D1D for ; Fri, 15 Oct 2004 15:26:50 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Oct 2004 16:26:48 +0100 (BST) To: Peter Edwards In-reply-to: Your message of "Fri, 15 Oct 2004 15:23:33 BST." <34cb7c840410150723733bca5a@mail.gmail.com> X-Request-Do: Date: Fri, 15 Oct 2004 16:26:48 +0100 From: David Malone Message-ID: <200410151626.aa06400@salmon.maths.tcd.ie> cc: freebsd-hackers@freebsd.org cc: Oliver Fromme Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 15:26:52 -0000 > > Since the server could actually hand out different content depending > > on the mount instance, I don't think the NFS client could make these > > assumptions. > Maybe I'm missing something, but I'm not convinced that's true. > NFS is "file-handle" centric: there's no real concept of a "mount > point" at the server: the mount operation just gives you a handle to > the root directory, so if the two mounts from a server give the same > file handles to a client, then the results should be consistent. Yep - I guess you're right - I was thinking that the mountd could be evil and hand out different file handles for the root directory after each mount. If the caching was hung off the file handle and identity of the client&server, then you could probably cache this sort of thing safely. David. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 16:58:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A57B16A4CE for ; Fri, 15 Oct 2004 16:58:06 +0000 (GMT) Received: from web14822.mail.yahoo.com (web14822.mail.yahoo.com [216.136.225.172]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C37543D46 for ; Fri, 15 Oct 2004 16:58:06 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20041015165805.62571.qmail@web14822.mail.yahoo.com> Received: from [212.143.154.227] by web14822.mail.yahoo.com via HTTP; Fri, 15 Oct 2004 09:58:05 PDT Date: Fri, 15 Oct 2004 09:58:05 -0700 (PDT) From: Rostislav Krasny To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Fwd: default resolver(5) configuration and behavior of functions like gethostbyname(3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 16:58:06 -0000 Hello everybody. About two weeks ago I've sent following email to the freebsd-net mailing list but I didn't get any reply of it yet. Could someone of you answer to my questions those I've asked in my original email? Thank you. --- Rostislav Krasny wrote: > From Rostislav Krasny Thu Sep 30 08:31:24 2004 > Thu, 30 Sep 2004 08:31:24 PDT > Date: Thu, 30 Sep 2004 08:31:24 -0700 (PDT) > From: Rostislav Krasny > Subject: default resolver(5) configuration and behavior of functions like > gethostbyname(3) > To: freebsd-net@freebsd.org > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Length: 1462 > > Hello all. Please consider following two questions: > > 1. According to the resolver(5) manual page the default number of times > the > resolver will send a query to each of its name servers is defined as > RES_DFLRETRY in resolv.h standard header file. Actually there was no > RES_DFLRETRY in the resolv.h before following commits to HEAD made by Yar > Tikhiy: > > http://docs.freebsd.org/cgi/mid.cgi?200409091739.i89HdlwM019548 > http://docs.freebsd.org/cgi/mid.cgi?200409091742.i89HgIan019681 > http://docs.freebsd.org/cgi/mid.cgi?200409091719.i89HJRGu019026 > > This default number of retries (the RES_DFLRETRY macro in the HEAD and a > hardcoded constant value in 5.x) is 4. But in most of other UNIX or > UNIX-like systems (Solaris, AIX, Linux, NetBSD) this default value is 2. > Only in OpenBSD it is 4 and also it is a hardcoded constant there. > > Please explain why developers of FreeBSD had chose 4 instead of 2? Maybe > they should change it to 2, as this default value is defined on most of > other systems, including NetBSD? > > > 2. Please consider following experimets I did on FreeBSD 5.3-BETA2-BETA6: > > I changed the /etc/resolv.conf so it had only one following line: > > nameserver 21.21.21.21 > > 21.21.21.21 is just some black-hole host without any working DNS on it. > Then I ran 'tcpdump -nvi ed1' on one pseudo terminal and 'ping yahoo.com' > on other pseudo terminal. This way I counted the "A? yahoo.com." DNS > queries before ping(8) returned an error. With this configuration there > were 8 "A? yahoo.com." DNS queries. Then I added following line to the > /etc/resolv.conf > > options attempts:1 > > With this configuration there were 2 "A? yahoo.com." DNS queries. With > "attempts:2" there were 4 "A? yahoo.com." DNS queries, with "attempts:3" > there were 6 "A? yahoo.com." DNS queries, with "attempts:5" there were 10 > "A? yahoo.com." DNS queries and so on. > > I repeated this experiment with following program been used instead of > the > ping(8): > > #include > #include > #include > #include > #include > #include > > int main(void) > { > const char *name="yahoo.com"; > struct hostent *ps_hostent; > char **st; > > ps_hostent=gethostbyname(name); > if (ps_hostent!=NULL) { > printf("%s\n", ps_hostent->h_name); > for (st=ps_hostent->h_addr_list; *st!=NULL; st++) { > printf("%s\n", > inet_ntoa(*(struct in_addr *)*st)); > } > if (st==ps_hostent->h_addr_list) > fputs("It have no address.\n", stderr); > } else { > herror(name); > } > return 0; > } > > The results where exactly the same. > > Why the number of DNS queries is always doubled? With default resolver(5) > configuration there are 8 DNS queries to one non-working DNS server and > it takes 2:30 minutes before an error returned. IMHO this is too much > time and too much queries for default resolver(5) configuration. Who and > why is doubling the number of DNS queries? Is it gethostbyname(3) > function or the resolver itself? __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 22:48:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD36916A4CE for ; Fri, 15 Oct 2004 22:48:24 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48B6443D1F for ; Fri, 15 Oct 2004 22:48:24 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 58995 invoked by uid 89); 15 Oct 2004 22:56:00 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 15 Oct 2004 22:56:00 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Fri, 15 Oct 2004 16:56:00 -0600 (MDT) Message-ID: <58805.208.4.77.15.1097880960.squirrel@208.4.77.15> In-Reply-To: <20041015165805.62571.qmail@web14822.mail.yahoo.com> References: <20041015165805.62571.qmail@web14822.mail.yahoo.com> Date: Fri, 15 Oct 2004 16:56:00 -0600 (MDT) From: "Ryan Sommers" To: "Rostislav Krasny" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: default resolver(5) configuration and behavior of functions like gethostbyname(3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 22:48:24 -0000 Rostislav Krasny said: >> Please explain why developers of FreeBSD had chose 4 instead of 2? Maybe >> they should change it to 2, as this default value is defined on most of >> other systems, including NetBSD? Don't know why 4 was chosen instead of 2, haven't had a chance to look at the commit logs. We might have ported over the code from OpenBSD and just didn't change their value. >> why is doubling the number of DNS queries? Is it gethostbyname(3) >> function or the resolver itself? Do you have 2 name servers in /etc/resolv.conf? Or do you have a hostname in /etc/resolv.conf that resolves to multiple IPs? -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 00:39:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14BDD16A4CE for ; Sat, 16 Oct 2004 00:39:26 +0000 (GMT) Received: from web14826.mail.yahoo.com (web14826.mail.yahoo.com [216.136.225.197]) by mx1.FreeBSD.org (Postfix) with SMTP id E80EC43D54 for ; Sat, 16 Oct 2004 00:39:25 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20041016003925.95600.qmail@web14826.mail.yahoo.com> Received: from [212.143.154.227] by web14826.mail.yahoo.com via HTTP; Fri, 15 Oct 2004 17:39:25 PDT Date: Fri, 15 Oct 2004 17:39:25 -0700 (PDT) From: Rostislav Krasny To: Ryan Sommers In-Reply-To: <58805.208.4.77.15.1097880960.squirrel@208.4.77.15> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: default resolver(5) configuration and behavior of functions like gethostbyname(3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 00:39:26 -0000 --- Ryan Sommers wrote: > > Rostislav Krasny said: > >> Please explain why developers of FreeBSD had chose 4 instead of 2? > >> Maybe they should change it to 2, as this default value is defined on > >> most of other systems, including NetBSD? > > Don't know why 4 was chosen instead of 2, haven't had a chance to look at > the commit logs. We might have ported over the code from OpenBSD and just > didn't change their value. Yes it looks so at first sight because both FreeBSD (before the foregoing commits of Yar Tikhiy) and OpenBSD have this value hardcoded by no macro definition in the lib/libc/net/res_init.c. After further looking through CVSWEB of these three *BSD OSes I've found following: OpenBSD have this value there since revision 1.11 where BIND 4.9.5 resolver and associated routines were integrated in 1997. FreeBSD have this value there since revision 1.2 where "get* rework and new bind code" was done in 1994. Maybe this value had come from BIND4? NetBSD had that source file too with the same value hardcoded in it till the file (and some others) was removed in May 21 02:30:04 2004 UTC after bind9 resolver merge had been finished. Look at http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/net/Attic/res_init.c The RES_DFLRETRY macro defined in the include/resolv.h of NetBSD since revisions 1.1.1.4 and 1.23 those were made in May 21 2004, during BIND9 merge. The RES_DFLRETRY macro defined as 2 already in those revisions. BIND9 was merged into FreeBSD (RELENG_5 and HEAD) recently. Meybe now is the time to change RES_DFLRETRY from 4 to 2 or even port NetBSD's resolver code? > >> why is doubling the number of DNS queries? Is it gethostbyname(3) > >> function or the resolver itself? > > Do you have 2 name servers in /etc/resolv.conf? Or do you have a hostname > in /etc/resolv.conf that resolves to multiple IPs? All my experimets of DNS queries counting were done with one address of name server (21.21.21.21) defined in the /etc/resolv.conf. Interesting what results would I get on NetBSD 2.0-RCx/RELEASE? _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 14:30:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39AB816A4CE for ; Fri, 15 Oct 2004 14:30:38 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A382343D49 for ; Fri, 15 Oct 2004 14:30:37 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=fYGfW/m4JQUW1GITODwvSofkjqGfTB9fgE0oWbjZMCLI6BbxUv/bkaSW6WKWUF1VLtQragfSN22Ma+GyxJmBLaKg/2DPhc7itb07wgw1NGlFotqTPVa2fZn9y4G44kntqokbp7enBR6XrRsDf9Daz2X8byEitJuT+wh6nYdfWVw Received: by mproxy.gmail.com with SMTP id 74so31219rnk for ; Fri, 15 Oct 2004 07:30:37 -0700 (PDT) Received: by 10.38.181.77 with SMTP id d77mr253976rnf; Fri, 15 Oct 2004 07:29:23 -0700 (PDT) Received: by 10.38.149.43 with HTTP; Fri, 15 Oct 2004 07:29:23 -0700 (PDT) Message-ID: <34cb7c8404101507297970e8dc@mail.gmail.com> Date: Fri, 15 Oct 2004 15:29:23 +0100 From: Peter Edwards To: David Malone In-Reply-To: <20041015124948.GA66898@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410141427.i9EERcTF056740@lurza.secnetix.de> <20041015124948.GA66898@walton.maths.tcd.ie> X-Mailman-Approved-At: Sat, 16 Oct 2004 12:18:22 +0000 cc: freebsd-hackers@freebsd.org cc: Oliver Fromme Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 14:30:38 -0000 On Fri, 15 Oct 2004 13:49:48 +0100, David Malone wrote: > On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > > On the other hand, the kernel should know that the mounts > > come from the same NFS source, so it might actually be able > > to handle it efficiently (i.e. share). But I really don't > > know. Any FreeBSD kernel hacker can enlighten me? > > Since the server could actually hand out different content depending > on the mount instance, I don't think the NFS client could make these > assumptions. If you try NFS mounting /usr a few times and then time > how long it takes to cat a cached file, you'll see this. > Maybe I'm missing something, but I'm not convinced that's true. NFS is "file-handle" centric: there's no real concept of a "mount point" at the server: the mount operation just gives you a handle to the root directory, so if the two mounts from a server give the same file handles to a client, then the results should be consistent. I'd go so far as to say It's even more general than that: a client mounting two different points of the server's filesystem locally could share filehandles if the server's directories intersected (or one was a proper subset of the other, which is more likely) This makes sense, given NFS's statelessness. Of course, given the way the _client_ filesystem code works, it's not going to take advantange of that particular quirk. It's almost certainly not worth doing it at this layer anyhow. (Having two local filesystems trying to share one vnode would be, em, awkward) > > If the memory isn't shared in this situation, is there a > > way to change the design so it can be shared? chroot and > > NFS are "musts", though. > > I don't think there is an easy way to get this caching to happen, > short of using hard links or some kind of union mount instead of > NFS. > "nullfs" sounds like just the job here. ie, mount the NFS filesystem once, then use nullfs to graft it into each chroot area: mount host:/usr /mnt mount -tnullfs /mnt /jail/1 mount -tnullfs /mnt /jail/2 Of course, there's more overhead than if you weren't using the extra nullfs layer, but the caching works as you want. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 14:36:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1088616A4CE for ; Fri, 15 Oct 2004 14:36:50 +0000 (GMT) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387AF43D55 for ; Fri, 15 Oct 2004 14:36:49 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fezkly@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.11/8.12.11) with ESMTP id i9FEalra008011; Fri, 15 Oct 2004 16:36:47 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.11/8.12.11/Submit) id i9FEak3C008009; Fri, 15 Oct 2004 16:36:46 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200410151436.i9FEak3C008009@lurza.secnetix.de> To: peadar.edwards@gmail.com Date: Fri, 15 Oct 2004 16:36:46 +0200 (CEST) In-Reply-To: <34cb7c8404101507297970e8dc@mail.gmail.com> from "Peter Edwards" at Oct 15, 2004 03:29:23 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 16 Oct 2004 12:18:22 +0000 cc: David Malone cc: freebsd-hackers@freebsd.org Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 14:36:50 -0000 Peter Edwards wrote: > On Fri, 15 Oct 2004 13:49:48 +0100, David Malone wrote: > > On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > > > [...] > > > If the memory isn't shared in this situation, is there a > > > way to change the design so it can be shared? chroot and > > > NFS are "musts", though. > > > > I don't think there is an easy way to get this caching to happen, > > short of using hard links or some kind of union mount instead of > > NFS. > > "nullfs" sounds like just the job here. ie, mount the NFS filesystem > once, then use nullfs to graft it into each chroot area: > > mount host:/usr /mnt > mount -tnullfs /mnt /jail/1 > mount -tnullfs /mnt /jail/2 > > Of course, there's more overhead than if you weren't using the extra > nullfs layer, but the caching works as you want. Thanks for the explanation. It really sounds like nullfs would be the solution for me, but unfortunately, I can't use it because of the known pro- blems of nullfs in FreeBSD 4-stable (which is the branch that I'm using). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 15 21:32:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9DAA16A4CE for ; Fri, 15 Oct 2004 21:32:01 +0000 (GMT) Received: from hotmail.com (bay15-f3.bay15.hotmail.com [65.54.185.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7811543D2F for ; Fri, 15 Oct 2004 21:32:01 +0000 (GMT) (envelope-from carlj1752@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Oct 2004 14:32:01 -0700 Received: from 18.97.6.72 by by15fd.bay15.hotmail.msn.com with HTTP; Fri, 15 Oct 2004 21:31:38 GMT X-Originating-IP: [18.97.6.72] X-Originating-Email: [carlj1752@hotmail.com] X-Sender: carlj1752@hotmail.com From: "Carl J" To: freebsd-hackers@freebsd.org Date: Fri, 15 Oct 2004 17:31:38 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Oct 2004 21:32:01.0027 (UTC) FILETIME=[680BFD30:01C4B2FE] X-Mailman-Approved-At: Sat, 16 Oct 2004 12:18:22 +0000 Subject: open() vs the lowest unused file descriptor X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 21:32:01 -0000 Hi! Today I noticed that on Single Unix Specification V2, as well as on the Linux 2.4.26 machine I have here, that the open() call promises to return the lowest unused file descriptor when successful. I'm just wondering: does FreeBSD 4.x and 5.x promise that? If so, should we update the manpage to match SUSv2 more closely? Thank you! - Carl _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 12:59:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17F9A16A4CE for ; Sat, 16 Oct 2004 12:59:52 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1794F43D2D for ; Sat, 16 Oct 2004 12:59:51 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i9GCxgi9013238; Sat, 16 Oct 2004 22:29:42 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sat, 16 Oct 2004 22:29:31 +0930 User-Agent: KMail/1.7 References: <200410141427.i9EERcTF056740@lurza.secnetix.de> In-Reply-To: <200410141427.i9EERcTF056740@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1302041.UR18Tb3Lj0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410162229.38715.doconnor@gsoft.com.au> X-Spam-Score: -1.7 () IN_REP_TO,PGP_SIGNATURE_2,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Oliver Fromme Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 12:59:52 -0000 --nextPart1302041.UR18Tb3Lj0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Oct 2004 23:57, Oliver Fromme wrote: > File: "/chroot/one/bin/httpd" > Device: 255,33554437 Inode: 2268790 Links: 1 > File: "/chroot/two/bin/httpd" > Device: 255,33554439 Inode: 2268790 Links: 1 > File: "/chroot/one/bin/httpd" > Device: 255,33554458 Inode: 2268790 Links: 1 You could do hardlink tricks (and chflags to prevent one jail attacking the= =20 others).. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1302041.UR18Tb3Lj0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBcRs65ZPcIHs/zowRAr09AJ9e8QDQRI/iGZ30FFFmZoRxNdPk0wCdGmcD F/qprrHwOdrEV8Zf1B1wIyA= =ekQA -----END PGP SIGNATURE----- --nextPart1302041.UR18Tb3Lj0-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 14:50:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDC4116A4CF for ; Sat, 16 Oct 2004 14:50:50 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id DF7CF43D46 for ; Sat, 16 Oct 2004 14:50:49 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 61811 invoked by uid 0); 16 Oct 2004 14:49:49 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.165.205) by node15.coopprint.com with SMTP; 16 Oct 2004 14:49:49 -0000 Message-ID: <4171354F.9090400@gamersimpact.com> Date: Sat, 16 Oct 2004 09:50:55 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl J References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: open() vs the lowest unused file descriptor X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 14:50:50 -0000 Carl J wrote: > Hi! > > Today I noticed that on Single Unix Specification V2, > as well as on the Linux 2.4.26 machine I have here, > that the open() call promises to return the lowest > unused file descriptor when successful. > > I'm just wondering: does FreeBSD 4.x and 5.x promise > that? If so, should we update the manpage > to match SUSv2 more closely? > > Thank you! > > - Carl 4.x I'm pretty sure about 5.x I know does. This isn't a new thing. Since as far back as I can remember the UNIX semantics have been to return the lowest unused fd on an open(2) call. This has also been the subject of much discussion as finding the first free descriptor can cost a lot of processing power for applications that use large numbers of descriptors. FreeBSD uses a bitmap with hints I believe. All code would be in sys/kern_descrip.c. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 15:18:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4F3016A4CE for ; Sat, 16 Oct 2004 15:18:44 +0000 (GMT) Received: from caine.easynet.fr (smarthost150.mail.easynet.fr [212.180.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CA2B43D1D for ; Sat, 16 Oct 2004 15:18:44 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from [212.180.127.72] (helo=tatooine.tataz.chchile.org) by caine.easynet.fr with esmtp (Exim 4.34) id 1CIqKQ-0006Eo-7V; Sat, 16 Oct 2004 17:18:42 +0200 Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id BC18D40B0; Sat, 16 Oct 2004 17:18:43 +0200 (CEST) Date: Sat, 16 Oct 2004 17:18:43 +0200 From: Jeremie Le Hen To: Oliver Fromme Message-ID: <20041016151842.GH729@obiwan.tataz.chchile.org> References: <34cb7c8404101507297970e8dc@mail.gmail.com> <200410151436.i9FEak3C008009@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410151436.i9FEak3C008009@lurza.secnetix.de> User-Agent: Mutt/1.5.6i X-Broken-Reverse-DNS: no host name found for IP address 212.180.127.72 cc: freebsd-hackers@freebsd.org Subject: Re: NFS + VM question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 15:18:45 -0000 > It really sounds like nullfs would be the solution for me, > but unfortunately, I can't use it because of the known pro- > blems of nullfs in FreeBSD 4-stable (which is the branch > that I'm using). It would definitely be the solution, but there are still problems with it. Mark Liminon made a call for PR concerning nullfs a few month ago. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1874558+0+archive/2004/freebsd-current/20040718.freebsd-current AFAIK, none of the above problems has been solved, but I may be wrong. -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 16:19:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54A8616A4CE for ; Sat, 16 Oct 2004 16:19:57 +0000 (GMT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9803D43D5F for ; Sat, 16 Oct 2004 16:19:56 +0000 (GMT) (envelope-from marck@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.1/8.13.1) with ESMTP id i9GGJtm9085847; Sat, 16 Oct 2004 20:19:55 +0400 (MSD) (envelope-from marck@FreeBSD.org) Date: Sat, 16 Oct 2004 20:19:55 +0400 (MSD) From: Dmitry Morozovsky X-X-Sender: marck@woozle.rinet.ru To: hackers@FreeBSD.org Message-ID: <20041016201612.N53591@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1254507317-1097943567=:53591" Content-ID: <20041016201933.H53591@woozle.rinet.ru> cc: oleg@rinet.ru Subject: thread-safe popen(3) at 4-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 16:19:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1254507317-1097943567=:53591 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20041016201933.R53591@woozle.rinet.ru> Dear colleagues, checking for hanged and CPU-eating clamav, my colleague (oleg@rinet.ru) found that popen(3) is not thread safe. What about commiting tjr's fix (attached) to RELENG_4? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@FreeBSD.org *** --------------------------------------------------------------------------- --0-1254507317-1097943567=:53591 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="popen.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20041016201927.L53591@woozle.rinet.ru> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="popen.patch" SW5kZXg6IGxpYi9saWJjL2dlbi9wb3Blbi5jDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvbGliL2xpYmMvZ2Vu L3BvcGVuLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE0DQpkaWZmIC11 IC1yMS4xNCBwb3Blbi5jDQotLS0gbGliL2xpYmMvZ2VuL3BvcGVuLmMJMjcg SmFuIDIwMDAgMjM6MDY6MTkgLTAwMDAJMS4xNA0KKysrIGxpYi9saWJjL2dl bi9wb3Blbi5jCTE2IE9jdCAyMDA0IDE2OjE0OjM4IC0wMDAwDQpAQCAtNTEs NiArNTEsMTcgQEANCiAjaW5jbHVkZSA8c3RyaW5nLmg+DQogI2luY2x1ZGUg PHBhdGhzLmg+DQogDQorI2lmbmRlZiBfVEhSRUFEX1NBRkUNCisjZGVmaW5l IFRIUkVBRF9MT0NLKCkNCisjZGVmaW5lIFRIUkVBRF9VTkxPQ0soKQ0KKyNl bHNlDQorI2luY2x1ZGUgPHB0aHJlYWQuaD4NCisjaW5jbHVkZSAibGliY19w cml2YXRlLmgiDQorc3RhdGljIHB0aHJlYWRfbXV0ZXhfdCBwaWRsaXN0X211 dGV4ID0gUFRIUkVBRF9NVVRFWF9JTklUSUFMSVpFUjsNCisjZGVmaW5lCVRI UkVBRF9MT0NLKCkJaWYgKF9faXN0aHJlYWRlZCkgX3B0aHJlYWRfbXV0ZXhf bG9jaygmcGlkbGlzdF9tdXRleCkNCisjZGVmaW5lCVRIUkVBRF9VTkxPQ0so KQlpZiAoX19pc3RocmVhZGVkKSBfcHRocmVhZF9tdXRleF91bmxvY2soJnBp ZGxpc3RfbXV0ZXgpDQorI2VuZGlmIC8qIF9USFJFQURfU0FGRSAqLw0KKw0K IGV4dGVybiBjaGFyICoqZW52aXJvbjsNCiANCiBzdGF0aWMgc3RydWN0IHBp ZCB7DQpAQCAtOTUsOCArMTA2LDEwIEBADQogCWFyZ3ZbMl0gPSAoY2hhciAq KWNvbW1hbmQ7DQogCWFyZ3ZbM10gPSBOVUxMOw0KIA0KKwlUSFJFQURfTE9D SygpOw0KIAlzd2l0Y2ggKHBpZCA9IHZmb3JrKCkpIHsNCiAJY2FzZSAtMToJ CQkvKiBFcnJvci4gKi8NCisJCVRIUkVBRF9VTkxPQ0soKTsNCiAJCSh2b2lk KV9jbG9zZShwZGVzWzBdKTsNCiAJCSh2b2lkKV9jbG9zZShwZGVzWzFdKTsN CiAJCWZyZWUoY3VyKTsNCkBAIC0xMzQsNiArMTQ3LDcgQEANCiAJCV9leGl0 KDEyNyk7DQogCQkvKiBOT1RSRUFDSEVEICovDQogCX0NCisJVEhSRUFEX1VO TE9DSygpOw0KIA0KIAkvKiBQYXJlbnQ7IGFzc3VtZSBmZG9wZW4gY2FuJ3Qg ZmFpbC4gKi8NCiAJaWYgKCp0eXBlID09ICdyJykgew0KQEAgLTE0Niw5ICsx NjAsMTEgQEANCiANCiAJLyogTGluayBpbnRvIGxpc3Qgb2YgZmlsZSBkZXNj cmlwdG9ycy4gKi8NCiAJY3VyLT5mcCA9IGlvcDsNCi0JY3VyLT5waWQgPSAg cGlkOw0KKwljdXItPnBpZCA9IHBpZDsNCisJVEhSRUFEX0xPQ0soKTsNCiAJ Y3VyLT5uZXh0ID0gcGlkbGlzdDsNCiAJcGlkbGlzdCA9IGN1cjsNCisJVEhS RUFEX1VOTE9DSygpOw0KIA0KIAlyZXR1cm4gKGlvcCk7DQogfQ0KQEAgLTE2 NywxMiArMTgzLDIzIEBADQogCWludCBwc3RhdDsNCiAJcGlkX3QgcGlkOw0K IA0KLQkvKiBGaW5kIHRoZSBhcHByb3ByaWF0ZSBmaWxlIHBvaW50ZXIuICov DQorCS8qDQorCSAqIEZpbmQgdGhlIGFwcHJvcHJpYXRlIGZpbGUgcG9pbnRl ciBhbmQgcmVtb3ZlIGl0IGZyb20gdGhlIGxpc3QuDQorCSAqLw0KKwlUSFJF QURfTE9DSygpOw0KIAlmb3IgKGxhc3QgPSBOVUxMLCBjdXIgPSBwaWRsaXN0 OyBjdXI7IGxhc3QgPSBjdXIsIGN1ciA9IGN1ci0+bmV4dCkNCiAJCWlmIChj dXItPmZwID09IGlvcCkNCiAJCQlicmVhazsNCi0JaWYgKGN1ciA9PSBOVUxM KQ0KKwlpZiAoY3VyID09IE5VTEwpIHsNCisJCVRIUkVBRF9VTkxPQ0soKTsN CiAJCXJldHVybiAoLTEpOw0KKwl9DQorCS8qIFJlbW92ZSB0aGUgZW50cnkg ZnJvbSB0aGUgbGlua2VkIGxpc3QuICovDQorCWlmIChsYXN0ID09IE5VTEwp DQorCQlwaWRsaXN0ID0gY3VyLT5uZXh0Ow0KKwllbHNlDQorCQlsYXN0LT5u ZXh0ID0gY3VyLT5uZXh0Ow0KKwlUSFJFQURfVU5MT0NLKCk7DQogDQogCSh2 b2lkKWZjbG9zZShpb3ApOw0KIA0KQEAgLTE4MCwxMSArMjA3LDYgQEANCiAJ CXBpZCA9IF93YWl0NChjdXItPnBpZCwgJnBzdGF0LCAwLCAoc3RydWN0IHJ1 c2FnZSAqKTApOw0KIAl9IHdoaWxlIChwaWQgPT0gLTEgJiYgZXJybm8gPT0g RUlOVFIpOw0KIA0KLQkvKiBSZW1vdmUgdGhlIGVudHJ5IGZyb20gdGhlIGxp bmtlZCBsaXN0LiAqLw0KLQlpZiAobGFzdCA9PSBOVUxMKQ0KLQkJcGlkbGlz dCA9IGN1ci0+bmV4dDsNCi0JZWxzZQ0KLQkJbGFzdC0+bmV4dCA9IGN1ci0+ bmV4dDsNCiAJZnJlZShjdXIpOw0KIA0KIAlyZXR1cm4gKHBpZCA9PSAtMSA/ IC0xIDogcHN0YXQpOw0K --0-1254507317-1097943567=:53591-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 16 17:23:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E7AD16A4CE for ; Sat, 16 Oct 2004 17:23:15 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id A077D43D2F for ; Sat, 16 Oct 2004 17:23:13 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 59002 invoked by uid 0); 16 Oct 2004 17:18:31 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 16 Oct 2004 17:18:31 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 204D3130E92 for ; Sun, 17 Oct 2004 01:23:08 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01797-02 for ; Sun, 17 Oct 2004 01:23:04 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 55A4D130E1D; Sun, 17 Oct 2004 01:23:02 +0800 (CST) Date: Sun, 17 Oct 2004 01:23:02 +0800 From: Xin LI To: freebsd-hackers@FreeBSD.org Message-ID: <20041016172302.GA2764@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #4: Mon Sep 13 12:44:05 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Subject: [PATCH] add '-' glibc extension to strftime(3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 17:23:15 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, folks, It turns out that the GNU extension '-' in their strftime(3) implementation is somewhat popular in several applications. The patch in the last part of this e-mail will add a simulate implementation for it. My question is: (1) Am I doing things cleanly and correctly? I have attempted to keep the code style consistent with the old one and style(9) but maybe I have missed something else, or did not do it sufficently? (2) Is the way of implementing it clean enough? Thanks for any comments! Index: strftime.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/fcvs/src/lib/libc/stdtime/strftime.3,v retrieving revision 1.34 diff -u -r1.34 strftime.3 --- strftime.3 2 Jul 2004 23:52:12 -0000 1.34 +++ strftime.3 16 Oct 2004 17:13:08 -0000 @@ -36,7 +36,7 @@ .\" @(#)strftime.3 8.1 (Berkeley) 6/4/93 .\" $FreeBSD: src/lib/libc/stdtime/strftime.3,v 1.34 2004/07/02 23:52:12 r= u Exp $ .\" -.Dd January 4, 2003 +.Dd October 17, 2004 .Dt STRFTIME 3 .Os .Sh NAME @@ -216,6 +216,8 @@ is replaced by national representation of the date and time (the format is similar to that produced by .Xr date 1 ) . +.It Cm %-* +GLIBC extensions. Do not do padding when making output. .It Cm %% is replaced by .Ql % . Index: strftime.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/fcvs/src/lib/libc/stdtime/strftime.c,v retrieving revision 1.40 diff -u -r1.40 strftime.c --- strftime.c 14 Jun 2004 10:31:52 -0000 1.40 +++ strftime.c 16 Oct 2004 17:14:24 -0000 @@ -59,6 +59,13 @@ #define IN_THIS 2 #define IN_ALL 3 =20 +#define PAD_DEFAULT 0 +#define PAD_LESS 1 +#if 0 /* XXX NOT IMPLEMENTED YET */ +#define PAD_SPACE 2 +#define PAD_ZERO 3 +#endif + size_t strftime(char * __restrict s, size_t maxsize, const char * __restrict form= at, const struct tm * __restrict t) @@ -99,13 +106,14 @@ const char * const ptlim; int * warnp; { - int Ealternative, Oalternative; + int Ealternative, Oalternative, Palternative; struct lc_time_T *tptr =3D __get_current_time_locale(); =20 for ( ; *format; ++format) { if (*format =3D=3D '%') { Ealternative =3D 0; Oalternative =3D 0; + Palternative =3D PAD_DEFAULT; label: switch (*++format) { case '\0': @@ -188,21 +196,27 @@ Oalternative++; goto label; case 'e': - pt =3D _conv(t->tm_mday, "%2d", pt, ptlim); + pt =3D _conv(t->tm_mday, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%2d", + pt, ptlim); continue; case 'F': pt =3D _fmt("%Y-%m-%d", t, pt, ptlim, warnp); continue; case 'H': - pt =3D _conv(t->tm_hour, "%02d", pt, ptlim); + pt =3D _conv(t->tm_hour, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 'I': pt =3D _conv((t->tm_hour % 12) ? - (t->tm_hour % 12) : 12, - "%02d", pt, ptlim); + (t->tm_hour % 12) : 12, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 'j': - pt =3D _conv(t->tm_yday + 1, "%03d", pt, ptlim); + pt =3D _conv(t->tm_yday + 1, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%03d", pt, ptlim); continue; case 'k': /* @@ -215,7 +229,9 @@ ** "%l" have been swapped. ** (ado, 1993-05-24) */ - pt =3D _conv(t->tm_hour, "%2d", pt, ptlim); + pt =3D _conv(t->tm_hour, (Palternative =3D=3D PAD_LESS) ? + "%d": "%2d", + pt, ptlim); continue; #ifdef KITCHEN_SINK case 'K': @@ -236,14 +252,19 @@ ** (ado, 1993-05-24) */ pt =3D _conv((t->tm_hour % 12) ? - (t->tm_hour % 12) : 12, - "%2d", pt, ptlim); + (t->tm_hour % 12) : 12, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%2d", + pt, ptlim); continue; case 'M': - pt =3D _conv(t->tm_min, "%02d", pt, ptlim); + pt =3D _conv(t->tm_min, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 'm': - pt =3D _conv(t->tm_mon + 1, "%02d", pt, ptlim); + pt =3D _conv(t->tm_mon + 1, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 'n': pt =3D _add("\n", pt, ptlim); @@ -262,7 +283,9 @@ warnp); continue; case 'S': - pt =3D _conv(t->tm_sec, "%02d", pt, ptlim); + pt =3D _conv(t->tm_sec, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 's': { @@ -289,8 +312,8 @@ continue; case 'U': pt =3D _conv((t->tm_yday + DAYSPERWEEK - - t->tm_wday) / DAYSPERWEEK, - "%02d", pt, ptlim); + t->tm_wday) / DAYSPERWEEK, (Palternative =3D=3D PAD_LESS) ? + "%d" : "%02d", pt, ptlim); continue; case 'u': /* @@ -423,11 +446,13 @@ continue; case 'y': *warnp =3D IN_ALL; - pt =3D _conv((t->tm_year + TM_YEAR_BASE) % 100, - "%02d", pt, ptlim); + pt =3D _conv((t->tm_year + TM_YEAR_BASE) % 100, (Palternative =3D=3D P= AD_LESS) ? + "%d" : "%02d", + pt, ptlim); continue; case 'Y': - pt =3D _conv(t->tm_year + TM_YEAR_BASE, "%04d", + pt =3D _conv(t->tm_year + TM_YEAR_BASE, (Palternative =3D=3D PAD_LESS)= ? + "%d" : "%04d", pt, ptlim); continue; case 'Z': @@ -501,6 +526,23 @@ pt =3D _fmt(tptr->date_fmt, t, pt, ptlim, warnp); continue; + case '-': + if (Palternative !=3D PAD_DEFAULT) + break; + Palternative =3D PAD_LESS; + goto label; +#if 0 /* XXX NOT IMPLEMENTED YET */ + case '_': + if (Palternative !=3D PAD_DEFAULT) + break; + Palternative =3D PAD_SPACE; + goto label; + case '0': + if (Palternative !=3D PAD_DEFAULT) + break; + Palternative =3D PAD_ZERO; + goto label; +#endif case '%': /* ** X311J/88-090 (4.12.3.5): if conversion char is --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBcVj2/cVsHxFZiIoRAi+pAKCGPA4g2L71AyR1kHfNBOo4KyaBPgCdFu4K QEphXtBLZogNaLH6fGL3l0g= =nI+R -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z--