From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 09:46:29 2003 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 7C70B37B401; Sun, 13 Apr 2003 09:46:29 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66FF743FD7; Sun, 13 Apr 2003 09:46:28 -0700 (PDT) (envelope-from kabaev@bellatlantic.net) Received: from kanhome ([151.203.222.111]) by pop018.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030413164627.FFJO1699.pop018.verizon.net@kanhome>; Sun, 13 Apr 2003 11:46:27 -0500 Date: Sun, 13 Apr 2003 12:46:26 -0400 From: Alexander Kabaev To: hackers@freebsd.org Message-Id: <20030413124626.5e782421.kabaev@bellatlantic.net> In-Reply-To: <20030413012636.GA76030@dragon.nuxi.com> References: <5.2.0.9.2.20030411082040.02604e90@194.184.65.4> <200304120241.h3C2fQCc061882@latour.rsch.comm.mot.com> <20030413012636.GA76030@dragon.nuxi.com> X-Mailer: Sylpheed version 0.8.10claws18 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [151.203.222.111] at Sun, 13 Apr 2003 11:46:27 -0500 cc: gmarco@giovannelli.it cc: rittle@latour.rsch.comm.mot.com Subject: Re: gcc iussue or ... ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ak03@gte.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 16:46:29 -0000 On Sat, 12 Apr 2003 18:26:36 -0700 "David O'Brien" wrote: > I'm not sure we should change FreeBSD to do something that purposfully > produces wrong semantics. From your test it sounds like either GCC > 3.3 or Binutils 2.13.2.1 changes things for us. I haven't updated > FreeBSD to 2.13.2.1 as the changes from 2.13.2 don't really change any > of the FreeBSD architectures. The behavior change is probably due to > improved g++ utilization of ELF features, or your FreeBSD-related bug > fixes in 3.3. > I think there is a slight confusion here. It is -fconserve-space flag what introduces wrong semantics, not the addition of missing definition. -fconserve-space marks all uninitialized static variables as 'common' which can obviously lead to unwanted namespace collisions. -- Alexander Kabaev From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 10:53:43 2003 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 A887937B405 for ; Sun, 13 Apr 2003 10:53:43 -0700 (PDT) Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id D916543FAF for ; Sun, 13 Apr 2003 10:53:41 -0700 (PDT) (envelope-from brian@shadowcom.net) Received: from shadowcom.net ([68.100.212.237]) by lakemtao02.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030413175341.KKHV24359.lakemtao02.cox.net@shadowcom.net> for ; Sun, 13 Apr 2003 13:53:41 -0400 Received: (qmail 33126 invoked by uid 500); 13 Apr 2003 17:55:28 -0000 Date: Sun, 13 Apr 2003 13:55:28 -0400 From: Brian Ledbetter To: hackers@freebsd.org Message-ID: <20030413175528.GB32297@shadowcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: dev/usb/uvisor - Sony Clie PEG-S360 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, 13 Apr 2003 17:53:44 -0000 Hiya, everyone. Who is the current maintainer of the 'uvisor' driver? I have a somewhat obscure Sony PDA that I would love to help add support for. :) In dmesg, it identifies itself as: ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ugen0: at uhub0 port 2 (addr 2) disconnected ugen0: detached usbdevs -v reports: port 1 addr 2: full speed, self powered, config 1, Palm Handheld(0x0095), Palm, Inc.(0x054c), rev 1.00 The device ends up attaching to the ugen driver, as uvisor doesn't claim it (it only thinks that it supports devices 0x009a and 0x0066). The device is running PalmOS 4.0, for what it's worth. I tried adding it to the uvisor driver (by adding it to usbdevs and into uvisor_devs[]), but got some kind of "timeout" error messages when the device attached. I'm running FreeBSD 5.0-RELEASE-p7, and would be willing to switch to -CURRENT if necessary... Thanks in advance, -- Brian Ledbetter http://www.shadowcom.net/brian/ From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 11:28:11 2003 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 57E3D37B417; Sun, 13 Apr 2003 11:28:11 -0700 (PDT) Received: from samson.dc.luth.se (samson.dc.luth.se [130.240.112.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C109D43F75; Sun, 13 Apr 2003 11:28:09 -0700 (PDT) (envelope-from bj@dc.luth.se) Received: from dc.luth.se (root@bompe.dc.luth.se [130.240.60.42]) by samson.dc.luth.se (8.12.5/8.12.5) with ESMTP id h3DIRxLG014071; Sun, 13 Apr 2003 20:27:59 +0200 (MET DST) Received: from bompe.dc.luth.se (bj@localhost.dc.luth.se [127.0.0.1]) by dc.luth.se (8.12.6/8.11.3) with ESMTP id h3DIRv2F004468; Sun, 13 Apr 2003 20:27:57 +0200 (CEST) (envelope-from bj@bompe.dc.luth.se) Message-Id: <200304131827.h3DIRv2F004468@dc.luth.se> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert In-reply-to: Your message of Fri, 11 Apr 2003 09:32:51 PDT. <3E96EE33.FAF4FABB@mindspring.com> Dcc: X-Disposition-notification-to: Borje.Josefsson@dc.luth.se X-uri: http://www.dc.luth.se/~bj/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Apr 2003 20:27:57 +0200 From: Borje Josefsson cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: "Jin Guojun \[DSD\]" cc: Eric Anderson cc: David Gilbert Subject: Re: tcp_output starving -- is due to mbuf get delay? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bj@dc.luth.se List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 18:28:11 -0000 On Fri, 11 Apr 2003 09:32:51 PDT Terry Lambert wrote: > See other posting; I listed a bunch of OIDs to play with. > = > One other, if you are running -CURRENT, would be: > = > net.isr.netisr_enable -> 1 I found "net.isr.enable", I hope that is what You mean. > This basically implements part 1 of 3 of LRP, which should > reduce your per packet latency by about 50ms +/- 50ms. > = > Note: The logic here is inverted; you'd expect "0=3DNo NETISR", > but it's just the opposite. I tried to install -current on a third system (just a PIII-933, with 33MH= z = bus) today: root@stinky 4# ttcp -s -t -f m -l 61440 -n 20345 dino ttcp-t: buflen=3D61440, nbuf=3D20345, align=3D16384/0, port=3D5001 tcp -= > dino ttcp-t: socket ttcp-t: connect ttcp-t: 1249996800 bytes in 27.04 real seconds =3D 352.65 Mbit/sec +++ ttcp-t: 20345 I/O calls, msec/call =3D 1.36, calls/sec =3D 752.31 ttcp-t: 0.0user 15.6sys 0:27real 57% 15i+359d 420maxrss 0+0pf 16+44950csw= root@stinky 5# = root@stinky 5# sysctl net.isr.enable=3D1 net.isr.enable: 0 -> 1 root@stinky 6# ttcp -s -t -f m -l 61440 -n 20345 dino ttcp-t: buflen=3D61440, nbuf=3D20345, align=3D16384/0, port=3D5001 tcp -= > dino ttcp-t: socket ttcp-t: connect ttcp-t: 1249996800 bytes in 27.27 real seconds =3D 349.70 Mbit/sec +++ ttcp-t: 20345 I/O calls, msec/call =3D 1.37, calls/sec =3D 746.03 ttcp-t: 0.0user 16.4sys 0:27real 60% 15i+355d 420maxrss 0+0pf 15+70547csw= I.e. no change. The same host with NetBSD gives me at least 525 Mbit/sec.= The symptoms with -current are the same as before. 100% CPU load. Note the strange behaviour on netstat below. I start at 50kpps (output), = and then fall back to 27,5k (steady). input (Total) output packets errs bytes packets errs bytes colls 16177 0 1067840 28767 0 43555599 0 28563 0 1885158 50583 0 76573756 0 28566 0 1885356 50582 0 76575270 0 28492 0 1880472 50451 0 76381478 0 28538 0 1883508 50534 0 76511682 0 27723 0 1829718 49096 0 74325466 0 15173 0 1001418 27498 0 41628940 0 15268 0 1007688 27581 0 41755578 0 15230 0 1005180 27498 0 41628732 0 15280 0 1008480 27498 0 41627892 0 15290 0 1009140 27624 0 41820384 0 15244 0 1006104 27498 0 41628172 0 15229 0 1005114 27498 0 41628108 0 15287 0 1008942 27540 0 41692056 0 15200 0 1003194 27413 0 41500866 0 15292 0 1009272 27625 0 41820522 0 15221 0 1004586 27411 0 41498918 0 15239 0 1005774 27540 0 41692552 0 15206 0 1003596 27540 0 41692752 0 15265 0 1007490 27584 0 41756928 0 15222 0 1004652 27539 0 41691102 0 15209 0 1003794 27540 0 41692944 0 15185 0 1002210 27496 0 41627448 0 15253 0 1006698 27540 0 41693344 0 15191 0 1002606 27496 0 41626656 0 15176 0 1001616 27540 0 41692880 0 15232 0 1005312 27627 0 41821342 0 2876 0 189816 5183 0 7838606 0 stinky# netstat -ss tcp: 863330 packets sent 863320 data packets (1250011712 bytes) 1 data packet (1448 bytes) retransmitted 9 ack-only packets (0 delayed) 1 control packet 483425 packets received 446021 acks (for 1250011665 bytes) 29 packets (1344 bytes) received in-sequence 37376 window update packets 1 connection request 1 connection established (including accepts) 1 connection updated cached RTT on close 1 connection updated cached RTT variance on close 446021 segments updated rtt (of 21215 attempts) 11864 correct ACK header predictions 26 correct data packet header predictions If time permits tomorrow, I'll install -current on one of the faster = hosts, but I don't think it will make any significant difference. --B=F6rje From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 12:42:14 2003 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 BEA1937B401 for ; Sun, 13 Apr 2003 12:42:14 -0700 (PDT) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0079A43FB1 for ; Sun, 13 Apr 2003 12:42:14 -0700 (PDT) (envelope-from joe@genius.tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id 05BCD4439; Sun, 13 Apr 2003 20:42:10 +0100 (BST) Date: Sun, 13 Apr 2003 20:42:09 +0100 From: Josef Karthauser To: Brian Ledbetter Message-ID: <20030413194209.GC92799@genius.tao.org.uk> References: <20030413175528.GB32297@shadowcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk" Content-Disposition: inline In-Reply-To: <20030413175528.GB32297@shadowcom.net> User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: dev/usb/uvisor - Sony Clie PEG-S360 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, 13 Apr 2003 19:42:15 -0000 --HG+GLK89HZ1zG0kk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 13, 2003 at 01:55:28PM -0400, Brian Ledbetter wrote: > Hiya, everyone. Who is the current maintainer of the 'uvisor' > driver? I have a somewhat obscure Sony PDA that I would love > to help add support for. :) >=20 > I'm running FreeBSD 5.0-RELEASE-p7, and would be willing to switch to=20 > -CURRENT if necessary... >=20 You shouldn't need to switch to -current, as it's only a few lines of code to get the uvisor to attach to the Clie. That unfortunately isn't the problem. We've got an issue with compatibility with palm os > 4.0 and I've not been able to determine what it is yet. There's an interaction somewhere in the stack that causes the palmos stack to stop sending data... unfortuately I can't give you a time scale as to how long it will take to get it fixed. Joe --HG+GLK89HZ1zG0kk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iEYEARECAAYFAj6ZvZEACgkQXVIcjOaxUBaz7wCfatN4dWDhBXRGyK3AoFa7AzAd otcAn2SoFuug1NP0tsJ+dh0hQ1srlmeJ =6gSE -----END PGP SIGNATURE----- --HG+GLK89HZ1zG0kk-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 15:12:20 2003 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 8B56237B401 for ; Sun, 13 Apr 2003 15:12:20 -0700 (PDT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF2FE43F85 for ; Sun, 13 Apr 2003 15:12:19 -0700 (PDT) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-7-62-147-154-217.dial.proxad.net [62.147.154.217]) by postfix3-2.free.fr (Postfix) with SMTP id E9E1DC12D for ; Mon, 14 Apr 2003 00:12:18 +0200 (CEST) Received: (qmail 21096 invoked by uid 1001); 13 Apr 2003 22:36:56 -0000 Date: Sun, 13 Apr 2003 22:36:56 +0000 From: Nicolas Souchu To: hackers@freebsd.org Message-ID: <20030413223656.A21075@armor.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: infinite loop in 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: Sun, 13 Apr 2003 22:12:20 -0000 Hi folks, I'm trying to debug some infinite loop in the kernel. I guess this is the problem since key interrupts are still working but the system does not respond otherwise. Unfortunatly, breaking in the debugger only gives my the trace of the kbd intr thread... Which data structure should I check? Thanks. Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 15:15:38 2003 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 132CD37B401 for ; Sun, 13 Apr 2003 15:15:38 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2154C43F75 for ; Sun, 13 Apr 2003 15:15:37 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3DMFRSA003404; Mon, 14 Apr 2003 00:15:32 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Nicolas Souchu From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 13 Apr 2003 22:36:56 -0000." <20030413223656.A21075@armor.free.fr> Date: Mon, 14 Apr 2003 00:15:27 +0200 Message-ID: <3403.1050272127@critter.freebsd.dk> cc: hackers@freebsd.org Subject: Re: infinite loop in 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: Sun, 13 Apr 2003 22:15:38 -0000 In message <20030413223656.A21075@armor.free.fr>, Nicolas Souchu writes: > >Hi folks, > >I'm trying to debug some infinite loop in the kernel. I guess >this is the problem since key interrupts are still working but >the system does not respond otherwise. > >Unfortunatly, breaking in the debugger only gives my the >trace of the kbd intr thread... > >Which data structure should I check? Use "ps" in DDB to see which processes are runnable for instance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 16:01:29 2003 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 7455137B401; Sun, 13 Apr 2003 16:01:29 -0700 (PDT) Received: from jhs.muc.de (pD950EEF7.dip.t-dialin.net [217.80.238.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A7E43F93; Sun, 13 Apr 2003 16:01:26 -0700 (PDT) (envelope-from jhs@berklix.com) Received: from flip.jhs.private (flip.jhs.private [192.168.91.24]) by jhs.muc.de (8.11.6/8.11.6) with ESMTP id h3DN1Qv81462; Mon, 14 Apr 2003 01:01:26 +0200 (CEST) (envelope-from jhs@berklix.com) Received: (from jhs@localhost) by flip.jhs.private (8.11.6/8.11.6) id h3DN0sM91460; Mon, 14 Apr 2003 01:00:54 +0200 (CEST) (envelope-from jhs) Date: Mon, 14 Apr 2003 01:00:54 +0200 (CEST) From: Julian Stacey Message-Id: <200304132300.h3DN0sM91460@flip.jhs.private> To: freebsd-hackers@freebsd.org Fcc: sent-mail In-Reply-To: Message from Erik Trulsson <20030410193810.GA52024@falcon.midgard.homeip.net> Organization: http://www.berklix.com/~jhs/vsl/ Fcc: sent-mail cc: Michael Elbel Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 13 Apr 2003 23:01:29 -0000 Erik Trulsson wrote: > On Thu, Apr 10, 2003 at 08:43:04PM +0200, Julian Stacey wrote: > > Anyone seen 4.8-RELEASE running on a real 386 processor (not a 486, 586 etc > > Try the following patch. > Makes my 386sx/33 work fine at least. > (Without it I get the same panic as you do.) This works :-) I'm now running 4.8, Thanks ! ----------- > From: John Baldwin > > Try the following patch. > > Makes my 386sx/33 work fine at least. > > (Without it I get the same panic as you do.) > > Oh my, I hope that isn't it. If so it's my fault. :( > > Hmm, can you try this patch instead? > > http://www.FreeBSD.org/~jhb/patches/4x_386.patch Thanks, but these patches Did Not fix the problem. They also did not apply cleanly to 4.8, perhaps made against current or stable ? whatever, it was easy to see what you intended, so I produced a 4.8 compliant set, including both Erik's & yours commented out at: http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/i386/i386/i386_cpu.REL=4.8-RELEASE.diff I'm not sure if Erik's one line patch is good to commit for all processors (I haven't read the logic, just know i fixes my 386). If anyone want to send me new patches to test before they commit, feel free. Ideally that would be in next day or so, before I return machine to remote service (where boot failure is inconvenient, but I could test later too if necessary). -------------- > From: Peter Jeremy > > AFAIK, the only difference is external bus width (SX is 16 bit, DX is > 32 bit). It's only 486 where the SX means half the CPU doesn't work. Thanks, I'd forgotten that. > >I recall 386 support was dropped in 5.0, but presume not dropped in 4.8, > > It's only dropped in 5.0 GENERIC - you should still be able to compile > your own kernel with I386_CPU specified (and all other CPU options removed). I built one, but it hung, but no problem, it probably wanted 5 instead of 4 type entries in /dev & /boot, maybe later I'll try 5 on that box, but for now I want it as a 4 service machine so dont want to change dev & boot, thanks though. > More useful would be a debug kernel and a crash dump. You can then > use gdb on it and find the offending line of source code. Yes, sorry I missed that. > > Fatal trap 1: priveleged instruction fault while in kernel mode > > instruction pointer = 0x8:0xc02695a0 > > If you can't get a crash dump, do an 'nm -n' on the kernel and find > the function containing this address. Not sure what the 0x8: means (I hated segmented 8086 asm from day one :-) c02693cc T pmap_mincore c02694a8 T pmap_activate c026950c T pmap_addr_hint c0269534 T pmap_pte c0269570 T pmap_kenter c02695a8 T pmap_kremove c02695d8 T procfs_read_regs c02695f8 T procfs_write_regs c0269618 T procfs_read_dbregs > > stopped at 0xc02695a0: invlpg 0(%ecx) > > invlpg doesn't exist on i386 - you have to invalidate the entire TLB. > It looks like someone forgot to protect an invlpg instruction. OK, Erik & John seem to have a handle on this, thanks. - Julian Stacey Freelance Systems Engineer, Unix & Net Consultant, Munich. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 16:18:39 2003 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 3C49C37B401; Sun, 13 Apr 2003 16:18:39 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FEC143FBD; Sun, 13 Apr 2003 16:18:37 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h3DNHuM2054243; Mon, 14 Apr 2003 09:17:56 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h3DNHp6m054242; Mon, 14 Apr 2003 09:17:51 +1000 (EST) Date: Mon, 14 Apr 2003 09:17:51 +1000 From: Peter Jeremy To: Julian Stacey Message-ID: <20030413231751.GC54121@cirb503493.alcatel.com.au> References: <20030410193810.GA52024@falcon.midgard.homeip.net> <200304132300.h3DN0sM91460@flip.jhs.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304132300.h3DN0sM91460@flip.jhs.private> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org cc: Michael Elbel Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 13 Apr 2003 23:18:39 -0000 On Mon, Apr 14, 2003 at 01:00:54AM +0200, Julian Stacey wrote: >> > Fatal trap 1: priveleged instruction fault while in kernel mode >> > instruction pointer = 0x8:0xc02695a0 >> >> If you can't get a crash dump, do an 'nm -n' on the kernel and find >> the function containing this address. > >Not sure what the 0x8: means (I hated segmented 8086 asm from day one :-) So did I. You can safely ignore it for FreeBSD. >c0269570 T pmap_kenter >c02695a8 T pmap_kremove The faulting instruction is just before the end of pmap_kenter(). I can't check the source right now. Peter From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 16:31:19 2003 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 487AB37B404 for ; Sun, 13 Apr 2003 16:31:19 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 7893E43FAF for ; Sun, 13 Apr 2003 16:31:16 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 34672 invoked by uid 1001); 13 Apr 2003 23:31:14 -0000 Date: Mon, 14 Apr 2003 01:31:13 +0200 From: Erik Trulsson To: Julian Stacey Message-ID: <20030413233113.GA34593@falcon.midgard.homeip.net> Mail-Followup-To: Julian Stacey , freebsd-hackers@freebsd.org, John Baldwin References: <20030410193810.GA52024@falcon.midgard.homeip.net> <200304132300.h3DN0sM91460@flip.jhs.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304132300.h3DN0sM91460@flip.jhs.private> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 13 Apr 2003 23:31:19 -0000 On Mon, Apr 14, 2003 at 01:00:54AM +0200, Julian Stacey wrote: > Erik Trulsson wrote: > > On Thu, Apr 10, 2003 at 08:43:04PM +0200, Julian Stacey wrote: > > > Anyone seen 4.8-RELEASE running on a real 386 processor (not a 486, 586 etc > > > > Try the following patch. > > Makes my 386sx/33 work fine at least. > > (Without it I get the same panic as you do.) > > This works :-) I'm now running 4.8, Thanks ! You are welcome. It seems that there can't be too many people trying to run 4.8 on a real '386. Otherwise I would have expected at least someone else to complain about 4.8 not working on their machine. > > ----------- > > > From: John Baldwin > > > > Try the following patch. > > > Makes my 386sx/33 work fine at least. > > > (Without it I get the same panic as you do.) > > > > Oh my, I hope that isn't it. If so it's my fault. :( > > > > Hmm, can you try this patch instead? > > > > http://www.FreeBSD.org/~jhb/patches/4x_386.patch > > Thanks, but these patches Did Not fix the problem. They also did not apply > cleanly to 4.8, perhaps made against current or stable ? It applied cleanly to 4-stable so it was presumably made against that. > whatever, it was easy to see what you intended, so I produced a 4.8 > compliant set, including both Erik's & yours commented out at: > > http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/i386/i386/i386_cpu.REL=4.8-RELEASE.diff > > I'm not sure if Erik's one line patch is good to commit for all > processors (I haven't read the logic, just know i fixes my 386). My patch will not break anything. John Baldwin has already committed my patch to the 4-stable branch. His commit message (quoted below) explains what the problem was and why my patch is not really the proper fix but will work. Modified files: (Branch: RELENG_4) sys/i386/i386 identcpu.c Log: Revert one part of the last change so that cpu_class has a default value again. Apparently some code in pmap reads the value of this variable before it is properly initialized. That is a bug (!) but not a critical one and it is easier to make this change than hunt down that bug. This fixes booting on 80386 machines. Submitted by: Erik Trulsson Pointy hat to: jhb Revision Changes Path 1.80.2.15 +1 -1 src/sys/i386/i386/identcpu.c > If anyone want to send me new patches to test before they commit, > feel free. Ideally that would be in next day or so, before I return > machine to remote service (where boot failure is inconvenient, but > I could test later too if necessary). [snip] -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 16:36:52 2003 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 ADA5E37B405; Sun, 13 Apr 2003 16:36:52 -0700 (PDT) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79EC443FBF; Sun, 13 Apr 2003 16:36:51 -0700 (PDT) (envelope-from dgilbert@velocet.ca) Received: from trooper.velocet.ca (trooper.velocet.net [216.138.242.2]) by sabre.velocet.net (Postfix) with ESMTP id E4913137FFE; Sun, 13 Apr 2003 19:36:49 -0400 (EDT) Received: by trooper.velocet.ca (Postfix, from userid 66) id 78D4874A44; Sun, 13 Apr 2003 19:36:49 -0400 (EDT) Received: by canoe.velocet.net (Postfix, from userid 101) id DE73056791B; Sun, 13 Apr 2003 19:36:45 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16025.62605.808335.650450@canoe.velocet.net> Date: Sun, 13 Apr 2003 19:36:45 -0400 To: Mike Silbersack In-Reply-To: <20030401095201.O1612@odysseus.silby.com> References: <20030401123319.GA8399@comp.chem.msu.su> <32984.1049200665@critter.freebsd.dk> <20030401131616.GA11282@comp.chem.msu.su> <20030401095201.O1612@odysseus.silby.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid cc: Yar Tikhiy cc: hackers@freebsd.org cc: Poul-Henning Kamp Subject: Expensive MII code (was Re: "Expensive timeout(9) function...") 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, 13 Apr 2003 23:36:53 -0000 Mike> The _tick routines are not easy to fix, FWIW. MII access Mike> functions are quite time consuming almost any way you look at Mike> it. Mike> Well, actually, I figured out a way to make them much faster, Mike> but it's been a few months since I looked at that patch, I guess Mike> I should pull it back up and post it somewhere... Expensive, certainly. The em driver locks up the whole machine for several seconds when ifconfig'ing cards. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 23:42:27 2003 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 57A5837B401 for ; Sun, 13 Apr 2003 23:42:27 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 83C3843F85 for ; Sun, 13 Apr 2003 23:42:23 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 29779 invoked from network); 14 Apr 2003 06:42:22 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 14 Apr 2003 06:42:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 13 Apr 2003 20:38:33 -0500 (CDT) From: Mike Silbersack To: David Gilbert In-Reply-To: <16025.62605.808335.650450@canoe.velocet.net> Message-ID: <20030413203755.H93049@odysseus.silby.com> References: <20030401123319.GA8399@comp.chem.msu.su> <32984.1049200665@critter.freebsd.dk> <20030401095201.O1612@odysseus.silby.com> <16025.62605.808335.650450@canoe.velocet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Yar Tikhiy cc: hackers@freebsd.org cc: Poul-Henning Kamp Subject: Re: Expensive MII code (was Re: "Expensive timeout(9) function...") 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, 14 Apr 2003 06:42:27 -0000 On Sun, 13 Apr 2003, David Gilbert wrote: > Mike> Well, actually, I figured out a way to make them much faster, > Mike> but it's been a few months since I looked at that patch, I guess > Mike> I should pull it back up and post it somewhere... > > Expensive, certainly. The em driver locks up the whole machine for > several seconds when ifconfig'ing cards. > > Dave. Well, that's an extreme case. It can probably be cut down considerably if you take a hard look at it. Mike "Silby" Silbersack. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 23:55:12 2003 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 2526737B401 for ; Sun, 13 Apr 2003 23:55:12 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D9D643FF3 for ; Sun, 13 Apr 2003 23:55:11 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 31351 invoked from network); 14 Apr 2003 06:55:09 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 14 Apr 2003 06:55:09 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 13 Apr 2003 20:51:20 -0500 (CDT) From: Mike Silbersack To: Hiten Pandya In-Reply-To: <20030412195711.GA30459@unixdaemons.com> Message-ID: <20030413204451.V93049@odysseus.silby.com> References: <200304101311.h3ADBgjY022790@samson.dc.luth.se> <20030412195711.GA30459@unixdaemons.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org cc: Eric Anderson cc: David Gilbert cc: freebsd-hackers@freebsd.org Subject: Re: tcp_output starving -- is due to mbuf get delay? 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, 14 Apr 2003 06:55:12 -0000 On Sat, 12 Apr 2003, Hiten Pandya wrote: > > That tcp_quench knocks the window size back to one packet, if I'm not > > mistaken. You might want to put a counter there and see if that's > > happening frequently to you; if so, it might explain some loss of > > performance. > > Maybe something like this: > > Cheers. > > -- Hiten As Jayanth pointed out, ip_output already keeps statistics on when it returns ENOBUFS, so adding this additional variable wouldn't be of much benefit. For reference (from netstat -s): 0 output packets dropped due to no bufs, etc. Although, I think ip_output could be improved. It precalculates the expected # of packets to be sent, and returns ENOBUFS early if its estimate looks bad. However, if it gets to the point where if_output is called, and if_output then fails, no statistic is kept. So, it does look like Hiten's patch could be useful, as well as another counter tracking if_output failures. But I'm too busy to worry about them for now. :) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 00:31:30 2003 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 53C8837B401 for ; Mon, 14 Apr 2003 00:31:30 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3ABCF43FA3 for ; Mon, 14 Apr 2003 00:31:29 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 35978 invoked from network); 14 Apr 2003 07:31:28 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 14 Apr 2003 07:31:28 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 13 Apr 2003 21:27:38 -0500 (CDT) From: Mike Silbersack To: harti@freebsd.org In-Reply-To: <20030411094125.P774@beagle.fokus.fraunhofer.de> Message-ID: <20030413212354.U93049@odysseus.silby.com> References: <20030409114957.GN83126@cicely9.cicely.de> <20030410181322.W774@beagle.fokus.fraunhofer.de> <20030411094125.P774@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: John Polstra Subject: Re: realtime problem 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, 14 Apr 2003 07:31:30 -0000 On Fri, 11 Apr 2003, Harti Brandt wrote: > So, of course, it never takes the early return. When I remove the first > assignment it seems to work. In this case I get a mean time for > xl_status_update of 205usec which is ok I suppose. That sounds like what I was seeing back when I was playing with the code. Not perfect, but a heck of a lot better than how it was before. If the logic in the patch is munged, it's probably because I took a snapshot of my work in an non-optimal state... nonetheless, the idea is clear, and should apply to all PHYs equally well. I encourage you to investigate further. :) I would take another look at the code, but I'm bound and determined to finish my mbuf testing / finding that if_xl-related panic before I get sidetracked again. (And I already have a great diversion planned for myself once this gets done.) Good luck, Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 01:51:27 2003 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 92A4437B401; Mon, 14 Apr 2003 01:51:27 -0700 (PDT) Received: from jhs.muc.de (pD950EC59.dip.t-dialin.net [217.80.236.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31A6443F93; Mon, 14 Apr 2003 01:51:23 -0700 (PDT) (envelope-from jhs@berklix.com) Received: from flip.jhs.private (flip.jhs.private [192.168.91.24]) by jhs.muc.de (8.11.6/8.11.6) with ESMTP id h3E8pFv82753; Mon, 14 Apr 2003 10:51:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from flip.jhs.private (localhost [127.0.0.1]) by flip.jhs.private (8.11.6/8.11.6) with ESMTP id h3E8ohD94528; Mon, 14 Apr 2003 10:50:56 +0200 (CEST) (envelope-from jhs@flip.jhs.private) Message-Id: <200304140850.h3E8ohD94528@flip.jhs.private> To: Erik Trulsson In-Reply-To: Message from Erik Trulsson <20030413233113.GA34593@falcon.midgard.homeip.net> Date: Mon, 14 Apr 2003 10:50:43 +0200 From: "Julian H. Stacey" cc: freebsd-hackers@freebsd.org Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 14 Apr 2003 08:51:27 -0000 Erik Trulsson wrote: > My patch will not break anything. > John Baldwin has already committed my patch to the 4-stable branch. > His commit message (quoted below) explains what the problem was and why > my patch is not really the proper fix but will work. Thanks, good to know its fixed for 4.X. ( Any comment on 5 BTW ? ) - Julian Stacey Freelance Systems Engineer, Unix & Net Consultant, Munich. Ihr Rauchen => mein allergischer Kopfschmerz ! Schnupftabak probieren. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 05:47:14 2003 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 779E937B401 for ; Mon, 14 Apr 2003 05:47:14 -0700 (PDT) Received: from asterix.rsu.ru (asterix.rsu.ru [195.208.245.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE4343F75 for ; Mon, 14 Apr 2003 05:47:12 -0700 (PDT) (envelope-from bushman@rsu.ru) Received: from rsu.ru (mac.cc.rsu.ru [195.208.252.173]) by asterix.rsu.ru (8.12.6p2/8.12.6) with ESMTP id h3ECl9g5071805; Mon, 14 Apr 2003 16:47:09 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Mon, 14 Apr 2003 16:47:02 +0400 Mime-Version: 1.0 (Apple Message framework v551) To: freebsd-hackers@freebsd.org From: "Michael A. Bushkov" Message-Id: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> X-Mailer: Apple Mail (2.551) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: and@rsu.ru cc: os@rsu.ru Subject: nsswitch implementation 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, 14 Apr 2003 12:47:15 -0000 Greetings! We are currently working on alternate nsswitch implementation for FreeBSD. We want to make this implementation more flexible and powerful than the current one. Our idea is to make 3-level structure of nsswitch: 1) libc functions talking to the level2 daemon 2) Special daemon (nssd) accepting queries from libc, passing them to level3 (modules) and sending answers back to libc 3) DSO modules, containing functions doing real work to obtain requested information from any source or database (for example nss_files.so, nss_dns.so and so on) The daemon (level 2) should be able do dynamically open modules - we can't call dlopen() directly from libc. At the moment we have a working alpha-version of daemon, nss_files module and some rewritten libc functions. And there is one problem: behaviour of modules should be different for regular users and for root. Currently (in libc) this is done with the help of geteuid(). This is not applicable for modules since their function are called by the daemon but not the originating process itself. We see two implementable solutions: 1. Run 2 daemons to separate root and non-root queries. 2. Pass uid information to the module functions and let them use it instead of geteuid() And another 'theoretical' solution: to intersept geteuid() calls from modules. We defenitely need some suggesions and discussion. Any help will be greatly appreciated. Pleas keep CC lines in replies since we're not on the list. Michael A. Bushkov Computer Center of Rostov State University From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 05:54:39 2003 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 28B2137B401 for ; Mon, 14 Apr 2003 05:54:39 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0350843F93 for ; Mon, 14 Apr 2003 05:54:38 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3ECsZbq045005; Mon, 14 Apr 2003 14:54:36 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 14 Apr 2003 14:54:35 +0200 (CEST) From: Martin Blapp To: freebsd-hackers@freebsd.org Message-ID: <20030414145126.M4749@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: os@rsu.ru Subject: Re: nsswitch implementation 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, 14 Apr 2003 12:54:39 -0000 Hi, >We are currently working on alternate nsswitch implementation for >FreeBSD. We want to make this implementation more flexible and powerful >than the current one. Have you coordinated this with nectar@freebsd.org (Jacques Vidrine) ? He currently works on nsdispach for FreeBSD which should be availabe for FreeBSD 5.1 Martin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 06:05:45 2003 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 9B2E337B401 for ; Mon, 14 Apr 2003 06:05:45 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDEBB43FA3 for ; Mon, 14 Apr 2003 06:05:44 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 3113644; Mon, 14 Apr 2003 08:05:44 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 8968078C44; Mon, 14 Apr 2003 08:05:43 -0500 (CDT) Date: Mon, 14 Apr 2003 08:05:43 -0500 From: "Jacques A. Vidrine" To: "Michael A. Bushkov" Message-ID: <20030414130543.GA55015@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Michael A. Bushkov" , freebsd-hackers@freebsd.org, and@rsu.ru, os@rsu.ru References: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-hackers@freebsd.org cc: os@rsu.ru cc: and@rsu.ru Subject: Re: nsswitch implementation 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, 14 Apr 2003 13:05:46 -0000 On Mon, Apr 14, 2003 at 04:47:02PM +0400, Michael A. Bushkov wrote: > Greetings! > > We are currently working on alternate nsswitch implementation for > FreeBSD. We want to make this implementation more flexible and powerful > than the current one. :-) You will see a new nsswitch committed by me to FreeBSD-CURRENT within the next two weeks. > Our idea is to make 3-level structure of nsswitch: > > 1) libc functions talking to the level2 daemon > > 2) Special daemon (nssd) accepting queries from > libc, passing them to level3 (modules) and sending answers > back to libc > > 3) DSO modules, containing functions doing real work > to obtain requested information from any source or > database (for example nss_files.so, nss_dns.so and so on) This structure is overkill, IMHO. Such a structure requires that all nsswitch consumers in libc marshall arguments. Also, some NSS modules already have their own daemon, e.g. winbind. That is the direction that is likely to continue, as it fits the model already established by Solaris, Linux, and IRS. > The daemon (level 2) should be able do dynamically open modules - we > can't call dlopen() directly from libc. Sure we can. You just can't if you are a statically-linked executable. [The implementation that will be committed shortly allows for building an NSS module with world so that statically-linked binaries are also supported.] > At the moment we have a working alpha-version of daemon, nss_files > module and some rewritten libc functions. And there is one problem: > behaviour of modules should be different for regular users and for > root. Currently (in libc) this is done with the help of > geteuid(). This is not applicable for modules since their function > are called by the daemon but not the originating process itself. > > We see two implementable solutions: > > 1. Run 2 daemons to separate root and non-root queries. > > 2. Pass uid information to the module functions and let them use it > instead of > geteuid() 3. Use a UNIX domain socket to talk to the daemon and utilize credential passing (SCM_CREDS). See the RPC libraries for an example. > And another 'theoretical' solution: to intersept geteuid() calls from > modules. > > We defenitely need some suggesions and discussion. Any help will be > greatly > appreciated. > > Pleas keep CC lines in replies since we're not on the list. I'm futzing with resolver stuff (scared to break it :-). I think I'll try to quickly bring in the new nsdispatch core and the getpw*, getgr* routines for now so that others can see what is going on. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 06:13:54 2003 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 BF38F37B401 for ; Mon, 14 Apr 2003 06:13:54 -0700 (PDT) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 169A443FA3 for ; Mon, 14 Apr 2003 06:13:54 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1953mS-000EmS-00; Mon, 14 Apr 2003 16:13:52 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Michael A. Bushkov" In-Reply-To: Message from "Michael A. Bushkov" <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Apr 2003 16:13:51 +0300 From: Danny Braniss Message-Id: cc: freebsd-hackers@freebsd.org cc: os@rsu.ru cc: and@rsu.ru Subject: Re: nsswitch implementation 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, 14 Apr 2003 13:13:55 -0000 Greetings 2u2! I won't go into the merrits of a new/er implementation, but i keep wondering the merrits of a different access for root/non-root. AFAIK, the only problematic issue is with the hashed-password visibility, and if that is so, then a much simpler solution should be available. danny > Greetings! > > We are currently working on alternate nsswitch implementation for > FreeBSD. We want to make this implementation more flexible and powerful > than the current one. > > Our idea is to make 3-level structure of nsswitch: > > 1) libc functions talking to the level2 daemon > > 2) Special daemon (nssd) accepting queries from > libc, passing them to level3 (modules) and sending answers > back to libc > > 3) DSO modules, containing functions doing real work > to obtain requested information from any source or > database (for example nss_files.so, nss_dns.so and so on) > > The daemon (level 2) should be able do dynamically open modules - we > can't call dlopen() directly from libc. > > At the moment we have a working alpha-version of daemon, nss_files > module and > some rewritten libc functions. And there is one problem: behaviour of > modules > should be different for regular users and for root. Currently (in libc) > this > is done with the help of geteuid(). This is not applicable for modules > since their function are called by the daemon but not the originating > process itself. > > We see two implementable solutions: > > 1. Run 2 daemons to separate root and non-root queries. > > 2. Pass uid information to the module functions and let them use it > instead of > geteuid() > > And another 'theoretical' solution: to intersept geteuid() calls from > modules. > > We defenitely need some suggesions and discussion. Any help will be > greatly > appreciated. > > Pleas keep CC lines in replies since we're not on the list. > > Michael A. Bushkov > Computer Center of Rostov State University > _______________________________________________ > 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 Mon Apr 14 06:50:05 2003 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 ED50D37B401 for ; Mon, 14 Apr 2003 06:50:05 -0700 (PDT) Received: from asterix.rsu.ru (asterix.rsu.ru [195.208.245.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13B6A43F85 for ; Mon, 14 Apr 2003 06:50:04 -0700 (PDT) (envelope-from bushman@rsu.ru) Received: from rsu.ru (mac.cc.rsu.ru [195.208.252.173]) by asterix.rsu.ru (8.12.6p2/8.12.6) with ESMTP id h3EDnug5072531; Mon, 14 Apr 2003 17:49:56 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Mon, 14 Apr 2003 17:49:50 +0400 Mime-Version: 1.0 (Apple Message framework v551) To: freebsd-hackers@freebsd.org From: "Michael A. Bushkov" Message-Id: X-Mailer: Apple Mail (2.551) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: bork@rsu.ru cc: and@rsu.ru cc: os@rsu.ru Subject: Re: Re: nsswitch implementation 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, 14 Apr 2003 13:50:06 -0000 > >> The daemon (level 2) should be able do dynamically open modules - we >> can't call dlopen() directly from libc. > > Sure we can. You just can't if you are a statically-linked > executable. [The implementation that will be committed shortly allows > for building an NSS module with world so that statically-linked > binaries are also supported.] Do you want to statically compile nss-modules in libc? If you do that, you'll have to statically link a lot of stuff into libc (for example, if we have nss_ldap module - we must compile whole ldap implementation into libc). And if we do it that way, libc will grow and grow... Besides, if you want to change a module code, you'll have to recompile whole libc. We are very interested to know your way of solving these problems... Michael A. Bushkov Computer Center of Rostov State University From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 07:39:27 2003 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 461C837B401 for ; Mon, 14 Apr 2003 07:39:27 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADAE543F85 for ; Mon, 14 Apr 2003 07:39:26 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16050 invoked from network); 14 Apr 2003 14:37:21 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Apr 2003 14:37:21 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3EEawOv066484; Mon, 14 Apr 2003 10:36:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304140850.h3E8ohD94528@flip.jhs.private> Date: Mon, 14 Apr 2003 10:37:01 -0400 (EDT) From: John Baldwin To: "Julian H. Stacey" cc: freebsd-hackers@freebsd.org Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 14 Apr 2003 14:39:27 -0000 On 14-Apr-2003 Julian H. Stacey wrote: > Erik Trulsson wrote: >> My patch will not break anything. >> John Baldwin has already committed my patch to the 4-stable branch. >> His commit message (quoted below) explains what the problem was and why >> my patch is not really the proper fix but will work. > > Thanks, good to know its fixed for 4.X. > ( Any comment on 5 BTW ? ) 5 doesn't have this problem but for different reasons. In 5.x, you have to build a custom kernel to get 386 support. 5.x does not support 80386 machines out of the box. Installing a 5.x release on a 80386 is not too difficult if you have 5.x installed on an existing machine. You just need to build a 80386 kernel and replace the kernel.gz on kern.flp. -- 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 Apr 14 07:40:14 2003 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 0A83C37B401 for ; Mon, 14 Apr 2003 07:40:14 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C0A43F85 for ; Mon, 14 Apr 2003 07:40:13 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26902 invoked from network); 14 Apr 2003 14:36:59 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Apr 2003 14:36:59 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3EEaqOv066481; Mon, 14 Apr 2003 10:36:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304112357.BAA02170@faui40p.informatik.uni-erlangen.de> Date: Mon, 14 Apr 2003 10:36:55 -0400 (EDT) From: John Baldwin To: Toerless Eckert cc: freebsd-hackers@FreeBSD.org Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 14:40:14 -0000 On 11-Apr-2003 Toerless Eckert wrote: >> > - Q: Is btx actually switching to real mode for int 13 ? Could it be >> > that there's a bug in that code ? >> >> No, we run it in virtual 86 mode, and it is likely that their BIOS >> routine just can't handle that. >> >> > - Q: Are there any alternatives how i could boot a 4.8 or 5.0 freebsd >> > solely from the disk ? (I guess i could try to install a linux and >> > then use liloboot, but that also uses the btx code from loader...) >> >> Nope. :( Other than get promise to fix their BIOS maybe. > > - Why is the BIOS routine not run in real mode ? Would it be hard trying > to change BTX so that it executes the interrupt in real mode ? Yes. Not to mention lack of space in boot2 for BTX to grow to support this. > - Is there actually a requirement for a BIOS to work correctly > in virtual mode ? I was under the assumption that BIOS is always > only assumed to need to work correctly in real mode. If this is > not true, then i would welcome if you could point me to an official > PC98, .. (or whatever) document WIntel , or > whoever leads the conspiracy what officially are requirements for a "PC"). > > Without such a reference i think anybody would have a hard time arguing > the case of requesting support for virtual mode from the BIOS of some > HW vendor, right ? Basically, the only problems we have with BIOS's usually happen because the BIOS writer thought they could be cute by entering protected mode themselves instead of using the defined BIOS calls (such as int 0x15, function 0x87) to access upper memory, etc. > - Do you know wether Linux relies on virtual mode in booting their kernel ? > because the vendor in my case is officially suporting linux. I guess i > need to test setting that up and see if i can boot it from the disk. Linux doesn't have a bootloader like FreeBSD. -- 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 Apr 14 07:59:49 2003 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 336FC37B401 for ; Mon, 14 Apr 2003 07:59:49 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E1D43F3F for ; Mon, 14 Apr 2003 07:59:48 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id D4F185D; Mon, 14 Apr 2003 09:59:47 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 32E4078C44; Mon, 14 Apr 2003 09:59:47 -0500 (CDT) Date: Mon, 14 Apr 2003 09:59:47 -0500 From: "Jacques A. Vidrine" To: "Michael A. Bushkov" Message-ID: <20030414145947.GA56580@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Michael A. Bushkov" , freebsd-hackers@freebsd.org, bork@rsu.ru, and@rsu.ru, os@rsu.ru References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: bork@rsu.ru cc: freebsd-hackers@freebsd.org cc: os@rsu.ru cc: and@rsu.ru Subject: Re: Re: nsswitch implementation 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, 14 Apr 2003 14:59:49 -0000 On Mon, Apr 14, 2003 at 05:49:50PM +0400, Michael A. Bushkov wrote: > > > >>The daemon (level 2) should be able do dynamically open modules - we > >>can't call dlopen() directly from libc. > > > >Sure we can. You just can't if you are a statically-linked > >executable. [The implementation that will be committed shortly allows > >for building an NSS module with world so that statically-linked > >binaries are also supported.] > > Do you want to statically compile nss-modules in libc? If you do that, > you'll have to statically link a lot of stuff into libc (for example, > if we have nss_ldap module - we must compile whole ldap implementation > into libc). And if we do it that way, libc will grow and grow... > Besides, if you want to change a module code, you'll have to recompile > whole libc. > We are very interested to know your way of solving these problems... I don't solve them. I expect people who want to use 3rd party NSS modules to use a completely dynamically-linked system. You are correct, I would not want to compile PADL.COM's nss_ldap into libc. However, Samba's winbind module is not so heavy-weight and possibly not so problematic from the code-size perspective. As I said, it is already partioned into a module and a daemon. Keep in mind why one wants nsswitch: in order to use already existing NSS modules. Most existing NSS modules are written for Solaris and/or Linux. These platforms follow an in-process model. An IPC model is quite different, and would require significant porting effort for each NSS module. (There is quite some distance between existing APIs and semantics versus the APIs and semantics of an IPC model.) I think it is presumptuous to believe that NSS module writers are going to invest significant effort to develop FreeBSD-specific NSS modules. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 08:38:06 2003 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 4A06137B401 for ; Mon, 14 Apr 2003 08:38:06 -0700 (PDT) Received: from icomag.de (ns.icomag.de [195.227.115.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 174A143FA3 for ; Mon, 14 Apr 2003 08:38:05 -0700 (PDT) (envelope-from bgd@icomag.de) Received: from localhost (bgd@localhost) by icomag.de (8.12.3/8.11.3) with ESMTP id h3EFc38k043470 for ; Mon, 14 Apr 2003 17:38:03 +0200 (CEST) (envelope-from bgd@icomag.de) Date: Mon, 14 Apr 2003 17:38:03 +0200 (CEST) From: Bogdan TARU X-X-Sender: To: Message-ID: <20030414173112.P43279-100000@fw.office.icom> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: max numbers of sockets? 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, 14 Apr 2003 15:38:06 -0000 Hi hackers, I am running some test programs to check the max number of sockets I can open on a machine. Don't ask why! :) The max number that I reached was 7318. I get 'Too many open files' when trying to open more. And I am curious why. I have bumped the following sysctl vars: (17:32) root@(alice)[~] sysctl kern.maxfiles kern.maxfiles: 15000 (17:32) root@(alice)[~] sysctl kern.maxfilesperproc kern.maxfilesperproc: 15000 (17:33) root@(alice)[~] sysctl kern.ipc.maxsockets kern.ipc.maxsockets: 15000 When trying to run 'sysctl kern.openfiles' I get indeed: (17:29) root@(alice)[~] sysctl kern.openfiles kern.openfiles: 7419 So there aren't any other processes 'eating up' the rest of the sockets. The other question that I've got is related to the 'vm.zone': (17:28) root@(alice)[~] sysctl vm.zone vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS .... socket: 192, 15000, 7348, 33, 43978 I thought that the LIMIT == USED + FREE, but it seems it's not that way... Could somebody explain? Thank you, bogdan ---------------------------- iCom Media AG Kirchweg 36 Koln, 50858 Germany Phone: +49-(0)221-485-689-16 Fax : +49-(0)221-485-689-20 Mobile:+49-(0)173-269-76-62 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 08:51:17 2003 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 E861A37B401 for ; Mon, 14 Apr 2003 08:51:17 -0700 (PDT) Received: from icomag.de (ns.icomag.de [195.227.115.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6348143FCB for ; Mon, 14 Apr 2003 08:51:14 -0700 (PDT) (envelope-from bgd@icomag.de) Received: from localhost (bgd@localhost) by icomag.de (8.12.3/8.11.3) with ESMTP id h3EFpCVf043844 for ; Mon, 14 Apr 2003 17:51:13 +0200 (CEST) (envelope-from bgd@icomag.de) Date: Mon, 14 Apr 2003 17:51:12 +0200 (CEST) From: Bogdan TARU X-X-Sender: To: In-Reply-To: <20030414173112.P43279-100000@fw.office.icom> Message-ID: <20030414175053.I43489-100000@fw.office.icom> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: max numbers of sockets? 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, 14 Apr 2003 15:51:18 -0000 Sorry, it was the 'shell limit' :) bogdan ---------------------------- iCom Media AG Kirchweg 36 Koln, 50858 Germany Phone: +49-(0)221-485-689-16 Fax : +49-(0)221-485-689-20 Mobile:+49-(0)173-269-76-62 On Mon, 14 Apr 2003, Bogdan TARU wrote: > > Hi hackers, > > I am running some test programs to check the max number of sockets I can > open on a machine. Don't ask why! :) > > The max number that I reached was 7318. I get 'Too many open files' when > trying to open more. And I am curious why. I have bumped the following > sysctl vars: > > (17:32) root@(alice)[~] sysctl kern.maxfiles > kern.maxfiles: 15000 > (17:32) root@(alice)[~] sysctl kern.maxfilesperproc > kern.maxfilesperproc: 15000 > (17:33) root@(alice)[~] sysctl kern.ipc.maxsockets > kern.ipc.maxsockets: 15000 > > > When trying to run 'sysctl kern.openfiles' I get indeed: > > (17:29) root@(alice)[~] sysctl kern.openfiles > kern.openfiles: 7419 > > So there aren't any other processes 'eating up' the rest of the sockets. > > The other question that I've got is related to the 'vm.zone': > > (17:28) root@(alice)[~] sysctl vm.zone > vm.zone: > ITEM SIZE LIMIT USED FREE REQUESTS > .... > socket: 192, 15000, 7348, 33, 43978 > > > I thought that the LIMIT == USED + FREE, but it seems it's not that > way... Could somebody explain? > > Thank you, > bogdan > > > ---------------------------- > iCom Media AG > Kirchweg 36 > Koln, 50858 > Germany > > Phone: +49-(0)221-485-689-16 > Fax : +49-(0)221-485-689-20 > Mobile:+49-(0)173-269-76-62 > > _______________________________________________ > 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 Mon Apr 14 09:00:33 2003 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 CC27B37B404; Mon, 14 Apr 2003 09:00:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40-smtp.informatik.uni-erlangen.de [131.188.34.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C54243F85; Mon, 14 Apr 2003 09:00:31 -0700 (PDT) (envelope-from eckert@faui40p.informatik.uni-erlangen.de) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) id SAA16177; Mon, 14 Apr 2003 18:00:29 +0200 (MEST) Received: (from eckert@localhost) by faui40p.informatik.uni-erlangen.de (8.9.3/8.1.6-FAU) id SAA21075; Mon, 14 Apr 2003 18:00:29 +0200 (MEST) From: Toerless Eckert Message-Id: <200304141600.SAA21075@faui40p.informatik.uni-erlangen.de> In-Reply-To: from John Baldwin at "Apr 14, 2003 10:36:55 am" To: jhb@FreeBSD.org (John Baldwin) Date: Mon, 14 Apr 2003 18:00:28 +0200 (MEST) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL42 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org cc: eckert@i4.informatik.uni-erlangen.de Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 16:00:34 -0000 > > - Why is the BIOS routine not run in real mode ? Would it be hard trying > > to change BTX so that it executes the interrupt in real mode ? > > Yes. Not to mention lack of space in boot2 for BTX to grow to support this. With boot2 being space challenged, why does it need to be a btx client anyhow ? > > - Is there actually a requirement for a BIOS to work correctly > > in virtual mode ? I was under the assumption that BIOS is always > > only assumed to need to work correctly in real mode. If this is > > not true, then i would welcome if you could point me to an official > > PC98, .. (or whatever) document WIntel , or > > whoever leads the conspiracy what officially are requirements for a "PC"). Is there an official answer to to this ? I am still under the assumption that officially BIOS code is assumed only to be executed under real mode. I can perfectly fine understand that maybe the maority of simple BIOS pieces for "normal" boot hardware may be so "simple" that they even perate under virtual mode, but that isn't a good argument to expect all BIOS code to execute from virtual mode, or is it ? > > Without such a reference i think anybody would have a hard time arguing > > the case of requesting support for virtual mode from the BIOS of some > > HW vendor, right ? > > Basically, the only problems we have with BIOS's usually happen because the > BIOS writer thought they could be cute by entering protected mode themselves > instead of using the defined BIOS calls (such as int 0x15, function 0x87) to > access upper memory, etc. I can believe that. But you also know that most exotic hardware by itself will not officially support FreeBSD even though someone like sos may have written a cool driver for it. ANd if then FreeBSD is the only OS with such requirements against the BIOS of add-on hardware and neither any windows nor Linux has it - that makes FreeBSD painting itself in a corner where boot-compatibility is lower than necessary. No such vendor would change their BIOS for it! Why not rather stick to requirements against the hardware that are known also to be needed by unfortunately better supported OSs ? Why not at least have an option for a boot process that does so ? Eg: I can find a replacement for boot2 easily, but how can i get the kernel nowadays booted without loader in between ? When was actually this btx client concept introduced in FreeBSD ? Eg: wasn't the bootstrap in before the kernel real-mode up until BSD 4.x ? Cheers Toerless From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 10:47:16 2003 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 BB65537B404; Mon, 14 Apr 2003 10:47:16 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05D943FB1; Mon, 14 Apr 2003 10:47:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <2003041417471405300dp68ke>; Mon, 14 Apr 2003 17:47:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA25808; Mon, 14 Apr 2003 10:47:14 -0700 (PDT) Date: Mon, 14 Apr 2003 10:47:12 -0700 (PDT) From: Julian Elischer To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: "Julian H. Stacey" Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 14 Apr 2003 17:47:17 -0000 John, did you get eh messages of "ok" from both re. and the security officer to put this in RELENG_4_8 On Mon, 14 Apr 2003, John Baldwin wrote: > > On 14-Apr-2003 Julian H. Stacey wrote: > > Erik Trulsson wrote: > >> My patch will not break anything. > >> John Baldwin has already committed my patch to the 4-stable branch. > >> His commit message (quoted below) explains what the problem was and why > >> my patch is not really the proper fix but will work. > > > > Thanks, good to know its fixed for 4.X. > > ( Any comment on 5 BTW ? ) > > 5 doesn't have this problem but for different reasons. In 5.x, you > have to build a custom kernel to get 386 support. 5.x does not support > 80386 machines out of the box. Installing a 5.x release on a 80386 > is not too difficult if you have 5.x installed on an existing machine. > You just need to build a 80386 kernel and replace the kernel.gz on kern.flp. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > _______________________________________________ > 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 Mon Apr 14 11:05:48 2003 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 71C9D37B401 for ; Mon, 14 Apr 2003 11:05:48 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D0743F93 for ; Mon, 14 Apr 2003 11:05:46 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h3EI5Yv97103; Mon, 14 Apr 2003 11:05:35 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3E9AF8AA.1080904@acm.org> Date: Mon, 14 Apr 2003 11:06:34 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael A. Bushkov" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: bork@rsu.ru cc: freebsd-hackers@freebsd.org cc: os@rsu.ru cc: and@rsu.ru Subject: Re: nsswitch implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 18:05:48 -0000 Michael A. Bushkov wrote: >>> The daemon (level 2) should be able do dynamically open modules - we >>> can't call dlopen() directly from libc. >> >> Sure we can. You just can't if you are a statically-linked >> executable. [The implementation that will be committed shortly allows >> for building an NSS module with world so that statically-linked >> binaries are also supported.] Of course, if the whole system were dynamically linked, that would also solve the problem. I've been working toward making the entire system dynamically linked. Some of the uglier parts are already done, but my time is limited, so I anticipate another couple of months before it's really usable. FYI, the reason I've been working on a fully-dynamic system is specifically so that NSS, PAM, and locale implementations can rely on dlopen(). It would be a pity to do all this work and have noone appreciate it. ;-) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 11:34:59 2003 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 8B36937B404; Mon, 14 Apr 2003 11:34:59 -0700 (PDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id D087243FAF; Mon, 14 Apr 2003 11:34:56 -0700 (PDT) (envelope-from sean@perrin.int.nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 0E67A21064; Mon, 14 Apr 2003 11:34:56 -0700 (PDT) Date: Mon, 14 Apr 2003 11:34:55 -0700 From: Sean Chittenden To: "Jacques A. Vidrine" , freebsd-hackers@freebsd.org Message-ID: <20030414183455.GZ79923@perrin.int.nxad.com> References: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> <20030414130543.GA55015@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030414130543.GA55015@madman.celabo.org> User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ Subject: Re: nsswitch implementation 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, 14 Apr 2003 18:34:59 -0000 > modules already have their own daemon, e.g. winbind. That is the > direction that is likely to continue, as it fits the model already > established by Solaris, Linux, and IRS. ^^^ Hrm, it wouldn't by chance be tax time, would it? :-] -sc -- Sean Chittenden From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 12:14:53 2003 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 818DB37B401 for ; Mon, 14 Apr 2003 12:14:52 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1F9343F93 for ; Mon, 14 Apr 2003 12:14:51 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24679 invoked from network); 14 Apr 2003 19:14:56 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Apr 2003 19:14:56 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3EJEmOv067011; Mon, 14 Apr 2003 15:14:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304141600.SAA21075@faui40p.informatik.uni-erlangen.de> Date: Mon, 14 Apr 2003 15:14:49 -0400 (EDT) From: John Baldwin To: Toerless Eckert cc: freebsd-hackers@FreeBSD.org Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 19:14:53 -0000 On 14-Apr-2003 Toerless Eckert wrote: >> > - Why is the BIOS routine not run in real mode ? Would it be hard trying >> > to change BTX so that it executes the interrupt in real mode ? >> >> Yes. Not to mention lack of space in boot2 for BTX to grow to support this. > > With boot2 being space challenged, why does it need to be a btx > client anyhow ? Because then the code to read UFS can be in C instead of assembly. :) Are you offering to rewrite the entire bootstrap in assembly and maintain it? Note that /boot/loader also uses BTX and vm86 mode to read the kernel off of disk and into memory > 1 meg, so you'd have to reimplement all of that (including the Forth support, etc.) in asm as well. Either that or try to bounce back into real mode for any BIOS calls, as well as for any hardware interrupts. >> > - Is there actually a requirement for a BIOS to work correctly >> > in virtual mode ? I was under the assumption that BIOS is always >> > only assumed to need to work correctly in real mode. If this is >> > not true, then i would welcome if you could point me to an official >> > PC98, .. (or whatever) document WIntel , or >> > whoever leads the conspiracy what officially are requirements for a "PC"). > > Is there an official answer to to this ? I am still under the assumption > that officially BIOS code is assumed only to be executed under real mode. > I can perfectly fine understand that maybe the maority of simple BIOS pieces > for "normal" boot hardware may be so "simple" that they even perate under > virtual mode, but that isn't a good argument to expect all BIOS code to > execute from virtual mode, or is it ? Well, considering there is no "official" standard for a BIOS (if you find one, please let us know) then it is hard there there to be an "official" policy of discouraging use of PM directly in BIOS routines. In reality, very few BIOS's have these types of problems. pst(4) is one of the few that doesn't work in this model. Also, I do know of at least one BIOS vendor I worked with recently to straighten out some kinks with BTX that specifically checks to see if they are in VM86 mode when executing in order to handle some special cases. >> > Without such a reference i think anybody would have a hard time arguing >> > the case of requesting support for virtual mode from the BIOS of some >> > HW vendor, right ? >> >> Basically, the only problems we have with BIOS's usually happen because the >> BIOS writer thought they could be cute by entering protected mode themselves >> instead of using the defined BIOS calls (such as int 0x15, function 0x87) to >> access upper memory, etc. > > I can believe that. But you also know that most exotic hardware by > itself will not officially support FreeBSD even though someone like sos > may have written a cool driver for it. ANd if then FreeBSD is the only OS > with such requirements against the BIOS of add-on hardware and neither > any windows nor Linux has it - that makes FreeBSD painting itself in a > corner where boot-compatibility is lower than necessary. No such vendor > would change their BIOS for it! Why not rather stick to requirements against > the hardware that are known also to be needed by unfortunately better > supported OSs ? Why not at least have an option for a boot process that > does so ? Eg: I can find a replacement for boot2 easily, but how can i > get the kernel nowadays booted without loader in between ? Actually, some vendors have fixed their BIOS drivers in the past. :) If Promise does not wish to fix their BIOS, then either buy some other product without these issues or use a standalone hard drive, CD, floppy, or network boot to load the kernel. > When was actually this btx client concept introduced in FreeBSD ? Eg: > wasn't the bootstrap in before the kernel real-mode up until > BSD 4.x ? It might have been 4.0, yes. 4.0 came out in the previous millenium however, and we haven't really had major issues with it. -- 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 Apr 14 12:14:58 2003 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 6BD7A37B401 for ; Mon, 14 Apr 2003 12:14:58 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE0BA43FA3 for ; Mon, 14 Apr 2003 12:14:57 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8334 invoked from network); 14 Apr 2003 19:15:03 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Apr 2003 19:15:03 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3EJEsOv067017; Mon, 14 Apr 2003 15:14:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 14 Apr 2003 15:14:56 -0400 (EDT) From: John Baldwin To: Julian Elischer cc: freebsd-hackers@freebsd.org cc: "Julian H. Stacey" Subject: Re: Anyone seen 4.8-RELEASE running on a real 386 (not 486 586 etc) ? 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, 14 Apr 2003 19:14:58 -0000 On 14-Apr-2003 Julian Elischer wrote: > John, did you get eh messages of "ok" from both re. and the security > officer to put this in RELENG_4_8 jhb 2003/04/14 07:36:19 PDT FreeBSD src repository Modified files: (Branch: RELENG_4_8) sys/i386/i386 identcpu.c Log: MFS: Fix booting on 80386 machines. CD vendor's may want to re-roll their own release to include this fix. Approved by: re (murray) Revision Changes Path 1.80.2.14.2.1 +1 -1 src/sys/i386/i386/identcpu.c > On Mon, 14 Apr 2003, John Baldwin wrote: > >> >> On 14-Apr-2003 Julian H. Stacey wrote: >> > Erik Trulsson wrote: >> >> My patch will not break anything. >> >> John Baldwin has already committed my patch to the 4-stable branch. >> >> His commit message (quoted below) explains what the problem was and why >> >> my patch is not really the proper fix but will work. >> > >> > Thanks, good to know its fixed for 4.X. >> > ( Any comment on 5 BTW ? ) >> >> 5 doesn't have this problem but for different reasons. In 5.x, you >> have to build a custom kernel to get 386 support. 5.x does not support >> 80386 machines out of the box. Installing a 5.x release on a 80386 >> is not too difficult if you have 5.x installed on an existing machine. >> You just need to build a 80386 kernel and replace the kernel.gz on kern.flp. >> >> -- >> >> John Baldwin <>< http://www.FreeBSD.org/~jhb/ >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >> _______________________________________________ >> 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" >> > -- 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 Apr 14 13:09:03 2003 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 3FD9037B401; Mon, 14 Apr 2003 13:09:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40-smtp.informatik.uni-erlangen.de [131.188.34.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id E409043F3F; Mon, 14 Apr 2003 13:09:01 -0700 (PDT) (envelope-from eckert@faui40p.informatik.uni-erlangen.de) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) id WAA03105; Mon, 14 Apr 2003 22:09:00 +0200 (MEST) Received: (from eckert@localhost) by faui40p.informatik.uni-erlangen.de (8.9.3/8.1.6-FAU) id WAA26011; Mon, 14 Apr 2003 22:09:00 +0200 (MEST) From: Toerless Eckert Message-Id: <200304142009.WAA26011@faui40p.informatik.uni-erlangen.de> In-Reply-To: from John Baldwin at "Apr 14, 2003 3:14:49 pm" To: jhb@FreeBSD.org (John Baldwin) Date: Mon, 14 Apr 2003 22:08:59 +0200 (MEST) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL42 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org cc: eckert@i4.informatik.uni-erlangen.de Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 20:09:03 -0000 > > With boot2 being space challenged, why does it need to be a btx > > client anyhow ? > > Because then the code to read UFS can be in C instead of assembly. :) Are > you offering to rewrite the entire bootstrap in assembly and maintain it? No, i was rather thinking about the good ol' mechanism of burning the sectors for "loaders" into the boot1/boot2 bootstrap code, foregoing the need to put UFS into boot2 and allowing it to be a simple real-mode loader. loader itself would still be a btx client but btx then could be improved to execute BIOS interrupts via a real-mode stub. If necessary this would invoke copying of read/written buffers between real and virtual mode. This construction gives the highest compatibility with existing hardware while still maintain the flexbility of loader. The downside of being required to burn the loader sectors into boot1/boot2 is in my option quite acceptable. I just think that maximizing compatibility between FreeBSD and hardware especially on PC platform should be a design goal. Right now the approach is just the other way around. With this virtual mode in boot/loader FreeBSD has put itself into the position of being potentially much _less_ compatible than othre operating systems. We can argue aout the quantity, but quite frankly that's not even the point. > Well, considering there is no "official" standard for a BIOS (if you find > one, please let us know) Well, i found a couple of places listing INT functionality, like for example the dev. documentation for grub, and there it says "real mode only" but yes, nothing directly from the three rulers of the universe. I'd still claim that "real mode only" for BIOS is rather a long time rule than an urban legend ;-) > policy of discouraging use of PM directly in BIOS routines. In reality, > very few BIOS's have these types of problems. pst(4) is one of the few > that doesn't work in this model. right, and there's not a single line in the boot/loader or pst() documentation highlighting this situation. > Also, I do know of at least one BIOS > vendor I worked with recently to straighten out some kinks with BTX that > specifically checks to see if they are in VM86 mode when executing in order > to handle some special cases. But here's the point: people buy PC hardware because it's cheap. Guess why it's cheap. If i had the money to buy a sun with a comparable system with raid, do you think i'd hang around with a PC ? Or for that matter with a clone of forth in loader if i can have real open boot prom where i can read and change the forth initialization routines of add-on cards instead of having to hope that the binary BIOS oroutines f some PC cards is compatible with the motherboard BIOS ? Heck, i had to return two motherboards because they couldn't initialize raid, scsi and firewire being in the system at the same time. In a cheesy hardware environment like PC the right thing to do is to minimize the expectations on what that stuff can do, especially the BIOS. You don't have to be better on this than the competition (linux, *bsd, windows), but you shouldn't be much more expectant. *BSDs strong point has always been to be architecturally and implementation wise more advanced than Linux. Raising the bar for hardware is NOT compliant with that goal if you ask me. It is rather going for the easy catch of the nice loader/non-burned-sectors but leaving interoperablity in the corner. That's really something i'd have expected from Linux. > Actually, some vendors have fixed their BIOS drivers in the past. :) If > Promise does not wish to fix their BIOS, then either buy some other product > without these issues or use a standalone hard drive, CD, floppy, or network > boot to load the kernel. There aren't that many inexpensive raid5 controllers on the market (sure, the list of the ones supported by freebsd is long, but check availablity, price and actual speeds supported). If you build a RAID system, it is logical to expect that you can also boot from it. Of course vendors suck. If there was a single comparable product that would officially support FreeBSD and be not more than 50% more expensive than this product, then i'd have gone for that immediately. There is not. I am not aware of a single Raid controller where the vendors website officially says freebsd supported. And given that these BIOS incompatiblities are not documented in FreeBSD, neither for pst, nor for the VM-issue of boot2/loader, i've only got that much cycles to trying to find a working combination, right ? > It might have been 4.0, yes. 4.0 came out in the previous millenium > however, and we haven't really had major issues with it. Well, don't worry for me, i've just got myself a nice PQI DOM module to put the boot environment (and DOS tools *sigh*) onto, but don't think that FreeBSD is not putting itself into a boot challenged corner just because 98% of people have a standard PC with boot devices supported by three standard onboard BIOSses. After all, in the past *BSD was _the_ preferred OS for all kind of embedded/OEM applications, but these kind of issues can become a quick tie breaker towards the end of such system builders going for Linux. Cheers Toerless From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 13:23:02 2003 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 757AC37B401 for ; Mon, 14 Apr 2003 13:23:02 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id D423243F85 for ; Mon, 14 Apr 2003 13:23:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12355 invoked from network); 14 Apr 2003 20:23:08 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Apr 2003 20:23:08 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3EKMvOv067184; Mon, 14 Apr 2003 16:22:58 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304142009.WAA26011@faui40p.informatik.uni-erlangen.de> Date: Mon, 14 Apr 2003 16:22:59 -0400 (EDT) From: John Baldwin To: Toerless Eckert cc: freebsd-hackers@FreeBSD.org Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 20:23:02 -0000 On 14-Apr-2003 Toerless Eckert wrote: >> > With boot2 being space challenged, why does it need to be a btx >> > client anyhow ? >> >> Because then the code to read UFS can be in C instead of assembly. :) Are >> you offering to rewrite the entire bootstrap in assembly and maintain it? > > No, i was rather thinking about the good ol' mechanism of burning the sectors > for "loaders" into the boot1/boot2 bootstrap code, foregoing the need > to put UFS into boot2 and allowing it to be a simple real-mode loader. The idea of burning the sectors into the bootstrap is very _very_ unacceptable. As you pointed out, FreeBSD does try to avoid dirty hacks like this for the sake of a cleaner and more flexible design. Hardcoding the sectors would make things like booting kernels directly from boot2 as well as booting /boot/loader.old in the case that /boot/loader breaks impossible. Also, apart from your hardware, FreeBSD is quite compatible with the large majority of PC hardware. We boot directly off of 3ware ATA RAID controllers where I work, so I really think your claims are rather overstated. -- 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 Apr 14 14:37:05 2003 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 F01EB37B401; Mon, 14 Apr 2003 14:37:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7699043F75; Mon, 14 Apr 2003 14:37:01 -0700 (PDT) (envelope-from eckert@faui40p.informatik.uni-erlangen.de) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) id XAA07617; Mon, 14 Apr 2003 23:37:00 +0200 (MEST) Received: (from eckert@localhost) by faui40p.informatik.uni-erlangen.de (8.9.3/8.1.6-FAU) id XAA28381; Mon, 14 Apr 2003 23:36:59 +0200 (MEST) From: Toerless Eckert Message-Id: <200304142136.XAA28381@faui40p.informatik.uni-erlangen.de> In-Reply-To: from John Baldwin at "Apr 14, 2003 4:22:59 pm" To: jhb@FreeBSD.org (John Baldwin) Date: Mon, 14 Apr 2003 23:36:59 +0200 (MEST) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL42 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org cc: eckert@i4.informatik.uni-erlangen.de Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 21:37:05 -0000 > As you pointed out, FreeBSD does try to avoid dirty hacks like this for the > sake of a cleaner and more flexible design. But you can't have it without affecting compatiblity. > Hardcoding the sectors would make > things like booting kernels directly from boot2 as well as booting > /boot/loader.old in the case that /boot/loader breaks impossible. If booting loader.old is so important, why not boot2.old ? It's no different. At some point there is something hardcoded. I don't see the big issue here in hardcoding the loader sectors instead of effetively the boot2 sectors. Heck, one could even hardcode sectors of both loader and loader.old for the choice. Sure, it would be nice to not depend on this. I for once think it's perfectly valid to spare a full freebsd partition just for the linear encoding of the bootstrap code, but that's just me. > Also, apart > from your hardware, FreeBSD is quite compatible with the large majority of > PC hardware. We boot directly off of 3ware ATA RAID controllers where I > work, so I really think your claims are rather overstated. Don't forget that neither 3ware nor promise list FreeBSD as a supported operating system, both are equally listed in FreeBSDs hardware list, there's no indication that booting for one of them doesn't work but that it's supposed to work on the other. Neither does the documentation of boot2 or loader explain the possible issue so as to buy possible buyers. It would really be nice if this boot-compatiblity/incompatiblity information would be documented somehwere. Like in pst(4) and boot(8). Cheers Toerless From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 15:24:44 2003 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 2755B37B401 for ; Mon, 14 Apr 2003 15:24:44 -0700 (PDT) Received: from ns.isi.ulatina.ac.cr (ns.isi.ulatina.ac.cr [163.178.60.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ADCB43F85 for ; Mon, 14 Apr 2003 15:24:43 -0700 (PDT) (envelope-from fabmirha@ns.isi.ulatina.ac.cr) Received: by ns.isi.ulatina.ac.cr (Postfix, from userid 5481) id 887E61FF79; Mon, 14 Apr 2003 16:18:12 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ns.isi.ulatina.ac.cr (Postfix) with ESMTP id 817242BFAF for ; Mon, 14 Apr 2003 16:18:12 -0600 (CST) Date: Mon, 14 Apr 2003 16:18:12 -0600 (CST) From: Fabio Miranda Hamburger To: FreeBsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: honest 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: Mon, 14 Apr 2003 22:24:44 -0000 Hi, I have been using freebsd since 3,0-release, but now I have a dell inspiron 2650 laptop with dual xp and fbsd. What I want to do is install freebsd using whole harddisk and install vmware and run windoze xp for multimedia stuff. The problem is Xfree86 just support 24 bit color quality, and vmware under freebsd is still bogus, the apm feature doesnt work. Okey, to be honest i like freebsd but I am affraid freebsd is not an ideal os for a laptop. What u guys think? I dont like linux, but I am forced to switch, what u think? --- Fabio Andres Miranda Ingenieria de sistemas informaticos Universidad Latina - Costa Rica From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 15:31:24 2003 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 9405D37B401 for ; Mon, 14 Apr 2003 15:31:24 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BEFA43F93 for ; Mon, 14 Apr 2003 15:31:22 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 97961 invoked from network); 14 Apr 2003 22:48:41 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 14 Apr 2003 22:48:41 -0000 Received: (nullmailer pid 4202 invoked by uid 136); Mon, 14 Apr 2003 22:34:18 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <200304142009.WAA26011@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert Date: Tue, 15 Apr 2003 02:34:18 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1050359658.658599.4201.nullmailer@cicuta.babolo.ru> cc: freebsd-hackers@freebsd.org Subject: Re: boot2 broken ? (booting from pst fails) 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, 14 Apr 2003 22:31:24 -0000 > But here's the point: people buy PC hardware because it's cheap. Guess why Some people buy PC hardware because of freedom in select of it. Compare to Mac. > it's cheap. If i had the money to buy a sun with a comparable system with > raid, do you think i'd hang around with a PC ? Or for that matter with Hm... Your freedom with Sun is more more restricted. > a clone of forth in loader if i can have real open boot prom where i can > read and change the forth initialization routines of add-on cards instead > of having to hope that the binary BIOS oroutines f some PC cards is compatible > with the motherboard BIOS ? Heck, i had to return two motherboards because > they couldn't initialize raid, scsi and firewire being in the system at > the same time. > > In a cheesy hardware environment like PC the right thing to do is to > minimize the expectations on what that stuff can do, especially the BIOS. The world is as bad as you allow it to be... > You don't have to be better on this than the competition (linux, *bsd, windows), > but you shouldn't be much more expectant. *BSDs strong point has always been > to be architecturally and implementation wise more advanced than Linux. Raising > the bar for hardware is NOT compliant with that goal if you ask me. .. Sorry my English is bad. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 15:43:29 2003 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 DDBE437B401; Mon, 14 Apr 2003 15:43:29 -0700 (PDT) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C4F43FBD; Mon, 14 Apr 2003 15:43:28 -0700 (PDT) (envelope-from rittle@latour.rsch.comm.mot.com) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3EMhSec009539; Mon, 14 Apr 2003 15:43:28 -0700 (MST) Received: from latour.rsch.comm.mot.com (latour.rsch.comm.mot.com [145.1.80.116])h3EMhPXL008360; Mon, 14 Apr 2003 17:43:26 -0500 Received: from latour.rsch.comm.mot.com (localhost.rsch.comm.mot.com [127.0.0.1])h3EMgAN8056900; Mon, 14 Apr 2003 17:42:10 -0500 (CDT) (envelope-from rittle@latour.rsch.comm.mot.com) Received: (from rittle@localhost) by latour.rsch.comm.mot.com (8.12.8/8.12.8/Submit) id h3EMg9d8056897; Mon, 14 Apr 2003 17:42:09 -0500 (CDT) Date: Mon, 14 Apr 2003 17:42:09 -0500 (CDT) From: Loren James Rittle Message-Id: <200304142242.h3EMg9d8056897@latour.rsch.comm.mot.com> To: hackers@freebsd.org In-reply-to: <20030413124626.5e782421.kabaev@bellatlantic.net> (message from Alexander Kabaev on Sun, 13 Apr 2003 12:46:26 -0400) References: <5.2.0.9.2.20030411082040.02604e90@194.184.65.4> <200304120241.h3C2fQCc061882@latour.rsch.comm.mot.com> <20030413012636.GA76030@dragon.nuxi.com> <20030413124626.5e782421.kabaev@bellatlantic.net> User-Agent: SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharaji?= =?ISO-8859-4?Q?ng=FE-mae?=) LEMI/1.14.1 Emacs/21.2 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: Re: gcc iussue or ... ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rittle@labs.mot.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 22:43:30 -0000 In article <20030413124626.5e782421.kabaev@bellatlantic.net>, Alexander Kabaev writes: > On Sat, 12 Apr 2003 18:26:36 -0700 > "David O'Brien" wrote: >> I'm not sure we should change FreeBSD to do something that purposfully >> produces wrong semantics. [...] > I think there is a slight confusion here. It is -fconserve-space flag > what introduces wrong semantics, [...] Agreed (with Alex). David, for the record: Here is the short test which displays the exact change: ; cat >t.C int t; ; /usr/bin/g++ -c t.C # gcc 2.95.4 20020320 [FreeBSD] ; size t.o text data bss dec hex filename 0 4 0 4 4 t.o ; /usr/local/beta-gcc/bin/g++ -c t.C # FSF mainline ; size t.o text data bss dec hex filename 0 0 4 4 4 t.o This is OK since there is no concept of "common merging" in C++. At one point, I knew the reason why older g++ assigned no data to BSS. Either way, this was a purposeful change in g++ (I can't cite the thread off-hand but I read it at the time). The system compiler on ref5/beast is doing section assignment for C++ the "new way". David, I do think that you found a section of code (which was originally written in 1996 before g++ used BSS) that could be tightened up in light of the new section rules used by g++. Anyone willing to post the patch ``attn: Mark Mitchell/Jason Merrill'' to gcc-patches? Tree munging is outside my area of expertise. Regards, Loren From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 16:33:16 2003 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 A9DD037B401 for ; Mon, 14 Apr 2003 16:33:16 -0700 (PDT) Received: from mailgate.ultradns.net (postfix.ultradns.net [204.74.100.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2695543F93 for ; Mon, 14 Apr 2003 16:33:16 -0700 (PDT) (envelope-from psoltani@ultradns.com) Received: from ultra-exchange.UltraDNS.com (nat-external.ultradns.net [204.74.100.10])h3ENXGuB013917; Mon, 14 Apr 2003 16:33:16 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 14 Apr 2003 16:33:15 -0700 Message-ID: <3DBB075EEB95944492E127F2B9A96FAF5398F4@ultra-exchange.ultradns.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: honest question. Thread-Index: AcMC1L0RahISsbdkQMmKcW+x9I3KxQAB7qbw From: "Patrick Soltani" To: "Fabio Miranda Hamburger" , Subject: RE: honest 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: Mon, 14 Apr 2003 23:33:17 -0000 > >Hi, I have been using freebsd since 3,0-release, but now I have a dell >inspiron 2650 laptop with dual xp and fbsd. >What I want to do is install freebsd using whole harddisk and install >vmware and run windoze xp for multimedia stuff. >The problem is Xfree86 just support 24 bit color quality, and=20 >vmware under >freebsd is still bogus, the apm feature doesnt work. Did you add the following line in your kernel file? device apm0 at nexus? flags 0x20 # Advanced Power Management Any specific errors/behavior? or Did you try the bios to disable the = power management? I don't have the your make and model laptop, but been very successful in = doing apm on many machines, even when XP says "now you can turn the = computer off" after issuing shutdown :-). Each laptop has slightly different attitude towards power management, = but I am sure you'd be able to find some help on the freebsd mailing = list and/or "googling" it. > >Okey, to be honest i like freebsd but I am affraid freebsd is=20 >not an ideal >os for a laptop. >What u guys think? >I dont like linux, but I am forced to switch, what u think? > > Have you updated the /usr/ports? Although Xfree86 is not as simple as = it should be, however, have had very little problem with compiling it = from source or installing it from CD. What has worked for me is "portupgrade" that automatically upgrades my = ports with little hassle. Regards, Patrick Soltani. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 04:09:28 2003 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 E71EF37B404 for ; Tue, 15 Apr 2003 04:09:28 -0700 (PDT) Received: from web12608.mail.yahoo.com (web12608.mail.yahoo.com [216.136.173.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 459B343FB1 for ; Tue, 15 Apr 2003 04:09:28 -0700 (PDT) (envelope-from raghu4jm@yahoo.com) Message-ID: <20030415110928.12078.qmail@web12608.mail.yahoo.com> Received: from [61.1.253.18] by web12608.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 04:09:28 PDT Date: Tue, 15 Apr 2003 04:09:28 -0700 (PDT) From: raghu To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-questions@FreeBSD.org Subject: porting UML-urgent 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, 15 Apr 2003 11:09:29 -0000 Hello, > The exact idea that i have and started is this. > 1.Implement system call tracing with ptrace system > call. > I have studied the relevant source code and added a > flag > that will be tested during the sytem call entry. This > is same as in linux ptrace. > > 2.To compile the Linux kernel(C code) in FreeBSD and > then UML patch onto it. > > Will this be enough, What might be the possible > problems in compiling Linux kernel,if any since it is > plain C code. Thanks , Raghu. ===== colorless green ideas sleep furiously. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 10:17:14 2003 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 0708337B401; Tue, 15 Apr 2003 10:17:14 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4519C43FBF; Tue, 15 Apr 2003 10:17:10 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 609583ABB51; Tue, 15 Apr 2003 19:17:57 +0200 (CEST) Date: Tue, 15 Apr 2003 19:17:57 +0200 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20030415171757.GU52293@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BcZrms9gUsdgyR6a" Content-Disposition: inline X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: Martin Blapp cc: Robert Watson cc: Poul-Henning Kamp Subject: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). 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, 15 Apr 2003 17:17:14 -0000 --BcZrms9gUsdgyR6a Content-Type: multipart/mixed; boundary="V4yrq4dHtCqH+JvC" Content-Disposition: inline --V4yrq4dHtCqH+JvC Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... I've just finished patch for multiple ip-numbers inside jails. There was a problem with handling INADDR_ANY correctly in multiple ips implementations, but I think I solved this problem. Another thing are priorities. When port X is opened on main host and in jail as INADDR_ANY, current implementation of jail converts INADDR_ANY to jail's IP. When we're connecting to this port we will connect to jail's daemon, because "exactly match" is there. In my solution looking for opened port is in this order: 1. non-jailed, non-wild. 2. non-jailed, wild. 3. jailed, non-wild. 4. jailed, wild. Please, review it. Thanks. PS. Patch is against FreeBSD-CURRENT. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --V4yrq4dHtCqH+JvC Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="mijail5.patch" Content-Transfer-Encoding: quoted-printable diff -ru /usr/src/sys/kern/kern_jail.c src/sys/kern/kern_jail.c --- /usr/src/sys/kern/kern_jail.c Wed Apr 9 04:55:17 2003 +++ src/sys/kern/kern_jail.c Tue Apr 15 12:39:34 2003 @@ -92,7 +92,7 @@ error =3D copyin(uap->jail, &j, sizeof j); if (error) return (error); - if (j.version !=3D 0) + if (j.version !=3D 1) return (EINVAL); =20 MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_WAITOK | M_ZERO); @@ -115,7 +115,14 @@ error =3D copyinstr(j.hostname, &pr->pr_host, sizeof pr->pr_host, 0); if (error) goto e_dropvnref; - pr->pr_ip =3D j.ip_number; + if (j.nips >=3D JAIL_MAX_IPS) + goto e_dropvnref; + MALLOC(pr->pr_ips, u_int32_t *, sizeof(u_int32_t) * j.nips, + M_PRISON, M_WAITOK); + error =3D copyin(j.ips, pr->pr_ips, sizeof(u_int32_t) * j.nips); + if (error) + goto e_dropips; + pr->pr_nips =3D j.nips; pr->pr_linux =3D NULL; pr->pr_securelevel =3D securelevel; =20 @@ -131,7 +138,7 @@ if (tryprid =3D=3D JAIL_MAX) { mtx_unlock(&allprison_mtx); error =3D EAGAIN; - goto e_dropvnref; + goto e_dropips; } goto next; } @@ -154,6 +161,8 @@ LIST_REMOVE(pr, pr_list); prisoncount--; mtx_unlock(&allprison_mtx); +e_dropips: + FREE(pr->pr_ips, M_PRISON); e_dropvnref: mtx_lock(&Giant); vrele(pr->pr_root); @@ -270,6 +279,7 @@ mtx_destroy(&pr->pr_mtx); if (pr->pr_linux !=3D NULL) FREE(pr->pr_linux, M_PRISON); + FREE(pr->pr_ips, M_PRISON); FREE(pr, M_PRISON); return; } @@ -286,13 +296,6 @@ mtx_unlock(&pr->pr_mtx); } =20 -u_int32_t -prison_getip(struct ucred *cred) -{ - - return (cred->cr_prison->pr_ip); -} - int prison_ip(struct ucred *cred, int flag, u_int32_t *ip) { @@ -304,23 +307,16 @@ tmp =3D *ip; else tmp =3D ntohl(*ip); - if (tmp =3D=3D INADDR_ANY) { - if (flag)=20 - *ip =3D cred->cr_prison->pr_ip; - else - *ip =3D htonl(cred->cr_prison->pr_ip); - return (0); - } if (tmp =3D=3D INADDR_LOOPBACK) { if (flag) - *ip =3D cred->cr_prison->pr_ip; + *ip =3D cred->cr_prison->pr_ips[0]; else - *ip =3D htonl(cred->cr_prison->pr_ip); + *ip =3D htonl(cred->cr_prison->pr_ips[0]); return (0); } - if (cred->cr_prison->pr_ip !=3D tmp) - return (1); - return (0); + if (tmp =3D=3D INADDR_ANY || jailed_ip(cred, tmp)) + return (0); + return (1); } =20 void @@ -336,9 +332,9 @@ tmp =3D ntohl(*ip); if (tmp =3D=3D INADDR_LOOPBACK) { if (flag) - *ip =3D cred->cr_prison->pr_ip; + *ip =3D cred->cr_prison->pr_ips[0]; else - *ip =3D htonl(cred->cr_prison->pr_ip); + *ip =3D htonl(cred->cr_prison->pr_ips[0]); return; } return; @@ -354,13 +350,31 @@ ok =3D 1; else if (sai->sin_family !=3D AF_INET) ok =3D 0; - else if (cred->cr_prison->pr_ip !=3D ntohl(sai->sin_addr.s_addr)) + else if (!jailed_ip(cred, ntohl(sai->sin_addr.s_addr))) ok =3D 1; else ok =3D 0; return (ok); } =20 +int +jailed_ip(struct ucred *cred, u_int32_t ip) +{ + register struct prison *pr; + register u_int i; + + if (!jailed(cred)) + return(1); + + pr =3D cred->cr_prison; + for (i =3D 0; i < pr->pr_nips; ++i) { + if (pr->pr_ips[i] =3D=3D ip) + return (1); + } + + return (0); +} + /* * Return 0 if jails permit p1 to frob p2, otherwise ESRCH. */ @@ -439,7 +453,8 @@ xp->pr_id =3D pr->pr_id; strlcpy(xp->pr_path, pr->pr_path, sizeof(xp->pr_path)); strlcpy(xp->pr_host, pr->pr_host, sizeof(xp->pr_host)); - xp->pr_ip =3D pr->pr_ip; + memcpy(xp->pr_ips, pr->pr_ips, sizeof(u_int32_t) * pr->pr_nips); + xp->pr_nips =3D pr->pr_nips; mtx_unlock(&pr->pr_mtx); xp++; } diff -ru /usr/src/sys/netinet/in_pcb.c src/sys/netinet/in_pcb.c --- /usr/src/sys/netinet/in_pcb.c Fri Feb 21 06:28:27 2003 +++ src/sys/netinet/in_pcb.c Tue Apr 15 18:58:34 2003 @@ -249,7 +249,7 @@ struct in_addr laddr; u_short lport =3D 0; int wild =3D 0, reuseport =3D (so->so_options & SO_REUSEPORT); - int error, prison =3D 0; + int error; =20 if (TAILQ_EMPTY(&in_ifaddrhead)) /* XXX broken! */ return (EADDRNOTAVAIL); @@ -270,9 +270,8 @@ if (sin->sin_family !=3D AF_INET) return (EAFNOSUPPORT); #endif - if (sin->sin_addr.s_addr !=3D INADDR_ANY) - if (prison_ip(td->td_ucred, 0, &sin->sin_addr.s_addr)) - return(EINVAL); + if (prison_ip(td->td_ucred, 0, &sin->sin_addr.s_addr)) + return(EINVAL); if (sin->sin_port !=3D *lportp) { /* Don't allow the port to change. */ if (*lportp !=3D 0) @@ -304,13 +303,11 @@ ntohs(lport) >=3D ipport_reservedlow && td && suser_cred(td->td_ucred, PRISON_ROOT)) return (EACCES); - if (td && jailed(td->td_ucred)) - prison =3D 1; if (so->so_cred->cr_uid !=3D 0 && !IN_MULTICAST(ntohl(sin->sin_addr.s_addr))) { - t =3D in_pcblookup_local(inp->inp_pcbinfo, - sin->sin_addr, lport, - prison ? 0 : INPLOOKUP_WILDCARD); + t =3D in_pcblookup_local(td->td_ucred, + inp->inp_pcbinfo, sin->sin_addr, lport, + INPLOOKUP_WILDCARD); /* * XXX * This entire block sorely needs a rewrite. @@ -340,11 +337,10 @@ return (EADDRINUSE); } } - if (prison && - prison_ip(td->td_ucred, 0, &sin->sin_addr.s_addr)) + if (prison_ip(td->td_ucred, 0, &sin->sin_addr.s_addr)) return (EADDRNOTAVAIL); - t =3D in_pcblookup_local(pcbinfo, sin->sin_addr, - lport, prison ? 0 : wild); + t =3D in_pcblookup_local(td->td_ucred, pcbinfo, + sin->sin_addr, lport, wild); if (t && (t->inp_vflag & INP_TIMEWAIT)) { if ((reuseport & intotw(t)->tw_so_options) =3D=3D 0) return (EADDRINUSE); @@ -369,9 +365,8 @@ ushort first, last; int count; =20 - if (laddr.s_addr !=3D INADDR_ANY) - if (prison_ip(td->td_ucred, 0, &laddr.s_addr)) - return (EINVAL); + if (prison_ip(td->td_ucred, 0, &laddr.s_addr)) + return (EINVAL); =20 if (inp->inp_flags & INP_HIGHPORT) { first =3D ipport_hifirstauto; /* sysctl */ @@ -409,8 +404,8 @@ if (*lastport > first || *lastport < last) *lastport =3D first; lport =3D htons(*lastport); - } while (in_pcblookup_local(pcbinfo, laddr, lport, - wild)); + } while (in_pcblookup_local(td->td_ucred, pcbinfo, + laddr, lport, wild)); } else { /* * counting up @@ -424,8 +419,8 @@ if (*lastport < first || *lastport > last) *lastport =3D first; lport =3D htons(*lastport); - } while (in_pcblookup_local(pcbinfo, laddr, lport, - wild)); + } while (in_pcblookup_local(td->td_ucred, pcbinfo, + laddr, lport, wild)); } } if (prison_ip(td->td_ucred, 0, &laddr.s_addr)) @@ -529,16 +524,6 @@ faddr =3D sin->sin_addr; fport =3D sin->sin_port; cred =3D inp->inp_socket->so_cred; - if (laddr.s_addr =3D=3D INADDR_ANY && jailed(cred)) { - bzero(&sa, sizeof(sa)); - sa.sin_addr.s_addr =3D htonl(prison_getip(cred)); - sa.sin_len =3D sizeof(sa); - sa.sin_family =3D AF_INET; - error =3D in_pcbbind_setup(inp, (struct sockaddr *)&sa, - &laddr.s_addr, &lport, td); - if (error) - return (error); - } =20 if (!TAILQ_EMPTY(&in_ifaddrhead)) { /* @@ -548,9 +533,12 @@ * and the primary interface supports broadcast, * choose the broadcast address for that interface. */ - if (faddr.s_addr =3D=3D INADDR_ANY) - faddr =3D IA_SIN(TAILQ_FIRST(&in_ifaddrhead))->sin_addr; - else if (faddr.s_addr =3D=3D (u_long)INADDR_BROADCAST && + if (faddr.s_addr =3D=3D INADDR_ANY) { + if (jailed(cred)) + faddr.s_addr =3D htonl(cred->cr_prison->pr_ips[0]); + else + faddr =3D IA_SIN(TAILQ_FIRST(&in_ifaddrhead))->sin_addr; + } else if (faddr.s_addr =3D=3D (u_long)INADDR_BROADCAST && (TAILQ_FIRST(&in_ifaddrhead)->ia_ifp->if_flags & IFF_BROADCAST)) faddr =3D satosin(&TAILQ_FIRST( @@ -907,7 +895,8 @@ * Lookup a PCB based on the local address and port. */ struct inpcb * -in_pcblookup_local(pcbinfo, laddr, lport_arg, wild_okay) +in_pcblookup_local(cred, pcbinfo, laddr, lport_arg, wild_okay) + struct ucred *cred; struct inpcbinfo *pcbinfo; struct in_addr laddr; u_int lport_arg; @@ -931,7 +920,9 @@ #endif if (inp->inp_faddr.s_addr =3D=3D INADDR_ANY && inp->inp_laddr.s_addr =3D=3D laddr.s_addr && - inp->inp_lport =3D=3D lport) { + inp->inp_lport =3D=3D lport && + inp->inp_socket->so_cred->cr_prison =3D=3D + cred->cr_prison) { /* * Found. */ @@ -969,6 +960,10 @@ if ((inp->inp_vflag & INP_IPV4) =3D=3D 0) continue; #endif + if (inp->inp_socket->so_cred->cr_prison !=3D + cred->cr_prison) { + continue; + } if (inp->inp_faddr.s_addr !=3D INADDR_ANY) wildcard++; if (inp->inp_laddr.s_addr !=3D INADDR_ANY) { @@ -997,8 +992,7 @@ * Lookup PCB in hash list. */ struct inpcb * -in_pcblookup_hash(pcbinfo, faddr, fport_arg, laddr, lport_arg, wildcard, - ifp) +in_pcblookup_hash(pcbinfo, faddr, fport_arg, laddr, lport_arg, wildcard, i= fp) struct inpcbinfo *pcbinfo; struct in_addr faddr, laddr; u_int fport_arg, lport_arg; @@ -1006,7 +1000,7 @@ struct ifnet *ifp; { struct inpcbhead *head; - register struct inpcb *inp; + register struct inpcb *inp, *jinp =3D NULL; u_short fport =3D fport_arg, lport =3D lport_arg; =20 /* @@ -1025,15 +1019,31 @@ /* * Found. */ - return (inp); + if (inp->inp_socket->so_cred->cr_prison =3D=3D NULL) + return (inp); + else { + if (jinp =3D=3D NULL) + jinp =3D inp; + } } } + if (jinp !=3D NULL) + return (jinp); if (wildcard) { struct inpcb *local_wild =3D NULL; #if defined(INET6) struct inpcb *local_wild_mapped =3D NULL; #endif /* defined(INET6) */ + struct inpcb *jinp_wild =3D NULL; + struct ucred *cred; =20 + /* + * Order of socket selection: + * 1. non-jailed, non-wild. + * 2. non-jailed, wild. + * 3. jailed, non-wild. + * 4. jailed, wild. + */ head =3D &pcbinfo->hashbase[INP_PCBHASH(INADDR_ANY, lport, 0, pcbinfo->h= ashmask)]; LIST_FOREACH(inp, head, inp_hash) { #ifdef INET6 @@ -1045,24 +1055,43 @@ if (ifp && ifp->if_type =3D=3D IFT_FAITH && (inp->inp_flags & INP_FAITH) =3D=3D 0) continue; - if (inp->inp_laddr.s_addr =3D=3D laddr.s_addr) - return (inp); - else if (inp->inp_laddr.s_addr =3D=3D INADDR_ANY) { + cred =3D inp->inp_socket->so_cred; + if (jailed(cred)) { + if (jinp !=3D NULL) + continue; + if (!jailed_ip(cred, + ntohl(laddr.s_addr))) { + continue; + } + } + if (inp->inp_laddr.s_addr =3D=3D laddr.s_addr) { + if (jailed(cred)) + jinp =3D inp; + else + return (inp); + } else if (inp->inp_laddr.s_addr =3D=3D INADDR_ANY) { #if defined(INET6) if (INP_CHECK_SOCKAF(inp->inp_socket, AF_INET6)) local_wild_mapped =3D inp; else #endif /* defined(INET6) */ - local_wild =3D inp; + if (jailed(cred)) + jinp_wild =3D inp; + else + local_wild =3D inp; } } } + if (local_wild !=3D NULL) + return (local_wild); #if defined(INET6) - if (local_wild =3D=3D NULL) + if (local_wild_mapped !=3D NULL) return (local_wild_mapped); #endif /* defined(INET6) */ - return (local_wild); + if (jinp !=3D NULL) + return (jinp); + return (jinp_wild); } =20 /* @@ -1176,7 +1205,7 @@ { if (!jailed(td->td_ucred)) return (0); - if (ntohl(inp->inp_laddr.s_addr) =3D=3D prison_getip(td->td_ucred)) + if (jailed_ip(td->td_ucred, ntohl(inp->inp_laddr.s_addr))) return (0); return (1); } diff -ru /usr/src/sys/netinet/in_pcb.h src/sys/netinet/in_pcb.h --- /usr/src/sys/netinet/in_pcb.h Wed Apr 2 22:14:43 2003 +++ src/sys/netinet/in_pcb.h Tue Apr 15 11:47:57 2003 @@ -40,6 +40,7 @@ #include #include #include +#include =20 #include =20 @@ -340,7 +341,7 @@ void in_pcbdisconnect(struct inpcb *); int in_pcbinshash(struct inpcb *); struct inpcb * - in_pcblookup_local(struct inpcbinfo *, + in_pcblookup_local(struct ucred *, struct inpcbinfo *, struct in_addr, u_int, int); struct inpcb * in_pcblookup_hash(struct inpcbinfo *, struct in_addr, u_int, diff -ru /usr/src/sys/netinet6/in6_pcb.c src/sys/netinet6/in6_pcb.c --- /usr/src/sys/netinet6/in6_pcb.c Wed Feb 19 23:32:42 2003 +++ src/sys/netinet6/in6_pcb.c Tue Apr 15 18:00:45 2003 @@ -211,9 +211,9 @@ struct sockaddr_in sin; =20 in6_sin6_2_sin(&sin, sin6); - t =3D in_pcblookup_local(pcbinfo, - sin.sin_addr, lport, - INPLOOKUP_WILDCARD); + t =3D in_pcblookup_local(td->td_ucred, + pcbinfo, sin.sin_addr, lport, + INPLOOKUP_WILDCARD); if (t && (so->so_cred->cr_uid !=3D t->inp_socket->so_cred->cr_uid) && @@ -233,8 +233,8 @@ struct sockaddr_in sin; =20 in6_sin6_2_sin(&sin, sin6); - t =3D in_pcblookup_local(pcbinfo, sin.sin_addr, - lport, wild); + t =3D in_pcblookup_local(td->td_ucred, pcbinfo, + sin.sin_addr, lport, wild); if (t && (reuseport & t->inp_socket->so_options) =3D=3D 0 && diff -ru /usr/src/sys/sys/jail.h src/sys/sys/jail.h --- /usr/src/sys/sys/jail.h Wed Apr 9 04:55:18 2003 +++ src/sys/sys/jail.h Tue Apr 15 12:38:23 2003 @@ -17,17 +17,21 @@ u_int32_t version; char *path; char *hostname; - u_int32_t ip_number; + u_int32_t *ips; + u_int nips; }; =20 +#define JAIL_MAX_IPS 256 + struct xprison { - int pr_version; - int pr_id; - char pr_path[MAXPATHLEN]; - char pr_host[MAXHOSTNAMELEN]; - u_int32_t pr_ip; + int pr_version; + int pr_id; + char pr_path[MAXPATHLEN]; + char pr_host[MAXHOSTNAMELEN]; + u_int32_t pr_ips[JAIL_MAX_IPS]; + u_int pr_nips; }; -#define XPRISON_VERSION 1 +#define XPRISON_VERSION 2 =20 #ifndef _KERNEL =20 @@ -65,7 +69,8 @@ char pr_path[MAXPATHLEN]; /* (c) chroot path */ struct vnode *pr_root; /* (c) vnode to rdir */ char pr_host[MAXHOSTNAMELEN]; /* (p) jail hostname */ - u_int32_t pr_ip; /* (c) ip addr host */ + u_int32_t *pr_ips; /* (c) ip addr host */ + u_int pr_nips; void *pr_linux; /* (p) linux abi */ int pr_securelevel; /* (p) securelevel */ struct mtx pr_mtx; @@ -92,11 +97,11 @@ void getcredhostname(struct ucred *cred, char *, size_t); int prison_check(struct ucred *cred1, struct ucred *cred2); void prison_free(struct prison *pr); -u_int32_t prison_getip(struct ucred *cred); void prison_hold(struct prison *pr); int prison_if(struct ucred *cred, struct sockaddr *sa); int prison_ip(struct ucred *cred, int flag, u_int32_t *ip); void prison_remote_ip(struct ucred *cred, int flags, u_int32_t *ip); +int jailed_ip(struct ucred *cred, u_int32_t ip); =20 #endif /* !_KERNEL */ #endif /* !_SYS_JAIL_H_ */ diff -ru /usr/src/usr.sbin/jail/jail.c src/usr.sbin/jail/jail.c --- /usr/src/usr.sbin/jail/jail.c Wed Apr 9 05:04:12 2003 +++ src/usr.sbin/jail/jail.c Tue Apr 15 12:30:01 2003 @@ -36,6 +36,8 @@ struct in_addr in; int ch, groups[NGROUPS], i, iflag, ngroups; char *username; + int c; + char *ip; =20 iflag =3D 0; username =3D NULL; @@ -71,12 +73,25 @@ if (chdir(argv[0]) !=3D 0) err(1, "chdir: %s", argv[0]); memset(&j, 0, sizeof(j)); - j.version =3D 0; + j.version =3D 1; j.path =3D argv[0]; j.hostname =3D argv[1]; - if (inet_aton(argv[2], &in) =3D=3D 0) - errx(1, "Could not make sense of ip-number: %s", argv[2]); - j.ip_number =3D ntohl(in.s_addr); + for (c =3D 1, ip =3D argv[2]; *ip; ++ip) { + if (*ip =3D=3D ',') + ++c; + } + if ((j.ips =3D (u_int32_t *)malloc(sizeof(u_int32_t) * c)) =3D=3D NULL) + errx(1, "malloc()"); + for (c =3D 0, ip =3D strtok(argv[2], ","); ip; + ++c, ip =3D strtok(NULL, ",")) { + i =3D inet_aton(ip, &in); + if (!i) { + free(j.ips); + errx(1, "Couldn't make sense of ip-number\n"); + } + j.ips[c] =3D ntohl(in.s_addr); + } + j.nips =3D c; i =3D jail(&j); if (i =3D=3D -1) err(1, "jail"); @@ -102,6 +117,6 @@ { =20 (void)fprintf(stderr, - "usage: jail [-i] [-u username] path hostname ip-number command ...\n"); + "usage: jail [-i] [-u username] path hostname ip1[,ip2[...]] command ...\= n"); exit(1); } diff -ru /usr/src/usr.sbin/jls/jls.c src/usr.sbin/jls/jls.c --- /usr/src/usr.sbin/jls/jls.c Wed Apr 9 05:04:12 2003 +++ src/usr.sbin/jls/jls.c Tue Apr 15 12:47:58 2003 @@ -43,7 +43,7 @@ {=20 struct xprison *sxp, *xp; struct in_addr in; - size_t i, len; + size_t i, j, len; =20 if (sysctlbyname("security.jail.list", NULL, &len, NULL, 0) =3D=3D -1) err(1, "sysctlbyname(): security.jail.list"); @@ -67,9 +67,13 @@ =20 printf(" JID IP Address Hostname Path\n"); for (i =3D 0; i < len / sizeof(*xp); i++) { - in.s_addr =3D ntohl(xp->pr_ip); + in.s_addr =3D ntohl(xp->pr_ips[0]); printf("%6d %-12.12s %-29.29s %.77s\n", xp->pr_id, inet_ntoa(in), xp->pr_host, xp->pr_path); + for (j =3D 1; j < xp->pr_nips; ++j) { + in.s_addr =3D ntohl(xp->pr_ips[j]); + printf(" %-12.12s\n", inet_ntoa(in)); + } xp++; } free(sxp); --V4yrq4dHtCqH+JvC-- --BcZrms9gUsdgyR6a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBPpw+xT/PhmMH/Mf1AQEavwQAmaG3u/QiwAfUG5PMPAMWfROPzl+SGHgA CfN5jx3S5ZPMI3awwASNYNF1WutHH++na/85tYU/zL6BKr/mKSZC2zW2WN/PFNul orRmBoYKXahige2JBYn8yc+IHbNwNf8AGNsqnEjWWDD6PRP9FFDySop7kymXcoSM qRmPircf0yo= =1/2N -----END PGP SIGNATURE----- --BcZrms9gUsdgyR6a-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 10:17:49 2003 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 2403537B404 for ; Tue, 15 Apr 2003 10:17:49 -0700 (PDT) Received: from ns.isi.ulatina.ac.cr (ns.isi.ulatina.ac.cr [163.178.60.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2404343FB1 for ; Tue, 15 Apr 2003 10:17:48 -0700 (PDT) (envelope-from fabmirha@ns.isi.ulatina.ac.cr) Received: by ns.isi.ulatina.ac.cr (Postfix, from userid 5481) id BD5201FF2A; Tue, 15 Apr 2003 11:11:02 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ns.isi.ulatina.ac.cr (Postfix) with ESMTP id AE5C02BFB3; Tue, 15 Apr 2003 11:11:02 -0600 (CST) Date: Tue, 15 Apr 2003 11:11:02 -0600 (CST) From: Fabio Miranda Hamburger To: Patrick Soltani In-Reply-To: <3DBB075EEB95944492E127F2B9A96FAF5398F4@ultra-exchange.ultradns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBsd-hackers@freebsd.org Subject: RE: honest 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: Tue, 15 Apr 2003 17:17:49 -0000 > >The problem is Xfree86 just support 24 bit color quality, and > >vmware under > >freebsd is still bogus, the apm feature doesnt work. > > Did you add the following line in your kernel file? > device apm0 at nexus? flags 0x20 # Advanced Power Management > > Any specific errors/behavior? or Did you try the bios to disable the power management? > > I don't have the your make and model laptop, but been very successful in doing apm on many machines, even when XP says "now you can turn the computer off" after issuing shutdown :-). > > Each laptop has slightly different attitude towards power management, but I am sure you'd be able to find some help on the freebsd mailing list and/or "googling" it. I have done all that, They apm status info says that is unable to get status. > >Okey, to be honest i like freebsd but I am affraid freebsd is > >not an ideal > >os for a laptop. > >What u guys think? > >I dont like linux, but I am forced to switch, what u think? > Have you updated the /usr/ports? Although Xfree86 is not as simple as it should be, however, have had very little problem with compiling it from source or installing it from CD. > > What has worked for me is "portupgrade" that automatically upgrades my ports with little hassle. I keep my system updated in -stable branch. XFree86 doesnt take advantage of my high resolution I only see 24 bits true color. FreeBSD should be able to run on laptops, i like freebsd style. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 11:37:35 2003 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 DBD3F37B401 for ; Tue, 15 Apr 2003 11:37:35 -0700 (PDT) Received: from mail-pm.star.spb.ru (mail-pm.star.spb.ru [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0574C43FA3 for ; Tue, 15 Apr 2003 11:37:32 -0700 (PDT) (envelope-from nkritsky@star.spb.ru) Received: from pink.star.spb.ru ([217.195.82.10]) by mail-pm.star.spb.ru (8.12.9/8.12.8) with ESMTP id h3FIbTaY005987 for ; Tue, 15 Apr 2003 22:37:29 +0400 (MSD) Received: from IBMKA ([217.195.82.7]) by pink.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20SVDT97; Tue, 15 Apr 2003 22:37:29 +0400 Date: Tue, 15 Apr 2003 22:37:30 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <1222010669.20030415223730@star.spb.ru> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Kernel variables - where is TFM? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 18:37:36 -0000 Hello freebsd-hackers, While browsing FreeBSD kernel sources I ocassionally stick in some strange words which I suppose are kernel-space global variables. For example: ticks, hz. Where can I find info about such variables? Please cc me in your reply, or reply me off-list because I am not subscribed to -hackers. Any help is very good. -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR SPb ; mailto:nkritsky@star.spb.ru From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 12:06:14 2003 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 1B1B337B404 for ; Tue, 15 Apr 2003 12:06:14 -0700 (PDT) Received: from lakemtao04.cox.net (lakemtao04.cox.net [68.1.17.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D51443FAF for ; Tue, 15 Apr 2003 12:06:12 -0700 (PDT) (envelope-from brian@shadowcom.net) Received: from shadowcom.net ([68.100.212.237]) by lakemtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030415190612.FOPJ13930.lakemtao04.cox.net@shadowcom.net> for ; Tue, 15 Apr 2003 15:06:12 -0400 Received: (qmail 76406 invoked by uid 500); 15 Apr 2003 19:08:18 -0000 Date: Tue, 15 Apr 2003 15:08:18 -0400 From: Brian Ledbetter To: Josef Karthauser Message-ID: <20030415190818.GQ75452@shadowcom.net> References: <20030413175528.GB32297@shadowcom.net> <20030413194209.GC92799@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030413194209.GC92799@genius.tao.org.uk> User-Agent: Mutt/1.4i cc: hackers@freebsd.org Subject: Re: dev/usb/uvisor - Sony Clie PEG-S360 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, 15 Apr 2003 19:06:14 -0000 > You shouldn't need to switch to -current, as it's only a few lines of > code to get the uvisor to attach to the Clie. That unfortunately isn't > the problem. We've got an issue with compatibility with palm os > 4.0 > and I've not been able to determine what it is yet. There's an > interaction somewhere in the stack that causes the palmos stack to stop > sending data... unfortuately I can't give you a time scale as to how > long it will take to get it fixed. Josef, Thanks for the quick reply! The device in question is Palm OS = 4.0, but it still doesn't work. I keep meaning to put my hacked code back into my copy of uvisor.ko so I can send you the dmesg of what happens when I activate the device - I get "timeout" errors attaching to the umass devices, as I recall... :) -- Brian Ledbetter http://www.shadowcom.net/brian/ From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 22:23:40 2003 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 AA8E737B401; Tue, 15 Apr 2003 22:23:40 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCCC143F93; Tue, 15 Apr 2003 22:23:39 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003041605233800100ohj9se>; Wed, 16 Apr 2003 05:23:38 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3G5Nbki002795; Tue, 15 Apr 2003 22:23:37 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3G5NZew002794; Tue, 15 Apr 2003 22:23:35 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 15 Apr 2003 22:23:35 -0700 From: "Crist J. Clark" To: "Jacques A. Vidrine" , freebsd-hackers@FreeBSD.org Message-ID: <20030416052335.GA2519@blossom.cjclark.org> References: <20030410161511.GA25681@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410161511.GA25681@madman.celabo.org> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 05:23:41 -0000 On Thu, Apr 10, 2003 at 11:15:11AM -0500, Jacques A. Vidrine wrote: [snip] > router1 > spdadd 10.3.14.0/24 173.173.173.173 any > -P out esp/tunnel/223.223.223.223-173.173.173.173/require; > spdadd 173.173.173.173 10.3.14.0/24 any > -P in esp/tunnel/173.173.173.173-223.223.223.223/require; > > server1 > spdadd 10.3.14.0/24 173.173.173.173 any > -P in esp/tunnel/223.223.223.223-173.173.173.173/require; > spdadd 173.173.173.173 10.3.14.0/24 any > -P out esp/tunnel/173.173.173.173-223.223.223.223/require; > > However, this does not work :-) Outbound packets are encapsulated as > expected, i.e. packets leave `router1' looking like this: [snip] > but they are dropped by `server1', and the `inbound packets violated > process security policy' counter is incremented. > > > If one relaxes the inbound policies given above by changing `require' > to `use', then the packets are no longer dropped and everything works > as (I) expected. Packets in both directions are properly encapsulated. > > However, `use' is not the policy desired, of course :-) > > The fact that `use' works, and `require' does not leads me to believe > that when a packet is received and processed in tunnel mode, that the > de-encapsulated packet (the internal one) is AGAIN matched against the > SPD, causing the `violated process security policy'. > > > So, KAME/IPsec experts ... have I gone atray with my configuration? > Or is this simply not doable within the KAME framework? > Or is this a bug (assuming my theory that packets are matched against > the SPD again after de-encapsulation is correct)? 'uname -a'? I can't reproduce this on a 4.8 to 4.7 tunnel. On 192.168.64.70, spdadd 192.168.64.70/32 10.0.0.0/24 any -P out ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; spdadd 10.0.0.0/24 192.168.64.70/32 any -P in ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; And on 192.168.64.20, the gateway to 10.0.0.0/24, spdadd 192.168.64.70/32 10.0.0.0/24 any -P in ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; spdadd 10.0.0.0/24 192.168.64.70/32 any -P out ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; Works fine. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 23:53:14 2003 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 5D28437B401; Tue, 15 Apr 2003 23:53:14 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B092043F85; Tue, 15 Apr 2003 23:53:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0135.cvx40-bradley.dialup.earthlink.net ([216.244.42.135] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 195gn8-0001yq-00; Tue, 15 Apr 2003 23:53:11 -0700 Message-ID: <3E9CFD8A.89353F06@mindspring.com> Date: Tue, 15 Apr 2003 23:51:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Crist J. Clark" References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f9a4ca659417c43cd7e53de84b8267fa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: "Jacques A. Vidrine" cc: freebsd-hackers@FreeBSD.org Subject: Re: Single IP host and IPsec tunnel mode experience 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, 16 Apr 2003 06:53:14 -0000 "Crist J. Clark" wrote: > On Thu, Apr 10, 2003 at 11:15:11AM -0500, Jacques A. Vidrine wrote: > > So, KAME/IPsec experts ... have I gone atray with my configuration? > > Or is this simply not doable within the KAME framework? > > Or is this a bug (assuming my theory that packets are matched against > > the SPD again after de-encapsulation is correct)? > > 'uname -a'? I can't reproduce this on a 4.8 to 4.7 tunnel. On > 192.168.64.70, > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; FWIW, we ran into this same problem. Deleting the default route fixed it, for some reason. I never did track it down because we stopped shipping with IPSEC enabled, because of the huge overhead it had for all IPv4 connections (each connection eats a large chunk of RAM, which doesn't happen in the IPv6 case). I keep meaning to fix this, but I'm always hoping that the KAME people get to it first (on the other hand, maybe they don't *want* it fixed, to encourage people to use IPv6 instead ;^)). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 00:04:44 2003 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 B548337B401; Wed, 16 Apr 2003 00:04:44 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id C866243FE1; Wed, 16 Apr 2003 00:04:43 -0700 (PDT) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h3G74hSs019202; Wed, 16 Apr 2003 09:04:43 +0200 Received: (nullmailer pid 1112 invoked by uid 1000); Wed, 16 Apr 2003 06:01:00 -0000 Date: Wed, 16 Apr 2003 08:01:00 +0200 From: Mark Santcroos To: phk@freebsd.org Message-ID: <20030416060100.GA1048@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Handles: MS6-6BONE, MS18417-RIPE cc: hackers@freebsd.org Subject: ioctl's in md 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, 16 Apr 2003 07:04:45 -0000 Hi Poul-Henning, Now that md is geomized [is that the correct term ;)], how can I add an ioctl handler for a created md device? As there isn't simply a make_dev(), and I have to go through the geom system, I wonder if it is possible at all. The reason for this is that I want to make a CDROM type, similar to the VNODE type, but that handles cdrom ioctl's. (Which is necesarry to make vmware2 boot from a "cdrom"). Mark ps. I tried to find the answer in sys/dev/ata/, there I saw that only atapi-cd and atapi-tape do make_dev()'s. Is that because they need ioctl's or is that totally unrelated? -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 01:24:15 2003 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 5A59A37B401 for ; Wed, 16 Apr 2003 01:24:15 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 4CA8343FAF for ; Wed, 16 Apr 2003 01:24:13 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 19924 invoked from network); 16 Apr 2003 08:18:51 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 16 Apr 2003 08:18:51 -0000 Received: (qmail 387 invoked by uid 1000); 16 Apr 2003 08:22:05 -0000 Date: Wed, 16 Apr 2003 11:22:04 +0300 From: Peter Pentchev To: omestre@freeshell.org Message-ID: <20030416082204.GC26408@straylight.oblivion.bg> Mail-Followup-To: omestre@freeshell.org, freebsd-hackers@freebsd.org References: <20030411194551.C5D0E10162@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <20030411194551.C5D0E10162@ws-tor-0004.procergs> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: perchild 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, 16 Apr 2003 08:24:15 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 11, 2003 at 04:45:46PM -0300, omestre@freeshell.org wrote: >=20 > Hello all... > Has somebody compiled FreeBSD 5.0 with apache 2.0 mpm perchild feature? > I have the old problem with php scripts (the php scripts runnig with=20 > the same user:group of apache). > So, I need apache 2.0, with mpm:perchild module. This modules allow apac= he > start php scripts with diferent uid:gid. > The threads in FreeBSD 5.0, how they are? userland or kernel level (like= linux)? > Somebody knows how can i solve that problem? A quick examination of the ports/www/apache2/Makefile shows that you can build it in perchild mode by setting the WITH_MPM environment variable to 'perchild'. In other words, cd /usr/ports/www/apache2 make WITH_MPM=3Dperchild clean all install && make clean G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+nRKr7Ri2jRYZRVMRAuzBAKC6V4xFGAdMobLkNPUQb0MeTlwylgCgtx2X m5ELkT2k9p29OfBqM7MC/U8= =bSxm -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 01:35:36 2003 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 17BF237B401 for ; Wed, 16 Apr 2003 01:35:36 -0700 (PDT) Received: from ns3.unixmexico.net (ns3.unixmexico.net [69.10.137.124]) by mx1.FreeBSD.org (Postfix) with SMTP id 62D3D43F85 for ; Wed, 16 Apr 2003 01:35:35 -0700 (PDT) (envelope-from nbari@unixmexico.com) Received: (qmail 99336 invoked by uid 85); 16 Apr 2003 08:36:03 -0000 Received: from nbari@unixmexico.com by ns3.unixmexico.net by uid 82 with qmail-scanner-1.15 (hbedv: 6.18.0.3/6.18.0.19. Clear:. Processed in 0.309112 secs); 16 Apr 2003 08:36:03 -0000 Received: from unknown (HELO mail.unixmexico.com) (69.10.137.124) by ns3.unixmexico.net with SMTP; 16 Apr 2003 08:36:03 -0000 Received: from 148.243.211.57 (SquirrelMail authenticated user nbari@unixmexico.com) by mail.unixmexico.com with HTTP; Wed, 16 Apr 2003 03:36:03 -0500 (CDT) Message-ID: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> Date: Wed, 16 Apr 2003 03:36:03 -0500 (CDT) From: nbari@unixmexico.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 1 Importance: High Subject: HP psc 750 on FreeBSD 4.8 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, 16 Apr 2003 08:35:36 -0000 Hi all, i have an HP psc 750 USB printer Any idea on how configure this printer to make it work on FreeBSD ? i have this lines on my kernel: device usb device uhci device ulpt device uscanner device ugen dmesg give me this: ugen0: Hewlett-Packard PSC 750, rev 1.10/1.00, addr 2 usbdevs -v give me this: Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: power 2 mA, config 1, PSC 750(0x1411), Hewlett-Packard(0x03f0), rev 1.00 port 2 addr 3: low speed, self powered, config 1, ASC495 Speakers(0xff05), ALTEC LANSING Multimedia (0x04d2), rev 0.00 when trying to run an lptest > /dev/ulpt0 i get an : /dev/ulpt0: Device not configured. and when runing lptest > /dev/ugen0 nothing happens. Thanks From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 03:09:26 2003 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 A766537B401 for ; Wed, 16 Apr 2003 03:09:26 -0700 (PDT) Received: from mail-pm.star.spb.ru (mail-pm.star.spb.ru [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F290643F85 for ; Wed, 16 Apr 2003 03:09:24 -0700 (PDT) (envelope-from nkritsky@star.spb.ru) Received: from pink.star.spb.ru ([217.195.82.10]) by mail-pm.star.spb.ru (8.12.9/8.12.8) with ESMTP id h3GA8naY011140; Wed, 16 Apr 2003 14:08:49 +0400 (MSD) Received: from IBMKA ([217.195.82.7]) by pink.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20SVDVJ6; Wed, 16 Apr 2003 14:08:49 +0400 Date: Wed, 16 Apr 2003 14:08:52 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <2377892423.20030416140852@star.spb.ru> To: Igor Pokrovsky In-reply-To: <20030416073329.GB298@exmatis1.cnrm.meteo.fr> References: <1222010669.20030415223730@star.spb.ru> <20030416073329.GB298@exmatis1.cnrm.meteo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re[2]: Kernel variables - where is TFM? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 10:09:26 -0000 Hello Igor, First, thanks for the reply. But I still have some questions. Wednesday, April 16, 2003, 11:33:29 AM, you wrote: IP> On Tue, Apr 15, 2003 at 10:37:30PM +0400, Nickolay A. Kritsky wrote: >> Hello freebsd-hackers, >> >> While browsing FreeBSD kernel sources I ocassionally stick in some >> strange words which I suppose are kernel-space global variables. For >> example: ticks, hz. Where can I find info about such variables? Please >> cc me in your reply, or reply me off-list because I am not subscribed >> to -hackers. IP> sysctl -a | grep hz On my 4.6 system it gives me: kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 } What does that mean? hz is the IRQ0 frequency? Then, what is tick? and what is ticks (note the trailing `s') ? IP> sysctl(8) sysctl. Well, this is great, but here comes another question: in /usr/src/sys/netinet/tcp_syncache_c one can see: ;-----------------Begin clipboard-------------------------- SYSCTL_INT(_net_inet_tcp, OID_AUTO, syncookies, CTLFLAG_RW, &tcp_syncookies, 0, "Use TCP SYN cookies if the syncache overflows"); ;-------------------End clipboard-------------------------- Is it the place where sysctl is added to kernel state MIB? If yes, I assume that every sysctl can have a `description' (the last parameter in SYSCTL_INT macro). Is there an interface to read such descriptions? -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR SPb ; mailto:nkritsky@star.spb.ru From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 04:27:31 2003 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 1817337B401; Wed, 16 Apr 2003 04:27:31 -0700 (PDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C0343FA3; Wed, 16 Apr 2003 04:27:29 -0700 (PDT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 16 Apr 2003 12:27:13 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 195l2N-0000c8-00; Wed, 16 Apr 2003 12:25:11 +0100 Date: Wed, 16 Apr 2003 12:25:11 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Pawel Jakub Dawidek In-Reply-To: <20030415171757.GU52293@garage.freebsd.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant cc: freebsd-hackers@freebsd.org cc: Martin Blapp cc: Robert Watson cc: Poul-Henning Kamp Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). 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, 16 Apr 2003 11:27:31 -0000 On Tue, 15 Apr 2003, Pawel Jakub Dawidek wrote: > Hello hackers... > > I've just finished patch for multiple ip-numbers inside jails. > > There was a problem with handling INADDR_ANY correctly in multiple ips > implementations, but I think I solved this problem. > > Another thing are priorities. > When port X is opened on main host and in jail as INADDR_ANY, current > implementation of jail converts INADDR_ANY to jail's IP. > When we're connecting to this port we will connect to jail's daemon, > because "exactly match" is there. > In my solution looking for opened port is in this order: > 1. non-jailed, non-wild. > 2. non-jailed, wild. > 3. jailed, non-wild. > 4. jailed, wild. Hang on, so you're saying that if my machine has (say) 4 IP addresses, and the jail has two of them, and I've a process listening on INADDR_ANY in a non-jail, and one listening on INADDR_ANY in a jail, then a connection to one of the jailed IPs will wind up with the non-jail process? That seems backwards to me. That is, it seems that the most "specific" INADDR_ANY should match first. > Please, review it. Thanks. > > PS. Patch is against FreeBSD-CURRENT. > > -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Axioms speak louder than words. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 05:02:10 2003 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 5A4CA37B401; Wed, 16 Apr 2003 05:02:10 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 712B143F3F; Wed, 16 Apr 2003 05:02:09 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 9074C3ABB4D; Wed, 16 Apr 2003 14:02:59 +0200 (CEST) Date: Wed, 16 Apr 2003 14:02:59 +0200 From: Pawel Jakub Dawidek To: Jan Grant Message-ID: <20030416120259.GB92137@garage.freebsd.pl> References: <20030415171757.GU52293@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org cc: Martin Blapp cc: Robert Watson cc: Poul-Henning Kamp Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). 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, 16 Apr 2003 12:02:10 -0000 --WhfpMioaduB5tiZL Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2003 at 12:25:11PM +0100, Jan Grant wrote: +> > Another thing are priorities. +> > When port X is opened on main host and in jail as INADDR_ANY, current +> > implementation of jail converts INADDR_ANY to jail's IP. +> > When we're connecting to this port we will connect to jail's daemon, +> > because "exactly match" is there. +> > In my solution looking for opened port is in this order: +> > 1. non-jailed, non-wild. +> > 2. non-jailed, wild. +> > 3. jailed, non-wild. +> > 4. jailed, wild. +>=20 +> Hang on, so you're saying that if my machine has (say) 4 IP addresses, +> and the jail has two of them, and I've a process listening on INADDR_ANY +> in a non-jail, and one listening on INADDR_ANY in a jail, then a +> connection to one of the jailed IPs will wind up with the non-jail +> process? In current implelentation - yes, becuase there is no INADDR_ANY in jail, becuase INADDR_ANY address is translated to jail's ip when bind(2) is called. When connection arrives kernel choosing "exactly match" first and "exactly match" is real ip number. If there is no "exactly match" INADDR_ANY is taken. But check this out by yourself: # /usr/sbin/sshd -p 666 # jail / temp /usr/sbin/sshd -p 666 # ssh -p 666 # hostname (sshd binds to INADDR_ANY by default) --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --WhfpMioaduB5tiZL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBPp1Gcz/PhmMH/Mf1AQFF1AP/dhwjLFRYRUhA+xitP6Jlsbpph7ugXzDF n89Fvm5IE8BVxI4MY1RJnkx0H7eaCQlDpzGBDF0RhYOMncb3SMFFDzc4GlyiJC8k QU3E40mtAgy3qSSeXiaMoPm2fOt3dhTjdf2tcN/1QdleAvSRNcmCsfFljxNtBkeV F1Hwu3yQQyc= =Hgq8 -----END PGP SIGNATURE----- --WhfpMioaduB5tiZL-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 05:14:51 2003 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 681DA37B401 for ; Wed, 16 Apr 2003 05:14:51 -0700 (PDT) Received: from vivaldi.meteo.fr (vivaldi.meteo.fr [137.129.28.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BCF43FA3 for ; Wed, 16 Apr 2003 05:14:44 -0700 (PDT) (envelope-from igor.pokrovsky@cnrm.meteo.fr) Received: from cti825.cnrm.meteo.fr (localhost.meteo.fr [127.0.0.1]) MAA16869 for ; Wed, 16 Apr 2003 12:14:40 GMT Received: from xdata.cnrm.meteo.fr (xdata.cnrm.meteo.fr [137.129.150.2]) OAA07581; Wed, 16 Apr 2003 14:14:38 +0200 (MESTDST) Received: from exmatis1.cnrm.meteo.fr (exmatis1.cnrm.meteo.fr [137.129.157.46]) by xdata.cnrm.meteo.fr with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id OAA21783; Wed, 16 Apr 2003 14:14:36 +0200 (METDST) Received: from exmatis1.cnrm.meteo.fr (localhost [127.0.0.1]) h3GCE6ZG000350; Wed, 16 Apr 2003 14:14:06 +0200 (CEST) (envelope-from pokrovsi@exmatis1.cnrm.meteo.fr) Received: (from pokrovsi@localhost) by exmatis1.cnrm.meteo.fr (8.12.9/8.12.9/Submit) id h3GCE63f000349; Wed, 16 Apr 2003 14:14:06 +0200 (CEST) Date: Wed, 16 Apr 2003 14:14:06 +0200 From: Igor Pokrovsky To: "Nickolay A. Kritsky" Message-ID: <20030416121406.GA229@exmatis1.cnrm.meteo.fr> Mail-Followup-To: Igor Pokrovsky , "Nickolay A. Kritsky" , freebsd-hackers@freebsd.org References: <1222010669.20030415223730@star.spb.ru> <20030416073329.GB298@exmatis1.cnrm.meteo.fr> <2377892423.20030416140852@star.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2377892423.20030416140852@star.spb.ru> User-Agent: Mutt/1.4.1i X-Accept-Language: ru X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (cti825/CNRM) Organization: METEO FRANCE(CNRM) cc: Igor Pokrovsky cc: freebsd-hackers@freebsd.org Subject: Re: Kernel variables - where is TFM? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Pokrovsky List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 12:14:51 -0000 On Wed, Apr 16, 2003 at 02:08:52PM +0400, Nickolay A. Kritsky wrote: > >> Hello freebsd-hackers, > >> > >> While browsing FreeBSD kernel sources I ocassionally stick in some > >> strange words which I suppose are kernel-space global variables. For > >> example: ticks, hz. Where can I find info about such variables? Please > >> cc me in your reply, or reply me off-list because I am not subscribed > >> to -hackers. > > IP> sysctl -a | grep hz > On my 4.6 system it gives me: > kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 } > What does that mean? hz is the IRQ0 frequency? Then, what is tick? and > what is ticks (note the trailing `s') ? Where did you find 'ticks'? >From /usr/include/sys/time.h : -- snip -- /* * Getkerninfo clock information structure */ struct clockinfo { int hz; /* clock frequency */ int tick; /* micro-seconds per hz tick */ int tickadj; /* clock skew rate for adjtime() */ int stathz; /* statistics clock frequency */ int profhz; /* profiling clock frequency */ }; -- snip -- > IP> sysctl(8) > sysctl. Well, this is great, but here comes another question: > in /usr/src/sys/netinet/tcp_syncache_c one can see: > ;-----------------Begin clipboard-------------------------- > SYSCTL_INT(_net_inet_tcp, OID_AUTO, syncookies, CTLFLAG_RW, > &tcp_syncookies, 0, > "Use TCP SYN cookies if the syncache overflows"); > ;-------------------End clipboard-------------------------- > Is it the place where sysctl is added to kernel state MIB? If yes, I > assume that every sysctl can have a `description' (the last parameter > in SYSCTL_INT macro). Is there an interface to read such descriptions? The only place where you can see all descriptions AFAIK is sysctl(3) (note '3', not '8') -- Igor From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 05:36:23 2003 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 5AC0837B401; Wed, 16 Apr 2003 05:36:23 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86EAC43F93; Wed, 16 Apr 2003 05:36:22 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id D88FE38; Wed, 16 Apr 2003 07:36:21 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 3AE7278C44; Wed, 16 Apr 2003 07:36:21 -0500 (CDT) Date: Wed, 16 Apr 2003 07:36:21 -0500 From: "Jacques A. Vidrine" To: "Crist J. Clark" Message-ID: <20030416123621.GC72501@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Crist J. Clark" , freebsd-hackers@FreeBSD.org References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030416052335.GA2519@blossom.cjclark.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-hackers@FreeBSD.org Subject: Re: Single IP host and IPsec tunnel mode experience 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, 16 Apr 2003 12:36:23 -0000 On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > 'uname -a'? The endpoints were both 4.7. > I can't reproduce this on a 4.8 to 4.7 tunnel. On > 192.168.64.70, > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > And on 192.168.64.20, the gateway to 10.0.0.0/24, > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > Works fine. Hmm, yes, that appears to be exactly what I'm trying to do. Well, that's heartening ... it means that there is likely some anomoly in my environment that is hosing me. Now if only I can figure what it is :-) -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 05:58:49 2003 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 A4B0E37B401 for ; Wed, 16 Apr 2003 05:58:49 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8B843FCB for ; Wed, 16 Apr 2003 05:58:48 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id D13D1A983 for ; Wed, 16 Apr 2003 09:58:45 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id CE1901030E; Wed, 16 Apr 2003 09:58:44 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id ACA851030D for ; Wed, 16 Apr 2003 09:58:44 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Wed, 16 Apr 2003 09:58:39 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030416125844.CE1901030E@ws-tor-0004.procergs> Subject: lock 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, 16 Apr 2003 12:58:49 -0000 Does somebody knows about preblems in locks in FreeBSD 5.0 (diskless)? I have some machines (4.7) working fine. But with 5.0, flock and lockf calls do not work... Thanks. --- +-----------------------------------------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 06:01:20 2003 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 3A05337B401 for ; Wed, 16 Apr 2003 06:01:20 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA9D643FDD for ; Wed, 16 Apr 2003 06:01:18 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h3GD0icx095723 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Apr 2003 15:01:09 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h3GD0cYi059668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2003 15:00:39 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.8) with ESMTP id h3GD0btA006672; Wed, 16 Apr 2003 15:00:38 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h3GD0VuL006671; Wed, 16 Apr 2003 15:00:31 +0200 (CEST) (envelope-from ticso) Date: Wed, 16 Apr 2003 15:00:31 +0200 From: Bernd Walter To: nbari@unixmexico.com Message-ID: <20030416130030.GB529@cicely9.cicely.de> References: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org Subject: Re: HP psc 750 on FreeBSD 4.8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 13:01:20 -0000 On Wed, Apr 16, 2003 at 03:36:03AM -0500, nbari@unixmexico.com wrote: > Hi all, i have an HP psc 750 USB printer > > Any idea on how configure this printer to make it work on FreeBSD ? > > i have this lines on my kernel: > > device usb > device uhci > device ulpt > device uscanner > device ugen > > > dmesg give me this: > > ugen0: Hewlett-Packard PSC 750, rev 1.10/1.00, addr 2 Can you please install http://www.cosmo-project.de/~bernd/usbutil.tgz and mail the usbctl output. > usbdevs -v give me this: > Controller /dev/usb0: > addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev > 1.00 > port 1 addr 2: power 2 mA, config 1, PSC 750(0x1411), > Hewlett-Packard(0x03f0), rev 1.00 > port 2 addr 3: low speed, self powered, config 1, ASC495 > Speakers(0xff05), ALTEC LANSING Multimedia (0x04d2), rev 0.00 > > > when trying to run an lptest > /dev/ulpt0 i get an : /dev/ulpt0: Device > not configured. > > and when runing lptest > /dev/ugen0 nothing happens. ugen is a generic driver for raw device access. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 06:49:23 2003 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 8B7A537B401 for ; Wed, 16 Apr 2003 06:49:23 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8739143F93 for ; Wed, 16 Apr 2003 06:49:22 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (gzuvql@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h3GDnKB5008395 for ; Wed, 16 Apr 2003 15:49:20 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h3GDnKxl008394; Wed, 16 Apr 2003 15:49:20 +0200 (CEST) Date: Wed, 16 Apr 2003 15:49:20 +0200 (CEST) Message-Id: <200304161349.h3GDnKxl008394@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20030416120259.GB92137@garage.freebsd.pl> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 13:49:23 -0000 Pawel Jakub Dawidek wrote: > On Wed, Apr 16, 2003 at 12:25:11PM +0100, Jan Grant wrote: > +> Hang on, so you're saying that if my machine has (say) 4 IP addresses, > +> and the jail has two of them, and I've a process listening on INADDR_ANY > +> in a non-jail, and one listening on INADDR_ANY in a jail, That shouldn't be possible at all. You cannot have multiple processes listen on the same address and port, no matter whether they're in a jail or not. If this patch for multiple IP numbers in jails breaks that behaviour, then it does not fix INADDR_ANY behaviour, despite what the subject says. :-) > # /usr/sbin/sshd -p 666 > # jail / temp /usr/sbin/sshd -p 666 That last command _must_ fail with errno EADDRINUSE. 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. "If you do things right, people won't be sure you've done anything at all." -- God in Futurama season 4 episode 8 From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 07:36:22 2003 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 83C6C37B401 for ; Wed, 16 Apr 2003 07:36:22 -0700 (PDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id A23F443FBD for ; Wed, 16 Apr 2003 07:36:21 -0700 (PDT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 16 Apr 2003 15:36:14 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 195nzi-0002GK-00; Wed, 16 Apr 2003 15:34:38 +0100 Date: Wed, 16 Apr 2003 15:34:38 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <200304161349.h3GDnKxl008394@lurza.secnetix.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). 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, 16 Apr 2003 14:36:22 -0000 On Wed, 16 Apr 2003, Oliver Fromme wrote: > Pawel Jakub Dawidek wrote: > > On Wed, Apr 16, 2003 at 12:25:11PM +0100, Jan Grant wrote: > > +> Hang on, so you're saying that if my machine has (say) 4 IP addresses, > > +> and the jail has two of them, and I've a process listening on INADDR_ANY > > +> in a non-jail, and one listening on INADDR_ANY in a jail, > > That shouldn't be possible at all. You cannot have multiple > processes listen on the same address and port, no matter > whether they're in a jail or not. > > If this patch for multiple IP numbers in jails breaks that > behaviour, then it does not fix INADDR_ANY behaviour, despite > what the subject says. :-) > > > # /usr/sbin/sshd -p 666 > > # jail / temp /usr/sbin/sshd -p 666 > > That last command _must_ fail with errno EADDRINUSE. You can't have multiple processes listen on the same address and port, but you CAN have one listen on a specific IP and port and another listen on INADDR_ANY and the same port. By extension, you'd expect a _more specific_ binding of INADDR_ANY to override a more general one. Certainly, if one process is listening on 192.168.0.1:1234, then another should NOT be able to bind to that same address. It's not clear that the same sweeping statement can be made about INADDR_ANY. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ YKYBPTMRogueW... you try to move diagonally in vi. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 08:11:10 2003 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 2B54837B405 for ; Wed, 16 Apr 2003 08:11:10 -0700 (PDT) Received: from mail-pm.star.spb.ru (mail-pm.star.spb.ru [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B77343F93 for ; Wed, 16 Apr 2003 08:11:08 -0700 (PDT) (envelope-from nkritsky@star.spb.ru) Received: from pink.star.spb.ru ([217.195.82.10]) by mail-pm.star.spb.ru (8.12.9/8.12.8) with ESMTP id h3GFASaY011364; Wed, 16 Apr 2003 19:10:28 +0400 (MSD) Received: from IBMKA ([217.195.82.7]) by pink.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20SVDW6F; Wed, 16 Apr 2003 19:10:28 +0400 Date: Wed, 16 Apr 2003 19:10:35 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <10695996045.20030416191035@star.spb.ru> To: Igor Pokrovsky In-reply-To: <20030416121406.GA229@exmatis1.cnrm.meteo.fr> References: <1222010669.20030415223730@star.spb.ru> <20030416073329.GB298@exmatis1.cnrm.meteo.fr> <2377892423.20030416140852@star.spb.ru> <20030416121406.GA229@exmatis1.cnrm.meteo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re[2]: Kernel variables - where is TFM? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 15:11:10 -0000 Hello Igor, Wednesday, April 16, 2003, 4:14:06 PM, you wrote: >> IP> sysctl -a | grep hz >> On my 4.6 system it gives me: >> kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 } >> What does that mean? hz is the IRQ0 frequency? Then, what is tick? and >> what is ticks (note the trailing `s') ? IP> Where did you find 'ticks'? in /usr/src/sys/netinet/tcp_syncache.c it is mentioned quite often. As I understood it is some sort of counter incremented tickly. From Epoch or from uptime, I don't know. >>From /usr/include/sys/time.h : IP> -- snip -- IP> /* IP> * Getkerninfo clock information structure IP> */ IP> struct clockinfo { IP> int hz; /* clock frequency */ IP> int tick; /* micro-seconds per hz tick */ IP> int tickadj; /* clock skew rate for adjtime() */ IP> int stathz; /* statistics clock frequency */ IP> int profhz; /* profiling clock frequency */ IP> }; IP> -- snip -- Hmm. Looks funny. Why keep both hz and tick if tick=(10^6)/hz ? Or am i missing something? >> IP> sysctl(8) >> sysctl. Well, this is great, but here comes another question: >> in /usr/src/sys/netinet/tcp_syncache_c one can see: >> ;-----------------Begin clipboard-------------------------- >> SYSCTL_INT(_net_inet_tcp, OID_AUTO, syncookies, CTLFLAG_RW, >> &tcp_syncookies, 0, >> "Use TCP SYN cookies if the syncache overflows"); >> ;-------------------End clipboard-------------------------- >> Is it the place where sysctl is added to kernel state MIB? If yes, I >> assume that every sysctl can have a `description' (the last parameter >> in SYSCTL_INT macro). Is there an interface to read such descriptions? IP> The only place where you can see all descriptions AFAIK is IP> sysctl(3) (note '3', not '8') Still cant find it. sysctl() - get or set value of state. sysctlbyname() - find variable by name. sysctlnametomib() - find array of variables by name. Looks like the only interface to look up sysctl description is grep(1) :-\ -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR SPb ; mailto:nkritsky@star.spb.ru From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 09:12:08 2003 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 A517437B401 for ; Wed, 16 Apr 2003 09:12:08 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E12043F85 for ; Wed, 16 Apr 2003 09:12:07 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lwxklm@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h3GGC5B5075926 for ; Wed, 16 Apr 2003 18:12:06 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h3GGC58Z075925; Wed, 16 Apr 2003 18:12:05 +0200 (CEST) Date: Wed, 16 Apr 2003 18:12:05 +0200 (CEST) Message-Id: <200304161612.h3GGC58Z075925@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 16:12:08 -0000 Jan Grant wrote: > You can't have multiple processes listen on the same address and port, > but you CAN have one listen on a specific IP and port and another listen > on INADDR_ANY and the same port. By extension, you'd expect a _more > specific_ binding of INADDR_ANY to override a more general one. Oops, you are right. Must have been my lack of caffeine. :-) It means that you have to be very careful with daemons that run in the host environment. If they bind to INADDR_ANY, then any jailed process can override them (for the jail IPs). That might be a dangerous. Would be nice to have a knob to disable that behaviour. 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. "If you do things right, people won't be sure you've done anything at all." -- God in Futurama season 4 episode 8 From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 11:04:26 2003 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 0E43F37B401 for ; Wed, 16 Apr 2003 11:04:26 -0700 (PDT) Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A2343FA3 for ; Wed, 16 Apr 2003 11:04:25 -0700 (PDT) (envelope-from l.ertl@univie.ac.at) Received: from localhost.localdomain (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id h3GI4Hos366236 for ; Wed, 16 Apr 2003 20:04:19 +0200 Date: Wed, 16 Apr 2003 20:04:17 +0200 (CEST) From: Lukas Ertl To: freebsd-hackers@freebsd.org Message-ID: <20030416195328.V719@leelou.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-DCC-ZID-Univie-Metrics: mx1 4261; Body=1 Fuz1=1 Fuz2=1 Subject: growing filesystems in 5-current 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, 16 Apr 2003 18:04:26 -0000 Hi Hackers, since growfs currently is not able to grow filesystems on vinum volumes in 5-current, I started playing around with it and hacked to following patch. On first look it seems to work, but there is still a problem I can't explain. Consider a simple vinum volume with a concat plex, containing a 32 MB subdisk. I newfs this volume like that: ---8<--- # newfs -O2 /dev/vinum/mytest /dev/vinum/mytest: 32.0MB (65536 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 8.02MB, 513 blks, 1088 inodes. super-block backups (for fsck -b #) at: 160, 16576, 32992, 49408 ---8<--- So far, so good. Then I attach another 32 MB subdisk to the plex and try my hacked growfs on it and I get this: ---8<--- # growfs /dev/vinum/mytest We strongly recommend you to make a backup before growing the Filesystem Did you backup your data (Yes/No) ? Yes new file systemsize is: 32768 frags Warning: 16160 sector(s) cannot be allocated. growfs: 56.1MB (114912 sectors) block size 16384, fragment size 2048 using 7 cylinder groups of 8.02MB, 513 blks, 1088 inodes. super-block backups (for fsck -b #) at: 65824, 82240, 98656 ---8<--- Why do I loose so many sectors there? Can you help me find the bug? At first I suspected sblock.fs_fpg, since a debug printf after: ---8<--- if (sblock.fs_size % sblock.fs_fpg !=3D 0 && sblock.fs_size % sblock.fs_fpg < cgdmin(&sblock, sblock.fs_ncg)) { ---8<--- said that sblock.fs_fpg is 0 - a debug printf before that if statement told me a more likely number. Apart from that: am I going the wrong way with this patch? Is there a better way to fit growfs to the new vinum/geom stuff? Here's the patch: ---8<--- Index: growfs.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: /u/cvs/cvs/src/sbin/growfs/growfs.c,v retrieving revision 1.13 diff -u -r1.13 growfs.c --- growfs.c=0930 Dec 2002 21:18:05 -0000=091.13 +++ growfs.c=0916 Apr 2003 17:51:02 -0000 @@ -56,6 +56,7 @@ #include #include #include +#include #include #include @@ -111,6 +112,8 @@ static char=09=09inobuf[MAXBSIZE];=09/* inode block */ static int=09=09maxino;=09=09=09/* last valid inode */ +static int unlabeled; + /* * An array of elements of type struct gfs_bpp describes all blocks to * be relocated in order to free the space needed for the cylinder group @@ -148,6 +151,7 @@ static void=09updrefs(int, ino_t, struct gfs_bpp *, int, int, unsigned int= ); static void=09indirchk(ufs_lbn_t, ufs_lbn_t, ufs2_daddr_t, ufs_lbn_t, =09=09 struct gfs_bpp *, int, int, unsigned int); +static void get_dev_size(int, int *); /* ************************************************************ growfs ***= ** */ /* @@ -1884,6 +1888,21 @@ =09return columns; } +static void +get_dev_size(int fd, int *size) +{ +=09int sectorsize; +=09off_t mediasize; + +=09ioctl(fd, DIOCGSECTORSIZE, §orsize); +=09ioctl(fd, DIOCGMEDIASIZE, &mediasize); + +=09if (sectorsize <=3D 0) +=09=09errx(1, "bogus sectorsize: %d", sectorsize); + +=09*size =3D mediasize / sectorsize; +} + /* ************************************************************** main ***= ** */ /* * growfs(8) is a utility which allows to increase the size of an exist= ing @@ -1921,6 +1940,7 @@ =09struct disklabel=09*lp; =09struct partition=09*pp; =09int=09i,fsi,fso; +=09u_int32_t p_size; =09char=09reply[5]; #ifdef FSMAXSNAP =09int=09j; @@ -2020,25 +2040,30 @@ =09 */ =09cp=3Ddevice+strlen(device)-1; =09lp =3D get_disklabel(fsi); -=09if(lp->d_type =3D=3D DTYPE_VINUM) { -=09=09pp =3D &lp->d_partitions[0]; -=09} else if (isdigit(*cp)) { -=09=09pp =3D &lp->d_partitions[2]; -=09} else if (*cp>=3D'a' && *cp<=3D'h') { -=09=09pp =3D &lp->d_partitions[*cp - 'a']; +=09if (lp !=3D NULL) { +=09=09if (isdigit(*cp)) { +=09=09=09pp =3D &lp->d_partitions[2]; +=09=09} else if (*cp>=3D'a' && *cp<=3D'h') { +=09=09=09pp =3D &lp->d_partitions[*cp - 'a']; +=09=09} else { +=09=09=09errx(1, "unknown device"); +=09=09} +=09=09p_size =3D pp->p_size; =09} else { -=09=09errx(1, "unknown device"); +=09=09get_dev_size(fsi, &p_size); =09} =09/* =09 * Check if that partition looks suited for growing a file system. =09 */ -=09if (pp->p_size < 1) { +=09if (p_size < 1) { =09=09errx(1, "partition is unavailable"); =09} +/* =09if (pp->p_fstype !=3D FS_BSDFFS) { =09=09errx(1, "partition not 4.2BSD"); =09} +*/ =09/* =09 * Read the current superblock, and take a backup. @@ -2067,11 +2092,11 @@ =09 * Determine size to grow to. Default to the full size specified in =09 * the disk label. =09 */ -=09sblock.fs_size =3D dbtofsb(&osblock, pp->p_size); +=09sblock.fs_size =3D dbtofsb(&osblock, p_size); =09if (size !=3D 0) { -=09=09if (size > pp->p_size){ +=09=09if (size > p_size){ =09=09=09errx(1, "There is not enough space (%d < %d)", -=09=09=09 pp->p_size, size); +=09=09=09 p_size, size); =09=09} =09=09sblock.fs_size =3D dbtofsb(&osblock, size); =09} @@ -2121,7 +2146,7 @@ =09 * later on realize we have to abort our operation, on that block =09 * there should be no data, so we can't destroy something yet. =09 */ -=09wtfs((ufs2_daddr_t)pp->p_size-1, (size_t)DEV_BSIZE, (void *)&sblock, +=09wtfs((ufs2_daddr_t)p_size-1, (size_t)DEV_BSIZE, (void *)&sblock, =09 fso, Nflag); =09/* @@ -2182,12 +2207,14 @@ =09/* =09 * Update the disk label. =09 */ -=09pp->p_fsize =3D sblock.fs_fsize; -=09pp->p_frag =3D sblock.fs_frag; -=09pp->p_cpg =3D sblock.fs_fpg; - -=09return_disklabel(fso, lp, Nflag); -=09DBG_PRINT0("label rewritten\n"); +=09if (!unlabeled) { +=09=09pp->p_fsize =3D sblock.fs_fsize; +=09=09pp->p_frag =3D sblock.fs_frag; +=09=09pp->p_cpg =3D sblock.fs_fpg; + +=09=09return_disklabel(fso, lp, Nflag); +=09=09DBG_PRINT0("label rewritten\n"); +=09} =09close(fsi); =09if(fso>-1) close(fso); @@ -2254,12 +2281,13 @@ =09if (!lab) { =09=09errx(1, "malloc failed"); =09} -=09if (ioctl(fd, DIOCGDINFO, (char *)lab) < 0) { -=09=09errx(1, "DIOCGDINFO failed"); +=09if (!ioctl(fd, DIOCGDINFO, (char *)lab)) { +=09=09return (lab); =09} +=09unlabeled++; =09DBG_LEAVE; -=09return (lab); +=09return (NULL); } ---8<--- best regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 11:07:40 2003 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 A49D837B401 for ; Wed, 16 Apr 2003 11:07:40 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2AEB43FBF for ; Wed, 16 Apr 2003 11:07:38 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h3GI79cx098878 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Apr 2003 20:07:26 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h3GI74tn013893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2003 20:07:04 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.8) with ESMTP id h3GI73tA007333; Wed, 16 Apr 2003 20:07:04 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h3GI714p007332; Wed, 16 Apr 2003 20:07:01 +0200 (CEST) (envelope-from ticso) Date: Wed, 16 Apr 2003 20:07:00 +0200 From: Bernd Walter To: Jan Grant Message-ID: <20030416180659.GD6845@cicely9.cicely.de> References: <200304161349.h3GDnKxl008394@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 18:07:41 -0000 On Wed, Apr 16, 2003 at 03:34:38PM +0100, Jan Grant wrote: > You can't have multiple processes listen on the same address and port, > but you CAN have one listen on a specific IP and port and another listen > on INADDR_ANY and the same port. By extension, you'd expect a _more > specific_ binding of INADDR_ANY to override a more general one. You *can* have multiple processes listen on the same address and port. 1) SO_REUSEPORT 2) You can pass a listen filedescriptor between processes (fork, UDS). [74]cicely30> cat foo.c #include #include #include int main (int argc, char *argv[]) { int listenfd, connfd; struct sockaddr_in cliaddr, servaddr; socklen_t clilen; int val; listenfd = socket(AF_INET, SOCK_STREAM, 0); bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(7000); val = 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEPORT, &val, sizeof(val)); bind(listenfd, (struct sockaddr*)&servaddr, sizeof(servaddr)); listen(listenfd, 2); for (;;) { clilen = sizeof(cliaddr); connfd = accept(listenfd, (struct sockaddr*)&cliaddr, &clilen); /* do something */ close(connfd); } } [75]cicely30> gcc -o foo foo.c [76]cicely30> ./foo & [1] 35763 [77]cicely30> ./foo & [2] 35764 [78]cicely30> netstat -an | grep 7000 tcp4 0 0 *.7000 *.* LISTEN tcp4 0 0 *.7000 *.* LISTEN -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 15:34:53 2003 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 BA60E37B401; Wed, 16 Apr 2003 15:34:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id E46D343FDD; Wed, 16 Apr 2003 15:34:52 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (tether-14.isi.edu [128.9.235.14]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3GMYo105275; Wed, 16 Apr 2003 15:34:51 -0700 (PDT) Message-ID: <3E9DDA89.3030208@isi.edu> Date: Wed, 16 Apr 2003 15:34:49 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Lambert References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <3E9CFD8A.89353F06@mindspring.com> In-Reply-To: <3E9CFD8A.89353F06@mindspring.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020403090307060808070606" cc: "Jacques A. Vidrine" cc: freebsd-hackers@FreeBSD.org cc: "Crist J. Clark" Subject: Re: Single IP host and IPsec tunnel mode experience 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, 16 Apr 2003 22:34:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020403090307060808070606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 4/15/2003 11:51 PM, Terry Lambert wrote: > I keep meaning to fix this, but I'm always > hoping that the KAME people get to it first (on the other hand, > maybe they don't *want* it fixed, to encourage people to use > IPv6 instead ;^)). Considering that our merged SNAP is ancient, this may have been fixed already. (But I did not check their CVS tree.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms020403090307060808070606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQxNjIyMzQ0OVowIwYJKoZIhvcNAQkEMRYEFHCZOwfMOz/9Hp1Ufobp BgPYX1VdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAY8yo8a6kDut+jtjFQJfXCGh0JxaxgrrxwOEI ECXAGI9X2ppHUz0QA9KxW6c6Tx1Ylp50b6WCnDMEt7PL4n05/8pImHLhlu+52t6PFvVZWJQw f+1+52isFt695OU7ztbz8/CiY6rGplCgtrDkSblSW/0/mrTxp37605MxKaY8vY+AqWj05kt3 ySdCmbDcX6fZl+heCGXdZSBVrevk7Xa9cX+YlT9hGVwalwCDWJJHleJbb1xSRhCLcOR6VeQv rNP5KxSDPYWLWzaOfeND3427zcr5kE8CaoidMwWaJviB8A0i35A2FlqwP51cnvt3vmMc9x4G idky4zfC+42l1nt/LgAAAAAAAA== --------------ms020403090307060808070606-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 20:22:36 2003 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 E198937B401 for ; Wed, 16 Apr 2003 20:22:36 -0700 (PDT) Received: from ns3.unixmexico.net (ns3.unixmexico.net [69.10.137.124]) by mx1.FreeBSD.org (Postfix) with SMTP id 21D2D43FA3 for ; Wed, 16 Apr 2003 20:22:36 -0700 (PDT) (envelope-from nbari@unixmexico.com) Received: (qmail 8733 invoked by uid 85); 17 Apr 2003 03:22:40 -0000 Received: from nbari@unixmexico.com by ns3.unixmexico.net by uid 82 with qmail-scanner-1.15 (hbedv: 6.18.0.3/6.18.0.19. Clear:. Processed in 0.3141 secs); 17 Apr 2003 03:22:40 -0000 Received: from unknown (HELO mail.unixmexico.com) (69.10.137.124) by ns3.unixmexico.net with SMTP; 17 Apr 2003 03:22:39 -0000 Received: from 148.243.211.1 (SquirrelMail authenticated user nbari@unixmexico.com) by mail.unixmexico.com with HTTP; Wed, 16 Apr 2003 22:22:39 -0500 (CDT) Message-ID: <22400.148.243.211.1.1050549759.squirrel@mail.unixmexico.com> In-Reply-To: <20030416130030.GB529@cicely9.cicely.de> References: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> <20030416130030.GB529@cicely9.cicely.de> Date: Wed, 16 Apr 2003 22:22:39 -0500 (CDT) From: nbari@unixmexico.com To: ticso@cicely.de User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal cc: nbari@unixmexico.com cc: freebsd-hackers@freebsd.org Subject: Re: HP psc 750 on FreeBSD 4.8 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, 17 Apr 2003 03:22:37 -0000 Ok, after installing usbutil.tgz. and using usbctl i get this: ------ USB device 1: 9 USB device 2: 0 USB device 3: 255 3 USB devices found DEVICE addr 1 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.00 bDeviceClass=9 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x0000 idProduct=0x0000 bcdDevice=100 iManufacturer=1(Intel) iProduct=2(UHCI root hub) iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=40 bMaxPower=0 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=1 bInterfaceClass=9 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=8 bInterval=255 current configuration 1 HUB descriptor: bDescLength=8 bDescriptorType=41 bNbrPorts=2 wHubCharacteristics=0a bPwrOn2PwrGood=50 bHubContrCurrent=0 DeviceRemovable=0 Hub status 0000 0000 Port 1 status=0103 change=0000 Port 2 status=0303 change=0000 ---------- DEVICE addr 2 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x03f0 idProduct=0x1411 bcdDevice=100 iManufacturer=1(Hewlett-Packard) iProduct=2(PSC 750) iSerialNumber=3(MY2B7D32Y4WB) bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=78 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=c0 bMaxPower=2 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=3 bInterfaceClass=7 bInterfaceSubClass=1 bInterfaceProtocol=3 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-in bmAttributes=interrupt wMaxPacketSize=8 bInterval=10 INTERFACE descriptor 1: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=1 bNumEndpoints=2 bInterfaceClass=7 bInterfaceSubClass=1 bInterfaceProtocol=2 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=bulk wMaxPacketSize=64 bInterval=0 INTERFACE descriptor 2: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=2 bNumEndpoints=1 bInterfaceClass=7 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 current configuration 1 ---------- DEVICE addr 3 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.00 bDeviceClass=255 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x04d2 idProduct=0xff05 bcdDevice=0 iManufacturer=1() iProduct=2() iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=40 bMaxPower=0 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=1 bInterfaceClass=1 bInterfaceSubClass=1 bInterfaceProtocol=0 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=2 bInterval=32 current configuration 1 ---------- > On Wed, Apr 16, 2003 at 03:36:03AM -0500, nbari@unixmexico.com wrote: >> Hi all, i have an HP psc 750 USB printer >> >> Any idea on how configure this printer to make it work on FreeBSD ? >> >> i have this lines on my kernel: >> >> device usb >> device uhci >> device ulpt >> device uscanner >> device ugen >> >> >> dmesg give me this: >> >> ugen0: Hewlett-Packard PSC 750, rev 1.10/1.00, addr 2 > > Can you please install http://www.cosmo-project.de/~bernd/usbutil.tgz > and mail the usbctl output. > >> usbdevs -v give me this: >> Controller /dev/usb0: >> addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), >> rev >> 1.00 >> port 1 addr 2: power 2 mA, config 1, PSC 750(0x1411), >> Hewlett-Packard(0x03f0), rev 1.00 >> port 2 addr 3: low speed, self powered, config 1, ASC495 >> Speakers(0xff05), ALTEC LANSING Multimedia (0x04d2), rev 0.00 >> >> >> when trying to run an lptest > /dev/ulpt0 i get an : /dev/ulpt0: Device >> not configured. >> >> and when runing lptest > /dev/ugen0 nothing happens. > > ugen is a generic driver for raw device access. > > -- > B.Walter BWCT http://www.bwct.de > ticso@bwct.de info@bwct.de > > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 23:02:56 2003 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 05ABE37B401; Wed, 16 Apr 2003 23:02:56 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1049343FA3; Wed, 16 Apr 2003 23:02:54 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 4C6003ABB47; Thu, 17 Apr 2003 08:03:44 +0200 (CEST) Date: Thu, 17 Apr 2003 08:03:44 +0200 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20030417060344.GA93872@garage.freebsd.pl> References: <20030415171757.GU52293@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20030415171757.GU52293@garage.freebsd.pl> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: Martin Blapp cc: Robert Watson cc: Poul-Henning Kamp Subject: Re: Multiple ip-numbers in jails (fixed INADDR_ANY behaviour). 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, 17 Apr 2003 06:02:56 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2003 at 07:17:57PM +0200, Pawel Jakub Dawidek wrote: +> I've just finished patch for multiple ip-numbers inside jails. [...] Updated version of patch avaliable here: http://garage.freebsd.pl/mijail5.patch (sometimes better by sure that inp_socket and td isn't NULL) --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBPp5DwD/PhmMH/Mf1AQHqtQQAl7TW63D5JoxMPVPFehfeuxSA0W3qXq6h xPU8U2smbIU8Kvp6aAdnc8tciMWJMKX6mZAzNyAekh4yu9bavtaP8svxwozYS8hk k9Tx64lkV2Aj1ufKpWsdtjxa8vNwTVQKjOXeTyW+KF4jme7IVfh7LqYcaKrFt1SU YpMaI44RtEs= =UUm7 -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 00:40:15 2003 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 34B3637B401 for ; Thu, 17 Apr 2003 00:40:15 -0700 (PDT) Received: from Danovitsch.dnsq.org (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52CCA43FA3 for ; Thu, 17 Apr 2003 00:40:13 -0700 (PDT) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Danovitsch.dnsq.org (8.12.3p2/8.11.3) with ESMTP id h3H7ZGCR045912 for ; Thu, 17 Apr 2003 09:35:17 +0200 (CEST) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="iso-8859-1" From: "Daan Vreeken [PA4DAN]" Date: Thu, 17 Apr 2003 09:41:53 +0200 User-Agent: KMail/1.4.3 To: FreeBSD-hackers@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200304170941.53069.Danovitsch@Vitsch.net> Subject: kern/51074: pointer arithmatic error in ugen.c 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, 17 Apr 2003 07:40:15 -0000 Hi, I have just submitted ker/51074: pointer arithmatic error in ugen.c ( http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3Dkern%2F51074 ) with this description : I believe there is a pointer arithmatic error in line 965 of ugen.c . The entire piece of code reads : 961: /* throw away oldest input if the buffer is full */ 962: if(sce->fill < sce->cur && sce->cur <=3D sce->fill + count) { 963: sce->cur +=3D count; 964: if(sce->cur >=3D sce->limit) 965: sce->cur =3D sce->ibuf + (sce->limit - sce->cur); 966: DPRINTFN(5, ("ugen_isoc_rintr: throwing away %d bytes\n", 967: count)); 978: } count gets added to sce->cur . if the pointer equals/exceeds the end of the buffer, we move it to the beginnen of the buffer (plus the X bytes it was past the end). If sce->cur exceeds sce->limit, (sce->cur - sce->limit) would be a negati= ve value. (resulting in a sce->cur pointer sitting X bytes before the beginn= ing of the buffer) -- end -- Could someone please check if I'm correct and apply the patch? ps: thanks to some mailing-weirdness the pr is marked confidential, which= it=20 shouldn't have been.. :S thanks, Daan From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 03:45:00 2003 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 A681C37B401 for ; Thu, 17 Apr 2003 03:45:00 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72B9643F75 for ; Thu, 17 Apr 2003 03:44:59 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h3HAipcx011634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 12:44:55 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h3HAintn018968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2003 12:44:49 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.8) with ESMTP id h3HAimtA009634; Thu, 17 Apr 2003 12:44:48 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h3HAilbA009633; Thu, 17 Apr 2003 12:44:47 +0200 (CEST) (envelope-from ticso) Date: Thu, 17 Apr 2003 12:44:46 +0200 From: Bernd Walter To: nbari@unixmexico.com Message-ID: <20030417104445.GL6845@cicely9.cicely.de> References: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> <20030416130030.GB529@cicely9.cicely.de> <22400.148.243.211.1.1050549759.squirrel@mail.unixmexico.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22400.148.243.211.1.1050549759.squirrel@mail.unixmexico.com> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: HP psc 750 on FreeBSD 4.8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 10:45:00 -0000 On Wed, Apr 16, 2003 at 10:22:39PM -0500, nbari@unixmexico.com wrote: > Ok, after installing usbutil.tgz. and using usbctl i get this: The printer just have three alternate settings for ulpt. Are you absolutely shure that ulpt was in the kernel you tested with? -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 05:08:22 2003 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 D0E0037B401 for ; Thu, 17 Apr 2003 05:08:22 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E3B43FA3 for ; Thu, 17 Apr 2003 05:08:21 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h3HC88cx012329 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 14:08:18 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h3HC84tn019312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2003 14:08:05 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.8) with ESMTP id h3HC84tA009815; Thu, 17 Apr 2003 14:08:04 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h3HC83Ed009814; Thu, 17 Apr 2003 14:08:03 +0200 (CEST) (envelope-from ticso) Date: Thu, 17 Apr 2003 14:08:02 +0200 From: Bernd Walter To: ???? ????? Message-ID: <20030417120802.GN6845@cicely9.cicely.de> References: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> <20030416130030.GB529@cicely9.cicely.de> <22400.148.243.211.1.1050549759.squirrel@mail.unixmexico.com> <20030417104445.GL6845@cicely9.cicely.de> <5319896796.20030417153935@rgrta.ryazan.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5319896796.20030417153935@rgrta.ryazan.ru> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org cc: Bernd Walter Subject: Re: Re[2]: HP psc 750 on FreeBSD 4.8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 12:08:23 -0000 On Thu, Apr 17, 2003 at 03:39:35PM +0400, ???? ????? wrote: > Hello Bernd, > Thursday, April 17, 2003, 2:44:46 PM, you wrote: > > >> Ok, after installing usbutil.tgz. and using usbctl i get this: > BW> The printer just have three alternate settings for ulpt. > BW> Are you absolutely shure that ulpt was in the kernel you tested with? > > For FreeBSD 4.7 ulpt uses only first interface configuration. > Initialization tests only first interface configuration for proper endpoint. > For my USB-connected HP LaserJet 1200 I made following modifications in > ULPT.C. Recompile kernel. Acording to usbctl output the PSC750 has only one interface. I doubt that this is different for an LJ1200. Also I don't see why you would need this change, ulpt gets asked for every interface and if the interface is not a printer class, then ulpt has no reason to think about being the right driver. See usbd_probe_and_attach() in usb_subr.c. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 06:42:39 2003 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 DE48E37B401 for ; Thu, 17 Apr 2003 06:42:39 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9F6643FA3 for ; Thu, 17 Apr 2003 06:42:38 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h3HDgbr09655 for hackers@freebsd.org; Thu, 17 Apr 2003 15:42:37 +0200 Date: Thu, 17 Apr 2003 15:42:37 +0200 From: Christoph Kukulies Message-Id: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: Undefined symbol "__stderrp 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, 17 Apr 2003 13:42:40 -0000 With one box I run isdn (i4b) on I had problems under 5.0 and I reverted back to 4.8 today after two days having been cut off the net with that box. I will stay at 4.8 until the isdn issues will have solved and I will probably revert the other 5.0 box to 4.8 because of those netgraph malloc leaks or bad malloc issues. I will try a last cvsup tonight to see if it has become better. Anyway, due to the hot switching between 5.0 and 4.8 I might have some undesired mix of libs and/or binaries. (I had SCSI disks booted under 4.8 and copied over the binaries and libs to the IDE disks over- writing the 5.0 binaries - yes, I also did a chflags noschg through the trees first. I have a bootable 4.8 ISDN kernel now again as I'm typing this. But I still can't start X because of lots of this kind of errors: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" What is wrong with this? -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 06:52:35 2003 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 53AF437B401 for ; Thu, 17 Apr 2003 06:52:35 -0700 (PDT) Received: from freebsd.org.ru (www.freebsd.org.ru [194.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F7CA43FBF for ; Thu, 17 Apr 2003 06:52:34 -0700 (PDT) (envelope-from osa@freebsd.org.ru) Received: by freebsd.org.ru (Postfix, from userid 1000) id 2BBF14F; Thu, 17 Apr 2003 17:52:32 +0400 (MSD) Date: Thu, 17 Apr 2003 17:52:32 +0400 From: "Sergey A. Osokin" To: Christoph Kukulies Message-ID: <20030417135232.GB82446@freebsd.org.ru> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: Undefined symbol "__stderrp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: osa@FreeBSD.org.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 13:52:35 -0000 On Thu, Apr 17, 2003 at 03:42:37PM +0200, Christoph Kukulies wrote: > I have a bootable 4.8 ISDN kernel now again as I'm typing this. > But I still can't start X because of lots of this kind of errors: > > > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" > What is wrong with this? Very short answer: Google is your friend :-) Try to add COMPAT4X=TRUE to your /etc/make.conf, then cd /usr/src/lib/compat make obj make make install Notify if something wrong. -- Rgdz, /"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 08:00:37 2003 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 94AEC37B404 for ; Thu, 17 Apr 2003 08:00:37 -0700 (PDT) Received: from ns3.unixmexico.net (ns3.unixmexico.net [69.10.137.124]) by mx1.FreeBSD.org (Postfix) with SMTP id C428843FBF for ; Thu, 17 Apr 2003 08:00:36 -0700 (PDT) (envelope-from nbari@unixmexico.com) Received: (qmail 13092 invoked by uid 85); 17 Apr 2003 15:00:44 -0000 Received: from nbari@unixmexico.com by ns3.unixmexico.net by uid 82 with qmail-scanner-1.15 (hbedv: 6.18.0.3/6.18.0.19. Clear:. Processed in 0.308791 secs); 17 Apr 2003 15:00:44 -0000 Received: from unknown (HELO mail.unixmexico.com) (69.10.137.124) by ns3.unixmexico.net with SMTP; 17 Apr 2003 15:00:43 -0000 Received: from 148.243.211.240 (SquirrelMail authenticated user nbari@unixmexico.com) by mail.unixmexico.com with HTTP; Thu, 17 Apr 2003 10:00:44 -0500 (CDT) Message-ID: <1304.148.243.211.240.1050591644.squirrel@mail.unixmexico.com> In-Reply-To: <20030417104445.GL6845@cicely9.cicely.de> References: <1334.148.243.211.57.1050482163.squirrel@mail.unixmexico.com> <20030416130030.GB529@cicely9.cicely.de> <22400.148.243.211.1.1050549759.squirrel@mail.unixmexico.com> <20030417104445.GL6845@cicely9.cicely.de> Date: Thu, 17 Apr 2003 10:00:44 -0500 (CDT) From: nbari@unixmexico.com To: ticso@cicely.de User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal cc: nbari@unixmexico.com cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: HP psc 750 on FreeBSD 4.8 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, 17 Apr 2003 15:00:37 -0000 Yes, i have this line on my kernel device ulpt and have compiled my kernel with that option. > On Wed, Apr 16, 2003 at 10:22:39PM -0500, nbari@unixmexico.com wrote: >> Ok, after installing usbutil.tgz. and using usbctl i get this: > > The printer just have three alternate settings for ulpt. > Are you absolutely shure that ulpt was in the kernel you tested with? > > -- > B.Walter BWCT http://www.bwct.de > ticso@bwct.de info@bwct.de > > From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 08:24:21 2003 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 4B76437B404 for ; Thu, 17 Apr 2003 08:24:21 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A6E443FDD for ; Thu, 17 Apr 2003 08:24:20 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h3HFOG311026; Thu, 17 Apr 2003 17:24:16 +0200 Date: Thu, 17 Apr 2003 17:24:16 +0200 From: "Christoph P. Kukulies" To: "Sergey A. Osokin" Message-ID: <20030417152415.GA10943@gilberto.physik.rwth-aachen.de> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> <20030417135232.GB82446@freebsd.org.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417135232.GB82446@freebsd.org.ru> User-Agent: Mutt/1.4i cc: hackers@freebsd.org cc: Christoph Kukulies Subject: Re: Undefined symbol "__stderrp 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, 17 Apr 2003 15:24:21 -0000 On Thu, Apr 17, 2003 at 05:52:32PM +0400, Sergey A. Osokin wrote: > On Thu, Apr 17, 2003 at 03:42:37PM +0200, Christoph Kukulies wrote: > > I have a bootable 4.8 ISDN kernel now again as I'm typing this. > > But I still can't start X because of lots of this kind of errors: > > > > > > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" > > What is wrong with this? > > Very short answer: Google is your friend :-) > > Try to add COMPAT4X=TRUE to your /etc/make.conf, then > cd /usr/src/lib/compat > make obj > make > make install This doesn't cure the problem. Only libcrypto.so.1 libcrypto.so.2 libfetch.so.1 libfetch.so.2 libssl.so.1 libssl.so.2 are built and copied to /usr/lib/compat. Do I have to reboot or do some ldconfig thing? > Notify if something wrong. -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 08:31:00 2003 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 0FB5437B401 for ; Thu, 17 Apr 2003 08:31:00 -0700 (PDT) Received: from freebsd.org.ru (freebsd.org.ru [194.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4A343FE0 for ; Thu, 17 Apr 2003 08:30:59 -0700 (PDT) (envelope-from osa@freebsd.org.ru) Received: by freebsd.org.ru (Postfix, from userid 1000) id 696CF93; Thu, 17 Apr 2003 19:30:57 +0400 (MSD) Date: Thu, 17 Apr 2003 19:30:57 +0400 From: "Sergey A. Osokin" To: "Christoph P. Kukulies" Message-ID: <20030417153057.GF82446@freebsd.org.ru> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> <20030417135232.GB82446@freebsd.org.ru> <20030417150522.GA10674@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417150522.GA10674@gilberto.physik.rwth-aachen.de> User-Agent: Mutt/1.5.4i cc: hackers@FreeBSD.org Subject: Re: Undefined symbol "__stderrp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: osa@FreeBSD.org.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 15:31:00 -0000 On Thu, Apr 17, 2003 at 05:05:22PM +0200, Christoph P. Kukulies wrote: > On Thu, Apr 17, 2003 at 05:52:32PM +0400, Sergey A. Osokin wrote: > > On Thu, Apr 17, 2003 at 03:42:37PM +0200, Christoph Kukulies wrote: > > > I have a bootable 4.8 ISDN kernel now again as I'm typing this. > > > But I still can't start X because of lots of this kind of errors: > > > > > > > > > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" > > > What is wrong with this? > > > > Very short answer: Google is your friend :-) > > > > Try to add COMPAT4X=TRUE to your /etc/make.conf, then > > Is it normal that 4.8 doesn't have a /etc/make.conf? Absolutely truth. -- Rgdz, /"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 08:38:59 2003 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 3B13C37B401 for ; Thu, 17 Apr 2003 08:38:59 -0700 (PDT) Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EBF643FDF for ; Thu, 17 Apr 2003 08:38:58 -0700 (PDT) (envelope-from osa@freebsd.org.ru) Received: by freebsd.org.ru (Postfix, from userid 1000) id 60A1DBD; Thu, 17 Apr 2003 19:38:57 +0400 (MSD) Date: Thu, 17 Apr 2003 19:38:57 +0400 From: "Sergey A. Osokin" To: "Christoph P. Kukulies" Message-ID: <20030417153857.GG82446@freebsd.org.ru> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> <20030417135232.GB82446@freebsd.org.ru> <20030417152415.GA10943@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417152415.GA10943@gilberto.physik.rwth-aachen.de> User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: Undefined symbol "__stderrp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: osa@FreeBSD.org.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 15:38:59 -0000 On Thu, Apr 17, 2003 at 05:24:16PM +0200, Christoph P. Kukulies wrote: > On Thu, Apr 17, 2003 at 05:52:32PM +0400, Sergey A. Osokin wrote: > > On Thu, Apr 17, 2003 at 03:42:37PM +0200, Christoph Kukulies wrote: > > > I have a bootable 4.8 ISDN kernel now again as I'm typing this. > > > But I still can't start X because of lots of this kind of errors: > > > > > > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" > > > What is wrong with this? > > > > Very short answer: Google is your friend :-) > > > > Try to add COMPAT4X=TRUE to your /etc/make.conf, then > > cd /usr/src/lib/compat > > make obj > > make > > make install > > This doesn't cure the problem. Only > libcrypto.so.1 > libcrypto.so.2 > libfetch.so.1 > libfetch.so.2 > libssl.so.1 > libssl.so.2 > > are built and copied to /usr/lib/compat. > Do I have to reboot or do some ldconfig thing? OK. Tell me more about your configuration... $ ls -al /usr/lib/libc.so $ strings /usr/lib/libc.so | grep __stderr -- Rgdz, /"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 08:50:55 2003 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 AF99D37B401; Thu, 17 Apr 2003 08:50:55 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A03843F93; Thu, 17 Apr 2003 08:50:54 -0700 (PDT) (envelope-from bmah@employees.org) Received: from bmah.dyndns.org (12-240-204-110.client.attbi.com[12.240.204.110]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003041715505300200h8h13e>; Thu, 17 Apr 2003 15:50:53 +0000 Received: from intruder.bmah.org (localhost [127.0.0.1]) by bmah.dyndns.org (8.12.9/8.12.9) with ESMTP id h3HFoqxV097075; Thu, 17 Apr 2003 08:50:53 -0700 (PDT) (envelope-from bmah@intruder.bmah.org) Message-Id: <200304171550.h3HFoqxV097075@bmah.dyndns.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Toerless Eckert In-Reply-To: <200304142136.XAA28381@faui40p.informatik.uni-erlangen.de> References: <200304142136.XAA28381@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Mon, 14 Apr 2003 23:36:59 +0200." From: "Bruce A. Mah" X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1387794734P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 08:50:52 -0700 Sender: bmah@employees.org cc: freebsd-hackers@freebsd.org Subject: Re: boot2 broken ? (booting from pst fails) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bmah@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 15:50:56 -0000 --==_Exmh_-1387794734P Content-Type: text/plain; charset=us-ascii If memory serves me right, Toerless Eckert wrote: > > Also, apart > > from your hardware, FreeBSD is quite compatible with the large majority of > > PC hardware. We boot directly off of 3ware ATA RAID controllers where I > > work, so I really think your claims are rather overstated. > > Don't forget that neither 3ware nor promise list FreeBSD as a supported > operating system, both are equally listed in FreeBSDs hardware list, > there's no indication that booting for one of them doesn't work but > that it's supposed to work on the other. Well, if it's as simple as adding a note to the hardware list that booting from pst(4) devices isn't supported, I'm happy to do that. Bear in mind that the poor sucker who does most of the hardware list (yours truly) has fairly pedestrian hardware. I'm always glad to get some help in this department. Bruce. --==_Exmh_-1387794734P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) Comment: Exmh version 2.5+ 20020506 iD8DBQE+ns1b2MoxcVugUsMRAqkZAKDZT32Z/vcT2XHzCoZ944jj7ehNKQCg4EfY Tonjak+kVWu29TbWK6182fo= =KvxN -----END PGP SIGNATURE----- --==_Exmh_-1387794734P-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 09:02:17 2003 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 3C63537B401 for ; Thu, 17 Apr 2003 09:02:17 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A8E743FAF for ; Thu, 17 Apr 2003 09:02:16 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h3HG2Cr11580; Thu, 17 Apr 2003 18:02:12 +0200 Date: Thu, 17 Apr 2003 18:02:12 +0200 From: "Christoph P. Kukulies" To: "Sergey A. Osokin" Message-ID: <20030417160212.GA11364@gilberto.physik.rwth-aachen.de> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> <20030417135232.GB82446@freebsd.org.ru> <20030417152415.GA10943@gilberto.physik.rwth-aachen.de> <20030417153857.GG82446@freebsd.org.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417153857.GG82446@freebsd.org.ru> User-Agent: Mutt/1.4i cc: hackers@freebsd.org cc: "Christoph P. Kukulies" Subject: Re: Undefined symbol "__stderrp 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, 17 Apr 2003 16:02:17 -0000 On Thu, Apr 17, 2003 at 07:38:57PM +0400, Sergey A. Osokin wrote: > On Thu, Apr 17, 2003 at 05:24:16PM +0200, Christoph P. Kukulies wrote: > > On Thu, Apr 17, 2003 at 05:52:32PM +0400, Sergey A. Osokin wrote: > > > On Thu, Apr 17, 2003 at 03:42:37PM +0200, Christoph Kukulies wrote: > > > > I have a bootable 4.8 ISDN kernel now again as I'm typing this. > > > > But I still can't start X because of lots of this kind of errors: > > > > > > > > /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libSM.so.6: Undefined symbol "__stderrp" > > > > What is wrong with this? > > > > > > Very short answer: Google is your friend :-) > > > > > > Try to add COMPAT4X=TRUE to your /etc/make.conf, then > > > cd /usr/src/lib/compat > > > make obj > > > make > > > make install > > > > This doesn't cure the problem. Only > > libcrypto.so.1 > > libcrypto.so.2 > > libfetch.so.1 > > libfetch.so.2 > > libssl.so.1 > > libssl.so.2 > > > > are built and copied to /usr/lib/compat. > > Do I have to reboot or do some ldconfig thing? > > OK. Tell me more about your configuration... > $ ls -al /usr/lib/libc.so lrwxrwxrwx 1 root wheel 9 Apr 17 13:01 /usr/lib/libc.so -> libc.so.4 > $ strings /usr/lib/libc.so | grep __stderr # strings /usr/lib/libc.so | grep __stderr __stderrp -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 09:42:18 2003 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 04F9C37B401; Thu, 17 Apr 2003 09:42:18 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 440D543FBD; Thu, 17 Apr 2003 09:42:16 -0700 (PDT) (envelope-from bmah@employees.org) Received: from bmah.dyndns.org (12-240-204-110.client.attbi.com[12.240.204.110]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003041716421500200h98fje>; Thu, 17 Apr 2003 16:42:15 +0000 Received: from intruder.bmah.org (localhost [127.0.0.1]) by bmah.dyndns.org (8.12.9/8.12.9) with ESMTP id h3HGgExV098213; Thu, 17 Apr 2003 09:42:14 -0700 (PDT) (envelope-from bmah@intruder.bmah.org) Message-Id: <200304171642.h3HGgExV098213@bmah.dyndns.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: taxman In-Reply-To: <200304171228.38808.taxman@acd.net> References: <200304142136.XAA28381@faui40p.informatik.uni-erlangen.de> <200304171550.h3HFoqxV097075@bmah.dyndns.org> <200304171228.38808.taxman@acd.net> Comments: In-reply-to taxman message dated "Thu, 17 Apr 2003 12:28:38 -0400." From: bmah@freebsd.org (Bruce A. Mah) X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-513223036P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 09:42:14 -0700 Sender: bmah@employees.org cc: freebsd-hackers@freebsd.org Subject: Re: boot2 broken ? (booting from pst fails) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bmah@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 16:42:18 -0000 --==_Exmh_-513223036P Content-Type: text/plain; charset=us-ascii [Back to hackers@ with permission...] If memory serves me right, taxman wrote: > sorry for the direct reply, but -hackers didn't seem appropriate for my > question. So what is the best way to have the most accurate hardware lists? > > Should people email -hardware every time they have something working that is > not mentioned, or something that does not work or an approximate status of a > piece of hardware if it is semi-supported? Or should they email you?,etc > feel free to cc the answer back to hackers or harware if thats appropriate. >From my perspective, the best thing I can think of is that if you have something you know that works (but is not mentioned), file a doc PR with a patch. If you don't speak DocBook, that's OK, file a PR with some English text and someone will mark it up for you. I'll probably be the one to do it, but if I'm lucky some other doc committer will take pity on me and help out. Note that in some cases, the hardware notes could be updated using information from the manual pages from a driver. Knowing that something *doesn't* work is more useful to whoever maintains a particular driver. There's some areas where there are a gazillion supported devices (I'm thinking of USB hubs as an example) where we can probably shorten the list by saying "in general, all devices of type FOO are supported". Thanks, Bruce. PS. Someone else pointed out that my "pedestrian hardware" comment was a bit ambiguous. I would appreciate help documenting less-mundane hardware. I'm not asking for donations of hardware. :-) --==_Exmh_-513223036P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) Comment: Exmh version 2.5+ 20020506 iD8DBQE+ntlm2MoxcVugUsMRArPWAJ9Jhq/D4NOJQ3mipjwFqwL5ocDt/QCdG/3y 7zHg7IrzCjoB1gAqdk4E0Wo= =r0gE -----END PGP SIGNATURE----- --==_Exmh_-513223036P-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 09:54:21 2003 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 3F12837B401 for ; Thu, 17 Apr 2003 09:54:21 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 040A843F75 for ; Thu, 17 Apr 2003 09:54:18 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h3HGs9B12293; Thu, 17 Apr 2003 18:54:09 +0200 Date: Thu, 17 Apr 2003 18:54:09 +0200 From: "Christoph P. Kukulies" To: "Sergey A. Osokin" Message-ID: <20030417165409.GA12276@gilberto.physik.rwth-aachen.de> References: <200304171342.h3HDgbr09655@accms33.physik.rwth-aachen.de> <20030417135232.GB82446@freebsd.org.ru> <20030417152415.GA10943@gilberto.physik.rwth-aachen.de> <20030417153857.GG82446@freebsd.org.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417153857.GG82446@freebsd.org.ru> User-Agent: Mutt/1.4i cc: hackers@freebsd.org cc: "Christoph P. Kukulies" Subject: Re: Undefined symbol "__stderrp 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, 17 Apr 2003 16:54:21 -0000 On Thu, Apr 17, 2003 at 07:38:57PM +0400, Sergey A. Osokin wrote: > On Thu, Apr 17, 2003 at 05:24:16PM +0200, Christoph P. Kukulies wrote: > > > make obj > > > make > > > make install > > > > This doesn't cure the problem. Only > > libcrypto.so.1 > > libcrypto.so.2 > > libfetch.so.1 > > libfetch.so.2 > > libssl.so.1 > > libssl.so.2 > > > > are built and copied to /usr/lib/compat. > > Do I have to reboot or do some ldconfig thing? > > OK. Tell me more about your configuration... > $ ls -al /usr/lib/libc.so > $ strings /usr/lib/libc.so | grep __stderr > I solved it now by installing all compat[1-4]x dists from the CD. Thanks. -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 13:51:08 2003 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 D7D1137B401 for ; Thu, 17 Apr 2003 13:51:08 -0700 (PDT) Received: from stargate.northwindcom.net (110-47-237-24.gci.net [24.237.47.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id D954143FBF for ; Thu, 17 Apr 2003 13:51:07 -0700 (PDT) (envelope-from akbeech@northwindcom.net) Received: from admin (admin.northwindcom.net [192.168.10.2]) by stargate.northwindcom.net (Postfix) with ESMTP id 087EF338B for ; Thu, 17 Apr 2003 12:51:07 -0800 (AKDT) From: "Beech Rintoul" To: Date: Thu, 17 Apr 2003 12:51:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: Shared Source CLI 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, 17 Apr 2003 20:51:09 -0000 Hi, I got a request from one of our microsoft programmers to install sscli on one of our FreeBSD boxes. I had no luck compiling it. Has anyone gotten it to compile successfully on -CURRENT? Beech ------------------------------------------------------------------- Beech Rintoul - Network Administrator - akbeech@sinbad.net /"\ ASCII Ribbon Campaign | Sinbad Network Communications Inc. \ / - NO HTML/RTF in e-mail | 3101 Penland Pkwy. Ste. K-38 X - NO Word docs in e-mail | Anchorage, AK 99508 No More Spam! http://www.knockmail.com/default.asp?AID=B0R00073 / \ ----------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 14:19:32 2003 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 E553537B401 for ; Thu, 17 Apr 2003 14:19:32 -0700 (PDT) Received: from freebsd.org.ru (www.freebsd.org.ru [194.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5621D43F75 for ; Thu, 17 Apr 2003 14:19:32 -0700 (PDT) (envelope-from osa@freebsd.org.ru) Received: by freebsd.org.ru (Postfix, from userid 1000) id 75B98BD; Fri, 18 Apr 2003 01:19:31 +0400 (MSD) Date: Fri, 18 Apr 2003 01:19:31 +0400 From: "Sergey A. Osokin" To: Beech Rintoul Message-ID: <20030417211931.GN82446@freebsd.org.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Shared Source CLI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: osa@FreeBSD.org.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 21:19:33 -0000 On Thu, Apr 17, 2003 at 12:51:00PM -0800, Beech Rintoul wrote: > > I got a request from one of our microsoft programmers to install sscli on > one of our FreeBSD boxes. I had no luck compiling it. Has anyone gotten it > to compile successfully on -CURRENT? If you have a problem with lang/cli - please describe you problem and send a PR via send-pr(1) interface. Also notify maintainer about your problem. Thanks. -- Rgdz, /"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 15:17:00 2003 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 3475F37B401 for ; Thu, 17 Apr 2003 15:17:00 -0700 (PDT) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8061E43FD7 for ; Thu, 17 Apr 2003 15:16:56 -0700 (PDT) (envelope-from kutulu@kutulu.org) Received: by basement.kutulu.org (Postfix, from userid 1001) id EC1D6A933; Thu, 17 Apr 2003 18:17:03 -0400 (EDT) Date: Thu, 17 Apr 2003 18:17:03 -0400 From: Michael Edenfield To: Beech Rintoul Message-ID: <20030417221703.GA45948@basement.kutulu.org> Mail-Followup-To: Beech Rintoul , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F cc: freebsd-hackers@freebsd.org Subject: Re: Shared Source CLI 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, 17 Apr 2003 22:17:00 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Beech Rintoul [030417 16:52]: > I got a request from one of our microsoft programmers to install sscli on > one of our FreeBSD boxes. I had no luck compiling it. Has anyone gotten it > to compile successfully on -CURRENT? At one point, I did get the lang/cli port to build with no problem. =20 It's a bit outdated (2002-06-19 vs. 2002-11-02) but it worked. =20 Unfortunately, I'm now getting a syntax error in the configure: =2E/configure: line 1041: syntax error near unexpected token `fi' =2E/configure: line 1041: `fi' that I think is unrelated to the sscli port and possibly related to a=20 broken shell. As far as doing a build of the latest snapshot, it certainly doesn't=20 work out of the box. The first problem I ran into was with their PAL=20 reimplementation of localtime, ctime, and mktime. After going through=20 the macro-hackery in the headers that's used to redefine the C runtime=20 functions, you end up with conflicting definitions for these=20 functions, eg, you get: struct * DUMMY_tm __attribute((cdecl)) PAL_localtime(const time_t *) and struct * PAL_tm __attribute((cdecl)) PAL_localtime(const time_t *) in misc.c, and gcc stops there. It looks like they're missing a macro=20 replacement of tm -> PAL_tm in a header, but I've not spent time=20 tracking it down. My next goal, during my free time tommorrow, is to=20 check the patchs in the lang/cli port that I assume deal with similar=20 issues. (FYI: I did try just dropping the new tarball overtop the one the port=20 expects but most of the patches didn't apply.) --Mike =20 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+nyffCczNhKRsh48RAg+VAJ9QvyOnxdQ4/LY+sHASw8LvdF/6vACdH5G8 HDCKWtSWq99a/y8QeaRCjRY= =hAlG -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 17:16:11 2003 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 3AAAE37B401; Thu, 17 Apr 2003 17:16:11 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF45E43F93; Thu, 17 Apr 2003 17:16:07 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3I0G4A7085661; Thu, 17 Apr 2003 18:16:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 17 Apr 2003 18:15:42 -0600 (MDT) Message-Id: <20030417.181542.123971267.imp@bsdimp.com> To: bmah@freebsd.org From: "M. Warner Losh" In-Reply-To: <200304171550.h3HFoqxV097075@bmah.dyndns.org> References: <200304142136.XAA28381@faui40p.informatik.uni-erlangen.de> <200304171550.h3HFoqxV097075@bmah.dyndns.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: eckert@i4.informatik.uni-erlangen.de Subject: Re: boot2 broken ? (booting from pst fails) 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, 18 Apr 2003 00:16:11 -0000 In message: <200304171550.h3HFoqxV097075@bmah.dyndns.org> "Bruce A. Mah" writes: : Well, if it's as simple as adding a note to the hardware list that : booting from pst(4) devices isn't supported, I'm happy to do that. I'm pretty sure there's a box at work booting from the pst device right now with 4.8. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 23:53:38 2003 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 D031337B401 for ; Thu, 17 Apr 2003 23:53:38 -0700 (PDT) Received: from ns.gfk.ru (ns.gfk.ru [62.205.179.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E8FC43F93 for ; Thu, 17 Apr 2003 23:53:37 -0700 (PDT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru ([10.0.0.30]) by ns.gfk.ru ([62.205.179.194]) with SMTP (MDaemon.PRO.v6.5.2.R) for ; Fri, 18 Apr 2003 10:52:42 +0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 18 Apr 2003 10:52:41 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sound drivers Thread-Index: AcLtmfvwVlZsG3tLQ9KFsTWY6JG2pwX1mOlQ From: "Yuriy Tsibizov" To: X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-hackers@FreeBSD.ORG Subject: How to debug panic()s in device_attach function of kernel module? 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, 18 Apr 2003 06:53:39 -0000 I'm trying to debug panic()s in one of my drivers (I can compile it only = as module now),=20 but I can't find a way to get address where it was loaded by kldload.=20 I can't run kldstat (as recommended by developers' handbook, 17.6) = because it panic()s=20 during kldloading (after LOR of ZONE_LOCKs after malloc(0) somewhere in = device_attach of my driver).=20 Can I get this address inside kdb? Another question, what is correct behavior of malloc(0, M_DEVBUF, = M_NOWAIT | M_ZERO)?=20 Yuriy Tsibizov From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 04:33:58 2003 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 0277737B401; Fri, 18 Apr 2003 04:33:58 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF53543FCB; Fri, 18 Apr 2003 04:33:56 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3IBXmVh063917; Fri, 18 Apr 2003 13:33:50 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Fri, 18 Apr 2003 13:33:48 +0200 (CEST) From: Martin Blapp To: hackers@freebsd.org Message-ID: <20030418132152.X6156@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: imp@imp.com Subject: [PATCH] dhclient active interface detection patch 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, 18 Apr 2003 11:33:58 -0000 Hi all, Already promised a few times, now I have done it :) Many of you may have a laptop and already had it a few times happen that the new IP didn't got set automatically. So you had to kill dhclient and restart it again. I've added code to dhclient to exactly fix this issue. Now dhclient behaves now like the win2000 dhcp-client. It polls the interface status of the selected interfaces and sends only requests if the link is there. It cancels all outstanding requests if the link goes away. The polling is currently hardcoded and done all 5 seconds. Of course I can change that later and make a option. The changes should still compile on different platforms, but of course, the polling mode doesn't work there till they add a customized version of interface_active(). Of course I'm happy about bugs and things which can be done better. And additional patches. I really like to see this code comitted and be part of isc-dhcpd. The code is also available here: http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling.diff diff -ruN contrib/isc-dhcp.old/client/dhclient.c contrib/isc-dhcp/client/dhclient.c --- contrib/isc-dhcp.old/client/dhclient.c Sun Mar 23 23:29:36 2003 +++ contrib/isc-dhcp/client/dhclient.c Fri Apr 18 11:12:04 2003 @@ -48,6 +48,11 @@ #include "dhcpd.h" #include "version.h" +#ifdef __FreeBSD__ +#include +#include +#endif + TIME cur_time; TIME default_lease_time = 43200; /* 12 hours... */ TIME max_lease_time = 86400; /* 24 hours... */ @@ -85,6 +90,7 @@ int onetry=0; int quiet=1; int nowait=0; +int linkcheck=0; static void usage PROTO ((void)); @@ -233,6 +239,7 @@ log_fatal ("%s: interface name too long (max %ld)", argv [i], (long)strlen (argv [i])); strlcpy (tmp -> name, argv [i], IFNAMSIZ); + tmp->status = interface_active(tmp->name); if (interfaces) { interface_reference (&tmp -> next, interfaces, MDL); @@ -379,19 +386,20 @@ } else if (!release_mode) { /* Call the script with the list of interfaces. */ for (ip = interfaces; ip; ip = ip -> next) { - /* If interfaces were specified, don't configure - interfaces that weren't specified! */ - if (interfaces_requested && - ((ip -> flags & (INTERFACE_REQUESTED | - INTERFACE_AUTOMATIC)) != - INTERFACE_REQUESTED)) - continue; - script_init (ip -> client, - "PREINIT", (struct string_list *)0); - if (ip -> client -> alias) - script_write_params (ip -> client, "alias_", - ip -> client -> alias); - script_go (ip -> client); + if (interface_active(ip->name)) { + /* If interfaces were specified, don't configure + interfaces that weren't specified! */ + if (interfaces_requested && + ((ip -> flags & (INTERFACE_REQUESTED | + INTERFACE_AUTOMATIC)) != + INTERFACE_REQUESTED)) + continue; + + if (ip -> client -> alias) + script_write_params (ip -> client, "alias_", + ip -> client -> alias); + script_go (ip -> client); + } } } @@ -428,8 +436,13 @@ client -> state = S_INIT; /* Set up a timeout to start the initialization process. */ +#ifdef ENABLE_POLLING_MODE add_timeout (cur_time + random () % 5, - state_reboot, client, 0, 0); + (void *)state_link, client, 0, 0); +#else + add_timeout (cur_time + random () % 5, + state_reboot, client, 0, 0); +#endif } } } @@ -2771,7 +2784,9 @@ break; } client -> state = S_INIT; - state_reboot (client); + if (interface_active(ip->name)) { + state_reboot (client); + } } } } @@ -2932,8 +2947,10 @@ client -> state = S_INIT; /* Set up a timeout to start the initialization process. */ - add_timeout (cur_time + random () % 5, - state_reboot, client, 0, 0); + if (interface_active(ip->name)) { + add_timeout (cur_time + random () % 5, + state_reboot, client, 0, 0); + } } } return ISC_R_SUCCESS; @@ -2997,7 +3014,9 @@ break; case server_awaken: - state_reboot (client); + if (interface_active(ip->name)) { + state_reboot (client); + } break; } } @@ -3134,3 +3153,94 @@ data_string_forget (&ddns_dhcid, MDL); return rcode; } + +/* Check to see if there's a wire plugged in */ +int +interface_active(const char *ifname) { +#ifdef __FreeBSD__ + struct ifmediareq ifmr; + int *media_list, i; + int sock; + + if ((sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) + log_fatal ("Can't create interface_active socket"); + + (void) memset(&ifmr, 0, sizeof(ifmr)); + (void) strncpy(ifmr.ifm_name, ifname, sizeof(ifmr.ifm_name)); + + if (ioctl(sock, SIOCGIFMEDIA, (caddr_t)&ifmr) < 0) { + /* + * Interface doesn't support SIOCGIFMEDIA, presume okay + */ + return (1); + } + + if (ifmr.ifm_count == 0) { + /* + * this is unexpected (to me), but we'll just assume + * that this means interface does not support SIOCGIFMEDIA + */ + return (1); + } + + if (ifmr.ifm_status & IFM_AVALID) { + if (ifmr.ifm_status & IFM_ACTIVE) + return (1); + } else + return (0); + + return (0); +} +#else /* ifdef __FreeBSD__ */ + + return (1); +#endif /* Add here implementations for other operating systems !!! */ + +#ifdef ENABLE_POLLING_MODE +/* Check the state of the NICs if we have link */ +int +state_link() { + struct interface_info *ip; + struct client_state *client; + + for (ip = interfaces; ip; ip = ip -> next) { +#ifdef DEBUG + printf("Connection-Status = %d, Name = %s\n", ip->status, ip->name); +#endif + if (ip->status == 0 || linkcheck == 0) { + if (interface_active(ip->name)) { +#ifdef DEBUG + printf("%s: Found Link on interface\n", ip->name); +#endif + for (client = ip -> client; + client; client = client -> next) { + add_timeout (cur_time + 2, + state_reboot, client, 0, 0); + } + ip->status = 1; + linkcheck = 1; + return(1); + } else { +#ifdef DEBUG + printf("%s: No Link on interface\n", ip->name); +#endif + for (client = ip -> client; + client; client = client -> next) { + cancel_timeout (send_discover, client); + cancel_timeout (send_request, client); + } + ip->status = 0; + } + } else { + if (interface_active(ip->name) == 0) { +#ifdef DEBUG + printf("%s: Lost Link on interface\n", ip->name); +#endif + ip->status = 0; + } + } + } + linkcheck = 1; + return(0); +} +#endif /* ifdef ENABLE_POLLING_MODE */ diff -ruN contrib/isc-dhcp.old/common/dispatch.c contrib/isc-dhcp/common/dispatch.c --- contrib/isc-dhcp.old/common/dispatch.c Thu Jan 16 07:04:49 2003 +++ contrib/isc-dhcp/common/dispatch.c Fri Apr 18 10:23:21 2003 @@ -51,6 +51,8 @@ struct timeout *timeouts; static struct timeout *free_timeouts; +extern int linkcheck; + void set_time (u_int32_t t) { /* Do any outstanding timeouts. */ @@ -96,10 +98,19 @@ { struct timeval tv, *tvp; isc_result_t status; + TIME cur_time; + tvp = NULL; /* Wait for a packet or a timeout... XXX */ do { tvp = process_outstanding_timeouts (&tv); +#ifdef ENABLE_POLLING_MODE + if (! state_link()) { + GET_TIME (&cur_time); + add_timeout (cur_time + 5, (void *)state_link, 0, 0, 0); + tvp = process_outstanding_timeouts (&tv); + } +#endif /* ENABLE_POLLING_MODE */ status = omapi_one_dispatch (0, tvp); } while (status == ISC_R_TIMEDOUT || status == ISC_R_SUCCESS); log_fatal ("omapi_one_dispatch failed: %s -- exiting.", diff -ruN contrib/isc-dhcp.old/includes/dhcpd.h contrib/isc-dhcp/includes/dhcpd.h --- contrib/isc-dhcp.old/includes/dhcpd.h Wed Jan 15 10:31:19 2003 +++ contrib/isc-dhcp/includes/dhcpd.h Fri Apr 18 10:48:09 2003 @@ -778,6 +778,7 @@ unsigned remote_id_len; /* Length of Remote ID. */ char name [IFNAMSIZ]; /* Its name... */ + int status; /* Link status */ int index; /* Its index. */ int rfdesc; /* Its read file descriptor. */ int wfdesc; /* Its write file descriptor, if @@ -1853,6 +1854,9 @@ void send_decline PROTO ((void *)); void state_reboot PROTO ((void *)); +#ifdef ENABLE_POLLING_MODE +int state_link PROTO (()); +#endif void state_init PROTO ((void *)); void state_selecting PROTO ((void *)); void state_requesting PROTO ((void *)); Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 05:59:06 2003 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 6509937B40A for ; Fri, 18 Apr 2003 05:59:06 -0700 (PDT) Received: from msgbas1x.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA9BE43FE1 for ; Fri, 18 Apr 2003 05:59:05 -0700 (PDT) (envelope-from ctuffli@rose.agilent.com) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 5AA2F16FC2 for ; Fri, 18 Apr 2003 06:59:05 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by relcos1.cos.agilent.com (Postfix) with ESMTP id E9AC85ED for ; Fri, 18 Apr 2003 06:59:04 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) ESMTP id FAA19727 for ; Fri, 18 Apr 2003 05:59:03 -0700 (PDT) Received: from thegrail (anu.rose.agilent.com [156.140.225.186]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA69A4; Fri, 18 Apr 2003 05:59:00 -0700 Received: by thegrail (Postfix, from userid 1001) id A204384BDF; Fri, 18 Apr 2003 04:52:49 -0700 (PDT) Date: Fri, 18 Apr 2003 04:52:49 -0700 From: Chuck Tuffli To: Yuriy Tsibizov Message-ID: <20030418115248.GA169@thegrail.rose.agilent.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How to debug panic()s in device_attach function of kernel module? 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, 18 Apr 2003 12:59:06 -0000 On Fri, Apr 18, 2003 at 10:52:41AM +0400, Yuriy Tsibizov wrote: > > I'm trying to debug panic()s in one of my drivers (I can compile it > only as module now), but I can't find a way to get address where it > was loaded by kldload. I can't run kldstat (as recommended by > developers' handbook, 17.6) because it panic()s during kldloading > (after LOR of ZONE_LOCKs after malloc(0) somewhere in device_attach > of my driver). Can I get this address inside kdb? You were in the right section of the handbook. Take a look at the paragraph after the kldstat suggestion. You can walk the linker_files structure to see where modules are loaded. I use gbd for debugging and define the following function in my .gdbinit file to walk this list define lm set $linker = (struct linker_file *)linker_files->tqh_first while $linker != 0 printf "found %s at %#x\n", $linker->filename, $linker->address set $linker = $linker.link.tqe_next end end You can manually follow the above approach using kdb as well. Hope that helps. -- Chuck Tuffli Agilent Technologies, Storage and Networking From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 07:41:59 2003 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 2E2F637B401; Fri, 18 Apr 2003 07:41:59 -0700 (PDT) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5073943FE5; Fri, 18 Apr 2003 07:41:58 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) by spode.pacbell.net (8.12.8p1/8.12.8) with ESMTP id h3I5C2u6000430; Thu, 17 Apr 2003 22:12:02 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3E9F8922.1166ABA8@lbl.gov> Date: Thu, 17 Apr 2003 22:12:02 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-hackers@freebsd.org Subject: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) 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, 18 Apr 2003 14:41:59 -0000 I have modified the sockbuf and mbuf operation to double the throughput over high bandwidth delay product path. The patch is available at: http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches The current modification is for tcp transmission only. I have adapted some code of uipc_socket2.c from Sam Leffler http://www.freebsd.org/~sam/thorpe-stable.patch for tcp receiver, but it has not been tested yet, so the tcp_input.p is empty. I ignored all record chain (m_nextpkt) related code. The details is explained at http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. I may submit the patch regardless if tcp_input code works or not, because the tcp sender (server) is more important in high-speed network than the receiver (client). It is appreciated if any one can verify the patch and provide feedback. -- ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov --- Distributed Systems Department http://www.itg.lbl.gov/~jin M/S 50B-2239 Ph#:(510) 486-7531 Fax: 486-6363 Lawrence Berkeley National Laboratory, Berkeley, CA 94720 From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 08:29:32 2003 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 9A80D37B401 for ; Fri, 18 Apr 2003 08:29:32 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B7B6F43F85 for ; Fri, 18 Apr 2003 08:29:30 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 13113 invoked from network); 18 Apr 2003 15:29:29 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 18 Apr 2003 15:29:29 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 17 Apr 2003 22:25:30 -0500 (CDT) From: Mike Silbersack To: "Jin Guojun [NCS]" In-Reply-To: <3E9F8922.1166ABA8@lbl.gov> Message-ID: <20030417222124.D3757@odysseus.silby.com> References: <3E9F8922.1166ABA8@lbl.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) 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, 18 Apr 2003 15:29:33 -0000 On Thu, 17 Apr 2003, Jin Guojun [NCS] wrote: > I have modified the sockbuf and mbuf operation to double the throughput over > high bandwidth delay product path. > > The patch is available at: > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > The current modification is for tcp transmission only. Impressive results, it sounds like we definitely need this improvement (in some form or another.) > Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. > I may submit the patch regardless if tcp_input code works or not, because the > tcp > sender (server) is more important in high-speed network than the receiver > (client). > > It is appreciated if any one can verify the patch and provide feedback. > > -- > ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov --- But I don't have time to look at it. :) Keep the patches and benchmarks coming, Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 08:32:58 2003 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 005E537B401 for ; Fri, 18 Apr 2003 08:32:58 -0700 (PDT) Received: from web13302.mail.yahoo.com (web13302.mail.yahoo.com [216.136.175.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 8EBD943FA3 for ; Fri, 18 Apr 2003 08:32:57 -0700 (PDT) (envelope-from oilbattle@yahoo.co.uk) Message-ID: <20030418153257.199.qmail@web13302.mail.yahoo.com> Received: from [196.2.50.9] by web13302.mail.yahoo.com via HTTP; Fri, 18 Apr 2003 16:32:57 BST Date: Fri, 18 Apr 2003 16:32:57 +0100 (BST) From: =?iso-8859-1?q?oil=20battle?= To: hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: 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, 18 Apr 2003 15:32:58 -0000 --------------------------------- Yahoo! Plus - For a better Internet experience From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 09:58:12 2003 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 5A83B37B405; Fri, 18 Apr 2003 09:58:12 -0700 (PDT) Received: from samson.dc.luth.se (samson.dc.luth.se [130.240.112.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE59D43FE9; Fri, 18 Apr 2003 09:58:09 -0700 (PDT) (envelope-from bj@dc.luth.se) Received: from dc.luth.se (root@bompe.dc.luth.se [130.240.60.42]) by samson.dc.luth.se (8.12.5/8.12.5) with ESMTP id h3IGw8LG012691; Fri, 18 Apr 2003 18:58:08 +0200 (MET DST) Received: from bompe.dc.luth.se (bj@localhost.dc.luth.se [127.0.0.1]) by dc.luth.se (8.12.6/8.11.3) with ESMTP id h3IGw72F021961; Fri, 18 Apr 2003 18:58:07 +0200 (CEST) (envelope-from bj@bompe.dc.luth.se) Message-Id: <200304181658.h3IGw72F021961@dc.luth.se> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Jin Guojun [NCS]" In-reply-to: Your message of Thu, 17 Apr 2003 22:12:02 PDT. <3E9F8922.1166ABA8@lbl.gov> Dcc: From: Borje Josefsson X-Disposition-notification-to: Borje.Josefsson@dc.luth.se X-uri: http://www.dc.luth.se/~bj/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Apr 2003 18:58:07 +0200 Sender: bj@dc.luth.se cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bj@dc.luth.se List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 16:58:12 -0000 On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > I have modified the sockbuf and mbuf operation to double the throughput= over > high bandwidth delay product path. > = > The patch is available at: > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patc= hes > = > The current modification is for tcp transmission only. > = > I have adapted some code of uipc_socket2.c from Sam Leffler > http://www.freebsd.org/~sam/thorpe-stable.patch > = > for tcp receiver, but it has not been tested yet, so the tcp_input.p is= empty. > = > I ignored all record chain (m_nextpkt) related code. The details is exp= lained at > = > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > = > Once the tcp_input code is tested, I will submit the patch to bugs@free= bsd.org. > I may submit the patch regardless if tcp_input code works or not, becau= se the > tcp > sender (server) is more important in high-speed network than the receiv= er > (client). > = > It is appreciated if any one can verify the patch and provide feedback.= OK. I have now tried this patch on a newly-installed 4.8R. The patch = applied fine. When the sysctl net.inet.tcp.liondmask is unset, everything= = seems OK, but when setting it to 7 (as specified with the patch = instructions) i get: Fatal trap 12: page fault while in kernel mode. (I could write down all the stuff on addresses etc if it makes sense) when I run ttcp to test the performance. This is repeatable. I'm willing to test more, if someone provides me with some hints on what = to do. --B=F6rje From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 13:04:29 2003 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 93C0D37B401; Fri, 18 Apr 2003 13:04:29 -0700 (PDT) Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C122D43F93; Fri, 18 Apr 2003 13:04:28 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from postal2.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.12.9/8.12.9) with ESMTP id h3IK4RCY007628; Fri, 18 Apr 2003 13:04:28 -0700 (PDT) Received: from lbl.gov (gracie.lbl.gov [131.243.2.175]) by postal2.lbl.gov (8.12.9/8.12.9) with ESMTP id h3IK4O1b007621; Fri, 18 Apr 2003 13:04:27 -0700 (PDT) Sender: jin@lbl.gov Message-ID: <3EA05A48.D9BB85E7@lbl.gov> Date: Fri, 18 Apr 2003 13:04:24 -0700 From: "Jin Guojun [DSD]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: zh, zh-CN, en MIME-Version: 1.0 To: bj@dc.luth.se References: <200304181658.h3IGw72F021961@dc.luth.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) 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, 18 Apr 2003 20:04:29 -0000 Opps, there was a bad file -- tcp_input.p -- which is not working yet. Also, a patch file -- tcp_usrreq.p -- was missing. I will take the tcp_input.p out and put tcp_usrreq.p in. When it is finished, I will send another mail out. -Jin Borje Josefsson wrote: > On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > > > I have modified the sockbuf and mbuf operation to double the throughput over > > high bandwidth delay product path. > > > > The patch is available at: > > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > The current modification is for tcp transmission only. > > > > I have adapted some code of uipc_socket2.c from Sam Leffler > > http://www.freebsd.org/~sam/thorpe-stable.patch > > > > for tcp receiver, but it has not been tested yet, so the tcp_input.p is empty. > > > > I ignored all record chain (m_nextpkt) related code. The details is explained at > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > > > > Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. > > I may submit the patch regardless if tcp_input code works or not, because the > > tcp > > sender (server) is more important in high-speed network than the receiver > > (client). > > > > It is appreciated if any one can verify the patch and provide feedback. > > OK. I have now tried this patch on a newly-installed 4.8R. The patch > applied fine. When the sysctl net.inet.tcp.liondmask is unset, everything > seems OK, but when setting it to 7 (as specified with the patch > instructions) i get: > > Fatal trap 12: page fault while in kernel mode. > (I could write down all the stuff on addresses etc if it makes sense) > > when I run ttcp to test the performance. > > This is repeatable. > > I'm willing to test more, if someone provides me with some hints on what > to do. > > --Börje From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 14:10:47 2003 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 C80A437B401 for ; Fri, 18 Apr 2003 14:10:47 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBBF43FE0 for ; Fri, 18 Apr 2003 14:10:47 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0240.cvx22-bradley.dialup.earthlink.net ([209.179.198.240] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196d8A-0004IG-00 for hackers@freebsd.org; Fri, 18 Apr 2003 14:10:46 -0700 Message-ID: <3EA06987.3CF6D402@mindspring.com> Date: Fri, 18 Apr 2003 14:09:27 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a435745805e1197074db3f89ddea4ff695387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Subject: Re: Repeated similar panics on -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: Fri, 18 Apr 2003 21:10:48 -0000 Since the thread occurred on -hackers, thought I'd post here, too. The thread (see subject) around 02 Apr 2003 demonstrated a panic in kern_malloc.c in malloc() as a result in the increased default KVA space in the 4.x branch. I just posted a patch to -stable. If there is a committer interested in fixing this problem for people who doesn't read -stable, they may want to grab it and commit it. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 14:40:18 2003 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 4CC6837B414 for ; Fri, 18 Apr 2003 14:40:18 -0700 (PDT) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 62C2F43F3F for ; Fri, 18 Apr 2003 14:40:16 -0700 (PDT) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 65379 invoked by uid 1500); 18 Apr 2003 21:40:13 -0000 Date: Fri, 18 Apr 2003 17:40:13 -0400 From: "Kevin A. Pieckiel" To: freebsd-hackers@freebsd.org Message-ID: <20030418214013.GA65290@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: kqueue events 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, 18 Apr 2003 21:40:18 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Will the kqueue interface work with pthread ID's, or is it limited only to system process ID's? If it doesn't work with pthread ID's, how much trouble is it to modify them and add a pthread ID filter? Kevin "Beaten paths are for beaten men" -- _Unix Shell Programming_ --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+oHC8c3iJbvFgTpIRAkBXAJ9ietwz4mnDqcfrP6Qxi1LH5ZrutgCfUDu3 FgJlttKVc/ZYbHxSmXr1HJY= =kOQP -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 15:45:25 2003 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 87F6B37B401; Fri, 18 Apr 2003 15:45:25 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B80A43F85; Fri, 18 Apr 2003 15:45:24 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3IMjNC2063383; Sat, 19 Apr 2003 02:45:23 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3IMjN42063382; Sat, 19 Apr 2003 02:45:23 +0400 (MSD) Date: Sat, 19 Apr 2003 02:45:22 +0400 From: Alex Semenyaka To: freebsd-threads@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20030418224522.GA63339@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i cc: David Xu cc: Daniel Eischen Subject: Re: libpthread patch 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, 18 Apr 2003 22:45:25 -0000 On Wed, Apr 16, 2003 at 01:09:46PM -0400, Daniel Eischen wrote: > Found it! The library's version of sigaction was not allowing > a signal handler for SIGCHLD to be installed; it was leftover > from libc_r. By the way, in this connection could somebody check my follow-up to the PR bin/48856? I suggested a really small fix (3 lines in total) to the current implementation of the signal(). With the current one the call of signal(SIGCHLD, SIG_IGN) still allows zombie to be born. There are to places to fix actually, one is the standard libc and second is the pthreads (that's why I am sending this message to -threads as well). If that fix is bad somehow I would gladly receive any explanations. Thanks! SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 15:53:56 2003 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 17CEB37B401; Fri, 18 Apr 2003 15:53:56 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D02C43FA3; Fri, 18 Apr 2003 15:53:55 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3IMrsBg005358; Fri, 18 Apr 2003 18:53:54 -0400 (EDT) Received: from localhost (eischen@localhost)h3IMrsnO005354; Fri, 18 Apr 2003 18:53:54 -0400 (EDT) Date: Fri, 18 Apr 2003 18:53:54 -0400 (EDT) From: Daniel Eischen To: Alex Semenyaka In-Reply-To: <20030418224522.GA63339@snark.ratmir.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch 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, 18 Apr 2003 22:53:56 -0000 On Sat, 19 Apr 2003, Alex Semenyaka wrote: > On Wed, Apr 16, 2003 at 01:09:46PM -0400, Daniel Eischen wrote: > > Found it! The library's version of sigaction was not allowing > > a signal handler for SIGCHLD to be installed; it was leftover > > from libc_r. > > By the way, in this connection could somebody check my follow-up to > the PR bin/48856? I suggested a really small fix (3 lines in total) > to the current implementation of the signal(). With the current one > the call of signal(SIGCHLD, SIG_IGN) still allows zombie to be born. > There are to places to fix actually, one is the standard libc and > second is the pthreads (that's why I am sending this message to > -threads as well). If that fix is bad somehow I would gladly receive > any explanations. Thanks! I don't think you can always set SA_NOCLDWAIT because it could screw up wait() in programs that don't set SA_NOCLDWAIT. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 16:08:23 2003 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 E91C537B401; Fri, 18 Apr 2003 16:08:23 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CA0C43FE5; Fri, 18 Apr 2003 16:08:22 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3IN8KC2063680; Sat, 19 Apr 2003 03:08:21 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3IN8J4M063675; Sat, 19 Apr 2003 03:08:19 +0400 (MSD) Date: Sat, 19 Apr 2003 03:08:19 +0400 From: Alex Semenyaka To: Daniel Eischen Message-ID: <20030418230818.GE3693@snark.ratmir.ru> References: <20030418224522.GA63339@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Alex Semenyaka cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch 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, 18 Apr 2003 23:08:24 -0000 On Fri, Apr 18, 2003 at 06:53:54PM -0400, Daniel Eischen wrote: > I don't think you can always set SA_NOCLDWAIT because it could > screw up wait() in programs that don't set SA_NOCLDWAIT. Sure, and I wrote it in that PR: zombie is the information for the wait, no zombie - no infromation. But are there programs which call signal(SIGCHLD, SIG_IGN) and then trying to wait()? I supposed that there are no such: suggested behaviour of signal() is the standard for a lot of systems. Yes, I know that most of them are SysV. But do we have such non-portable BSD-only products trying to use signal(SIGCHLD, SIG_IGN)/wait()? I may be wrong of course, but would anybody points me out the product that will be broken after such changes? Thanks in advance! SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 16:34:16 2003 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 E9B7637B401; Fri, 18 Apr 2003 16:34:16 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E5B943FE0; Fri, 18 Apr 2003 16:34:15 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3INYEC2063991; Sat, 19 Apr 2003 03:34:14 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3INYEkR063990; Sat, 19 Apr 2003 03:34:14 +0400 (MSD) Date: Sat, 19 Apr 2003 03:34:14 +0400 From: Alex Semenyaka To: Daniel Eischen Message-ID: <20030418233414.GF3693@snark.ratmir.ru> References: <20030418224522.GA63339@snark.ratmir.ru> <20030418230818.GE3693@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418230818.GE3693@snark.ratmir.ru> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Alex Semenyaka cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch 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, 18 Apr 2003 23:34:17 -0000 On Sat, Apr 19, 2003 at 03:08:19AM +0400, Alex Semenyaka wrote: > But are there programs which call signal(SIGCHLD, SIG_IGN) and then trying > to wait()? I supposed that there are no such: suggested behaviour of signal() By the way... I just thought that it might be reasonable to allow user to choose that behaviour on the fly (like he can do it for the malloc(3)). Do anyone have the objections against this way? If there are no ones, I can do the patch that allows to signal() OPTIONALLY set SA_NOCLDWAIT flag if the environment variable (say, NOCHLD_NOWAIT) is set. Thanks again :) SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 17:49:13 2003 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 6BC8F37B401; Fri, 18 Apr 2003 17:49:13 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB0DA43FB1; Fri, 18 Apr 2003 17:49:11 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3J0nAC2067873; Sat, 19 Apr 2003 04:49:10 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3J0nA0G067872; Sat, 19 Apr 2003 04:49:10 +0400 (MSD) Date: Sat, 19 Apr 2003 04:49:10 +0400 From: Alex Semenyaka To: Daniel Eischen Message-ID: <20030419004910.GG3693@snark.ratmir.ru> References: <20030418224522.GA63339@snark.ratmir.ru> <20030418230818.GE3693@snark.ratmir.ru> <20030418233414.GF3693@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418233414.GF3693@snark.ratmir.ru> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Alex Semenyaka cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch 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, 19 Apr 2003 00:49:14 -0000 On Sat, Apr 19, 2003 at 03:34:14AM +0400, Alex Semenyaka wrote: > By the way... I just thought that it might be reasonable to allow user to > choose that behaviour on the fly (like he can do it for the malloc(3)). Sorry for such amount of messages. This is the last one in this bunch. I found myself software that ignores SIGCHLD with signal(3) but wants then to wait() for a child. So, I must say: this behaviour might be done as an option, if user wants it, and sould be prohibited by default. So do anybody have objections against the patch which will allow such optional behaviour if some envvariable is set? > Thanks again :) And again, and sorry :) SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 20:35:53 2003 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 664BD37B401 for ; Fri, 18 Apr 2003 20:35:53 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA5243FDD for ; Fri, 18 Apr 2003 20:35:50 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3J3ZhXB015986; Fri, 18 Apr 2003 20:35:47 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304190335.h3J3ZhXB015986@gw.catspoiler.org> Date: Fri, 18 Apr 2003 20:35:43 -0700 (PDT) From: Don Lewis To: tlambert2@mindspring.com In-Reply-To: <3EA06987.3CF6D402@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 03:35:53 -0000 On 18 Apr, Terry Lambert wrote: > Since the thread occurred on -hackers, thought I'd post here, too. > > The thread (see subject) around 02 Apr 2003 demonstrated a panic > in kern_malloc.c in malloc() as a result in the increased default > KVA space in the 4.x branch. > > I just posted a patch to -stable. > > If there is a committer interested in fixing this problem for > people who doesn't read -stable, they may want to grab it and > commit it. The patch looks ok, but I don't understand the failure mechanism. If kbp->kb_next is initially NULL, then kmem_malloc() should get called. It doesn't look possible for kmem_malloc() to return NULL in the !M_NOWAIT case with the kmem_map. It looks like kmem_malloc() will either retry or panic. I don't see how the kbp list could be refreshed and reemptied as you suggested in a previous message, because we're protected by splmem() except if kmem_malloc() blocks, and that can only happen before we put the newly allocated memory on the kbp list. Depending on how much you believe the line number reported by gdb, the trap is caused by va = kbp->kb_next; and not the following line: kbp->kb_next = ((struct freelist *)va)->next; which would tend to make me think that kbp was somehow getting stomped on. Something else that bothers me is >> fault virtual address = 0x5cdd8000 If the trap is being caused by va being NULL, I'd expect the fault adress to be 0x12 because the next member of struct freelist is at offset 12, at least for the i386 architecture. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 23:21:24 2003 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 EA31D37B401; Fri, 18 Apr 2003 23:21:24 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC7D143FDD; Fri, 18 Apr 2003 23:21:23 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3J6LLC2070372; Sat, 19 Apr 2003 10:21:22 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3J6LLZj070371; Sat, 19 Apr 2003 10:21:21 +0400 (MSD) Date: Sat, 19 Apr 2003 10:21:21 +0400 From: Alex Semenyaka To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20030419062121.GA70121@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Slow vipw and fast pwd_mkdb 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, 19 Apr 2003 06:21:25 -0000 Hello, could somebody to comment PR bin/51148? It is suggestion how to pass a value of cache size to pwd_mkdb when we are doing vipw or such. It can give a greate speed-up when master.passwd is really big (and sometimes it is). Appropriate cache size can make process 10 to 100 or more times faster. I gave the results of measurements in that problem report. Thanks in advance! SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 23:53:16 2003 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 662BF37B401; Fri, 18 Apr 2003 23:53:16 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B50BF43FA3; Fri, 18 Apr 2003 23:53:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0181.cvx22-bradley.dialup.earthlink.net ([209.179.198.181] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196mDo-0004eF-00; Fri, 18 Apr 2003 23:53:13 -0700 Message-ID: <3EA0F1E0.9D0165B4@mindspring.com> Date: Fri, 18 Apr 2003 23:51:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200304190335.h3J3ZhXB015986@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4bb08ff659f321d3113e933ccf576744193caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 06:53:16 -0000 Don Lewis wrote: > On 18 Apr, Terry Lambert wrote: > > Since the thread occurred on -hackers, thought I'd post here, too. > > > > The thread (see subject) around 02 Apr 2003 demonstrated a panic > > in kern_malloc.c in malloc() as a result in the increased default > > KVA space in the 4.x branch. > > > > I just posted a patch to -stable. > > > > If there is a committer interested in fixing this problem for > > people who doesn't read -stable, they may want to grab it and > > commit it. > > The patch looks ok, but I don't understand the failure mechanism. If > kbp->kb_next is initially NULL, then kmem_malloc() should get called. It > doesn't look possible for kmem_malloc() to return NULL in the !M_NOWAIT > case with the kmem_map. It looks like kmem_malloc() will either retry > or panic. It's hard to see. But it can happen. The way it happens is to take a fault that causes the freep to be NULL in the case that kbp->kb_last == kbp->kb_next. We know it happens, because the "va" dereference fails in the same place on several machines, and it's set to kbp->kb_next immediately before the failure. If you hear hoofbeats, look for horses, but once you've eliminated the possibility of horses, well, zebras are a good guess. 8-). Basically, if I allocate 1 page, put it on the freelist, then it gets grabbed by something else meanwhile, then cp <= va is true, and it breaks with kbp->kb_next = NULL. This can happen for zalloci() zones, for which there are page mappings, but no backing pages (mbufs, whatever). All that's required is that you run out of physical RAM before you run out of kmem_map (a distinct possibility with a large KVA, and a stair function in the scaling -- or even if you just follow the handbook, and increase the number of mbufs/nmbclusters). What the patch basically does is forces the caller to sleep until it's possible to satisfy the request (yeah, this could be "never", but it's more likely to be a transient condition. It didn't happen with the smaller KVA, because the page mapping overhead vs. pages ratio vs. users of zalloci() happened to keep things happy. Plus you have to have a pretty big load to see it. > I don't see how the kbp list could be refreshed and reemptied as you > suggested in a previous message, because we're protected by splmem() > except if kmem_malloc() blocks, and that can only happen before we put > the newly allocated memory on the kbp list. > > Depending on how much you believe the line number reported by gdb, the > trap is caused by > va = kbp->kb_next; > and not the following line: > kbp->kb_next = ((struct freelist *)va)->next; > which would tend to make me think that kbp was somehow getting stomped > on. > > Something else that bothers me is > > >> fault virtual address = 0x5cdd8000 > > If the trap is being caused by va being NULL, I'd expect the fault > adress to be 0x12 because the next member of struct freelist is at > offset 12, at least for the i386 architecture. No; the problem is kbp->kb_next is NULL, not kbp itself. Consider if "cp -= allocsize" is zero. No matter what va is, that's going to drop out of the "for(;;)" loop. FWIW, -current has a similar case (no patch, sorry) because of the new allocator, which can return NULL for any request, if it rus out of map space. This happens because the zalloci() *formerly* staked out space for each zone, and merely failed to provide backing pages. Now, with the new allocator, the zone pages are demand allocated; they're type-stable, but they aren't region-stable any more. Because of this, it's possible that a zone grow can fail, prior to reaching the administrative limit on the zone, and the allocation can fail. There's a heck of a lot of code that depends on zalloci() never being able to return NULL. I've fixed two places for different people, so far, and told people to file bugs against about three others. Basically, it comes down to tuning that used to be safe in 5.x, and some load conditions that used to be safe in 5.x, but aren't any more. IMO, the new allocator has a number of problems like this, though, and probably the correct place to fix them is the allocator. This can't mean making the allocation hang the caller until it can proceed, though (this is OK to do in malloc(), because it's OK to hang in the M_WAITOK case, and code with M_NOWAIT already expects NULL; the 4.x fix is therefore pretty easy to do in one place). My personal suggestion on 5.x, if you want to see people quit complaining about "Trap 12" or switching off to 4.8 and giving 5.x a "pass", would be to provide kernel mappings for all of the physical RAM in the machine, up front, and then allocate from that by taking over the mappings. That way, there's no such thing as a "kmem_map too small" or a trap 12 as a result of a zalloci() zone grow failure: if there's no RAM, that doesn't mean there's no mapping. It also saves all the mapping later. I've suggested this before. 8-). Actually, if you want another patch for 4.x, I can save a good 10%-15% of the performance overhead in zalloci() and zalloc() with a couple of trivial changes (unnecessary math is expensive, particularly if it's the same math each time). It's also possible to save a large amount of RAM in the zalloc() and zalloci() code; once you know that the RAM is type-stable, if you are willing to do a little better job of fit-to-page, it's pretty easy to save an average of 64 bytes per object. That's also a patch for 4.x. This isn't really a high priority, unless you are trying to squeeze everything you can out of the box, and are dealing with incredible RAM pressure to do it... -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 01:59:31 2003 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 C8C5C37B401 for ; Sat, 19 Apr 2003 01:59:31 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F389843FD7 for ; Sat, 19 Apr 2003 01:59:30 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3J8xNXB016406; Sat, 19 Apr 2003 01:59:27 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304190859.h3J8xNXB016406@gw.catspoiler.org> Date: Sat, 19 Apr 2003 01:59:23 -0700 (PDT) From: Don Lewis To: tlambert2@mindspring.com In-Reply-To: <3EA0F1E0.9D0165B4@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 08:59:32 -0000 On 18 Apr, Terry Lambert wrote: > Don Lewis wrote: >> On 18 Apr, Terry Lambert wrote: >> > Since the thread occurred on -hackers, thought I'd post here, too. >> > >> > The thread (see subject) around 02 Apr 2003 demonstrated a panic >> > in kern_malloc.c in malloc() as a result in the increased default >> > KVA space in the 4.x branch. >> > >> > I just posted a patch to -stable. >> > >> > If there is a committer interested in fixing this problem for >> > people who doesn't read -stable, they may want to grab it and >> > commit it. >> >> The patch looks ok, but I don't understand the failure mechanism. If >> kbp->kb_next is initially NULL, then kmem_malloc() should get called. It >> doesn't look possible for kmem_malloc() to return NULL in the !M_NOWAIT >> case with the kmem_map. It looks like kmem_malloc() will either retry >> or panic. > > It's hard to see. But it can happen. The way it happens is to > take a fault that causes the freep to be NULL in the case that > kbp->kb_last == kbp->kb_next. > > We know it happens, because the "va" dereference fails in the > same place on several machines, and it's set to kbp->kb_next > immediately before the failure. > > If you hear hoofbeats, look for horses, but once you've eliminated > the possibility of horses, well, zebras are a good guess. 8-). Ok, here's a Reader's Digest version of the code in question: if (kbp->kb_next == NULL) { kbp->kb_last = NULL; if (size > MAXALLOCSAVE) allocsize = roundup(size, PAGE_SIZE); else allocsize = 1 << indx; npg = btoc(allocsize); va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags ); /* * Just in case we blocked while allocating memory, * and someone else also allocated memory for this * bucket, don't assume the list is still empty. */ savedlist = kbp->kb_next; kbp->kb_next = cp = va + (npg * PAGE_SIZE) - allocsize; for (;;) { freep = (struct freelist *)cp; if (cp <= va) break; cp -= allocsize; freep->next = cp; } freep->next = savedlist; if (kbp->kb_last == NULL) kbp->kb_last = (caddr_t)freep; } va = kbp->kb_next; kbp->kb_next = ((struct freelist *)va)->next; > Basically, if I allocate 1 page, put it on the freelist, then it > gets grabbed by something else meanwhile, then cp <= va is true, > and it breaks with kbp->kb_next = NULL. This whole section of code is protected by splmem() except that it may sleep inside kmem_malloc(), so kbp->kb_next and kbp->kb_last could be modified by another process during that time. freep is a local variable and from the time we update kbp->kb_next with the new allocation through the end of the "for" loop and beyond is protected by splmem(), so nothing else should be able to steal anything from the free list during this time. > This can happen for zalloci() zones, for which there are page > mappings, but no backing pages (mbufs, whatever). All that's > required is that you run out of physical RAM before you run out > of kmem_map (a distinct possibility with a large KVA, and a > stair function in the scaling -- or even if you just follow the > handbook, and increase the number of mbufs/nmbclusters). That should just cause kmem_malloc() to block. > What the patch basically does is forces the caller to sleep > until it's possible to satisfy the request (yeah, this could be > "never", but it's more likely to be a transient condition. Yup, I understand that part. > It didn't happen with the smaller KVA, because the page mapping > overhead vs. pages ratio vs. users of zalloci() happened to keep > things happy. Plus you have to have a pretty big load to see it. >> Something else that bothers me is >> >> >> fault virtual address = 0x5cdd8000 >> >> If the trap is being caused by va being NULL, I'd expect the fault >> adress to be 0x12 because the next member of struct freelist is at >> offset 12, at least for the i386 architecture. > > No; the problem is kbp->kb_next is NULL, not kbp itself. Consider > if "cp -= allocsize" is zero. No matter what va is, that's going > to drop out of the "for(;;)" loop. I don't see how that can happen. allocsize will either be a power of two that is less than PAGE_SIZE and npg will be 1, or allocsize will be some multiple of the page size. In the first case kbp->kb_next = cp = va + (npg * PAGE_SIZE) - allocsize will be > va and the "for" loop will iterate a power of two times, and on the last iteration cp == va. In the second case, allocsize == (npg * PAGE_SIZE) so that cp and kbp->kb_next will be equal to va and the "for" loop will terminate on its first iteration. Also, if "cp -= allocsize" is zero, this happens after the loop termination test so we'd start the next iteration and do the freep = (struct freelist *)cp; assignment and then blow up on this assignment freep->next = savedlist; immediately after the "for" loop. This code bothers me, though, because if allocsize ever happened to not evenly divide (npg * PAGE_SIZE), the loop termination condition would be wrong and the end of the previous page (or more) would end up on the free list. If va were small enough and allocsize were big enough, it would even be possible to wrap around. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 06:05:32 2003 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 006BB37B401; Sat, 19 Apr 2003 06:05:32 -0700 (PDT) Received: from samson.dc.luth.se (samson.dc.luth.se [130.240.112.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FCE43F75; Sat, 19 Apr 2003 06:05:30 -0700 (PDT) (envelope-from bj@dc.luth.se) Received: from dc.luth.se (root@bompe.dc.luth.se [130.240.60.42]) by samson.dc.luth.se (8.12.5/8.12.5) with ESMTP id h3JD5TLG019266; Sat, 19 Apr 2003 15:05:29 +0200 (MET DST) Received: from bompe.dc.luth.se (bj@localhost.dc.luth.se [127.0.0.1]) by dc.luth.se (8.12.6/8.11.3) with ESMTP id h3JD5S2F026929; Sat, 19 Apr 2003 15:05:28 +0200 (CEST) (envelope-from bj@bompe.dc.luth.se) Message-Id: <200304191305.h3JD5S2F026929@dc.luth.se> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Jin Guojun [DSD]" In-reply-to: Your message of Fri, 18 Apr 2003 13:04:24 PDT. <3EA05A48.D9BB85E7@lbl.gov> Dcc: From: Borje Josefsson X-Disposition-notification-to: Borje.Josefsson@dc.luth.se X-uri: http://www.dc.luth.se/~bj/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Apr 2003 15:05:28 +0200 Sender: bj@dc.luth.se cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bj@dc.luth.se List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 13:05:32 -0000 Hmm. I'm not sure if I misunderstood if this was ready for another test = run or not. Anyhow - I took the new patch .tgz (which, btw, still had = tcp_input.p in it). I applied the patches (except tcp_input) and tested. Now I get: Panic: bad cur_off 00000 m_p 0xc0a7f400 0xc0a7f400 my_off 0 1448 cc 3407144 As usual, I'm willing to test more when there are an update available. --B=F6rje On Fri, 18 Apr 2003 13:04:24 PDT "Jin Guojun [DSD]" wrote: > Opps, there was a bad file -- tcp_input.p -- which is not working yet. > Also, a patch file -- tcp_usrreq.p -- was missing. > = > I will take the tcp_input.p out and put tcp_usrreq.p in. > When it is finished, I will send another mail out. > = > -Jin > = > Borje Josefsson wrote: > = > > On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > > > > > I have modified the sockbuf and mbuf operation to double the throug= hput over > > > high bandwidth delay product path. > > > > > > The patch is available at: > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_= Patches > > > > > > The current modification is for tcp transmission only. > > > > > > I have adapted some code of uipc_socket2.c from Sam Leffler > > > http://www.freebsd.org/~sam/thorpe-stable.patch > > > > > > for tcp receiver, but it has not been tested yet, so the tcp_input.= p is empty. > > > > > > I ignored all record chain (m_nextpkt) related code. The details is= explained at > > > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > > > > > > Once the tcp_input code is tested, I will submit the patch to bugs@= freebsd.org. > > > I may submit the patch regardless if tcp_input code works or not, b= ecause the > > > tcp > > > sender (server) is more important in high-speed network than the re= ceiver > > > (client). > > > > > > It is appreciated if any one can verify the patch and provide feedb= ack. > > > > OK. I have now tried this patch on a newly-installed 4.8R. The patch > > applied fine. When the sysctl net.inet.tcp.liondmask is unset, everyt= hing > > seems OK, but when setting it to 7 (as specified with the patch > > instructions) i get: > > > > Fatal trap 12: page fault while in kernel mode. > > (I could write down all the stuff on addresses etc if it makes sens= e) > > > > when I run ttcp to test the performance. > > > > This is repeatable. > > > > I'm willing to test more, if someone provides me with some hints on w= hat > > to do. > > > > --B=F6rje > = From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 11:25:21 2003 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 DCB0537B401 for ; Sat, 19 Apr 2003 11:25:21 -0700 (PDT) Received: from x12.dk (xforce.dk [80.62.90.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4924C43FDD for ; Sat, 19 Apr 2003 11:25:20 -0700 (PDT) (envelope-from xride@x12.dk) Received: from x12.dk (xride@localhost [127.0.0.1]) by x12.dk (8.12.8/8.12.8) with ESMTP id h3JIPDS9049479; Sat, 19 Apr 2003 20:25:13 +0200 (CEST) (envelope-from xride@x12.dk) Received: from localhost (xride@localhost) by x12.dk (8.12.8/8.12.8/Submit) with ESMTP id h3JIPBOY049476; Sat, 19 Apr 2003 20:25:12 +0200 (CEST) Date: Sat, 19 Apr 2003 20:25:07 +0200 (CEST) From: Soeren Straarup To: Fabio Miranda Hamburger In-Reply-To: Message-ID: <20030419202405.M42371-100000@x12.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: FreeBsd-hackers@freebsd.org Subject: RE: honest 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, 19 Apr 2003 18:25:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 15 Apr 2003, Fabio Miranda Hamburger wrote: > > >The problem is Xfree86 just support 24 bit color quality, and > > >vmware under > > >freebsd is still bogus, the apm feature doesnt work. > > > > Did you add the following line in your kernel file? > > device apm0 at nexus? flags 0x20 # Advanced Power Managemen= t > > > > Any specific errors/behavior? or Did you try the bios to disable the po= wer management? > > > > I don't have the your make and model laptop, but been very successful i= n doing apm on many machines, even when XP says "now you can turn the compu= ter off" after issuing shutdown :-). > > > > Each laptop has slightly different attitude towards power management, b= ut I am sure you'd be able to find some help on the freebsd mailing list an= d/or "googling" it. > > I have done all that, They apm status info says that is unable to get > status. > > > >Okey, to be honest i like freebsd but I am affraid freebsd is > > >not an ideal > > >os for a laptop. > > >What u guys think? > > >I dont like linux, but I am forced to switch, what u think? > > > Have you updated the /usr/ports? Although Xfree86 is not as simple as = it should be, however, have had very little problem with compiling it from = source or installing it from CD. > > > > What has worked for me is "portupgrade" that automatically upgrades my = ports with little hassle. > > I keep my system updated in -stable branch. > XFree86 doesnt take advantage of my high resolution I only see 24 bits > true color. > > FreeBSD should be able to run on laptops, i like freebsd style. Well it would, but it need man hours and someone has to donate them. > > _______________________________________________ > 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= " > Best regards S=F8ren. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+oZSHXTGeGCdlN14RAkURAKCXU9wNSxWFmdg7ip5JxKol6FrCjACfV6KQ MTJWAWg6VpALnZ7Gde5cqXM=3D =3Dk+wM -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 11:52:42 2003 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 5DB0F37B401 for ; Sat, 19 Apr 2003 11:52:42 -0700 (PDT) Received: from gateh.kw.bbc.co.uk (gateh.kw.bbc.co.uk [132.185.132.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id F10FC43FDF for ; Sat, 19 Apr 2003 11:52:40 -0700 (PDT) (envelope-from damiony@rd.bbc.co.uk) Received: from sunf8 ([132.185.128.108]) by gateh.kw.bbc.co.uk (8.11.2/8.11.2) with ESMTP id h3JIqdS09957 for ; Sat, 19 Apr 2003 19:52:39 +0100 (BST) Received: from damiony (helo=localhost) by sunf8 with local-esmtp (Exim 3.33 #11) id 196xS4-0003IL-00 for hackers@freebsd.org; Sat, 19 Apr 2003 19:52:40 +0100 Date: Sat, 19 Apr 2003 19:52:40 +0100 (BST) From: Damion Yates X-X-Sender: damiony@sunf8 To: hackers@freebsd.org Message-ID: Subject: Fixes to a weird de0: Digital 21041 Ethernet 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, 19 Apr 2003 18:52:42 -0000 Hi, I've recently tried to sort my dec tulip card out under a stock FreeBSD4.8 install (It also didn't work in 5.0). The boot up would find it but fail to like it: Apr 6 12:14:25 /kernel: de0: port 0x1000-0x107f mem 0xd0004800-0xd000487f irq 11 at device 13.0 on pci0 Apr 6 12:14:25 /kernel: de0: can't read ENET ROM (why=-4) (0000000000000000ffff000000000000000001010000c03e9cd4001e00000008 Apr 6 12:14:25 /kernel: de0: 21041 [10Mb/s] pass 1.1 Apr 6 12:14:25 /kernel: de0: address unknown After taking a look in the src for this in: /usr/src/sys/pci/if_de.c I started pissing around removing some of the checks to force it to thing it was happy. I thought this was highly unlikely to work as I'd assumed that all of the complex part about being an ethernet driver wouldn't just rely on the card being happy at boot time as far as the kernel was concerned. However after turning off two main checks in tulip_read_macaddr() and hard wiring the ethernet address (which you can actually see above in the ENET ROM). The resulting build actually worked fine! I was pretty surprised. I've got the diff below, it's just commenting two blocks and manually setting the ethernet address (the bcopy above fails). Near that section of code are several workarounds for known weird variations of the 21041, I can only guess that mine is yet another weird variation that needs to be worked around. Sadly my C is utter bollocks (it's been years, I shouldn't try and make excuses really). I'll happily try some patches to better match my style of card (checking various parts of the ROM string 0000000000000000ffff000000000000000001010000c03e9cd4001e00000008 perhaps) and make this a generic fix. Thanks for any response I get, Damion pants# diff -u if_de.c* --- if_de.c Sat Apr 19 19:08:36 2003 +++ if_de.c-orig Sat Apr 19 19:14:19 2003 @@ -2812,29 +2812,20 @@ * ZNYX?) (well sometimes they put in a checksum so we'll * start at 8). */ -/* DMY */ -/* for (idx = 8; idx < 32; idx++) { + for (idx = 8; idx < 32; idx++) { if (sc->tulip_rombuf[idx] != 0xFF) return -4; - } */ + } /* * Make sure the address is not multicast or locally assigned * that the OUI is not 00-00-00. */ -/* DMY */ - /* if ((sc->tulip_rombuf[0] & 3) != 0) + if ((sc->tulip_rombuf[0] & 3) != 0) return -4; if (sc->tulip_rombuf[0] == 0 && sc->tulip_rombuf[1] == 0 && sc->tulip_rombuf[2] == 0) - return -4; */ + return -4; bcopy(sc->tulip_rombuf, sc->tulip_enaddr, 6); -/* DMY */ - sc->tulip_enaddr[0] = 0x00; - sc->tulip_enaddr[1] = 0x00; - sc->tulip_enaddr[2] = 0xc0; - sc->tulip_enaddr[3] = 0x3e; - sc->tulip_enaddr[4] = 0x9c; - sc->tulip_enaddr[5] = 0xd4; sc->tulip_features |= TULIP_HAVE_OKROM; goto check_oui; } else { @@ -5273,8 +5264,6 @@ 33MHz that comes to two microseconds but wait a bit longer anyways) */ -/* DMY */ - /* if ((retval = tulip_read_macaddr(sc)) < -4) { */ if ((retval = tulip_read_macaddr(sc)) < 0) { printf("%s%d", sc->tulip_name, sc->tulip_unit); printf(": can't read ENET ROM (why=%d) (", retval); pants# After this patch: pants# ifconfig de0: flags=8843 mtu 1500 inet 172.29.17.2 netmask 0xffffff00 broadcast 172.29.17.255 inet6 fe80::200:c0ff:fe3e:9cd4%de0 prefixlen 64 scopeid 0x1 ether 00:00:c0:3e:9c:d4 media: Ethernet autoselect (10baseT/UTP) status: active lp0: flags=8810 mtu 1500 ed1: flags=8802 mtu 1500 ether 00:00:e8:18:77:10 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 pants# ping 172.29.17.1 PING 172.29.17.1 (172.29.17.1): 56 data bytes 64 bytes from 172.29.17.1: icmp_seq=0 ttl=255 time=1.420 ms 64 bytes from 172.29.17.1: icmp_seq=1 ttl=255 time=1.336 ms ^C pants# dmesg |grep de0 de0: port 0x1000-0x107f mem 0xd0004800-0xd000487f irq 11 at device 13.0 on pci0 de0: SMC 21041 [10Mb/s] pass 1.1 de0: address 00:00:c0:3e:9c:d4 de0: enabling 10baseT port -- Damion Yates - Maiden House, Vanwall Business estate, Maidenhead email: Damion.Yates@bbc.co.uk - phone: +44 (0) 1628 407759 (or ex: 37759) From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 12:07:56 2003 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 DC50E37B401; Sat, 19 Apr 2003 12:07:56 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66AE943FBD; Sat, 19 Apr 2003 12:07:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0234.cvx22-bradley.dialup.earthlink.net ([209.179.198.234] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196xgo-0000Pr-00; Sat, 19 Apr 2003 12:07:55 -0700 Message-ID: <3EA19E3C.661C9A28@mindspring.com> Date: Sat, 19 Apr 2003 12:06:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200304190859.h3J8xNXB016406@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41d8c330c342e87a641950f2c415955ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 19:07:57 -0000 Don Lewis wrote: > Ok, here's a Reader's Digest version of the code in question: > > if (kbp->kb_next == NULL) { > kbp->kb_last = NULL; > if (size > MAXALLOCSAVE) > allocsize = roundup(size, PAGE_SIZE); > else > allocsize = 1 << indx; > npg = btoc(allocsize); > va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags > ); > /* > * Just in case we blocked while allocating memory, > * and someone else also allocated memory for this > * bucket, don't assume the list is still empty. > */ > savedlist = kbp->kb_next; > kbp->kb_next = cp = va + (npg * PAGE_SIZE) - allocsize; > for (;;) { > freep = (struct freelist *)cp; > if (cp <= va) > break; > cp -= allocsize; > freep->next = cp; > } > freep->next = savedlist; Take an interrupt somewhere around here, and have the available entries removed from the freelist by an interrupt level driver. Or take a page fault, and have the same thing happen with page-related metadata coming from the freelist in question. > if (kbp->kb_last == NULL) > kbp->kb_last = (caddr_t)freep; > } > va = kbp->kb_next; > kbp->kb_next = ((struct freelist *)va)->next; [ ... ] > This code bothers me, though, because if allocsize ever happened to not > evenly divide (npg * PAGE_SIZE), the loop termination condition would be > wrong and the end of the previous page (or more) would end up on the > free list. If va were small enough and allocsize were big enough, it > would even be possible to wrap around. That actually can't happen. Basically, the allocators "waste" the ends of pages. See the: if (cp <= va) break; cp -= allocsize; ? The "<= saves you. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 13:56:18 2003 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 146DE37B401 for ; Sat, 19 Apr 2003 13:56:18 -0700 (PDT) Received: from mail1.arcor-ip.de (mail1.arcor-ip.de [145.253.2.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD8143FAF for ; Sat, 19 Apr 2003 13:56:15 -0700 (PDT) (envelope-from Friedemann.Becker@student.uni-tuebingen.de) Received: from chasey (213.23.45.98) by mail1.arcor-ip.de (5.5.034) id 3E1E8763006AF115 for freebsd-hackers@freebsd.org; Sat, 19 Apr 2003 22:56:13 +0200 Date: Sat, 19 Apr 2003 22:56:39 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=) From: Friedemann Becker To: freebsd-hackers@freebsd.org Message-ID: X-X-Sender: zxmxy33@mailserv02.uni-tuebingen.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: blocking nfs call X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Friedemann.Becker@student.uni-tuebingen.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 20:56:18 -0000 I tried to mount /usr/src /usr/obj and /usr/gnats from my home machine on a remote computer, it is a router that hangs on reboot and I have no time to get there soon, so I have to solve it per ssh. The problem is, the calls in mount and umount seem to be blocking calls, and when something goes wrong (appearently it did ;-), mount/umount does never return and can't be killed. this is the ps ax output of the dead processes 14672 ?? D 0:00.01 find /usr -xdev -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm 15833 ?? Is 0:00.12 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t 15907 ?? D 0:14.14 find /usr -xdev -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm 14230 p0- D 0:25.57 umount /usr/obj 15302 p0- D 0:00.05 umount /usr/gnats 19156 p0 D+ 0:00.00 egrep D (bash) 14268 p1- DX 0:00.05 umount /usr/obj 15122 p1- D 0:00.05 mount /usr/obj 15139 p1 Ds 0:00.28 -bash (bash) 15208 p1- D 0:00.05 umount /usr/obj 15211 p1- D 0:00.05 umount -f /usr/obj 15213 p1 Ds+ 0:20.27 -bash (bash) note, that all of them are in D status (blocking disk call), but i'm not sure, if this is convenient for nfs calls. maybe a nfs call should return after a timeout period or something, but all those dead mounts and umounts are rotting since days now. additionally locate.updatedb, periodic/daily, cron and some more are started every day and some of them won't die too. So, what can I do: attaching with gdb does not work - the processes don't respond to interupts while in kernel mode. Every process, trying to access one of the above directories will block too. Friedemann From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 13:59:53 2003 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 C482D37B401 for ; Sat, 19 Apr 2003 13:59:53 -0700 (PDT) Received: from mail1.arcor-ip.de (mail1.arcor-ip.de [145.253.2.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 351EF43FAF for ; Sat, 19 Apr 2003 13:59:53 -0700 (PDT) (envelope-from Friedemann.Becker@student.uni-tuebingen.de) Received: from chasey (213.23.45.98) by mail1.arcor-ip.de (5.5.034) id 3E1E8763006AFCDE for freebsd-hackers@freebsd.org; Sat, 19 Apr 2003 22:59:52 +0200 Date: Sat, 19 Apr 2003 23:00:18 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=) From: Friedemann Becker To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: X-X-Sender: zxmxy33@mailserv02.uni-tuebingen.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: blocking nfs call X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Friedemann.Becker@student.uni-tuebingen.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 20:59:54 -0000 On Sat, 19 Apr 2003, Friedemann Becker wrote some stuff I forgot to mention: FreeBSD cleff.sand 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 14 21:23:26 GMT 2002 murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC i386 I was trying to update to 5.0, but I did not get past the nfs-mounts, so this shouldn't be too important to know :) Friedemann From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 14:56:22 2003 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 4D63637B401 for ; Sat, 19 Apr 2003 14:56:22 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 664A643F93 for ; Sat, 19 Apr 2003 14:56:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3JLuDXB019980; Sat, 19 Apr 2003 14:56:17 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304192156.h3JLuDXB019980@gw.catspoiler.org> Date: Sat, 19 Apr 2003 14:56:13 -0700 (PDT) From: Don Lewis To: tlambert2@mindspring.com In-Reply-To: <3EA19E3C.661C9A28@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 21:56:22 -0000 On 19 Apr, Terry Lambert wrote: > Don Lewis wrote: >> Ok, here's a Reader's Digest version of the code in question: >> >> if (kbp->kb_next == NULL) { >> kbp->kb_last = NULL; >> if (size > MAXALLOCSAVE) >> allocsize = roundup(size, PAGE_SIZE); >> else >> allocsize = 1 << indx; >> npg = btoc(allocsize); >> va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags >> ); >> /* >> * Just in case we blocked while allocating memory, >> * and someone else also allocated memory for this >> * bucket, don't assume the list is still empty. >> */ >> savedlist = kbp->kb_next; >> kbp->kb_next = cp = va + (npg * PAGE_SIZE) - allocsize; >> for (;;) { >> freep = (struct freelist *)cp; >> if (cp <= va) >> break; >> cp -= allocsize; >> freep->next = cp; >> } >> freep->next = savedlist; > > Take an interrupt somewhere around here, and have the available > entries removed from the freelist by an interrupt level driver. > > Or take a page fault, and have the same thing happen with > page-related metadata coming from the freelist in question. How can an interrupt or another process touch the freelist while we're protected by splmem()? If that were possible, the block could be stolen out from under us in the code below between the assignment to va and the update of kbb->kb_next, allocating the same block of memory to two different consumers. >> if (kbp->kb_last == NULL) >> kbp->kb_last = (caddr_t)freep; >> } >> va = kbp->kb_next; >> kbp->kb_next = ((struct freelist *)va)->next; > > [ ... ] > >> This code bothers me, though, because if allocsize ever happened to not >> evenly divide (npg * PAGE_SIZE), the loop termination condition would be >> wrong and the end of the previous page (or more) would end up on the >> free list. If va were small enough and allocsize were big enough, it >> would even be possible to wrap around. > > That actually can't happen. Basically, the allocators "waste" > the ends of pages. See the: > > if (cp <= va) > break; > cp -= allocsize; > > ? The "<= saves you. It only works because allocsize evenly divides npg*PAGE_SIZE. If there was a heavy consumer of 129 byte blocks, someone might get the bright idea to allocate a special bucket for them because a lot more 129 byte blocks fit in a page than 256 byte blocks. As the "for" loop iterated, we'd get to the point where va < cp < va + allocsize. The "<=" test would pass, we'd decrement cp, causing it to be less than va, do the freep->next = cp; assignment, return to the top of the "for" loop, do the freep = (struct freelist *)cp; assignment, so that freep now points outside the block of memory allocated by kmem_malloc(). Now the "<=" test will kick us out of the loop and we'll do the freep->next = savedlist; assignment and stomping on someone else's memory. A safer, but slightly more expensive test would be cp < va + allocsize From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 15:15:33 2003 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 9DB1D37B401 for ; Sat, 19 Apr 2003 15:15:33 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5A4F43FE3 for ; Sat, 19 Apr 2003 15:15:32 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3JMFKXB020012; Sat, 19 Apr 2003 15:15:25 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304192215.h3JMFKXB020012@gw.catspoiler.org> Date: Sat, 19 Apr 2003 15:15:20 -0700 (PDT) From: Don Lewis To: Dmitry Sivachenko In-Reply-To: <200304192156.h3JLuDXB019980@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 22:15:33 -0000 Dmitry, If you still have the core and kernel files, I'd appreciate it if you could point gdb at them and print the following stuff from the malloc() stack frame. indx &bucket[0] kbp *kpb allocsize npg cp freep *freep va From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 15:25:28 2003 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 2562F37B401 for ; Sat, 19 Apr 2003 15:25:28 -0700 (PDT) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 819DA43FE1 for ; Sat, 19 Apr 2003 15:25:27 -0700 (PDT) (envelope-from brucem@cruzio.com) Received: from cruzio.com (dsl3-63-249-85-132.cruzio.com [63.249.85.132]) by mail.cruzio.com with ESMTP id h3JMSJjM078656 for ; Sat, 19 Apr 2003 15:28:19 -0700 (PDT) Received: (from brucem@localhost) by cruzio.com (8.12.6/8.12.6/Submit) id h3JMOIXb000930 for freebsd-hackers@freebsd.org; Sat, 19 Apr 2003 15:24:18 -0700 (PDT) Date: Sat, 19 Apr 2003 15:24:18 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200304192224.h3JMOIXb000930@cruzio.com> To: freebsd-hackers@freebsd.org Subject: ohci usb isochronous xfers (abort panic, start) 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, 19 Apr 2003 22:25:28 -0000 The following patch fixes two problems with the usb ohci driver and isochrous transfers: 1) Isochronous transfers are never started; 2) if an application conducting isochronous transfers is aborted (ctrl-C), a kernel panic occurs. The routine "ohci.c/ohci_device_isoc_start()" never sets the bit in the EndPoint descriptor that allows isochronous TDs to be processed by the controller (that is, it never `starts the device'). There is a comment in the code suggesting this was an unclear issue. The abort code in "ohci_device_isoc_abort()" and the code in "ohci_device_isoc_done()" do not check for the case (apparently common) in which there are no ITDs attached to the relevant xfer structure (and this panic). If there is anyone that could check this, that would be great. Even better, if anyone has advice on working with ohci isochronous transfers (especially without a usb analyzer)... I don't see how the current code could ever do isochronous transfers on an OHCI usb controller. My `test device' is an "OmniVision OV511+ Camera" (actually a D-Link DSB-C100), known to work with uhci usb controllers. With the patched code, the application ("vid") reads the input stream, identifies the image header in the data stream, and reads about 20 frames before things just quit. No errors or anything, just no more data. Any advice most appreciated! The patch: ==================================== --- /usr/src/sys/dev/usb/ohci.c.old Sat Apr 19 06:45:25 2003 +++ /usr/src/sys/dev/usb/ohci.c Sat Apr 19 09:22:14 2003 @@ -3340,6 +3340,7 @@ { struct ohci_pipe *opipe = (struct ohci_pipe *)xfer->pipe; ohci_softc_t *sc = (ohci_softc_t *)opipe->pipe.device->bus; + ohci_soft_ed_t *sed; DPRINTFN(5,("ohci_device_isoc_start: xfer=%p\n", xfer)); @@ -3353,6 +3354,9 @@ /* XXX anything to do? */ + sed = opipe->sed; /* Turn off ED skip-bit to start processing */ + sed->ed.ed_flags &= htole32(~OHCI_ED_SKIP); /* ED's ITD list.*/ + return (USBD_IN_PROGRESS); } @@ -3391,11 +3395,14 @@ return; } #endif - for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if ( sitd ) { /* Only if xfer has ITDs. */ + for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if ( sitd == NULL ) break; #ifdef DIAGNOSTIC DPRINTFN(1,("abort sets done sitd=%p\n", sitd)); sitd->isdone = 1; #endif + } } splx(s); @@ -3407,7 +3414,9 @@ /* Run callback. */ usb_transfer_complete(xfer); - sed->ed.ed_headp = htole32(sitd->physaddr); /* unlink TDs */ + if ( sitd ) { /* Only if there is an ITD... */ + sed->ed.ed_headp = htole32(sitd->physaddr); /* unlink TDs */ + } sed->ed.ed_flags &= htole32(~OHCI_ED_SKIP); /* remove hardware skip */ splx(s); @@ -3421,6 +3430,8 @@ ohci_soft_itd_t *sitd, *nsitd; DPRINTFN(1,("ohci_device_isoc_done: xfer=%p\n", xfer)); + + if( 0 == xfer->hcpriv ) return; /* Only if xfer has ITDs.*/ for (sitd = xfer->hcpriv; !(sitd->flags & OHCI_CALL_DONE); From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 16:47:49 2003 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 957A837B401; Sat, 19 Apr 2003 16:47:49 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 335FB43FD7; Sat, 19 Apr 2003 16:47:48 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3JNleVh070931; Sun, 20 Apr 2003 01:47:40 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 20 Apr 2003 01:47:40 +0200 (CEST) From: Martin Blapp To: hackers@freebsd.org In-Reply-To: <20030418132152.X6156@cvs.imp.ch> Message-ID: <20030420014419.T95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: imp@imp.com Subject: Re: [PATCH] dhclient active interface detection patch 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, 19 Apr 2003 23:47:49 -0000 Hi all, The previous version of the code contained a bug. It only worked for the first interface of a host because state_link() did return too early. I fixed this. I uploaded a fixed patch to the same URL as before. http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling.diff Martin From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 16:51:46 2003 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 7D6E637B401; Sat, 19 Apr 2003 16:51:46 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE7B343FA3; Sat, 19 Apr 2003 16:51:45 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0077.cvx40-bradley.dialup.earthlink.net ([216.244.42.77] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19727T-0000ry-00; Sat, 19 Apr 2003 16:51:45 -0700 Message-ID: <3EA1E0C4.F097ADBA@mindspring.com> Date: Sat, 19 Apr 2003 16:50:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200304192156.h3JLuDXB019980@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49862cec7e0c614debcc007437d5d55e6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -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, 19 Apr 2003 23:51:46 -0000 Don Lewis wrote: > > Take an interrupt somewhere around here, and have the available > > entries removed from the freelist by an interrupt level driver. > > > > Or take a page fault, and have the same thing happen with > > page-related metadata coming from the freelist in question. > > How can an interrupt or another process touch the freelist while we're > protected by splmem()? If that were possible, the block could be stolen > out from under us in the code below between the assignment to va and the > update of kbb->kb_next, allocating the same block of memory to two > different consumers. Personally, I think it's a page fault. In any case, the stack traces were posted about 02 Apr 2003, and the patch fixes the problem empirically, so we can argue about why, or we can fix the problem for everyone. > > if (cp <= va) > > break; > > cp -= allocsize; > > > > ? The "<= saves you. > > It only works because allocsize evenly divides npg*PAGE_SIZE. Yes. > If there was a heavy consumer of 129 byte blocks, someone might get > the bright idea to allocate a special bucket for them because a lot > more 129 byte blocks fit in a page than 256 byte blocks. As the > "for" loop iterated, we'd get to the point where va < cp < va + > allocsize. The "<=" test would pass, we'd decrement cp, causing it > to be less than va, do the > freep->next = cp; > assignment, return to the top of the "for" loop, do the > freep = (struct freelist *)cp; > assignment, so that freep now points outside the block of memory > allocated by kmem_malloc(). Now the "<=" test will kick us out of the > loop and we'll do the > freep->next = savedlist; > assignment and stomping on someone else's memory. Yes. 8-). I did exactly this, in fact, at Clickarray, though I rounded to an 8 byte alignment boundary. The way I did it was to figure out the minimal number of pages to allocate at one time that resulted in an even number of structures. This actually saved a hell of a lot of RAM. This is the method I described in my first response to you. 8-). > A safer, but slightly > more expensive test would be > cp < va + allocsize This is really painful, actually. You can lose a full object per page doing this. It also makes the coelesce logic almost incomprehensible (at least in the implementation I tried). -- Tery From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 16:55:17 2003 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 BE79237B401; Sat, 19 Apr 2003 16:55:17 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 397C343F3F; Sat, 19 Apr 2003 16:55:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0077.cvx40-bradley.dialup.earthlink.net ([216.244.42.77] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1972At-0001Pa-00; Sat, 19 Apr 2003 16:55:16 -0700 Message-ID: <3EA1E193.F974C378@mindspring.com> Date: Sat, 19 Apr 2003 16:53:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200304192215.h3JMFKXB020012@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49862cec7e0c614de070090903125d4c3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: hackers@FreeBSD.org cc: Dmitry Sivachenko Subject: Re: Repeated similar panics on -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, 19 Apr 2003 23:55:18 -0000 Don Lewis wrote: > > Dmitry, > > If you still have the core and kernel files, I'd appreciate it if you > could point gdb at them and print the following stuff from the malloc() > stack frame. > > indx > &bucket[0] > kbp > *kpb > allocsize > npg > cp > freep > *freep > va This is a good question. FWIW, Dmitry is the main guy for whom the patch has been working for 2 weeks now (he's the main guy for which the panic repeats). 8-). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 17:46:49 2003 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 7E08437B401; Sat, 19 Apr 2003 17:46:49 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8D6443FBD; Sat, 19 Apr 2003 17:46:45 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K0kfC2052304; Sun, 20 Apr 2003 04:46:42 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K0kdjN052299; Sun, 20 Apr 2003 04:46:39 +0400 (MSD) Date: Sun, 20 Apr 2003 04:46:39 +0400 From: Alex Semenyaka To: freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20030420004639.GA52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.4i Subject: tjr@@freebsd.org, imp@freebsd.org, ru@freebsd.org 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, 20 Apr 2003 00:46:50 -0000 Hi, I've heard a lot of recommendation about where I shoud show my patch and the results of performance changes because of it. So I gathered all advices into To: and CC: fields. Sorry, if there are unnecessary addresses (which then?). Also as I was told the final patch I've send as the PR. Brief description what was done: I've chanched the arithmitics in the /bin/= sh =66rom 32 bits to 64 bits. There are some doubts that it conforms to the standards: it does, I have send a quotations to -standards, there were no objections. Couple of people advuces me to use intmax_t and %jd - I've rewr= itten the patch, now there is those species instead of long long and %qd. The last question was performance, I will show the results of measurements below. The patch can be found in the attach to this message or in the PR bin/51171. Also I've added the overflow control to the addition, substraction and multiplication. There is pretty small overhead (see data below) so I decided it harmless. First, here is the processor description in the box I've run the tests. CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 Features=3D0x387f9ff real memory =3D 268435456 (262144K bytes) avail memory =3D 256475136 (250464K bytes) The tests was a set of 12 scripts with the following structure: for x in `jot 300000` do done and operations were "" (just no operation, empty loop), i=3D$(($i+1)), i=3D$(($i+$m)) (here is _two_ variables), i=3D$(($i*1)), i=3D$(($i*$m)), i= =3D$(($i/1)), i=3D$(($i/$m)), i=3D$(($i<<1)), i=3D$(($i<<$m)), i=3D$(($i||1)), i=3D$(($i|= |$m)), i=3D$((~$i)). In the tests with two variables second one ($m) was always eq= ual to 1. Starting value of $i was also 1.` I've run those twelve scripts first with the 64-bit shell without overflow control and compared with 32-bit shell: Test Time Difference Arith. No Old New Abs %% operation ----+----------------+-------------------------------- 0 1.35 1.36 0.04 0.99% no op 1 5.12 5.36 0.72 4.69% i=3D$(($i+1)) 2 5.17 5.43 0.78 5.03% i=3D$(($i+$a)) 3 4.39 4.57 0.55 4.18% i=3D$(($i*1)) 4 4.43 4.64 0.64 4.82% i=3D$(($i*$m)) 5 4.40 4.62 0.67 5.08% i=3D$(($i/1)) 6 4.45 4.68 0.68 5.09% i=3D$(($i/$m)) 7 5.20 6.37 3.51 22.50% i=3D$(($i<<1)) 8 5.25 6.42 3.51 22.27% i=3D$(($i<<$m)) 9 4.52 4.67 0.45 3.32% i=3D$(($i||1)) 10 4.58 4.73 0.44 3.20% i=3D$(($i||$m)) 11 4.30 4.38 0.25 1.94% i=3D$((~$i)) As you can see, even for arithmetic-only script the overhead is not too big except with one case: shift operation. I decided to investigate is it usual script operation. I've went through all scripts I could find in my FreeBSD box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot of them: $ locate .sh | grep '\.sh$' | wc -l 1637 But there was no any script that uses the shift operation. Good, but not enough. I've take the script that uses arithmetics and do some other job, ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop with both (64-bit and 32-bit) shells. As an argument it received empty directory so no work has been done, just run, check pars, found no files, exit. It takes 65.35 seconds in the first case and 65.30 second in the seco= nd one. So the the time that arithmetics takes during the real script execution is too small in comparison to total running time (obviously: arithmetics is in-core calculations while any script usually run some external programs etc, and at least I/O is involved). Then I've run tests with the addition and multiplication to compare 64-bit shells compiled without the overview control and with it. In the last case I've turned that control on by setting corresponding command line option (-O in my patch). Here are results: 1 5.24 5.26 0.08 0.51% 2 5.31 5.34 0.08 0.50% 3 4.53 4.57 0.14 1.03% 4 4.60 4.65 0.14 1.01% You can see, the difference is just negligible.=20 So I hope I've answered all questions were asked about that 64-bit modifica= tion. All apprehensions are, I hope, dismissed. Probably, after the last look of the responsible person it can be committed, am I right? Thanks! SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 18:10:50 2003 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 9572837B401; Sat, 19 Apr 2003 18:10:50 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AC643FE1; Sat, 19 Apr 2003 18:10:46 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1AeC2052397; Sun, 20 Apr 2003 05:10:41 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1Ad4h052396; Sun, 20 Apr 2003 05:10:39 +0400 (MSD) Date: Sun, 20 Apr 2003 05:10:39 +0400 From: Alex Semenyaka To: freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20030420011039.GC52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.4i cc: imp@freebsd.org cc: tjr@freebsd.org Subject: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 01:10:51 -0000 I'm EXTREMELY sorry about the previous wrong posting, just mixed the header fields. Sorry again! Here is the correct one. Especially sorry to those guys whose addresses get into the Subject line. J= ust a mistake, nothing personal :( ---------------------------------------------------------------------------= -- Hi, I've heard a lot of recommendation about where I shoud show my patch and the results of performance changes because of it. So I gathered all advices into To: and CC: fields. Sorry, if there are unnecessary addresses (which then?). Also as I was told the final patch I've send as the PR. Brief description what was done: I've chanched the arithmitics in the /bin/= sh =66rom 32 bits to 64 bits. There are some doubts that it conforms to the standards: it does, I have send a quotations to -standards, there were no objections. Couple of people advuces me to use intmax_t and %jd - I've rewr= itten the patch, now there is those species instead of long long and %qd. The last question was performance, I will show the results of measurements below. The patch can be found in the attach to this message or in the PR bin/51171. Also I've added the overflow control to the addition, substraction and multiplication. There is pretty small overhead (see data below) so I decided it harmless. First, here is the processor description in the box I've run the tests. CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 Features=3D0x387f9ff real memory =3D 268435456 (262144K bytes) avail memory =3D 256475136 (250464K bytes) The tests was a set of 12 scripts with the following structure: for x in `jot 300000` do done and operations were "" (just no operation, empty loop), i=3D$(($i+1)), i=3D$(($i+$m)) (here is _two_ variables), i=3D$(($i*1)), i=3D$(($i*$m)), i= =3D$(($i/1)), i=3D$(($i/$m)), i=3D$(($i<<1)), i=3D$(($i<<$m)), i=3D$(($i||1)), i=3D$(($i|= |$m)), i=3D$((~$i)). In the tests with two variables second one ($m) was always eq= ual to 1. Starting value of $i was also 1.` I've run those twelve scripts first with the 64-bit shell without overflow control and compared with 32-bit shell: Test Time Difference Arith. No Old New Abs %% operation ----+----------------+-------------------------------- 0 1.35 1.36 0.04 0.99% no op 1 5.12 5.36 0.72 4.69% i=3D$(($i+1)) 2 5.17 5.43 0.78 5.03% i=3D$(($i+$a)) 3 4.39 4.57 0.55 4.18% i=3D$(($i*1)) 4 4.43 4.64 0.64 4.82% i=3D$(($i*$m)) 5 4.40 4.62 0.67 5.08% i=3D$(($i/1)) 6 4.45 4.68 0.68 5.09% i=3D$(($i/$m)) 7 5.20 6.37 3.51 22.50% i=3D$(($i<<1)) 8 5.25 6.42 3.51 22.27% i=3D$(($i<<$m)) 9 4.52 4.67 0.45 3.32% i=3D$(($i||1)) 10 4.58 4.73 0.44 3.20% i=3D$(($i||$m)) 11 4.30 4.38 0.25 1.94% i=3D$((~$i)) As you can see, even for arithmetic-only script the overhead is not too big except with one case: shift operation. I decided to investigate is it usual script operation. I've went through all scripts I could find in my FreeBSD box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot of them: $ locate .sh | grep '\.sh$' | wc -l 1637 But there was no any script that uses the shift operation. Good, but not enough. I've take the script that uses arithmetics and do some other job, ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop with both (64-bit and 32-bit) shells. As an argument it received empty directory so no work has been done, just run, check pars, found no files, exit. It takes 65.35 seconds in the first case and 65.30 second in the seco= nd one. So the the time that arithmetics takes during the real script execution is too small in comparison to total running time (obviously: arithmetics is in-core calculations while any script usually run some external programs etc, and at least I/O is involved). Then I've run tests with the addition and multiplication to compare 64-bit shells compiled without the overview control and with it. In the last case I've turned that control on by setting corresponding command line option (-O in my patch). Here are results: 1 5.24 5.26 0.08 0.51% 2 5.31 5.34 0.08 0.50% 3 4.53 4.57 0.14 1.03% 4 4.60 4.65 0.14 1.01% You can see, the difference is just negligible.=20 So I hope I've answered all questions were asked about that 64-bit modifica= tion. All apprehensions are, I hope, dismissed. Probably, after the last look of the responsible person it can be committed, am I right? Thanks! SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 18:14:36 2003 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 31B9837B401; Sat, 19 Apr 2003 18:14:36 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC35143FE1; Sat, 19 Apr 2003 18:14:32 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1ERC2052447; Sun, 20 Apr 2003 05:14:27 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1EOrL052446; Sun, 20 Apr 2003 05:14:25 +0400 (MSD) Date: Sun, 20 Apr 2003 05:14:24 +0400 From: Alex Semenyaka To: threads@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20030420011424.GA52428@snark.ratmir.ru> References: <20030408164614.GA7236@comp.chem.msu.su> <20030409044301.J628@gamplex.bde.org> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> <3E940993.FBAFFD70@mindspring.com> <20030409123431.GD33144@snark.ratmir.ru> <3E94AB82.496681D5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E94AB82.496681D5@mindspring.com> User-Agent: Mutt/1.5.4i cc: "Andrey A. Chernov" cc: Yar Tikhiy Subject: Re: termios & non-blocking I/O 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, 20 Apr 2003 01:14:36 -0000 Hi! On Wed, Apr 09, 2003 at 04:23:46PM -0700, Terry Lambert wrote: >> when MIN>0 and TIME=0. Don't you think the behaviour in the (TIME=0, MIN>0) >> and (TIME>0, MIN=0) should be consistent somehow? > Consistent with what? With each other, see: > The cases are: > > MIN TIME > 1) >0 >0 Interbyte timer; after 1 byte received, timer > is started; if MIN bytes received before timer > is statisfied, return. If another byte is > received, timer is reset; if timer expires, > read is satisfied. > 2) >0 =0 Pending read is not satisfied until MIN bytes > received. > 3) =0 >0 NOT interbyte timer; read is satisfied on a > single byte received or timer expired. > 4) =0 =0 Polling read; available bytes up to number of > requested bytes is returned, and read is always > satisfied. The cases 2) and 3) should be consistent when there is no input data. Now thay are not. > unacceptable. I think it is impossible to implement case #1 correctly > with NBIO enabled, and would convert it to case #4, and implement the > TIME in user space in libc_r. Probably you are right, but that was not the subject of the discussion. > Case #2 is still not correctly handled at all by your proposed change; > libc_r work is required to avoid stalling until input is present; the > correct return on NBIO is pretty obviously "EAGAIN,-1"; HOWEVER, you > may have received *some* input data, but not MIN worth of input data; > returning some number < MIN violates the interface contract; so does > losing the data. That's right as well, of course. Let me remind you that we are discussing the case when there is no input data at all. > Case #3 is a full read timer for one byte; also not correctly handled > in the face of the proposed change. For a TIME=100, we are talking > about stalling all threads for 100 seconds; the correct return is You just left the rest empty, unfortunatelly. But the WHOLE SUBJECT of the discussion is HERE, and my idea is that the correct return is -1/EAGAIN if there is no data. > Case #4 is polling I/O; it's trivial to implement in libc_r. Sure. > Rule of thumb: If it adds latency, which is always annoying; if > it can add an arbitray number of seconds of latency, it's > unacceptable. I never, never, NEVER suggest to add the latency or to block the process in the kernel or something like this. I understand perfectly why is not acceptable. In several letters I wrote my point. Here it is: in the case TIME>0, MIN=0 we in non-blocking mode in the absence of data we should return immidiately, without any blocking (as now, just perfect), but with -1/EAGAIN instead of 0 (as we do now). Because of that 0 we cannot distinguish the legal EOF and just "no data yet" case behind the libc_r. That's it. >> No, sorry, you have missed my point. Sure I do NOT propose to block >> the input when TIME>0. I propose to return -1/EAGAIN (as in the >> MIN>0 case) instead of 0 (as it is done now). That is what I called >> "the second way". And in this case both libc_r and program can >> easely distinct between EOF and nothing-to-read situation and handle >> them properly. Also all other threads will not be stucked. > The problem with this is case #2 with some number of characters less > than MIN. For example, let us propose a MIN of 10, with 3 characters Well it is _another_ problem. The originator had no questions about incomptele block of data for the MIN>0 and waiting data case. It was ok with him. He told about the case MIN=0, TIME>0, no data, non-clocking mode. It is incorrect to return 0 in this case, told he. And I agree with him. ##1 TIME>0 I argue that this is impossible to implement > in the presence of NBIO, since you can not > return both the value of the short read, and > the fact that the timer would result in a > block, simultaneously. Best approach is to > cause an error, EAGAIN,-1. Right! You see? Exactly our point! But NOW it returns just 0. Should be fixed, I think, shouldn't it? :) SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 18:34:05 2003 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 DCE4537B401; Sat, 19 Apr 2003 18:34:05 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53A043F3F; Sat, 19 Apr 2003 18:34:03 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1Y0C2073365; Sun, 20 Apr 2003 05:34:00 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1Y0gn073364; Sun, 20 Apr 2003 05:34:00 +0400 (MSD) Date: Sun, 20 Apr 2003 05:34:00 +0400 From: Alex Semenyaka To: Alex Semenyaka Message-ID: <20030420013400.GB52428@snark.ratmir.ru> References: <20030420011039.GC52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420011039.GC52081@snark.ratmir.ru> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org cc: tjr@freebsd.org cc: imp@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: freebsd-standards@freebsd.org Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 01:34:06 -0000 ...ghmmm... sorry and sorry... and here the patch, it is pretty small: diff -u -r -U 2 -b ../sh.old/Makefile ./Makefile --- ../sh.old/Makefile Sat Apr 19 23:22:31 2003 +++ ./Makefile Sun Apr 20 02:47:41 2003 @@ -19,5 +19,5 @@ LFLAGS= -8 # 8-bit lex scanner for arithmetic -CFLAGS+=-DSHELL -I. -I${.CURDIR} +CFLAGS+=-DSHELL -I. -I${.CURDIR} -DOVERFLOW # for debug: #CFLAGS+= -g -DDEBUG=2 -pg diff -u -r -U 2 -b ../sh.old/arith.h ./arith.h --- ../sh.old/arith.h Fri Jul 19 08:38:51 2002 +++ ./arith.h Sun Apr 20 02:37:37 2003 @@ -35,4 +35,7 @@ */ -int arith(char *); +/* XXX some day probably should go to /usr/include/machine/_inttypes.h */ +#define MAXINT_LEN 20 + +intmax_t arith(char *); int expcmd(int , char **); diff -u -r -U 2 -b ../sh.old/arith.y ./arith.y --- ../sh.old/arith.y Fri Jul 19 08:38:51 2002 +++ ./arith.y Sun Apr 20 03:52:31 2003 @@ -1,2 +1,13 @@ +%{ +#include +#ifdef OVERFLOW +#include "options.h" +#endif + +#define YYSTYPE intmax_t + +static intmax_t arith_res; +%} + %token ARITH_NUM ARITH_LPAREN ARITH_RPAREN @@ -15,5 +26,6 @@ exp: expr = { - return ($1); + arith_res = $1; + return (0); } ; @@ -34,7 +46,25 @@ | expr ARITH_LSHIFT expr = { $$ = $1 << $3; } | expr ARITH_RSHIFT expr = { $$ = $1 >> $3; } - | expr ARITH_ADD expr = { $$ = $1 + $3; } - | expr ARITH_SUB expr = { $$ = $1 - $3; } - | expr ARITH_MUL expr = { $$ = $1 * $3; } + | expr ARITH_ADD expr = { + $$ = $1 + $3; +#ifdef OVERFLOW + if (Oflag && is_add_overflow($1, $3, $$)) + yyerror("overflow in"); +#endif + } + | expr ARITH_SUB expr = { + $$ = $1 - $3; +#ifdef OVERFLOW + if (Oflag && is_add_overflow($1, -$3, $$)) + yyerror("overflow in"); +#endif + } + | expr ARITH_MUL expr = { + $$ = $1 * $3; +#ifdef OVERFLOW + if (Oflag && $$/$1 != $3 ) + yyerror("overflow in"); +#endif + } | expr ARITH_DIV expr = { if ($3 == 0) @@ -110,16 +140,24 @@ int -arith(char *s) +is_add_overflow(intmax_t a, intmax_t b, intmax_t s) { - long result; + if (a > 0 && b > 0 && s <= 0) + return 1; + if (a < 0 && b < 0 && s >= 0) + return 1; + return 0; +} +intmax_t +arith(char *s) +{ arith_buf = arith_startbuf = s; INTOFF; - result = yyparse(); + yyparse(); arith_lex_reset(); /* reprime lex */ INTON; - return (result); + return (arith_res); } @@ -143,5 +181,5 @@ char *concat; char **ap; - long i; + intmax_t i; if (argc > 1) { @@ -168,5 +206,5 @@ i = arith(p); - out1fmt("%ld\n", i); + out1fmt("%jd\n", i); return (! i); } diff -u -r -U 2 -b ../sh.old/arith_lex.l ./arith_lex.l --- ../sh.old/arith_lex.l Fri Jul 19 08:38:51 2002 +++ ./arith_lex.l Sun Apr 20 02:37:37 2003 @@ -44,8 +44,9 @@ #endif /* not lint */ +#include #include "y.tab.h" #include "error.h" -extern int yylval; +extern intmax_t yylval; extern char *arith_buf, *arith_startbuf; #undef YY_INPUT @@ -57,5 +58,5 @@ %% [ \t\n] { ; } -[0-9]+ { yylval = atol(yytext); return(ARITH_NUM); } +[0-9]+ { yylval = strtoll(yytext, NULL, 10); return(ARITH_NUM); } "(" { return(ARITH_LPAREN); } ")" { return(ARITH_RPAREN); } diff -u -r -U 2 -b ../sh.old/expand.c ./expand.c --- ../sh.old/expand.c Fri Jan 17 14:37:03 2003 +++ ./expand.c Sun Apr 20 02:37:37 2003 @@ -46,4 +46,5 @@ #include #include +#include #include #include @@ -367,5 +368,5 @@ { char *p, *start; - int result; + intmax_t result; int begoff; int quotes = flag & (EXP_FULL | EXP_CASE | EXP_REDIR); @@ -383,8 +384,8 @@ * characters have to be processed left to right. */ -#if INT_MAX / 1000000000 >= 10 || INT_MIN / 1000000000 <= -10 -#error "integers with more than 10 digits are not supported" -#endif - CHECKSTRSPACE(12 - 2, expdest); +//#if INT_MAX / 1000000000 >= 10 || INT_MIN / 1000000000 <= -10 +//#error "integers with more than 10 digits are not supported" +//#endif + CHECKSTRSPACE(MAXINT_LEN, expdest); USTPUTC('\0', expdest); start = stackblock(); @@ -408,5 +409,5 @@ rmescapes(p+2); result = arith(p+2); - fmtstr(p, 12, "%d", result); + fmtstr(p, MAXINT_LEN + 2, "%qd", result); while (*p++) ; diff -u -r -U 2 -b ../sh.old/options.h ./options.h --- ../sh.old/options.h Tue Aug 27 05:36:28 2002 +++ ./options.h Sun Apr 20 02:24:46 2003 @@ -67,6 +67,13 @@ #define Tflag optlist[16].val #define Pflag optlist[17].val +#ifdef OVERFLOW +#define Oflag optlist[18].val +#endif +#ifdef OVERFLOW +#define NOPTS 19 +#else #define NOPTS 18 +#endif struct optent { @@ -96,4 +103,7 @@ { "trapsasync", 'T', 0 }, { "physical", 'P', 0 }, +#ifdef OVERFLOW + { "overflow", 'O', 0 }, +#endif }; #else diff -u -r -U 2 -b ../sh.old/sh.1 ./sh.1 --- ../sh.old/sh.1 Tue Feb 25 13:27:12 2003 +++ ./sh.1 Sun Apr 20 02:52:02 2003 @@ -44,5 +44,5 @@ .Sh SYNOPSIS .Nm -.Op Fl /+abCEefIimnPpsTuVvx +.Op Fl /+abCEefIimnOPpsTuVvx .Op Fl /+o Ar longname .Op Fl c Ar string @@ -226,4 +226,6 @@ execute them. This is useful for checking the syntax of shell scripts. +.It Fl O Li interactive +If compiled with the overflow checks, turn them during arithmetic operations on. .It Fl P Li physical Change the default for the From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 19:17:53 2003 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 26A8B37B401 for ; Sat, 19 Apr 2003 19:17:53 -0700 (PDT) Received: from web21509.mail.yahoo.com (web21509.mail.yahoo.com [66.163.169.58]) by mx1.FreeBSD.org (Postfix) with SMTP id CBD8243FE0 for ; Sat, 19 Apr 2003 19:17:52 -0700 (PDT) (envelope-from rmhlldr@yahoo.co.uk) Message-ID: <20030420021752.13758.qmail@web21509.mail.yahoo.com> Received: from [194.44.215.99] by web21509.mail.yahoo.com via HTTP; Sun, 20 Apr 2003 03:17:52 BST Date: Sun, 20 Apr 2003 03:17:52 +0100 (BST) From: =?iso-8859-1?q?RMH?= To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: low-level routines X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rhett@alasir.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 02:17:53 -0000 Hello gentlemen, could you point me to some function(s) used by FreeBSD to read\write values from\to hardware ports? I remember outp\inp (or outportb\inportb for Borland Turbo C) from DOS times, but these of course don't work for UNIX... --- Regards, Rhett P.S. Please keep me in cc: because I'm not subscribed to this list. __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 20:58:22 2003 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 8532037B401; Sat, 19 Apr 2003 20:58:22 -0700 (PDT) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9522B43FBD; Sat, 19 Apr 2003 20:58:21 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id h3K301o1000382; Sat, 19 Apr 2003 20:00:02 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3EA20D31.2606389B@lbl.gov> Date: Sat, 19 Apr 2003 20:00:01 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: bj@dc.luth.se References: <200304191305.h3JD5S2F026929@dc.luth.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) 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, 20 Apr 2003 03:58:23 -0000 Not yet. I said I will send out email when it is ready. The problem is we have a significantly modified system based on 4.8-RC2. I tried to extract the only sockbut/mbuf code, but it apparently, the patch is in completed for pure 4.8 system. Somehow, it have some depenency of our new TCP stack. So, I am building two new systems, one pure 4.7 and one pure 4.8. I will extract correct patch for these system, test them, then send out another email. Thanks for the patient. -Jin Borje Josefsson wrote: > Hmm. I'm not sure if I misunderstood if this was ready for another test > run or not. Anyhow - I took the new patch .tgz (which, btw, still had > tcp_input.p in it). I applied the patches (except tcp_input) and tested. > > Now I get: > > Panic: bad cur_off > 00000 m_p 0xc0a7f400 0xc0a7f400 my_off 0 1448 cc 3407144 > > As usual, I'm willing to test more when there are an update available. > > --Börje > > On Fri, 18 Apr 2003 13:04:24 PDT "Jin Guojun [DSD]" wrote: > > > Opps, there was a bad file -- tcp_input.p -- which is not working yet. > > Also, a patch file -- tcp_usrreq.p -- was missing. > > > > I will take the tcp_input.p out and put tcp_usrreq.p in. > > When it is finished, I will send another mail out. > > > > -Jin > > > > Borje Josefsson wrote: > > > > > On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > > > > > > > I have modified the sockbuf and mbuf operation to double the throughput over > > > > high bandwidth delay product path. > > > > > > > > The patch is available at: > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > > > > > The current modification is for tcp transmission only. > > > > > > > > I have adapted some code of uipc_socket2.c from Sam Leffler > > > > http://www.freebsd.org/~sam/thorpe-stable.patch > > > > > > > > for tcp receiver, but it has not been tested yet, so the tcp_input.p is empty. > > > > > > > > I ignored all record chain (m_nextpkt) related code. The details is explained at > > > > > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > > > > > > > > Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. > > > > I may submit the patch regardless if tcp_input code works or not, because the > > > > tcp > > > > sender (server) is more important in high-speed network than the receiver > > > > (client). > > > > > > > > It is appreciated if any one can verify the patch and provide feedback. > > > > > > OK. I have now tried this patch on a newly-installed 4.8R. The patch > > > applied fine. When the sysctl net.inet.tcp.liondmask is unset, everything > > > seems OK, but when setting it to 7 (as specified with the patch > > > instructions) i get: > > > > > > Fatal trap 12: page fault while in kernel mode. > > > (I could write down all the stuff on addresses etc if it makes sense) > > > > > > when I run ttcp to test the performance. > > > > > > This is repeatable. > > > > > > I'm willing to test more, if someone provides me with some hints on what > > > to do. > > > > > > --Börje