From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 5 00:10:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B7ABD16A420 for ; Sun, 5 Mar 2006 00:10:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7679143D48 for ; Sun, 5 Mar 2006 00:10:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 4A6E11A4E21; Sat, 4 Mar 2006 16:10:36 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9B43C51456; Sat, 4 Mar 2006 19:10:35 -0500 (EST) Date: Sat, 4 Mar 2006 19:10:35 -0500 From: Kris Kennaway To: "Carlos Silva, yourdot-internet.com" Message-ID: <20060305001035.GA63876@xor.obsecurity.org> References: <440A1F98.2000304@yourdot-mail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <440A1F98.2000304@yourdot-mail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: make error :| X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 00:10:36 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 04, 2006 at 11:15:36PM +0000, Carlos Silva, yourdot-internet.co= m wrote: > Hi, >=20 > i have upgraded my ports with cvsup and when installing samba i have the= =20 > following error: >=20 > " ... > Building for libtool-1.5.22_2 > ..... > Making all in doc > make: don't know how to make libtool14.texi. Stop. > ***Error Code 1 >=20 > .... > " >=20 > someone have any idea? Yes, we heard you the first time (and the second and third time) when you posted on ports@. Please don't abuse the privilege of sending mail to freebsd mailing lists. Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFECix7Wry0BWjoQKURAgESAKCWky81pqNpvExyT7pb+idqogX6DwCeLnHX KPa0rNyfGnGl+g3XaDWjsY4= =hn5O -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 5 00:31:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D663816A420 for ; Sun, 5 Mar 2006 00:31:38 +0000 (GMT) (envelope-from ruselek@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51FC643D45 for ; Sun, 5 Mar 2006 00:31:38 +0000 (GMT) (envelope-from ruselek@gmail.com) Received: by xproxy.gmail.com with SMTP id h26so630060wxd for ; Sat, 04 Mar 2006 16:31:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lQWYl+hRva5W+9gQwFjzmSMzDEGAq+d8Dq0CGLk+kcIhRi8gsexF7R+WnHEmVvWbykAImcaN9jQIX0oW3rDLhp+mo2eq5+ELpBYOCDg9xLaIQbltyyuWoD7B3gGWCgP2sKIjM5MDwIX/tmUlGkeGjUf30AzVWoWJYDLFUGTLfb4= Received: by 10.11.120.36 with SMTP id s36mr53633cwc; Sat, 04 Mar 2006 16:31:36 -0800 (PST) Received: by 10.11.120.76 with HTTP; Sat, 4 Mar 2006 16:31:36 -0800 (PST) Message-ID: <1a8aebce0603041631h2f29eaefy@mail.gmail.com> Date: Sun, 5 Mar 2006 01:31:36 +0100 From: rusel To: "Kris Kennaway" In-Reply-To: <20060305001035.GA63876@xor.obsecurity.org> MIME-Version: 1.0 References: <440A1F98.2000304@yourdot-mail.com> <20060305001035.GA63876@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Carlos Silva, yourdot-internet.com" , freebsd-hackers@freebsd.org Subject: Re: make error :| X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 00:31:38 -0000 upgrade your libtools. Regards. 2006/3/5, Kris Kennaway : > > On Sat, Mar 04, 2006 at 11:15:36PM +0000, Carlos Silva, > yourdot-internet.com wrote: > > Hi, > > > > i have upgraded my ports with cvsup and when installing samba i have th= e > > following error: > > > > " ... > > Building for libtool-1.5.22_2 > > ..... > > Making all in doc > > make: don't know how to make libtool14.texi. Stop. > > ***Error Code 1 > > > > .... > > " > > > > someone have any idea? > > Yes, we heard you the first time (and the second and third time) when > you posted on ports@. Please don't abuse the privilege of sending > mail to freebsd mailing lists. > > Kris > > > -- Artur Grabowski +48 886 787 778 Sys Admin From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 5 14:37:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CF12E16A420 for ; Sun, 5 Mar 2006 14:37:14 +0000 (GMT) (envelope-from gclarkii@vsservices.com) Received: from mailsys.vsservices.com (primus.vsservices.com [204.251.8.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01D8843D49 for ; Sun, 5 Mar 2006 14:37:13 +0000 (GMT) (envelope-from gclarkii@vsservices.com) Received: from localhost (localhost [127.0.0.1]) by mailsys.vsservices.com (Postfix) with ESMTP id 0C052B890 for ; Sun, 5 Mar 2006 07:37:13 -0700 (MST) Received: from mailsys.vsservices.com ([127.0.0.1]) by localhost (primus.vsservices.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00479-01 for ; Sun, 5 Mar 2006 07:37:12 -0700 (MST) Received: from prime (63-224-142-150.phnx.qwest.net [63.224.142.150]) by mailsys.vsservices.com (Postfix) with ESMTP id 6D51EB827 for ; Sun, 5 Mar 2006 07:37:12 -0700 (MST) Date: Sun, 5 Mar 2006 07:37:10 -0700 From: GB Clark To: freebsd-hackers@freebsd.org Message-ID: <20060305073710.0a1b3218@prime> In-Reply-To: <200602240830.42905.flz@xbsd.org> References: <43FDE57A.7040504@citi.umich.edu> <200602240830.42905.flz@xbsd.org> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.12; i386-portbld-freebsd5.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at vsservices.com Subject: Re: wireless on a laptop X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 14:37:14 -0000 On Fri, 24 Feb 2006 08:30:36 +0100 Florent Thoumie wrote: > On Thursday 23 February 2006 17:40, Chuck Lever wrote: > > hi all- > > > > i have a D-Link DWL-G650M PCCard (Atheros) and an IBM T40 laptop. they > > don't want to talk with each other. > > > > the T40 has a built in Aironet, but the driver generates "received 194 > > bytes, expected 196 bytes" messages in the system log, and i can't get > > it to work. > > > > so i bought this Atheros-based super-G card. > > > > the problem is the cardbus infrastructure doesn't seem to recognize the > > card. even if i "kldload if_ath". > > > > i'm new to FreeBSD, so any guidance here would be greatly appreciated. > > Atheros Super-G cards are not (yet?) supported. > > I think your best bet is to use ndis(4) (see ndisgen(8)). > > -- > Florent Thoumie > flz@FreeBSD.org > FreeBSD Committer Greetings, I use a D-Link DWL-G650B2/TP600E combo under FreeBSD 6 with the ath driver and get G+ speeds, but only when I'm connecting to my D-Link AP, though. Note, it is not enough to just do a "kldload if_ath", you have to load the HAL ("kldload ath_hal" and then load the primary driver. Do a "man ath" for the details. GClarkII -- GB Clark II | Roaming FreeBSD Admin gclarkii@VSServices.COM | General Geek CTHULU for President - Why choose the lesser of two evils? From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 5 15:02:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 938F716A420 for ; Sun, 5 Mar 2006 15:02:01 +0000 (GMT) (envelope-from anupamdeshpande@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72BCF43D6E for ; Sun, 5 Mar 2006 15:01:56 +0000 (GMT) (envelope-from anupamdeshpande@gmail.com) Received: by zproxy.gmail.com with SMTP id m7so1061064nzf for ; Sun, 05 Mar 2006 07:01:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tARCSy3LF1AEKYdZGwD5ouwf2zUUrnsF/wQpyTZxDvFInYJhOZtuRamEDUjkTySrXVBgRCNN8dOyyyWrjoyd26wcUZEhfP8knAyzP7I4Blr/Orxyp3e8u9jh1ky0XkBzJnpdHymnzy1/0NBktW2Ig9seL9NSqkvkzbnkWb//a2M= Received: by 10.65.237.9 with SMTP id o9mr2223944qbr; Sun, 05 Mar 2006 07:01:55 -0800 (PST) Received: by 10.64.27.7 with HTTP; Sun, 5 Mar 2006 07:01:55 -0800 (PST) Message-ID: <25da4ac50603050701j3fc63843oe288f6d34b67d115@mail.gmail.com> Date: Sun, 5 Mar 2006 20:31:55 +0530 From: "Anupam Deshpande" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Using open system call in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 15:02:01 -0000 Hello, I have used open system call in KLD to create a file. But after inserting the module the file is not created though the file descriptor returned is non zero. I also used close system call to close the file, usin= g the descriptor returned by open system call. I called the following function from my module: int f_open(void) { struct open_args o; struct close_args c; struct thread *td =3D curthread; int fd; o.path =3D "/home/file1.c"; o.flags =3D O_CREAT | O_RDWR | O_APPEND; o.mode =3D 777; fd =3D open(td,&a); printf("\nFile descriptor =3D %d",fd); c.fd =3D fd; close(td,&c); } Can anyone help me in this regard? TIA, Anupam Deshpande From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 5 17:23:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1854716A420 for ; Sun, 5 Mar 2006 17:23:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B2E243D53 for ; Sun, 5 Mar 2006 17:23:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DD63B46B1D; Sun, 5 Mar 2006 12:23:27 -0500 (EST) Date: Sun, 5 Mar 2006 17:23:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Anupam Deshpande In-Reply-To: <25da4ac50603050701j3fc63843oe288f6d34b67d115@mail.gmail.com> Message-ID: <20060305172046.V51568@fledge.watson.org> References: <25da4ac50603050701j3fc63843oe288f6d34b67d115@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Using open system call in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 17:23:50 -0000 On Sun, 5 Mar 2006, Anupam Deshpande wrote: > I have used open system call in KLD to create a file. But after > inserting the module the file is not created though the file descriptor > returned is non zero. I also used close system call to close the file, using > the descriptor returned by open system call. > I called the following function from my module: > > int f_open(void) > { > struct open_args o; > struct close_args c; > struct thread *td = curthread; > int fd; > o.path = "/home/file1.c"; There are a couple of things going on here: - open() accepts a pointer to a pathname in user address space. If this code is running in kernel, then the above string is in the kernel address space. You probably want to look at kern_open(), which accepts a path pointer and also an address space identifier, which can be set to UIO_SYSSPACE to indicate that the path argument is being copied from a kernel address. - In kernel, system calls return (0) for success, or an error value, not a file descriptor number. This is placed in the thread context return values to be returned to user space. Specifically, in td->td_retval[0]. So you're not checking to make sure the call succeeded, and you're also not getting the file descriptor from the right place. You'll probably find that the value you're getting back is EFAULT, indicating that the path pointer was not valid for a user process. Robert N M Watson > o.flags = O_CREAT | O_RDWR | O_APPEND; > o.mode = 777; > fd = open(td,&a); > printf("\nFile descriptor = %d",fd); > c.fd = fd; > close(td,&c); > } > > > Can anyone help me in this regard? > > TIA, > Anupam Deshpande > _______________________________________________ > 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 Sun Mar 5 18:41:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1A00F16A420 for ; Sun, 5 Mar 2006 18:41:50 +0000 (GMT) (envelope-from pranav.sawargaonkar@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D9B43D45 for ; Sun, 5 Mar 2006 18:41:49 +0000 (GMT) (envelope-from pranav.sawargaonkar@gmail.com) Received: by wproxy.gmail.com with SMTP id i12so1240601wra for ; Sun, 05 Mar 2006 10:41:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=qp8SLMpv5ipYvgSaTilN8kCNjJ2V4eb0QpDHRpPfUKTBaBH7aR9ZZErhY4JejRGW1xgfMtA1NB2Nm4ZyY3K1GkJBYpb68/d/JRIBt1Ywfsd/bPbB3WvkYi6hJ8k/KxsDbY0R3Rmfx6Z9QIMBmLQ4J/GA1j9ch7+AnyuR42ztRds= Received: by 10.54.62.3 with SMTP id k3mr4084352wra; Sun, 05 Mar 2006 10:41:48 -0800 (PST) Received: by 10.54.119.2 with HTTP; Sun, 5 Mar 2006 10:41:47 -0800 (PST) Message-ID: <5007e1a40603051041wc59ae7ar97d71ac3746f611f@mail.gmail.com> Date: Mon, 6 Mar 2006 00:11:47 +0530 From: "Pranav Sawargaonkar" To: anupamdeshpande@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: RE:Using open system call in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 18:41:50 -0000 On 3/5/06, Anupam Deshpande wrote: > > >Hello, > > I have used open system call in KLD to create >a file. But afte= r > >inserting the module the file is not created though >the file descriptor > >returned is non zero. I also used close system call to >close the file, > using > >the descriptor returned by open system call. > > Instead of >int f_open(void) >{ >struct open_args o; >struct close_args c; >struct thread *td =3D curthread; >int fd; >o.path =3D "/home/file1.c"; >o.flags =3D O_CREAT | O_RDWR | O_APPEND; >o.mode =3D 777; >fd =3D open(td,&a); >printf("\nFile descriptor =3D %d",fd); >c.fd =3D fd; >close(td,&c); >} U need to change it to int f_open(void) { struct open_args o; struct close_args c; struct thread *td =3D curthread; int fd; o.path =3D "/home/file1.c"; o.flags =3D O_CREAT | O_RDWR | O_APPEND; o.mode =3D 777; />>/fd =3D open(td,&a); /*Beacuse open passes UIO_USERSPACE and you are using open from KLD thus you need to change it to UIO_SYSSPACE and also need to use kern_open() which is defined in #include as below*/ fd=3Dkern_open(td,o.path, UIO_SYSSPACE, o.flags,o.mode); printf("\nFile descriptor =3D %d",fd); c.fd =3D fd; close(td,&c); } -Pranav Sawargaonkar From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 05:34:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0A70216A420 for ; Mon, 6 Mar 2006 05:34:48 +0000 (GMT) (envelope-from ben@coverity.com) Received: from coverity.dreamhost.com (supmuscle.dreamhost.com [66.33.192.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2503243D75 for ; Mon, 6 Mar 2006 05:34:43 +0000 (GMT) (envelope-from ben@coverity.com) Received: from [10.34.114.75] (unknown [12.153.11.143]) by coverity.dreamhost.com (Postfix) with ESMTP id 90F1E3AAD8 for ; Sun, 5 Mar 2006 21:34:43 -0800 (PST) Message-ID: <440BC9FC.9000209@coverity.com> Date: Sun, 05 Mar 2006 21:34:52 -0800 From: Ben Chelf User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Mar 2006 05:55:54 +0000 Subject: Coverity Open Source Defect Scan of FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ben@coverity.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 05:34:48 -0000 Hello FreeBSD Developers, I'm the CTO of Coverity, Inc., a company that does static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. FreeBSD is one of the 32 projects currently scanned at: http://scan.coverity.com My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results. Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of FreeBSD, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers (or group nominated individuals) reach out to me to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to reach out to me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message. Many thanks for reading this far... -ben Ben Chelf Chief Technology Officer Coverity, Inc. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 09:28:52 2006 Return-Path: X-Original-To: hackers@freebsd.org 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 6CD6A16A420 for ; Mon, 6 Mar 2006 09:28:52 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B01A043D48 for ; Mon, 6 Mar 2006 09:28:38 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id k269fOVO040128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 11:41:28 +0200 (EET) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id EE4415C023; Mon, 6 Mar 2006 11:28:28 +0200 (EET) Date: Mon, 6 Mar 2006 11:28:28 +0200 From: Andrey Simonenko To: Divacky Roman Message-ID: <20060306092828.GA768@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20060304171123.GA37661@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060304171123.GA37661@stud.fit.vutbr.cz> User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/1314/Sat Mar 4 15:39:05 2006 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: hackers@freebsd.org Subject: Re: sched_newthread question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 09:28:52 -0000 On Sat, Mar 04, 2006 at 06:11:24PM +0100, Divacky Roman wrote: > hi, > > sched_newthread(struct thread *td) > { > struct td_sched *ke; > > ke = (struct td_sched *) (td + 1); > bzero(ke, sizeof(*ke)); > td->td_sched = ke; > ke->ke_thread = td; > ke->ke_state = KES_THREAD; > } > > whats the logic behind: > ke = (struct td_sched *) (td + 1); ? > > shouldnt it be: > ke = td -> td_sched; ? > This function does exactly as the comment for it describes. When memory is allocated for struct thread{}, then this memory consists of two parts, one part is for struct thread{} and next part is scheduler specific structure for this thread. To get pointer to that scheduler specific data it is necessary to point to the next byte after struct thread{}. For more detail information see how thread_zone is created and what the sched_sizeof_thread() function returns for each scheduler. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 10:10:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 80E5C16A420 for ; Mon, 6 Mar 2006 10:10:11 +0000 (GMT) (envelope-from anupamdeshpande@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C356543D48 for ; Mon, 6 Mar 2006 10:10:10 +0000 (GMT) (envelope-from anupamdeshpande@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1101329wra for ; Mon, 06 Mar 2006 02:10:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kLbE/yO1AbVf4bnfgGi5FjSMexkfuCWd7HcIUu8E2gdTtYmYXhqQEH9vYksUFKDpj4ryLr8f7E7wUPfTp9aw3s1I8Ru23UvfUGwvwSsOkBGnU6XNSR3+0r7YzK9KNuRkIKheXbb0EV2/qoTUIKFe3AaggaoJ2NFv7fm85q7fCzM= Received: by 10.65.211.10 with SMTP id n10mr2514917qbq; Mon, 06 Mar 2006 02:10:10 -0800 (PST) Received: by 10.64.27.7 with HTTP; Mon, 6 Mar 2006 02:10:10 -0800 (PST) Message-ID: <25da4ac50603060210j1902a751g9e4c615605f9def7@mail.gmail.com> Date: Mon, 6 Mar 2006 02:10:10 -0800 From: "Anupam Deshpande" To: "Robert Watson" In-Reply-To: <20060305172046.V51568@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <25da4ac50603050701j3fc63843oe288f6d34b67d115@mail.gmail.com> <20060305172046.V51568@fledge.watson.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Using open system call in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 10:10:11 -0000 On 3/5/06, Robert Watson wrote: > > On Sun, 5 Mar 2006, Anupam Deshpande wrote: > > > I have used open system call in KLD to create a file. But after > > inserting the module the file is not created though the file descriptor > > returned is non zero. I also used close system call to close the file, > using > > the descriptor returned by open system call. > > I called the following function from my module: > > > > int f_open(void) > > { > > struct open_args o; > > struct close_args c; > > struct thread *td =3D curthread; > > int fd; > > o.path =3D "/home/file1.c"; > > There are a couple of things going on here: > > - open() accepts a pointer to a pathname in user address space. If this > code > is running in kernel, then the above string is in the kernel address > space. > You probably want to look at kern_open(), which accepts a path pointer > and > also an address space identifier, which can be set to UIO_SYSSPACE to > indicate that the path argument is being copied from a kernel address. > > - In kernel, system calls return (0) for success, or an error value, not = a > file descriptor number. This is placed in the thread context return > values > to be returned to user space. Specifically, in td->td_retval[0]. So > you're > not checking to make sure the call succeeded, and you're also not gett= ing > the file descriptor from the right place. You'll probably find that t= he > value you're getting back is EFAULT, indicating that the path pointer = was > not valid for a user process. > > Robert N M Watson > hello, I successfully created a file using kern_open(). Now I want to 'write to' or 'read from' the file.What functions should I use for that purpose? TIA, Anupam From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 10:20:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 17F6816A420 for ; Mon, 6 Mar 2006 10:20:13 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 615ED43D48 for ; Mon, 6 Mar 2006 10:20:11 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by zproxy.gmail.com with SMTP id i11so1201556nzi for ; Mon, 06 Mar 2006 02:20:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=ed90eR5jNwInUve7slZPB7h3SE36vC0/8NeONSc/lAo3O6XrO0X4yJa+opuuBv11f9Y1QZI9fpnJs+NFeVcuX+ZWydrkkDt+OrlFQHTC7voRfveu9rUFOpccZTvMOmS1j5JbGRblF5Lji1tKwDf9VOclyhJ6UwgvbQNKp1tea+E= Received: by 10.36.46.1 with SMTP id t1mr6810087nzt; Mon, 06 Mar 2006 02:20:10 -0800 (PST) Received: by 10.36.41.11 with HTTP; Mon, 6 Mar 2006 02:20:10 -0800 (PST) Message-ID: <3bbf2fe10603060220k3c055092t@mail.gmail.com> Date: Mon, 6 Mar 2006 11:20:10 +0100 From: "Attilio Rao" To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: [patch] Adding optimized kernel copying support to FreeBSD-i386 - Part II X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rookie@gufi.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 10:20:13 -0000 Hi, I did not received too much feedbacks about Part I stability, but I went on= , so Part II is available for tests. It presents an mmx copy which doesn't give much performance increases but what I need now is testing for correctness. In particular I would see feedbacks about races inside dropping/undropping FPU mechanism. It would be better testing with PREEMPTION + FULL_PREEMPTION enabled (and maybe on SMP archs). Some minor styling issues have been fixed of the previous patch. http://users.gufi.org/~rookie/works/patches/mmxcopy.tar.gz This mmx copy is not intended to be in final release, this is just a testin= g issue in order to involve CPU < P4 & friends. For anything else, mail to me. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 10:50:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9692316A420 for ; Mon, 6 Mar 2006 10:50:32 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9752743D45 for ; Mon, 6 Mar 2006 10:50:16 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id k26B3OVO040573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Mar 2006 13:03:24 +0200 (EET) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 83B605C023; Mon, 6 Mar 2006 12:50:29 +0200 (EET) Date: Mon, 6 Mar 2006 12:50:29 +0200 From: Andrey Simonenko To: Tanmay Message-ID: <20060306105029.GA1002@pm513-1.comsys.ntu-kpi.kiev.ua> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/1314/Sat Mar 4 15:39:05 2006 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: Accessing address space of a process through kld!! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 10:50:32 -0000 On Fri, Mar 03, 2006 at 09:26:35PM +0530, Tanmay wrote: > On Tue, Feb 28, 2006 at 01:33:47PM -0500, > John Baldwin wrote: > >you can use the proc_rwmem() function (it takes a uio >and a struct proc) > >to do the actual I/O portion. You can see example use in >the ptrace() > >syscall. > > Thanks.The memory of the process could be read using the proc_rwmem function > . > How can i access the stack segment of a process ? I tried knowing more > about the stack allocation by running a small (user-level) program and > observing its addresses using GDB.Then I printed the max VA address and > stack size for that process from my KLD using p->p_vmspace->vm_maxsaddr and > p->p_vmspace->vm_ssize respectively.But i could not infer anything > useful.Can you shed some light on this ? At what address does the stack > segment start ? where can we get this address from for a running process ? > In struct sysentvec{} there is sv_usrstack field, which gives the top address for stack. Each process has pointer to its own sysentvec in p_sysent. It is possible to get this value by reading kern.usrstack value, kern.usrstack is not a global system value, it is value of current process's p_sysent->sv_usrstack. sv_usrstack is usually MD macro variable USRSTACK. Memory for stack is allocated by portions and grows down or up, depending on architecture. Each portion is sgrowsiz size. As the result for stack several vm_map_entries are allocated. Even if some program will not use already allocated stack there is not any way for the system to release memory used by previously allocated stack. I mean normal stack usage, not alternative stack provided by an application. I do not know your task, but if you need something in stack, then you really need all vm_map_entries of stack, since an application can have several threads (type of multithreading does not metter) and each thread has own portion of stack. This is the example of stack of my test program run on i386, where stack grows to lower addresses: 0xbfb80000 0xbfba0000 32 0 0xc4097210 rwx 1 0 0x2180 NCOW NNC default - 0xbfba0000 0xbfbc0000 32 0 0xc3e32420 rwx 1 0 0x2180 NCOW NNC default - 0xbfbc0000 0xbfbe0000 32 0 0xc4201000 rwx 1 0 0x2180 NCOW NNC default - 0xbfbe0000 0xbfc00000 32 0 0xc3e3918c rwx 1 0 0x2180 NCOW NNC default - The size of each vm_map_entry is 128k, the same value as SGROWSIZ. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 11:47:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CF83516A420; Mon, 6 Mar 2006 11:47:44 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BAA43D48; Mon, 6 Mar 2006 11:47:44 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id ADD775174A; Mon, 6 Mar 2006 12:47:41 +0100 (CET) Received: from localhost (ana50.internetdsl.tpnet.pl [83.17.82.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6B23F516E1; Mon, 6 Mar 2006 12:47:33 +0100 (CET) Date: Mon, 6 Mar 2006 12:47:08 +0100 From: Pawel Jakub Dawidek To: Anupam Deshpande Message-ID: <20060306114708.GD53437@garage.freebsd.pl> References: <25da4ac50603050701j3fc63843oe288f6d34b67d115@mail.gmail.com> <20060305172046.V51568@fledge.watson.org> <25da4ac50603060210j1902a751g9e4c615605f9def7@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <25da4ac50603060210j1902a751g9e4c615605f9def7@mail.gmail.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: Using open system call in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 11:47:44 -0000 --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 06, 2006 at 02:10:10AM -0800, Anupam Deshpande wrote: +> I successfully created a file using kern_open(). +> Now I want to 'write to' or 'read from' the file.What functions should +> I use for that purpose? This is not so trivial as it is in userland (but you already know that:)). Here are functions I created for one of my projects: http://people.freebsd.org/~pjd/misc/kernio/subr_kernio.c http://people.freebsd.org/~pjd/misc/kernio/kernio.h There are only open/close/write functions - no read function as I didn't needed it, so you must create one for your own. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEDCE8ForvXbEpPzQRAqlXAJ9GVnOQPrq3lw6WtGCFxYDMtWvxrgCg2x7b ZFU+ggmZdICf2Z3ifTxMEJU= =0JW1 -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 12:44:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8737116A420 for ; Mon, 6 Mar 2006 12:44:17 +0000 (GMT) (envelope-from listas@itm.net.br) Received: from venom.itm.net.br (venom.itm.net.br [201.30.187.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 443E543D81 for ; Mon, 6 Mar 2006 12:43:59 +0000 (GMT) (envelope-from listas@itm.net.br) Received: (qmail 34358 invoked by uid 89); 6 Mar 2006 12:43:31 -0000 Received: by simscan 1.1.0 ppid: 34353, pid: 34354, t: 0.2558s scanners: attach: 1.1.0 clamav: 0.88/m:35/d:1281 spam: 3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on venom.itm.net.br X-Spam-Level: X-Spam-Status: No, score=-3.9 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from ironman.fsonline.com.br (HELO ironman) (201.30.187.70) by venom.itm.net.br with SMTP; 6 Mar 2006 12:43:30 -0000 Message-ID: <009601c6411b$0d455d90$0e4fdfc8@ironman> From: "Cesar" To: Date: Mon, 6 Mar 2006 09:39:46 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Antivirus: avast! (VPS 0609-3, 03/03/2006), Outbound message X-Antivirus-Status: Clean Subject: Spam from NAT boxes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 12:44:17 -0000 Hi, I have some NAT boxes running FreeBSD, each of these boxes do NAT for like 100+ people. Almost everyday my IPs got blacklisted because of spam. I cant block the smtp traffic going out became some people need it to send true e-mails. Are there any tool to detect/block those spams? I tought in a program that receive the connection diverted/forwarded by ipfw and then deliver it to SpamAssassin ... I also have an e-mail server fully configurated with anti-spam, anti-virus ... I tried forward to this e-mail server all my NAT box tcp connections to port 25. ipfw add fwd xx.xx.xx.xx,25 tcp from 192.168.0.0/24 to any 25 I got some matches in this rule when I try to send an email, but I didnt get redirected to my email server. Any ideas and/or sugestions? Thanks From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 10:01:57 2006 Return-Path: X-Original-To: hackers@freebsd.org 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 EA72116A420 for ; Mon, 6 Mar 2006 10:01:57 +0000 (GMT) (envelope-from kevin.rong@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A40343D46 for ; Mon, 6 Mar 2006 10:01:57 +0000 (GMT) (envelope-from kevin.rong@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so696972nzp for ; Mon, 06 Mar 2006 02:01:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IFfPVl1lDbW2/qiZcHashnrMSwSyaahbpL8WOfpTNxWASQeBP35hYrnLhqarKi5Pj2ve0i7B57apAgk+cUHodEyesnh5R4sbaifXMWarEjHgdQKZADvgmjE4ZQFlsVSQY683vMCO8owuVWN48VFOQyVC9wxxQJcgAIpCnu86kmY= Received: by 10.35.99.5 with SMTP id b5mr1122298pym; Mon, 06 Mar 2006 02:01:56 -0800 (PST) Received: by 10.35.112.14 with HTTP; Mon, 6 Mar 2006 02:01:56 -0800 (PST) Message-ID: Date: Mon, 6 Mar 2006 10:01:56 +0000 From: "Kevin Rong" To: hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Mar 2006 12:50:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: panic coredump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 10:01:58 -0000 Dear sirs I am a freebsd 6.0-stable user. Recently my thinkpad will panic when I use vmware 3.2.1 and mozilla at sames times. So I think I can send these info to you. Help you can help me. thanks you a lot. kevin.rong FreeBSD r51bsd.corp.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Tue Feb 2= 8 13:52:07 UTC 2006 root@r51bsd.corp.com:/usr/src/sys/i386/compile/R51BSD i386 =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 my kernel machine i386 cpu I686_CPU ident R51BSD # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=3D5000 # Delay (in ms) before probing SC= SI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options CPU_FASTER_5X86_FPU #firewall options IPFILTER options IPFILTER_LOG device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem # RAID controllers # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VESA device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs= ! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc device fxp # Intel EtherExpress PRO/100B (82557, 82558= ) device lge # Level 1 LXT1001 gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device lnc # NE2100, NE32-VL Lance Ethernet cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and d= a device ums # Mouse device urio # Diamond Rio 500 MP3 player # USB Ethernet, requires miibus # FireWire support device smb device smbus device ichsmb device sound device snd_ich =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 Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x1c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0576a63 stack pointer =3D 0x28:0xd51b3c50 frame pointer =3D 0x28:0xd51b3c54 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 44 (pagedaemon) trap number =3D 12 panic: page fault Uptime: 2h58m58s Dumping 502 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 502MB (128480 pages) 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 (CTRL-C to abort) 7= 0 54 38 22 6 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc057f336 in boot (howto=3D260) at ../../../kern/kern_shutdown.c:399 #2 0xc057f5cc in panic (fmt=3D0xc070b950 "%s") at ../../../kern/kern_shutdown.c:555 #3 0xc06e4ef4 in trap_fatal (frame=3D0xd51b3c10, eva=3D28) at ../../../i386/i386/trap.c:836 #4 0xc06e4c5b in trap_pfault (frame=3D0xd51b3c10, usermode=3D0, eva=3D28) at ../../../i386/i386/trap.c:744 #5 0xc06e48b9 in trap (frame=3D {tf_fs =3D -719650808, tf_es =3D -1051983832, tf_ds =3D 65576, tf_edi= =3D 0, tf_es i =3D 89698, tf_ebp =3D -719635372, tf_isp =3D -719635396, tf_ebx =3D -1054= 063072, tf_ed x =3D -1065604544, tf_ecx =3D 0, tf_eax =3D -1050885784, tf_trapno =3D 12, = tf_err =3D 0, t f_eip =3D -1068012957, tf_cs =3D 32, tf_eflags =3D 66118, tf_esp =3D -10540= 63072, tf_ss =3D -719635204}) at ../../../i386/i386/trap.c:434 #6 0xc06d495a in calltrap () at ../../../i386/i386/exception.s:139 #7 0xc0576a63 in _mtx_trylock (m=3D0x0, opts=3D0, file=3D0x0, line=3D0) at ../../../kern/kern_mutex.c:418 #8 0xc06a0a4d in vm_pageout_scan (pass=3D0) at ../../../vm/vm_pageout.c:10= 85 #9 0xc06a1662 in vm_pageout () at ../../../vm/vm_pageout.c:1541 #10 0xc0569f94 in fork_exit (callout=3D0xc06a1350 , arg=3D0x0, frame=3D0xd51b3d38) at ../../../kern/kern_fork.c:789 #11 0xc06d49bc in fork_trampoline () at ../../../i386/i386/exception.s:208 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 15:32:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EDE0016A420 for ; Mon, 6 Mar 2006 15:32:12 +0000 (GMT) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80EF43D49 for ; Mon, 6 Mar 2006 15:32:10 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (unknown [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id AEAC028427; Mon, 6 Mar 2006 15:32:09 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id D550A28424; Mon, 6 Mar 2006 15:32:05 +0000 (GMT) Date: Mon, 6 Mar 2006 15:32:05 +0000 From: Baldur Gislason To: Cesar Message-ID: <20060306153205.GM20678@gremlin.foo.is> References: <009601c6411b$0d455d90$0e4fdfc8@ironman> In-Reply-To: <009601c6411b$0d455d90$0e4fdfc8@ironman> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: Spam from NAT boxes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 15:32:13 -0000 With the fwd rule, you can only redirect to 127.0.0.1 when you want your machine to intercept the connection. I'd suggest putting a tcp proxy or smtp proxy listening on 127.0.0.1 port 25 that just forwards to the mailserver box. Baldur On Mon, Mar 06, 2006 at 09:39:46AM -0300, Cesar wrote: > Hi, > > I have some NAT boxes running FreeBSD, each of these boxes do NAT for > like 100+ people. > Almost everyday my IPs got blacklisted because of spam. I cant block the > smtp traffic going out became some people need it to send true e-mails. > Are there any tool to detect/block those spams? > > I tought in a program that receive the connection diverted/forwarded by > ipfw and then deliver it to SpamAssassin ... > > I also have an e-mail server fully configurated with anti-spam, > anti-virus ... I tried forward to this e-mail server all my NAT box tcp > connections to port 25. > > ipfw add fwd xx.xx.xx.xx,25 tcp from 192.168.0.0/24 to any 25 > > I got some matches in this rule when I try to send an email, but I didnt > get redirected to my email server. > > > Any ideas and/or sugestions? > > > Thanks > > _______________________________________________ > 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 Mar 6 16:55:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 AB14C16A422 for ; Mon, 6 Mar 2006 16:55:56 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D66743D64 for ; Mon, 6 Mar 2006 16:55:53 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by zproxy.gmail.com with SMTP id r28so1288134nza for ; Mon, 06 Mar 2006 08:55:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NXHNI458+rfZ6pKuNDks8zubq7Chqli/0K0yNQJuj48HZ76vzYJ+rM7VqJ3I69II9G5NuNTQ0KGOzzpRvrxo5fKtluxv/Y5LxcAuJ87oAXNkV42RseHRIWWla7U9ljlYZKhwtrser4GO9SWzmm2TdgzNakYHnqo47Hdx2qVIvrg= Received: by 10.36.97.6 with SMTP id u6mr7288256nzb; Mon, 06 Mar 2006 08:55:52 -0800 (PST) Received: by 10.36.41.11 with HTTP; Mon, 6 Mar 2006 08:55:52 -0800 (PST) Message-ID: <3bbf2fe10603060855j1c261056mcf8c458e2d3b315f@mail.gmail.com> Date: Mon, 6 Mar 2006 08:55:52 -0800 From: "Attilio Rao" To: "Divacky Roman" In-Reply-To: <20060306145211.GA44977@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3bbf2fe10603060220k3c055092t@mail.gmail.com> <20060306145211.GA44977@stud.fit.vutbr.cz> Cc: freebsd-hackers@freebsd.org Subject: Re: Adding optimized kernel copying support to FreeBSD-i386 - Part II X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rookie@gufi.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 16:55:56 -0000 2006/3/6, Divacky Roman : > On Mon, Mar 06, 2006 at 11:20:10AM +0100, Attilio Rao wrote: > > Hi, > > I did not received too much feedbacks about Part I stability, but I wen= t > on, > > so Part II is available for tests. > > > > It presents an mmx copy which doesn't give much performance increases b= ut > > what I need now is testing for correctness. In particular I would see > > feedbacks about races inside dropping/undropping FPU mechanism. It woul= d > be > > better testing with PREEMPTION + FULL_PREEMPTION enabled (and maybe on = SMP > > archs). > > > > Some minor styling issues have been fixed of the previous patch. > > > > http://users.gufi.org/~rookie/works/patches/mmxcopy.tar.gz > > > > This mmx copy is not intended to be in final release, this is just a > testing > > issue in order to involve CPU < P4 & friends. > > > > For anything else, mail to me. > > hi, > > thnx for the great work. I think you should publish some benchmarks > (ministate-ed buildworld before and after or something like that) and als= o > tell > people what is suitable for their processor. this way people are not > interested > in testing ;( > > anyway - thnx again for your work Actually what I'm interested in is stability. I had a 2% measurable clock wall improvement just for fpu overhaul (bandwidth increased 146 MB/s to 149 MB/s on my P3, 450 MHz). The main effort will be on P4,Xeon and on amd64 porting for Athlon (I'm speaking about performancy matters). But now I need some very intensive testings about "base-code". Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 6 17:36:26 2006 Return-Path: X-Original-To: hackers@freebsd.org 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 04DA716A422 for ; Mon, 6 Mar 2006 17:36:26 +0000 (GMT) (envelope-from me@carrollkong.com) Received: from mail.faerunconsulting.com (vzdsl-jcnj-216-182-31-61.static.tellurian.net [216.182.31.61]) by mx1.FreeBSD.org (Postfix) with SMTP id A19AC43D60 for ; Mon, 6 Mar 2006 17:35:58 +0000 (GMT) (envelope-from me@carrollkong.com) Received: (qmail 88771 invoked from network); 6 Mar 2006 17:35:57 -0000 Received: from unknown (HELO athena) (192.168.0.2) by dmz.faerunhome.com with SMTP; 6 Mar 2006 17:35:57 -0000 From: "Carroll Kong" To: Date: Mon, 6 Mar 2006 12:35:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcY8CbIWzZo0izQhTH+KVM6Em5BJowFNaAQA In-Reply-To: Message-Id: <20060306173558.A19AC43D60@mx1.FreeBSD.org> Cc: Subject: RE: FreeBSD 4.11 P13 Crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 17:36:26 -0000 Well bad news. It happened again even with a new CPU and new = PowerSupply. However, the good news is that it seems to be saving the core dumps a = bit more consistently now. I swapped the motherboard back to the old one. Honestly, I've had similar core dumps in either case, I'm starting to = think it isn't the hardware but more of a software or software configuration = issue (one that works but is apparently not stable). I can swap the = motherboard back to the new one, but I got the same error in either case. It sure looks a lot like the other backtraces, but I suppose if = something corrupted the data in memory, it could still be anything. > So far I am thinking > - IPFilter intermittent bug with some packets, but I run a=20 > box with 112 days of uptime with the same version of=20 > IPFilter, albeit not with 4 NICs. It keeps failing around the net or ppp process. It might not mean = anything though since the box will always log 'junk'. Although, I find it odd = that it has never crashed when using the other, cable link, ONLY on the PPP process. Only an experienced hacker can tell me if my hypothesis is = correct in pointing the finger closer to PPP. Then again, there is no 'process' = to refer to if the issue was on the cable link! Maybe a bug in handling 4 = FXP Intel cards? I already swapped one of them (the other 2 are built = onboard, and the last one I have not swapped out yet that connects to the cable link). > - 3Ware driver is flakey, but I have a 4.10 box with 3Ware=20 > that is somewhat stable > - CPU (I would tend to think this would result in HARD lock=20 > ups vs Fatal Trap 12s though) New CPU didn't fix it, so let's scratch that out. In fact, it's been = pulled from a working system. > - PowerSupply (I suppose anything is possible, please note it=20 > is on an APC UPS, but the power supply might be delivering bad juice?) New Power supply. Antec 380 or so. I don't have a method of testing it = so it 'could' be a bad new power supply but honestly, I would expect it to = have crashed with a different error. > - Harddisks and 3Ware driver have incompatible firmware=20 > issue, I doubt this is it though since I purchased new=20 > Seagates in 9/2004 for the RAID1, then I added another=20 > Seagate as a JBOD, and that disk is not being written to=20 > during the crash. This is still a possibility, although it seems to fail in a memory operation. Unless the 3Ware somehow corrupted memory ahead of time, = which seems kind of odd but possible. Someone suggested I go back to 4.9. I don't mind doing so although I = wonder if I would be vulnerable to certain security issues. Furthermore, I'm = not sure how to do this right. I would guess cvsup with 4.9_RELEASE tag? Anyway, I am going to try to go back to 4.9, but wanted to throw some = more information to the list to see if anyone had any other ideas. The only hardware I have not changed so far is - cdrom - floppy - case :) Here is another backtrace. It seems to be doing the standard log to the ipf.log file thing, then die during an mbuf operation. Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x41f59 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc0192696 stack pointer =3D 0x10:0xd71cbbd0 frame pointer =3D 0x10:0xd71cbbd8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 105 (ppp) interrupt mask =3D net tty=20 trap number =3D 12 panic: page fault --------------- #0 dumpsys () at ../../kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc0173f3f in boot (howto=3D256) at ../../kern/kern_shutdown.c:316 #2 0xc0174364 in poweroff_wait (junk=3D0xc02f2aac, howto=3D-1070651985) = at ../../kern/kern_shutdown.c:595 #3 0xc02a77ba in trap_fatal (frame=3D0xd71cbb90, eva=3D270169) at ../../i386/i386/trap.c:974 #4 0xc02a748d in trap_pfault (frame=3D0xd71cbb90, usermode=3D0, = eva=3D270169) at ../../i386/i386/trap.c:867 #5 0xc02a704b in trap (frame=3D{tf_fs =3D -1072562160, tf_es =3D 16, = tf_ds =3D -686030832, tf_edi =3D 6757530, tf_esi =3D -1055310592,=20 tf_ebp =3D -685982760, tf_isp =3D -685982788, tf_ebx =3D 270169, = tf_edx =3D 6757530, tf_ecx =3D -1055840256, tf_eax =3D -28864,=20 tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D -1072093546, tf_cs =3D = 8, tf_eflags =3D 66054, tf_esp =3D -1055310592, tf_ss =3D -1055310592}) at ../../i386/i386/trap.c:466 #6 0xc0192696 in m_tag_delete_chain (m=3D0xc1193d00, t=3D0x0) at ../../kern/uipc_mbuf2.c:358 #7 0xc01904d3 in m_free (m=3D0xc1193d00) at ../../kern/uipc_mbuf.c:734 #8 0xc0190606 in m_freem (m=3D0xc117ef00) at ../../kern/uipc_mbuf.c:763 #9 0xc0127df8 in fr_check (ip=3D0xc117ef30, hlen=3D20, = ifp=3D0xc21a9508, out=3D0, mp=3D0xd71cbce8) at ../../contrib/ipfilter/netinet/fil.c:1387 #10 0xc01d7d06 in ip_input (m=3D0xc117ef00) at = ../../netinet/ip_input.c:478 #11 0xc01d838b in ipintr () at ../../netinet/ip_input.c:971 #12 0xc0299ee9 in swi_net_next () #13 0xc016e7c8 in lockmgr (lkp=3D0xc21a9600, flags=3D16973826, interlkp=3D0xd71c162c, p=3D0xd48bd5a0) at ../../kern/kern_lock.c:355 #14 0xc019fda8 in vop_stdlock (ap=3D0xd71cbdd0) at ../../kern/vfs_default.c:256 #15 0xc025a9c9 in ufs_vnoperatespec (ap=3D0xd71cbdd0) at ../../ufs/ufs/ufs_vnops.c:2394 #16 0xc01a9ffd in vn_lock (vp=3D0xd71c15c0, flags=3D131074, = p=3D0xd48bd5a0) at vnode_if.h:861 #17 0xc01ad842 in spec_write (ap=3D0xd71cbe64) at ../../miscfs/specfs/spec_vnops.c:284 #18 0xc025a3ac in ufsspec_write (ap=3D0xd71cbe64) at ../../ufs/ufs/ufs_vnops.c:1827 #19 0xc025a9c9 in ufs_vnoperatespec (ap=3D0xd71cbe64) at ../../ufs/ufs/ufs_vnops.c:2394 #20 0xc01a9b9a in vn_write (fp=3D0xc21a8c40, uio=3D0xd71cbed4, = cred=3D0xc219b780, flags=3D0, p=3D0xd48bd5a0) at vnode_if.h:363 #21 0xc018330d in dofilewrite (p=3D0xd48bd5a0, fp=3D0xc21a8c40, fd=3D9, buf=3D0xbfbfe89c, nbyte=3D213, offset=3D-1, flags=3D0) at ../../sys/file.h:163 #22 0xc01831c6 in write (p=3D0xd48bd5a0, uap=3D0xd71cbf80) at ../../kern/sys_generic.c:329 #23 0xc02a7a69 in syscall2 (frame=3D{tf_fs =3D 134938671, tf_es =3D 47, = tf_ds =3D -1078001617, tf_edi =3D 134996736, tf_esi =3D 213,=20 tf_ebp =3D -1077940064, tf_isp =3D -685981740, tf_ebx =3D = -1077942112, tf_edx =3D 0, tf_ecx =3D 13, tf_eax =3D 4, tf_trapno =3D 7,=20 tf_err =3D 2, tf_eip =3D 673683504, tf_cs =3D 31, tf_eflags =3D = 663, tf_esp =3D -1077942172, tf_ss =3D 47}) at ../../i386/i386/trap.c:1175 #24 0xc0298a85 in Xint0x80_syscall () #25 0x80655de in ?? () #26 0x806c2fb in ?? () #27 0x806c21d in ?? () #28 0x807470a in ?? () #29 0x8083a78 in ?? () #30 0x805b84b in ?? () #31 0x804d484 in ?? () #32 0x806ed77 in ?? () #33 0x806e967 in ?? () #34 0x804b62a in ?? () (kgdb) quit daemon# nm /kernel | grep c0192696 daemon# nm /kernel | grep c019269=20 daemon# nm /kernel | grep c01926=20 c01926e8 T m_tag_copy c0192658 T m_tag_delete c0192674 T m_tag_delete_chain c0192600 T m_tag_free c01926ac T m_tag_locate c0192614 T m_tag_prepend c0192628 T m_tag_unlink > -----Original Message----- > From: Carroll Kong=20 > Sent: Monday, February 27, 2006 8:53 PM > To: 'hackers@freebsd.org' > Subject: FreeBSD 4.11 P13 Crash >=20 > Okay this time my kernel was recompiled so there are no=20 > modules to make it easier to see all of the symbols. >=20 > Sometimes the box cycles through the fatal traps 12. Other=20 > times it does not. Based on my other Fatal trap errors, it=20 > seems to interrupt more often with the m_tag_delete function.=20 > I don't think this necessarily means the problem is with=20 > IPFilter or PPP mostly because this box acts as a firewall=20 > and logs constantly. Therefore, it is not surprising it=20 > always fails after logging with IPFilter, but I am always=20 > open to the possibility. >=20 > This box was stable before I upgraded from 4.9->4.11. Among=20 > one of the software changes was probably the change of=20 > IPFilter. I used to use the IPFilter 3.4.33pre modules, but=20 > after I moved to 4.11 I just used the distribution packaged=20 > 3.4.35. This might be the source of the problem, but I could=20 > not google for relevant entries. >=20 > I have since swapped the RAM, motherboard, RAM again (I=20 > bought another stick thinking maybe my new RAM was=20 > coincidentally bugged), one of the Intel NICs, and my 3Ware=20 > controller. The problem still occurred and actually more=20 > frequently. The usual frequency was about 14 days or so. It=20 > just crashed in less than 23 hours and then again within 25 minutes. >=20 > The final pieces of hardware that still can be swapped is the=20 > other Intel NIC (but this NIC is NOT connected to the PPPoE),=20 > CPU, Power Supply, CDROM (not used), Harddisks, or Case. :) >=20 > I tried disabling physical swap completely, and the system=20 > still crashed, so I doubt it is the 3Ware, but who knows. >=20 > So far I am thinking > - IPFilter intermittent bug with some packets, but I run a=20 > box with 112 days of uptime with the same version of=20 > IPFilter, albeit not with 4 NICs. > - 3Ware driver is flakey, but I have a 4.10 box with 3Ware=20 > that is somewhat stable > - CPU (I would tend to think this would result in HARD lock=20 > ups vs Fatal Trap 12s though) > - PowerSupply (I suppose anything is possible, please note it=20 > is on an APC UPS, but the power supply might be delivering bad juice?) > - Harddisks and 3Ware driver have incompatible firmware=20 > issue, I doubt this is it though since I purchased new=20 > Seagates in 9/2004 for the RAID1, then I added another=20 > Seagate as a JBOD, and that disk is not being written to=20 > during the crash. >=20 > I am tempted to consider upgrading to 5.X, but I am a=20 > conservative person and somehow doubt 4.X is the source of=20 > the problem as the system worked fine for over a year. >=20 > The box does a lot of things however I omitted this=20 > information to avoid flooding the list with too much=20 > information since it has worked fine for a year in the past. =20 > As a note, the problem is NOT load related. In fact, one=20 > time the fatal panic said the running process was "idle". :)=20 > Furthermore, I haven't really updated the software=20 > unnecessarily except for security issues and the system has=20 > been stable in the past with the same hardware and same=20 > software. I am very conservative when it comes to servers,=20 > so this seems like a hardware issue but I already swapped so=20 > much of it, I am beginning to wonder. >=20 > I am going to buy a new CPU and power supply as I have=20 > replaced nearly every other part by now. >=20 > I have included my dmesg, nm greps for the functions, a=20 > backtrace, uname output. I have the kernel dump so if there=20 > are any commands someone needs me to punch through, I will=20 > gladly do so. I included some of my own feeble debugging. I=20 > didn't like the line that said "address is out of bounds" in=20 > one of the mbuf structures. I am guessing that means the=20 > mbuf was already corrupted way before we got there. Any=20 > suggestions and advice are welcome. Thanks in advance! >=20 >=20 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0xc11e4402 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x8:0xc018ffcf > stack pointer =3D 0x10:0xc02fa6f0 > frame pointer =3D 0x10:0xc02fa704 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D Idle > interrupt mask =3D net tty bio cam=20 > trap number =3D 12 > panic: page fault > Uptime: 6h5m10s > twe0: Cannot delete unit. error =3D 16 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0xc11e4402 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x8:0xc018ffcf > stack pointer =3D 0x10:0xc02fa444 > frame pointer =3D 0x10:0xc02fa458 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D Idle > interrupt mask =3D net tty bio cam=20 > tx0, limit 0xfffff, type 0x1b >=20 > nm -n /kernel | grep c018f > c018f058 T accept_filt_del > c018f07c T accept_filt_get > c018f0b4 T accept_filt_generic_mod_event > c018f134 t net_init_domain > c018f1bc T net_add_domain > c018f1ec t domaininit > c018f244 T pffindtype > c018f290 T pffindproto > c018f304 T pfctlinput > c018f34c T pfctlinput2 > c018f3a4 t pfslowtimo > c018f3fc t pffasttimo > c018f45c t tunable_mbinit > c018f4ac t mbinit > c018f53c T m_mballoc > c018f5f8 T m_mballoc_wait > c018f7e8 T m_clalloc > c018f8b4 T m_clalloc_wait > c018f9a0 T m_retry > c018fa74 T m_retryhdr > c018fb60 t m_reclaim > c018fbb0 T m_get > c018fc54 T m_gethdr > c018fd0c T m_getclr > c018fdd0 T m_getcl >=20 > ------------------------------------------------------------------- >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x28067100 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xc0192696 > stack pointer =3D 0x10:0xd71cbbd0 > frame pointer =3D 0x10:0xd71cbbd8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 110 (ppp) > interrupt mask =3D net tty=20 > trap number =3D 12 > panic: page fault >=20 > syncing disks... 7 > done > Uptime: 25m51s > twe0: Cannot delete unit. error =3D 16 >=20 > dumping to dev #twed/0x20001, offset 3146240 dump 511 510 509=20 > 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494=20 > 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479=20 > 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464=20 > 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449=20 > 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434=20 > 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419=20 > 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404=20 > 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389=20 > 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374=20 > 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359=20 > 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344=20 > 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329=20 > 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314=20 > 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299=20 > 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284=20 > 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269=20 > 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254=20 > 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239=20 > 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224=20 > 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209=20 > 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194=20 > 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179=20 > 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164=20 > 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149=20 > 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134=20 > 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119=20 > 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104=20 > 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85=20 > 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65=20 > 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45=20 > 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25=20 > 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2=20 > 1 0 succeeded Automatic reboot in 15 seconds - press a key on=20 > the console to abort Rebooting... >=20 > nm -n /kernel | grep c01926 > c0192600 T m_tag_free > c0192614 T m_tag_prepend > c0192628 T m_tag_unlink > c0192658 T m_tag_delete > c0192674 T m_tag_delete_chain > c01926ac T m_tag_locate > c01926e8 T m_tag_copy >=20 > --------------- >=20 > (kgdb) bt > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > #1 0xc0173f3f in boot (howto=3D256) at ../../kern/kern_shutdown.c:316 > #2 0xc0174364 in poweroff_wait (junk=3D0xc02f2aac,=20 > howto=3D-1070651985) at ../../kern/kern_shutdown.c:595 > #3 0xc02a77ba in trap_fatal (frame=3D0xd71cbb90,=20 > eva=3D671510784) at ../../i386/i386/trap.c:974 > #4 0xc02a748d in trap_pfault (frame=3D0xd71cbb90, usermode=3D0,=20 > eva=3D671510784) at ../../i386/i386/trap.c:867 > #5 0xc02a704b in trap (frame=3D{tf_fs =3D -1072562160, tf_es =3D=20 > 16, tf_ds =3D -686030832, tf_edi =3D 6757530, tf_esi =3D -1055667456,=20 > tf_ebp =3D -685982760, tf_isp =3D -685982788, tf_ebx =3D=20 > 671510784, tf_edx =3D 6757530, tf_ecx =3D -1056411648, tf_eax =3D = 28672,=20 > tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D -1072093546, tf_cs=20 > =3D 8, tf_eflags =3D 66054, tf_esp =3D -1055667456, tf_ss =3D = -1055667456}) > at ../../i386/i386/trap.c:466 > #6 0xc0192696 in m_tag_delete_chain (m=3D0xc113cb00, t=3D0x0) at=20 > ../../kern/uipc_mbuf2.c:358 > #7 0xc01904d3 in m_free (m=3D0xc113cb00) at = ../../kern/uipc_mbuf.c:734 > #8 0xc0190606 in m_freem (m=3D0xc1094000) at = ../../kern/uipc_mbuf.c:763 > #9 0xc0127df8 in fr_check (ip=3D0xc1094030, hlen=3D20,=20 > ifp=3D0xc21a7008, out=3D0, mp=3D0xd71cbce8) > at ../../contrib/ipfilter/netinet/fil.c:1387 > #10 0xc01d7d06 in ip_input (m=3D0xc1094000) at=20 > ../../netinet/ip_input.c:478 > #11 0xc01d838b in ipintr () at ../../netinet/ip_input.c:971 > #12 0xc0299ee9 in swi_net_next () > #13 0xc016e7c8 in lockmgr (lkp=3D0xc21a7100, flags=3D16973826,=20 > interlkp=3D0xd71c0bac, p=3D0xd48bd5a0) at ../../kern/kern_lock.c:355 > #14 0xc019fda8 in vop_stdlock (ap=3D0xd71cbdd0) at=20 > ../../kern/vfs_default.c:256 > #15 0xc025a9c9 in ufs_vnoperatespec (ap=3D0xd71cbdd0) at=20 > ../../ufs/ufs/ufs_vnops.c:2394 > #16 0xc01a9ffd in vn_lock (vp=3D0xd71c0b40, flags=3D131074,=20 > p=3D0xd48bd5a0) at vnode_if.h:861 > #17 0xc01ad842 in spec_write (ap=3D0xd71cbe64) at=20 > ../../miscfs/specfs/spec_vnops.c:284 > #18 0xc025a3ac in ufsspec_write (ap=3D0xd71cbe64) at=20 > ../../ufs/ufs/ufs_vnops.c:1827 > #19 0xc025a9c9 in ufs_vnoperatespec (ap=3D0xd71cbe64) at=20 > ../../ufs/ufs/ufs_vnops.c:2394 #20 0xc01a9b9a in vn_write=20 > (fp=3D0xc219b100, uio=3D0xd71cbed4, cred=3D0xc2197080, flags=3D0,=20 > p=3D0xd48bd5a0) at vnode_if.h:363 > #21 0xc018330d in dofilewrite (p=3D0xd48bd5a0, fp=3D0xc219b100,=20 > fd=3D9, buf=3D0xbfbfe89c, nbyte=3D580, offset=3D-1, flags=3D0) > at ../../sys/file.h:163 > #22 0xc01831c6 in write (p=3D0xd48bd5a0, uap=3D0xd71cbf80) at=20 > ../../kern/sys_generic.c:329 > #23 0xc02a7a69 in syscall2 (frame=3D{tf_fs =3D -1078001617, tf_es=20 > =3D 134938671, tf_ds =3D -1078001617, tf_edi =3D 135090176, tf_esi =3D = 580,=20 > tf_ebp =3D -1077940064, tf_isp =3D -685981740, tf_ebx =3D=20 > -1077942112, tf_edx =3D 0, tf_ecx =3D 13, tf_eax =3D 4, tf_trapno =3D = 7,=20 > tf_err =3D 2, tf_eip =3D 673683504, tf_cs =3D 31, tf_eflags =3D=20 > 663, tf_esp =3D -1077942172, tf_ss =3D 47}) > at ../../i386/i386/trap.c:1175 > #24 0xc0298a85 in Xint0x80_syscall () > #25 0x80655de in ?? () > #26 0x806c2fb in ?? () > #27 0x806c21d in ?? () > #28 0x807470a in ?? () > #29 0x8083a78 in ?? () > #30 0x805b84b in ?? () > #31 0x804d484 in ?? () > #32 0x806ed77 in ?? () > #33 0x806e967 in ?? () > #34 0x804b62a in ?? () >=20 > (kgdb) f 11 > #11 0xc01d838b in ipintr () at ../../netinet/ip_input.c:971 > 971 ip_input(m); > (kgdb) print *m > $13 =3D {m_hdr =3D {mh_next =3D 0xc1128100, mh_nextpkt =3D 0x0,=20 > mh_data =3D 0xc1094030 "E", mh_len =3D 208, mh_type =3D 0, mh_flags = =3D 2}, > M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc21a7008, len =3D 576, = > header =3D 0x0, csum_flags =3D 0, csum_data =3D 0, tags =3D { > slh_first =3D 0x0}}, MH_dat =3D {MH_ext =3D {ext_buf =3D=20 > 0x2000000
, ext_free =3D 0x2400045,=20 > ext_size =3D 28454, ext_ref =3D 0x6d3d012e},=20 > MH_databuf =3D=20 > = "\000\000\000\002E\000@\002&o\000\000.\001=3Dm;=BD=F30=D8=B6\037=3D\003\0= 0 > = 1=BA\006\000\000\000\000E\000\005=C8=E9=BA@\000/\006=A2t=D8=B6\037=3D=C0=A8= \001e'B > \rmy=BB6\216^\222@\002P\020=E1\000=B1=A1\000\000\000\000@\t\a\000\000\ > = 002r\000\003=C0\000\227=AB\212!\225@\204]\001\214\027=C1=F9\177\232=F9=E3= =F2 > = \222\016\000=F9au1=3D\216=DD\204=A8\207O\002+=F80=E9H=F0\eD\2056n\001=F7U= \025=E0 > = \222=FE\f:S=F5PI\037)T=D8(=FD=A8\r=D3@\210=EA\217(S=F5c=E2=E9=B8\n?\217%x= &=B5\177=F4UqX\ > = 222\020\225\\=D1=D9~\fh=EA=A9\036\t\"Az\206=E1p=FE+}=C7=A3=A3=A2"...}},=20 > M_databuf =3D "\bp\032=C2@\002", '\000' ,=20 > = "\002E\000@\002&o\000\000.\001=3Dm;=BD=F30=D8=B6\037=3D\003\001=BA\006\00= 0\0 > = 00\000\000E\000\005=C8=E9=BA@\000/\006=A2t=D8=B6\037=3D=C0=A8\001e'B\rmy=BB= 6\216^\ > 222@\002P\020=E1\000=B1=A1\000\000\000\000@\t\a\000\000\002r\000\003 > = =C0\000\227=AB\212!\225@\204]\001\214\027=C1=F9\177\232=F9=E3=F2\222\016\= 000 > = =F9au1=3D\216=DD\204=A8\207O\002+=F80=E9H=F0\eD\2056n\001=F7U\025=E0\222=FE= \f:S=F5PI > = \037)T=D8(=FD=A8\r=D3@\210=EA\217(S=F5c=E2=E9=B8\n?\217%x&=B5\177=F4UqX\2= 22\020\225\ > \=D1=D9~\fh=EA=A9\036\t"...}} > (kgdb) f 6 > #6 0xc0192696 in m_tag_delete_chain (m=3D0xc113cb00, t=3D0x0) at=20 > ../../kern/uipc_mbuf2.c:358 > 358 m_tag_delete(m, q); > (kgdb) print *m > $14 =3D {m_hdr =3D {mh_next =3D 0xc113ca00, mh_nextpkt =3D=20 > 0x280ef4cd, mh_data =3D 0x14
,=20 > mh_len =3D 663,=20 > mh_type =3D 28672, mh_flags =3D 10246}, M_dat =3D {MH =3D=20 > {MH_pkthdr =3D {rcvif =3D 0x280ef492, len =3D 672120748, header =3D = 0x2,=20 > csum_flags =3D 16384, csum_data =3D 1, tags =3D {slh_first=20 > =3D 0x28067100}}, MH_dat =3D {MH_ext =3D { > ext_buf =3D 0x28067200
bounds>, ext_free =3D 0x280541fd, ext_size =3D 134516476,=20 > ext_ref =3D 0x280819da},=20 > MH_databuf =3D=20 > = "\000r\006(=FDA\005(=FC\216\004\b=DA\031\b(\000\000\000\000=A2A\005(=A8: > \006(@\200\006(\000\000\000\000\000\000\000\000`=FB=BF=BF@\200\006\0 > = 01\234=FB=BF=BFOA\005(=FC\216\004\b\004=CFe\000\000r\006(\001\000\000\00 > 0=A8:\006(\000p\006(=FC\216\004\b=FDA\005(=FC\216\004\b\t\013\005(\200 > = =E6\020(=A2A\005(=A8:\006(\000=E9\a(\200=3D\006(\227?\005(5(\005(=A8:\006= ( > \f=FC=BF=BF=CF@\005(=20 > \006\005(\004=CFe\000\200=3D\006(\001\000\000\000\000p\006(\000q\0 > = 06(\000r\006(=DA>\005(=A8:\006(\000p\006(=FC\216\004\b=D0=FC=BF=BFS=D4\00= 4\b\2 > 00=E6\020(@ \005\b\000r\006("...}},=20 > M_databuf =3D=20 > "\222=F4\016(=AC=BF\017(\002\000\000\000\000@\000\000\001\000\000\00 > 0\000q\006(\000r\006(=FDA\005(=FC\216\004\b=DA\031\b(\000\000\000\00 > = 0=A2A\005(=A8:\006(@\200\006(\000\000\000\000\000\000\000\000`=FB=BF=BF@ > = \200\006\001\234=FB=BF=BFOA\005(=FC\216\004\b\004=CFe\000\000r\006(\001\ > 000\000\000=A8:\006(\000p\006(=FC\216\004\b=FDA\005(=FC\216\004\b\t\01 > = 3\005(\200=E6\020(=A2A\005(=A8:\006(\000=E9\a(\200=3D\006(\227?\005(5(\0 > 05(=A8:\006(\f=FC=BF=BF=CF@\005(=20 > \006\005(\004=CFe\000\200=3D\006(\001\000\000\000\000p\006(\000q\0 > 06(\000r\006(=DA>\005(=A8:\006(\000p\006("...}} > (kgdb) print *q > Cannot access memory at address 0x0. > (kgdb) > ---------------------------- > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 > 1993, 1994 > The Regents of the University of California. All=20 > rights reserved. > FreeBSD 4.11-RELEASE-p13 #3: Thu Feb 23 13:09:31 EST 2006 > damascus@daemon.faerunhome.com:/usr/src/sys/compile/DAEMON > Timecounter "i8254" frequency 1193182 Hz > CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1993.54-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf24 Stepping =3D 4 > =20 > Features=3D0x3febfbff P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SS > E2,SS,HTT,TM> > real memory =3D 536608768 (524032K bytes) avail memory =3D=20 > 518377472 (506228K bytes) Preloaded elf kernel "kernel" at 0xc03af000. > Warning: Pentium 4 CPU: PSE disabled > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 11 entries at 0xc00f28c0 > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device=20 > 30.0 on pci0 > pci2: on pcib2 > twe0: <3ware Storage Controller driver ver. 1.40.01.002> port=20 > 0xdfa0-0xdfaf mem 0xfe000000-0xfe7fffff,0xfeafec00-0xfeafec0f=20 > irq 9 at device 9.0 on pci2 > twe0: 4 ports, Firmware FE7X 1.05.00.068, BIOS BE7X 1.08.00.048 > fxp0: port 0xdf00-0xdf3f mem=20 > 0xfeaa0000-0xfeabffff,0xfeafd000-0xfeafdfff irq 11 at device=20 > 10.0 on pci2 > fxp0: Ethernet address 00:02:b3:d0:e3:73 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp1: port 0xde80-0xdebf mem=20 > 0xfea80000-0xfea9ffff,0xfeafc000-0xfeafcfff irq 10 at device=20 > 11.0 on pci2 > fxp1: Ethernet address 00:02:b3:ee:65:88 > inphy1: on miibus1 > inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp2: port 0xdd80-0xddbf mem=20 > 0xfea40000-0xfea5ffff,0xfeafb000-0xfeafbfff irq 11 at device=20 > 12.0 on pci2 > fxp2: Ethernet address 00:11:11:c1:a2:e5 > inphy2: on miibus2 > inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp3: port 0xdd00-0xdd3f mem=20 > 0xfea20000-0xfea3ffff,0xfeafa000-0xfeafafff irq 11 at device=20 > 13.0 on pci2 > fxp3: Ethernet address 00:11:11:c1:a2:e7 > inphy3: on miibus3 > inphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > atapci0: port=20 > 0xdcc0-0xdcff,0xdfe0-0xdfe3,0xdf98-0xdf9f,0xdfe4-0xdfe7,0xdff0 > -0xdff7 mem 0xfe9e0000-0xfe9fffff irq 11 at device 14.0 on pci2 > ata2: at 0xdff0 on atapci0 > ata3: at 0xdf98 on atapci0 > pci2: at 15.0 irq 11 > isab0: at device=20 > 31.0 on pci0 > isa0: on isab0 > atapci1: port 0xffa0-0xffaf at=20 > device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci1 > ata1: at 0x170 irq 15 on atapci1 > uhci0: port=20 > 0xef40-0xef5f irq 11 at device 31.2 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pci0: (vendor=3D0x8086, dev=3D0x2443) at 31.3 irq 11 > uhci1: port=20 > 0xef80-0xef9f irq 10 at device 31.4 on pci0 > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > orm0: