From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 03:12:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202A216A518 for ; Sun, 11 Jul 2004 03:12:07 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA0F43D2F for ; Sun, 11 Jul 2004 03:12:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6B3AKt9017375; Sat, 10 Jul 2004 21:10:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Jul 2004 21:10:39 -0600 (MDT) Message-Id: <20040710.211039.82990024.imp@bsdimp.com> To: ulf@Alameda.net From: "M. Warner Losh" In-Reply-To: <20040710212822.GX41460@seven.alameda.net> References: <20040710212822.GX41460@seven.alameda.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: PS/2 and USB keyboard at the same time, where to 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: Sun, 11 Jul 2004 03:12:07 -0000 In message: <20040710212822.GX41460@seven.alameda.net> Ulf Zimmermann writes: : I want to try myself on kernel hacking again and a thing which peaked my : interest was some emails a few days ago about making the kernel use both : PS/2 and USB keyboards at the same time. My questions is can anyone point : me at the relevant pieces of the kernel I should study about trying myself : on this? There's already a keyboard mux in the kernel. You'll just need to make it max many to 1. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 10 18:36:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E8A016A4CE for ; Sat, 10 Jul 2004 18:36:24 +0000 (GMT) Received: from clever.eusc.inter.net (clever.eusc.inter.net [213.73.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3451543D45 for ; Sat, 10 Jul 2004 18:36:24 +0000 (GMT) (envelope-from msch@snafu.de) Received: from dial-76-245.de.inter.net ([213.73.76.245] helo=current.best-eng.de) by clever.eusc.inter.net with esmtp (Exim 3.36 #4) id 1BjMhy-0002Xd-00 for freebsd-hackers@FreeBSD.org; Sat, 10 Jul 2004 20:36:23 +0200 Received: from current.best-eng.de (localhost.best-eng.de [127.0.0.1]) by current.best-eng.de (8.12.11/8.12.11) with ESMTP id i6AIaMl8001575 for ; Sat, 10 Jul 2004 20:36:22 +0200 (CEST) (envelope-from matthias@current.best-eng.de) Received: from localhost (localhost [[UNIX: localhost]]) by current.best-eng.de (8.12.11/8.12.11/Submit) id i6AIaMh7001574 for freebsd-hackers@FreeBSD.org; Sat, 10 Jul 2004 20:36:22 +0200 (CEST) (envelope-from matthias) From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: freebsd-hackers@FreeBSD.org Date: Sat, 10 Jul 2004 20:36:22 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200407102036.22076.msch@snafu.de> X-Mailman-Approved-At: Sun, 11 Jul 2004 12:35:02 +0000 Subject: gdb 6.1.1: File format not recognized X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2004 18:36:24 -0000 Hello, I tried to look into a core dump from a -current kernel with 'gdb' but all i get is: --------------8><----------------------------- root@current - /var/crash 504 # gdb kernel.debug vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... "/var/crash/vmcore.0" is not a core dump: File format not recognized (gdb) quit --------------8><----------------------------- I looked at the man-pages of gdb(1), savecore(8) and into the 'Developers Handbook' but I didn't find anything about the correct file format of a core dump. If I look at /var/crash/info.0, there's: --------------8><----------------------------- Good dump found on device /dev/da0s1b Architecture: i386 Architecture version: 1 Dump length: 268369920B (255 MB) Blocksize: 512 Dumptime: Sat Jul 10 19:40:30 2004 Hostname: current.best-eng.de Versionstring: FreeBSD 5.2-CURRENT #5: Sat Jul 10 12:37:27 CEST 2004 root@current.best-eng.de:/raid/obj/usr/src/sys/CURRENT Panicstring: unmount: dangling vnode Bounds: 0 --------------8><----------------------------- Did I overlook something? Has someone a pointer or hint for me? -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 17:06:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC65C16A4CE for ; Sun, 11 Jul 2004 17:06:35 +0000 (GMT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16CAE43D31 for ; Sun, 11 Jul 2004 17:06:35 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.11/8.12.11) with ESMTP id i6BH6W1h088828 for ; Sun, 11 Jul 2004 21:06:33 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 11 Jul 2004 21:06:32 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-hackers@freebsd.org Message-ID: <20040711210219.J84500@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: gcc strangeness 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, 11 Jul 2004 17:06:36 -0000 Dear colleagues, one of my friends has raisen very strange issue regarding gcc rounding: marck@woozle:/tmp/tsostik> uname -r 4.10-STABLE marck@woozle:/tmp/tsostik> gcc -v Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] marck@woozle:/tmp/tsostik> cat x.c #include int main () { float a; for(a=0.01;a<=0.1; a+=0.01) printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); return 0; } marck@woozle:/tmp/tsostik> cc x.c marck@woozle:/tmp/tsostik> ./a.out 1.000000 1.000 0 2.000000 2.000 1 3.000000 3.000 2 4.000000 4.000 3 5.000000 5.000 5 6.000000 6.000 6 7.000000 7.000 7 8.000000 8.000 7 9.000000 9.000 8 9.999999 10.000 9 Any comments? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 17:40:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11AC716A4CE for ; Sun, 11 Jul 2004 17:40:46 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A353A43D1F for ; Sun, 11 Jul 2004 17:40:43 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 5CA7C22850; Sun, 11 Jul 2004 19:40:41 +0200 (CEST) Date: Sun, 11 Jul 2004 19:40:31 +0200 From: Dimitry Andric X-Mailer: The Bat! (v2.12 RC/3) Business X-Priority: 3 (Normal) Message-ID: <115911306.20040711194031@andric.com> To: Dmitry Morozovsky In-Reply-To: <20040711210219.J84500@woozle.rinet.ru> References: <20040711210219.J84500@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------D81AD301C85E2F5" cc: freebsd-hackers@freebsd.org Subject: Re: gcc strangeness 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, 11 Jul 2004 17:40:46 -0000 ------------D81AD301C85E2F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2004-07-11 at 19:06:32 Dmitry Morozovsky wrote: > 1.000000 1.000 0 > 2.000000 2.000 1 > 3.000000 3.000 2 > 4.000000 4.000 3 > 5.000000 5.000 5 > 6.000000 6.000 6 > 7.000000 7.000 7 > 8.000000 8.000 7 > 9.000000 9.000 8 > 9.999999 10.000 9 Yes, this is completely normal if you use IEEE floating point, due to decimal <-> binary conversion and other accumulating rounding errors. In other words, floating point calculations will almost never be exact... This is not a gcc problem. In fact, I can even reproduce your output under Windows using a Microsoft C compiler! :) ------------D81AD301C85E2F5 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.4 (MingW32) iD8DBQFA8XuOsF6jCi4glqMRAuh3AKCX9aqzKBh5i9Nj5SQsMOjDuRLcBgCfWyFl 28onGDE/9u8YlOHXbYqMjH0= =NJ5n -----END PGP MESSAGE----- ------------D81AD301C85E2F5-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 18:07:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AFAB16A4CE for ; Sun, 11 Jul 2004 18:07:30 +0000 (GMT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC6CE43D3F for ; Sun, 11 Jul 2004 18:07:29 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.11/8.12.11) with ESMTP id i6BI7Rwu089458; Sun, 11 Jul 2004 22:07:27 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 11 Jul 2004 22:07:27 +0400 (MSD) From: Dmitry Morozovsky To: Dimitry Andric In-Reply-To: <115911306.20040711194031@andric.com> Message-ID: <20040711220440.R84500@woozle.rinet.ru> References: <20040711210219.J84500@woozle.rinet.ru> <115911306.20040711194031@andric.com> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: gcc strangeness 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, 11 Jul 2004 18:07:30 -0000 On Sun, 11 Jul 2004, Dimitry Andric wrote: DA> > 1.000000 1.000 0 DA> > 2.000000 2.000 1 DA> > 3.000000 3.000 2 DA> > 4.000000 4.000 3 DA> > 5.000000 5.000 5 DA> > 6.000000 6.000 6 DA> > 7.000000 7.000 7 DA> > 8.000000 8.000 7 DA> > 9.000000 9.000 8 DA> > 9.999999 10.000 9 DA> DA> Yes, this is completely normal if you use IEEE floating point, due to DA> decimal <-> binary conversion and other accumulating rounding errors. DA> In other words, floating point calculations will almost never be DA> exact... DA> DA> This is not a gcc problem. In fact, I can even reproduce your output DA> under Windows using a Microsoft C compiler! :) Wow, it's interesting for us to have exact step-by-step instructions for that! ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 18:14:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20D2316A4CF for ; Sun, 11 Jul 2004 18:14:11 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4591843D31 for ; Sun, 11 Jul 2004 18:14:09 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from vaiowjw (beck [212.61.27.74]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i6BICrsD060250; Sun, 11 Jul 2004 20:12:53 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <00c301c46773$180335a0$4a1b3dd4@digiware.nl> From: "Willem Jan Withagen" To: , References: <200407102036.22076.msch@snafu.de> Date: Sun, 11 Jul 2004 20:15:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: gdb 6.1.1: File format not recognized 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, 11 Jul 2004 18:14:11 -0000 Use gdb6 from the ports..... gdb6 -k ......... --WjW ----- Original Message ----- From: "Matthias Schuendehuette" To: Sent: Saturday, July 10, 2004 8:36 PM Subject: gdb 6.1.1: File format not recognized > Hello, > > I tried to look into a core dump from a -current kernel with > 'gdb' but all i get is: > > --------------8><----------------------------- > root@current - /var/crash > 504 # gdb kernel.debug vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > "/var/crash/vmcore.0" is not a core dump: File format not recognized > (gdb) quit > --------------8><----------------------------- > > I looked at the man-pages of gdb(1), savecore(8) and into the > 'Developers Handbook' but I didn't find anything about the > correct file format of a core dump. > > If I look at /var/crash/info.0, there's: > > --------------8><----------------------------- > Good dump found on device /dev/da0s1b > Architecture: i386 > Architecture version: 1 > Dump length: 268369920B (255 MB) > Blocksize: 512 > Dumptime: Sat Jul 10 19:40:30 2004 > Hostname: current.best-eng.de > Versionstring: FreeBSD 5.2-CURRENT #5: Sat Jul 10 12:37:27 CEST 2004 > root@current.best-eng.de:/raid/obj/usr/src/sys/CURRENT > Panicstring: unmount: dangling vnode > Bounds: 0 > --------------8><----------------------------- > > Did I overlook something? Has someone a pointer or hint for me? > > > -- > Ciao/BSD - Matthias > > Matthias Schuendehuette , Berlin (Germany) > PGP-Key at and ID: 0xDDFB0A5F > _______________________________________________ > 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 Jul 11 18:37:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C66E516A4CE for ; Sun, 11 Jul 2004 18:37:29 +0000 (GMT) Received: from cruzio.com (dsl3-63-249-85-132.cruzio.com [63.249.85.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76F0443D1D for ; Sun, 11 Jul 2004 18:37:29 +0000 (GMT) (envelope-from brucem@mail.cruzio.com) Received: from mail.cruzio.com (localhost [127.0.0.1]) by cruzio.com (8.12.10/8.12.10) with ESMTP id i6BIcHe4000793; Sun, 11 Jul 2004 11:38:17 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.12.10/8.12.10/Submit) id i6BIcHku000792; Sun, 11 Jul 2004 11:38:17 -0700 (PDT) (envelope-from brucem) Date: Sun, 11 Jul 2004 11:38:17 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200407111838.i6BIcHku000792@mail.cruzio.com> To: freebsd-hackers@freebsd.org cc: marck@rinet.ru Subject: Re: gcc strangeness 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, 11 Jul 2004 18:37:29 -0000 Hi, re: >one of my friends has raisen very strange issue regarding gcc rounding: > printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); > > 9.999999 10.000 9 Hasty unresearched guess: If you print with a large fp fmt (say 22.18) you will get a better idea of the value: 9.999999403953552246 10.000 9 The "%.3f" says to round upward to inf after 3 decimal places, so "9.9999" is rounded to "10.000". The "%f" defaults to round up after 6 decimal places, so "9.9999994" is rounded to ""9.999999". Everything is working. There are a lot of subtleties in floating-point printf(). Printing binary values out and reading them back accurately can be a non-trivial exercise. - bruce From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 21:01:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6879316A4CE for ; Sun, 11 Jul 2004 21:01:07 +0000 (GMT) Received: from VARK.homeunix.com (adsl-69-107-108-110.dsl.pltn13.pacbell.net [69.107.108.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2627743D1F for ; Sun, 11 Jul 2004 21:01:07 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i6BL0pfs045032; Sun, 11 Jul 2004 14:00:51 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i6BL0prq045031; Sun, 11 Jul 2004 14:00:51 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 11 Jul 2004 14:00:51 -0700 From: David Schultz To: Dmitry Morozovsky Message-ID: <20040711210051.GA44904@VARK.homeunix.com> Mail-Followup-To: Dmitry Morozovsky , freebsd-hackers@FreeBSD.ORG References: <20040711210219.J84500@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040711210219.J84500@woozle.rinet.ru> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: gcc strangeness 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, 11 Jul 2004 21:01:07 -0000 On Sun, Jul 11, 2004, Dmitry Morozovsky wrote: > one of my friends has raisen very strange issue regarding gcc rounding: [...] > marck@woozle:/tmp/tsostik> cat x.c > #include > int main () > { > float a; > for(a=0.01;a<=0.1; a+=0.01) > printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); > return 0; > } 0.01 is not exactly representable in IEEE 754 floating-point, so when you use the float type, you get a rounding error of ~2.2e-10. After 10 additions, the error grows to ~2.2e-9. Then you multiply by 100, which results in a maximum error bound of ~2.2e-7. That is, on the last loop iteration, a has a value that is roughly 0.09999999404. That's why you should always use at least double precision; it's at least as fast as single precision on most architectures anyway. > marck@woozle:/tmp/tsostik> cc x.c > marck@woozle:/tmp/tsostik> ./a.out > 1.000000 1.000 0 > 2.000000 2.000 1 > 3.000000 3.000 2 > 4.000000 4.000 3 > 5.000000 5.000 5 > 6.000000 6.000 6 > 7.000000 7.000 7 > 8.000000 8.000 7 > 9.000000 9.000 8 > 9.999999 10.000 9 > > Any comments? Both printf() and gcc got everything right here. As I mentioned, a*100 is approximately 9.999999404 due to rounding error. The closest 7-digit decimal to a*100 is 9.999999, and the closest 5-digit decimal is 10.000. However, 9.999999404 < 10, and floating to integer casts are required to round down in the C language, which is why the third field has the values it does. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 07:56:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A189016A4CE for ; Mon, 12 Jul 2004 07:56:11 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4D2D43D1F for ; Mon, 12 Jul 2004 07:56:10 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i6C7r9V2026255 for freebsd-hackers@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 12 Jul 2004 11:53:09 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i6C7oBAk026115; (8.12.8/vak/2.1) Mon, 12 Jul 2004 11:50:12 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40F242AC.5020109@cronyx.ru> Date: Mon, 12 Jul 2004 11:50:04 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Morozovsky References: <20040711210219.J84500@woozle.rinet.ru> In-Reply-To: <20040711210219.J84500@woozle.rinet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: gcc strangeness 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, 12 Jul 2004 07:56:11 -0000 Dmitry Morozovsky wrote: >Dear colleagues, > >one of my friends has raisen very strange issue regarding gcc rounding: > >marck@woozle:/tmp/tsostik> uname -r >4.10-STABLE >marck@woozle:/tmp/tsostik> gcc -v >Using builtin specs. >gcc version 2.95.4 20020320 [FreeBSD] > >marck@woozle:/tmp/tsostik> cat x.c >#include >int main () >{ > float a; > for(a=0.01;a<=0.1; a+=0.01) > printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); > > I believe this should more correct: printf ("%f %.3f %d\n", a*100, a*100, (int)(a*100+.5)); rik >return 0; >} >marck@woozle:/tmp/tsostik> cc x.c >marck@woozle:/tmp/tsostik> ./a.out >1.000000 1.000 0 >2.000000 2.000 1 >3.000000 3.000 2 >4.000000 4.000 3 >5.000000 5.000 5 >6.000000 6.000 6 >7.000000 7.000 7 >8.000000 8.000 7 >9.000000 9.000 8 >9.999999 10.000 9 > >Any comments? > > >Sincerely, >D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >------------------------------------------------------------------------ >*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** >------------------------------------------------------------------------ >_______________________________________________ >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 Jul 11 14:19:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E70A16A4CE; Sun, 11 Jul 2004 14:19:47 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3AEE43D5A; Sun, 11 Jul 2004 14:19:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6BEOsYv018869; Sun, 11 Jul 2004 08:24:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40F14C67.5050803@samsco.org> Date: Sun, 11 Jul 2004 08:19:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@FreeBSD.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org X-Mailman-Approved-At: Mon, 12 Jul 2004 12:13:02 +0000 Subject: [REMINDER] Call for FreeBSD status reports 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, 11 Jul 2004 14:19:47 -0000 All, This is a reminder that status reports are due on July 15! It's time again for the bi-monthly FreeBSD status reports. We're on an upward trend in numbers of reports that are submitted, and I'm hoping to get 25 this time. As always, reports are encouraged for anything that relates to FreeBSD development, documentation, independent projects, or anything else that might be interesting to the community as a whole. Reports should be one to two paragraphs in length. The template can be found at http://www.freebsd.org/news/status/report-sample.xml Submissions are due to monthly@freebsd.org by July 15. Thanks, Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 01:50:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0392B16A4CE for ; Mon, 12 Jul 2004 01:50:48 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE8E43D5C for ; Mon, 12 Jul 2004 01:50:47 +0000 (GMT) (envelope-from dev@opensound.com) Received: from [192.1.2.22] (c-24-127-17-145.we.client2.attbi.com[24.127.17.145]) by comcast.net (sccrmhc11) with ESMTP id <20040712015041011009g27me> (Authid: opensound); Mon, 12 Jul 2004 01:50:46 +0000 Message-ID: <40F1EE71.6000704@opensound.com> Date: Sun, 11 Jul 2004 18:50:41 -0700 From: 4Front Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Jul 2004 12:13:02 +0000 Subject: FreeBSD open() questions 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, 12 Jul 2004 01:50:48 -0000 Hi, We are trying to implement multi-open() in our OSS drivers for FreeBSD. The idea is that all apps keep opening /dev/dsp and internally OSS finds the next available device (/dev/dspNN+1) and returns that device's minor number back to the open routine. What happens is that every read/write/close/ioctl call now uses the new minor number. This works in Solaris and Linux. In Solaris the open routine has an extra parameter that permits giving a new device number that will be used in subsequent read/write/etc calls. Changing this field doesn't affect the way how open works. In Linux struct file has a private field that the driver can use as it likes. We simply store the major/minor number in this field. In the read/write/ioctl/etc routines we read the device number from this field instead of using inode->dev. BSD doesn't have such mechanisms. The dev_t parameter is a "global" one and the same structure is shared by all applications having the same device file opened. If you change anything in this structure then it will affect the other applications that had opened the same file. Every time one application tries to open /dev/dsp the changes will affect also the applications that are already running (they will jump to use the new device). I've taken a look at dev_clone and EVENT_HANDLER stuff in FreeBSD's pcm drivers but essentially this works by creating a new device and adding it via devfs_create if you access /dev/dsp. But in our case we have already added all the devices so using dev_clone doesn't work (or atleast I've not been able to get it to do what we want) We already have all the devices configured during our Module Load. So all we really want to do is if you open /dev/dsp, OSS's device manager will look for a free device and return that device's minor number and from now on all read/write/ioctl/close routines will use that device number. Does anybody have any suggestions on how to get such features working in both FreeBSD 4x and 5x? Should we be looking at /dev/tty (because you can keep opening /dev/tty and it kind of behaves the same way OSS's open works in Solaris or Linux. BTW, we also want to work with the BSD audio guys to implement the upcoming OSS V4.0 mixer extensions that will allow you to add mixer extensions to devices that aren't your standard AC97 or ISA devices. So if anyone wants to extend FreeBSD's OSS api, by all means contact us and we'll work with you to implement this. best regards Dev Mazumdar PS: Please respond directly to me as I'm not subscribed to the freebsd-hackers list. ----------------------------------------------------------- 4Front Technologies 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA. Tel: (310) 202 8530 URL: www.opensound.com Fax: (310) 202 0496 Email: info@opensound.com ----------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 11:52:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDCCF16A4CE for ; Mon, 12 Jul 2004 11:52:59 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [194.125.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8441D43D41 for ; Mon, 12 Jul 2004 11:52:56 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i6CEv5rg034551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2004 14:57:06 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id D6C3F14F; Mon, 12 Jul 2004 14:51:34 +0300 (EEST) From: Andrey Simonenko To: Steven Smith In-Reply-To: <1089501790.00086820.1089489001@10.7.7.3> X-Newsgroups: lucky.freebsd.hackers User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.9-STABLE (i386)) Message-Id: <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> Date: Mon, 12 Jul 2004 14:51:34 +0300 (EEST) X-Mailman-Approved-At: Mon, 12 Jul 2004 12:13:02 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Article on Sun's DTrace 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, 12 Jul 2004 11:53:00 -0000 On Sat, 10 Jul 2004 20:45:14 +0100 in lucky.freebsd.hackers, Steven Smith wrote: > >> > It's also possible to put probes on the return instruction of the >> > function. I'm not sure how they're actually finding that, though. >> I think the return probe is done by adding a call probe that changes the >> return address. > Yeah, I thought that when I first saw it, but the probe is passed the > address of the return instruction when it fires, and I can't see how > you could get that if it was just invoked by modifying the return > address on the call stack. Don't you think that they disassemble functions on-the-fly to find out prolog and return sequence of a function? On their DTrace support forum there is the article about the problem with different byte patterns of "movl %esp, %ebp" produced by different assemblers. (As an optimization fbt:::entry and fbt:::return probes' entry points can be found before and be placed in well known section.) At least if the control goes from the target function to some DTrace probe dispatch function, then this DTrace function should know which commands to emulate before returning to the target function, and it is impossible to run original function's commands without knowing their size, I mean that DTrace function should copy exactly complete sequence of commands from target function, not some bytes. I haven't opportunity to test DTrace, but there is another interesting question. fbt:::entry probe (or similar so called wild card probe) can create tens of thousands entry points on-the-fly. How does this creation affect on whole system? Also modifying functions on-the-fly require some sort of synchronization: noone should run function which currently is being modified (fbt provider). From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 12:28:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D4AE16A4CE for ; Mon, 12 Jul 2004 12:28:19 +0000 (GMT) Received: from mx.x123.info (165.Red-80-37-224.pooles.rima-tde.net [80.37.224.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4612E43D62 for ; Mon, 12 Jul 2004 12:28:18 +0000 (GMT) (envelope-from esn@x123.info) Received: by mx.x123.info (Postfix, from userid 80) id A54E7170A8; Mon, 12 Jul 2004 14:28:05 +0200 (CEST) Received: from 192.168.1.2 ([192.168.1.2]) by www.x123.info (Horde) with HTTP for ; Mon, 12 Jul 2004 14:28:05 +0200 Message-ID: <20040712142805.wvswgcwoss4g8808@www.x123.info> X-Priority: 3 (Normal) Date: Mon, 12 Jul 2004 14:28:05 +0200 From: "Sebastian Yepes F. [ESN]" To: freebsd-hackers@freebsd.org References: <20040710212822.GX41460@seven.alameda.net> <20040710.211039.82990024.imp@bsdimp.com> In-Reply-To: <20040710.211039.82990024.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs Subject: Re: PS/2 and USB keyboard at the same time, where to 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: Mon, 12 Jul 2004 12:28:19 -0000 > In message: <20040710212822.GX41460@seven.alameda.net> > Ulf Zimmermann writes: > : I want to try myself on kernel hacking again and a thing which peaked my > : interest was some emails a few days ago about making the kernel use both > : PS/2 and USB keyboards at the same time. My questions is can anyone point > : me at the relevant pieces of the kernel I should study about trying myself > : on this? > > There's already a keyboard mux in the kernel. You'll just need to > make it max many to 1. > > Warner How is this setup, I don't see no MUX stuff on the files device.hints or kern conf. can you please explain your self, thanks From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 13:30:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22BC716A4CE for ; Mon, 12 Jul 2004 13:30:51 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF9543D39 for ; Mon, 12 Jul 2004 13:30:50 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [80.119.170.204]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 01EF914B9C8; Mon, 12 Jul 2004 15:34:18 +0200 (CEST) Message-ID: <040101c46814$70849bf0$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "Roman Kurakin" , "Dmitry Morozovsky" References: <20040711210219.J84500@woozle.rinet.ru> <40F242AC.5020109@cronyx.ru> Date: Mon, 12 Jul 2004 15:30:45 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-hackers@freebsd.org Subject: Re: gcc strangeness 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, 12 Jul 2004 13:30:51 -0000 "Roman Kurakin" wrote: > Dmitry Morozovsky wrote: [snip] > >marck@woozle:/tmp/tsostik> cat x.c > >#include > >int main () > >{ > > float a; > > for(a=0.01;a<=0.1; a+=0.01) > > printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); > > > > > I believe this should more correct: > printf ("%f %.3f %d\n", a*100, a*100, (int)(a*100+.5)); it is much better to use ceilf(3) (or ceil(3) for double) here : printf("%f %.3f %f %d\n", a*100, a*100, ceilf(a*100), (int)ceilf(a*100)); # ./a.out 1.000000 1.000 1.000000 1 2.000000 2.000 2.000000 2 3.000000 3.000 3.000000 3 4.000000 4.000 4.000000 4 5.000000 5.000 5.000000 5 6.000000 6.000 6.000000 6 7.000000 7.000 7.000000 7 8.000000 8.000 8.000000 8 9.000000 9.000 9.000000 9 9.999999 10.000 10.000000 10 Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 18:08:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E8516A4CE for ; Mon, 12 Jul 2004 18:08:20 +0000 (GMT) Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC5943D2D for ; Mon, 12 Jul 2004 18:08:19 +0000 (GMT) (envelope-from sos22@cantab.net) Received: from archibold.chu.cam.ac.uk ([131.111.131.102]:60490) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with smtp (Exim 4.34) id 1Bk5Dt-0005Gy-3h; Mon, 12 Jul 2004 19:08:17 +0100 Received: by archibold.chu.cam.ac.uk (sSMTP sendmail emulation); Mon, _d Jul 2004 19:09:33 +0100 Date: Mon, 12 Jul 2004 19:09:33 +0100 From: Steven Smith To: freebsd-hackers@freebsd.org Message-ID: <20040712180933.GA1093@archibold.chu.cam.ac.uk> References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned cc: sos22@srcf.ucam.org Subject: Re: Article on Sun's DTrace 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, 12 Jul 2004 18:08:20 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >> > It's also possible to put probes on the return instruction of the > >> > function. I'm not sure how they're actually finding that, though. > >> I think the return probe is done by adding a call probe that changes t= he=20 > >> return address. > > Yeah, I thought that when I first saw it, but the probe is passed the > > address of the return instruction when it fires, and I can't see how > > you could get that if it was just invoked by modifying the return > > address on the call stack. > Don't you think that they disassemble functions on-the-fly to find > out prolog and return sequence of a function? That is entirely plausible. > On their DTrace support forum there is the article about the problem > with different byte patterns of "movl %esp, %ebp" produced by > different assemblers. Do you have an URL for that? I can't seem to find it. > Also modifying functions on-the-fly require some sort of > synchronization: noone should run function which currently is being > modified (fbt provider). I suspect that the actual probe trigger is an int3 instruction, rather than a call, since that's a single byte and can therefore be atomically copied in over the start of any instruction. Any other processor either sees the value before the probe was activated (which is fine; it's just equivalent to the probe activating a split second later) ot afterwards (which is also fine). The x86 memory model is (I think; someone with more knowledge may want to correct me) strong enough to make that perfectly safe. (So the push %ebp part of the prolog becomes an int3 instruction in a single atomic operation, rather than just the first byte of a call instruction). I don't know enough about Sparcs to even speculate how it's done there. Steven. --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA8tPdO4S8/gLNrjcRAsthAJ9zYS5sWzeC6ojvaB7JHICKop0rMQCeKlvj hwBEfShdlCHmosqRIw3meHI= =bVeR -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 06:20:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F0E016A4CE; Tue, 13 Jul 2004 06:20:25 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F0E43D2D; Tue, 13 Jul 2004 06:20:25 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs1.cs.huji.ac.il with esmtp id 1BkGeN-000Pq2-Pb; Tue, 13 Jul 2004 09:20:23 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 2004 09:20:23 +0300 From: Danny Braniss Message-Id: <20040713062025.07F0E43D2D@mx1.FreeBSD.org> cc: freebsd-hackers@FreeBSD.org Subject: Seagate 200GB/ST3200822A, was Re: problems with RAID0 ... 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, 13 Jul 2004 06:20:25 -0000 Is there any know problems with this disk (Seagate 200gb/ata) + FreeBSD + Promise/RAID0? Im asking, since a similar configuration but with smaller disk works fine. I keep getting - after several hours of populating a huge data base: /kernel: ad4: hard error reading fsbn 0 (ad4 bn 0; cn 0 tn 0 sn 0) trying PIO mode /kernel: ad4: hard error reading fsbn 0 (ad4 bn 0; cn 0 tn 0 sn 0) status=59 error=10 /kernel: ar0: ERROR - array broken why would the kernel want to read ad4 fsbn 0 (ad4 bn 0; cn 0 tn 0 sn 0) when the filesystem is ar0? /kernel: ar0: 381564MB [48642/255/63] status: READY subdisks: /kernel: 0 READY ad4: 190782MB [387621/16/63] at ata2-master UDMA100 /kernel: 1 READY ad6: 190782MB [387621/16/63] at ata3-master UDMA100 danny From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 07:17:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39AE116A4CE for ; Tue, 13 Jul 2004 07:17:26 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id F213443D5D for ; Tue, 13 Jul 2004 07:17:25 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id BF33C530C; Tue, 13 Jul 2004 09:17:24 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 1E3805308; Tue, 13 Jul 2004 09:17:19 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id C26BBB85E; Tue, 13 Jul 2004 09:17:18 +0200 (CEST) To: Steven Smith References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> <20040712180933.GA1093@archibold.chu.cam.ac.uk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 13 Jul 2004 09:17:18 +0200 In-Reply-To: <20040712180933.GA1093@archibold.chu.cam.ac.uk> (Steven Smith's message of "Mon, 12 Jul 2004 19:09:33 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.63 cc: freebsd-hackers@freebsd.org cc: sos22@srcf.ucam.org Subject: Re: Article on Sun's DTrace 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, 13 Jul 2004 07:17:26 -0000 Steven Smith writes: > I don't know enough about Sparcs to even speculate how it's done > there. The UltraSparc is a RISC processor, which amongst other things implies constant instruction size. Memory barriers take care of any cache coherence issues that may arise. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 09:30:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE7616A4CE for ; Tue, 13 Jul 2004 09:30:59 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [194.125.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238C743D49 for ; Tue, 13 Jul 2004 09:30:33 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i6DCXinF039106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2004 12:33:44 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 5DF6114F; Tue, 13 Jul 2004 12:28:11 +0300 (EEST) Date: Tue, 13 Jul 2004 12:28:11 +0300 From: Andrey Simonenko To: Steven Smith Message-ID: <20040713092811.GA288@pm514-9.comsys.ntu-kpi.kiev.ua> References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> <20040712180933.GA1093@archibold.chu.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040712180933.GA1093@archibold.chu.cam.ac.uk> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: sos22@srcf.ucam.org Subject: Re: Article on Sun's DTrace 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, 13 Jul 2004 09:30:59 -0000 On Mon, Jul 12, 2004 at 07:09:33PM +0100, Steven Smith wrote: > > On their DTrace support forum there is the article about the problem > > with different byte patterns of "movl %esp, %ebp" produced by > > different assemblers. > Do you have an URL for that? I can't seem to find it. http://forum.sun.com/thread.jsp?forum=211&thread=19877 > > Also modifying functions on-the-fly require some sort of > > synchronization: noone should run function which currently is being > > modified (fbt provider). > I suspect that the actual probe trigger is an int3 instruction, rather > than a call, since that's a single byte and can therefore be > atomically copied in over the start of any instruction. Having read that bug report I began to think that they change several continues bytes in a function, probably they just search for well known commands sequence and atomically change one of them. I think it is possible to change almost any instruction on x86, just because changed instruction should be emulated after return from DTrace probe (this very actual for probes in userspace). Yes, you are right, using classic debugging technique for activating DTrace trampoline should work. One can find description of probe's activating for x86 in the 4.1 paragraph of the DTrace Usenix report. They talked about IDT and interrupt handler. I know that you know this, but... If an interrupt call for activating probe is used on x86, then this explains how it is possible to get offset of "ret" command (cs:eip from trap frame) and how probes work in the userspace (control goes to kernel, where it works with script's variables). Again, if every "ret" instructions or instructions before "ret" instructions are changed in a function (because an offset of "ret" instruction is available in :return probe), then to speed up instruction changing, it is possible to save offsets of probes entries in some well known sections of object files (during compilation phase for example) and if there isn't such section, then try to find probes entries on-the-fly by disassembling binary code. Wildcard probes can require changing at least two instructions in every of tens of thousands functions. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 11:06:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C8716A4CE for ; Tue, 13 Jul 2004 11:06:16 +0000 (GMT) Received: from mps3.plala.or.jp (c146240.vh.plala.or.jp [210.150.146.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23DDE43D48 for ; Tue, 13 Jul 2004 11:06:11 +0000 (GMT) (envelope-from e-kamo@trio.plala.or.jp) Received: from msvc2.plala.or.jp ([172.23.8.210]) by mps3.plala.or.jp with SMTP id <20040713110609.CJEP2393.mps3.plala.or.jp@msvc2.plala.or.jp> for ; Tue, 13 Jul 2004 20:06:09 +0900 Received: ( 15263 invoked from network); 13 Jul 2004 20:06:09 +0900 X-SVCK: Received: from unknown (HELO mpb1.plala.or.jp) (172.23.8.16) by msvc2 with SMTP; 13 Jul 2004 20:06:08 +0900 Received: from trio.plala.or.jp ([219.25.148.126]) by mpb1.plala.or.jp with ESMTP id <20040713110608.EBNY19716.mpb1.plala.or.jp@trio.plala.or.jp> for ; Tue, 13 Jul 2004 20:06:08 +0900 Message-ID: <40F3C3B9.4030001@trio.plala.or.jp> Date: Tue, 13 Jul 2004 20:12:57 +0900 From: Eitarou Kamo User-Agent: Mozilla/5.0 (Windows; U; Win98; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: Article on Sun's DTrace 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, 13 Jul 2004 11:06:16 -0000 Hi Andrey, Andrey Simonenko wrote: > > Having read that bug report I began to think that they change several > continues bytes in a function, probably they just search for well known > commands sequence and atomically change one of them. I think it is > possible > to change almost any instruction on x86, just because changed instruction > should be emulated after return from DTrace probe (this very actual for > probes in userspace). Yes, you are right, using classic debugging > technique for activating DTrace trampoline should work. > > One can find description of probe's activating for x86 in the 4.1 > paragraph of the DTrace Usenix report. They talked about IDT and > interrupt handler. > > I know that you know this, but... > > If an interrupt call for activating probe is used on x86, then this > explains how it is possible to get offset of "ret" command (cs:eip from > trap frame) and how probes work in the userspace (control goes to kernel, > where it works with script's variables). > > Again, if every "ret" instructions or instructions before "ret" > instructions > are changed in a function (because an offset of "ret" instruction is > available in :return probe), then to speed up instruction changing, it > is possible to save offsets of probes entries in some well known sections > of object files (during compilation phase for example) and if there isn't > such section, then try to find probes entries on-the-fly by disassembling > binary code. Wildcard probes can require changing at least two > instructions > in every of tens of thousands functions. > _______________________________________________ > > You seem to know well about DTrace. I was taught a lot by you on the off line too. By the way, Are you plan to port DTrace like tool to FreeBSD? or are you Sun or DTrace developer? Sorry, I'm not sure who and what you are, and I'm not old-timer on this list. Eitarou -- *********************** Eitarou Kamo Tel. +81 75 7035997 Fax +81 75 7035997 VoIP 050 10585997(domestic only) e$B!>(Bmail e-kamo@trio.plala.or.jp For business: Feel free to mail me(above), please. Donation http://www.PayPal.Com GPG FingerPrint: 032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 ************************************************************************ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 13:52:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D29616A4CE for ; Tue, 13 Jul 2004 13:52:09 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 29E7643D3F for ; Tue, 13 Jul 2004 13:52:08 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail 9938 invoked by uid 65534); 13 Jul 2004 13:52:04 -0000 Received: from p5090C148.dip0.t-ipconnect.de (EHLO gmx.de) (80.144.193.72) by mail.gmx.net (mp022) with SMTP; 13 Jul 2004 15:52:04 +0200 X-Authenticated: #1954550 Message-ID: <40F3E8DE.3050005@gmx.de> Date: Tue, 13 Jul 2004 15:51:26 +0200 From: Phil Schulz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040520 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Code review / Monitoring battery 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, 13 Jul 2004 13:52:09 -0000 Hello! I wrote a little daemon which monitors the value of sysctl hw.acpi.battery.life and issues me two warnings before shutting down the machine in case of low battery. Since this is one of my first steps in Unix-programming, I wonder if anyone might take a minute or two to look over the code and comment on it. I put a lot of comments all over the place, especially where I'm unsure about how things work. The source code can be found at [1]. Please note that this 'server' is connected over an ADSL line with only 128kbps upstream just in case you wonder why it's so slow. Also I'd like to know if anyone knows something similar to this little tool. I found wmbattery from ports, but it doesn't shut down the computer. If there isn't such a program, I'd be happy to make this little thing a port (provided that there is need for it). Thanks, Phil. [1] http://phil.homeunix.net:8000/battd.c From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 19:37:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3053D16A4CE for ; Tue, 13 Jul 2004 19:37:37 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B0C43D1D for ; Tue, 13 Jul 2004 19:37:36 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup154-70.ip.peterstar.net ([81.3.154.70] helo=doom.homeunix.org) by voodoo.oberon.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1BkT5t-0006mR-Ku for freebsd-hackers@freebsd.org; Tue, 13 Jul 2004 21:37:38 +0200 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.12.11/8.12.11) with ESMTP id i6DIC5ag001306; Tue, 13 Jul 2004 22:13:01 +0400 (MSD) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.12.11/8.12.11/Submit) id i6DIBCvD001305; Tue, 13 Jul 2004 22:11:12 +0400 (MSD) (envelope-from igor) Date: Tue, 13 Jul 2004 22:11:12 +0400 From: Igor Pokrovsky To: Phil Schulz Message-ID: <20040713181112.GA1247@doom.homeunix.org> Mail-Followup-To: Phil Schulz , freebsd-hackers@freebsd.org References: <40F3E8DE.3050005@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F3E8DE.3050005@gmx.de> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: Code review / Monitoring battery 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, 13 Jul 2004 19:37:37 -0000 On Tue, Jul 13, 2004 at 03:51:26PM +0200, Phil Schulz wrote: > Also I'd like to know if anyone knows something similar to this little > tool. I found wmbattery from ports, but it doesn't shut down the > computer. If there isn't such a program, I'd be happy to make this > little thing a port (provided that there is need for it). You can configure apmd to do this. -ip -- When we try to pick out anything by itself we find it hitched to everything else in the universe. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 23:31:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1D516A4CE for ; Tue, 13 Jul 2004 23:31:25 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A5E43D1F for ; Tue, 13 Jul 2004 23:31:24 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i6DNVM6E083424; Wed, 14 Jul 2004 03:31:22 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i6DNVLHp083423; Wed, 14 Jul 2004 03:31:21 +0400 (MSD) (envelope-from yar) Date: Wed, 14 Jul 2004 03:31:21 +0400 From: Yar Tikhiy To: Jean-Sebastien Roy Message-ID: <20040713233120.GA79064@comp.chem.msu.su> References: <40EF172C.7020508@jeannot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EF172C.7020508@jeannot.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: Silent errors when reading CDs 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, 13 Jul 2004 23:31:25 -0000 On Sat, Jul 10, 2004 at 12:07:40AM +0200, Jean-Sebastien Roy wrote: > > I'm currently using FreeBSD 4.10 on an HP D530 SFF. > The system is perfectly stable except for the following problem > I'm unable to understand : > > When I mount a cdrom (mount /cdrom), then calculate the MD5 hash > of a big file on a CD (md5 /cdrom/bigfile), the results are often random: > unmounting, mounting again and calculating again the MD5 often result in > a different value. What disturb me the most is that absolutely no errors > are reported in any log (no read errors for example). > > I thought the CDROM reader, a LITE-ON LTR-48327S PQS3, was the culprit, > so I replaced it with a PLEXTOR DVDR PX-712A and got the exact same > results (i.e. random MD5 values). I checked the RAM using memtest and > got no errors. The problem does not occur for files on the harddisk. Once I had an old noname PC (iP200 in an i430VX motherboard), and I installed a DVD+RW drive into it. Data read from a CD or DVD was damaged with high probability. With hw.ata.atapi_dma set to zero, the probability of data corruption was lower, but still noticable. That's while there were no corruption on burning in DMA or PIO mode. I got used to always checksumming data read or written; it was a real pain in the back. Finally, I dismantled the PC, but kept the DVD-RW drive for a new PC; thus I got rid of the problem once and for all. My conclusion was: If your hardware sucks, you may choose to work around the bugs, but it's usually easier to dump the POS and find a replacement. Of course, you may need to do some testing before you know which part sucks. > hw.ata.atapi_dma is set since both drives support it and it seems to be > required for proper CD/DVD burning. The CD drive is the master on its > own ATA bus. DMA mode on an ATAPI device might be the root of the evil. Alas, a lot of ATA controllers have bugs there. And you'll need DMA mode only for high-speed burning, when PIO mode cannot provide enough throughput--it's not required in general. E.g., I had DVD+Rs burned OK at 2.4x in PIO mode on the P200. Therefore you can at least see if disabling hw.ata.atapi_dma is a workaround for your problem. > While the problem occurs on multiple CDs (mostly RW), to my surprise, I > was not able to reproduce the problem by reading big files on DVDs. Are there CDs in your collection that produce no errors? > Could someone provide me a hint on what to check next or how to fix this > problem ? Can errors on CDs generate such a behavior ? Even a badly scratched CD won't produce damaged data unless read in a brain-dead drive. If your drives work OK with a different ATA controller, then it's probably your present ATA controller to blame. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 23:26:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 192AB16A4CE for ; Tue, 13 Jul 2004 23:26:10 +0000 (GMT) Received: from chococat.sd.dreamhost.com (chococat.sd.dreamhost.com [66.33.206.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0149343D3F for ; Tue, 13 Jul 2004 23:26:10 +0000 (GMT) (envelope-from tedu@coverity.com) Received: from webmail.coverity.com (localhost [127.0.0.1]) by chococat.sd.dreamhost.com (Postfix) with SMTP id 66A59FA1D; Tue, 13 Jul 2004 16:26:08 -0700 (PDT) Received: from 66.93.171.98 (SquirrelMail authenticated user tedu@coverity.com) by webmail.coverity.com with HTTP; Tue, 13 Jul 2004 16:26:08 -0700 (PDT) Message-ID: <16734.66.93.171.98.1089761168.spork@webmail.coverity.com> Date: Tue, 13 Jul 2004 16:26:08 -0700 (PDT) From: "Ted Unangst" To: hackers@freebsd.org User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Jul 2004 12:06:33 +0000 cc: rees@umich.edu Subject: out of bounds in rpcclnt 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, 13 Jul 2004 23:26:10 -0000 the following code, around line 562 in sys/rpc/rpcclnt.c, exceeds the bounds of the array. each array is only four bytes, the [4] is too much. /* Initialize other non-zero congestion variables */ rpc->rc_srtt[0] = rpc->rc_srtt[1] = rpc->rc_srtt[2] = rpc->rc_srtt[3] = rpc->rc_srtt[4] = (RPC_TIMEO << 3); rpc->rc_sdrtt[0] = rpc->rc_sdrtt[1] = rpc->rc_sdrtt[2] = rpc->rc_sdrtt[3] = rpc->rc_sdrtt[4] = 0; From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 23:39:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DD2F16A4CE for ; Tue, 13 Jul 2004 23:39:20 +0000 (GMT) Received: from chococat.sd.dreamhost.com (chococat.sd.dreamhost.com [66.33.206.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69A6F43D2D for ; Tue, 13 Jul 2004 23:39:20 +0000 (GMT) (envelope-from tedu@coverity.com) Received: from webmail.coverity.com (localhost [127.0.0.1]) by chococat.sd.dreamhost.com (Postfix) with SMTP id D9593FA45 for ; Tue, 13 Jul 2004 16:39:18 -0700 (PDT) Received: from 66.93.171.98 (SquirrelMail authenticated user tedu@coverity.com) by webmail.coverity.com with HTTP; Tue, 13 Jul 2004 16:39:18 -0700 (PDT) Message-ID: <16435.66.93.171.98.1089761958.spork@webmail.coverity.com> Date: Tue, 13 Jul 2004 16:39:18 -0700 (PDT) From: "Ted Unangst" To: hackers@freebsd.org User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Jul 2004 12:06:33 +0000 Subject: out of bounds in local_apic.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: Tue, 13 Jul 2004 23:39:20 -0000 if lapic_create is passed the value 16, it will use it as index into lapics, with potentially bad results. the check should be if (apic_id >= MAX_APICID). From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 00:54:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73B0016A4CE for ; Wed, 14 Jul 2004 00:54:59 +0000 (GMT) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 594BF43D1F for ; Wed, 14 Jul 2004 00:54:56 +0000 (GMT) (envelope-from peter.jeremy@alcatel.com.au) Received: from gsmx07.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])i6E0sp3l031533; Wed, 14 Jul 2004 10:54:51 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) i6E0spks036007; Wed, 14 Jul 2004 10:54:51 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from pjeremy@localhost) by gsmx07.alcatel.com.au (8.12.9p2/8.12.9/Submit) id i6E0sjHc036003; Wed, 14 Jul 2004 10:54:45 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Wed, 14 Jul 2004 10:54:44 +1000 From: Peter Jeremy To: Dmitry Morozovsky Message-ID: <20040714005444.GA35946@gsmx07.alcatel.com.au> Mail-Followup-To: Dmitry Morozovsky , freebsd-hackers@freebsd.org References: <20040711210219.J84500@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040711210219.J84500@woozle.rinet.ru> User-Agent: Mutt/1.4.2i X-Mailman-Approved-At: Wed, 14 Jul 2004 12:06:33 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: gcc strangeness 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, 14 Jul 2004 00:54:59 -0000 On 2004-Jul-11 21:06:32 +0400, Dmitry Morozovsky wrote: >marck@woozle:/tmp/tsostik> cat x.c >#include >int main () >{ > float a; > for(a=0.01;a<=0.1; a+=0.01) > printf("%f %.3f %d\n", a*100, a*100, (int)(a*100)); >return 0; >} >marck@woozle:/tmp/tsostik> cc x.c >marck@woozle:/tmp/tsostik> ./a.out >1.000000 1.000 0 >2.000000 2.000 1 >3.000000 3.000 2 >4.000000 4.000 3 >5.000000 5.000 5 >6.000000 6.000 6 >7.000000 7.000 7 >8.000000 8.000 7 >9.000000 9.000 8 >9.999999 10.000 9 As various other people have pointed out, this is an artifact of binary floating point arithmetic, rather than gcc. Note that single-precision floating point only gives you 24 binary (or 7.22 decimal) digits of precision. Expecting to accurately display 7 digits may be somewhat hopeful. The correct solution is to use rint(3), rather than casting to int (which is truncation). ceil(3) will solve this specific issue but is just as susceptable to unexpected rounding. Switching to double precision will help but is still not a complete solution. I looked into a similar problem this a few years ago following a complaint that int(0.29 * 100) == 28 in double precision. The following is my analysis of that problem. The underlying problem is that 1/100 is not representable in a finite number of bits. Specifically, 1/100 = 0d0.01 = 0b0.0000[00101000111101011100] = 0x0.0[28F5C] (where the brackets enclose the repeating digits). As an example, 0.29 = 0x0.4[A3D70]. Expressed as a rounded IEEE 754 double precision number, this is 0x3fd28f5c28f5c28f, which underestimates the correct value by ~2e-17 (0.36ULP[1]). When this number is multiplied by 100, the underestimate becomes 0.56ULP, causing the result to round down (ie the result is 1ULP = ~3.4e-15 low). Since conversion-to-integer is defined to round towards zero, this gives an integer value of 28. A good (though not hyper-linked) bibliography on floating point can be found at http://www.cse.nd.edu/~milind/references/floatingpoint. Prof William Kahan's writings (http://www.cs.berkeley.edu/~wkahan/) also make interesting reading. [1] Units in the Last Place. Peter From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 13:56:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5501816A4CE for ; Wed, 14 Jul 2004 13:56:45 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E02443D46 for ; Wed, 14 Jul 2004 13:56:44 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i6EDuc6E019489; Wed, 14 Jul 2004 17:56:38 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i6EDubdE019488; Wed, 14 Jul 2004 17:56:37 +0400 (MSD) (envelope-from yar) Date: Wed, 14 Jul 2004 17:56:37 +0400 From: Yar Tikhiy To: Jean-Sebastien Roy Message-ID: <20040714135637.GB18493@comp.chem.msu.su> References: <40EF172C.7020508@jeannot.org> <20040713233120.GA79064@comp.chem.msu.su> <40F52FD1.9040908@jeannot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40F52FD1.9040908@jeannot.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: marck@rinet.ru Subject: Re: Silent errors when reading CDs 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, 14 Jul 2004 13:56:45 -0000 On Wed, Jul 14, 2004 at 03:06:25PM +0200, Jean-Sebastien Roy wrote: > > >Once I had an old noname PC (iP200 in an i430VX motherboard), and > >I installed a DVD+RW drive into it. Data read from a CD or DVD was > >damaged with high probability. With hw.ata.atapi_dma set to zero, > >the probability of data corruption was lower, but still noticable. > >That's while there were no corruption on burning in DMA or PIO mode. > > > At least I'm not alone ! Of course you are not! A lot of ATA users are in the same boat. I myself managed to get out of it only thanks to VIA ;-) Now I have a VIA KT133-based motherboard, which seems to have no trouble with DMA on ATAPI. Alas, it doesn't mean that other VIA chipsets have bug-free ATAPI support. Moreover, it won't guarantee that another instance of the same chipset would give you no trouble. > >Are there CDs in your collection that produce no errors? > > > Yes, but I cannot really tell if it's by chance or they really do not > produce errors. That's a point to test in order to be completely sure. Just pick such a "error-free" CD, read it *really many* a time, and compare the checksums. > The CDs read well in other computers. FWIW, my ATA controler is an Intel > ICH5 : [skip] > I think I will live with this bug until I change hardware. In any case, testing the effect of disabling atapi_dma in your system would be interesting. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 15:29:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E86716A4E0 for ; Wed, 14 Jul 2004 15:29:03 +0000 (GMT) Received: from ms006msg.fastweb.it (ms006msg.fastweb.it [213.140.2.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEB7B43D31 for ; Wed, 14 Jul 2004 15:28:57 +0000 (GMT) (envelope-from thefly@acaro.org) Received: from tyler (1.10.185.81) by ms006msg.fastweb.it (7.0.028) id 40D855CC002BD670 for freebsd-hackers@freebsd.org; Wed, 14 Jul 2004 17:28:56 +0200 Received: by tyler (Postfix, from userid 1000) id 8BBF0123DEA; Wed, 14 Jul 2004 17:32:58 +0200 (CEST) Date: Wed, 14 Jul 2004 17:32:58 +0200 From: thefly To: freebsd-hackers@freebsd.org Message-ID: <20040714153258.GA2629@tyler> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline X-Editor: VIM - Vi IMproved 6.2 (2003 Jun 1, compiled May 20 2004 09:35:32) X-OS: Debian GNU/Linux 2.6.6 i686 User-Agent: Mutt/1.5.6+20040523i Subject: My module freezes the 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: Wed, 14 Jul 2004 15:29:03 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everybody. I finised developing my module (actually modifying ng_netflow), and my code can be found at http://www.acaro.org/ng_netflow-0.2.4/ i added a few hooks to my code inside ng_netflow.c in the constructor, rmnode, rcvdata etc etc, and the mmap/ioctl code. The rest of my code is found in ng_counter.c. I'm testing it, and it happens it makes my box panic.=20 I tested it using linux's packetgenerator building 95Mb/s, and the box doesn't freeze. I tested it with an nmap on ALL ports range (1-65535), and it logs it. But with high traffic, and actually general purpouse traffic (scp of a big file plus 4 nmaps + some ftp + some http etc etc) the code panics saying the kernel is trying to access a page which doesn't exist. This happens simply counting, not while doing mmap() or ioctl(). The actual code that counts is this: static int _add_traffic(struct ng_counter_data *counters, u_int16_t dest_port, u_short= packet_len, char prot) { u_int64_t * dest, old_val; if(dest_port < 0 || dest_port > 65535) return EINVAL; mtx_lock(&counters->counter_lock); switch(prot){ case UDP_P: dest =3D counters->B_array+ARRAY_SHIFT; break; case TCP_P: dest =3D counters->B_array; break; default: return EINVAL; } old_val =3D *(dest+dest_port); *(dest+dest_port) +=3D packet_len; mtx_unlock(&counters->counter_lock); return 0; } i don't know how netgraph reacts with my lockings, and what the problem might be. I tested it on a freebsd 5.2.1 both on a UP and a dual SMP box, and i've got the same problem on both of them. The two big memory chunks are given me by contigmalloc(), it can be found in ng_counter.c:ng_counter_constr(). I don't know what it can be, because under medium load it works, but with high variegate load it crashes.So it doesn't seem to be a coding error, and all the shared data is under the mutex lock. TIA --=20 Claudio "thefly" Martella thefly@acaro.org GNU/PG keyid: 0x8EA95625 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9VIqygeBqo6pViURAqOIAKC71+10mroIhNFwuyGsdV0KFTv61ACgjUnV 2HkZl6orPi5GH+1h5PbX26Q= =SFvT -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 14 15:48:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78E2416A4CE; Wed, 14 Jul 2004 15:48:51 +0000 (GMT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 696DA43D2D; Wed, 14 Jul 2004 15:48:43 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i6EFmeTb000624; Wed, 14 Jul 2004 23:48:40 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i6EFmeb7000623; Wed, 14 Jul 2004 23:48:40 +0800 (KRAST) (envelope-from eugen) Date: Wed, 14 Jul 2004 23:48:40 +0800 (KRAST) Message-Id: <200407141548.i6EFmeb7000623@grosbein.pp.ru> To: FreeBSD-gnats-submit@freebsd.org From: Eugene Grosbein X-send-pr-version: 3.113 X-GNATS-Notify: cc: hackers@freebsd.org Subject: kernel reads unmapped memory while unloading modules X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Eugene Grosbein List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 15:48:51 -0000 >Submitter-Id: current-users >Originator: Eugene Grosbein >Organization: Svyaz Service JSC >Confidential: no >Synopsis: kernel reads unmapped memory while unloading modules >Severity: serious >Priority: low >Category: kern >Class: sw-bug >Release: FreeBSD 4.10-STABLE i386 >Environment: System: FreeBSD grosbein.pp.ru 4.10-STABLE FreeBSD 4.10-STABLE #11: Wed Jul 14 22:10:30 KRAST 2004 eu@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV i386 >Description: Page fault while in kernel mode occures after kldload snd.ko/kldunload snd.ko regardless of presence of audio hardware. The same panic occures for custom kernel and for GENERIC, for Pentium notebook and for Celeron-900E desktop, with Yamaha OPL3-SA2, with Crystal Sound CS4232 or without any sound card. >How-To-Repeat: Boot a kernel without device pcm into single or multiuser mode, kldload /modules/snd.ko, kldunload snd.ko and get kernel panic. Single mode was used to simplify things. A patch for src/sys/kern/kern_linker.c,1.41.2.3 was used to obtain detailed debug printfs: --- kern_linker.c.orig Tue Jul 13 22:20:11 2004 +++ kern_linker.c Wed Jul 14 22:06:25 2004 @@ -27,6 +27,7 @@ */ #include "opt_ddb.h" +#define KLD_DEBUG #include #include @@ -47,7 +48,7 @@ #include #ifdef KLD_DEBUG -int kld_debug = 0; +int kld_debug = 1; #endif MALLOC_DEFINE(M_LINKER, "kld", "kernel linker"); @@ -180,6 +181,7 @@ * Since some things care about execution order, this is the * operation which ensures continued function. */ + KLD_DPF(FILE, ("linker_file_sysuninit: ls_items=%p\n", sysuninits->ls_items)); for (sipp = (struct sysinit **)sysuninits->ls_items; *sipp; sipp++) { for (xipp = sipp + 1; *xipp; xipp++) { if ((*sipp)->subsystem > (*xipp)->subsystem || @@ -202,6 +204,7 @@ continue; /* skip dummy task(s)*/ /* Call function */ + KLD_DPF(FILE, ("linker_file_sysuninit: calling function %p, address stored at %p", (*sipp)->func,&((*sipp)->func))); (*((*sipp)->func))((*sipp)->udata); } } Here is a script of debug session made using serial console, 0xc1f5bb8c is a value of (*sipp)->func in the last loop of function linker_file_sysuninit() that triggers panic and 0xc200530c is an address of variable (*sipp)->func itself. Default: 1:ad(1,a)/boot/loader boot: -h Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (eu@grosbein.pp.ru, Tue Jul 6 02:01:55 KRAST 2004) Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 1 second... Type '?' for a list of commands, 'help' for more detailed help. ok boot -s Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-STABLE #11: Wed Jul 14 22:10:30 KRAST 2004 eu@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV Timecounter "i8254" frequency 1193168 Hz CPU: Intel Celeron (902.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 536805376 (524224K bytes) config> flags atkbd 0x0 config> quit sio0: gdb debugging port avail memory = 518860800 (506700K bytes) linker_make_file: new file, filename=kernel Preloaded elf kernel "kernel" at 0xc036a000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc036a0a8. VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc03023a2 (1000022) VESA: ATI RADEON 9200 Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 pci1: at 0.1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xe000-0xe01f irq 10 at device 7.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 uscanner0: Hewlett-Packard HP ScanJet 2200C, rev 1.10/1.00, addr 2 uhid0: American Power Conversion Back-UPS 500 FW: 6.5.I USB FW: c1, rev 1.10/1.00, addr 3, iclass 3/0 intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 fxp0: port 0xe400-0xe41f mem 0xef000000-0xef0fffff,0xef100000-0xef100fff irq 9 at device 16.0 on pci0 fxp0: Ethernet address 00:a0:c9:89:95:1f inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: