From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 00:48:37 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E312816A400; Sun, 21 Jan 2007 00:48:37 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from mx.isc.org (mx.isc.org [204.152.184.167]) by mx1.freebsd.org (Postfix) with ESMTP id C9BF613C44B; Sun, 21 Jan 2007 00:48:37 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id C59641140AD; Sat, 20 Jan 2007 23:51:21 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from [IPv6:2001:4f8:3:bb::37] (tardis.isc.org [IPv6:2001:4f8:3:bb::37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 8A8FEE601F; Sat, 20 Jan 2007 23:51:21 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <45B2AAF8.9010509@isc.org> Date: Sat, 20 Jan 2007 15:51:20 -0800 From: Peter Losher Organization: ISC User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4EE1BC23CE5320E9AFEE54CB" Cc: jhb@freebsd.org Subject: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 00:48:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EE1BC23CE5320E9AFEE54CB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a Matushita based USB CD/DVD-ROM drive that I have been using to install FreeBSD with for the better part of the last year. I just took delivery yesterday of both a HP Proliant 1450 G3 and a generic 1U server based on a Tyan Tomcat i845GV S3098 MB. In both cases, once the USB CD-ROM started loading either 6.1 or 6.2, I get a BTX halt: -=3D- from CD : CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 Consoles: internal video/keyboard int=3D0000000d err=3D00000000 efl=3D00030206 eip=3D000037d0 eax=3D00008001 ebx=3D00000000 ecx=3Da3900001 edx=3D0000009f esi=3D00000b32 edi=3D00000000 ebp=3D00000000 esp=3D000003d2 cs=3Df000 ds=3D3eca es=3D3eac fs=3D0000 gs=3D0000 ss=3D97fc cs:eip=3D2e 0f 01 16 f8 38 0f 20-c0 0c 01 0f 22 c0 b8 30 00 8e c0 0f 20 c0 24 fe-0f 22 c0 eb 00 66 58 c3 ss:esp=3D01 80 00 00 db 36 00 00-00 00 32 0b 00 00 00 00 00 00 f8 03 00 00 00 00-00 00 9f 00 00 00 01 00 BTX halted -=3D- Opening up the cases and plugging in a EIDE CD-ROM, the installer CD's work just fine. So it looks like perhaps there is some new BIOS instruction set that's causing the BTX loader some pain with a USB device= =2E Anyone encounter similar issues recently? Best Wishes - Peter --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enig4EE1BC23CE5320E9AFEE54CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFsqr4PtVx9OgEjQgRAvkhAKDMtTUGkOJAfO38PXI7r5dHa37xrwCgrw0C ThDRj7UThb4kNud3K0/ak8w= =K8CE -----END PGP SIGNATURE----- --------------enig4EE1BC23CE5320E9AFEE54CB-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 01:17:57 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 993D416A400 for ; Sun, 21 Jan 2007 01:17:57 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5E47013C441 for ; Sun, 21 Jan 2007 01:17:57 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H8RLI-000OgZ-3K for freebsd-stable@freebsd.org; Sun, 21 Jan 2007 01:17:56 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H8RLH-0006Za-Ku for freebsd-stable@freebsd.org; Sun, 21 Jan 2007 01:17:55 +0000 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Sun, 21 Jan 2007 01:17:55 +0000 Subject: IPv6 problems with 6.2-RELEASE ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 01:17:57 -0000 I have a network with a 6.2-RELEASE machine as a gateway to the outside world, and on the inside three machines hung off it, running OSX, XPx64 and 6.2-RELEASE as well. The gateway machine NATs the internal network under Ipv4 and runs IPv6 via 6to4. It has routing advertised on the internal network. This *should* work - the OSX machine gets an IPv6 address and runs fine. The Windows XP x64 machine also gets an IPv6 address, and though it has problems with some wwebsites, it also basically works. The only machine which refuses to work is the FreeBSD machine, which refuses to acquire an IPv6 address! I find it very opuzzling, as this has worked in the past, and also the one machine I nwould have thought I would have had no problems with would have been the FreeBSD box - especially as the gateway machine is running an identical OS! I am not even sure where to start debugging this - how can I make the interface try and get an IPv6 address whilst watching what it is doing ? Has anyone else had problems like this ? -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 01:28:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 582B216A401 for ; Sun, 21 Jan 2007 01:28:33 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by mx1.freebsd.org (Postfix) with ESMTP id 1B44A13C441 for ; Sun, 21 Jan 2007 01:28:33 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-24-27-51-69.austin.res.rr.com [24.27.51.69]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 46548778-1817707 for ; Sat, 20 Jan 2007 19:28:32 -0600 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.8/8.13.8) with ESMTP id l0L1SWFb009011 for ; Sat, 20 Jan 2007 19:28:32 -0600 (CST) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.8/8.13.8/Submit) id l0L1SVxj009010 for freebsd-stable@freebsd.org; Sat, 20 Jan 2007 19:28:31 -0600 (CST) (envelope-from brucegb) Date: Sat, 20 Jan 2007 19:28:31 -0600 From: Bruce Burden To: freebsd-stable@freebsd.org Message-ID: <20070121012831.GY89970@tigerfish2.my.domain> References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B0F758.70408@delphij.net> User-Agent: Mutt/1.4.2.2i Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 01:28:33 -0000 On Sat, Jan 20, 2007 at 12:52:40AM +0800, LI Xin wrote: > Jeff Royle wrote: > > aacu0: Adaptec Raid Controller 2.0.7-1 > > aacpu0: on aacu0 > > > > Going to continue testing with the newer driver. > > I have some preliminary work on merging the Adaptec driver: > > http://people.freebsd.org/~delphij/for_review/patch-aac-vendor-b11518 > Hi Jeff, LI, I think I missed some of this exchange, so please bear with me. I have an Adaptec 2130SLP + battery backup that I am thinking about using. I was going to go with a LSI/Dell card, but that seems to be giving me trouble. So, back to the 2130SLP. I have downloaded the FreeBSD x64 driver from Adaptec. I also have your patch, LI. Which one do you recommend? (FWIW, I am running FBSD 6.2-STABLE/amd64). LI, do I understand that I should download your aaccli change? I believe you indicated that this change was not MFC'd from -CURRENT in time for the 6.2 release, right? So I need to cvsup the ports? I have, I believe, an older Rev. 1 card, which I believe will work with the aaccli code, but it would be nice to have the ability to work with things moving forward. Thank you, Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 02:11:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A5F716A400 for ; Sun, 21 Jan 2007 02:11:18 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (24-123-13-51.irtnog.org [24.123.13.51]) by mx1.freebsd.org (Postfix) with ESMTP id F0AC713C459 for ; Sun, 21 Jan 2007 02:11:17 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from localhost (unknown [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 18FAB114E5 for ; Sat, 20 Jan 2007 20:46:02 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by localhost (cinep010bsdmx.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lR57+enshksc for ; Sat, 20 Jan 2007 20:45:56 -0500 (EST) Received: from irtnog.org (svr1.irtnog.org [10.63.0.100]) by mx1.irtnog.org (Postfix) with ESMTP id 6ED06114E3 for ; Sat, 20 Jan 2007 20:45:56 -0500 (EST) Date: Sat, 20 Jan 2007 20:45:44 -0500 Message-ID: MIME-Version: 1.0 In-Reply-To: <45B09856.8080600@IPricot.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: tcpdump, rl, sis, fxp and multicast problems X-MimeOLE: Produced By Microsoft Exchange V6.5 thread-index: Acc7saUuFDx1W8J6ROahG7ZTX5lNWwBS6Ckg References: <45AF8586.8080908@IPricot.com><20070118235125.GA80971@xor.obsecurity.org> <45B09856.8080600@IPricot.com> From: "Matthew X. Economou" To: Subject: RE: tcpdump, rl, sis, fxp and multicast problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 02:11:18 -0000 > not very important but wouldn't it be better to set the checksum > to 0 instead of some arbitrary (?) and confusing value then ? No, as not setting the checksum is a (minor) optimization. Setting that field to any arbitrary constant means at least one completely unnecessary CPU instruction per datagram. Best wishes, Matthew=20 --=20 "Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery." - A. C. Hobbs in _Locks and Safes_ (1853) From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 03:21:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E657E16A401 for ; Sun, 21 Jan 2007 03:21:26 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from public.aci.on.ca (aci.on.ca [205.207.148.251]) by mx1.freebsd.org (Postfix) with ESMTP id A8E3713C44C for ; Sun, 21 Jan 2007 03:21:26 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from (invalid client hostname: host address literal does not match remote client address)[127.0.0.1] (xtreme-156-171.dyn.aci.on.ca[69.17.156.171] port=4772) by public.aci.on.ca([205.207.148.252] port=25) via TCP with esmtp (3202 bytes) (sender: ) id for ; Sat, 20 Jan 2007 22:21:13 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2006-Feb-21) Message-ID: <45B2DC35.2080000@qwirky.net> Date: Sat, 20 Jan 2007 22:21:25 -0500 From: Jeff Royle User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bruce Burden References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <20070121012831.GY89970@tigerfish2.my.domain> In-Reply-To: <20070121012831.GY89970@tigerfish2.my.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0704-0, 18/01/2007), Outbound message X-Antivirus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@qwirky.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 03:21:27 -0000 Bruce Burden wrote: > On Sat, Jan 20, 2007 at 12:52:40AM +0800, LI Xin wrote: >> Jeff Royle wrote: >>> aacu0: Adaptec Raid Controller 2.0.7-1 >>> aacpu0: on aacu0 >>> >>> Going to continue testing with the newer driver. >> I have some preliminary work on merging the Adaptec driver: >> >> http://people.freebsd.org/~delphij/for_review/patch-aac-vendor-b11518 >> > > Hi Jeff, LI, > > I think I missed some of this exchange, so please bear > with me. > > I have an Adaptec 2130SLP + battery backup that I am > thinking about using. I was going to go with a LSI/Dell card, > but that seems to be giving me trouble. > > So, back to the 2130SLP. I have downloaded the FreeBSD > x64 driver from Adaptec. I also have your patch, LI. Which one > do you recommend? (FWIW, I am running FBSD 6.2-STABLE/amd64). The binary driver version is 2.0.7-1 x64 b11518 is what you have I assume. Which is accdu if you do load it. 6.2's driver is version 2.0.0-1 (aac) Xin's patch is to bring the aac driver up to version 2.0.7-1. Here is a copy from my dmesg: --- snip --- aac0: mem 0xfc600000-0xfc7fffff,0xfc5ff000-0xfc5fffff irq 24 at device 1.0 on pci2 aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.7-1 aacp0: on aac0 --- snip --- I am using his patch currently testing the card. Other then the bug I have mentioned in this thread, it has been stable for me. Note: I use i386 so I haven't tested this under amd64 (yet). > LI, do I understand that I should download your aaccli > change? I believe you indicated that this change was not MFC'd > from -CURRENT in time for the 6.2 release, right? So I need > to cvsup the ports? The patch Xin listed above is strictly for the driver and not the aacli. > I have, I believe, an older Rev. 1 card, which I believe > will work with the aaccli code, but it would be nice to have > the ability to work with things moving forward. Unfortunately for me in my testing my 2130S just does not work with aaccli. If you need help in patching let me know. Cheers, Jeff From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 05:25:34 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B593316A402 for ; Sun, 21 Jan 2007 05:25:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4440413C465 for ; Sun, 21 Jan 2007 05:25:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.6.102] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1H8VCe107L-0004aw; Sun, 21 Jan 2007 06:25:31 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Sun, 21 Jan 2007 06:24:57 +0100 User-Agent: KMail/1.9.5 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1312589.DbOBBIxenK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701210625.09523.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX18CKYqdJkvhab2wzZKpuiuZrbzodjvd0pzQrK79C3rvW07RMovMqTV/a8gOK8es/TnY+UnU/gjE0gjkImtsRRvFf+zVNzeuInTnAPyzCtFF4A== Cc: Pete French Subject: Re: IPv6 problems with 6.2-RELEASE ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 05:25:34 -0000 --nextPart1312589.DbOBBIxenK Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 21 January 2007 02:17, Pete French wrote: > I have a network with a 6.2-RELEASE machine as a gateway to > the outside world, and on the inside three machines hung off it, > running OSX, XPx64 and 6.2-RELEASE as well. The gateway machine > NATs the internal network under Ipv4 and runs IPv6 via 6to4. It > has routing advertised on the internal network. > > This *should* work - the OSX machine gets an IPv6 address and runs > fine. The Windows XP x64 machine also gets an IPv6 address, and > though it has problems with some wwebsites, it also basically works. > The only machine which refuses to work is the FreeBSD machine, which > refuses to acquire an IPv6 address! > > I find it very opuzzling, as this has worked in the past, and also > the one machine I nwould have thought I would have had no problems > with would have been the FreeBSD box - especially as the gateway > machine is running an identical OS! > > I am not even sure where to start debugging this - how can I make the > interface try and get an IPv6 address whilst watching what it is doing > ? Has anyone else had problems like this ? There has been some confusion a while back, I don't remember the details. As for debugging: 1) What do you have in rc.conf? ipv6_enable should be set to "YES" and=20 ipv6_network_interfaces should be "auto" or a list of the interfaces that=20 should use IPv6. 2) rtsol(8) is used to initiate stateless autoconfiguration. You might=20 want to try "rtsol -d interface". 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should take=20 care of this. 4) Check your firewall rules. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1312589.DbOBBIxenK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFsvk1XyyEoT62BG0RAum5AJ0a+1Q4v0v6hJHzeKWBpsI/o9PoFwCdG++0 sgUOJCW//dndkT8g58UKFrU= =hodi -----END PGP SIGNATURE----- --nextPart1312589.DbOBBIxenK-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 07:02:53 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A59216A401 for ; Sun, 21 Jan 2007 07:02:53 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 4174913C45A for ; Sun, 21 Jan 2007 07:02:53 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0L72qv8015564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jan 2007 23:02:52 -0800 Message-ID: <45B31017.20508@freebsd.org> Date: Sat, 20 Jan 2007 23:02:47 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Max Laier References: <200701210625.09523.max@love2party.net> In-Reply-To: <200701210625.09523.max@love2party.net> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig811CBF8DEBA16C5288BBE0E1" Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: IPv6 problems with 6.2-RELEASE ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 07:02:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig811CBF8DEBA16C5288BBE0E1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Max Laier wrote: > On Sunday 21 January 2007 02:17, Pete French wrote: >> I have a network with a 6.2-RELEASE machine as a gateway to >> the outside world, and on the inside three machines hung off it, >> running OSX, XPx64 and 6.2-RELEASE as well. The gateway machine >> NATs the internal network under Ipv4 and runs IPv6 via 6to4. It >> has routing advertised on the internal network. >> >> This *should* work - the OSX machine gets an IPv6 address and runs >> fine. The Windows XP x64 machine also gets an IPv6 address, and >> though it has problems with some wwebsites, it also basically works. >> The only machine which refuses to work is the FreeBSD machine, which >> refuses to acquire an IPv6 address! >> >> I find it very opuzzling, as this has worked in the past, and also >> the one machine I nwould have thought I would have had no problems >> with would have been the FreeBSD box - especially as the gateway >> machine is running an identical OS! >> >> I am not even sure where to start debugging this - how can I make the >> interface try and get an IPv6 address whilst watching what it is doing= >> ? Has anyone else had problems like this ? For the record, I haven't. I have a 6-STABLE machine built that does a fine job of handing out prefixes to clients (MacOS X and FreeBSD 6.X) doing stateless autoconfiguration. Although come to think of it, I haven't yet tested stateless autoconf with a 6.2 host lately. > There has been some confusion a while back, I don't remember the detail= s. >=20 > As for debugging: > 1) What do you have in rc.conf? ipv6_enable should be set to "YES" and= =20 > ipv6_network_interfaces should be "auto" or a list of the interfaces th= at=20 > should use IPv6. One change that was made with 6.2-RELEASE is that ipv6_enable needs to be set to "YES" in order for auto linklocal addresses to work (previously they were on by default). This change was made to improve the security of systems in common IPv4-only configurations, but it resulted in some unusual setups not working correctly. > 2) rtsol(8) is used to initiate stateless autoconfiguration. You might= =20 > want to try "rtsol -d interface". > 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should tak= e=20 > care of this. > 4) Check your firewall rules. Maybe tcpdump(8) on the internal interface of the gateway box to see if it's even getting the router solicitation message? I have seen some problems with gif(4) tunnels, discussed in other messages on this list, but this doesn't sound related to this situation. Bruce. --------------enig811CBF8DEBA16C5288BBE0E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsxAc2MoxcVugUsMRAsD2AKDLzpiQIPQ8+h4nosV/BIgWVS0DjgCghmcG YLghKz7Wp+CI4EhQ0QWLvQQ= =jCjH -----END PGP SIGNATURE----- --------------enig811CBF8DEBA16C5288BBE0E1-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 10:15:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A90EF16A400 for ; Sun, 21 Jan 2007 10:15:33 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 89D0013C43E for ; Sun, 21 Jan 2007 10:15:33 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l0L9eeFI037710; Sun, 21 Jan 2007 01:40:45 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l0L9eett037709; Sun, 21 Jan 2007 01:40:40 -0800 (PST) (envelope-from steve) Message-Id: <200701210940.l0L9eett037709@wattres.watt.com> X-Newsgroups: local.freebsd-stable In-Reply-To: <45A7B081.6040504@svcolo.com> From: steve@Watt.COM (Steve Watt) References: <45A78CA4.30903@sh.cvut.cz> Organization: Watt Consultants, San Jose, CA, USA Date: Sun, 21 Jan 2007 01:40:40 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: jrhett@svcolo.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (wattres.watt.com [127.0.0.1]); Sun, 21 Jan 2007 01:40:45 -0800 (PST) X-Archived: 1169372445.812478125@wattres.Watt.COM Cc: freebsd-stable@freebsd.org Subject: Re: any real documentation of the boot2 prompt? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 10:15:33 -0000 In <45A7B081.6040504@svcolo.com>, jrhett@svcolo.com wrote: >Václav Haisman wrote: >> What does lsdev or whatever it was say? Does it show any devices besides >> the raw disks? > >So I booted from CD and ran lsdev, and showed something like this (from >memory) > >0: Drive A >2: Disk 0 > 1: FFS You need to get into your SCSI BIOS (don't know what the key sequence is for 3ware, it's ^A for Adaptec) at the correct time and enable the disk for booting. As shown here, there's no chance of it being bootable. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 10:19:31 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78E1616A404 for ; Sun, 21 Jan 2007 10:19:31 +0000 (UTC) (envelope-from ced@grumly.eu.org) Received: from spike.grumly.eu.org (spike.grumly.eu.org [195.5.253.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4766D13C467 for ; Sun, 21 Jan 2007 10:19:31 +0000 (UTC) (envelope-from ced@grumly.eu.org) Received: by spike.grumly.eu.org (Postfix, from userid 1001) id 6DBB0117B2; Sun, 21 Jan 2007 11:02:20 +0100 (CET) Date: Sun, 21 Jan 2007 11:02:20 +0100 From: Cedric Tabary To: freebsd-stable@freebsd.org Message-ID: <20070121100220.GA92448@efrei.fr> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: 6.2-prerelease from 8 jan crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 10:19:31 -0000 uname -a : FreeBSD xxx 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #21: Mon Jan 8 14:37:57 CET 2007 kgdb backtrace : Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06efa29 stack pointer = 0x28:0xe538cc60 frame pointer = 0x28:0xe538cc74 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 5 (thread taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 8d10h42m51s Dumping 2047 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 2047MB (523968 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06fa662 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06faa13 in panic (fmt=0xc0996d81 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0936c1d in trap_fatal (frame=0xe538cc20, eva=0) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc09362bd in trap (frame= {tf_fs = 8, tf_es = -964755416, tf_ds = -449314776, tf_edi = -964734208, tf_esi = 4, tf_ebp = -449262476, tf_isp = -449262516, tf_ebx = -848968900, tf_edx = 6, tf_ecx = -964734208, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1066468823, tf_cs = 32, tf_eflags = 65538, tf_esp = -848968900, tf_ss = -933423232}) at /usr/src/sys/i386/i386/trap.c:270 #5 0xc092004a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc06efa29 in _mtx_lock_sleep (m=0xcd65c33c, tid=3330233088, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 #7 0xc074cfd4 in unp_gc (arg=0x0, pending=2) at /usr/src/sys/kern/uipc_usrreq.c:1714 #8 0xc07209d1 in taskqueue_run (queue=0xc6848200) at /usr/src/sys/kern/subr_taskqueue.c:257 #9 0xc0721000 in taskqueue_thread_loop (arg=0x1) at /usr/src/sys/kern/subr_taskqueue.c:376 #10 0xc06df223 in fork_exit (callout=0xc0720f40 , arg=0x1, frame=0x1) at /usr/src/sys/kern/kern_fork.c:821 #11 0xc09200ac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 Any idea what happened ? Cédric From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 12:12:29 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79C5016A402 for ; Sun, 21 Jan 2007 12:12:29 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from daemon.crashmail.de (daemon.crashmail.de [88.198.125.180]) by mx1.freebsd.org (Postfix) with ESMTP id 4377913C45B for ; Sun, 21 Jan 2007 12:12:28 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from localhost (dslb-082-083-102-164.pools.arcor-ip.net [82.83.102.164]) by daemon.crashmail.de (Postfix) with ESMTP id 583F664B08 for ; Sun, 21 Jan 2007 12:47:14 +0100 (CET) Received: by crashmail.de (OpenXP/4.10.7328 (FreeBSD) (i386)); 21 Jan 2007 12:46:54 +0100 Date: 21 Jan 2007 12:46:00 +0100 From: steve.tell@crashmail.de (Stefan 'Steve' Tell) To: freebsd-stable@freebsd.org Message-ID: User-Agent: OpenXP/4.10.7328 (FreeBSD) (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: The Third Place X-Homepage: http://blog.crashmail.de Subject: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 12:12:29 -0000 Hi, I have a Notebook[1] with a Realtek 8136 chipset. While trying to install FreeBSD or running a LiveCD like Freesbie or DesktopBSD it results in a fatal trap. This is the output of a running Kubuntu installation of lspci: 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8136 (rev 01) (whole output at: http://zeus.crashmail.de/nopaste/?494) I got this error message: NMI ISA b0, EISA ff RAM parity error, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode instruction pointer = 0x20:0xc06021ed stack pointer = 0x28:0xe9452bbc frame pointer = 0x28:0xe9452be0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 312 (ifconfig) trap number = 19 panic: non-maskable interrupt trap When I try to Configure -> Networking with the FreeBSD installer, it crashes after choosing "DCHP?" -> yes ... Any hints? Known behavior? What information do you need? -------------- [1] = Medion MD 98000 -- By(t)e, Stefan 'Steve' Tell | http://blog.crashmail.de -------------------------------| http://www.freebsd.org Powered by FreeBSD/i386 | http://www.naturefund.de From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 15:01:36 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F72B16A402 for ; Sun, 21 Jan 2007 15:01:36 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id 98B4513C471 for ; Sun, 21 Jan 2007 15:01:35 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 2264 invoked from network); 21 Jan 2007 18:01:33 +0300 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 21 Jan 2007 18:01:33 +0300 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 170702, updated: 21.01.2007] Message-ID: <003601c73d6d$0620c910$0c00a8c0@Artem> From: "Artem Kuchin" To: "Mark Kirkwood" References: <01c501c73a58$2c546550$0c00a8c0@Artem> <45B280C5.30106@paradise.net.nz> Date: Sun, 21 Jan 2007 18:00:31 +0300 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: freebsd-stable@freebsd.org Subject: Re: Cannot start install cd of 6.2-R at all X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 15:01:36 -0000 Mark Kirkwood wrote: > Artem Kuchin wrote: >> Hello! >> >> I am having a VERY weird problem. >> >> The pc config is: >> >> 1) Celeron 1+ GHZ >> 2) Intel PCI ethernet nic >> 3) Fasttrak TX2000 raid + 2 mirrored disks (seagate 80gb) >> 4) teac dvd driver >> 5) 512 MB ram >> 6) Chaintech montherboard (old one) >> >> also tried on gigabyte motherboard >> >> I insert boot cd and when it starts loading a get a dump >> of cpu register scrolling crazy on the screen. >> >> If i delete TX2000 the installer loads fine. >> >> Any idea what is happening and how to SOLVE it? >> >> > > I have seen this with a Tyan PIII board + TX2000. In my case re-trying > the boot from cd several times would *eventually* get a working > installer session. (If you search the archives you'll see several > cases of folks encountering this). Unfortunately I don't know of any > solution. > > A (tedious) workaround (in case repeated attempts always fail for > you), is to install a minimal system off an earlier version of > FreeBSD and run the installer off the installed system - or just src > upgrade to the version you want. I found that the 4.x, 5.0, 5.1 and > 5.2 cd's all worked fine - but 5.3 onwards and 6.x would register > dump. There is a better workaround which i used. A simple start of installer from 4 floppies. Then install the whole system from CD-ROM. It does work but insolved copying of floppy images onto the disks. However is it a very annoying problem which i have been encountering since 5.0-RELEASE. The bootloader failed when trying to load installed from CD-ROM on pretty much every PIII and old Celeron pc which i tried. (it is about 6 machines by now). Very weird and i have no idea to how help to solve the problem. -- Regards Artem From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 15:01:47 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34D9316A573 for ; Sun, 21 Jan 2007 15:01:47 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 10EF013C467 for ; Sun, 21 Jan 2007 15:01:46 +0000 (UTC) (envelope-from louie@transsys.com) Received: from g5.transsys.com (c-69-141-143-164.hsd1.nj.comcast.net [69.141.143.164]) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 8403F1CC23; Sun, 21 Jan 2007 09:32:11 -0500 (EST) Message-ID: <45B3796A.3020409@transsys.com> Date: Sun, 21 Jan 2007 09:32:10 -0500 From: Louis Mamakos User-Agent: Thunderbird 2.0b1 (Macintosh/20061206) MIME-Version: 1.0 To: "Matthew X. Economou" References: <45AF8586.8080908@IPricot.com><20070118235125.GA80971@xor.obsecurity.org> <45B09856.8080600@IPricot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: tcpdump, rl, sis, fxp and multicast problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 15:01:47 -0000 Matthew X. Economou wrote: >> not very important but wouldn't it be better to set the checksum >> to 0 instead of some arbitrary (?) and confusing value then ? > > No, as not setting the checksum is a (minor) optimization. Setting that > field to any arbitrary constant means at least one completely > unnecessary CPU instruction per datagram. > > Best wishes, > Matthew > However, since it is a 1's complement checksum, there is a distinguished value (all zero bits) that you could set the checksum field to that wouldn't occur for a normal computed checksum. Since the presence of a checksum is mandatory for TCP, you can use this trick and external software could "know" that it's a distinguished value. This is similar to UDP, where the protocol allows the "no checksum present" case by setting the checksum field to all zero bits. I suspect the overhead isn't the CPU instruction, but the memory reference. If you manipulate the checksum field to the distinguished value at the time the other fields are written, they they'll all get written out to memory when the cache line is flushed. You've already got to initialize the Urgent Pointer field, which is the other 16 bits in the same 32 bit word. If you were really clever, you could make a union to cover both fields and zero both out in the same store instruction. louie From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 16:05:18 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDCDD16A402 for ; Sun, 21 Jan 2007 16:05:18 +0000 (UTC) (envelope-from burningc@sdf.lonestar.org) Received: from sdf.lonestar.org (mx.freeshell.ORG [192.94.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE8E13C43E for ; Sun, 21 Jan 2007 16:05:18 +0000 (UTC) (envelope-from burningc@sdf.lonestar.org) Received: from sdf.lonestar.org (burningc@sdf.lonestar.org [192.94.73.1]) by sdf.lonestar.org (8.13.5.20060308/8.13.8) with ESMTP id l0LFs0Jm006116 for ; Sun, 21 Jan 2007 15:54:00 GMT Received: (from burningc@localhost) by sdf.lonestar.org (8.13.8/8.12.8/Submit) id l0LFsMYL004806; Sun, 21 Jan 2007 15:54:22 GMT Date: Sun, 21 Jan 2007 15:54:22 +0000 (UTC) From: Glenn Becker To: FreeBSD Stable List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Firefox keeps beeping at me ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 16:05:18 -0000 All - I've been away from FreeBSD for some time and have been updating my installation, getting used to the ways of portupgrade, etc. Have noticed that Firefox keeps emitting what sound like console beeps - I haven't established much of a pattern for these though it always happens when I close the app. Is there a way to kill these? Apologies in advance if this is a dopey question. Obviously more an annoyance than anything. Thanks, Glenn +-----------------------------------------------------+ Glenn Becker - burningc@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org +-----------------------------------------------------+ From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 16:56:34 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 850BC16A401; Sun, 21 Jan 2007 16:56:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from home.quip.cz (grimm.quip.cz [213.220.192.218]) by mx1.freebsd.org (Postfix) with ESMTP id 43F7913C448; Sun, 21 Jan 2007 16:56:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (qwork.quip.test [192.168.1.2]) by home.quip.cz (Postfix) with ESMTP id D3CDE62D8; Sun, 21 Jan 2007 17:35:03 +0100 (CET) Message-ID: <45B39637.9060706@quip.cz> Date: Sun, 21 Jan 2007 17:35:03 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Peter Losher References: <45B2AAF8.9010509@isc.org> In-Reply-To: <45B2AAF8.9010509@isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 16:56:34 -0000 Peter Losher wrote: > I have a Matushita based USB CD/DVD-ROM drive that I have been using to > install FreeBSD with for the better part of the last year. I just took > delivery yesterday of both a HP Proliant 1450 G3 and a generic 1U server > based on a Tyan Tomcat i845GV S3098 MB. > > In both cases, once the USB CD-ROM started loading either 6.1 or 6.2, I > get a BTX halt: > > -=- > from CD : CD Loader 1.2 > > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > Relocating the loader and the BTX > Starting the BTX loader > > BTX loader 1.00 BTX version is 1.01 > Consoles: internal video/keyboard > > int=0000000d err=00000000 efl=00030206 eip=000037d0 > eax=00008001 ebx=00000000 ecx=a3900001 edx=0000009f > esi=00000b32 edi=00000000 ebp=00000000 esp=000003d2 > cs=f000 ds=3eca es=3eac fs=0000 gs=0000 ss=97fc > cs:eip=2e 0f 01 16 f8 38 0f 20-c0 0c 01 0f 22 c0 b8 30 > 00 8e c0 0f 20 c0 24 fe-0f 22 c0 eb 00 66 58 c3 > ss:esp=01 80 00 00 db 36 00 00-00 00 32 0b 00 00 00 00 > 00 00 f8 03 00 00 00 00-00 00 9f 00 00 00 01 00 > BTX halted > -=- > > Opening up the cases and plugging in a EIDE CD-ROM, the installer CD's > work just fine. So it looks like perhaps there is some new BIOS > instruction set that's causing the BTX loader some pain with a USB device. > > Anyone encounter similar issues recently? > > Best Wishes - Peter Hi, this is well known problem discussed a few months ago: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030897.html sterted at semptember http://lists.freebsd.org/pipermail/freebsd-qa/2006-September/000783.html Partial fix could be to use GRUB (it helps me on Sun, but does not help on HP servers) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 17:04:47 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED6016A405 for ; Sun, 21 Jan 2007 17:04:47 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAEB13C448 for ; Sun, 21 Jan 2007 17:04:46 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.8/8.13.8) with ESMTP id l0LGlamv097898; Sun, 21 Jan 2007 16:47:37 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <45B39923.8030505@infracaninophile.co.uk> Date: Sun, 21 Jan 2007 16:47:31 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 1.5.0.9 (X11/20070120) MIME-Version: 1.0 To: Steve Watt References: <45A78CA4.30903@sh.cvut.cz> <200701210940.l0L9eett037709@wattres.watt.com> In-Reply-To: <200701210940.l0L9eett037709@wattres.watt.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB57F4FE4AB3684CFFB48E982" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Sun, 21 Jan 2007 16:47:52 +0000 (GMT) X-Virus-Scanned: ClamAV 0.88.7/2475/Sun Jan 21 14:29:40 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_POLICY_TESTING, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on happy-idiot-talk.infracaninophile.co.uk Cc: jrhett@svcolo.com, freebsd-stable@freebsd.org Subject: Re: any real documentation of the boot2 prompt? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 17:04:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB57F4FE4AB3684CFFB48E982 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Steve Watt wrote: > You need to get into your SCSI BIOS (don't know what the key > sequence is for 3ware, it's ^A for Adaptec)=20 Alt-F3 funnily enough... Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enigB57F4FE4AB3684CFFB48E982 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFs5ko8Mjk52CukIwRCP1TAJ4uLBBnlyCWxXLu4isg+3LodAt/FQCfY8Rq SMJ2s5ml0/Ur2GO7jC+qEh4= =Dlyn -----END PGP SIGNATURE----- --------------enigB57F4FE4AB3684CFFB48E982-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 17:17:11 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9826116A400 for ; Sun, 21 Jan 2007 17:17:11 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 420B713C43E for ; Sun, 21 Jan 2007 17:17:11 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <45B39891.4030207@intersonic.se> Date: Sun, 21 Jan 2007 17:45:05 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.9 (X11/20070120) MIME-Version: 1.0 To: Glenn Becker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Firefox keeps beeping at me ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 17:17:11 -0000 Glenn Becker wrote: > > All - > > I've been away from FreeBSD for some time and have been updating my > installation, getting used to the ways of portupgrade, etc. > > Have noticed that Firefox keeps emitting what sound like console beeps - > I haven't established much of a pattern for these though it always > happens when I close the app. > > Is there a way to kill these? Apologies in advance if this is a dopey > question. Obviously more an annoyance than anything. perhaps -questions is more appropriate... Anyway, that makes two of us - mine beeps too - when sending and reading mails. No idea why though, sorry. Anyone? From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 17:36:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E8BA16A409 for ; Sun, 21 Jan 2007 17:36:42 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from daemon.crashmail.de (daemon.crashmail.de [88.198.125.180]) by mx1.freebsd.org (Postfix) with ESMTP id CB0B413C45E for ; Sun, 21 Jan 2007 17:36:41 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from localhost (dslb-082-083-102-164.pools.arcor-ip.net [82.83.102.164]) by daemon.crashmail.de (Postfix) with ESMTP id EA5D764B08 for ; Sun, 21 Jan 2007 18:36:39 +0100 (CET) Received: by crashmail.de (OpenXP/4.10.7328 (FreeBSD) (i386)); 21 Jan 2007 18:36:20 +0100 Date: 21 Jan 2007 18:36:00 +0100 From: steve.tell@crashmail.de (Stefan 'Steve' Tell) To: freebsd-stable@freebsd.org Message-ID: In-Reply-To: User-Agent: OpenXP/4.10.7328 (FreeBSD) (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: The Third Place X-Homepage: http://blog.crashmail.de Subject: Re: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 17:36:42 -0000 * Stefan 'Steve' Tell wrote: > 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device > 8136 (rev 01) (whole output at: http://zeus.crashmail.de/nopaste/?494) pciconf -vl re0@pci4:0:0: class=0x020000 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 class = network subclass = ethernet none3@pci6:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 class = network -- By(t)e, Stefan 'Steve' Tell | http://blog.crashmail.de -------------------------------| http://www.freebsd.org Powered by FreeBSD/i386 | http://www.naturefund.de From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 18:09:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEBE416A402 for ; Sun, 21 Jan 2007 18:09:38 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 94C1B13C43E for ; Sun, 21 Jan 2007 18:09:38 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H8h8L-0006BU-5d; Sun, 21 Jan 2007 18:09:37 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H8h8K-000868-Oz; Sun, 21 Jan 2007 18:09:36 +0000 To: freebsd-stable@freebsd.org, max@love2party.net In-Reply-To: <200701210625.09523.max@love2party.net> Message-Id: From: Pete French Date: Sun, 21 Jan 2007 18:09:36 +0000 Cc: Subject: Re: IPv6 problems with 6.2-RELEASE ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 18:09:39 -0000 > 2) rtsol(8) is used to initiate stateless autoconfiguration. You might=20 > want to try "rtsol -d interface". Aha... this does not work... > 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should take=20 > care of this. ...because this is 0 All of which appears to be because a spurious 'ipv6_gateway_enable="YES"' has found it's way into my rc.conf due to cut-n-paste. Which is interesting though, since even when I spotted it, it hadn;'t occurred to me that it would prevent the auto configuration working. Thnaks for the help, all works fine now. -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 18:45:04 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D08CD16A400 for ; Sun, 21 Jan 2007 18:45:04 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC5C13C459 for ; Sun, 21 Jan 2007 18:45:04 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id A331C1A0007B4 for ; Sun, 21 Jan 2007 10:14:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rNeBwAjYQk8K for ; Sun, 21 Jan 2007 10:14:30 -0800 (PST) Received: from webmail.sd73.bc.ca (webmail.sd73.bc.ca [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id D088F1A000B2C for ; Sun, 21 Jan 2007 10:14:29 -0800 (PST) Received: from 24.71.119.183 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Sun, 21 Jan 2007 10:14:29 -0800 (PST) Message-ID: <61725.24.71.119.183.1169403269.squirrel@webmail.sd73.bc.ca> In-Reply-To: <45B39923.8030505@infracaninophile.co.uk> References: <45A78CA4.30903@sh.cvut.cz> <200701210940.l0L9eett037709@wattres.watt.com> <45B39923.8030505@infracaninophile.co.uk> Date: Sun, 21 Jan 2007 10:14:29 -0800 (PST) From: "Freddie Cash" To: stable@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: any real documentation of the boot2 prompt? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 18:45:04 -0000 On Sun, January 21, 2007 8:47 am, Matthew Seaman wrote: > Steve Watt wrote: >> You need to get into your SCSI BIOS (don't know what the key >> sequence is for 3ware, it's ^A for Adaptec) > > Alt-F3 > funnily enough... It's ALT+3 for all our 3Ware Escalade cards (PATA/SATA). ---- Freddie Cash fcash@ocis.net From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 20:35:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7CA516A401; Sun, 21 Jan 2007 20:35:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (springbank.echomania.com [82.94.255.114]) by mx1.freebsd.org (Postfix) with ESMTP id A1BDA13C455; Sun, 21 Jan 2007 20:35:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 5EB69A70C0; Sun, 21 Jan 2007 21:17:24 +0100 (CET) Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27582-04-3; Sun, 21 Jan 2007 21:17:23 +0100 (CET) Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTP id 43474A707D; Sun, 21 Jan 2007 21:17:23 +0100 (CET) Message-ID: <45B3CA56.4040106@andric.com> Date: Sun, 21 Jan 2007 21:17:26 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b1 (Windows/20070106) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> In-Reply-To: <45B251A5.4000209@freebsd.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 20:35:19 -0000 Bruce A. Mah wrote: >> I remember Dimitry Andric reported the same problem on -stable on 30 >> Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do >> you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEASE >> did not have the change, I thought there was no problem. ... > On my 6-STABLE system (which appears to be working fine), I still have > the change from 1.48.2.16, I only backed out .15 and .14. I didn't try > my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. > > Hmmm...I was looking for that bug report before, but I couldn't find it. > It's not clear to me how 1.48.2.16 is involved...hmmm... I originally reported this here: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html and later I found out it was caused by commit 1.48.2.16: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html I'll shoot in a regular PR later tonight... From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 23:12:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C4F016A47A for ; Sun, 21 Jan 2007 23:12:50 +0000 (UTC) (envelope-from SRS1=2a0af5a13ac547e5f8d0e6e2ba2bb9fb83795734=es.net==2a0af5a13ac547e5f8d0e6e2ba2bb9fb83795734=222=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id B3D6613C53A for ; Sun, 21 Jan 2007 23:12:45 +0000 (UTC) (envelope-from SRS1=2a0af5a13ac547e5f8d0e6e2ba2bb9fb83795734=es.net==2a0af5a13ac547e5f8d0e6e2ba2bb9fb83795734=222=es.net=oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id AYV18703 for ; Sun, 21 Jan 2007 15:00:03 -0800 Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id AYV54501 for ; Sun, 21 Jan 2007 15:00:01 -0800 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id AYV59500; Sun, 21 Jan 2007 15:00:00 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6141345053; Sun, 21 Jan 2007 15:00:00 -0800 (PST) To: Cedric Tabary In-Reply-To: Your message of "Sun, 21 Jan 2007 11:02:20 +0100." <20070121100220.GA92448@efrei.fr> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1169420400_89300P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 21 Jan 2007 15:00:00 -0800 From: "Kevin Oberman" Message-Id: <20070121230000.6141345053@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: 6.2-prerelease from 8 jan crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 23:12:51 -0000 --==_Exmh_1169420400_89300P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 21 Jan 2007 11:02:20 +0100 > From: Cedric Tabary > Sender: owner-freebsd-stable@freebsd.org > > > uname -a : > FreeBSD xxx 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #21: Mon Jan 8 14:37:57 CET 2007 > > kgdb backtrace : > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 06 > fault virtual address = 0x104 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06efa29 > stack pointer = 0x28:0xe538cc60 > frame pointer = 0x28:0xe538cc74 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 5 (thread taskq) > trap number = 12 > panic: page fault > cpuid = 1 John Baldwin committed a fix to -stable a week or two ago that fixed this for me. It was MFCed on Jan. 12, so you don't have it. Patches to: /sys/kern/kern_descrip.c /sys/kern/uipc_syscalls.c -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1169420400_89300P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFFs/Bwkn3rs5h7N1ERAoT7AJ4wc7c+a2/9UgDOO9EGuamiiew7KgCfW/un +IsVV1USRjzPAo3pg3o7rMs= =sWJJ -----END PGP SIGNATURE----- --==_Exmh_1169420400_89300P-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 00:10:10 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E9BC16A401 for ; Mon, 22 Jan 2007 00:10:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E949E13C44B for ; Mon, 22 Jan 2007 00:10:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 5665B8CA1D; Sun, 21 Jan 2007 18:39:05 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sun, 21 Jan 2007 18:39:05 -0500 X-Sasl-enc: mMZPdLX94DPaNjCFvAQbslY5INvZOF/GgbkUuDrh0OxC 1169422745 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 14E1F14D9D; Sun, 21 Jan 2007 18:39:03 -0500 (EST) Message-ID: <45B3F996.8030303@FreeBSD.org> Date: Sun, 21 Jan 2007 23:39:02 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Peter Losher References: <45B2AAF8.9010509@isc.org> In-Reply-To: <45B2AAF8.9010509@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 00:10:10 -0000 Peter Losher wrote: > In both cases, once the USB CD-ROM started loading either 6.1 or 6.2, I > get a BTX halt: > Known issue. The btx code can't deal with BIOSes which want to enter protected mode to service the I/Os. USB support in most BIOSen generally does this. I see the same issue with FreeBSD's pxeboot and the PXE client in Etherboot. Regards, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 00:24:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7447816A400 for ; Mon, 22 Jan 2007 00:24:18 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 25DA313C459 for ; Mon, 22 Jan 2007 00:24:18 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1126195wxc for ; Sun, 21 Jan 2007 16:24:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YmPxoeXhU/n8q3HtPTjGlnnIHcji+OjSlCCG5cuSjNM5dWxTge1uDNXeWp2/K6szalj86EVSIhSTv+L43ZY9geF3BfMMY+xKERnTjVGE4t0hyVqFnufxWKtff5dEnR5Oc3js7LTjreDhrm2nNOeWpCw5M3OqEO1nhsAO4XFUvNo= Received: by 10.70.61.1 with SMTP id j1mr9490748wxa.1169423897750; Sun, 21 Jan 2007 15:58:17 -0800 (PST) Received: by 10.70.14.13 with HTTP; Sun, 21 Jan 2007 15:58:17 -0800 (PST) Message-ID: <585602e10701211558s66d2fc82vd25cc32a4c17b7ab@mail.gmail.com> Date: Mon, 22 Jan 2007 00:58:17 +0100 From: "=?ISO-8859-1?Q?Matthias_Gamsj=E4ger?=" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Harddisk gone. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 00:24:18 -0000 HI, I am a user of freebsd for couple of year now and had recently made a fresh install with 6.2. Everything worked as it always did but as i booted the system today it seems that the kernel couldnt find my harddisk. Strange thing is: - I get the bootloader (dual boot with windows) - windows works just fine - I can access all my files on the hd through the bootloader - the kernel boots of the harddisk and finds the (s)ata-controllers - it finds the cdrom attachet to the ata0 - it finds my sata disk but my first pata disk seems to be gone. The bootscript ends because there is no ad0 (dev isnt created so cant do manualy) I tried to boot 2 live-cdroms (freesbie and frenzy) with the same result. System: Nforce 4 motherboard AMD X2 4600+ 1GB ram GF 7900tgo PATA Maxtor hd (which is gone) SATA WD (works fine) Anyone got any idea whay might cause this? From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 00:32:29 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF37B16A400 for ; Mon, 22 Jan 2007 00:32:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 2C5DB13C455 for ; Mon, 22 Jan 2007 00:32:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 3533 invoked by uid 399); 22 Jan 2007 00:32:28 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Jan 2007 00:32:28 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45B40619.30206@FreeBSD.org> Date: Sun, 21 Jan 2007 16:32:25 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1169038057.23831.24.camel@richard02> <20070117142552.GC1225@dkirhlarov.mow.oilspace.com> <1169044590.23831.38.camel@richard02> <45AE68DF.5010700@FreeBSD.org> <1169110278.20706.58.camel@chaffinch> <20070119170012.GB1532@roadrunner.q.local> In-Reply-To: <20070119170012.GB1532@roadrunner.q.local> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Failover-HA-Setup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 00:32:29 -0000 Ulrich Spoerlein wrote: > Only two options remain: modify existing mysql-server script (bad idea, > will be overwritten on update) or go through a proxy script which > "transforms" start|stop -> onestart|onestop > > You could also alter the environment of heartbeat (it's really just a > bunch of poorly written shell scripts) and set mysql_enable=YES there, > but that'd be just as fragile as rewriting the existing mysql-server > script. Yeah, I thin we're definitely in territory that is not covered by the boot scripts as written here. This thread has got me thinking though, how useful would something like 'foo_enable=conditional' be? What I'm thinking is that you could define a script in foo_condition that rc.d would run. We could either do a straight yes/no, where if the script exits successfully (exit code 0) then we run the service, and if it fails (non-zero exit code) we don't. OR, we could have the script return the argument we want to feed that service's startup script. I think that may have some utility here, what do y'all think? Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 01:33:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B91016A403 for ; Mon, 22 Jan 2007 01:33:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3238813C448 for ; Mon, 22 Jan 2007 01:33:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1139040wxc for ; Sun, 21 Jan 2007 17:33:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=bwP/PpwHY77pY2HMwJgFAa7AQvdemH6vaG8frPmPSeRozbLfFCacGTehIKcR2u+nzP/4PKB4M8exeKGhxzywvxD41SSeC7+4Vi4ouN9mgdPbDNM3Apu9xX1wPMd9f/GZuMo6dLTkqL03eMjk7/6/t81UYYeiC4Kj4uVQS4EZkXo= Received: by 10.70.125.11 with SMTP id x11mr9645772wxc.1169429602603; Sun, 21 Jan 2007 17:33:22 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 33sm8622361wra.2007.01.21.17.33.20; Sun, 21 Jan 2007 17:33:21 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l0M1YHWV029621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 10:34:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0M1YGdY029620; Mon, 22 Jan 2007 10:34:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 22 Jan 2007 10:34:16 +0900 From: Pyun YongHyeon To: "Stefan 'Steve' Tell" Message-ID: <20070122013416.GA29223@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 01:33:26 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 21, 2007 at 06:36:00PM +0100, Stefan 'Steve' Tell wrote: > * Stefan 'Steve' Tell wrote: > > > 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device > > 8136 (rev 01) (whole output at: http://zeus.crashmail.de/nopaste/?494) > > pciconf -vl > > re0@pci4:0:0: class=0x020000 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 > class = network > subclass = ethernet > none3@pci6:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 > class = network > How about attached one? -- Regards, Pyun YongHyeon --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_re.c.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.82 diff -u -r1.82 if_re.c --- if_re.c 16 Jan 2007 20:35:23 -0000 1.82 +++ if_re.c 22 Jan 2007 01:32:23 -0000 @@ -2319,6 +2319,20 @@ re_tx_list_init(sc); /* + * Load the addresses of the RX and TX lists into the chip. + */ + + CSR_WRITE_4(sc, RL_RXLIST_ADDR_HI, + RL_ADDR_HI(sc->rl_ldata.rl_rx_list_addr)); + CSR_WRITE_4(sc, RL_RXLIST_ADDR_LO, + RL_ADDR_LO(sc->rl_ldata.rl_rx_list_addr)); + + CSR_WRITE_4(sc, RL_TXLIST_ADDR_HI, + RL_ADDR_HI(sc->rl_ldata.rl_tx_list_addr)); + CSR_WRITE_4(sc, RL_TXLIST_ADDR_LO, + RL_ADDR_LO(sc->rl_ldata.rl_tx_list_addr)); + + /* * Enable transmit and receive. */ CSR_WRITE_1(sc, RL_COMMAND, RL_CMD_TX_ENB|RL_CMD_RX_ENB); @@ -2335,6 +2349,9 @@ RL_TXCFG_CONFIG|RL_LOOPTEST_ON_CPLUS); } else CSR_WRITE_4(sc, RL_TXCFG, RL_TXCFG_CONFIG); + + CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); + CSR_WRITE_4(sc, RL_RXCFG, RL_RXCFG_CONFIG); /* Set the individual bit to receive frames for this host only. */ @@ -2389,21 +2406,6 @@ /* Enable receiver and transmitter. */ CSR_WRITE_1(sc, RL_COMMAND, RL_CMD_TX_ENB|RL_CMD_RX_ENB); #endif - /* - * Load the addresses of the RX and TX lists into the chip. - */ - - CSR_WRITE_4(sc, RL_RXLIST_ADDR_HI, - RL_ADDR_HI(sc->rl_ldata.rl_rx_list_addr)); - CSR_WRITE_4(sc, RL_RXLIST_ADDR_LO, - RL_ADDR_LO(sc->rl_ldata.rl_rx_list_addr)); - - CSR_WRITE_4(sc, RL_TXLIST_ADDR_HI, - RL_ADDR_HI(sc->rl_ldata.rl_tx_list_addr)); - CSR_WRITE_4(sc, RL_TXLIST_ADDR_LO, - RL_ADDR_LO(sc->rl_ldata.rl_tx_list_addr)); - - CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); #ifdef RE_TX_MODERATION /* --82I3+IH0IqGh5yIs-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 02:02:14 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB3CA16A405 for ; Mon, 22 Jan 2007 02:02:14 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from mail.coruscant.info (coruscant.coruscant.info [88.198.12.237]) by mx1.freebsd.org (Postfix) with ESMTP id 31D2A13C457 for ; Mon, 22 Jan 2007 02:02:14 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from localhost (localhost [127.0.0.1]) by mail.coruscant.info (Postfix) with SMTP id 922323CC454 for ; Mon, 22 Jan 2007 02:44:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.coruscant.info (Postfix) with ESMTP id BC3CE3CC452 for ; Mon, 22 Jan 2007 02:44:17 +0100 (CET) X-Virus-Scanned: amavisd-new at coruscant.info Received: from mail.coruscant.info ([127.0.0.1]) by localhost (mail.coruscant.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmqBbc-Mp40B for ; Mon, 22 Jan 2007 02:44:15 +0100 (CET) Received: from [10.8.0.2] (chimaere.ninth-art.net [10.8.0.2]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.coruscant.info (Postfix) with ESMTP id DE6EE3CC451 for ; Mon, 22 Jan 2007 02:44:14 +0100 (CET) From: Georg Bege To: freebsd-stable@freebsd.org Date: Mon, 22 Jan 2007 02:42:54 +0100 Message-Id: <1169430174.3433.5.camel@cerberus.ninth-art.de> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jan 22 02:44:18 2007 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 45b416f2896269661917265 X-DSPAM-Factors: 27, From*ninth+art.de>, 0.40000, could, 0.40000, but, 0.40000, but, 0.40000, Received*(localhost+[127.0.0.1]), 0.40000, >+System, 0.40000, the+cdrom, 0.40000, I+tried, 0.40000, controllers, 0.40000, just, 0.40000, PATA, 0.40000, 45b404ee896261676220417!+>, 0.40000, System+>, 0.40000, made, 0.40000, Content-Type*micalg=pgp, 0.40000, Received*localhost, 0.40000, Received*localhost, 0.40000, art+de>, 0.40000, art+de>, 0.40000, References+<585602e10701211558s66d2fc82vd25cc32a4c17b7ab, 0.40000, X-Virus-Scanned*new, 0.40000, the+bootloader, 0.40000, the+bootloader, 0.40000, of+freebsd, 0.40000, 0100+schrieb, 0.40000, "freebsd, 0.40000, gone), 0.40000 Content-Type: multipart/mixed; boundary=DSPAM_MULTIPART_EX-89626 Subject: [Fwd: Re: Harddisk gone.] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: therion@ninth-art.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 02:02:15 -0000 --DSPAM_MULTIPART_EX-89626 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6I9hA5tq0HiBInUg4ZuQ" --=-6I9hA5tq0HiBInUg4ZuQ Content-Type: multipart/mixed; boundary="=-DGlwrpBhjWGmWjqU98Cy" --=-DGlwrpBhjWGmWjqU98Cy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=20 Georg 'Therion' Bege http://coruscant.info http://www.ninth-art.de therion@ninth-art.de GnuPG-Key-ID: 0x5717E214 FingerPrint: A8EC B4B2 C9A9 483B CC87 56EE 07A1 C78E 5717 E214 --=-DGlwrpBhjWGmWjqU98Cy Content-Disposition: inline Content-Description: Weitergeleitete Nachricht - Re: Harddisk gone. Content-Type: message/rfc822 Subject: Re: Harddisk gone. From: Georg Bege Reply-To: therion@ninth-art.de To: Matthias =?ISO-8859-1?Q?Gamsj=E4ger?= In-Reply-To: <585602e10701211558s66d2fc82vd25cc32a4c17b7ab@mail.gmail.com> References: <585602e10701211558s66d2fc82vd25cc32a4c17b7ab@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eaJaxIlwPf38pdys6/AT" Message-Id: <1169430141.3433.3.camel@cerberus.ninth-art.de> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 Date: Mon, 22 Jan 2007 02:42:22 +0100 --=-eaJaxIlwPf38pdys6/AT Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: quoted-printable Moin Obviously it is a driver/chipset problem - Maybe printing dmesg output helps. So your FBSD is located on the pata hdd? If you could boot with the previous 6.1 release then you might install 6.1 and then checkout 6.2 and compile a custom kernel. Or did you install already? Am Montag, den 22.01.2007, 00:58 +0100 schrieb Matthias Gamsj=C3=A4ger: > HI, >=20 > I am a user of freebsd for couple of year now and had recently made a fre= sh > install with 6.2. Everything worked as it always did but as i booted the > system today it seems that the kernel couldnt find my harddisk. >=20 > Strange thing is: > - I get the bootloader (dual boot with windows) > - windows works just fine > - I can access all my files on the hd through the bootloader > - the kernel boots of the harddisk and finds the (s)ata-controllers > - it finds the cdrom attachet to the ata0 > - it finds my sata disk >=20 > but my first pata disk seems to be gone. The bootscript ends because ther= e > is no ad0 (dev isnt created so cant do manualy) >=20 >=20 > I tried to boot 2 live-cdroms (freesbie and frenzy) with the same result= . >=20 > System: > Nforce 4 motherboard > AMD X2 4600+ > 1GB ram > GF 7900tgo > PATA Maxtor hd (which is gone) > SATA WD (works fine) >=20 > Anyone got any idea whay might cause this? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 > !DSPAM:45b404ee896261676220417! >=20 >=20 --=20 Georg 'Therion' Bege http://coruscant.info http://www.ninth-art.de therion@ninth-art.de GnuPG-Key-ID: 0x5717E214 FingerPrint: A8EC B4B2 C9A9 483B CC87 56EE 07A1 C78E 5717 E214 --=-eaJaxIlwPf38pdys6/AT Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFtBZ9B6HHjlcX4hQRAlwRAJ9YklfT4MnBMbskqfrNQblLh5khhACdHUx9 n2CoHei76uRf2tSS3rCdKQ8= =rPZ1 -----END PGP SIGNATURE----- --=-eaJaxIlwPf38pdys6/AT-- --=-DGlwrpBhjWGmWjqU98Cy-- --=-6I9hA5tq0HiBInUg4ZuQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFtBaeB6HHjlcX4hQRAnFaAKCGiB7dzBbJQj336wZWQt3uBNY9LACfeKnB 7C3iLkJYPIRR+iZG84RRZxI= =SdM8 -----END PGP SIGNATURE----- --=-6I9hA5tq0HiBInUg4ZuQ-- --DSPAM_MULTIPART_EX-89626 Content-Type: text/plain X-DSPAM-Signature: 45b416f2896269661917265 !DSPAM:45b416f2896269661917265! --DSPAM_MULTIPART_EX-89626-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 02:30:48 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E68516A400; Mon, 22 Jan 2007 02:30:48 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5377E13C45B; Mon, 22 Jan 2007 02:30:48 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0M2Ujrf030953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 18:30:45 -0800 Message-ID: <45B421D4.2050008@freebsd.org> Date: Sun, 21 Jan 2007 18:30:44 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dimitry Andric References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> In-Reply-To: <45B3CA56.4040106@andric.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB6AE63A7FA61973A62DB677" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 02:30:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB6AE63A7FA61973A62DB677 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> I remember Dimitry Andric reported the same problem on -stable on 30= >>> Dec, and after he reverted rev.1.48.2.16 it worked fine again. Do >>> you have the symptom even on 6.2-RELEASE? Since RELENG_6_2_0_RELEAS= E >>> did not have the change, I thought there was no problem. > ... >> On my 6-STABLE system (which appears to be working fine), I still have= >> the change from 1.48.2.16, I only backed out .15 and .14. I didn't tr= y >> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet. >> >> Hmmm...I was looking for that bug report before, but I couldn't find i= t. >> It's not clear to me how 1.48.2.16 is involved...hmmm... >=20 > I originally reported this here: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.= html >=20 > and later I found out it was caused by commit 1.48.2.16: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.= html >=20 > I'll shoot in a regular PR later tonight... Hi Dimitry-- This isn't consistent with what I'm finding. For one thing, rev. 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there anyways. Also, that's not the change I made to my local sources to get my gif(4) tunnel working. Are you sure about this? :-) Thanks! Bruce. --------------enigDB6AE63A7FA61973A62DB677 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtCHU2MoxcVugUsMRAh2BAJ4ko8DJylWIz8Hv5cME5jThGyvbugCgsoIO o8WDZf7XNeRRO9ibZMwd2IA= =pPCU -----END PGP SIGNATURE----- --------------enigDB6AE63A7FA61973A62DB677-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 07:43:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F10E16A408 for ; Mon, 22 Jan 2007 07:43:06 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5E913C442 for ; Mon, 22 Jan 2007 07:43:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0M7h4tG000908; Mon, 22 Jan 2007 18:43:04 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0M7h4kZ000907; Mon, 22 Jan 2007 18:43:04 +1100 (EST) (envelope-from peter) Date: Mon, 22 Jan 2007 18:43:04 +1100 From: Peter Jeremy To: Louis Mamakos Message-ID: <20070122074304.GB837@turion.vk2pj.dyndns.org> References: <45B09856.8080600@IPricot.com> <45B3796A.3020409@transsys.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <45B3796A.3020409@transsys.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: tcpdump, rl, sis, fxp and multicast problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 07:43:06 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2007-Jan-21 09:32:10 -0500, Louis Mamakos wrote: >However, since it is a 1's complement checksum, there is a distinguished= =20 >value (all zero bits) that you could set the checksum field to that=20 >wouldn't occur for a normal computed checksum. That's a useful idea. > Since the presence of a=20 >checksum is mandatory for TCP, you can use this trick and external=20 >software could "know" that it's a distinguished value. Keep in mind that tcpdump/libpcap in contributed software so making local changes is frowned upon. >I suspect the overhead isn't the CPU instruction, but the memory=20 >reference. If you manipulate the checksum field to the distinguished=20 >value at the time the other fields are written, they they'll all get=20 >written out to memory when the cache line is flushed. You've already=20 >got to initialize the Urgent Pointer field, which is the other 16 bits=20 >in the same 32 bit word. If you were really clever, you could make a=20 >union to cover both fields and zero both out in the same store instruction. And given that a 16-bit update is no faster (and typically slower) than a 32-bit update on all supported architectures, this may even be faster. Feel free to come up with a patch. --=20 Peter Jeremy --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtGsI/opHv/APuIcRAoLzAJ9Hzzvr0Q9sVbUwjoEsS4+dkCpQBACfZ3bP E4UsV7Zx1cNVTOTbhRkLObU= =jhIk -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 09:04:54 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96E2616A401; Mon, 22 Jan 2007 09:04:54 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id E897813C45A; Mon, 22 Jan 2007 09:04:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0M8Z7QZ071608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 11:35:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l0M8Z6ua071607; Mon, 22 Jan 2007 11:35:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 22 Jan 2007 11:35:06 +0300 From: Gleb Smirnoff To: Jack Vogel Message-ID: <20070122083506.GW4485@FreeBSD.org> References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> User-Agent: Mutt/1.5.6i Cc: Bill Paul , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, jon.otterholm@ide.resurscentrum.se Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 09:04:54 -0000 Jack, On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: J> >> Since this was just seen, and the patch below validated as working I J> >wanted J> >> to send general email to capture this: J> >> J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has J> >> not been decided on yet. Nevertheless, the patch below will work, but J> >> I do not want to check it in as its still temporary. J> >> J> >> Address questions to me, J> > J> >Okay, I have a question. Could you elaborate on just what the problem is? J> >(I mean, since it's KNOWN and all...) I'm just having a hard time figuring J> >out what problem could possibly be fixed by setting the RX interrupt J> >delay timer to a non-zero value (especially since elsewhere in the em(4) J> >source it says that doing so is a Bad Thing (tm)). J> J> saying its known to be a problem doesnt mean its cause is known :) J> They discovered that setting this eliminated the problem, but we J> immediately pointed out that this is, as you pointed out, a Bad J> Thing on other hardware, so the investigation continues, there is J> always a communication lag on these kind of things, so I dont know J> if it has been resolved yet or not. J> J> I just dont think this patch will become the final way to solve this, J> but we shall see :) Good to know that there is progress on this. Thanks! I will try the patch on my Lenovo T60 notebook, where the problem is also present. AFAIK, it is present on any Lenovo notebook with 82573 NIC. Can you please acknowledge that another bug with Lenovo + em(4) is known? I mean the problem, that em(4) isn't initialized properly on kernel boot, if the link is down. I have already reported this to you, and you said that I probably have bad hardware. Since that time, I've found several similar reports about Lenovo notebooks and em(4) driver in FreeBSD. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 10:16:51 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D2F16A400; Mon, 22 Jan 2007 10:16:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (springbank.echomania.com [82.94.255.114]) by mx1.freebsd.org (Postfix) with ESMTP id 524A813C465; Mon, 22 Jan 2007 10:16:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 97DA7A713D; Mon, 22 Jan 2007 11:16:49 +0100 (CET) Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16238-01; Mon, 22 Jan 2007 11:16:45 +0100 (CET) Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTP id 3E8A2A70C0; Mon, 22 Jan 2007 11:16:45 +0100 (CET) Message-ID: <45B48F0C.9090809@andric.com> Date: Mon, 22 Jan 2007 11:16:44 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b1 (Windows/20070106) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> In-Reply-To: <45B421D4.2050008@freebsd.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 10:16:51 -0000 Bruce A. Mah wrote: >> and later I found out it was caused by commit 1.48.2.16: >> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html > > This isn't consistent with what I'm finding. For one thing, rev. > 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there > anyways. Also, that's not the change I made to my local sources to get > my gif(4) tunnel working. Are you sure about this? :-) I'm following -STABLE, and 1.48.2.16 is in there. Since it was committed on 29 Nov, I suspected it would end up in -RELEASE, but apparently not. :) I explicitly tried reverting just this one commit, and for me it solved the problem (i.e. the automagical addition of needed routing entries). So for you, reverting the combination of 1.48.2.14 and .15 works? Maybe there is something else involved too, for example the route command itself? I'll have to experiment a bit further, I guess. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 15:26:53 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89CD716A402 for ; Mon, 22 Jan 2007 15:26:53 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from daemon.crashmail.de (daemon.crashmail.de [88.198.125.180]) by mx1.freebsd.org (Postfix) with ESMTP id 50D8013C465 for ; Mon, 22 Jan 2007 15:26:52 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from localhost (dslb-082-083-105-188.pools.arcor-ip.net [82.83.105.188]) by daemon.crashmail.de (Postfix) with ESMTP id C334F64B08 for ; Mon, 22 Jan 2007 16:26:50 +0100 (CET) Received: by crashmail.de (OpenXP/4.10.7328 (FreeBSD) (i386)); 22 Jan 2007 16:26:27 +0100 Date: 22 Jan 2007 16:26:00 +0100 From: steve.tell@crashmail.de (Stefan 'Steve' Tell) To: freebsd-stable@freebsd.org Message-ID: In-Reply-To: <20070122013416.GA29223@cdnetworks.co.kr> User-Agent: OpenXP/4.10.7328 (FreeBSD) (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: The Third Place X-Homepage: http://blog.crashmail.de Subject: Re: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 15:26:53 -0000 * Pyun YongHyeon wrote: > How about attached one? I cannot test that at this moment. There is no free partition to install freebsd to (that's why I tried a LiveCD first). I'll try to get an empty hdd and test it. Thanks. -- By(t)e, Stefan 'Steve' Tell | http://blog.crashmail.de -------------------------------| http://www.freebsd.org Powered by FreeBSD/i386 | http://www.naturefund.de From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 17:39:11 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9571E16A407 for ; Mon, 22 Jan 2007 17:39:11 +0000 (UTC) (envelope-from steve.tell@crashmail.de) Received: from daemon.crashmail.de (daemon.crashmail.de [88.198.125.180]) by mx1.freebsd.org (Postfix) with ESMTP id 57A8813C4CE for ; Mon, 22 Jan 2007 17:39:11 +0000 (UTC) (envelope-from steve.tell@crashmail.de) Received: from currahee.crashmail.de (dslb-082-083-105-188.pools.arcor-ip.net [82.83.105.188]) by daemon.crashmail.de (Postfix) with ESMTP id 6A05464B08; Mon, 22 Jan 2007 18:21:56 +0100 (CET) To: pyunyh@gmail.com X-Face: #Xe~sd&4-Nt4!$0V"R?!MDM"@&ft'xzx+0j]DIA!AyXC)lv0ea!k_GV5?#ZM{uGi*h@>BI/1%]9h)r,R\jES^Tq8~[*RQ^I8(?&Fg~sR't{xG"[m0Ve; q5K^bav,^Ut`[iP(4c,rQCNxo5UF^2S95:t-e@$2Ai{`t=we/**fuT~i_.3R6r,wogCl\2[]FW@sroLn*v.#'J*0Z X-PGP-Key: 0x9B6C7E15 X-PGP-Fingerprint: 0A21 6C88 552E 54AE 3FB5 4732 25EE 6ABE 9B6C 7E15 Organization: The Third Place In-Reply-To: <20070122013416.GA29223@cdnetworks.co.kr> (Pyun YongHyeon's message of "Mon, 22 Jan 2007 10:34:16 +0900") References: <20070122013416.GA29223@cdnetworks.co.kr> From: Stefan 'Steve' Tell Date: Mon, 22 Jan 2007 18:21:33 +0100 Message-ID: <87r6tn6kpu.fsf@zeus.crashmail.de> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 17:39:11 -0000 * Pyun YongHyeon wrote: > On Sun, Jan 21, 2007 at 06:36:00PM +0100, Stefan 'Steve' Tell wrote: >> re0@pci4:0:0: class=0x020000 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 >> class = network >> subclass = ethernet >> none3@pci6:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 >> class = network > How about attached one? Very cool, it works. I've brought the device up and dhclient re0 get's an IP from my router. Very nice and many thanks for this. There are some new ACPI-1304-warnings now. I'll post them later to this mailinglist. -- By(t)e, Steve /\ http://www.crashmail.de GnuPG/PGP: 0x9B6C7E15, encrypted mail prefered, see header From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 17:52:34 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5406D16A400 for ; Mon, 22 Jan 2007 17:52:34 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 387AF13C4B9 for ; Mon, 22 Jan 2007 17:52:34 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.26.75] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0MHqXuN032485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 09:52:33 -0800 Message-ID: <45B4F9DB.6070908@freebsd.org> Date: Mon, 22 Jan 2007 09:52:27 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE521B5E3D412CFC2AF0AE79C" Cc: max@love2party.net, freebsd-stable@freebsd.org Subject: Re: IPv6 problems with 6.2-RELEASE ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 17:52:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE521B5E3D412CFC2AF0AE79C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Pete French wrote: >> 2) rtsol(8) is used to initiate stateless autoconfiguration. You migh= t=3D20 >> want to try "rtsol -d interface". >=20 > Aha... this does not work... >=20 >> 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should ta= ke=3D20 >> care of this. >=20 > ...because this is 0 >=20 > All of which appears to be because a spurious 'ipv6_gateway_enable=3D"Y= ES"' > has found it's way into my rc.conf due to cut-n-paste. Which is > interesting though, since even when I spotted it, it hadn;'t occurred > to me that it would prevent the auto configuration working. Ah yes, I remember stumbling over this (or some similar problem) many years ago. Machines that are configured as routers/gateways, as well as multi-homed end-hosts, aren't supposed to use rtsol. Also, accept_rtadv is usually 0...I think that our IPv6 startup scripts toggle it to 1 just long enough to get a route advertisement and then set it back to 0. Bruce. --------------enigE521B5E3D412CFC2AF0AE79C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtPnb2MoxcVugUsMRApz9AJwKhUmOarxWgCy6cXT0f0nvWUlN6gCgjilE IBbvpksw+JjNPcY6KgPFzOQ= =9Mz7 -----END PGP SIGNATURE----- --------------enigE521B5E3D412CFC2AF0AE79C-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 18:30:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A324716A400 for ; Mon, 22 Jan 2007 18:30:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECDD13C44C for ; Mon, 22 Jan 2007 18:30:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so795322wri for ; Mon, 22 Jan 2007 10:30:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LypZu9zXm94JUYUYZbaJ58muOL/ZaN/AOoIV99gXwTQfkw7mlbqN+zu3kqFtnC/q3zurzxbMYW+aIxnR2DV2XSfRFkGOhwR9ypVIimOPgPpihimPP3zNv5QU+J1ZkTRocV4TJo1sE9ltCoYW4bJP3pDekxWH+ECeE+Ge3knFU/0= Received: by 10.82.105.13 with SMTP id d13mr7218829buc.1169490648616; Mon, 22 Jan 2007 10:30:48 -0800 (PST) Received: by 10.82.127.12 with HTTP; Mon, 22 Jan 2007 10:30:48 -0800 (PST) Message-ID: <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> Date: Mon, 22 Jan 2007 10:30:48 -0800 From: "Jack Vogel" To: "Gleb Smirnoff" In-Reply-To: <20070122083506.GW4485@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> Cc: Bill Paul , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, jon.otterholm@ide.resurscentrum.se Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 18:30:50 -0000 On 1/22/07, Gleb Smirnoff wrote: > Jack, > > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > J> >> Since this was just seen, and the patch below validated as working I > J> >wanted > J> >> to send general email to capture this: > J> >> > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > J> >> not been decided on yet. Nevertheless, the patch below will work, but > J> >> I do not want to check it in as its still temporary. > J> >> > J> >> Address questions to me, > J> > > J> >Okay, I have a question. Could you elaborate on just what the problem is? > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time figuring > J> >out what problem could possibly be fixed by setting the RX interrupt > J> >delay timer to a non-zero value (especially since elsewhere in the em(4) > J> >source it says that doing so is a Bad Thing (tm)). > J> > J> saying its known to be a problem doesnt mean its cause is known :) > J> They discovered that setting this eliminated the problem, but we > J> immediately pointed out that this is, as you pointed out, a Bad > J> Thing on other hardware, so the investigation continues, there is > J> always a communication lag on these kind of things, so I dont know > J> if it has been resolved yet or not. > J> > J> I just dont think this patch will become the final way to solve this, > J> but we shall see :) > > Good to know that there is progress on this. Thanks! I will try the patch > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > is present on any Lenovo notebook with 82573 NIC. > > Can you please acknowledge that another bug with Lenovo + em(4) is known? I > mean the problem, that em(4) isn't initialized properly on kernel boot, if > the link is down. I have already reported this to you, and you said that > I probably have bad hardware. Since that time, I've found several similar > reports about Lenovo notebooks and em(4) driver in FreeBSD. Hey Gleb, Acknowledge... I can do better than that, I have a fix for this problem, and its not temporary. Here is the code change (not a patch, I'm very busy), its in hardware_init, should be obvious how to patch: /* Make sure we have a good EEPROM before we read from it */ if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { /* ** Some PCI-E parts fail the first check due to ** the link being in sleep state, call it again, ** if it fails a second time its a real issue. */ if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { device_printf(dev, "The EEPROM Checksum Is Not Valid\n"); return (EIO); } } This is already checked into my code base at Intel, I've just been too busy to do anything with it, be my guest if you wish to check it in after testing... Cheers, Jack From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 18:34:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64A8316A40A for ; Mon, 22 Jan 2007 18:34:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id C6CF913C4D9 for ; Mon, 22 Jan 2007 18:34:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1049737uge for ; Mon, 22 Jan 2007 10:34:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X4gBLCTQlvA0X33liZitVbnSrcmGLO0ckIjzW76tW9ed/6lwKDkxvssPMn4ieRFs29qRi0BVOkVuHlkqwIda1UqD8MFG41jCw1S3j3wTXRUD7j/0YaQKuKyP3gUq7b+x/kR7eb9d3lVSEZGNkIdu/8S0reeG/h8QGJ78ZFm5eZI= Received: by 10.82.138.6 with SMTP id l6mr5620904bud.1169490888138; Mon, 22 Jan 2007 10:34:48 -0800 (PST) Received: by 10.82.127.12 with HTTP; Mon, 22 Jan 2007 10:34:48 -0800 (PST) Message-ID: <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com> Date: Mon, 22 Jan 2007 10:34:48 -0800 From: "Jack Vogel" To: "Gleb Smirnoff" In-Reply-To: <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> Cc: Bill Paul , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, jon.otterholm@ide.resurscentrum.se Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 18:34:50 -0000 On 1/22/07, Jack Vogel wrote: > On 1/22/07, Gleb Smirnoff wrote: > > Jack, > > > > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > > J> >> Since this was just seen, and the patch below validated as working I > > J> >wanted > > J> >> to send general email to capture this: > > J> >> > > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN > > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > > J> >> not been decided on yet. Nevertheless, the patch below will work, but > > J> >> I do not want to check it in as its still temporary. > > J> >> > > J> >> Address questions to me, > > J> > > > J> >Okay, I have a question. Could you elaborate on just what the problem is? > > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time figuring > > J> >out what problem could possibly be fixed by setting the RX interrupt > > J> >delay timer to a non-zero value (especially since elsewhere in the em(4) > > J> >source it says that doing so is a Bad Thing (tm)). > > J> > > J> saying its known to be a problem doesnt mean its cause is known :) > > J> They discovered that setting this eliminated the problem, but we > > J> immediately pointed out that this is, as you pointed out, a Bad > > J> Thing on other hardware, so the investigation continues, there is > > J> always a communication lag on these kind of things, so I dont know > > J> if it has been resolved yet or not. > > J> > > J> I just dont think this patch will become the final way to solve this, > > J> but we shall see :) > > > > Good to know that there is progress on this. Thanks! I will try the patch > > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > > is present on any Lenovo notebook with 82573 NIC. > > > > Can you please acknowledge that another bug with Lenovo + em(4) is known? I > > mean the problem, that em(4) isn't initialized properly on kernel boot, if > > the link is down. I have already reported this to you, and you said that > > I probably have bad hardware. Since that time, I've found several similar > > reports about Lenovo notebooks and em(4) driver in FreeBSD. > > Hey Gleb, > > Acknowledge... I can do better than that, I have a fix for this problem, and > its not temporary. Here is the code change (not a patch, I'm very busy), > its in hardware_init, should be obvious how to patch: > > /* Make sure we have a good EEPROM before we read from it */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > /* > ** Some PCI-E parts fail the first check due to > ** the link being in sleep state, call it again, > ** if it fails a second time its a real issue. > */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > device_printf(dev, > "The EEPROM Checksum Is Not Valid\n"); > return (EIO); > } > } > > This is already checked into my code base at Intel, I've just been too > busy to do anything with it, be my guest if you wish to check it in after > testing... > > Cheers, > > Jack > LOL, opps, I just realized, this code reflects the new shared code that I am in the process of releasing, in order for this to work in 6.2 change 'e1000_validate_nvm_checksum' to 'em_validate_eeprom_checksum' and all should be clear :) Jack From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 18:46:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23ED916A404 for ; Mon, 22 Jan 2007 18:46:33 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id D819F13C44C for ; Mon, 22 Jan 2007 18:46:32 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCA00H4A9HJWW40@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 22 Jan 2007 19:46:31 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCA00APM9HJRWP2@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 22 Jan 2007 19:46:31 +0100 (CET) Date: Mon, 22 Jan 2007 19:46:31 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <45B3F996.8030303@FreeBSD.org> To: freebsd-stable@freebsd.org Message-id: <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <45B2AAF8.9010509@isc.org> <45B3F996.8030303@FreeBSD.org> Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 18:46:33 -0000 On Sun, 21 Jan 2007 23:39:02 +0000 "Bruce M. Simpson" wrote: > Peter Losher wrote: > > In both cases, once the USB CD-ROM started loading either 6.1 or > > 6.2, I get a BTX halt: > > > Known issue. The btx code can't deal with BIOSes which want to enter > protected mode to service the I/Os. USB support in most BIOSen > generally does this. Aha. So on a laptop I have where booting FreeBSD from a usb harddrive results in endless scrolling of text on the console (probably register dumps, hard to tell) until the laptop is turned off, this might be the same issue? I can boot NetBSD and OpenBSD from different partitions on the same usb hardrive, on the same laptop. Is there a known fix or workaround for this issue? (Probably not, but just in case...) -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 18:54:35 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6735416A404 for ; Mon, 22 Jan 2007 18:54:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAD813C465 for ; Mon, 22 Jan 2007 18:54:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (sccrmhc13) with ESMTP id <2007012218543401300kg33be>; Mon, 22 Jan 2007 18:54:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9536A1FA038; Mon, 22 Jan 2007 10:54:33 -0800 (PST) Date: Mon, 22 Jan 2007 10:54:33 -0800 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20070122185433.GA65112@icarus.home.lan> Mail-Followup-To: Torfinn Ingolfsen , freebsd-stable@freebsd.org References: <45B2AAF8.9010509@isc.org> <45B3F996.8030303@FreeBSD.org> <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 18:54:35 -0000 On Mon, Jan 22, 2007 at 07:46:31PM +0100, Torfinn Ingolfsen wrote: > Aha. So on a laptop I have where booting FreeBSD from a usb harddrive > results in endless scrolling of text on the console (probably register > dumps, hard to tell) until the laptop is turned off, this might be the > same issue? > I can boot NetBSD and OpenBSD from different partitions on the same usb > hardrive, on the same laptop. > > Is there a known fix or workaround for this issue? (Probably not, but > just in case...) Does the GRUB bootloader behave this way? If not (e.g. it works), then one could use that as an alternative to btx. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 19:02:23 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7343A16A400 for ; Mon, 22 Jan 2007 19:02:23 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 2538413C4A6 for ; Mon, 22 Jan 2007 19:02:23 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from unknown (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 22 Jan 2007 19:02:18 -0000 Date: Mon, 22 Jan 2007 21:01:45 +0200 From: Nikolay Pavlov To: erich Message-ID: <20070122190145.GA61389@zone3000.net> Mail-Followup-To: Nikolay Pavlov , erich , freebsd-stable@freebsd.org References: <20070105165910.GA37906@zone3000.net> <00d001c73ded$b305e540$4e00a8c0@erich2003> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <00d001c73ded$b305e540$4e00a8c0@erich2003> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic on 6.2-RC2 with GENERIC. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:02:23 -0000 On Monday, 22 January 2007 at 14:22:29 +0800, erich wrote: > Dear Nikolay Pavlov, >=20 > Please update your RAID adapter firmware's version into 1.42. > I the problem still there please tell me again. > I am trying to reproduce this bug in my lab, > but till now I can not reproduce it. No luck, sir. After upgrade to 1.42 it's still very unstable: # kgdb kernel.debug /mnt/mnt2/crash/vmcore.5 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] 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 condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: softdep_deallocate_dependencies: dangling deps Uptime: 5m11s Dumping 3583 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 34= 39 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 31= 99 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 29= 59 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 27= 19 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 24= 79 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 22= 39 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 19= 99 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 17= 59 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 15= 19 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 12= 79 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 10= 39 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 75= 1 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 4= 47 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 = 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc067005a in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc06702f0 in panic (fmt=3D0xc08e0219 "softdep_deallocate_dependencies:= dangling deps") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc079dc2e in softdep_deallocate_dependencies (bp=3D0x0) at /usr/src/sy= s/ufs/ffs/ffs_softdep.c:6255 #4 0xc06b73e3 in getnewbuf (slpflag=3D0, slptimeo=3D0, size=3D16384, maxsi= ze=3D16384) at buf.h:447 #5 0xc06b88dc in getblk (vp=3D0xcd2b2330, blkno=3D2115, size=3D16384, slpf= lag=3D0, slptimeo=3D0, flags=3D1) at /usr/src/sys/kern/vfs_bio.c:2497 #6 0xc06bc9b3 in cluster_rbuild (vp=3D0xcd2b2330, filesize=3D50608376, lbn= =3D2113, blkno=3D1819849504, size=3D16384, run=3D8, fbp=3D0x0) at /usr/src/sys/kern/vfs_cluster.c:374 #7 0xc06bc607 in cluster_read (vp=3D0xcd2b2330, filesize=3D50608376, lblkn= o=3D2113, size=3D16384, cred=3D0x0, totread=3D4096, seqcount=3D127, bpp=3D0= x0) at /usr/src/sys/kern/vfs_cluster.c:252 #8 0xc07a234b in ffs_read (ap=3D0x0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:5= 03 #9 0xc086f924 in VOP_READ_APV (vop=3D0x0, a=3D0x0) at vnode_if.c:643 #10 0xc06d4209 in vn_read (fp=3D0xc9bbe3a8, uio=3D0xec89bcbc, active_cred= =3D0xccde6a00, flags=3D0, td=3D0xcba86480) at vnode_if.h:343 #11 0xc0691e0d in dofileread (td=3D0xcba86480, fd=3D5, fp=3D0xc9bbe3a8, aui= o=3D0xec89bcbc, offset=3DUnhandled dwarf expression opcode 0x93 ) at file.h:240 #12 0xc0691ca6 in kern_readv (td=3D0xcba86480, fd=3D5, auio=3D0xec89bcbc) a= t /usr/src/sys/kern/sys_generic.c:192 #13 0xc0691bd1 in read (td=3D0xcba86480, uap=3D0x0) at /usr/src/sys/kern/sy= s_generic.c:116 #14 0xc085e9f7 in syscall (frame=3D {tf_fs =3D 59, tf_es =3D -1078001605, tf_ds =3D -1078001605, tf_edi = =3D 8192, tf_esi =3D 672845424, tf_ebp =3D -1077951544, tf_isp =3D -3265174= 04, tf_ebx =3D 672769032, tf_edx =3D 0, tf_ecx =3D 1, tf_eax =3D 3, tf_trap= no =3D 32, tf_err =3D 2, tf_eip =3D 672715519, tf_cs =3D 51, tf_eflags =3D = 530, tf_esp =3D -1077951572, tf_ss =3D 59}) at /usr/src/sys/i386/i386/trap.c:983 #15 0xc084d0cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :200 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) >=20 > Best Regards > Erich Chen > ----- Original Message -----=20 > From: "Nikolay Pavlov" > To: > Sent: Saturday, January 06, 2007 12:59 AM > Subject: kernel panic on 6.2-RC2 with GENERIC. >=20 >=20 > Hello folks. > I have kernel panic on GENERIC kernel while executing postmark. >=20 > Before panic there were messages like this: > g_vfs_done():da1s1d[WRITE(offset=3D772363010048, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363026432, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363042816, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363059200, length=3D16384)]error = =3D 5 >=20 > and >=20 > initiate_write_filepage: already started >=20 > And finaly here is a panic: >=20 > kgdb kernel.debug /mnt/mnt2/crash/vmcore.2 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o:=20 > Undefined symbol "ps_pglobal_lookup"] > 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=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd". >=20 > Unread portion of the kernel message buffer: > panic: initiate_write_inodeblock_ufs2: already started > Uptime: 9m27s > Dumping 3583 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455= =20 > 3439 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 321= 5=20 > 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 297= 5=20 > 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 273= 5=20 > 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 249= 5=20 > 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 225= 5=20 > 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 201= 5=20 > 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 177= 5=20 > 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 153= 5=20 > 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 129= 5=20 > 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 105= 5=20 > 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 76= 7=20 > 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 4= 63=20 > 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 1= 59=20 > 143 127 111 95 79 63 47 31 15 >=20 > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0672a26 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :409 > #2 0xc0672cbc in panic (fmt=3D0xc0909c75 "initiate_write_inodeblock_ufs2= :=20 > already started") at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=3D0xc9c54000,= =20 > bp=3D0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022 > #4 0xc07bf897 in softdep_disk_io_initiation (bp=3D0xdc9c63b8) at=20 > /usr/src/sys/ufs/ffs/ffs_softdep.c:3757 > #5 0xc07c8411 in ffs_geom_strategy (bo=3D0xc8c5a830, bp=3D0xdc9c63b8) at= =20 > buf.h:433 > #6 0xc06b8048 in bufwrite (bp=3D0xdc9c63b8) at buf.h:426 > #7 0xc07c82d2 in ffs_bufwrite (bp=3D0xdc9c63b8) at=20 > /usr/src/sys/ufs/ffs/ffs_vfsops.c:1740 > #8 0xc06b9a77 in vfs_bio_awrite (bp=3D0xdc9c63b8) at buf.h:410 > #9 0xc06ba8bd in flushbufqueues (flushdeps=3D0) at=20 > /usr/src/sys/kern/vfs_bio.c:2125 > #10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999 > #11 0xc065cc5c in fork_exit (callout=3D0xc06ba2d0 , arg=3D0x0= ,=20 > frame=3D0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821 > #12 0xc087397c in fork_trampoline () at=20 > /usr/src/sys/i386/i386/exception.s:208 >=20 >=20 > This box is using ARECA RAID with GENERIC UP kernel: >=20 > arcmsr0@pci3:14:0: class=3D0x010400 card=3D0x116017d3 chip=3D0x11601= 7d3=20 > rev=3D0x00 hdr=3D0x00 > vendor =3D 'Areca Technology Corporation' > device =3D 'ARC-1160 16-Port PCI-X to SATA RAID Controller' > class =3D mass storage > subclass =3D RAID >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 - Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 19:37:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64C6016A401 for ; Mon, 22 Jan 2007 19:37:20 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 23BCA13C4B7 for ; Mon, 22 Jan 2007 19:37:20 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCA00HOIBU7XD60@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 22 Jan 2007 20:37:19 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCA00A1FBU6RHS2@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 22 Jan 2007 20:37:19 +0100 (CET) Date: Mon, 22 Jan 2007 20:37:18 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <20070122185433.GA65112@icarus.home.lan> To: freebsd-stable@freebsd.org Message-id: <20070122203718.60e59d5e.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <45B2AAF8.9010509@isc.org> <45B3F996.8030303@FreeBSD.org> <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> <20070122185433.GA65112@icarus.home.lan> Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:37:20 -0000 On Mon, 22 Jan 2007 10:54:33 -0800 Jeremy Chadwick wrote: > Does the GRUB bootloader behave this way? If not (e.g. it works), > then one could use that as an alternative to btx. Don't know, I haven't tested it. I have tested the NetBSD boot loader, and it behaves in the same way as the FreeBSD boot loader. Like this: (FreeBSD, NetBSD and OpenBSD installed on different partitions on the same usb hard drive. Using "F12" on laptop bootup to get a boot menu, then selecting the usb hard drive, whivj brings up the boot loader on that usb hard drive) FreeBSD boot loader: boots NetBSD, OpenBSD, but not FreeBSD NetBSD boot loader: boots NetBSD, OpenBSD, but not FreeBSD See messages with the subject "Install FreeBSD on an external (usb) hard drive?" in the archives of freebsd-mobile for more information. I hope I don't need to test grub. Everytime I try it, I end up having to recover something (probably my fault). I'm really not comfortable with grub. -- Regards Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 19:40:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4F3616A400 for ; Mon, 22 Jan 2007 19:40:12 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from kininvie.sv.svcolo.com (kininvie.sv.svcolo.com [64.13.135.12]) by mx1.freebsd.org (Postfix) with ESMTP id AD18B13C465 for ; Mon, 22 Jan 2007 19:40:12 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by kininvie.sv.svcolo.com (8.13.8/8.13.4) with ESMTP id l0MJeCxU073512; Mon, 22 Jan 2007 11:40:12 -0800 (PST) (envelope-from jrhett@svcolo.com) In-Reply-To: <200701210940.l0L9eett037709@wattres.watt.com> References: <45A78CA4.30903@sh.cvut.cz> <200701210940.l0L9eett037709@wattres.watt.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1612EE46-1153-4115-9403-FE8CCFB0D2B8@svcolo.com> Content-Transfer-Encoding: quoted-printable From: Jo Rhett Date: Mon, 22 Jan 2007 11:40:06 -0800 To: Steve Watt X-Mailer: Apple Mail (2.752.2) X-Spam-Score: undef - SENDER Whitelisted (jrhett@svcolo.com: Mail from user authenticated via SMTP AUTH allowed always) X-CanItPRO-Stream: default X-Canit-Stats-ID: 48459 - cbb2f78d42aa X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.135.12 Cc: freebsd-stable@freebsd.org Subject: Re: any real documentation of the boot2 prompt? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 19:40:12 -0000 On Jan 21, 2007, at 1:40 AM, Steve Watt wrote: > In <45A7B081.6040504@svcolo.com>, jrhett@svcolo.com wrote: >> V=E1clav Haisman wrote: >>> What does lsdev or whatever it was say? Does it show any devices =20 >>> besides >>> the raw disks? >> >> So I booted from CD and ran lsdev, and showed something like this =20 >> (from >> memory) >> >> 0: Drive A >> 2: Disk 0 >> 1: FFS > > You need to get into your SCSI BIOS (don't know what the key > sequence is for 3ware, it's ^A for Adaptec) at the correct time > and enable the disk for booting. As shown here, there's no chance > of it being bootable. Thanks, but I didn't need any help with the SCSI BIOS. The question =20 was only how to determine what devices are visible to FreeBSD. =20 Apparently 3ware only shows a single LUN to the BIOS, even when it =20 shows multiple LUNs to the booted system. --=20 Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 20:01:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C8BA16A5CB for ; Mon, 22 Jan 2007 20:01:15 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.freebsd.org (Postfix) with ESMTP id EB7F713C461 for ; Mon, 22 Jan 2007 20:01:14 +0000 (UTC) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 476AFB80A for ; Mon, 22 Jan 2007 15:01:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <45B1BF6E.7090704@delphij.net> References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <72347C40-81E3-4E4D-9F27-3058B73359B3@khera.org> <45B1BF6E.7090704@delphij.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-62828750; protocol="application/pkcs7-signature" Message-Id: From: Vivek Khera Date: Mon, 22 Jan 2007 15:01:13 -0500 To: FreeBSD Stable X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 20:01:15 -0000 --Apple-Mail-5-62828750 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 20, 2007, at 2:06 AM, LI Xin wrote: >> My newer 2230SLP cards do not work with any extant command line tools >> for freebsd under amd64. The older cards did. I've tested >> FreeBSD 6.0 >> and 6.1. 6.2 is on the agenda to test soon. > > Do you mean Linux CLI tools on FreeBSD? I think I have missed my > src/sys/dev/aac/aac_linux.c,v 1.4 change with re@ so I think there > might > be no change. Just MFC'ed that to RELENG_6. The linux tools have 0 chance of working on amd64.... I have some newer version from one of the freebsd devs of adaptec CLI but it doesn't recognize the latest firmware in the 2230 card. I've been trying to work with that developer to sponsor some work to make the tools available and working on newer hardware and FreeBSD versions, but there has been some hold up getting necessary bits out of Adaptec. --Apple-Mail-5-62828750-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 21:07:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD47B16A401 for ; Mon, 22 Jan 2007 21:07:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 84D1713C468 for ; Mon, 22 Jan 2007 21:07:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 12046939AE; Mon, 22 Jan 2007 16:07:16 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 22 Jan 2007 16:07:16 -0500 X-Sasl-enc: sMEmwgWPMReI/GrU5zqE+OVrxJanXX7N3FUlWK3Iu1Nv 1169500035 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C17E82772A; Mon, 22 Jan 2007 16:07:14 -0500 (EST) Message-ID: <45B52780.5090505@FreeBSD.org> Date: Mon, 22 Jan 2007 21:07:12 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Torfinn Ingolfsen References: <45B2AAF8.9010509@isc.org> <45B3F996.8030303@FreeBSD.org> <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> <20070122185433.GA65112@icarus.home.lan> <20070122203718.60e59d5e.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20070122203718.60e59d5e.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 21:07:16 -0000 Torfinn Ingolfsen wrote: > I hope I don't need to test grub. Everytime I try it, I end up having > to recover something (probably my fault). I'm really not comfortable > with grub. > Until the btx code is rewritten to deal with BIOS routines which expect to be run from within real mode and not vm86 mode, GRUB is probably the most convenient workaround for the issue. Regards, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Jan 22 23:33:10 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3946716A401 for ; Mon, 22 Jan 2007 23:33:10 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 05A6513C455 for ; Mon, 22 Jan 2007 23:33:09 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from [192.168.1.11] (121-72-69-246.dsl.telstraclear.net [121.72.69.246]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JCA00878MR8UP30@smtp3.clear.net.nz> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 12:33:09 +1300 (NZDT) Date: Tue, 23 Jan 2007 12:33:08 +1300 From: Mark Kirkwood In-reply-to: <003601c73d6d$0620c910$0c00a8c0@Artem> To: Artem Kuchin Message-id: <45B549B4.50201@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <01c501c73a58$2c546550$0c00a8c0@Artem> <45B280C5.30106@paradise.net.nz> <003601c73d6d$0620c910$0c00a8c0@Artem> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Cc: freebsd-stable@freebsd.org Subject: Re: Cannot start install cd of 6.2-R at all X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 23:33:10 -0000 Artem Kuchin wrote: > Mark Kirkwood wrote: > >> I have seen this with a Tyan PIII board + TX2000. In my case re-trying >> the boot from cd several times would *eventually* get a working >> installer session. (If you search the archives you'll see several >> cases of folks encountering this). Unfortunately I don't know of any >> solution. >> A (tedious) workaround (in case repeated attempts always fail for >> you), is to install a minimal system off an earlier version of >> FreeBSD and run the installer off the installed system - or just src >> upgrade to the version you want. I found that the 4.x, 5.0, 5.1 and >> 5.2 cd's all worked fine - but 5.3 onwards and 6.x would register >> dump. > > > There is a better workaround which i used. A simple start of installer from > 4 floppies. Then install the whole system from CD-ROM. It does work but > insolved copying of floppy images onto the disks. > However is it a very annoying problem which i have been encountering > since 5.0-RELEASE. The bootloader failed when trying to load installed > from CD-ROM on pretty much every PIII and old Celeron pc which i tried. > (it is about 6 machines by now). Very weird and i have no idea to how > help to solve the problem. > Right, however it means you need a floppy drive - and I've "gone floppiless" for my machines... :-) From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 00:39:19 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E7EE16A400 for ; Tue, 23 Jan 2007 00:39:19 +0000 (UTC) (envelope-from jeff@sailorfej.net) Received: from mail.sailorfej.net (mail.sailorfej.net [66.93.72.123]) by mx1.freebsd.org (Postfix) with ESMTP id D7C8D13C478 for ; Tue, 23 Jan 2007 00:39:18 +0000 (UTC) (envelope-from jeff@sailorfej.net) Received: from [192.168.150.100] (c-24-20-239-104.hsd1.wa.comcast.net [24.20.239.104]) (authenticated bits=0) by mail.sailorfej.net (8.13.4/8.13.4) with ESMTP id l0N0O6CF002438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jan 2007 16:24:07 -0800 (PST) (envelope-from jeff@sailorfej.net) Message-ID: <45B5592D.9050609@sailorfej.net> Date: Mon, 22 Jan 2007 16:39:09 -0800 From: Jeffrey Williams User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=6.0 tests=BAYES_00 autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail.sailorfej.net Subject: Sony GC89 edge/gprs card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 00:39:19 -0000 Does anyone know if it is possible to get the Sony Ericsson GC89 EDGE/GPRS PC Card working in FreeBSD, I can't find any references in the release or hardware notes, but there are some tantalizing hints when I Google it that there is support, but nothing concrete, and definitely no how to's. If anyome has got it working, what drivers were used? Thanks Jeff From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 00:46:10 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0719916A401 for ; Tue, 23 Jan 2007 00:46:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id B9B0B13C465 for ; Tue, 23 Jan 2007 00:46:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so699013nzh for ; Mon, 22 Jan 2007 16:46:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=p8gBGTHQU4b7Xm+i3IBjNCqioy20a4RreNl4np3BMnuG3MR43C0Vv595FEU6r9DVeo1mxthNJxh9CucYglhFgYK//egOrdaH+ITRZwmX7Oj/qs/GYl/wVaC0N61x67LDq40kNeg98iadoLxpGoFHKr5oWLmJK+PD4/OQttiz1V8= Received: by 10.35.93.19 with SMTP id v19mr11638147pyl.1169513168826; Mon, 22 Jan 2007 16:46:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id w38sm5820932pyg.2007.01.22.16.46.06; Mon, 22 Jan 2007 16:46:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l0N0lGtJ033957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 09:47:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0N0lEhk033956; Tue, 23 Jan 2007 09:47:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 23 Jan 2007 09:47:14 +0900 From: Pyun YongHyeon To: "Stefan 'Steve' Tell" Message-ID: <20070123004714.GF29223@cdnetworks.co.kr> References: <20070122013416.GA29223@cdnetworks.co.kr> <87r6tn6kpu.fsf@zeus.crashmail.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r6tn6kpu.fsf@zeus.crashmail.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap while configuring re0 (Realtek 8136) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 00:46:10 -0000 On Mon, Jan 22, 2007 at 06:21:33PM +0100, Stefan 'Steve' Tell wrote: > * Pyun YongHyeon wrote: > > On Sun, Jan 21, 2007 at 06:36:00PM +0100, Stefan 'Steve' Tell wrote: > > >> re0@pci4:0:0: class=0x020000 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 > >> class = network > >> subclass = ethernet > >> none3@pci6:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 > >> class = network > > > How about attached one? > > Very cool, it works. I've brought the device up and dhclient re0 get's > an IP from my router. Very nice and many thanks for this. > Committed(if_re.c rev, 1.83). MFC after 1 week. Thanks for the report and testing. > There are some new ACPI-1304-warnings now. I'll post them later to this > mailinglist. > > -- > By(t)e, > Steve /\ http://www.crashmail.de > > GnuPG/PGP: 0x9B6C7E15, encrypted mail prefered, see header > -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 05:09:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C740A16A400 for ; Tue, 23 Jan 2007 05:09:09 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by mx1.freebsd.org (Postfix) with ESMTP id 8859E13C45D for ; Tue, 23 Jan 2007 05:09:09 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-24-27-51-69.austin.res.rr.com [24.27.51.69]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 47007329-1817707 for ; Mon, 22 Jan 2007 23:09:08 -0600 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.8/8.13.8) with ESMTP id l0N598ws017961 for ; Mon, 22 Jan 2007 23:09:08 -0600 (CST) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.8/8.13.8/Submit) id l0N598X8017960 for freebsd-stable@freebsd.org; Mon, 22 Jan 2007 23:09:08 -0600 (CST) (envelope-from brucegb) Date: Mon, 22 Jan 2007 23:09:08 -0600 From: Bruce Burden To: freebsd-stable@freebsd.org Message-ID: <20070123050907.GD89970@tigerfish2.my.domain> References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <72347C40-81E3-4E4D-9F27-3058B73359B3@khera.org> <45B1BF6E.7090704@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 05:09:09 -0000 On Mon, Jan 22, 2007 at 03:01:13PM -0500, Vivek Khera wrote: > On Jan 20, 2007, at 2:06 AM, LI Xin wrote: > > >>My newer 2230SLP cards do not work with any extant command line tools > >>for freebsd under amd64. The older cards did. I've tested > >>FreeBSD 6.0 > >>and 6.1. 6.2 is on the agenda to test soon. > > > The linux tools have 0 chance of working on amd64.... > > I have some newer version from one of the freebsd devs of adaptec CLI > but it doesn't recognize the latest firmware in the 2230 card. > Sigh. Okay, thank you for the responses. I think I will go with "Plan 'C'", and find a PCI-X LSI MegaRAID card. I think there is some hope the megamgr port will work with them. Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 07:06:47 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C61C16A403 for ; Tue, 23 Jan 2007 07:06:47 +0000 (UTC) (envelope-from 54netkey@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id D426613C4C4 for ; Tue, 23 Jan 2007 07:06:46 +0000 (UTC) (envelope-from 54netkey@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so752183pyh for ; Mon, 22 Jan 2007 23:06:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=bROTRTpqeOPcYsFjbOW4g1Uf5DCtNcczoRDGNo1560jEeLZgNxEqTEPeTB7cQx6esYz+qV/zhK1C8A/5xlbNoUpaP18iKHsF+bXTm5XWEH/Y1VThsFtw/q6JYy7IWDE35OhcRmaoA23/ved+oVxqwiDfovv7XjXkyaya+1LHvjk= Received: by 10.35.98.6 with SMTP id a6mr12228291pym.1169534283069; Mon, 22 Jan 2007 22:38:03 -0800 (PST) Received: from nwsd2w0xm01qsco ( [219.136.186.67]) by mx.google.com with ESMTP id 37sm5142776nzf.2007.01.22.22.37.58; Mon, 22 Jan 2007 22:38:02 -0800 (PST) Date: Tue, 23 Jan 2007 14:37:59 +0800 From: "54netkey" <54netkey@gmail.com> To: "freebsd-stable" Message-ID: <200701231437564214220@gmail.com> X-mailer: Foxmail 6, 4, 104, 20 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (no subject) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 07:06:47 -0000 ... 54netkey 2007-01-23 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 07:58:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92DF516A401 for ; Tue, 23 Jan 2007 07:58:42 +0000 (UTC) (envelope-from casner@acm.org) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by mx1.freebsd.org (Postfix) with ESMTP id 81CA213C428 for ; Tue, 23 Jan 2007 07:58:42 +0000 (UTC) (envelope-from casner@acm.org) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id l0N7weN6006491; Mon, 22 Jan 2007 23:58:40 -0800 Date: Tue, 23 Jan 2007 00:15:39 -0800 (PST) From: Stephen Casner Sender: casner@packetdesign.com To: freebsd-stable@freebsd.org Message-ID: <20070123001343.J641@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: System hang on laptop suspend/resume X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 07:58:42 -0000 [Working my way up the food chain here after no response on freebsd-questions and freebsd-mobile. Please tell me if this question is ill-formed or if the answer is unlikely to be known.] I was running FreeBSD 4.8 on my Sony PCG-505TR laptop for about three years until I recently upgraded to 6.1 with a clean install on a new disk drive. One aspect of FreeBSD that I really liked was that suspend-to-memory and resume worked perfectly and quickly every time, whereas when I had previously tried this with Windows it usually failed. I did not even need to run apmd or configure any suspend or resume scripts other than the normal configuration in pccard.conf for the an0 802.11 network card. Sadly, with FreeBSD 6.1, the result is often a system hang requiring a power cycle to recover. I have found that I can avoid the hang if I do two things before suspend: - switch the display from X to the console vty (which I have automated using vidcontrol as suggested in the laptop article) - manually unplug the 802.11 network card and wait for dhclient to exit before suspending, and leave the card unplugged until after resuming My question is this: How can I programmatically power down or detach the network card? "ifconfig an0 down" is not sufficient. I'm worried about wearing out my PC Card slot by frequently unplugging the card. On 4.8, I used "pccardc power 0 0" to power down the card, but on 6.1 it results in the error message: pccardc: /dev/card0: No such file or directory In the mail archive, I saw that pccardc is not supported in NEWCARD, but the binary and man page are still included in the 6.1 release. Or is there something else I should be doing instead? Here are additional details -- - This laptop BIOS supports APM but not ACPI. - I am running apmd and have it configured to invoke rc.suspend and rc.resume, which in turn run vidcontrol. - I have two network cards: an0 and ath0. For an0, the hang occurs on resume about half the time. With ath0, it aways hangs. - The hang is indicated by a timeout on ad0 (see below). At that point, I can switch vtys among 1-8, but going to vty9 (X server) will hang. Ctrl-Alt-Delete does nothing. Return just echoes return, no login prompt (will echo more than once). - Pulling Aironet card and replugging results in: Interrupt storm detected on "irq9:"; throttling interrrupt source Messages on the console vty (manually copied): Dec 2 00:57:56 kao root: Received USERSUSPENDREQ Dec 2 00:57:56 kao apm: suspend an0: detached Dec 2 14:32:20 kao root: Received NORMRESUME Dec 2 14:32:20 kao apm: resumed from suspend Dec 2 14:32:20 kao dhclient[3365]: send_packet: Device not configured an0: at port 0x100-0x13f irq 9 function 0 config 5 on pccard0 an0: got RSSI <-> dBM map an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps an0: Ethernet address: 00:40:96:32:05:b7 an0: [GIANT-LOCKED] ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=68041200 Messages from /var/log/messages: Dec 2 00:57:56 kao apmd[412]: apmevent 000a index 7 Dec 2 00:57:56 kao root: Received USERSUSPENDREQ Dec 2 00:57:56 kao apm: suspend Dec 2 14:32:20 kao kernel: an0: detached Dec 2 14:32:20 kao kernel: wakeup from sleeping state (slept 13:34:17) Dec 2 14:32:19 kao apmd[412]: apmevent 0003 index 8 Dec 2 14:32:20 kao root: Received NORMRESUME Dec 2 14:32:20 kao apm: resumed from suspend Dec 2 14:32:20 kao dhclient[3365]: send_packet: Device not configured Dec 2 14:54:13 kao syslogd: kernel boot file is /boot/kernel/kernel Note that some log messages are written after resuming and before the hang, so ad0 is working up to the point where it gets the timeout. -- Steve From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 10:18:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E864E16A400 for ; Tue, 23 Jan 2007 10:18:50 +0000 (UTC) (envelope-from dzalewski@open-craft.com) Received: from zeus.lunarpages.com (zeus.lunarpages.com [216.193.211.2]) by mx1.freebsd.org (Postfix) with ESMTP id CE9D613C442 for ; Tue, 23 Jan 2007 10:18:50 +0000 (UTC) (envelope-from dzalewski@open-craft.com) Received: from [196.218.200.206] (helo=polonium.opencraft.local) by zeus.lunarpages.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1H9IG6-0005xk-Ez for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 01:48:07 -0800 From: Dominik Zalewski Organization: OpenCraft To: freebsd-stable@freebsd.org Date: Tue, 23 Jan 2007 11:48:58 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701231148.58209.dzalewski@open-craft.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zeus.lunarpages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - open-craft.com X-Source: X-Source-Args: X-Source-Dir: Subject: FreeBSD 6.2 ipw3945 on HP Pavilion dv6000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dzalewski@open-craft.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 10:18:51 -0000 Hi All, I'm running FreeBSD 6.2-RELEASE on HP Pavilion dv6000. I have a problem with intel 3945 wireless card. Simply, kernel didnt detect any ipw* device. When I'm loading a module if_ipw nothing happen. I tried also to compile this driver static into the kernel. No results :( I installed /usr/ports/net/ipw-firmware Any ideas? Thank you in advance, Dominik here is my dmesg output: FreeBSD 6.2-RELEASE #2: Wed Jan 24 11:27:35 EET 2007 root@argon.opencraft.local:/usr/obj/usr/src/sys/OWAHAB Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1829.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd,CX16,,> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 1072103424 (1022 MB) avail memory = 1035800576 (987 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xdd000000-0xddffffff,0xc0000000-0xcfffffff,0xdc000000-0xdcffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] pci0: at device 27.0 (no driver attached) pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci5: on pcib4 em0: port 0x4000-0x401f mem 0xda000000-0xda01ffff irq 18 at device 0.0 on pci5 em0: Ethernet address: 00:16:36:b7:63:e6 uhci0: port 0x1800-0x181f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] 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 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] 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 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xde304000-0xde3043ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ugen0: Sonix Technology Co., Ltd. USB 2.0 Camera, rev 2.00/1.00, addr 2 pcib5: at device 30.0 on pci0 pci7: on pcib5 pci7: at device 5.0 (no driver attached) pci7: at device 5.1 (no driver attached) pci7: at device 5.2 (no driver attached) pci7: at device 5.3 (no driver attached) pci7: at device 5.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x18c8-0x18cf,0x18ac-0x18af,0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf mem 0xde304400-0xde3047ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 ata5: on atapci1 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff,0xdf000-0xdf7ff,0xe0000-0xe17ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen1: Broadcom Corp HP Integrated Module, rev 2.00/1.00, addr 2 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master PIO4 ad4: 95396MB at ata2-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s2a From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 10:50:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06BE216A402 for ; Tue, 23 Jan 2007 10:50:33 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mailhost.graphdata.co.uk (mailhost.graphdata.co.uk [195.12.22.194]) by mx1.freebsd.org (Postfix) with ESMTP id BB24713C4C9 for ; Tue, 23 Jan 2007 10:50:32 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mailhost.graphdata.co.uk (Postfix) with ESMTP id C5D68114025; Tue, 23 Jan 2007 10:50:30 +0000 (GMT) X-Virus-Scanned: amavisd-new at graphdata.co.uk Received: from mailhost.graphdata.co.uk ([127.0.0.1]) by localhost (mailhost.graphdata.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHotAeLtXnPL; Tue, 23 Jan 2007 10:50:28 +0000 (GMT) Received: from gdc083.internal.graphdata.co.uk (gdc083.internal.graphdata.co.uk [192.168.0.86]) by mailhost.graphdata.co.uk (Postfix) with SMTP id 12B80114023; Tue, 23 Jan 2007 10:50:28 +0000 (GMT) Date: Tue, 23 Jan 2007 10:50:27 +0000 From: Dominic Marks To: freebsd-stable@freebsd.org Message-Id: <20070123105027.90d433de.dom@helenmarks.co.uk> In-Reply-To: <200701231148.58209.dzalewski@open-craft.com> References: <200701231148.58209.dzalewski@open-craft.com> X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dzalewski@open-craft.com Subject: Re: FreeBSD 6.2 ipw3945 on HP Pavilion dv6000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 10:50:33 -0000 On Tue, 23 Jan 2007 11:48:58 +0200 Dominik Zalewski wrote: > Hi All, > > I'm running FreeBSD 6.2-RELEASE on HP Pavilion dv6000. I have a problem with > intel 3945 wireless card. Simply, kernel didnt detect any ipw* device. When > I'm loading a module if_ipw nothing happen. I tried also to compile this > driver static into the kernel. No results :( > > I installed /usr/ports/net/ipw-firmware > > > Any ideas? I can't help you specifically but often the output of `pciconf -lv` is useful to the developers. Dominic From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 11:35:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C752916A401; Tue, 23 Jan 2007 11:35:33 +0000 (UTC) (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 B716B13C44B; Tue, 23 Jan 2007 11:35:32 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8D0A5487F3; Tue, 23 Jan 2007 12:35:30 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D118B45683; Tue, 23 Jan 2007 12:35:23 +0100 (CET) Date: Tue, 23 Jan 2007 12:34:44 +0100 From: Pawel Jakub Dawidek To: Alexander Leidinger Message-ID: <20070123113444.GB11767@garage.freebsd.pl> References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <20070113112937.GI90718@garage.freebsd.pl> <20070120122432.GA971@zaphod.nitro.dk> <20070120130308.GD6697@garage.freebsd.pl> <20070120152423.3195b15b@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <20070120152423.3195b15b@Magellan.Leidinger.net> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (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-security@freebsd.org, freebsd-stable@freebsd.org, Colin Percival , "Simon L. Nielsen" Subject: Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 11:35:34 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 20, 2007 at 03:24:23PM +0100, Alexander Leidinger wrote: > Quoting Pawel Jakub Dawidek (Sat, 20 Jan 2007 14:03:08 = +0100): >=20 > > I fully agree that console.log should be outside a jail. At least noone > > proposed safe solution so far, which also means it's not an easy fix. >=20 > What's unsafe about my proposal? I did had a look at the code now, and > it should work (with minor mods). >=20 > Original: > ---snip--- > _tmp_jail=3D${_tmp_dir}/jail.$$ > eval jail ${_flags} -i ${_rootdir} ${_hostname} \ > ${_ip} ${_exec_start} > ${_tmp_jail} 2>&1 >=20 > if [ "$?" -eq 0 ] ; then > _jail_id=3D$(head -1 ${_tmp_jail}) > i=3D1 > while [ true ]; do > eval out=3D\"\${_exec_afterstart${i}:-''}= \" >=20 > if [ -z "$out" ]; then > break; > fi >=20 > jexec "${_jail_id}" ${out} > i=3D$((i + 1)) > done >=20 > echo -n " $_hostname" > tail +2 ${_tmp_jail} >${_consolelog} > echo ${_jail_id} > /var/run/jail_${_jail}.id > ---snip--- >=20 > Pseudocode proposal, not tested (changes prefixed with 'x'): > ---snip--- > _tmp_jail=3D${_tmp_dir}/jail.$$ > x # assuming safe _consolelog (inside chroot) according > to the > x # previous mails here in the thread > x eval (echo "" ; \ > x jail ${_flags} -I /var/run/jail_${_jail}.id \ > x ${_rootdir} ${_hostname} {_ip} ${_exec_start}) \ > x > ${_consolelog} 2>&1 >=20 > if [ "$?" -eq 0 ] ; then > x _jail_id=3D$(cat /var/run/jail_${_jail}.id) > i=3D1 > while [ true ]; do > eval out=3D\"\${_exec_afterstart${i}:-''}= \" >=20 > if [ -z "$out" ]; then > break; > fi >=20 > jexec "${_jail_id}" ${out} > i=3D$((i + 1)) > done >=20 > echo -n " $_hostname" > x > x > ---snip--- >=20 > Repeating my points: > - sanitize the consolelog path like discussed in this thread > - the jail is not running, so nobody can create a link (jail > root within FS space of another jail still prohibited) > - subshell to group echo and jail > - 'echo ""' to make sure the file exists when the jail starts > - (new) additional flag to jail to write a jid file > - redirect to the consolelog, it is still open from the echo > when the jail starts so there's no race >=20 > I did test "(echo 1; sleep 60 ; echo 2) >/tmp/test" in /bin/sh, and it > is line buffered, so the above works. >=20 > Where's the security problem in the above? It looks like it may work, but I still find it a bit risky. If sh(1) can reopen the file under some conditions or someone in the future will modify sh(1) in that way (because he won't be aware that such a change may have impact on system security) we will have a security hole. Chances are small, but I'm not going to be the one who will accept that change:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtfLUForvXbEpPzQRAoo1AJ9Q/u5YAPeHsQiOUBCEEOR8BzKuoACbBnQH g1ixkeanvC5aURwI48b/TW4= =TDkY -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 12:25:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F40216A400; Tue, 23 Jan 2007 12:25:20 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E003413C4E7; Tue, 23 Jan 2007 12:25:19 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5DA15.dip.t-dialin.net [84.165.218.21]) by redbull.bpaserver.net (Postfix) with ESMTP id 202692E1B0; Tue, 23 Jan 2007 13:34:26 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8A1395B4C0E; Tue, 23 Jan 2007 13:25:08 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0NCP8j1007485; Tue, 23 Jan 2007 13:25:08 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 23 Jan 2007 13:25:08 +0100 Message-ID: <20070123132508.oy4elyx7kkogokkg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 23 Jan 2007 13:25:08 +0100 From: Alexander Leidinger To: Pawel Jakub Dawidek References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <20070113112937.GI90718@garage.freebsd.pl> <20070120122432.GA971@zaphod.nitro.dk> <20070120130308.GD6697@garage.freebsd.pl> <20070120152423.3195b15b@Magellan.Leidinger.net> <20070123113444.GB11767@garage.freebsd.pl> In-Reply-To: <20070123113444.GB11767@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-security@FreeBSD.org, freebsd-stable@FreeBSD.org, Colin Percival , "Simon L. Nielsen" Subject: Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 12:25:20 -0000 Quoting Pawel Jakub Dawidek (from Tue, 23 Jan 2007 =20 12:34:44 +0100): > On Sat, Jan 20, 2007 at 03:24:23PM +0100, Alexander Leidinger wrote: >> Quoting Pawel Jakub Dawidek (Sat, 20 Jan 2007 =20 >> 14:03:08 +0100): >> >> > I fully agree that console.log should be outside a jail. At least noone >> > proposed safe solution so far, which also means it's not an easy fix. >> >> What's unsafe about my proposal? I did had a look at the code now, and >> it should work (with minor mods). >> >> Original: >> ---snip--- >> _tmp_jail=3D${_tmp_dir}/jail.$$ >> eval jail ${_flags} -i ${_rootdir} ${_hostname} \ >> ${_ip} ${_exec_start} > ${_tmp_jail} 2>&1 >> >> if [ "$?" -eq 0 ] ; then >> _jail_id=3D$(head -1 ${_tmp_jail}) >> i=3D1 >> while [ true ]; do >> eval out=3D\"\${_exec_afterstart${i}:-''}= \" >> >> if [ -z "$out" ]; then >> break; >> fi >> >> jexec "${_jail_id}" ${out} >> i=3D$((i + 1)) >> done >> >> echo -n " $_hostname" >> tail +2 ${_tmp_jail} >${_consolelog} >> echo ${_jail_id} > /var/run/jail_${_jail}.id >> ---snip--- >> >> Pseudocode proposal, not tested (changes prefixed with 'x'): >> ---snip--- >> _tmp_jail=3D${_tmp_dir}/jail.$$ >> x # assuming safe _consolelog (inside chroot) according >> to the >> x # previous mails here in the thread >> x=09=09eval (echo "" ; \ >> x jail ${_flags} -I /var/run/jail_${_jail}.id \ >> x ${_rootdir} ${_hostname} {_ip} ${_exec_start}) \ >> x > ${_consolelog} 2>&1 >> >> if [ "$?" -eq 0 ] ; then >> x _jail_id=3D$(cat /var/run/jail_${_jail}.id) >> i=3D1 >> while [ true ]; do >> eval out=3D\"\${_exec_afterstart${i}:-''}= \" >> >> if [ -z "$out" ]; then >> break; >> fi >> >> jexec "${_jail_id}" ${out} >> i=3D$((i + 1)) >> done >> >> echo -n " $_hostname" >> x >> x >> ---snip--- >> >> Repeating my points: >> - sanitize the consolelog path like discussed in this thread >> - the jail is not running, so nobody can create a link (jail >> root within FS space of another jail still prohibited) >> - subshell to group echo and jail >> - 'echo ""' to make sure the file exists when the jail starts >> - (new) additional flag to jail to write a jid file >> - redirect to the consolelog, it is still open from the echo >> when the jail starts so there's no race >> >> I did test "(echo 1; sleep 60 ; echo 2) >/tmp/test" in /bin/sh, and it >> is line buffered, so the above works. >> >> Where's the security problem in the above? > > It looks like it may work, but I still find it a bit risky. If sh(1) can > reopen the file under some conditions or someone in the future will > modify sh(1) in that way (because he won't be aware that such a change > may have impact on system security) we will have a security hole. > Chances are small, but I'm not going to be the one who will accept that > change:) The spawned subshell is like a command. It doesn't make sense to =20 reopen the file for a command. It's like saying we open and close the =20 file for each line. I didn't calculated the probability of this to =20 happen, but I would be very surprised if it is significant. Just think =20 about the performance of such behavior (or a more complex logic which =20 open()/close()es in a more complex way). And if you think about such =20 unlikely stuff to happen, you should also think about some other stuff =20 we are not prepared to survive. But feel free to propose a better =20 solution for the problem. Bye, Alexander. --=20 In Newark the laundromats are open 24 hours a day! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 12:41:10 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0124E16A401 for ; Tue, 23 Jan 2007 12:41:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4D513C4BA for ; Tue, 23 Jan 2007 12:41:09 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.246] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1H9KxT1VIA-0000Hr; Tue, 23 Jan 2007 13:41:04 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org, dzalewski@open-craft.com Date: Tue, 23 Jan 2007 13:40:55 +0100 User-Agent: KMail/1.9.5 References: <200701231148.58209.dzalewski@open-craft.com> In-Reply-To: <200701231148.58209.dzalewski@open-craft.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6613468.uPK64j58Ov"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701231341.02538.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: FreeBSD 6.2 ipw3945 on HP Pavilion dv6000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 12:41:10 -0000 --nextPart6613468.uPK64j58Ov Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 23 January 2007 10:48, Dominik Zalewski wrote: > I'm running FreeBSD 6.2-RELEASE on HP Pavilion dv6000. I have a problem > with intel 3945 wireless card. Simply, kernel didnt detect any ipw* > device. When I'm loading a module if_ipw nothing happen. I tried also > to compile this driver static into the kernel. No results :( > > I installed /usr/ports/net/ipw-firmware > > > Any ideas? =46rom the ipw(4) manual page: ipw -- Intel PRO/Wireless 2100 IEEE 802.11 driver i.e. 3945 hardware is *not* supported by this driver - sorry. There is an= =20 ongoing effort to port a driver called wpi(4) to support this hardware,=20 details at: http://www.clearchain.com/wiki/Wpi But this is in an early=20 stage of development. Testing is welcome, however. An additional=20 possibility is the ndis framework - see ndisgen(8). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6613468.uPK64j58Ov Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFtgJeXyyEoT62BG0RAh0zAJ9DWgHqJuTIs/h06+vvpUdyTEQ6ZACeOTBN 4m7K1i8lLgF3pS4lYMQl4Zs= =vI1m -----END PGP SIGNATURE----- --nextPart6613468.uPK64j58Ov-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 12:43:39 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EB1416A402; Tue, 23 Jan 2007 12:43:39 +0000 (UTC) (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 45A0B13C4A7; Tue, 23 Jan 2007 12:43:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C7A9B487FF; Tue, 23 Jan 2007 13:43:35 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5F41A45684; Tue, 23 Jan 2007 13:43:27 +0100 (CET) Date: Tue, 23 Jan 2007 13:42:48 +0100 From: Pawel Jakub Dawidek To: Alexander Leidinger Message-ID: <20070123124247.GC11767@garage.freebsd.pl> References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <20070113112937.GI90718@garage.freebsd.pl> <20070120122432.GA971@zaphod.nitro.dk> <20070120130308.GD6697@garage.freebsd.pl> <20070120152423.3195b15b@Magellan.Leidinger.net> <20070123113444.GB11767@garage.freebsd.pl> <20070123132508.oy4elyx7kkogokkg@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+" Content-Disposition: inline In-Reply-To: <20070123132508.oy4elyx7kkogokkg@webmail.leidinger.net> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (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-security@FreeBSD.org, freebsd-stable@FreeBSD.org, Colin Percival , "Simon L. Nielsen" Subject: Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 12:43:39 -0000 --ZwgA9U+XZDXt4+m+ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 23, 2007 at 01:25:08PM +0100, Alexander Leidinger wrote: > Quoting Pawel Jakub Dawidek (from Tue, 23 Jan 2007 12:3= 4:44 +0100): > >It looks like it may work, but I still find it a bit risky. If sh(1) can > >reopen the file under some conditions or someone in the future will > >modify sh(1) in that way (because he won't be aware that such a change > >may have impact on system security) we will have a security hole. > >Chances are small, but I'm not going to be the one who will accept that > >change:) >=20 > The spawned subshell is like a command. It doesn't make sense to reopen t= he file for a command. It's like saying we open and close the file for each= line. I didn't=20 > calculated the probability of this to happen, but I would be very surpris= ed if it is significant. Just think about the performance of such behavior = (or a more complex logic=20 > [...] And if you think about such unlikely stuff to happen, you should al= so think about some other stuff we are not prepared to=20 > survive. [...] Come on, this argument always stands. I only wanted to point out that we should be extra careful with building security on top of tools that are not intended for this purpose. > [...] But feel free to propose a better solution for the problem. The solution was proposed already - keep console.log outside of jail. Don't read my comment as a "no" vote for your solution. If secteam@ decide there is nothing to be worry about - fine by me. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ZwgA9U+XZDXt4+m+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtgLHForvXbEpPzQRAnjAAJ9ueKbsFjJFL0MTvyM7I7zDpXo3PgCeJY9t /DVf7IrfkNtREpzBhkLsXEY= =ndf4 -----END PGP SIGNATURE----- --ZwgA9U+XZDXt4+m+-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 16:43:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D2B216A417 for ; Tue, 23 Jan 2007 16:43:50 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 258D813C507 for ; Tue, 23 Jan 2007 16:43:50 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCB00AAOYGVH2E0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 17:43:43 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCB001CLYGVXW60@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 17:43:43 +0100 (CET) Date: Tue, 23 Jan 2007 17:43:43 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <200701231148.58209.dzalewski@open-craft.com> To: freebsd-stable@freebsd.org Message-id: <20070123174343.4acafcca.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200701231148.58209.dzalewski@open-craft.com> Cc: dzalewski@open-craft.com Subject: Re: FreeBSD 6.2 ipw3945 on HP Pavilion dv6000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 16:43:50 -0000 On Tue, 23 Jan 2007 11:48:58 +0200 Dominik Zalewski wrote: > I'm running FreeBSD 6.2-RELEASE on HP Pavilion dv6000. I have a > problem with intel 3945 wireless card. Simply, kernel didnt detect > any ipw* device. When I'm loading a module if_ipw nothing happen. I > tried also to compile this driver static into the kernel. No results : There are already answers in this thread: the ipw driver does not support the intel 3945. However, there is a work-in-progress driver (wpi) at http://people.freebsd.org/%7Eflz/local/wpi/ which I'm using on a Acer Aspire AS5672 laptop with good results. I'm even using WPA encryption. YMMV. For me, the driver only works with acpi disabled, but I think the reason for that have more to do with my laptop and bios /acpi issues. If you want more information, search the archives of the freebsd-mobile mailinglist for "intel 3945". HTH -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 16:48:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B3CF16A403; Tue, 23 Jan 2007 16:48:09 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE4E13C45D; Tue, 23 Jan 2007 16:48:09 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.26.75] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0NGm4XV016006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 08:48:06 -0800 Message-ID: <45B63C3E.9010808@freebsd.org> Date: Tue, 23 Jan 2007 08:47:58 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dimitry Andric References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> In-Reply-To: <45B48F0C.9090809@andric.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FD97F734167E6F5E0E2A499" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 16:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FD97F734167E6F5E0E2A499 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> and later I found out it was caused by commit 1.48.2.16: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/03185= 3.html >> This isn't consistent with what I'm finding. For one thing, rev. >> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there >> anyways. Also, that's not the change I made to my local sources to ge= t >> my gif(4) tunnel working. Are you sure about this? :-) >=20 > I'm following -STABLE, and 1.48.2.16 is in there. Since it was > committed on 29 Nov, I suspected it would end up in -RELEASE, but > apparently not. :) >=20 > I explicitly tried reverting just this one commit, and for me it solved= > the problem (i.e. the automagical addition of needed routing entries). I tried this too and it didn't help. :-( Just to confirm, you're dealing with a gif(4) interface with an explicitly-configured destination address and a 128-bit prefixlen, yes? > So for you, reverting the combination of 1.48.2.14 and .15 works? Yep. BTW these two changes really go together, so it doesn't really make sense to revert just one of them (the commit logs implied that this would be fairly broken in other ways). > Maybe > there is something else involved too, for example the route command > itself? Not sure what you mean by this exactly...???... Here's what I've tested so far...in the table below, "work" means that the host route to the destination got installed correctly and "no work" means that it didn't. Base Local Patch Result ---- ----------- ------ 6.2-RELEASE Unmodified No work 6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Unmodified No work 6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Revert nd6.c 1.48.2.16 No work I'm going to write up an entry for the 6.2-RELEASE errata notes documenting the existence of a problem and a workaround. We still need to figure out exactly what the right fix is. Testing results from other users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome. Bruce. --------------enig3FD97F734167E6F5E0E2A499 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFtjw+2MoxcVugUsMRAtqCAKDLjhYA+KIyxLDcsWMPUqUPktHy1QCdG2pL a5DO4JF6QFuYE9xf+z7WNng= =YYxb -----END PGP SIGNATURE----- --------------enig3FD97F734167E6F5E0E2A499-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 17:23:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A37C416A400 for ; Tue, 23 Jan 2007 17:23:16 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [192.188.162.7]) by mx1.freebsd.org (Postfix) with ESMTP id 8968813C4B8 for ; Tue, 23 Jan 2007 17:23:15 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NHNE5l063709 for ; Tue, 23 Jan 2007 11:23:15 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NHN6Jg011243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jan 2007 11:23:06 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45B64469.9020002@palisadesys.com> Date: Tue, 23 Jan 2007 11:22:49 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Tue, 23 Jan 2007 11:23:07 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_21 0.60, UPPERCASE_25_50 0.00) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 17:23:16 -0000 Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ motherboard (dual Xeon 5130 CPUs on the Blackford chipset - http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) hanging after printing the "Waiting 5 seconds for SCSI devices to settle" message. The hang doesn't always happen - sometimes we have to go through several reboot cycles for it to happen - but sometimes it happens with every reboot. For those who would suggest that this happens because I'm using Seagate drives, it happens even if we totally remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit ethernet NICs aren't found but the hang doesn't occur. I've built a kernel with kdb/ddb in it, and cause an NMI to drop into the debugger when it seems hung. If I don't boot with the -v flag, then I'm able to use "n" a few times and seem to wind up in em0's interrupt handler, then issuing "c" results in "Interrupt storm detected on "irq18:"; throttling interrupt source" followed by a message from ahd0 beginning with "Recovery Initiated - Card was not paused" and by a dump of the card state, and then the kernel finishes booting! If I boot with the -v flag, then after the NMI the machine hangs again no matter where I issue the "c" command. If I keep issuing the "n" command instead of "c", it hangs here: ... After 9 instructions (0 loads, 0 stores), [thread pid 25 tid 100819 ] Stopped at intr_execute_handlers+0x...: ret db> n After 2 instructions (0 loads, 0 stores), [thread pid 25 tid 100819 ] Stopped at lapic_handle_intr+0x22: ret db> n "ps" shows pid 25 is running on cpu 0 and handling irq30: ahd0. Full dmesg and acpidump follow. If anyone has any ideas or would like more details, please let me know! Guy Helmer Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RC2 #1: Mon Jan 22 18:51:58 UTC 2007 support@palisadesys.com:/usr/src/sys/amd64/compile/PALISADE-SMP-DEBUG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5130 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e33d,CX16,,,> AMD Features=0x20000800 AMD Features2=0x1 Cores per package: 2 real memory = 5368709120 (5120 MB) avail memory = 4116361216 (3925 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: irq 18 at device 2.0 on pci2 pci4: on pcib4 em0: port 0x2000-0x201f mem 0xc8200000-0xc821ffff irq 18 at device 0.0 on pci4 em0: Ethernet address: 00:30:48:31:1f:76 em1: port 0x2020-0x203f mem 0xc8220000-0xc823ffff irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:30:48:31:1f:77 pcib5: at device 0.3 on pci1 pci5: on pcib5 ahd0: port 0x3400-0x34ff,0x3000-0x30ff mem 0xc8300000-0xc8301fff irq 30 at device 2.0 on pci5 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x3c00-0x3cff,0x3800-0x38ff mem 0xc8302000-0xc8303fff irq 31 at device 2.1 on pci5 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pcib6: at device 4.0 on pci0 pci6: on pcib6 pcib7: at device 6.0 on pci0 pci7: on pcib7 pci0: at device 8.0 (no driver attached) pcib8: irq 17 at device 28.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] 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 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] 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 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xc8000000-0xc80003ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib10: at device 30.0 on pci0 pci10: on pcib10 pci10: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDROM at ata0-slave UDMA33 Waiting 5 seconds for SCSI devices to settle NMI ... going to debugger NMI ... going to debugger Interrupt storm detected on "irq18:"; throttling interrupt source ahd0: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x5 Mode 0x33 INTSTAT[0x0] SELOID[0xa] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x18]:(P_DATAOUT|SELI|ATNI) SCSIPHASE[0x0] SCSIBUS[0x80] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x40]:(ENSELO) SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x0] KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x10]:(SELINGO) SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 8 LASTSCB 0xffff CURRSCB 0x6 NEXTSCB 0x0 qinstart = 17 qinfifonext = 17 QINFIFO: WAITING_TID_QUEUES: 10 ( 0x6 ) 11 ( 0x5 ) 12 ( 0x4 ) 13 ( 0x3 ) 14 ( 0x2 ) 15 ( 0x1 ) 0 ( 0xf ) 6 ( 0x8 ) Pending list: 8 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] 15 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x7] 1 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xf7]:(TID) 2 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xe7] 3 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xd7] 4 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xc7] 5 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xb7] 6 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xa7] Total 8 Kernel Free SCB list: 7 9 10 11 12 13 14 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0x9 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0xf, SINDEX = 0x10e, DINDEX = 0x10e ahd0: SCBPTR == 0x6, SCB_NEXT == 0xff80, SCB_NEXT2 == 0x5 CDB 12 0 0 0 24 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (probe0:ahd0:0:0:0): SCB 15 - timed out (probe0:ahd0:0:0:0): Other SCB Timeout (probe14:ahd0:0:15:0): SCB 1 - timed out (probe14:ahd0:0:15:0): Other SCB Timeout (probe13:ahd0:0:14:0): SCB 2 - timed out (probe13:ahd0:0:14:0): Other SCB Timeout (probe12:ahd0:0:13:0): SCB 3 - timed out (probe12:ahd0:0:13:0): Other SCB Timeout (probe11:ahd0:0:12:0): SCB 4 - timed out (probe11:ahd0:0:12:0): Other SCB Timeout (probe10:ahd0:0:11:0): SCB 5 - timed out (probe10:ahd0:0:11:0): Other SCB Timeout (probe9:ahd0:0:10:0): SCB 6 - timed out (probe9:ahd0:0:10:0): Other SCB Timeout ahd1: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0x4 Mode 0x22 INTSTAT[0x0] SELOID[0x6] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x18]:(P_DATAOUT|SELI|ATNI) SCSIPHASE[0x0] SCSIBUS[0xc0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x40]:(ENSELO) SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x0] KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x10]:(SELINGO) SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 9 LASTSCB 0xffff CURRSCB 0x9 NEXTSCB 0x0 qinstart = 15 qinfifonext = 15 QINFIFO: WAITING_TID_QUEUES: 6 ( 0x9 ) 8 ( 0x8 ) 9 ( 0x7 ) 10 ( 0x6 ) 11 ( 0x5 ) 12 ( 0x4 ) 13 ( 0x3 ) 14 ( 0x2 ) 15 ( 0x1 ) Pending list: 1 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xf7]:(TID) 2 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xe7] 3 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xd7] 4 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xc7] 5 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xb7] 6 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xa7] 7 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x97] 8 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x87] 9 FIFO_USE[0x0] SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] Total 9 Kernel Free SCB list: 10 11 12 13 14 15 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd1: FIFO1 Free, LONGJMP == 0x80ff, SCB 0x0 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 ahd1: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd1: REG0 == 0x1, SINDEX = 0x120, DINDEX = 0x120 ahd1: SCBPTR == 0x2, SCB_NEXT == 0xff80, SCB_NEXT2 == 0x1 CDB 12 0 0 0 24 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (probe29:ahd1:0:15:0): SCB 1 - timed out (probe29:ahd1:0:15:0): Other SCB Timeout (probe29:ahd1:0:15:0): No other SCB worth waiting for... ahd1: Issued Channel A Bus Reset. 9 SCBs aborted ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) Trying to mount root from ufs:/dev/da0s1a em0: link state changed to UP em1: link state changed to UP /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of /tmp/acpidump.KdSAue, Tue Jan 23 08:48:00 2007 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "Intel", "BLAKFORD", 100925440) { OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000) Field (RCRB, DWordAcc, Lock, Preserve) { Offset (0x1000), Offset (0x3000), Offset (0x3404), HPAS, 2, , 5, HPAE, 1, Offset (0x3418), , 1, PATD, 1, SATD, 1, SMBD, 1, AZAD, 1, A97D, 1, Offset (0x341A), RE1D, 1, RE2D, 1, RE3D, 1, RE4D, 1 } Scope (_GPE) { Method (_L03, 0, NotSerialized) { Store (0x03, \_SB.PCI0.PT80) Notify (\_SB.PCI0.USB1, 0x02) } Method (_L04, 0, NotSerialized) { Store (0x04, \_SB.PCI0.PT80) Notify (\_SB.PCI0.USB2, 0x02) } Method (_L08, 0, NotSerialized) { Store (0x08, \_SB.PCI0.PT80) Notify (\_SB.PCI0.LPC0.SIO.COM1, 0x02) Notify (\_SB.PCI0.LPC0.SIO.COM2, 0x02) } Method (_L09, 0, NotSerialized) { Store (0x09, \_SB.PCI0.PT80) Notify (\_SB.PCI0.P0P2.BMD0.BPD0, 0x02) Notify (\_SB.PCI0.P0P2.BMD0.BPD1, 0x02) Notify (\_SB.PCI0.P0P2.BMD0.BPD2, 0x02) Notify (\_SB.PCI0.P0P4, 0x02) Notify (\_SB.PCI0.P0P6, 0x02) } Method (_L0B, 0, NotSerialized) { Store (0x0B, \_SB.PCI0.PT80) Notify (\_SB.PCI0.PCIB, 0x02) } Method (_L0C, 0, NotSerialized) { Store (0x0C, \_SB.PCI0.PT80) Notify (\_SB.PCI0.USB3, 0x02) } Method (_L0D, 0, NotSerialized) { Store (0x0D, \_SB.PCI0.PT80) Notify (\_SB.PCI0.EUSB, 0x02) } Method (_L18, 0, NotSerialized) { Store (0x18, \_SB.PCI0.PT80) Notify (\_SB.PCI0.PEX0.PXH0, 0x02) } Method (_L1E, 0, NotSerialized) { Store (0x1E, \_SB.PCI0.PT80) Notify (\_SB.PCI0.LPC0.SIO.KBC0, 0x02) Notify (\_SB.PCI0.LPC0.SIO.MSE0, 0x02) } } Scope (_PR) { Processor (CPU0, 0x00, 0x00001010, 0x06) {} Processor (CPU1, 0x01, 0x00001010, 0x06) {} Processor (CPU2, 0x02, 0x00001010, 0x06) {} Processor (CPU3, 0x03, 0x00001010, 0x06) {} Processor (CPU4, 0x04, 0x00001010, 0x06) {} Processor (CPU5, 0x05, 0x00001010, 0x06) {} Processor (CPU6, 0x06, 0x00001010, 0x06) {} Processor (CPU7, 0x07, 0x00001010, 0x06) {} } Scope (_SB) { OperationRegion (ACB, SystemMemory, 0xBFF69EBC, 0x00000090) Field (ACB, AnyAcc, NoLock, Preserve) { BCMD, 8, DID, 32, INFO, 1104 } Field (ACB, AnyAcc, NoLock, Preserve) { DMY, 40, INF, 8 } OperationRegion (SMIB, SystemIO, 0x0000FE00, 0x02) Field (SMIB, AnyAcc, NoLock, Preserve) { SMIC, 8 } Name (OSTB, 0xFFFFFFFF) Method (OSTP, 0, NotSerialized) { If (LEqual (^OSTB, 0xFFFFFFFF)) { If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Windows 2001")) { Store (0x08, ^OSTB) } Else { Store (0x00, ^OSTB) } } Else { If (CondRefOf (\_OS, Local0)) { If (^SEQL (\_OS, "Microsoft Windows")) { Store (0x01, ^OSTB) } Else { If (^SEQL (\_OS, "Microsoft WindowsME: Millennium Edition")) { Store (0x02, ^OSTB) } Else { If (^SEQL (\_OS, "Microsoft Windows NT")) { Store (0x04, ^OSTB) } Else { Store (0x00, ^OSTB) } } } } Else { Store (0x00, ^OSTB) } } } Return (^OSTB) } Method (SEQL, 2, Serialized) { Noop Store (SizeOf (Arg0), Local0) Store (SizeOf (Arg1), Local1) If (LNot (LEqual (Local0, Local1))) { Return (Zero) } Name (BUF0, Buffer (Local0) {}) Store (Arg0, BUF0) Name (BUF1, Buffer (Local0) {}) Store (Arg1, BUF1) Store (Zero, Local2) While (LLess (Local2, Local0)) { Store (DerefOf (Index (BUF0, Local2)), Local3) Store (DerefOf (Index (BUF1, Local2)), Local4) If (LNot (LEqual (Local3, Local4))) { Return (Zero) } Increment (Local2) } Return (One) } Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_BBN, 0x00) Name (_ADR, 0x00) Name (RSRC, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, 0x0000, 0x00FF, 0x0000, 0x0100, 0x00) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0000, 0x0CF7, 0x0000, 0x0CF8, 0x00) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0D00, 0xFFFF, 0x0000, 0xF300, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000A0000, 0x000BFFFF, 0x00000000, 0x00020000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C0000, 0x000C3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C4000, 0x000C7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C8000, 0x000CBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000CC000, 0x000CFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D0000, 0x000D3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D4000, 0x000D7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D8000, 0x000DBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000DC000, 0x000DFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E0000, 0x000E3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E4000, 0x000E7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E8000, 0x000EBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000EC000, 0x000EFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00) }) Method (_CRS, 0, Serialized) { CreateDWordField (RSRC, 0x01A4, BTMN) CreateDWordField (RSRC, 0x01A8, BTMX) CreateDWordField (RSRC, 0x01B0, BTLN) And (TOLM, 0xF000, Local0) ShiftLeft (Local0, 0x10, Local0) Store (Local0, BTMN) Subtract (0xFEC00000, Local0, BTLN) Subtract (Add (BTMN, BTLN), 0x01, BTMX) CreateBitField (RSRC, 0x02D8, C0RW) CreateDWordField (RSRC, 0x60, C0MN) CreateDWordField (RSRC, 0x64, C0MX) CreateDWordField (RSRC, 0x6C, C0LN) Store (One, C0RW) If (LEqual (And (PAM1, 0x03), 0x01)) { Store (Zero, C0RW) } Store (Zero, C0LN) If (LNot (And (PAM1, 0x03))) { Store (0x4000, C0LN) } CreateBitField (RSRC, 0x03B0, C4RW) CreateDWordField (RSRC, 0x7B, C4MN) CreateDWordField (RSRC, 0x7F, C4MX) CreateDWordField (RSRC, 0x87, C4LN) Store (One, C4RW) If (LEqual (And (PAM1, 0x30), 0x10)) { Store (Zero, C4RW) } Store (Zero, C4LN) If (LNot (And (PAM1, 0x30))) { Store (0x4000, C4LN) } CreateBitField (RSRC, 0x0488, C8RW) CreateDWordField (RSRC, 0x96, C8MN) CreateDWordField (RSRC, 0x9A, C8MX) CreateDWordField (RSRC, 0xA2, C8LN) Store (One, C8RW) If (LEqual (And (PAM2, 0x03), 0x01)) { Store (Zero, C8RW) } Store (Zero, C8LN) If (LNot (And (PAM2, 0x03))) { Store (0x4000, C8LN) } CreateBitField (RSRC, 0x0560, CCRW) CreateDWordField (RSRC, 0xB1, CCMN) CreateDWordField (RSRC, 0xB5, CCMX) CreateDWordField (RSRC, 0xBD, CCLN) Store (One, CCRW) If (LEqual (And (PAM2, 0x30), 0x10)) { Store (Zero, CCRW) } Store (Zero, CCLN) If (LNot (And (PAM2, 0x30))) { Store (0x4000, CCLN) } CreateBitField (RSRC, 0x0638, D0RW) CreateDWordField (RSRC, 0xCC, D0MN) CreateDWordField (RSRC, 0xD0, D0MX) CreateDWordField (RSRC, 0xD8, D0LN) Store (One, D0RW) If (LEqual (And (PAM3, 0x03), 0x01)) { Store (Zero, D0RW) } Store (Zero, D0LN) If (LNot (And (PAM3, 0x03))) { Store (0x4000, D0LN) } CreateBitField (RSRC, 0x0710, D4RW) CreateDWordField (RSRC, 0xE7, D4MN) CreateDWordField (RSRC, 0xEB, D4MX) CreateDWordField (RSRC, 0xF3, D4LN) Store (One, D4RW) If (LEqual (And (PAM3, 0x30), 0x10)) { Store (Zero, D4RW) } Store (Zero, D4LN) If (LNot (And (PAM3, 0x30))) { Store (0x4000, D4LN) } CreateBitField (RSRC, 0x07E8, D8RW) CreateDWordField (RSRC, 0x0102, D8MN) CreateDWordField (RSRC, 0x0106, D8MX) CreateDWordField (RSRC, 0x010E, D8LN) Store (One, D8RW) If (LEqual (And (PAM4, 0x03), 0x01)) { Store (Zero, D8RW) } Store (Zero, D8LN) If (LNot (And (PAM4, 0x03))) { Store (0x4000, D8LN) } CreateBitField (RSRC, 0x08C0, DCRW) CreateDWordField (RSRC, 0x011D, DCMN) CreateDWordField (RSRC, 0x0121, DCMX) CreateDWordField (RSRC, 0x0129, DCLN) Store (One, DCRW) If (LEqual (And (PAM4, 0x30), 0x10)) { Store (Zero, DCRW) } Store (Zero, DCLN) If (LNot (And (PAM4, 0x30))) { Store (0x4000, DCLN) } CreateBitField (RSRC, 0x0998, E0RW) CreateDWordField (RSRC, 0x0138, E0MN) CreateDWordField (RSRC, 0x013C, E0MX) CreateDWordField (RSRC, 0x0144, E0LN) Store (One, E0RW) If (LEqual (And (PAM5, 0x03), 0x01)) { Store (Zero, E0RW) } Store (Zero, E0LN) If (LNot (And (PAM5, 0x03))) { Store (0x4000, E0LN) } CreateBitField (RSRC, 0x0A70, E4RW) CreateDWordField (RSRC, 0x0153, E4MN) CreateDWordField (RSRC, 0x0157, E4MX) CreateDWordField (RSRC, 0x015F, E4LN) Store (One, E4RW) If (LEqual (And (PAM5, 0x30), 0x10)) { Store (Zero, E4RW) } Store (Zero, E4LN) If (LNot (And (PAM5, 0x30))) { Store (0x4000, E4LN) } CreateBitField (RSRC, 0x0B48, E8RW) CreateDWordField (RSRC, 0x016E, E8MN) CreateDWordField (RSRC, 0x0172, E8MX) CreateDWordField (RSRC, 0x017A, E8LN) Store (One, E8RW) If (LEqual (And (PAM6, 0x03), 0x01)) { Store (Zero, E8RW) } Store (Zero, E8LN) If (LNot (And (PAM6, 0x03))) { Store (0x4000, E8LN) } CreateBitField (RSRC, 0x0C20, ECRW) CreateDWordField (RSRC, 0x0189, ECMN) CreateDWordField (RSRC, 0x018D, ECMX) CreateDWordField (RSRC, 0x0195, ECLN) Store (One, ECRW) If (LEqual (And (PAM6, 0x30), 0x10)) { Store (Zero, ECRW) } Store (Zero, ECLN) If (LNot (And (PAM6, 0x30))) { Store (0x4000, ECLN) } Return (RSRC) } Method (_INI, 0, NotSerialized) { \_SB.OSTP () } Device (P0P2) { Name (_ADR, 0x00020000) OperationRegion (PCE2, PCI_Config, 0x00, 0xFF) Field (PCE2, DWordAcc, NoLock, Preserve) { Offset (0x48), , 9, PGPE, 1, Offset (0x88), , 3, PMEI, 1, Offset (0x8E), PMES, 1 } Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 } }) } Else { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 } }) } } Device (BMD0) { Name (_ADR, 0x00) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x03) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 } }) } Else { Return (Package (0x03) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x12 } }) } } Device (BPD0) { Name (_ADR, 0x00) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x13 } }) } } } Device (BPD1) { Name (_ADR, 0x00010000) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKA, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x13 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x10 } }) } } } Device (BPD2) { Name (_ADR, 0x00020000) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x02) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x02) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x13 } }) } } } } Device (BMF3) { Name (_ADR, 0x03) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x03) { Package (0x04) { 0x0003FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x03) { Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x1C }, Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x1E }, Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x1F } }) } } } } Device (P0P4) { Name (_ADR, 0x00040000) OperationRegion (PCE4, PCI_Config, 0x00, 0xFF) Field (PCE4, DWordAcc, NoLock, Preserve) { Offset (0x48), , 9, PGPE, 1, Offset (0x88), , 3, PMEI, 1, Offset (0x8E), PMES, 1 } Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x13 } }) } } } Device (P0P6) { Name (_ADR, 0x00060000) OperationRegion (PCE6, PCI_Config, 0x00, 0xFF) Field (PCE6, DWordAcc, NoLock, Preserve) { Offset (0x48), , 9, PGPE, 1, Offset (0x88), , 3, PMEI, 1, Offset (0x8E), PMES, 1 } Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKB, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x13 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x11 } }) } } } Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x14) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0004FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001CFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x001CFFFF, 0x01, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001CFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001CFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x001DFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x001DFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x001DFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001DFFFF, 0x03, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001EFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x001EFFFF, 0x01, \_SB.PCI0.LPC0.LNKE, 0x00 }, Package (0x04) { 0x001FFFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001FFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x14) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x13 }, Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0004FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0006FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0008FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x001CFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x001CFFFF, 0x01, 0x00, 0x10 }, Package (0x04) { 0x001CFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x001CFFFF, 0x03, 0x00, 0x13 }, Package (0x04) { 0x001DFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x001DFFFF, 0x01, 0x00, 0x13 }, Package (0x04) { 0x001DFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x001DFFFF, 0x03, 0x00, 0x10 }, Package (0x04) { 0x001EFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x001EFFFF, 0x01, 0x00, 0x14 }, Package (0x04) { 0x001FFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0x001FFFFF, 0x01, 0x00, 0x13 } }) } } Method (_S1D, 0, NotSerialized) { Return (0x01) } OperationRegion (DB80, SystemIO, 0x80, 0x01) Field (DB80, ByteAcc, NoLock, Preserve) { PT80, 8 } OperationRegion (DB90, SystemIO, 0x90, 0x01) Field (DB90, ByteAcc, NoLock, Preserve) { PT90, 8 } OperationRegion (REGS, SystemMemory, 0xE0080059, 0x08) Field (REGS, AnyAcc, NoLock, Preserve) { PAM0, 8, PAM1, 8, PAM2, 8, PAM3, 8, PAM4, 8, PAM5, 8, PAM6, 8 } OperationRegion (LMEM, SystemMemory, 0xE008106C, 0x02) Field (LMEM, AnyAcc, NoLock, Preserve) { TOLM, 16 } Device (PEX0) { Name (_ADR, 0x001C0000) Device (PXH0) { Name (_ADR, 0x00) Name (_PRW, Package (0x02) { 0x18, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0001FFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x0001FFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0001FFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0001FFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0x0001FFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x0001FFFF, 0x03, 0x00, 0x13 } }) } } } } Device (USB1) { Name (_ADR, 0x001D0000) OperationRegion (US1W, PCI_Config, 0xC4, 0x04) Field (US1W, DWordAcc, Lock, Preserve) { W1EN, 2 } Name (_PRW, Package (0x02) { 0x03, 0x05 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, W1EN) } Else { Store (0x00, W1EN) } } Method (_S1D, 0, NotSerialized) { Return (0x01) } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB2) { Name (_ADR, 0x001D0001) OperationRegion (US2W, PCI_Config, 0xC4, 0x04) Field (US2W, DWordAcc, Lock, Preserve) { W2EN, 2 } Name (_PRW, Package (0x02) { 0x04, 0x05 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, W2EN) } Else { Store (0x00, W2EN) } } Method (_S1D, 0, NotSerialized) { Return (0x01) } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB3) { Name (_ADR, 0x001D0002) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x0C, 0x05 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S1D, 0, NotSerialized) { Return (0x02) } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB4) { Name (_ADR, 0x001D0003) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x0E, 0x05 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S1D, 0, NotSerialized) { Return (0x02) } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (EUSB) { Name (_ADR, 0x001D0007) Name (_S1D, 0x02) Name (_S3D, 0x02) Name (_S4D, 0x02) Name (_PRW, Package (0x02) { 0x0D, 0x05 }) } Device (PCIB) { Name (_ADR, 0x001E0000) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x03) { Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 } }) } Else { Return (Package (0x03) { Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x11 } }) } } Name (_PRW, Package (0x02) { 0x0B, 0x05 }) } Device (LPC0) { Name (_ADR, 0x001F0000) Name (DVEN, 0x00) Method (DECD, 4, Serialized) { Noop } Device (MBRD) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x1F) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0010, 0x0010, 0x01, 0x10) IO (Decode16, 0x0024, 0x0024, 0x01, 0x02) IO (Decode16, 0x0028, 0x0028, 0x01, 0x02) IO (Decode16, 0x002C, 0x002C, 0x01, 0x02) IO (Decode16, 0x002E, 0x002E, 0x01, 0x02) IO (Decode16, 0x0030, 0x0030, 0x01, 0x02) IO (Decode16, 0x0034, 0x0034, 0x01, 0x02) IO (Decode16, 0x0038, 0x0038, 0x01, 0x02) IO (Decode16, 0x003C, 0x003C, 0x01, 0x02) IO (Decode16, 0x004E, 0x004E, 0x01, 0x02) IO (Decode16, 0x0050, 0x0050, 0x01, 0x04) IO (Decode16, 0x0063, 0x0063, 0x01, 0x01) IO (Decode16, 0x0065, 0x0065, 0x01, 0x01) IO (Decode16, 0x0067, 0x0067, 0x01, 0x01) IO (Decode16, 0x0072, 0x0072, 0x01, 0x06) IO (Decode16, 0x0080, 0x0080, 0x01, 0x01) IO (Decode16, 0x0090, 0x0090, 0x01, 0x10) IO (Decode16, 0x00A4, 0x00A4, 0x01, 0x02) IO (Decode16, 0x00A8, 0x00A8, 0x01, 0x02) IO (Decode16, 0x00AC, 0x00AC, 0x01, 0x02) IO (Decode16, 0x00B0, 0x00B0, 0x01, 0x06) IO (Decode16, 0x00B8, 0x00B8, 0x01, 0x02) IO (Decode16, 0x00BC, 0x00BC, 0x01, 0x02) IO (Decode16, 0x04D0, 0x04D0, 0x01, 0x02) IO (Decode16, 0x0295, 0x0295, 0x01, 0x02) IO (Decode16, 0x0CA2, 0x0CA2, 0x01, 0x02) IO (Decode16, 0x0CA8, 0x0CA8, 0x01, 0x08) IO (Decode16, 0x1000, 0x1000, 0x01, 0x80) IO (Decode16, 0x1180, 0x1180, 0x01, 0x40) IO (Decode16, 0x0800, 0x0800, 0x01, 0x10) IO (Decode16, 0xFE00, 0xFE00, 0x01, 0x01) Memory32Fixed (ReadWrite, 0xE0000000, 0x10000000) Memory32Fixed (ReadWrite, 0xFEE00000, 0x00010000) Memory32Fixed (ReadWrite, 0xFEC80000, 0x00001000) Memory32Fixed (ReadWrite, 0xFED1C000, 0x00004000) Memory32Fixed (ReadWrite, 0xFE000000, 0x00020000) Memory32Fixed (ReadWrite, 0xFE600000, 0x00100000) }) Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0xDA, PMMN) CreateWordField (RSRC, 0xDC, PMMX) And (^^PMBA, 0xFF80, PMMN) Store (PMMN, PMMX) CreateWordField (RSRC, 0xE2, GPMN) CreateWordField (RSRC, 0xE4, GPMX) And (^^GPBA, 0xFFC0, GPMN) Store (GPMN, GPMX) Return (RSRC) } } Device (DMAC) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x20) IO (Decode16, 0x0081, 0x0081, 0x01, 0x11) IO (Decode16, 0x0093, 0x0093, 0x01, 0x0D) IO (Decode16, 0x00C0, 0x00C0, 0x01, 0x20) DMA (Compatibility, NotBusMaster, Transfer8_16) {4} }) } Device (MATH) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, 0x00F0, 0x01, 0x0F) IRQ (Edge, ActiveHigh, Exclusive) {13} }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, 0x0020, 0x01, 0x02) IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02) IRQ (Edge, ActiveHigh, Exclusive) {2} }) } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400) }) Method (_STA, 0, NotSerialized) { If (LNot (LLess (\_SB.OSTB, 0x08))) { If (HPAE) { Return (0x0F) } } Else { If (HPAE) { Return (0x0B) } } Return (0x00) } Method (_CRS, 0, Serialized) { If (HPAE) { CreateDWordField (BUF0, 0x0A, HPT0) If (LEqual (HPAS, 0x01)) { Store (0xFED01000, HPT0) } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) } } Return (BUF0) } } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x02) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x02) IRQ (Edge, ActiveHigh, Exclusive) {8} }) Method (_CRS, 0, Serialized) { If (LNot (LLess (\_SB.OSTB, 0x08))) { If (HPAE) { Return (BUF0) } } Return (BUF1) } } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, 0x0061, 0x01, 0x01) }) } Device (TIME) { Name (_HID, EisaId ("PNP0100")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x01, 0x04) IO (Decode16, 0x0050, 0x0050, 0x10, 0x04) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x01, 0x04) IO (Decode16, 0x0050, 0x0050, 0x10, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {0} }) Method (_CRS, 0, Serialized) { If (LNot (LLess (\_SB.OSTB, 0x08))) { If (HPAE) { Return (BUF0) } } Return (BUF1) } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRA, 0x80, PIRA) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRA, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRA, 0x70), PIRA) } Method (_STA, 0, NotSerialized) { If (And (PIRA, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRB, 0x80, PIRB) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRB, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRB, 0x70), PIRB) } Method (_STA, 0, NotSerialized) { If (And (PIRB, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRC, 0x80, PIRC) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRC, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRC, 0x70), PIRC) } Method (_STA, 0, NotSerialized) { If (And (PIRC, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRD, 0x80, PIRD) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRD, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRD, 0x70), PIRD) } Method (_STA, 0, NotSerialized) { If (And (PIRD, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRE, 0x80, PIRE) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRE, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRE, 0x70), PIRE) } Method (_STA, 0, NotSerialized) { If (And (PIRE, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRF, 0x80, PIRF) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRF, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRF, 0x70), PIRF) } Method (_STA, 0, NotSerialized) { If (And (PIRF, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRG, 0x80, PIRG) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRG, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRG, 0x70), PIRG) } Method (_STA, 0, NotSerialized) { If (And (PIRG, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {4,5,6,7,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRH, 0x80, PIRH) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRH, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRH, 0x70), PIRH) } Method (_STA, 0, NotSerialized) { If (And (PIRH, 0x80)) { Return (0x09) } Return (0x0B) } } OperationRegion (PIRX, PCI_Config, 0x60, 0x04) Field (PIRX, DWordAcc, Lock, Preserve) { AccessAs (ByteAcc, 0x00), PIRA, 8, PIRB, 8, PIRC, 8, PIRD, 8 } OperationRegion (PIRY, PCI_Config, 0x68, 0x04) Field (PIRY, DWordAcc, Lock, Preserve) { AccessAs (ByteAcc, 0x00), PIRE, 8, PIRF, 8, PIRG, 8, PIRH, 8 } OperationRegion (REGS, PCI_Config, 0x40, 0x10) Field (REGS, DWordAcc, Lock, Preserve) { PMBA, 16, Offset (0x08), GPBA, 16 } OperationRegion (PMRG, PCI_Config, 0xA0, 0x04) Field (PMRG, DWordAcc, Lock, Preserve) { , 10, BPEE, 1 } OperationRegion (LIOE, PCI_Config, 0x80, 0x02) Field (LIOE, WordAcc, Lock, Preserve) { CAPD, 3, , 1, CBPD, 3, Offset (0x01), LPPD, 2 } Method (IODE, 2, NotSerialized) { If (LEqual (Arg0, 0x00)) { If (LEqual (Arg1, 0x03F8)) { Store (0x00, CAPD) } If (LEqual (Arg1, 0x02F8)) { Store (0x01, CAPD) } If (LEqual (Arg1, 0x03E8)) { Store (0x07, CAPD) } If (LEqual (Arg1, 0x02E8)) { Store (0x05, CAPD) } } If (LEqual (Arg0, 0x01)) { If (LEqual (Arg1, 0x03F8)) { Store (0x00, CBPD) } If (LEqual (Arg1, 0x02F8)) { Store (0x01, CBPD) } If (LEqual (Arg1, 0x03E8)) { Store (0x07, CBPD) } If (LEqual (Arg1, 0x02E8)) { Store (0x05, CBPD) } } If (LEqual (Arg0, 0x02)) { If (LEqual (Arg1, 0x0378)) { Store (0x00, LPPD) } If (LEqual (Arg1, 0x0278)) { Store (0x01, LPPD) } If (LEqual (Arg1, 0x03BC)) { Store (0x02, LPPD) } } } Device (FWHD) { Name (_HID, EisaId ("INT0800")) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFF000000, 0x01000000) }) } Device (SIO) { Name (_HID, EisaId ("PNP0A05")) Mutex (W627, 0x00) OperationRegion (SIBP, SystemIO, 0x2E, 0x02) Field (SIBP, ByteAcc, NoLock, Preserve) { BPIO, 8 } OperationRegion (SIIO, SystemIO, 0x2E, 0x02) Field (SIIO, ByteAcc, NoLock, Preserve) { INDX, 8, DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x07), LDN, 8, Offset (0x22), POW, 8, Offset (0x30), ACT, 1, Offset (0x60), IOBH, 8, IOBL, 8, IO2H, 8, IO2L, 8, Offset (0x70), INT, 4, Offset (0x74), DMAS, 3, Offset (0xE0), Z000, 8, Offset (0xE4), Z001, 8, Offset (0xF0), MODE, 3, Offset (0xF1), , 3, IRMD, 3, Offset (0xF3), , 6, SLED, 2, Offset (0xF5), , 6, PLED, 2 } Method (CFG, 1, NotSerialized) { Store (0x87, BPIO) Store (0x87, BPIO) Store (Arg0, LDN) } Method (XCFG, 0, NotSerialized) { Store (0xAA, BPIO) } Method (STA, 1, NotSerialized) { Acquire (W627, 0x5000) CFG (Arg0) Store (0x00, Local1) If (ACT) { Store (0x0F, Local1) } Else { If (LOr (IOBH, IOBL)) { Store (0x0D, Local1) } } XCFG () Release (W627) Return (Local1) } Method (DIS, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x00, ACT) XCFG () Release (W627) Return (0x00) } Method (PS0, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x01, ACT) XCFG () Release (W627) Return (0x00) } Method (PS3, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x00, ACT) XCFG () Release (W627) Return (0x00) } Device (KBC0) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x01, 0x01) IO (Decode16, 0x0064, 0x0064, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {1} }) Name (_PRW, Package (0x02) { 0x1E, 0x05 }) } Device (MSE0) { Name (_HID, EisaId ("PNP0F13")) Name (_CID, 0x130FD041) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IRQ (Edge, ActiveHigh, Exclusive) {12} }) Name (_PRW, Package (0x02) { 0x1E, 0x05 }) } Device (COM1) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Store (STA (0x02), Local1) Return (Local1) } Name (_PRW, Package (0x02) { 0x08, 0x05 }) Method (_DIS, 0, NotSerialized) { DIS (0x02) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) IRQNoFlags () {} }) CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateWordField (RSRC, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x02) If (ACT) { Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x02) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) Store (0x01, ACT) XCFG () Release (W627) CreateWordField (Arg0, 0x02, IORG) \_SB.PCI0.LPC0.IODE (0x00, IORG) } Method (_PS0, 0, NotSerialized) { PS0 (0x02) } Method (_PS3, 0, NotSerialized) { PS3 (0x02) } } Device (COM2) { Method (_HID, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x03) If (LAnd (IRMD, 0x38)) { Store (0x1005D041, Local1) } Else { Store (0x0105D041, Local1) } XCFG () Release (W627) Return (Local1) } Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Store (STA (0x03), Local1) Return (Local1) } Name (_PRW, Package (0x02) { 0x08, 0x05 }) Method (_DIS, 0, NotSerialized) { DIS (0x03) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) IRQNoFlags () {} }) CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateWordField (RSRC, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x03) If (ACT) { Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x00, 0x00) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x03) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) Store (0x01, ACT) XCFG () Release (W627) CreateWordField (Arg0, 0x02, IORG) \_SB.PCI0.LPC0.IODE (0x01, IORG) } Method (_PS0, 0, NotSerialized) { PS0 (0x03) } Method (_PS3, 0, NotSerialized) { PS3 (0x03) } } Device (FDC) { Name (_HID, EisaId ("PNP0700")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Store (STA (0x00), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x00) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x06) IO (Decode16, 0x0000, 0x0000, 0x01, 0x01) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer8) {} }) Acquire (W627, 0x1388) CFG (0x00) If (ACT) { CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateByteField (RSRC, 0x0A, IO5) CreateByteField (RSRC, 0x0B, IO6) CreateByteField (RSRC, 0x0C, IO7) CreateByteField (RSRC, 0x0D, IO8) CreateWordField (RSRC, 0x11, IRQV) CreateByteField (RSRC, 0x14, DMAV) Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Add (IOBL, 0x07, IO5) Store (IOBH, IO6) Add (IOBL, 0x07, IO7) Store (IOBH, IO8) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) Store (0x01, Local0) ShiftLeft (Local0, DMAS, DMAV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0370, 0x0370, 0x01, 0x06) IO (Decode16, 0x0377, 0x0377, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x11, IRQV) CreateByteField (Arg0, 0x14, DMAV) Acquire (W627, 0x1388) CFG (0x00) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) FindSetRightBit (DMAV, Local0) Subtract (Local0, 0x01, DMAS) Store (0x01, ACT) XCFG () Release (W627) } Method (_PS0, 0, NotSerialized) { PS0 (0x00) } Method (_PS3, 0, NotSerialized) { PS3 (0x00) } } Device (PRT) { Method (_HID, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { Store (0x0104D041, Local1) } Else { Store (0x0004D041, Local1) } XCFG () Release (W627) Return (Local1) } Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Store (STA (0x01), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x01) } Method (_CRS, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) Name (CRSA, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IRQNoFlags () {} }) CreateByteField (CRSA, 0x02, IOA1) CreateByteField (CRSA, 0x03, IOA2) CreateByteField (CRSA, 0x04, IOA3) CreateByteField (CRSA, 0x05, IOA4) CreateByteField (CRSA, 0x06, ALA1) CreateByteField (CRSA, 0x07, LNA1) CreateWordField (CRSA, 0x09, IRQA) Name (CRSB, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer16) {} }) CreateByteField (CRSB, 0x02, IOB1) CreateByteField (CRSB, 0x03, IOB2) CreateByteField (CRSB, 0x04, IOB3) CreateByteField (CRSB, 0x05, IOB4) CreateByteField (CRSB, 0x06, ALB1) CreateByteField (CRSB, 0x07, LNB1) CreateByteField (CRSB, 0x0A, IOB5) CreateByteField (CRSB, 0x0B, IOB6) CreateByteField (CRSB, 0x0C, IOB7) CreateByteField (CRSB, 0x0D, IOB8) CreateByteField (CRSB, 0x0E, ALB2) CreateByteField (CRSB, 0x0F, LNB2) CreateWordField (CRSB, 0x11, IRQB) CreateWordField (CRSB, 0x14, DMAV) If (ACT) { If (LEqual (MODE, 0x02)) { Store (IOBL, IOB1) Store (IOBH, IOB2) Store (IOBL, IOB3) Store (IOBH, IOB4) Store (IOBL, IOB5) Add (IOBH, 0x04, IOB6) Store (IOBL, IOB7) Add (IOBH, 0x04, IOB8) If (LEqual (IOBL, 0xBC)) { Store (0x01, ALB1) Store (0x04, LNB1) Store (0x01, ALB2) Store (0x04, LNB2) } Store (0x01, Local0) ShiftLeft (Local0, INT, IRQB) Store (0x01, Local0) ShiftLeft (Local0, DMAS, DMAV) Return (CRSB) } Else { Store (IOBL, IOA1) Store (IOBH, IOA2) Store (IOBL, IOA3) Store (IOBH, IOA4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQA) If (LEqual (IOBL, 0xBC)) { Store (0x01, ALA1) Store (0x04, LNA1) } Return (CRSA) } } Else { If (LEqual (MODE, 0x02)) { Return (CRSB) } Else { Return (CRSA) } } XCFG () Release (W627) } Name (PRSA, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {5} } EndDependentFn () }) Name (PRSB, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } EndDependentFn () }) Method (_PRS, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { Store (PRSB, Local0) } Else { Store (PRSA, Local0) } XCFG () Release (W627) Return (Local0) } Method (_SRS, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { CreateByteField (Arg0, 0x02, IOB1) CreateByteField (Arg0, 0x03, IOB2) CreateByteField (Arg0, 0x04, IOB3) CreateByteField (Arg0, 0x05, IOB4) CreateByteField (Arg0, 0x06, ALB1) CreateByteField (Arg0, 0x07, LNB1) CreateByteField (Arg0, 0x0A, IOB5) CreateByteField (Arg0, 0x0B, IOB6) CreateByteField (Arg0, 0x0C, IOB7) CreateByteField (Arg0, 0x0D, IOB8) CreateByteField (Arg0, 0x0E, ALB2) CreateByteField (Arg0, 0x0F, LNB2) CreateWordField (Arg0, 0x11, IRQB) CreateWordField (Arg0, 0x14, DMAV) Store (IOB1, IOBL) Store (IOB2, IOBH) FindSetLeftBit (IRQB, Local0) Subtract (Local0, 0x01, INT) FindSetLeftBit (DMAV, Local0) Subtract (Local0, 0x01, DMAS) } Else { CreateByteField (Arg0, 0x02, IOA1) CreateByteField (Arg0, 0x03, IOA2) CreateByteField (Arg0, 0x04, IOA3) CreateByteField (Arg0, 0x05, IOA4) CreateByteField (Arg0, 0x06, ALA1) CreateByteField (Arg0, 0x07, LNA1) CreateWordField (Arg0, 0x09, IRQA) Store (IOA1, IOBL) Store (IOA2, IOBH) FindSetLeftBit (IRQA, Local0) Subtract (Local0, 0x01, INT) } Store (0x01, ACT) XCFG () Release (W627) CreateWordField (Arg0, 0x02, IORG) \_SB.PCI0.LPC0.IODE (0x02, IORG) } Method (_PS0, 0, NotSerialized) { PS0 (0x01) } Method (_PS3, 0, NotSerialized) { PS3 (0x01) } } Method (ENWK, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x0A) Store (0x01, ACT) Store (0xF3, INDX) Store (0x3F, DATA) Store (0xF6, INDX) Store (0x33, DATA) Store (0xF9, INDX) Store (0x05, DATA) XCFG () Release (W627) } Method (DSWK, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x0A) Store (0x00, ACT) Store (0xF6, INDX) Store (0x00, DATA) Store (0xF9, INDX) Store (0x00, DATA) Store (0xF3, INDX) Store (0x3F, DATA) XCFG () Release (W627) } Method (CLED, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (0x09) Store (Arg0, SLED) XCFG () Release (W627) } } } Name (NATA, Package (0x01) { 0x001F0001 }) Device (IDEC) { Name (_ADR, 0x001F0001) OperationRegion (IDEC, PCI_Config, 0x40, 0x18) Field (IDEC, DWordAcc, NoLock, Preserve) { PRIT, 16, SECT, 16, PSIT, 4, SSIT, 4, Offset (0x08), SDMA, 4, Offset (0x0A), SDT0, 2, , 2, SDT1, 2, Offset (0x0B), SDT2, 2, , 2, SDT3, 2, Offset (0x14), ICR0, 4, ICR1, 4, ICR2, 4, ICR3, 4, ICR4, 4, ICR5, 4 } Method (GETP, 1, NotSerialized) { Noop If (LEqual (And (Arg0, 0x09), 0x00)) { Return (0xFFFFFFFF) } If (LEqual (And (Arg0, 0x09), 0x08)) { Return (0x0384) } ShiftRight (And (Arg0, 0x0300), 0x08, Local0) ShiftRight (And (Arg0, 0x3000), 0x0C, Local1) Return (Multiply (0x1E, Subtract (0x09, Add (Local0, Local1)))) } Method (GETD, 4, NotSerialized) { Noop If (Arg0) { If (Arg1) { Return (0x14) } If (Arg2) { Return (Multiply (Subtract (0x04, Arg3), 0x0F)) } Return (Multiply (Subtract (0x04, Arg3), 0x1E)) } Return (0xFFFFFFFF) } Method (GETT, 1, NotSerialized) { Noop Return (Multiply (0x1E, Subtract (0x09, Add (And (ShiftRight (Arg0, 0x02), 0x03), And (Arg0, 0x03))))) } Method (GETF, 3, NotSerialized) { Noop Name (TMPF, 0x00) If (Arg0) { Or (TMPF, 0x01, TMPF) } If (And (Arg2, 0x02)) { Or (TMPF, 0x02, TMPF) } If (Arg1) { Or (TMPF, 0x04, TMPF) } If (And (Arg2, 0x20)) { Or (TMPF, 0x08, TMPF) } If (And (Arg2, 0x4000)) { Or (TMPF, 0x10, TMPF) } Return (TMPF) } Method (SETP, 3, NotSerialized) { Noop If (LNot (LLess (Arg0, 0xF0))) { Return (0x08) } Else { If (And (Arg1, 0x02)) { If (LAnd (LNot (LGreater (Arg0, 0x78)), And (Arg2, 0x02))) { Return (0x2301) } If (LAnd (LNot (LGreater (Arg0, 0xB4)), And (Arg2, 0x01))) { Return (0x2101) } } Return (0x1001) } } Method (SETD, 1, NotSerialized) { Noop If (LNot (LGreater (Arg0, 0x14))) { Return (0x01) } If (LNot (LGreater (Arg0, 0x1E))) { Return (0x02) } If (LNot (LGreater (Arg0, 0x2D))) { Return (0x01) } If (LNot (LGreater (Arg0, 0x3C))) { Return (0x02) } If (LNot (LGreater (Arg0, 0x5A))) { Return (0x01) } Return (0x00) } Method (SETT, 3, NotSerialized) { Noop If (And (Arg1, 0x02)) { If (LAnd (LNot (LGreater (Arg0, 0x78)), And (Arg2, 0x02))) { Return (0x0B) } If (LAnd (LNot (LGreater (Arg0, 0xB4)), And (Arg2, 0x01))) { Return (0x09) } } Return (0x04) } Device (PRID) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Noop Name (PBUF, Buffer (0x14) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (PBUF, 0x00, PIO0) CreateDWordField (PBUF, 0x04, DMA0) CreateDWordField (PBUF, 0x08, PIO1) CreateDWordField (PBUF, 0x0C, DMA1) CreateDWordField (PBUF, 0x10, FLAG) Store (GETP (PRIT), PIO0) Store (GETD (And (SDMA, 0x01), And (ICR3, 0x01), And (ICR0, 0x01), SDT0), DMA0) If (LEqual (DMA0, 0xFFFFFFFF)) { Store (PIO0, DMA0) } If (And (PRIT, 0x4000)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x0384, PIO1) } Else { Store (GETT (PSIT), PIO1) } } Else { Store (0xFFFFFFFF, PIO1) } Store (GETD (And (SDMA, 0x02), And (ICR3, 0x02), And (ICR0, 0x02), SDT1), DMA1) If (LEqual (DMA1, 0xFFFFFFFF)) { Store (PIO1, DMA1) } Store (GETF (And (SDMA, 0x01), And (SDMA, 0x02), PRIT), FLAG) Return (PBUF) } Method (_STM, 3, NotSerialized) { Noop CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x04, ICR2) If (LEqual (SizeOf (Arg1), 0x0200)) { And (PRIT, 0x4CF0, PRIT) And (SDMA, 0x0E, SDMA) Store (0x00, SDT0) And (ICR0, 0x0E, ICR0) And (ICR1, 0x0E, ICR1) And (ICR3, 0x0E, ICR3) And (ICR5, 0x0E, ICR5) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Or (PRIT, 0x8004, PRIT) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Or (PRIT, 0x02, PRIT) } Or (PRIT, SETP (PIO0, W530, W640), PRIT) If (And (FLAG, 0x01)) { Or (SDMA, 0x01, SDMA) Store (SETD (DMA0), SDT0) If (And (W880, 0x20)) { Or (ICR1, 0x01, ICR1) Or (ICR5, 0x01, ICR5) } If (And (W880, 0x10)) { Or (ICR1, 0x01, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x01, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x01, ICR0) } } } If (LEqual (SizeOf (Arg2), 0x0200)) { And (PRIT, 0x3F0F, PRIT) Store (0x00, PSIT) And (SDMA, 0x0D, SDMA) Store (0x00, SDT1) And (ICR0, 0x0D, ICR0) And (ICR1, 0x0D, ICR1) And (ICR3, 0x0D, ICR3) And (ICR5, 0x0D, ICR5) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Or (PRIT, 0x8040, PRIT) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Or (PRIT, 0x20, PRIT) } If (And (FLAG, 0x10)) { Or (PRIT, 0x4000, PRIT) If (LGreater (PIO1, 0xF0)) { Or (PRIT, 0x80, PRIT) } Else { Or (PRIT, 0x10, PRIT) Store (SETT (PIO1, W531, W641), PSIT) } } If (And (FLAG, 0x04)) { Or (SDMA, 0x02, SDMA) Store (SETD (DMA1), SDT1) If (And (W881, 0x20)) { Or (ICR1, 0x02, ICR1) Or (ICR5, 0x02, ICR5) } If (And (W881, 0x10)) { Or (ICR1, 0x02, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x02, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x02, ICR0) } } } } Method (_PS0, 0, NotSerialized) { Noop } Method (_PS3, 0, NotSerialized) { Noop } Device (P_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Noop Name (PIB0, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }) CreateByteField (PIB0, 0x01, PMD0) CreateByteField (PIB0, 0x08, DMD0) If (And (PRIT, 0x02)) { If (LEqual (And (PRIT, 0x09), 0x08)) { Store (0x08, PMD0) } Else { Store (0x0A, PMD0) ShiftRight (And (PRIT, 0x0300), 0x08, Local0) ShiftRight (And (PRIT, 0x3000), 0x0C, Local1) Add (Local0, Local1, Local2) If (LEqual (0x03, Local2)) { Store (0x0B, PMD0) } If (LEqual (0x05, Local2)) { Store (0x0C, PMD0) } } } Else { Store (0x01, PMD0) } If (And (SDMA, 0x01)) { Store (Or (SDT0, 0x40), DMD0) If (And (ICR0, 0x01)) { Add (DMD0, 0x02, DMD0) } If (And (ICR3, 0x01)) { Store (0x45, DMD0) } } Else { Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0) } Return (PIB0) } } Device (P_D1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Noop Name (PIB1, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }) CreateByteField (PIB1, 0x01, PMD1) CreateByteField (PIB1, 0x08, DMD1) If (And (PRIT, 0x20)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x08, PMD1) } Else { Add (And (PSIT, 0x03), ShiftRight (And (PSIT, 0x0C), 0x02), Local0) If (LEqual (0x05, Local0)) { Store (0x0C, PMD1) } Else { If (LEqual (0x03, Local0)) { Store (0x0B, PMD1) } Else { Store (0x0A, PMD1) } } } } Else { Store (0x01, PMD1) } If (And (SDMA, 0x02)) { Store (Or (SDT1, 0x40), DMD1) If (And (ICR0, 0x02)) { Add (DMD1, 0x02, DMD1) } If (And (ICR3, 0x02)) { Store (0x45, DMD1) } } Else { Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1) } Return (PIB1) } } } } Device (SMBS) { Name (_ADR, 0x001F0003) } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) } } } Scope (_SI) { Method (_SST, 1, NotSerialized) { } } Scope (_TZ) { } Name (_S0, Package (0x02) { 0x00, 0x00 }) Name (_S1, Package (0x02) { 0x01, 0x01 }) Name (_S4, Package (0x02) { 0x06, 0x06 }) Name (_S5, Package (0x02) { 0x07, 0x07 }) Name (PICF, 0x00) Method (_PIC, 1, NotSerialized) { Store (Arg0, \PICF) } Method (_PTS, 1, NotSerialized) { Store (Arg0, \_SB.PCI0.PT80) Store (0x01, \_SB.PCI0.P0P2.PMES) Store (0x01, \_SB.PCI0.P0P2.PMES) Store (0x01, \_SB.PCI0.P0P4.PMES) Store (0x01, \_SB.PCI0.P0P4.PMES) Store (0x01, \_SB.PCI0.P0P6.PMES) Store (0x01, \_SB.PCI0.P0P6.PMES) If (LEqual (Arg0, 0x01)) { Store (0x01, \_SB.PCI0.P0P2.PMEI) Store (0x01, \_SB.PCI0.P0P2.PGPE) Store (0x01, \_SB.PCI0.P0P4.PMEI) Store (0x01, \_SB.PCI0.P0P4.PGPE) Store (0x01, \_SB.PCI0.P0P6.PMEI) Store (0x01, \_SB.PCI0.P0P6.PGPE) Store (0x01, \_SB.PCI0.LPC0.BPEE) \_SB.PCI0.LPC0.SIO.ENWK () \_SB.PCI0.LPC0.SIO.CLED (0x02) } If (LNot (LLess (Arg0, 0x04))) { \_SB.PCI0.LPC0.SIO.CLED (0x00) } } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, \_SB.PCI0.PT80) \_SB.PCI0.LPC0.SIO.CLED (0x01) Notify (\_SB.PCI0.PWRB, 0x02) If (LEqual (Arg0, 0x01)) { Store (0x00, \_SB.PCI0.P0P2.PMEI) Store (0x00, \_SB.PCI0.P0P2.PGPE) Store (0x00, \_SB.PCI0.P0P4.PMEI) Store (0x00, \_SB.PCI0.P0P4.PGPE) Store (0x00, \_SB.PCI0.P0P6.PMEI) Store (0x00, \_SB.PCI0.P0P6.PGPE) Store (0x00, \_SB.PCI0.LPC0.BPEE) \_SB.PCI0.LPC0.SIO.ENWK () } \_SB.PCI0.LPC0.SIO.DSWK () Return (Package (0x02) { 0x00, 0x00 }) } Scope (\) { Name (SSDT, Package (0x30) { "CPU0IST ", 0x00000000, 0xF000FF53, "CPU1IST ", 0x00000000, 0xF000FF53, "CPU0CST ", 0x00000000, 0xF000FF53, "CPU1CST ", 0x00000000, 0xF000FF53, "CPU2IST ", 0x00000000, 0xF000FF53, "CPU3IST ", 0x00000000, 0xF000FF53, "CPU2CST ", 0x00000000, 0xF000FF53, "CPU3CST ", 0x00000000, 0xF000FF53, "CPU4IST ", 0x00000000, 0xF000FF53, "CPU5IST ", 0x00000000, 0xF000FF53, "CPU4CST ", 0x00000000, 0xF000FF53, "CPU5CST ", 0x00000000, 0xF000FF53, "CPU6IST ", 0x00000000, 0xF000FF53, "CPU7IST ", 0x00000000, 0xF000FF53, "CPU6CST ", 0x00000000, 0xF000FF53, "CPU7CST ", 0x00000000, 0xF000FF53 }) Name (CFGD, 0x09010000) Name (\PDC0, 0x80000000) Name (\PDC1, 0x80000000) Name (\PDC2, 0x80000000) Name (\PDC3, 0x80000000) Name (\PDC4, 0x80000000) Name (\PDC5, 0x80000000) Name (\PDC6, 0x80000000) Name (\PDC7, 0x80000000) Name (\SDTL, 0x00) } Scope (\_PR.CPU0) { Name (HI0, 0x00) Name (HC0, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS0, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS0) CreateDWordField (Arg3, 0x04, CAP0) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, 0x00, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS0, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS0, 0x00)) Return (Arg3) } Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC0, 0x09), 0x09)), LNot (And (SDTL, 0x01)))) { Or (SDTL, 0x01, SDTL) OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02))) Load (IST0, HI0) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18)), LNot (And (SDTL, 0x02)))) { Or (SDTL, 0x02, SDTL) OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08))) Load (CST0, HC0) } } Return (Arg3) } } Scope (\_PR.CPU1) { Name (HI1, 0x00) Name (HC1, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS1, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS1, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS1) CreateDWordField (Arg3, 0x04, CAP1) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS1, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS1, 0x00)) Return (Arg3) } Or (And (PDC1, 0x7FFFFFFF), CAP1, PDC1) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC1, 0x09), 0x09)), LNot (And (SDTL, 0x10)))) { Or (SDTL, 0x10, SDTL) OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05))) Load (IST1, HI1) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC1, 0x18)), LNot (And (SDTL, 0x20)))) { Or (SDTL, 0x20, SDTL) OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B))) Load (CST1, HC1) } } Return (Arg3) } } Scope (\_PR.CPU2) { Name (HI2, 0x00) Name (HC2, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS2, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS2, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS2) CreateDWordField (Arg3, 0x04, CAP2) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS2, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS2, 0x00)) Return (Arg3) } Or (And (PDC2, 0x7FFFFFFF), CAP2, PDC2) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC2, 0x09), 0x09)), LNot (And (SDTL, 0x04)))) { Or (SDTL, 0x04, SDTL) OperationRegion (IST2, SystemMemory, DerefOf (Index (SSDT, 0x0D)), DerefOf (Index (SSDT, 0x0E))) Load (IST2, HI2) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC2, 0x18)), LNot (And (SDTL, 0x08)))) { Or (SDTL, 0x08, SDTL) OperationRegion (CST2, SystemMemory, DerefOf (Index (SSDT, 0x13)), DerefOf (Index (SSDT, 0x14))) Load (CST2, HC2) } } Return (Arg3) } } Scope (\_PR.CPU3) { Name (HI3, 0x00) Name (HC3, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS3, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS3, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS3) CreateDWordField (Arg3, 0x04, CAP3) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS3, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS3, 0x00)) Return (Arg3) } Or (And (PDC3, 0x7FFFFFFF), CAP3, PDC3) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC3, 0x09), 0x09)), LNot (And (SDTL, 0x40)))) { Or (SDTL, 0x40, SDTL) OperationRegion (IST3, SystemMemory, DerefOf (Index (SSDT, 0x10)), DerefOf (Index (SSDT, 0x11))) Load (IST3, HI3) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC3, 0x18)), LNot (And (SDTL, 0x80)))) { Or (SDTL, 0x80, SDTL) OperationRegion (CST3, SystemMemory, DerefOf (Index (SSDT, 0x16)), DerefOf (Index (SSDT, 0x17))) Load (CST3, HC3) } } Return (Arg3) } } Scope (\_PR.CPU4) { Name (HI4, 0x00) Name (HC4, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS4, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS4, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS4) CreateDWordField (Arg3, 0x04, CAP4) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS4, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS4, 0x00)) Return (Arg3) } Or (And (PDC4, 0x7FFFFFFF), CAP4, PDC4) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC4, 0x09), 0x09)), LNot (And (SDTL, 0x0100)))) { Or (SDTL, 0x0100, SDTL) OperationRegion (IST4, SystemMemory, DerefOf (Index (SSDT, 0x19)), DerefOf (Index (SSDT, 0x1A))) Load (IST4, HI4) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC4, 0x18)), LNot (And (SDTL, 0x0200)))) { Or (SDTL, 0x0200, SDTL) OperationRegion (CST4, SystemMemory, DerefOf (Index (SSDT, 0x1F)), DerefOf (Index (SSDT, 0x20))) Load (CST4, HC4) } } Return (Arg3) } } Scope (\_PR.CPU5) { Name (HI5, 0x00) Name (HC5, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS5, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS5, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS5) CreateDWordField (Arg3, 0x04, CAP5) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS5, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS5, 0x00)) Return (Arg3) } Or (And (PDC5, 0x7FFFFFFF), CAP5, PDC5) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC5, 0x09), 0x09)), LNot (And (SDTL, 0x0400)))) { Or (SDTL, 0x0400, SDTL) OperationRegion (IST5, SystemMemory, DerefOf (Index (SSDT, 0x1C)), DerefOf (Index (SSDT, 0x1D))) Load (IST5, HI5) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC5, 0x18)), LNot (And (SDTL, 0x0800)))) { Or (SDTL, 0x0800, SDTL) OperationRegion (CST5, SystemMemory, DerefOf (Index (SSDT, 0x22)), DerefOf (Index (SSDT, 0x23))) Load (CST5, HC5) } } Return (Arg3) } } Scope (\_PR.CPU6) { Name (HI6, 0x00) Name (HC6, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS6, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS6, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS6) CreateDWordField (Arg3, 0x04, CAP6) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS6, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS6, 0x00)) Return (Arg3) } Or (And (PDC6, 0x7FFFFFFF), CAP6, PDC6) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC6, 0x09), 0x09)), LNot (And (SDTL, 0x1000)))) { Or (SDTL, 0x1000, SDTL) OperationRegion (IST6, SystemMemory, DerefOf (Index (SSDT, 0x25)), DerefOf (Index (SSDT, 0x26))) Load (IST6, HI6) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC6, 0x18)), LNot (And (SDTL, 0x2000)))) { Or (SDTL, 0x2000, SDTL) OperationRegion (CST6, SystemMemory, DerefOf (Index (SSDT, 0x2B)), DerefOf (Index (SSDT, 0x2C))) Load (CST6, HC6) } } Return (Arg3) } } Scope (\_PR.CPU7) { Name (HI7, 0x00) Name (HC7, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS7, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS7, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS7) CreateDWordField (Arg3, 0x04, CAP7) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS7, 0x00)) Return (Arg3) } If (LNot (LEqual (Arg1, 0x01))) { Store (0x0A, Index (STS7, 0x00)) Return (Arg3) } Or (And (PDC7, 0x7FFFFFFF), CAP7, PDC7) If (And (CFGD, 0x01)) { If (LAnd (LAnd (Or (Or (And (CFGD, 0x08000000), And (CFGD, 0x04000000)), Or (And (CFGD, 0x01000000), And (CFGD, 0x02000000))), LEqual (And (PDC7, 0x09), 0x09)), LNot (And (SDTL, 0x4000)))) { Or (SDTL, 0x4000, SDTL) OperationRegion (IST7, SystemMemory, DerefOf (Index (SSDT, 0x28)), DerefOf (Index (SSDT, 0x29))) Load (IST7, HI7) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC7, 0x18)), LNot (And (SDTL, 0x8000)))) { Or (SDTL, 0x8000, SDTL) OperationRegion (CST7, SystemMemory, DerefOf (Index (SSDT, 0x2E)), DerefOf (Index (SSDT, 0x2F))) Load (CST7, HC7) } } Return (Arg3) } } } From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 17:37:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EB3F16A40B for ; Tue, 23 Jan 2007 17:37:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 3C37213C4EA for ; Tue, 23 Jan 2007 17:37:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1198203uge for ; Tue, 23 Jan 2007 09:37:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aVKXZe+xAKVYkKnJhoQ41YfhyJfVBSp5ktcqrqyzQDJqjTSyVLK9qS8vYYmNzoQTFxsXCkqTw3N56Vw7EUwR5Lzd9BpS5bL34kv/o+GcURAzxNzTqrOJCfmOXdxg4Fdg3negot4bNp1l6lXKx95ztjVE44fPQOxaeMLWPL3yJeU= Received: by 10.82.184.2 with SMTP id h2mr7973391buf.1169573856607; Tue, 23 Jan 2007 09:37:36 -0800 (PST) Received: by 10.82.127.12 with HTTP; Tue, 23 Jan 2007 09:37:36 -0800 (PST) Message-ID: <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> Date: Tue, 23 Jan 2007 09:37:36 -0800 From: "Jack Vogel" To: "Guy Helmer" In-Reply-To: <45B64469.9020002@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B64469.9020002@palisadesys.com> Cc: freebsd-stable@freebsd.org Subject: Re: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 17:37:38 -0000 On 1/23/07, Guy Helmer wrote: > Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) > hanging after printing the "Waiting 5 seconds for SCSI devices to > settle" message. The hang doesn't always happen - sometimes we have to > go through several reboot cycles for it to happen - but sometimes it > happens with every reboot. For those who would suggest that this > happens because I'm using Seagate drives, it happens even if we totally > remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) > and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit > ethernet NICs aren't found but the hang doesn't occur. Uh, just a wild stab, I dont have the Supermicro motherboard, but on the Intel design its based on there is unfortunately still this problem where the floppy has some bogus wait in it. I thought this was fixed along the way but I just installed RELEASE on Friday and saw it still occurs. It will make the system appear to hang, look at the floppy LED, is it on? If that is the problem you are seeing then it will eventually time out, I get around it by defining the driver out of the kernel after install, but you could also remove the floppy. If that isnt it, I would suggest installing using ACPI disabled or SAFE if needed, and then tweak the kernel after. Have you checked the January snapshot of CURRENT to see what happens there? Jack From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 17:53:07 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A97816A401 for ; Tue, 23 Jan 2007 17:53:07 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [192.188.162.7]) by mx1.freebsd.org (Postfix) with ESMTP id 15E5E13C4DA for ; Tue, 23 Jan 2007 17:53:06 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NHr7UD063871; Tue, 23 Jan 2007 11:53:07 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NHr07B012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 11:53:00 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45B64B67.2000905@palisadesys.com> Date: Tue, 23 Jan 2007 11:52:39 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jack Vogel References: <45B64469.9020002@palisadesys.com> <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> In-Reply-To: <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Tue, 23 Jan 2007 11:53:00 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 17:53:07 -0000 Jack Vogel wrote: > On 1/23/07, Guy Helmer wrote: >> Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ >> motherboard (dual Xeon 5130 CPUs on the Blackford chipset - >> http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) >> >> hanging after printing the "Waiting 5 seconds for SCSI devices to >> settle" message. The hang doesn't always happen - sometimes we have to >> go through several reboot cycles for it to happen - but sometimes it >> happens with every reboot. For those who would suggest that this >> happens because I'm using Seagate drives, it happens even if we totally >> remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) >> and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit >> ethernet NICs aren't found but the hang doesn't occur. > > Uh, just a wild stab, I dont have the Supermicro motherboard, but on the > Intel design its based on there is unfortunately still this problem > where the > floppy has some bogus wait in it. I thought this was fixed along the way > but I just installed RELEASE on Friday and saw it still occurs. It will > make the system appear to hang, look at the floppy LED, is it on? > If that is the problem you are seeing then it will eventually time out, I > get around it by defining the driver out of the kernel after install, > but you > could also remove the floppy. Sorry, there isn't a floppy drive on this system. > If that isnt it, I would suggest installing using ACPI disabled or > SAFE if > needed, and then tweak the kernel after. OK, thanks. > Have you checked the January snapshot of CURRENT to see what > happens there? I'll try it and report what happens. Thanks again, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 18:18:34 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF1AA16A402 for ; Tue, 23 Jan 2007 18:18:34 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [192.188.162.7]) by mx1.freebsd.org (Postfix) with ESMTP id 65BD713C461 for ; Tue, 23 Jan 2007 18:18:34 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NIIYWJ064002; Tue, 23 Jan 2007 12:18:34 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0NIIM6W014561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 12:18:22 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45B65155.5080304@palisadesys.com> Date: Tue, 23 Jan 2007 12:17:57 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jack Vogel References: <45B64469.9020002@palisadesys.com> <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> In-Reply-To: <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Tue, 23 Jan 2007 12:18:22 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_61 0.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 18:18:34 -0000 Jack Vogel wrote: > On 1/23/07, Guy Helmer wrote: >> Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ >> motherboard (dual Xeon 5130 CPUs on the Blackford chipset - >> http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) >> >> hanging after printing the "Waiting 5 seconds for SCSI devices to >> settle" message. The hang doesn't always happen - sometimes we have to >> go through several reboot cycles for it to happen - but sometimes it >> happens with every reboot. For those who would suggest that this >> happens because I'm using Seagate drives, it happens even if we totally >> remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) >> and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit >> ethernet NICs aren't found but the hang doesn't occur. > ... > If that isnt it, I would suggest installing using ACPI disabled or > SAFE if > needed, and then tweak the kernel after. hint.apic.0.disabled=1 helped - it hasn't hung yet in several boot cycles. New dmesg is attached below in case it helps anyone see a better fix than disabling the APICs. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RC2 #1: Mon Jan 22 18:51:58 UTC 2007 support@palisadesys.com:/usr/src/sys/amd64/compile/PALISADE-SMP-DEBUG Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80870000. Preloaded splash_image_data "/boot/ph-splash.pcx" at 0xffffffff80870208. Preloaded elf obj module "/boot/kernel/if_silbpi.ko" at 0xffffffff80870268. Calibrating clock(s) ... i8254 clock: 1193278 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2000081040 Hz CPU: Intel(R) Xeon(R) CPU 5130 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e33d,CX16,,,> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 real memory = 5100273664 (4864 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x000000000096e000 - 0x00000000c7089fff, 3329343488 bytes (812828 pages) 0x0000000100000000 - 0x000000012ffeffff, 805240832 bytes (196592 pages) avail memory = 4124282880 (3933 MB) kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device null: random: io: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80051000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25d88086) AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 7 N 0 3 4 5 6 7 10 11 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 7 N 0 3 4 5 6 7 10 11 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 4 5 6 7 10 11 14 15 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1010 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.0.INTA at func 0: 255 ACPI: Found matching pin for 0.2.INTA at func 0: 255 ACPI: Found matching pin for 0.4.INTA at func 0: 255 ACPI: Found matching pin for 0.6.INTA at func 0: 255 ACPI: Found matching pin for 0.8.INTA at func 0: 7 ACPI: Found matching pin for 0.28.INTA at func 0: 5 ACPI: Found matching pin for 0.29.INTA at func 0: 5 ACPI: Found matching pin for 0.29.INTB at func 1: 10 ACPI: Found matching pin for 0.29.INTC at func 2: 11 ACPI: Found matching pin for 0.29.INTD at func 3: 7 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 3: 10 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x25d8, revid=0x93 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f7, revid=0x93 bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x25f8, revid=0x93 bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x25f9, revid=0x93 bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x1a38, revid=0x93 bus=0, slot=8, func=0 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 64, base fe700000, size 10, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.LPC0.LNKA:0) pcib0: slot 8 INTA routed to irq 7 via \\_SB_.PCI0.LPC0.LNKA found-> vendor=0x8086, dev=0x25f0, revid=0x93 bus=0, slot=16, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0x93 bus=0, slot=16, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0x93 bus=0, slot=16, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f1, revid=0x93 bus=0, slot=17, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f3, revid=0x93 bus=0, slot=19, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f5, revid=0x93 bus=0, slot=21, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f6, revid=0x93 bus=0, slot=22, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2690, revid=0x09 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 pcib0: matched entry for 0.28.INTA (src \\_SB_.PCI0.LPC0.LNKB:0) pcib0: slot 28 INTA routed to irq 5 via \\_SB_.PCI0.LPC0.LNKB found-> vendor=0x8086, dev=0x2688, revid=0x09 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 00001800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPC0.LNKB:0) pcib0: slot 29 INTA routed to irq 5 via \\_SB_.PCI0.LPC0.LNKB found-> vendor=0x8086, dev=0x2689, revid=0x09 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.PCI0.LPC0.LNKD:0) pcib0: slot 29 INTB routed to irq 10 via \\_SB_.PCI0.LPC0.LNKD found-> vendor=0x8086, dev=0x268a, revid=0x09 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.PCI0.LPC0.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.PCI0.LPC0.LNKC found-> vendor=0x8086, dev=0x268b, revid=0x09 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=7 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.PCI0.LPC0.LNKA:0) pcib0: slot 29 INTD routed to irq 7 via \\_SB_.PCI0.LPC0.LNKA found-> vendor=0x8086, dev=0x268c, revid=0x09 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d8600000, size 10, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPC0.LNKB:0) pcib0: slot 29 INTA routed to irq 5 via \\_SB_.PCI0.LPC0.LNKB found-> vendor=0x8086, dev=0x244e, revid=0xd9 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2670, revid=0x09 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x269e, revid=0x09 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001880, size 4, enabled found-> vendor=0x8086, dev=0x269b, revid=0x09 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0141, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001100, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPC0.LNKD:0) pcib0: slot 31 INTB routed to irq 10 via \\_SB_.PCI0.LPC0.LNKD pcib1: at device 2.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 5 pcib1: I/O decode 0x2000-0x3fff pcib1: memory decode 0xd8000000-0xd82fffff pcib1: prefetched decode 0xfff00000-0xfffff ACPI: Found matching pin for 1.0.INTA at func 0: 7 pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x8086, dev=0x3500, revid=0x01 bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LPC0.LNKA:0) pcib1: slot 0 INTA routed to irq 7 via \\_SB_.PCI0.LPC0.LNKA found-> vendor=0x8086, dev=0x350c, revid=0x01 bus=1, slot=0, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) pcib2: irq 7 at device 0.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 4 pcib2: I/O decode 0x2000-0x2fff pcib2: memory decode 0xd8000000-0xd80fffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI: Found matching pin for 2.0.INTA at func 0: 7 ACPI: Found matching pin for 2.2.INTA at func 0: 11 pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x8086, dev=0x3510, revid=0x01 bus=2, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.LPC0.LNKA:0) pcib2: slot 0 INTA routed to irq 7 via \\_SB_.PCI0.LPC0.LNKA found-> vendor=0x8086, dev=0x3518, revid=0x01 bus=2, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 pcib2: matched entry for 2.2.INTA (src \\_SB_.PCI0.LPC0.LNKC:0) pcib2: slot 2 INTA routed to irq 11 via \\_SB_.PCI0.LPC0.LNKC pcib3: irq 7 at device 0.0 on pci2 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 pcib4: irq 11 at device 2.0 on pci2 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x2000-0x2fff pcib4: memory decode 0xd8000000-0xd80fffff pcib4: prefetched decode 0xfff00000-0xfffff ACPI: Found matching pin for 4.0.INTA at func 0: 5 pci_link2: BIOS IRQ 5 for 4.0.INTA does not match previous BIOS IRQ 11 ACPI: Found matching pin for 4.0.INTB at func 1: 11 pci_link3: BIOS IRQ 11 for 4.0.INTB does not match previous BIOS IRQ 10 pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x8086, dev=0x1096, revid=0x01 bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8000000, size 17, enabled pcib4: (null) requested memory range 0xd8000000-0xd801ffff: good pcib2: (null) requested memory range 0xd8000000-0xd801ffff: good pcib1: (null) requested memory range 0xd8000000-0xd801ffff: good map[18]: type 4, range 32, base 00002000, size 5, enabled pcib4: (null) requested I/O range 0x2000-0x201f: in range pcib2: (null) requested I/O range 0x2000-0x201f: in range pcib1: (null) requested I/O range 0x2000-0x201f: in range pcib4: matched entry for 4.0.INTA (src \\_SB_.PCI0.LPC0.LNKC:0) pcib4: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LPC0.LNKC found-> vendor=0x8086, dev=0x1096, revid=0x01 bus=4, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8020000, size 17, enabled pcib4: (null) requested memory range 0xd8020000-0xd803ffff: good pcib2: (null) requested memory range 0xd8020000-0xd803ffff: good pcib1: (null) requested memory range 0xd8020000-0xd803ffff: good map[18]: type 4, range 32, base 00002020, size 5, enabled pcib4: (null) requested I/O range 0x2020-0x203f: in range pcib2: (null) requested I/O range 0x2020-0x203f: in range pcib1: (null) requested I/O range 0x2020-0x203f: in range pcib4: matched entry for 4.0.INTB (src \\_SB_.PCI0.LPC0.LNKD:0) pcib4: slot 0 INTB routed to irq 10 via \\_SB_.PCI0.LPC0.LNKD em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 11 at device 0.0 on pci4 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0x2000 em0: bpf attached em0: Ethernet address: 00:30:48:31:1f:76 em0: [MPSAFE] em1: port 0x2020-0x203f mem 0xd8020000-0xd803ffff irq 10 at device 0.1 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8020000 em1: Reserved 0x20 bytes for rid 0x18 type 4 at 0x2020 em1: bpf attached em1: Ethernet address: 00:30:48:31:1f:77 em1: [MPSAFE] pcib5: at device 0.3 on pci1 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x3000-0x3fff pcib5: memory decode 0xd8100000-0xd81fffff pcib5: prefetched decode 0xfff00000-0xfffff ACPI: Found matching pin for 5.2.INTA at func 0: 11 ACPI: Found matching pin for 5.2.INTB at func 1: 10 pci5: on pcib5 pci5: physical bus=5 found-> vendor=0x9005, dev=0x801d, revid=0x10 bus=5, slot=2, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 4, range 32, base 00003400, size 8, enabled pcib5: (null) requested I/O range 0x3400-0x34ff: in range pcib1: (null) requested I/O range 0x3400-0x34ff: in range map[14]: type 1, range 64, base d8100000, size 13, enabled pcib5: (null) requested memory range 0xd8100000-0xd8101fff: good pcib1: (null) requested memory range 0xd8100000-0xd8101fff: good map[1c]: type 4, range 32, base 00003000, size 8, enabled pcib5: (null) requested I/O range 0x3000-0x30ff: in range pcib1: (null) requested I/O range 0x3000-0x30ff: in range pcib5: matched entry for 5.2.INTA (src \\_SB_.PCI0.LPC0.LNKC:0) pcib5: slot 2 INTA routed to irq 11 via \\_SB_.PCI0.LPC0.LNKC found-> vendor=0x9005, dev=0x801d, revid=0x10 bus=5, slot=2, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 4, range 32, base 00003c00, size 8, enabled pcib5: (null) requested I/O range 0x3c00-0x3cff: in range pcib1: (null) requested I/O range 0x3c00-0x3cff: in range map[14]: type 1, range 64, base d8102000, size 13, enabled pcib5: (null) requested memory range 0xd8102000-0xd8103fff: good pcib1: (null) requested memory range 0xd8102000-0xd8103fff: good map[1c]: type 4, range 32, base 00003800, size 8, enabled pcib5: (null) requested I/O range 0x3800-0x38ff: in range pcib1: (null) requested I/O range 0x3800-0x38ff: in range pcib5: matched entry for 5.2.INTB (src \\_SB_.PCI0.LPC0.LNKD:0) pcib5: slot 2 INTB routed to irq 10 via \\_SB_.PCI0.LPC0.LNKD ahd0: port 0x3400-0x34ff,0x3000-0x30ff mem 0xd8100000-0xd8101fff irq 11 at device 2.0 on pci5 ahd0: Defaulting to MEMIO on ahd0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x3400 ahd0: Reserved 0x100 bytes for rid 0x1c type 4 at 0x3000 ahd0: Enabling 39Bit Addressing ahd0: Reading VPD from SEEPROM...ahd0: VPD parsing successful ahd0: Reading SEEPROM...done. ahd0: STPWLEVEL is on ahd0: Manual Primary Termination ahd0: Manual Secondary Termination ahd0: Primary High byte termination Enabled ahd0: Primary Low byte termination Enabled ahd0: Secondary High byte termination Disabled ahd0: Secondary Low byte termination Disabled ahd0: Downloading Sequencer Program... 697 instructions downloaded ahd0: Features 0x3c101, Bugs 0x740002, Flags 0x143f1 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x3c00-0x3cff,0x3800-0x38ff mem 0xd8102000-0xd8103fff irq 10 at device 2.1 on pci5 ahd1: Defaulting to MEMIO on ahd1: Reserved 0x100 bytes for rid 0x10 type 4 at 0x3c00 ahd1: Reserved 0x100 bytes for rid 0x1c type 4 at 0x3800 ahd1: Enabling 39Bit Addressing ahd1: Reading VPD from SEEPROM...ahd1: VPD parsing successful ahd1: Reading SEEPROM...done. ahd1: STPWLEVEL is on ahd1: Manual Primary Termination ahd1: Manual Secondary Termination ahd1: Primary High byte termination Enabled ahd1: Primary Low byte termination Enabled ahd1: Secondary High byte termination Disabled ahd1: Secondary Low byte termination Disabled ahd1: Downloading Sequencer Program... 697 instructions downloaded ahd1: Features 0x3c101, Bugs 0x740002, Flags 0x143f0 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pcib6: at device 4.0 on pci0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xf000-0xfff pcib6: memory decode 0xfff00000-0xfffff pcib6: prefetched decode 0xfff00000-0xfffff pci6: on pcib6 pci6: physical bus=6 pcib7: at device 6.0 on pci0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xf000-0xfff pcib7: memory decode 0xfff00000-0xfffff pcib7: prefetched decode 0xfff00000-0xfffff pci7: on pcib7 pci7: physical bus=7 pci0: at device 8.0 (no driver attached) pcib8: irq 5 at device 28.0 on pci0 pcib8: secondary bus 8 pcib8: subordinate bus 9 pcib8: I/O decode 0xf000-0xfff pcib8: memory decode 0xfff00000-0xfffff pcib8: prefetched decode 0xfff00000-0xfffff pcib8: could not get PCI interrupt routing table for \\_SB_.PCI0.PEX0 - AE_NOT_FOUND pci8: on pcib8 pci8: physical bus=8 found-> vendor=0x8086, dev=0x032c, revid=0x09 bus=8, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) pcib9: at device 0.0 on pci8 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0xfff00000-0xfffff pcib9: prefetched decode 0xfff00000-0xfffff pci9: on pcib9 pci9: physical bus=9 uhci0: port 0x1800-0x181f irq 5 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 uhci0: [GIANT-LOCKED] 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 uhci1: port 0x1820-0x183f irq 10 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 uhci1: [GIANT-LOCKED] 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 uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 7 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8600000-0xd86003ff irq 5 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8600000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib10: at device 30.0 on pci0 pcib10: secondary bus 10 pcib10: subordinate bus 10 pcib10: I/O decode 0x4000-0x4fff pcib10: memory decode 0xd8300000-0xd83fffff pcib10: prefetched decode 0xd0000000-0xd7ffffff pcib10: Subtractively decoded bridge. ACPI: Found matching pin for 10.1.INTA at func 0: 11 pci10: on pcib10 pci10: physical bus=10 found-> vendor=0x1002, dev=0x515e, revid=0x02 bus=10, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base d0000000, size 27, enabled pcib10: (null) requested memory range 0xd0000000-0xd7ffffff: good map[14]: type 4, range 32, base 00004000, size 8, enabled pcib10: (null) requested I/O range 0x4000-0x40ff: in range map[18]: type 1, range 32, base d8300000, size 16, enabled pcib10: (null) requested memory range 0xd8300000-0xd830ffff: good pcib10: matched entry for 10.1.INTA (src \\_SB_.PCI0.LPC0.LNKC:0) pcib10: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LPC0.LNKC pci10: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1880 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=50 ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x8 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: failed to reset the aux device. sio0: irq maps: 0x801 0x811 0x801 0x801 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x801 0x809 0x801 0x801 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 233016 -> 100000 linprocfs registered procfs registered Timecounter "TSC" frequency 2000081040 Hz quality 800 Timecounters tick every 1.000 msec Linux ELF exec handler installed ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default DUMMYNET em0: Link is up 100 Mbps Half Duplex with IPv6 initialized (040826) lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire acd0: setting PIO4 on 63XXESB2 chip acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: setting UDMA33 on 63XXESB2 chip acd0: DVDROM drive at ata0 as slave acd0: read 4125KB/s (4125KB/s), 256KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Waiting 5 seconds for SCSI devices to settle (noperiph:ahd0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahd1:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahd1: Selection Timeout on A:0. 0 SCBs aborted ahd0: Selection Timeout on A:1. 0 SCBs aborted ahd1: Selection Timeout on A:1. 0 SCBs aborted ahd0: Selection Timeout on A:2. 0 SCBs aborted ahd1: Selection Timeout on A:10. 0 SCBs aborted ahd0: Selection Timeout on A:3. 0 SCBs aborted ahd1: Selection Timeout on A:11. 0 SCBs aborted ahd0: Selection Timeout on A:10. 0 SCBs aborted ahd1: Selection Timeout on A:12. 0 SCBs aborted ahd0: Selection Timeout on A:11. 0 SCBs aborted ahd1: Selection Timeout on A:13. 0 SCBs aborted ahd0: Selection Timeout on A:12. 0 SCBs aborted ahd1: Selection Timeout on A:14. 0 SCBs aborted ahd0: Selection Timeout on A:13. 0 SCBs aborted ahd1: Selection Timeout on A:15. 0 SCBs aborted ahd0: Selection Timeout on A:14. 0 SCBs aborted ahd1: Selection Timeout on A:2. 0 SCBs aborted ahd0: Selection Timeout on A:15. 0 SCBs aborted ahd1: Selection Timeout on A:3. 0 SCBs aborted ahd0: Selection Timeout on A:4. 0 SCBs aborted ahd1: Selection Timeout on A:4. 0 SCBs aborted ahd0: Selection Timeout on A:5. 0 SCBs aborted ahd1: Selection Timeout on A:5. 0 SCBs aborted ahd0: Selection Timeout on A:8. 0 SCBs aborted ahd1: Selection Timeout on A:6. 0 SCBs aborted ahd0: Selection Timeout on A:9. 0 SCBs aborted (probe0:ahd0:0:0:0): Retrying Command (ahd0:A:0:0): Sending PPR bus_width 1, period 8, offset fe, ppr_options ff (ahd0:A:0:0): Received PPR width 1, period 8, offset 3f,options ff Filtered to width 1, period 8, offset 3f, options ff ahd0: target 0 using 16bit transfers ahd0: target 0 synchronous with period = 0x8, offset = 0x3f(RDSTRM|DT|IU|RTI|QAS) ahd1: Selection Timeout on A:8. 0 SCBs aborted ahd1: Selection Timeout on A:9. 0 SCBs aborted pass0 at ahd0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number 3KS4DNXG00009713RWDT pass0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled pass1 at ahd0 bus 0 target 6 lun 0 pass1: Fixed Processor SCSI-2 device pass1: Serial Number 1 pass1: 3.300MB/s transfers ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: Serial Number 1 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device GEOM: new disk da0 ATA PseudoRAID loaded da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number 3KS4DNXG00009713RWDT da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init em0: Link is Down em0: Link is up 100 Mbps Half Duplex em0: link state changed to UP From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 18:58:00 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE00C16A4CB for ; Tue, 23 Jan 2007 18:58:00 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 1271913C4DB for ; Tue, 23 Jan 2007 18:57:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCC00EXN4OH5C70@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 19:57:53 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCC001KR4OGPUP0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 19:57:53 +0100 (CET) Date: Tue, 23 Jan 2007 19:57:52 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH To: freebsd-stable@freebsd.org Message-id: <20070123195752.f75382e4.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: OT: problems with ftp-archive? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 18:58:01 -0000 Hello, Are there problems with ftp-archive.freebsd.org? It won't let me login as anonymous, I just get this: tingo@kg-work$ ftp ftp-archive.freebsd.org Trying 2001:468:902:201::106... Trying 128.205.32.51... Connected to coggsworth.cse.buffalo.edu. 220 ftp.cse.buffalo.edu FTP server (Version wu-2.6.2(1) Thu Nov 2 08:49:01 EST 2006) ready. Name (ftp-archive.freebsd.org:tingo): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 530 Login incorrect. ftp: Login failed. Or has it been closed somehow? -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 19:13:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E8016A405 for ; Tue, 23 Jan 2007 19:13:16 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from daemon.crashmail.de (daemon.crashmail.de [88.198.125.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0E00C13C442 for ; Tue, 23 Jan 2007 19:13:15 +0000 (UTC) (envelope-from stefan.tell@crashmail.de) Received: from localhost (dslb-082-083-075-123.pools.arcor-ip.net [82.83.75.123]) by daemon.crashmail.de (Postfix) with ESMTP id 384AE64B6A for ; Tue, 23 Jan 2007 20:13:14 +0100 (CET) Received: by crashmail.de (OpenXP/4.10.7328 (FreeBSD) (i386)); 23 Jan 2007 20:12:46 +0100 Date: 23 Jan 2007 20:12:00 +0100 From: steve.tell@crashmail.de (Stefan 'Steve' Tell) To: freebsd-stable@freebsd.org Message-ID: User-Agent: OpenXP/4.10.7328 (FreeBSD) (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: The Third Place X-Homepage: http://blog.crashmail.de Subject: Can't get Enhanced Speedstep working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 19:13:16 -0000 Hi, I cannot get Enhanced Speedstep working on my new laptop (Medion MD98000). Maybe you guys have an idea ... ,---- [ dmesg | grep est ] | est0: on cpu0 | est: CPU supports Enhanced Speedstep, but is not recognized. | est: cpu_vendor GenuineIntel, msr 6130a2c06000a2c | device_attach: est0 attach returned 6 `---- You can get a full 'pciconf -vl' here: * You can get a dmesg-output here: * You can also get a full 'acpidump -t -d > medion_md98000_acpidump.asl' here: * Can I provide any other information? Any hints how to get this working? Thanks in advance again. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 19:22:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FB9816A407 for ; Tue, 23 Jan 2007 19:22:56 +0000 (UTC) (envelope-from jandrese@mitre.org) Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by mx1.freebsd.org (Postfix) with ESMTP id 6203E13C44C for ; Tue, 23 Jan 2007 19:22:56 +0000 (UTC) (envelope-from jandrese@mitre.org) Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l0NJMtu3013530 for ; Tue, 23 Jan 2007 14:22:55 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 601721BD7C for ; Tue, 23 Jan 2007 14:22:55 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l0NJMtKD013527 for ; Tue, 23 Jan 2007 14:22:55 -0500 Received: from IMCSRV6.MITRE.ORG ([129.83.20.237]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:22:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2007 14:22:54 -0500 Message-ID: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dummynet and simulating random delay thread-index: Acc/I+FRI1NKfsplS6GVSLJ+SmRh9A== From: "Andresen, Jason R." To: X-OriginalArrivalTime: 23 Jan 2007 19:22:55.0037 (UTC) FILETIME=[E1F036D0:01C73F23] Subject: Dummynet and simulating random delay X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 19:22:56 -0000 I have a project that requires me to simulate a link with varying but well defined delay. The link is guarenteed to deliver packets in order, so I wish to maintain that behavior with Dummynet. My first thought was to create three or four different queues with different delays and use the probability rule to dump them into the queue, but that gets packets out of order and doesn't work. =20 My next thought is to write a script that reconfigures the pipe randomly every few hundred milliseconds or so during the test, but I'm not sure what that means for packets that are already in it. Does it mean bursts of data when the delay is turned down (which would actually be realistic in this scenario), or is there a danger of out of order packets? Are there any dummynet experts out there that can tell me exactly how it will behave when delays are changed while there are still packets in the buckets? Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 20:01:14 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 969D216A400 for ; Tue, 23 Jan 2007 20:01:14 +0000 (UTC) (envelope-from matthew.herzog@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 30D5C13C461 for ; Tue, 23 Jan 2007 20:01:13 +0000 (UTC) (envelope-from matthew.herzog@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so355256nfc for ; Tue, 23 Jan 2007 12:01:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=a8MM70od38+v6InroOZGiOjyWRN6le2naz/nGCRU0N6f2G17axYl+16q7HhAeKaz0BSOxwK1rU8MVJbf8nnvLKwg7oQa7iGdwvb1CNlYy5h65miiEXW5jBsQCdPKKavEdYvKuYxG6lj1ZulXbCLsEEXKSOYsxJaGQgK0KG5wT4E= Received: by 10.82.118.2 with SMTP id q2mr8142615buc.1169582472236; Tue, 23 Jan 2007 12:01:12 -0800 (PST) Received: by 10.82.167.2 with HTTP; Tue, 23 Jan 2007 12:01:12 -0800 (PST) Message-ID: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> Date: Tue, 23 Jan 2007 15:01:12 -0500 From: "Matthew Herzog" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: php apache2 config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 20:01:14 -0000 When I load a file named php4.info I can see all my php build information. If I change that same file's name to phpinfo.php, I get a "premature end of script headers" error. The file contains this text only: and is owned by apache. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 20:18:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05DCA16A401 for ; Tue, 23 Jan 2007 20:18:40 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by mx1.freebsd.org (Postfix) with ESMTP id D48DA13C4BF for ; Tue, 23 Jan 2007 20:18:39 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from localhost (localhost [127.0.0.1]) by ly.sdf.com (Postfix) with ESMTP id 00D5410C6CD; Tue, 23 Jan 2007 12:21:52 -0800 (PST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jan 23 12:21:52 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45b66e60120332145363081 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=-0.306, BAYES_00=-2.599, DSPAM_HAM=-0.1, INFO_TLD=1.273] Received: from ly.sdf.com ([127.0.0.1]) by localhost (ly.sdf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3c5kXmtF-cY; Tue, 23 Jan 2007 12:21:51 -0800 (PST) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by ly.sdf.com (Postfix) with ESMTP id CCBC510C6CC; Tue, 23 Jan 2007 12:21:51 -0800 (PST) Message-ID: <4974936.161169583711744.JavaMail.root@ly.sdf.com> Date: Tue, 23 Jan 2007 12:21:51 -0800 (PST) From: Tom Samplonius To: Matthew Herzog In-Reply-To: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: php apache2 config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 20:18:40 -0000 ----- Matthew Herzog wrote: > When I load a file named php4.info I can see all my php build > information. > > If I change that same file's name to phpinfo.php, I get a "premature > end of script headers" > error. The file contains this text only: > > phpinfo(); > ?> > > and is owned by apache. This posting does not seem FreeBSD related, or even contain a question. I guess you want to fix your PHP install. It appears that your configuration is incorrect. Tom From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 20:57:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75F0C16A400 for ; Tue, 23 Jan 2007 20:57:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [213.154.244.69]) by mx1.freebsd.org (Postfix) with ESMTP id E33D413C442 for ; Tue, 23 Jan 2007 20:57:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id BA0A7B80E; Tue, 23 Jan 2007 21:57:06 +0100 (CET) Message-ID: <45B676A2.5090009@andric.com> Date: Tue, 23 Jan 2007 21:57:06 +0100 From: Dimitry Andric User-Agent: Thunderbird 3.0a1 (Windows/20070122) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org> In-Reply-To: <45B63C3E.9010808@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 20:57:09 -0000 Bruce A. Mah wrote: > Just to confirm, you're dealing with a gif(4) interface with an > explicitly-configured destination address and a 128-bit prefixlen, yes? Yes. The specific line in my rc.conf is: ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128" >> Maybe >> there is something else involved too, for example the route command >> itself? > Not sure what you mean by this exactly...???... I mean that it may be that between -RELEASE and -STABLE, other things have changed, e.g. network rc scripts, /sbin/route itself, etc, which may also influence this behaviour. I'm sure more than only nd6.c changed. :) However, for me, with the whole system at -STABLE (as of Jan 11), I verified the following results again just now: nd6.c rev state --------- ----- 1.48.2.12 works 1.48.2.13 works 1.48.2.14 works 1.48.2.15 works 1.48.2.16 doesn't work > Here's what I've tested so far...in the table below, "work" means that > the host route to the destination got installed correctly and "no work" > means that it didn't. > > Base Local Patch Result > ---- ----------- ------ > 6.2-RELEASE Unmodified No work > 6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work > 6.2-STABLE Unmodified No work > 6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work > 6.2-STABLE Revert nd6.c 1.48.2.16 No work So strangely, this is different from my results... I can't install 6.2-RELEASE on the specific box, alas. > I'm going to write up an entry for the 6.2-RELEASE errata notes > documenting the existence of a problem and a workaround. We still need > to figure out exactly what the right fix is. Testing results from other > users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome. Just FYI, my initial alternative workaround was to use prefixlen 126, e.g.: ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126" Cheers, Dimitry From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 21:09:14 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80CEC16A400 for ; Tue, 23 Jan 2007 21:09:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 243D013C459 for ; Tue, 23 Jan 2007 21:09:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9123 invoked by uid 399); 23 Jan 2007 21:09:05 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Jan 2007 21:09:05 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45B67968.2030304@FreeBSD.org> Date: Tue, 23 Jan 2007 13:08:56 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stephen Casner References: <20070123001343.J641@oak.packetdesign.com> In-Reply-To: <20070123001343.J641@oak.packetdesign.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: System hang on laptop suspend/resume X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 21:09:14 -0000 Stephen Casner wrote: > [Working my way up the food chain here after no response on > freebsd-questions and freebsd-mobile. Please tell me if this question > is ill-formed or if the answer is unlikely to be known.] Your post is exemplary in providing complete and relevant details. My guess as to why you're not getting a response is that suspend/resume issues currently have no champion amongst FreeBSD developers, and therefore they are simply not being addressed. This is disappointing, but part of life in a volunteer project. > I was running FreeBSD 4.8 on my Sony PCG-505TR laptop for about three > years until I recently upgraded to 6.1 The first and only suggestion I have is to upgrade to 6.2 now that it's out, but that's just to make doubly sure your issue hasn't been solved (which is likely). Beyond that, carefully combing the archives of the -mobile, -stable, and -current lists for similar issues might lead to some things for you to try. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 21:11:43 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A6A216A406 for ; Tue, 23 Jan 2007 21:11:43 +0000 (UTC) (envelope-from gmenhennitt@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id AC25813C45E for ; Tue, 23 Jan 2007 21:11:42 +0000 (UTC) (envelope-from gmenhennitt@optusnet.com.au) Received: from [203.2.73.8] (c210-49-176-194.mckinn1.vic.optusnet.com.au [210.49.176.194]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l0NLBeEP026135; Wed, 24 Jan 2007 08:11:41 +1100 Message-ID: <45B67A85.4080500@optusnet.com.au> Date: Wed, 24 Jan 2007 08:13:41 +1100 From: Graham Menhennitt User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Matthew Herzog References: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> In-Reply-To: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: php apache2 config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 21:11:43 -0000 Matthew Herzog wrote: > When I load a file named php4.info I can see all my php build > information. > > If I change that same file's name to phpinfo.php, I get a "premature > end of script headers" > error. The file contains this text only: > > phpinfo(); > ?> > > and is owned by apache. This is purely a guess since I know nothing about php or apache... Is phpinfo() causing a recursive call to phpinfo.php by chance? Graham From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 22:19:13 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 569A216A401 for ; Tue, 23 Jan 2007 22:19:13 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.freebsd.org (Postfix) with ESMTP id 0E46013C4A5 for ; Tue, 23 Jan 2007 22:19:13 +0000 (UTC) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 473F7B80A for ; Tue, 23 Jan 2007 17:19:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070123050907.GD89970@tigerfish2.my.domain> References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <72347C40-81E3-4E4D-9F27-3058B73359B3@khera.org> <45B1BF6E.7090704@delphij.net> <20070123050907.GD89970@tigerfish2.my.domain> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-157506821; protocol="application/pkcs7-signature" Message-Id: From: Vivek Khera Date: Tue, 23 Jan 2007 17:19:11 -0500 To: FreeBSD Stable X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 22:19:13 -0000 --Apple-Mail-5-157506821 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 23, 2007, at 12:09 AM, Bruce Burden wrote: > Sigh. Okay, thank you for the responses. I think I will > go with "Plan 'C'", and find a PCI-X LSI MegaRAID card. I think > there is some hope the megamgr port will work with them. My preferred card is the 320-2X dual channel card. It is wicked awesome fast and the megamgr program does work with them. Unfortunately, the Sun X4100 boxes have low-profile slots, and the only option for RAID cards is the Adaptec 2230SLP for dual channels. This is why I use the adaptec cards :-( --Apple-Mail-5-157506821-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 22:25:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 406CC16A468 for ; Tue, 23 Jan 2007 22:25:24 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from home.quip.cz (grimm.quip.cz [213.220.192.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8313713C4F8 for ; Tue, 23 Jan 2007 22:25:22 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (qwork.quip.test [192.168.1.2]) by home.quip.cz (Postfix) with ESMTP id 2D2DF62DB; Tue, 23 Jan 2007 23:25:14 +0100 (CET) Message-ID: <45B68B49.8070605@quip.cz> Date: Tue, 23 Jan 2007 23:25:13 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Jeremy Chadwick References: <45B2AAF8.9010509@isc.org> <45B3F996.8030303@FreeBSD.org> <20070122194631.cef384c2.torfinn.ingolfsen@broadpark.no> <20070122185433.GA65112@icarus.home.lan> In-Reply-To: <20070122185433.GA65112@icarus.home.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: BTX issues when booting from a USB CD-ROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 22:25:24 -0000 Jeremy Chadwick wrote: > On Mon, Jan 22, 2007 at 07:46:31PM +0100, Torfinn Ingolfsen wrote: > >>Aha. So on a laptop I have where booting FreeBSD from a usb harddrive >>results in endless scrolling of text on the console (probably register >>dumps, hard to tell) until the laptop is turned off, this might be the >>same issue? >>I can boot NetBSD and OpenBSD from different partitions on the same usb >>hardrive, on the same laptop. >> >>Is there a known fix or workaround for this issue? (Probably not, but >>just in case...) > > > Does the GRUB bootloader behave this way? If not (e.g. it works), > then one could use that as an alternative to btx. GRUB is working in my case (GRUB on USB flash can boot FreeBSD 6.2 on Sun Fire X2100 and some others, where BTX is not working). But as I mentioned somewhere - stil not working on HP servers - don't know why. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 22:27:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5864B16A401 for ; Tue, 23 Jan 2007 22:27:50 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 1B17913C4DB for ; Tue, 23 Jan 2007 22:27:50 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCC00HBMEEDED20@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 23:27:49 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCC001KMEECGBF1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 23:27:49 +0100 (CET) Date: Tue, 23 Jan 2007 23:27:48 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <20070123195752.f75382e4.torfinn.ingolfsen@broadpark.no> To: freebsd-stable@freebsd.org Message-id: <20070123232748.086dd095.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20070123195752.f75382e4.torfinn.ingolfsen@broadpark.no> Subject: Re: OT: problems with ftp-archive? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 22:27:50 -0000 On Tue, 23 Jan 2007 19:57:52 +0100 Torfinn Ingolfsen wrote: > Are there problems with ftp-archive.freebsd.org? Never mind, it is working again now. Sorry about the noise. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 23:16:16 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CF6A16A405 for ; Tue, 23 Jan 2007 23:16:16 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: from smtp104.plus.mail.re2.yahoo.com (smtp104.plus.mail.re2.yahoo.com [206.190.53.29]) by mx1.freebsd.org (Postfix) with SMTP id 52C5713C4B9 for ; Tue, 23 Jan 2007 23:16:16 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: (qmail 4649 invoked from network); 23 Jan 2007 23:16:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=UtkCIGCnB07J0W/xbh2Zh1Ej+oZlxbVf0JU+HamTiAt6L7xN67m4r5sA5fKmSx3FDrR4W+BAoqxr6CNnkYdrH3N0BhOFux7ncSaocVVUrLVbHmw/Q+gJV/PgfphKdzNMxodiCWD3zripy7JFmKddRj3Ckm8gRTfkY1MLD4ct+PI= ; Received: from unknown (HELO ?192.168.7.202?) (strbenjr@69.143.49.135 with plain) by smtp104.plus.mail.re2.yahoo.com with SMTP; 23 Jan 2007 23:16:15 -0000 X-YMail-OSG: bp9yN4gVM1nEP3sjNeLoKiAaAbbjqYd3BGlIgdySpmh38wWfQUMKe3hEV4kkC_HtHF2kO4wnB7C6a8rYJDrsPs3pz8gOxMSNHGne1rT5L4tBFKQWIurJK8dpbgWyxFLAlFH2TdTDAuE6adPxae4vxL0OMf_gEfq.hQ-- Message-ID: <45B6973D.3010405@yahoo.com> Date: Tue, 23 Jan 2007 18:16:13 -0500 From: Ben Hacker Jr User-Agent: Thunderbird 1.5.0.9 (X11/20061224) MIME-Version: 1.0 To: Stable FBSD , questions FBSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Audio (Record) not functioning... (record interrupt timeout) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 23:16:16 -0000 Any help will be Greatly appreciated! I currently believe this is a problem with the "snd_t4dwave" driver device" Please respond directly as well as to the list. Thanks! http://www.bsdforums.org/forums/showthread.php?t=45514 [HISTORY] http://www.bsdforums.org/forums/showthread.php?p=242514 [More Detail] http://lists.freebsd.org/pipermail/...rch/003877.html [Related Links] http://unix.derkeiler.com/Mailing-L...05-10/0446.html I am trying to get Skype or Vonage softphone(via wine) working on my notebook. My problem is getting the input from the mic to the application. The "mic" is working because I can talk and hear the sound via the external speakers. If (on command line mixer) I turn the "rec" and "igain" to 0 the I CAN still hear any sound I make via the mic on the attached speakers. If I turn "mic" to 0 then I cannot hear any sound I make via the mic on the attached speakers. Here is the error I am seeing on the system console: pcm0:record:0:dsp0.0: record interrupt timeout, channel dead Here are my settings: user@sony$ uname -a FreeBSD sony.family.hom 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: Tue Dec 19 16:55:50 EST 2006 root@sony.family.hom :/usr/obj/usr/src/sys/SONY01 i386 user@sony$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0x1800 irq 9 kld snd_t4dwave (4p/1r/4v channels duplex default) user@sony$ dmesg | grep pcm pcm0: port 0x1800-0x18ff mem 0xe8100000-0xe8100fff at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pcm0:record:0:dsp0.0: record interrupt timeout, channel dead pcm0:record:0:dsp0.0: record interrupt timeout, channel dead user@sony$ sysctl hw.snd hw.snd.report_soft_formats: 1 hw.snd.targetirqrate: 32 hw.snd.verbose: 1 hw.snd.maxautovchans: 4 hw.snd.unit: 0 hw.snd.pcm0.buffersize: 4096 hw.snd.pcm0.vchans: 4 -- Ben Network Systems Administrator strbenjr {at} yahoo.com -- -- -- http://www.coeba.org http://www.cbsnews.com/sections/i_video/main500251.shtml?id=1419445n From owner-freebsd-stable@FreeBSD.ORG Tue Jan 23 23:50:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA9ED16A400 for ; Tue, 23 Jan 2007 23:50:56 +0000 (UTC) (envelope-from admin@truthsolo.net) Received: from twu.net (bilbo.twu.net [64.246.24.15]) by mx1.freebsd.org (Postfix) with ESMTP id 95D8613C4D0 for ; Tue, 23 Jan 2007 23:50:56 +0000 (UTC) (envelope-from admin@truthsolo.net) Received: from [192.168.123.108] (197-76.126-70.tampabay.res.rr.com [70.126.76.197]) (authenticated bits=0) by twu.net (8.12.9/8.12.9) with ESMTP id l0NMu8ki017409; Tue, 23 Jan 2007 17:56:08 -0500 Message-ID: <45B691C7.4030702@truthsolo.net> Date: Tue, 23 Jan 2007 17:52:55 -0500 From: Rob Dosogne User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Matthew Herzog References: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> In-Reply-To: <7cf39bb60701231201o4330cf1an8fa891a0086e48a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: php apache2 config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 23:50:56 -0000 Try commenting out the line for 'doc_root' in your php.ini Matthew Herzog wrote: > When I load a file named php4.info I can see all my php build information. > > If I change that same file's name to phpinfo.php, I get a "premature > end of script headers" > error. The file contains this text only: > > phpinfo(); > ?> > > and is owned by apache. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > cheers, -- Rob Dosogne Systems Administrator http://www.truthsolo.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 00:00:35 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3CC716A46E; Wed, 24 Jan 2007 00:00:35 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from abeyance.cryptomonkeys.com (abeyance.cryptomonkeys.com [67.42.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 32B3713C428; Wed, 24 Jan 2007 00:00:24 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from localhost (SJC-Office-NAT-236.Mail-Abuse.ORG [168.61.10.236]) (authenticated bits=0) by abeyance.cryptomonkeys.com (8.13.8+Sun/8.13.8) with ESMTP id l0NNo36p014781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 15:50:10 -0800 (PST) Date: Tue, 23 Jan 2007 15:50:05 -0800 From: Louis Kowolowski To: Jack Vogel Message-ID: <20070123235004.GF1504@cryptomonkeys.com> Mail-Followup-To: Jack Vogel , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Ow488MNN9B9o/ov" Content-Disposition: inline In-Reply-To: <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com> User-Agent: TV Remote 3.2b X-Disclaimer: WARNING: May contain scarcasm! X-Header: "WARNING: POLITICALLY INCORRECT AREA All P.C. Personnel entering these premises will encounter gravely offensive behavior and opinions. (SEC4623. Ministry of political incorrection security act of 1995) RAMPANT INSENSITIVITY AUTHORIZED" X-GPG-Fingerprint: 7A77 80FD 3F4D 995E A807 A218 664D 2BEA 8024 37B6 X-GPG-Key: http://www.cryptomonkeys.com/~louisk/pgp.html Organization: Hopelessly Disorganized Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 00:00:35 -0000 --1Ow488MNN9B9o/ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote: > On 1/22/07, Jack Vogel wrote: > >On 1/22/07, Gleb Smirnoff wrote: > >> Jack, > >> > >> On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > >> J> >> Since this was just seen, and the patch below validated as worki= ng=20 > >I > >> J> >wanted > >> J> >> to send general email to capture this: > >> J> >> > >> J> >> The Lenovo X60 can have issues with long ping times, this is a= =20 > >KNOWN > >> J> >> hardware problem, and Intel is working with IBM/Lenovo, a final= =20 > >'fix' has > >> J> >> not been decided on yet. Nevertheless, the patch below will work= ,=20 > >but > >> J> >> I do not want to check it in as its still temporary. > >> J> >> > >> J> >> Address questions to me, > >> J> > > >> J> >Okay, I have a question. Could you elaborate on just what the=20 > >problem is? > >> J> >(I mean, since it's KNOWN and all...) I'm just having a hard time= =20 > >figuring > >> J> >out what problem could possibly be fixed by setting the RX interru= pt > >> J> >delay timer to a non-zero value (especially since elsewhere in the= =20 > >em(4) > >> J> >source it says that doing so is a Bad Thing (tm)). > >> J> > >> J> saying its known to be a problem doesnt mean its cause is known :) > >> J> They discovered that setting this eliminated the problem, but we > >> J> immediately pointed out that this is, as you pointed out, a Bad > >> J> Thing on other hardware, so the investigation continues, there is > >> J> always a communication lag on these kind of things, so I dont know > >> J> if it has been resolved yet or not. > >> J> > >> J> I just dont think this patch will become the final way to solve thi= s, > >> J> but we shall see :) > >> > >> Good to know that there is progress on this. Thanks! I will try the pa= tch > >> on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > >> is present on any Lenovo notebook with 82573 NIC. > >> > >> Can you please acknowledge that another bug with Lenovo + em(4) is=20 > >known? I > >> mean the problem, that em(4) isn't initialized properly on kernel boot= ,=20 > >if > >> the link is down. I have already reported this to you, and you said th= at > >> I probably have bad hardware. Since that time, I've found several simi= lar > >> reports about Lenovo notebooks and em(4) driver in FreeBSD. > > > >Hey Gleb, > > > >Acknowledge... I can do better than that, I have a fix for this problem,= =20 > >and > >its not temporary. Here is the code change (not a patch, I'm very busy), > >its in hardware_init, should be obvious how to patch: > > > > /* Make sure we have a good EEPROM before we read from it */ > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > /* > > ** Some PCI-E parts fail the first check due to > > ** the link being in sleep state, call it again, > > ** if it fails a second time its a real issue. > > */ > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > device_printf(dev, > > "The EEPROM Checksum Is Not Valid\n"); > > return (EIO); > > } > > } > > > >This is already checked into my code base at Intel, I've just been too > >busy to do anything with it, be my guest if you wish to check it in after > >testing... > > > >Cheers, > > > >Jack > > >=20 > LOL, opps, I just realized, this code reflects the new shared code > that I am in the process of releasing, in order for this to work in > 6.2 change 'e1000_validate_nvm_checksum' to > 'em_validate_eeprom_checksum' and all should be clear :) >=20 This worked for me. (hoping it will get committed to -STABLE soonish) --=20 Louis Kowolowski KE7BAX louisk@cryptomonkeys.com Cryptomonkeys: http://www.cryptomonkeys.com/~louisk Warning: Do not point laser at remaining eye! --1Ow488MNN9B9o/ov Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtp8sZk0r6oAkN7YRAt81AJ0aIkaFqp8wVDq2xEMeSR9jyjT66QCfXXoC 4+nUzLdBURjLtxuCOD1FEkM= =voHN -----END PGP SIGNATURE----- --1Ow488MNN9B9o/ov-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 01:46:58 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDE0516A407 for ; Wed, 24 Jan 2007 01:46:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 5863013C461 for ; Wed, 24 Jan 2007 01:46:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so426786nfc for ; Tue, 23 Jan 2007 17:46:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BfnBouBmKDf+hwb1WtcIbSphbnr4AsHUuXtragpKMltcXxGLjlKOHaVwTJxR1mwniKPsx8rfsG2kSGC1GxIknp+UHjlI12RPuQ3kvtpH47A9muFy0loh7YG8KQJsdK2NN+Amj1CXMJUHa+1u+1hvV+HT+T26yljVQGzFUiE2y+w= Received: by 10.82.118.2 with SMTP id q2mr46409buc.1169603216749; Tue, 23 Jan 2007 17:46:56 -0800 (PST) Received: by 10.82.127.12 with HTTP; Tue, 23 Jan 2007 17:46:51 -0800 (PST) Message-ID: <2a41acea0701231746p5706bda4vb54cb0c83b809e1b@mail.gmail.com> Date: Tue, 23 Jan 2007 17:46:51 -0800 From: "Jack Vogel" To: "Jack Vogel" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <20070123235004.GF1504@cryptomonkeys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com> <20070123235004.GF1504@cryptomonkeys.com> Cc: Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 01:46:58 -0000 On 1/23/07, Louis Kowolowski wrote: > On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote: > > On 1/22/07, Jack Vogel wrote: > > >On 1/22/07, Gleb Smirnoff wrote: > > >> Jack, > > >> > > >> On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > > >> J> >> Since this was just seen, and the patch below validated as working > > >I > > >> J> >wanted > > >> J> >> to send general email to capture this: > > >> J> >> > > >> J> >> The Lenovo X60 can have issues with long ping times, this is a > > >KNOWN > > >> J> >> hardware problem, and Intel is working with IBM/Lenovo, a final > > >'fix' has > > >> J> >> not been decided on yet. Nevertheless, the patch below will work, > > >but > > >> J> >> I do not want to check it in as its still temporary. > > >> J> >> > > >> J> >> Address questions to me, > > >> J> > > > >> J> >Okay, I have a question. Could you elaborate on just what the > > >problem is? > > >> J> >(I mean, since it's KNOWN and all...) I'm just having a hard time > > >figuring > > >> J> >out what problem could possibly be fixed by setting the RX interrupt > > >> J> >delay timer to a non-zero value (especially since elsewhere in the > > >em(4) > > >> J> >source it says that doing so is a Bad Thing (tm)). > > >> J> > > >> J> saying its known to be a problem doesnt mean its cause is known :) > > >> J> They discovered that setting this eliminated the problem, but we > > >> J> immediately pointed out that this is, as you pointed out, a Bad > > >> J> Thing on other hardware, so the investigation continues, there is > > >> J> always a communication lag on these kind of things, so I dont know > > >> J> if it has been resolved yet or not. > > >> J> > > >> J> I just dont think this patch will become the final way to solve this, > > >> J> but we shall see :) > > >> > > >> Good to know that there is progress on this. Thanks! I will try the patch > > >> on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > > >> is present on any Lenovo notebook with 82573 NIC. > > >> > > >> Can you please acknowledge that another bug with Lenovo + em(4) is > > >known? I > > >> mean the problem, that em(4) isn't initialized properly on kernel boot, > > >if > > >> the link is down. I have already reported this to you, and you said that > > >> I probably have bad hardware. Since that time, I've found several similar > > >> reports about Lenovo notebooks and em(4) driver in FreeBSD. > > > > > >Hey Gleb, > > > > > >Acknowledge... I can do better than that, I have a fix for this problem, > > >and > > >its not temporary. Here is the code change (not a patch, I'm very busy), > > >its in hardware_init, should be obvious how to patch: > > > > > > /* Make sure we have a good EEPROM before we read from it */ > > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > > /* > > > ** Some PCI-E parts fail the first check due to > > > ** the link being in sleep state, call it again, > > > ** if it fails a second time its a real issue. > > > */ > > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > > device_printf(dev, > > > "The EEPROM Checksum Is Not Valid\n"); > > > return (EIO); > > > } > > > } > > > > > >This is already checked into my code base at Intel, I've just been too > > >busy to do anything with it, be my guest if you wish to check it in after > > >testing... > > > > > >Cheers, > > > > > >Jack > > > > > > > LOL, opps, I just realized, this code reflects the new shared code > > that I am in the process of releasing, in order for this to work in > > 6.2 change 'e1000_validate_nvm_checksum' to > > 'em_validate_eeprom_checksum' and all should be clear :) > > > This worked for me. > > (hoping it will get committed to -STABLE soonish) OK, hint taken, I'll try and get that committed asap. Jack From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 03:14:49 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D06D16A401 for ; Wed, 24 Jan 2007 03:14:49 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD4D13C428 for ; Wed, 24 Jan 2007 03:14:48 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-24-27-51-69.austin.res.rr.com [24.27.51.69]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 47244305-1817707 for ; Tue, 23 Jan 2007 21:14:48 -0600 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.8/8.13.8) with ESMTP id l0O3Elwx022431 for ; Tue, 23 Jan 2007 21:14:47 -0600 (CST) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.8/8.13.8/Submit) id l0O3ElRE022430 for freebsd-stable@freebsd.org; Tue, 23 Jan 2007 21:14:47 -0600 (CST) (envelope-from brucegb) Date: Tue, 23 Jan 2007 21:14:47 -0600 From: Bruce Burden To: freebsd-stable@freebsd.org Message-ID: <20070124031447.GI89970@tigerfish2.my.domain> References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <72347C40-81E3-4E4D-9F27-3058B73359B3@khera.org> <45B1BF6E.7090704@delphij.net> <20070123050907.GD89970@tigerfish2.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 03:14:49 -0000 On Tue, Jan 23, 2007 at 05:19:11PM -0500, Vivek Khera wrote: > > On Jan 23, 2007, at 12:09 AM, Bruce Burden wrote: > > > Sigh. Okay, thank you for the responses. I think I will > > go with "Plan 'C'", and find a PCI-X LSI MegaRAID card. I think > > there is some hope the megamgr port will work with them. > > My preferred card is the 320-2X dual channel card. It is wicked > awesome fast and the megamgr program does work with them. > Unfortunately, the Sun X4100 boxes have low-profile slots, and the > only option for RAID cards is the Adaptec 2230SLP for dual channels. > This is why I use the adaptec cards :-( > Vivek, Excellent info, thank you! As it happens, I do have a 320-2x on its way to me. I am replacing an Adaptec 3210S. I had originally planned to use a 2130S, but the lack of a manager put me off (not to mention just getting this Tyan Thunder K8WE running...). I did try a 320-2e, but the board did not enter BIOS when the card was in slot 1. Tyan has not responded as to whether this is a good thing or not, hence the waiting for the 320-2x... Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 07:10:25 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ADB516A401 for ; Wed, 24 Jan 2007 07:10:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 08D2C13C457 for ; Wed, 24 Jan 2007 07:10:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0O7ALFU001183; Wed, 24 Jan 2007 18:10:21 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0O7ALQf001182; Wed, 24 Jan 2007 18:10:21 +1100 (EST) (envelope-from peter) Date: Wed, 24 Jan 2007 18:10:21 +1100 From: Peter Jeremy To: "Andresen, Jason R." Message-ID: <20070124071021.GG874@turion.vk2pj.dyndns.org> References: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: Dummynet and simulating random delay X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 07:10:25 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: >I have a project that requires me to simulate a link with varying but >well defined delay. The link is guarenteed to deliver packets in >order, so I wish to maintain that behavior with Dummynet. I don't think dummynet can do this in its current form. Based on a quick look at the source, the packet delivery time is set to the current time plus the current delay when the packet arrives (see sys/netinet/ip_dummynet.c:move_pkt(). This means that changing the delay will not affect existing queued packets. Changing dummynet to allow variable delays whilst maintaining packet order is not immediately trivial. The only option I can see would be to change the dummynet curr_time (net.inet.ip.dummynet.curr_time) to increment at variable rate instead of one count per tick. You would probably need to do some fiddling to provide anything better than very coarse delay variation. --=20 Peter Jeremy --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtwZd/opHv/APuIcRAuRZAJkBcKMagvb62xrj0wAKKSwgFJQj3ACbB8aQ v9HNayCZ+N3XKXpVhCG0f6I= =fkgJ -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 08:12:31 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 794C116A401 for ; Wed, 24 Jan 2007 08:12:31 +0000 (UTC) (envelope-from conrad.burger@mxit.com) Received: from smtp.swistgroup.com (smtp.swisttech.com [196.211.145.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA4013C4B8 for ; Wed, 24 Jan 2007 08:12:22 +0000 (UTC) (envelope-from conrad.burger@mxit.com) Received: from localhost (localhost [127.0.0.1]) by smtp.swistgroup.com (Postfix) with ESMTP id 9399AB68CA for ; Wed, 24 Jan 2007 09:39:28 +0200 (SAST) Received: from smtp.swistgroup.com ([127.0.0.1]) by localhost (fw-swist [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31096-04 for ; Wed, 24 Jan 2007 09:39:27 +0200 (SAST) Received: from timon.swistgroup.com (unknown [172.16.1.30]) by smtp.swistgroup.com (Postfix) with ESMTP id C71FEA4ED3 for ; Wed, 24 Jan 2007 09:39:27 +0200 (SAST) Received: from mailnull by timon.swistgroup.com with local (Exim 4.52 (FreeBSD)) id 1H9co1-000Ffg-Hx for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 09:44:29 +0200 Received: from mail.swistgroup.com ([172.16.1.6] helo=hermes.swistgroup.com) by timon.swistgroup.com with esmtp (Exim 4.52 (FreeBSD)) id 1H9co1-000FfF-EC; Wed, 24 Jan 2007 09:44:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Jan 2007 09:46:19 +0200 Message-ID: <45FBF1D2998C93429047415BE8091CC8283236@HERMES.swistgroup.com> In-Reply-To: <45FBF1D2998C93429047415BE8091CC81F3995@HERMES.swistgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) Thread-Index: Acc5PK+5ZwngBAC/Sb68FJWUaGo1wgAYpSLQAXrI7gA= From: "Conrad Burger" To: "Conrad Burger" , "Morten A. Middelthon" , "David Christensen" X-disclaimer: Legalsentry X-Virus-Scanned: by amavisd-new at example.com Cc: freebsd-stable@freebsd.org, Roar Pettersen Subject: RE: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 08:12:31 -0000 ******************************************************************* Click here to view our e-mail legal notice: http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 ******************************************************************* Any progress on the BCE serdes driver? -----Original Message----- From: owner-freebsd-stable@freebsd.org = [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Conrad Burger Sent: 16 January 2007 08:53 PM To: Morten A. Middelthon; David Christensen Cc: freebsd-stable@freebsd.org; Roar Pettersen Subject: RE: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) ******************************************************************* Click here to view our e-mail legal notice:=20 http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 ******************************************************************* If you have an alpha or beta version of the bce driver that supports = serdes, please let me know and I'll start testing right away! Regards=20 Conrad=20 -----Original Message----- From: owner-freebsd-stable@freebsd.org = [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Morten A. Middelthon Sent: 16 January 2007 08:56 AM To: David Christensen Cc: freebsd-stable@freebsd.org; Roar Pettersen Subject: Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) On Mon, Jan 15, 2007 at 09:16:16AM -0800, David Christensen wrote: > > Hello Dave ! > >=20 > > >Wed Nov 1 18:54:19 UTC 2006 > > > > > >Yes, the Linux bnx2 driver does support SerDes. I don't have the > > >bandwidth to tackle this feature until after the first of the year, > > >though a few other people have also considered looking into adding > > >the support. > >=20 > >=20 > > Any news or status report regarding support for this new=20 > > network interface=20 > > in FreeBSD ? >=20 > I've copied Doug White who is working to add SerDes support to bce. I'm _really_ looking forward to getting SerDes support in the bce-driver = :) --=20 Morten A. Middelthon Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 08:53:08 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EC2316A48F for ; Wed, 24 Jan 2007 08:53:08 +0000 (UTC) (envelope-from cyberlab@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7F85313C4C3 for ; Wed, 24 Jan 2007 08:53:07 +0000 (UTC) (envelope-from cyberlab@gmx.de) Received: (qmail 3932 invoked by uid 0); 24 Jan 2007 08:26:26 -0000 Received: from 62.225.62.67 by www073.gmx.net with HTTP; Wed, 24 Jan 2007 09:26:26 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Jan 2007 09:26:26 +0100 From: "Jost Menke" In-Reply-To: <45B6973D.3010405@yahoo.com> Message-ID: <20070124082626.44750@gmx.net> MIME-Version: 1.0 References: <45B6973D.3010405@yahoo.com> To: Ben Hacker Jr , freebsd-questions@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Authenticated: #1026516 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Audio (Record) not functioning... (record interrupt timeout) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 08:53:08 -0000 -------- Original-Nachricht -------- Datum: Tue, 23 Jan 2007 18:16:13 -0500 Von: Ben Hacker Jr An: Stable FBSD , questions FBSD Betreff: Audio (Record) not functioning... (record interrupt timeout) > Any help will be Greatly appreciated! I currently believe this is a > problem with the "snd_t4dwave" driver device" Hi Ben, I am experiencing similar problems with the snd_t4dwave driver, but with playback. Playback works for a few seconds, then it stops and the kernel also reports an interrupt timeout. Didn't find a solution yet I'm afraid. Regards, Jost Menke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 10:34:52 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE85E16A47B for ; Wed, 24 Jan 2007 10:34:52 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id 37D7E13C4DB for ; Wed, 24 Jan 2007 10:34:52 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0O9vfsD027275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jan 2007 10:57:41 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0O9vfVT027274 for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 10:57:41 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Wed, 24 Jan 2007 10:57:41 +0100 Message-ID: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> Date: Wed, 24 Jan 2007 10:57:41 +0100 From: Robin Gruyters To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 10:34:52 -0000 On 13 Dec 2006, at 19:30, Greg Eden wrote: > On 13 Dec 2006, at 09:18, Gleb Smirnoff wrote: > > > D> > Greg Eden wrote: > > D> >> Hello > > D> >> > > D> >> I recently updated two production servers from 5.3 to 6.1 via > > D> >> cvsup and > > D> >> buildworld. Since the upgrade I've seen an increase in the =20 > > number of > > D> >> Input packet errors reported on the bge cards in on both boxes. > > > > In 5.3-RELEASE the bge(4) driver did not read the error count from the > > chip at all. So errors were not accounted. > > Many thanks for clearing up the mystery.... > I have the same problem here. At the moment I only have two servers =20 upgraded from FreeBSD 5.4R to FreeBSD 6.1R and one to FreeBSD 6.2R. [FreeBSD 6.1R] Copyright (c) 1992-2006 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 6.1-RELEASE-p10 #1: Tue Oct 24 10:44:15 CEST 2006 root@server.yirdis.net:/data/obj/data/src_6_1/sys/YIRDIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.14-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 =20 Features=3D0xbfebfbff Features2=3D0x649d> AMD Features=3D0x20000000 Logical CPUs per core: 2 real memory =3D 2147430400 (2047 MB) avail memory =3D 2100654080 (2003 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci3: on pcib2 bge0: mem =20 0xfdef0000-0xfdefffff irq 25 at device 1.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:d7:bb:99 bge1: mem =20 0xfdee0000-0xfdeeffff irq 26 at device 1.1 on pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:d7:bb:98 pcib3: at device 0.2 on pci2 pci4: on pcib3 ciss0: port 0x4000-0x40ff mem =20 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 51 at device 3.0 on pci4 ciss0: [GIANT-LOCKED] pcib4: at device 6.0 on pci0 pci5: on pcib4 pcib5: at device 0.0 on pci5 pci6: on pcib5 pcib6: at device 0.2 on pci5 pci10: on pcib6 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib7: at device 30.0 on pci0 pci1: on pcib7 pci1: at device 3.0 (no driver attached) pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port =20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] pmtimer0 on isa0 orm0: at iomem =20 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xee000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 sa0 at ciss0 bus 33 target 5 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 135.168MB/s transfers da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) da1 at ciss0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 135.168MB/s transfers da1: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) da2 at ciss0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-0 device da2: 135.168MB/s transfers da2: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a bge1: link state changed to UP bge0: link state changed to UP [/FreeBSD 6.1R] [FreeBSD 6.2R] Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #1: Mon Jan 15 15:34:19 CET 2007 root@server.yirdis.net:/data/obj/data/src_6_2/sys/YIRDIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 =20 Features=3D0xbfebfbff Features2=3D0x641d> AMD Features=3D0x20000000 Logical CPUs per core: 2 real memory =3D 2147430400 (2047 MB) avail memory =3D 2100547584 (2003 MB) ACPI APIC Table: Security auditing service present BSM auditing present ioapic1: Changing APIC ID to 9 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci13: on pcib1 pcib2: at device 4.0 on pci0 pci6: on pcib2 pcib3: at device 0.0 on pci6 pci7: on pcib3 pcib4: at device 0.2 on pci6 pci10: on pcib4 pcib5: at device 1.0 on pci10 pci11: on pcib5 ste0: port 0x5000-0x507f irq 72 at =20 device 4.0 on pci11 miibus0: on ste0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste0: Ethernet address: 00:0d:88:fc:c8:cc ste1: port 0x5080-0x50ff irq 73 at =20 device 5.0 on pci11 miibus1: on ste1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste1: Ethernet address: 00:0d:88:fc:c8:cd ste2: port 0x5400-0x547f irq 74 at =20 device 6.0 on pci11 miibus2: on ste2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste2: Ethernet address: 00:0d:88:fc:c8:ce ste3: port 0x5480-0x54ff irq 75 at =20 device 7.0 on pci11 miibus3: on ste3 ukphy3: on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ste3: Ethernet address: 00:0d:88:fc:c8:cf pcib6: at device 6.0 on pci0 pci3: on pcib6 pcib7: at device 28.0 on pci0 pci2: on pcib7 ciss0: port 0x4000-0x40ff mem =20 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 24 at device 1.0 on pci2 ciss0: [GIANT-LOCKED] bge0: mem =20 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 miibus4: on bge0 brgphy0: on miibus4 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:94:ed:12 bge1: mem =20 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 miibus5: on bge1 brgphy1: on miibus5 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:94:ed:11 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no =20 driver attached) pci0: at device 29.7 (no driver attached) pcib8: at device 30.0 on pci0 pci1: on pcib8 pci1: at device 3.0 (no driver attached) pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port =20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 18 at device 31.1 =20 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem =20 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 3000124702 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) Trying to mount root from ufs:/dev/da0s1a Accounting enabled [/FreeBSD 6.2R] And here is the netstat -ni output from our development server: [netstat -ni] Name Mtu Ipkts Ierrs Opkts Oerrs Coll ste0* 1500 0 0 0 0 0 ste1* 1500 0 0 0 0 0 ste2* 1500 0 0 0 0 0 ste3* 1500 0 0 0 0 0 bge0 1500 9866912 2114443 18835209 0 0 bge0 1500 2004841 - 18833483 - - bge0 1500 1723393 - 1719554 - - bge0 1500 82 - 66 - - bge0 1500 19036813 - 14796159 - - bge0 1500 38709278 - 35167554 - - bge0 1500 0 - 0 - - bge0 1500 621 - 0 - - bge0 1500 1716 - 0 - - bge0 1500 184 - 0 - - bge0 1500 52881 - 2336 - - bge1* 1500 0 0 0 0 0 pflog 33208 0 0 0 0 lo0 16384 0 51692624 0 0 lo0 16384 6611 - 6611 - - [...] Is there a fix for it already, or maybe a workaround? Regards, Robin Gruyters Network and Security Engineer Yirdis B.V. I: http://yirdis.com P: +31 (0)36 5300394 F: +31 (0)36 5489119 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 11:27:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B53D16A402 for ; Wed, 24 Jan 2007 11:27:15 +0000 (UTC) (envelope-from admin@trunkcom.ru) Received: from mail.trunkcom.ru (mail.trunkcom.ru [213.80.150.5]) by mx1.freebsd.org (Postfix) with SMTP id 3A5A313C428 for ; Wed, 24 Jan 2007 11:27:13 +0000 (UTC) (envelope-from admin@trunkcom.ru) Received: (qmail 7769 invoked by uid 1005); 24 Jan 2007 11:00:32 -0000 Received: from 192.168.223.7 by nwtm.trunkcom.ru (envelope-from , uid 98) with qmail-scanner-1.25-st-qms (clamdscan: 0.88.2/1507. spamassassin: 3.1.1. perlscan: 1.25-st-qms. Clear:RC:0(192.168.223.7):SA:0(-2.7/5.0):. Processed in 12.853546 secs); 24 Jan 2007 11:00:32 -0000 X-Spam-Status: No, hits=-2.7 required=5.0 Small-Antivirus-trin-Mail-From: admin@trunkcom.ru via nwtm.trunkcom.ru Small-Antivirus-trin: 1.25-st-qms (Clear:RC:0(192.168.223.7):SA:0(-2.7/5.0):. Processed in 12.853546 secs Process 7728) Received: from unknown (HELO darvins) (admin@192.168.223.7) by mail.trunkcom.ru with SMTP; 24 Jan 2007 11:00:19 -0000 From: "Rinat K. Nugaev" Organization: TRUNKNET To: freebsd-stable@freebsd.org Date: Wed, 24 Jan 2007 14:00:16 +0300 User-Agent: KMail/1.9.4 References: <20070124103503.E3B6516A655@hub.freebsd.org> In-Reply-To: <20070124103503.E3B6516A655@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701241400.16980.admin@trunkcom.ru> Subject: Re: freebsd-stable Digest, Vol 190, Issue 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 11:27:15 -0000 =D0=92 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B8 =D0=BE=D1=82 = 24 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2007 13:35 freebsd-stable-request@f= reebsd.org=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(a): > On 1/23/07, Guy Helmer wrote: > > Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > > motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > > http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.= cf > >m) hanging after printing the "Waiting 5 seconds for SCSI devices to > > settle" message. =C2=A0The hang doesn't always happen - sometimes we ha= ve to > > go through several reboot cycles for it to happen - but sometimes it > > happens with every reboot. =C2=A0For those who would suggest that this = happens > > because I'm using Seagate drives, it happens even if we totally remove > > the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot > > from a SATA disk. =C2=A0Using FreeBSD 6.1, the Intel gigabit ethernet N= ICs > > aren't found but the hang doesn't occur. 1.Boot in safe_mode 2.Rebuild kernel with SMP (options SMP) 3.Be Happy. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 11:55:17 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3607216A401; Wed, 24 Jan 2007 11:55:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8405113C442; Wed, 24 Jan 2007 11:55:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.64]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.12) with ESMTPA id 393087190; Wed, 24 Jan 2007 12:55:14 +0100 From: Hans Petter Selasky To: Ed Schouten Date: Wed, 24 Jan 2007 12:54:51 +0100 User-Agent: KMail/1.9.5 References: <20070124113858.GG64263@hoeg.nl> In-Reply-To: <20070124113858.GG64263@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701241254.51900.hselasky@c2i.net> Cc: FreeBSD Hackers , freebsd-stable@freebsd.org, Pietro Cerutti Subject: Re: atacontrol kernel crash (atausb?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 11:55:17 -0000 On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > Hello, > > * Pietro Cerutti wrote: > > On 1/15/07, Hans Petter Selasky wrote: > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > Everything works nice with umass. It creates the da0 device node. > > It just shows up these errors, as it always did... > > GEOM: new disk da0 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > da0: Serial Number > > da0: 40.000MB/s transfers > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > I had these messages with two other devices before, an MP3 player and a > USB floppy drive. I fixed these errors by adding a quirk to > /sys/cam/scsi/scsi_da.c. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 Instead of having all these quirks, isn't it possible that the SCSI layer can auto-probe this? --HPS From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 12:03:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57AAD16A408; Wed, 24 Jan 2007 12:03:56 +0000 (UTC) (envelope-from nixx@freebsd.se) Received: from thebox.our-own.net (our-own.net [72.36.210.66]) by mx1.freebsd.org (Postfix) with ESMTP id 34DC713C4A6; Wed, 24 Jan 2007 12:03:56 +0000 (UTC) (envelope-from nixx@freebsd.se) Received: from thebox.our-own.net (localhost.localdomain [127.0.0.1]) by aq.our-own.net (Postfix) with ESMTP id 1518263883D; Wed, 24 Jan 2007 05:31:56 -0600 (CST) X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on thebox.our-own.net X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.5 tests=AWL,DK_POLICY_SIGNSOME autolearn=ham version=3.1.7 Received: from [127.0.0.1] (unknown [87.253.82.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bq.our-own.net (Postfix) with ESMTP id 8446763883A; Wed, 24 Jan 2007 05:31:52 -0600 (CST) Message-ID: <45B743A5.8080103@freebsd.se> Date: Wed, 24 Jan 2007 12:31:49 +0100 From: Nikolaj Farrell User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Per olof Ljungmark References: <45B39891.4030207@intersonic.se> In-Reply-To: <45B39891.4030207@intersonic.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Glenn Becker , freebsd-questions@freebsd.org Subject: Re: Firefox keeps beeping at me ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 12:03:56 -0000 Per olof Ljungmark skrev: > Glenn Becker wrote: >> >> All - >> >> I've been away from FreeBSD for some time and have been updating my >> installation, getting used to the ways of portupgrade, etc. >> >> Have noticed that Firefox keeps emitting what sound like console >> beeps - I haven't established much of a pattern for these though it >> always happens when I close the app. >> >> Is there a way to kill these? Apologies in advance if this is a dopey >> question. Obviously more an annoyance than anything. > > perhaps -questions is more appropriate... > > Anyway, that makes two of us - mine beeps too - when sending and > reading mails. No idea why though, sorry. > > Anyone? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" The beeping can be avoided by recompiling without the debug option. (I am clueless on how to disable it if debug is on though). Sorry for the crosspost-reply. /Nikolaj From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 12:12:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9E6E16A400 for ; Wed, 24 Jan 2007 12:12:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id ACEC513C4D3 for ; Wed, 24 Jan 2007 12:12:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 4A6CF1CD4A; Wed, 24 Jan 2007 12:38:58 +0100 (CET) Date: Wed, 24 Jan 2007 12:38:58 +0100 From: Ed Schouten To: Pietro Cerutti Message-ID: <20070124113858.GG64263@hoeg.nl> References: <200701151555.07155.hselasky@c2i.net> <200701151716.20094.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z4ZSWl3cPHKQyRxO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Hackers , freebsd-stable@freebsd.org, Hans Petter Selasky Subject: Re: atacontrol kernel crash (atausb?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 12:12:10 -0000 --Z4ZSWl3cPHKQyRxO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, * Pietro Cerutti wrote: > On 1/15/07, Hans Petter Selasky wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > Everything works nice with umass. It creates the da0 device node. > It just shows up these errors, as it always did... > GEOM: new disk da0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > da0: Serial Number > da0: 40.000MB/s transfers > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > (da0:umass-sim0:0:0:0): Synchronize cache failed, status =3D=3D 0x4, scsi > status =3D=3D 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status =3D=3D 0x4, scsi > status =3D=3D 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status =3D=3D 0x4, scsi > status =3D=3D 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status =3D=3D 0x4, scsi > status =3D=3D 0x0 I had these messages with two other devices before, an MP3 player and a USB floppy drive. I fixed these errors by adding a quirk to /sys/cam/scsi/scsi_da.c. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D97174 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D107101 --=20 Ed Schouten WWW: http://g-rave.nl/ --Z4ZSWl3cPHKQyRxO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFt0VS52SDGA2eCwURArAtAJ4hYPnwSLUzDnHQsFLqjrkLMXwHwACfVPRs UhQ6a/iZX4wvFuWzyQHH6rg= =Ywri -----END PGP SIGNATURE----- --Z4ZSWl3cPHKQyRxO-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 12:15:10 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9823B16A406 for ; Wed, 24 Jan 2007 12:15:10 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.freebsd.org (Postfix) with ESMTP id 34EF813C467 for ; Wed, 24 Jan 2007 12:15:10 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id l0OCF5fo024597; Wed, 24 Jan 2007 12:15:05 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id l0OCEw7D059698; Wed, 24 Jan 2007 12:15:04 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id l0OCEve4059697; Wed, 24 Jan 2007 12:14:57 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Jack Vogel In-Reply-To: <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 Jan 2007 12:14:57 +0000 Message-Id: <1169640897.59181.20.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Bill Paul , jon.otterholm@ide.resurscentrum.se, Gleb Smirnoff , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 12:15:10 -0000 On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote: > On 1/22/07, Gleb Smirnoff wrote: > > Jack, > > > > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > > J> >> Since this was just seen, and the patch below validated as working I > > J> >wanted > > J> >> to send general email to capture this: > > J> >> > > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN > > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > > J> >> not been decided on yet. Nevertheless, the patch below will work, but > > J> >> I do not want to check it in as its still temporary. > > J> >> > > J> >> Address questions to me, > > J> > > > J> >Okay, I have a question. Could you elaborate on just what the problem is? > > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time figuring > > J> >out what problem could possibly be fixed by setting the RX interrupt > > J> >delay timer to a non-zero value (especially since elsewhere in the em(4) > > J> >source it says that doing so is a Bad Thing (tm)). > > J> > > J> saying its known to be a problem doesnt mean its cause is known :) > > J> They discovered that setting this eliminated the problem, but we > > J> immediately pointed out that this is, as you pointed out, a Bad > > J> Thing on other hardware, so the investigation continues, there is > > J> always a communication lag on these kind of things, so I dont know > > J> if it has been resolved yet or not. > > J> > > J> I just dont think this patch will become the final way to solve this, > > J> but we shall see :) > > > > Good to know that there is progress on this. Thanks! I will try the patch > > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > > is present on any Lenovo notebook with 82573 NIC. > > > > Can you please acknowledge that another bug with Lenovo + em(4) is known? I > > mean the problem, that em(4) isn't initialized properly on kernel boot, if > > the link is down. I have already reported this to you, and you said that > > I probably have bad hardware. Since that time, I've found several similar > > reports about Lenovo notebooks and em(4) driver in FreeBSD. > > Hey Gleb, > > Acknowledge... I can do better than that, I have a fix for this problem, and > its not temporary. Here is the code change (not a patch, I'm very busy), > its in hardware_init, should be obvious how to patch: > > /* Make sure we have a good EEPROM before we read from it */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > /* > ** Some PCI-E parts fail the first check due to > ** the link being in sleep state, call it again, > ** if it fails a second time its a real issue. > */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > device_printf(dev, > "The EEPROM Checksum Is Not Valid\n"); > return (EIO); > } > } > > This is already checked into my code base at Intel, I've just been too > busy to do anything with it, be my guest if you wish to check it in after > testing... Just to add another datapoint - and for the archives - this also appears to fix an issue with the Toshiba Tecra M5L. The "EEPROM Checksum Is Not Valid" message would appear on boot if there was no link on the interface, although the interface would appear to work fine from then on. With this patch, the message no longer appears. I also have problems with connections to networks (only seen when connected to 10 meg half duplex hubs) with long delays on some packets (which I'm assuming is the issue that started this thread) - I haven't been able to verify yet that either patch fixes that, though. Gavin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 12:52:57 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3489516A403 for ; Wed, 24 Jan 2007 12:52:57 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.freebsd.org (Postfix) with ESMTP id EC43813C4BC for ; Wed, 24 Jan 2007 12:52:56 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id CD0AA7BA692 for ; Wed, 24 Jan 2007 13:52:55 +0100 (CET) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 49BCEB919; Wed, 24 Jan 2007 13:52:55 +0100 (CET) Date: Wed, 24 Jan 2007 13:52:55 +0100 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20070124125255.GA52851@tirith.brixandersen.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org> <45B676A2.5090009@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <45B676A2.5090009@andric.com> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 12:52:57 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 23, 2007 at 09:57:06PM +0100, Dimitry Andric wrote: > Yes. The specific line in my rc.conf is: >=20 > ipv6_ifconfig_gif0=3D"2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 1= 28" With that setup you should be able to just do: ipv6_defaultrouter=3D"2001:7b8:2ff:146::1" ipv6_ifconfig_gif0=3D"2001:7b8:2ff:146::2 prefixlen 127" I know it doesn't solve the bug, but if you just need it working... :) Regards, Brix --=20 Henrik Brix Andersen --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: GnuPG signed iD8DBQFFt1amv+Q4flTiePgRAghMAJ9zuR+iEtujBF/+05ySKhb0S+TrpACeJDPO qcmy0WhSp+mQ8ipGDeEDzSo= =ojDe -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 14:17:39 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 025F416A402 for ; Wed, 24 Jan 2007 14:17:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by mx1.freebsd.org (Postfix) with ESMTP id C181613C4C6 for ; Wed, 24 Jan 2007 14:17:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (sccrmhc14) with ESMTP id <2007012414173701400hgut8e>; Wed, 24 Jan 2007 14:17:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6B7B71FA037; Wed, 24 Jan 2007 06:17:37 -0800 (PST) Date: Wed, 24 Jan 2007 06:17:37 -0800 From: Jeremy Chadwick To: Robin Gruyters Message-ID: <20070124141737.GA7772@icarus.home.lan> Mail-Followup-To: Robin Gruyters , freebsd-stable@freebsd.org References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 14:17:39 -0000 On Wed, Jan 24, 2007 at 10:57:41AM +0100, Robin Gruyters wrote: > I have the same problem here. At the moment I only have two servers > upgraded from FreeBSD 5.4R to FreeBSD 6.1R and one to FreeBSD 6.2R. > > And here is the netstat -ni output from our development server: > > [netstat -ni] > Name Mtu Ipkts Ierrs Opkts Oerrs Coll > ste0* 1500 0 0 0 0 0 > ste1* 1500 0 0 0 0 0 > ste2* 1500 0 0 0 0 0 > ste3* 1500 0 0 0 0 0 > bge0 1500 9866912 2114443 18835209 0 0 > bge0 1500 2004841 - 18833483 - - > bge0 1500 1723393 - 1719554 - - > bge0 1500 82 - 66 - - > bge0 1500 19036813 - 14796159 - - > bge0 1500 38709278 - 35167554 - - > bge0 1500 0 - 0 - - > bge0 1500 621 - 0 - - > bge0 1500 1716 - 0 - - > bge0 1500 184 - 0 - - > bge0 1500 52881 - 2336 - - > bge1* 1500 0 0 0 0 0 > pflog 33208 0 0 0 0 > lo0 16384 0 51692624 0 0 > lo0 16384 6611 - 6611 - - > [...] > > Is there a fix for it already, or maybe a workaround? The problem was that the driver code was not properly obtaining error statistics from the Broadcom chip, thus errors _were_ (before the fix) not being calculated/accounted for. Now (after the fix) errors are being accounted for correctly. So the errors you see in your netstat output are probably real/ ccurate. I'll vote for a duplex-related problem or some naughty cabling. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 14:25:40 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2ACD316A400 for ; Wed, 24 Jan 2007 14:25:40 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAA413C4A5 for ; Wed, 24 Jan 2007 14:25:39 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0OEPbxE071251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 15:25:37 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0OEPbHN071250; Wed, 24 Jan 2007 15:25:37 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Wed, 24 Jan 2007 15:25:37 +0100 Message-ID: <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> Date: Wed, 24 Jan 2007 15:25:37 +0100 From: Robin Gruyters To: Jeremy Chadwick References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> In-Reply-To: <20070124141737.GA7772@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 14:25:40 -0000 Quoting Jeremy Chadwick : >> >> Is there a fix for it already, or maybe a workaround? > > The problem was that the driver code was not properly obtaining > error statistics from the Broadcom chip, thus errors _were_ > (before the fix) not being calculated/accounted for. Now (after > the fix) errors are being accounted for correctly. > > So the errors you see in your netstat output are probably real/ > ccurate. I'll vote for a duplex-related problem or some naughty > cabling. > Should this not be visible on the switch as well?!? Here some output from the interface on the server and from the switch (Cisco= ) [development interface] bge0: flags=3D8843 mtu 1500 options=3D1b ether 00:12:79:94:ed:12 media: Ethernet autoselect (100baseTX ) status: active [/development interface] [switch] FastEthernet0/3 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000e.84d0.de03 (bia 000e.84d0.de03) Description: development MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:02, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 179000 bits/sec, 28 packets/sec 5 minute output rate 56000 bits/sec, 24 packets/sec 22823978 packets input, 4067576147 bytes, 0 no buffer Received 13138 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 12929 multicast, 0 pause input 0 input packets with dribble condition detected 15673035 packets output, 3975127029 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out [/switch] Regards, Robin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 14:35:39 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADDA716A402 for ; Wed, 24 Jan 2007 14:35:39 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 75B2A13C4D1 for ; Wed, 24 Jan 2007 14:35:36 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (unknown [89.53.125.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id A9A9012882A for ; Wed, 24 Jan 2007 15:09:41 +0100 (CET) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 644A22E56B for ; Wed, 24 Jan 2007 15:09:30 +0100 (CET) Message-ID: <45B7689C.2060209@vwsoft.com> Date: Wed, 24 Jan 2007 15:09:32 +0100 From: Volker User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Subject: IPSEC clarifications X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 14:35:39 -0000 Hi folks, I'm wondering if someone please could clarify some IPSec specific questions to me? IPSEC_FILTERGIF: What are the consequences when enabling this if one does use IPSEC (or FAST_IPSEC) w/o any GIF tunnels? Are there any or does IPSEC_FILTERGIF only influence packet flow with gif devices? NOTES says: # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured packet filtering (ipfw, ipf). # The default is that packets coming from a tunnel are _not_ processed; # they are assumed trusted. But I've found signs in the archives even while not using gif tunnels with IPSec packets are getting filtered with FILTERGIF option. I might be wrong about this. device enc: I haven't been aware of the fact that we already have such a device. There's a man page (man 4 enc) but it's not in NOTES or GENERIC. Is the enc(4) man page correct and up to date? Shouldn't there at least be a note in NOTES somewhere around the options FAST_IPSEC line with a hint for enc(4)? Is just compiling device enc into the kernel, using options FAST_IPSEC and passing (or blocking) traffic on interface enc0 using pf rules all one has to do? IPSEC / FAST_IPSEC: What is the (say) 'official' recommended option to use? Where are the differences, what are the consequences while using one or the other? Will both do the same w/o any consequences for the admin? I'm currently in the process of checking for migration to racoon2 and need to re-check every IPSec related setup. Thanks, Volker From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 14:47:08 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5BC816A403 for ; Wed, 24 Jan 2007 14:47:07 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [192.188.162.7]) by mx1.freebsd.org (Postfix) with ESMTP id A924A13C442 for ; Wed, 24 Jan 2007 14:47:07 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0OEl7tH070601; Wed, 24 Jan 2007 08:47:07 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l0OEklRd055278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 08:46:47 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45B77158.1080607@palisadesys.com> Date: Wed, 24 Jan 2007 08:46:48 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Rinat K. Nugaev" References: <20070124103503.E3B6516A655@hub.freebsd.org> <200701241400.16980.admin@trunkcom.ru> In-Reply-To: <200701241400.16980.admin@trunkcom.ru> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Wed, 24 Jan 2007 08:46:47 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.81, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, HTML_30_40 0.37, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.21) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 14:47:08 -0000 Rinat K. Nugaev wrote: > Ð’ Ñообщении от 24 ÑÐ½Ð²Ð°Ñ€Ñ 2007 13:35 freebsd-stable-request@freebsd.org > напиÑал(a): > >> On 1/23/07, Guy Helmer wrote: >> >>> Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ >>> motherboard (dual Xeon 5130 CPUs on the Blackford chipset - >>> http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cf >>> m) hanging after printing the "Waiting 5 seconds for SCSI devices to >>> settle" message. The hang doesn't always happen - sometimes we have to >>> go through several reboot cycles for it to happen - but sometimes it >>> happens with every reboot. For those who would suggest that this happens >>> because I'm using Seagate drives, it happens even if we totally remove >>> the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot >>> from a SATA disk. Using FreeBSD 6.1, the Intel gigabit ethernet NICs >>> aren't found but the hang doesn't occur. >>> > 1.Boot in safe_mode > 2.Rebuild kernel with SMP (options SMP) > 3.Be Happy. > Well, I was using SMP kernels... Jack Vogel's suggestion to set hint.apic.0.disabled=1 has resolved the hang on boot on my system. FreeBSD 7 (January 2007 snapshot) has been working for me as well, but I'm not ready to use that in production. Thanks, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 15:01:53 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3260C16A402 for ; Wed, 24 Jan 2007 15:01:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC7513C4D0 for ; Wed, 24 Jan 2007 15:01:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (rwcrmhc13) with ESMTP id <20070124150152m1300pgr6ke>; Wed, 24 Jan 2007 15:01:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 36C8E1FA037; Wed, 24 Jan 2007 07:01:43 -0800 (PST) Date: Wed, 24 Jan 2007 07:01:43 -0800 From: Jeremy Chadwick To: Robin Gruyters Message-ID: <20070124150143.GA8460@icarus.home.lan> Mail-Followup-To: Robin Gruyters , freebsd-stable@FreeBSD.org References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 15:01:53 -0000 On Wed, Jan 24, 2007 at 03:25:37PM +0100, Robin Gruyters wrote: > Should this not be visible on the switch as well?!? > > Here some output from the interface on the server and from the switch > (Cisco) > > [development interface] > bge0: flags=8843 mtu 1500 > options=1b > ether 00:12:79:94:ed:12 > media: Ethernet autoselect (100baseTX ) > status: active > [/development interface] > > [switch] > FastEthernet0/3 is up, line protocol is up (connected) > Hardware is Fast Ethernet, address is 000e.84d0.de03 (bia 000e.84d0.de03) > Description: development > MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 100Mb/s > input flow-control is off, output flow-control is off > ARP type: ARPA, ARP Timeout 04:00:00 > Last input never, output 00:00:02, output hang never > Last clearing of "show interface" counters never > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 179000 bits/sec, 28 packets/sec > 5 minute output rate 56000 bits/sec, 24 packets/sec > 22823978 packets input, 4067576147 bytes, 0 no buffer > Received 13138 broadcasts (0 multicast) > 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 watchdog, 12929 multicast, 0 pause input > 0 input packets with dribble condition detected > 15673035 packets output, 3975127029 bytes, 0 underruns > 0 output errors, 0 collisions, 1 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier, 0 PAUSE output > 0 output buffer failures, 0 output buffers swapped out > [/switch] You've got a Cisco involved, so I doubt it. :-) I've seen many times in the past where one end of the link shows errors while the other end (in my experiences, Cisco Catalysts) shows none. When dealing with Cisco<->othervendor, I've never seen auto-neg work properly. One has to always hard set the speed and duplex on both sides for it to work. For example: I lease space in two co-location facilities, from different providers. Both providers use Cisco switches (different models), while we use HP ProCurves. In both facilities, we saw input errors on our ProCurve, while the providers saw absolutely no errors. Both sides were set to auto. The instant I had the providers set 100/full on their Ciscos and I set 100/FD on our ProCurves, the error counts completely disappeared. Set your Cisco configuration to use 100/full, and edit the ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media 100baseTX mediaopt full-duplex", then reboot the FreeBSD box. If the problem continues, there may be faulty cabling, but usually errors on one direction are a sign of duplex mismatch. If after replacing the cabling the issue continues, then there's a chance the bge(4) driver may be obtaining statistics wrong for the particular chip revision being used (this is hearsay on my part; I'm just guessing...) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 15:06:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 305FD16A40E for ; Wed, 24 Jan 2007 15:06:21 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 894E513C4D9 for ; Wed, 24 Jan 2007 15:06:18 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l0OEkJKd054966; Wed, 24 Jan 2007 15:46:19 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l0OEkBiV042747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 15:46:12 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l0OEkBLA040083; Wed, 24 Jan 2007 15:46:11 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l0OEk881040082; Wed, 24 Jan 2007 15:46:08 +0100 (CET) (envelope-from ticso) Date: Wed, 24 Jan 2007 15:46:08 +0100 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20070124144607.GD39608@cicely12.cicely.de> References: <20070124113858.GG64263@hoeg.nl> <200701241254.51900.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701241254.51900.hselasky@c2i.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: FreeBSD Hackers , freebsd-stable@freebsd.org, Ed Schouten , Pietro Cerutti Subject: Re: atacontrol kernel crash (atausb?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 15:06:21 -0000 On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: > On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > > Hello, > > > > * Pietro Cerutti wrote: > > > On 1/15/07, Hans Petter Selasky wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > > > Everything works nice with umass. It creates the da0 device node. > > > It just shows up these errors, as it always did... > > > GEOM: new disk da0 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > > da0: Serial Number > > > da0: 40.000MB/s transfers > > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > > I had these messages with two other devices before, an MP3 player and a > > USB floppy drive. I fixed these errors by adding a quirk to > > /sys/cam/scsi/scsi_da.c. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 > > Instead of having all these quirks, isn't it possible that the SCSI layer can > auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 15:27:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D512D16A401 for ; Wed, 24 Jan 2007 15:27:33 +0000 (UTC) (envelope-from pieter@migo.nl) Received: from mail01.mmb.nl (mail01.mmb.nl [81.4.69.195]) by mx1.freebsd.org (Postfix) with ESMTP id 715AA13C4C8 for ; Wed, 24 Jan 2007 15:27:33 +0000 (UTC) (envelope-from pieter@migo.nl) Received: from [192.168.0.235] ([192.168.0.10]) by mail01.mmb.nl (8.12.9/8.12.6) with ESMTP id l0OErgM3039939 for ; Wed, 24 Jan 2007 15:53:43 +0100 (CET) (envelope-from pieter@migo.nl) From: Pieter Migo Organization: mmb To: freebsd-stable@freebsd.org Date: Wed, 24 Jan 2007 15:54:35 +0100 User-Agent: KMail/1.9.5 References: <20070124120048.3614716A61B@hub.freebsd.org> In-Reply-To: <20070124120048.3614716A61B@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701241554.35382.pieter@migo.nl> Subject: Re: freebsd-stable Digest, Vol 190, Issue 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 15:27:33 -0000 please unsubscribe=20 On Wednesday 24 January 2007 13:00, freebsd-stable-request@freebsd.org wrot= e: > org/mailman =2D-=20 Met vriendelijke groet, Pieter Migo _______________________________________ MMB Holding MMB : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +31 40 2333 5 25 ChartNet : =A0 =A0 =A0 =A0 =A0 =A0 =A0+31 40 2333 5 33 =46ibbs : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +31 40 2333 5 32 TA.nl : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +31 40 2333 5 31 =46ax : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +31 40 2811 7 94 Keizersgracht 16c 5611 GD Eindhoven Nederland MMB.nl ChartNet.nl TA.nl FiBBS.nl _______________________________________=20 DISCLAIMER: Aan dit bericht kunnen geen rechten worden ontleend. Dit bericht is uitsluitend bestemd voor de geadresseerde. Als u dit bericht per abuis hebt ontvangen, wordt u verzocht het te vernietigen en de afzender te informeren. Wij adviseren u om bij twijfel over de juistheid of de volledigheid van de e-mail contact met de afzender op te nemen.=20 Nothing in this email shall bind the sender in any contract or obligation. This e-mail is for the intended addressee only. If you have received it in error then please delete it and notify the sender by return e-mail. In case of doubt about correctness or completeness of this e-mail please contact the sender. =A0 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 15:36:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E744716A46F for ; Wed, 24 Jan 2007 15:36:09 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 95BAB13C4C2 for ; Wed, 24 Jan 2007 15:36:03 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0OFa26S057918; Wed, 24 Jan 2007 07:36:02 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0OFa2TF057917; Wed, 24 Jan 2007 07:36:02 -0800 (PST) (envelope-from rizzo) Date: Wed, 24 Jan 2007 07:36:02 -0800 From: Luigi Rizzo To: "Andresen, Jason R." , freebsd-stable@freebsd.org Message-ID: <20070124073602.B57678@xorpc.icir.org> References: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> <20070124071021.GG874@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070124071021.GG874@turion.vk2pj.dyndns.org>; from peterjeremy@optushome.com.au on Wed, Jan 24, 2007 at 06:10:21PM +1100 Cc: Subject: Re: Dummynet and simulating random delay X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 15:36:10 -0000 On Wed, Jan 24, 2007 at 06:10:21PM +1100, Peter Jeremy wrote: > On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: > >I have a project that requires me to simulate a link with varying but > >well defined delay. The link is guarenteed to deliver packets in > >order, so I wish to maintain that behavior with Dummynet. > > I don't think dummynet can do this in its current form. Based on actually dummynet never does reordering within a single pipe, even if you change the delay on the fly. But this said, you should explain "varying but well defined delay", because if you use TCP or similar as the source, then you have no control on when the userland write->tcp transmission delay anyways so the concept is a bit vague and probably not a meaningful experiment. And even in any common network (from switched ethernet to wireless to dsl...) you have some variance on the delay, ranging from a fraction of a millisecond to much larger values, due to queueing and/or protocol issues (e.g. MAC channel allocation) and/or switch/router/operating system issues. If your delay varies on a coarse timescale, you can just change the pipe's delay as needed, and once things have settled (because of the no-reordering) you know that your packets are delayed by exactly what you specify, plus the If you are interested in somewhat random delays (e.g. to model the effect of interfering traffic) you do just that - fire extra traffic to the same pipe, and then as a side effect of the queueing, your traffic will be subject to variable delays. Also keep in mind that the resolution of dummynet is 1/hz so it is in the order of 1 millisecond. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 16:12:10 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BCD316A40B for ; Wed, 24 Jan 2007 16:12:10 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 617B313C4E9 for ; Wed, 24 Jan 2007 16:12:09 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 69244 invoked from network); 24 Jan 2007 15:45:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Jan 2007 15:45:26 -0000 Date: Wed, 24 Jan 2007 16:45:26 +0100 (CET) Message-Id: <20070124.164526.74683574.sthaug@nethelp.no> To: koitsu@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <20070124150143.GA8460@icarus.home.lan> References: <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> <20070124150143.GA8460@icarus.home.lan> 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: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 16:12:10 -0000 > When dealing with Cisco<->othervendor, I've never seen auto-neg > work properly. One has to always hard set the speed and duplex > on both sides for it to work. Nowadays auto-neg almost always works for us, even for Fast Ethernet. We have Cisco-Extreme, Cisco-Juniper, Cisco-Cisco, Cisco-Riverstone and of course lots of Cisco-various hosts. Basically, things just work. We always use auto-neg for Gigabit Ethernet. 3-4 years ago the situation was different, and we always used to set speed/duplex. Not any more. Maybe you've been unlucky. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 16:17:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0719816A401 for ; Wed, 24 Jan 2007 16:17:50 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from public.aci.on.ca (aci.on.ca [205.207.148.251]) by mx1.freebsd.org (Postfix) with ESMTP id BD0C113C44C for ; Wed, 24 Jan 2007 16:17:49 +0000 (UTC) (envelope-from lists@qwirky.net) Received: from (invalid client hostname: host address literal does not match remote client address)[127.0.0.1] (xtreme-156-171.dyn.aci.on.ca[69.17.156.171] port=3290) by public.aci.on.ca([205.207.148.252] port=25) via TCP with esmtp (7747 bytes) (sender: ) id for ; Wed, 24 Jan 2007 11:17:40 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2006-Feb-21) Message-ID: <45B786A8.40400@qwirky.net> Date: Wed, 24 Jan 2007 11:17:44 -0500 From: Jeff Royle User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <45B0D996.8070704@qwirky.net> <45B0F61A.8020507@qwirky.net> <45B0F758.70408@delphij.net> <45B24C73.3010807@qwirky.net> In-Reply-To: <45B24C73.3010807@qwirky.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0706-1, 24/01/2007), Outbound message X-Antivirus-Status: Clean Subject: Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@qwirky.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 16:17:50 -0000 Jeff Royle wrote: > LI Xin wrote: >> Jeff Royle wrote: >>> Jeff Royle wrote: >>>> I could use some advice on this issue I have had with my raid >>>> controller. >>>> I am not really running much on the system yet, postfix, Pf + pflogd, >>>> rlogind, ssh, bsnmp and ntpd. While I was just reading a file with >>>> less the system stopped responding. I thought it was the network >>>> interfaces but I was able to ping the interface. Once I plugged a >>>> monitor into the system I saw this (roughly): >>>> >>>> AAC0: COMMAND TIMEOUT AFTER X number of seconds >>>> >>>> Not good :) >>>> >>>> Reset of the system resolved the issue and it booted fine. Since >>>> the controller stopped responding nothing was recorded to my logs. >>>> >>>> Now I have to figure out how to prevent that from happening again. >>>> >>>> Basic run down on the system and some history... >>>> >>>> P4 3.2Ghz >>>> Asus P5MT-S MB >>>> 2 x 1GB DDR2 667 memory >>>> Adaptec 2130SLP Raid Controller + battery backup module >>>> 2 Segate Ultra320 73GB 15k RPM (mirrored) >>>> >>>> I have run this same system hardware testing 6.2-BETA3, RC-1 and RC-2 >>>> without this issue. I was using the driver released by Adaptec >>>> while testing the pre-release installs >>>> (http://www.adaptec.com/en-US/speed/raid/aac/unix/aacraid_freebsd6_drv_b11518_tgz.htm). >>>> You could say I am fairly confidient in the hardware itself. I have >>>> put this system through a lot of testing since BETA3. >>>> >>>> The 6.2 release kernel has not been customized all that much, I just >>>> pulled out all the drivers I would never use. To be safe I kept >>>> just about all scsi devices/card models still in as I continued my >>>> testing of 6.2 release. Right now I am going to try taking out aac and >>>> aacp then try the driver I used in my previous tests. However, >>>> since I have run a week without this issue it will be hard/impossible >>>> tell if this did anything to resolve it...I almost want a crash on the >>>> old driver :) >>>> >>>> So I need some advice... How best do I debug this issue? >>>> >>>> Thanks in advance for any direction you guys can offer me. >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> >>> It appears the driver I was using in my pre-release testing is newer >>> then the release driver. >>> >>> Stock driver in 6.2r dmesg: >>> >>> aac0: mem >>> 0xfc600000-0xfc7fffff,0xfc5ff000-0xfc5fffff irq 24 at device 1.0 on pci2 >>> aac0: New comm. interface enabled >>> aac0: Adaptec Raid Controller 2.0.0-1 >>> aacp0: on aac0 >>> >>> Currently using: >>> >>> aacu0: mem >>> 0xfc600000-0xfc7fffff,0xfc5ff000-0xfc5fffff irq 24 at device 1.0 on pci2 >>> aacu0: New comm. interface enabled >>> aacu0: Adaptec Raid Controller 2.0.7-1 >>> aacpu0: on aacu0 >>> >>> Going to continue testing with the newer driver. >> >> I have some preliminary work on merging the Adaptec driver: >> >> http://people.freebsd.org/~delphij/for_review/patch-aac-vendor-b11518 >> >> But one of the reviewers has advised me to request boarder testing, >> especially against old cards and CLI tools, so I have hold the commit >> for now. >> >> Cheers, > > Well the driver patched fine, no issues to report there. > > The speed performance is where I expected to see it while using bonnie > and simple DD tests based on my previous testing. > > So far the issue I noted above with the TIMEOUT error has not shown > itself again, time will tell I think on this one. > > However I have encountered a intermittent bug on boot. > > Sometimes, say every 5-10 boots the system will hang while probing the > the scsi bus for the drives. Now I have seen this happen on the aacdu > 2.0.7-1 binary driver I was using in my 6.2-RC 1 / 6.2-RC 2 testing once > before. This problem is happening a fair bit more. > > Here is where it hangs... > > Hung dmesg output: > > -- snip --- > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcd7ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > Timecounters tick every 1.000 msec > acd0: CDRW at ata0-master UDMA33 > aacd0: on aac0 > aacd0: 69889MB (143132672 sectors) > --- end snip --- > > The system does not continue on and probe the drives, as seen in a > normal boot dmesg: > > --- snip --- > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > Timecounters tick every 1.000 msec > acd0: CDRW at ata0-master UDMA33 > aacd0: on aac0 > aacd0: 69889MB (143132672 sectors) > pass0 at aacp0 bus 0 target 0 lun 0 > pass0: Fixed unknown SCSI-3 device > pass0: 3.300MB/s transfers > pass1 at aacp0 bus 0 target 3 lun 0 > pass1: Fixed unknown SCSI-3 device > pass1: 3.300MB/s transfers > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/aacd0s1a > -- end snip -- > > In a effort to resolve this I increased the scsi delay in the kernel > from 5ms to 10ms > > options SCSI_DELAY=10000 > > It *may* have helped on one of my reboot tests, I thought it was going > to hang again but proceeded. However it definitely did not solve the > issue. > > Once I am back in the office I will see if I can get some debug output > for you. > > Cheers, > > Jeff Update --- The TIMEOUT error I think has been resolved using aac 2.0.7-1 patch. The system has never failed on any of my tests to generate the timeout. However the hardlock on boot while probing the hard drives continues. From another post someone suggested disabling the device fdc as there is a bug in the Intel chipset that can cause issues. So I attempted that as I have seen the floppy seek an unusually long time. No change. I am assuming at this point this bug is not specific to the aac driver since I saw it at least once on the binary 2.0.7-1 driver from Adaptec. Last reboot test results was : Reboot #10 hardlock Unfortunately it will not break into the debugger to get more detailed information. Last time I am going to try was a recent post suggesting hint.apic.0.disabled=1 might help. This was to resolve another boot issue, not exactly the same issue I have but I am willing to try almost anything at this point. I admit I don't really understand what exactly hint.apic.0.disabled does. My assumption is it disables all APIC, we shall have to see :) Cheers, Jeff From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 16:40:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 570D016A51D for ; Wed, 24 Jan 2007 16:40:56 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 55C7713C467 for ; Wed, 24 Jan 2007 16:40:54 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 24 Jan 2007 11:40:50 -0500 id 0005644A.45B78C13.0000B648 Date: Wed, 24 Jan 2007 11:40:50 -0500 From: Bill Moran To: Pieter Migo Message-Id: <20070124114050.a2f3ae3e.wmoran@collaborativefusion.com> In-Reply-To: <200701241554.35382.pieter@migo.nl> References: <20070124120048.3614716A61B@hub.freebsd.org> <200701241554.35382.pieter@migo.nl> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.7; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-stable Digest, Vol 190, Issue 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 16:40:56 -0000 In response to Pieter Migo : > please unsubscribe > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 16:51:03 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F01FA16A404 for ; Wed, 24 Jan 2007 16:51:03 +0000 (UTC) (envelope-from cadavo@mail.ru) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by mx1.freebsd.org (Postfix) with ESMTP id 303D013C44C for ; Wed, 24 Jan 2007 16:51:02 +0000 (UTC) (envelope-from cadavo@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 86E485E38A for ; Wed, 24 Jan 2007 15:31:12 +0300 (MSK) Received: from [213.140.244.14] (port=40809 helo=[192.168.0.8]) by mx3.mail.ru with esmtp id 1H9hHS-000C1c-00 for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 15:31:10 +0300 Message-ID: <45B751E0.5080907@mail.ru> Date: Wed, 24 Jan 2007 15:32:32 +0300 From: Ilia Gorstkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.8) Gecko/20061123 SeaMonkey/1.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: arp: unknown hardware address format X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 16:51:04 -0000 Hi all! FreeBSD 6.2-release. I'm having trouble with arp: arp: unknown hardware address format (0x4500) and arp: unknown hardware address format (0x4242) these messages fall on the console in a plenty. I do tcpdump -exn "arp[0]=0x45 and arp[1]=0": tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 68 bytes 15:12:23.308179 00:02:55:53:46:13 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: truncated-arp 0x0000: 4500 0020 9f4e 4000 3f2f bfa1 c0a8 fc6b E....N@.?/.....k 0x0010: c0a8 5f02 2081 880b 0000 8000 0000 0023 .._............# 0x0020: 0000 0000 0000 0000 0000 2020 2020 .............. 0x0000: 4500 0020 9f4e 4000 3f2f bfa1 c0a8 fc6b 0x0010: c0a8 5f02 2081 880b 0000 8000 0000 0023 0x0020: 0000 0000 0000 0000 0000 2020 2020 15:12:23.428057 00:02:55:53:46:13 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: truncated-arp 0x0000: 4500 0020 9f4f 4000 3f2f bfa0 c0a8 fc6b E....O@.?/.....k 0x0010: c0a8 5f02 2081 880b 0000 8000 0000 0025 .._............% 0x0020: 0000 0000 0000 0000 0000 2020 2020 .............. 0x0000: 4500 0020 9f4f 4000 3f2f bfa0 c0a8 fc6b 0x0010: c0a8 5f02 2081 880b 0000 8000 0000 0025 0x0020: 0000 0000 0000 0000 0000 2020 2020 In the arp-table of my network there is not MAC-address 00:02:55:53:46:13. Where is it address from? How does it influence on safety? How to solve this problem? Thanks From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 17:09:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDBFF16A401; Wed, 24 Jan 2007 17:09:38 +0000 (UTC) (envelope-from casner@acm.org) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by mx1.freebsd.org (Postfix) with ESMTP id 96D2413C441; Wed, 24 Jan 2007 17:09:38 +0000 (UTC) (envelope-from casner@acm.org) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id l0OH9ZnS012327; Wed, 24 Jan 2007 09:09:35 -0800 Date: Wed, 24 Jan 2007 09:26:54 -0800 (PST) From: Stephen Casner Sender: casner@packetdesign.com To: Doug Barton In-Reply-To: <45B67968.2030304@FreeBSD.org> Message-ID: <20070124092103.G3837@oak.packetdesign.com> References: <20070123001343.J641@oak.packetdesign.com> <45B67968.2030304@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: System hang on laptop suspend/resume X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 17:09:38 -0000 On Tue, 23 Jan 2007, Doug Barton wrote: > My guess as to why you're not getting a response is that > suspend/resume issues currently have no champion amongst FreeBSD > developers, and therefore they are simply not being addressed. This > is disappointing, but part of life in a volunteer project. Understood. Thanks for your reply. > The first and only suggestion I have is to upgrade to 6.2 now that > it's out, but that's just to make doubly sure your issue hasn't been > solved (which is likely). Beyond that, carefully combing the archives > of the -mobile, -stable, and -current lists for similar issues might > lead to some things for you to try. I will do that. As I mentioned to another off-list responder, I have to admit that I hadn't noticed that 6.2 had been released. It seemed to be permanently stuck in beta. Indeed, the disk timeout seems like a bug that might have been fixed. Do you know, though, whether there is any way in NEWCARD to power down the PC Card / Cardbus slot? I didn't see anything in the 6.2 release note regarding changes in that area. -- Steve From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 17:28:14 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8B9916A400 for ; Wed, 24 Jan 2007 17:28:14 +0000 (UTC) (envelope-from feijo.listas@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id A1BA913C442 for ; Wed, 24 Jan 2007 17:28:14 +0000 (UTC) (envelope-from feijo.listas@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so88025pye for ; Wed, 24 Jan 2007 09:28:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tMKuDn84VJ4jhrqXvx2nA4OTWYmunEv9vWjFXhmHqSgFRTLAXymCToCxVZblZilJS5Beu8a3vjATzb+U1DIKge/+lCczyupgg/5XPJk0o58z8UJ6Um7UZIyJjCQ2BJwuvjUi8zGbjFlwj3JHxT9o46v2NWdLgBUfH/huTxOoLUQ= Received: by 10.35.21.1 with SMTP id y1mr1889368pyi.1169658186886; Wed, 24 Jan 2007 09:03:06 -0800 (PST) Received: by 10.35.48.10 with HTTP; Wed, 24 Jan 2007 09:03:06 -0800 (PST) Message-ID: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> Date: Wed, 24 Jan 2007 15:03:06 -0200 From: "=?ISO-8859-1?Q?Gustavo_Feij=F3?=" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 17:28:14 -0000 Hi there, I know it's not the right list to write to, but I'll still try a shot. I'm running sendmail in my FreeBSD box and wish to block mails comming from domains with no ptr configs. Am I missing something? My sendmail-rx.mc is like this FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(redirect)dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`ALIAS_FILE', `/etc/mail/aliases')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl FEATURE(`use_cw_file')dnl FEATURE(`use_ct_file')dnl FEATURE(`use_client_ptr')dnl FEATURE(`delay_checks')dnl dnl # dnl # configuracoes de lista de spammers dnl # FEATURE(`dnsbl', `dul.dnsbl.sorbs.net', `"550 Mail from " $`'&{client_addr} " refused - see http://www.dul.dnsbl.sorbs.net/"') FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from " $`'&{client_addr} " refused - see http://www.spamhaus.org/sbl/"') FEATURE(`dnsbl', `list.dsbl.org', `"550 Mail from " $`'&{client_addr} " refused - see http://dsbl.org/"') FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from " $`'&{client_addr} " refused - see http://spamcop.net/bl.shtml"') dnl # -- []'s chmod000 "Microsoft butterfly is their way of telling you their system has a lot of @#$ bugs!" From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 17:53:19 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0508316A402 for ; Wed, 24 Jan 2007 17:53:19 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mailhost.graphdata.co.uk (mailhost.graphdata.co.uk [195.12.22.194]) by mx1.freebsd.org (Postfix) with ESMTP id BC5E113C45B for ; Wed, 24 Jan 2007 17:53:18 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mailhost.graphdata.co.uk (Postfix) with ESMTP id 8C081114032 for ; Wed, 24 Jan 2007 17:53:17 +0000 (GMT) X-Virus-Scanned: amavisd-new at graphdata.co.uk Received: from mailhost.graphdata.co.uk ([127.0.0.1]) by localhost (mailhost.graphdata.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krp48fAd5Q3X for ; Wed, 24 Jan 2007 17:53:12 +0000 (GMT) Received: from gdc083.internal.graphdata.co.uk (gdc083.internal.graphdata.co.uk [192.168.0.86]) by mailhost.graphdata.co.uk (Postfix) with SMTP id 4863511402F for ; Wed, 24 Jan 2007 17:53:12 +0000 (GMT) Date: Wed, 24 Jan 2007 17:53:11 +0000 From: Dominic Marks To: freebsd-stable@freebsd.org Message-Id: <20070124175311.63cfeef4.dom@helenmarks.co.uk> In-Reply-To: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 17:53:19 -0000 On Wed, 24 Jan 2007 15:03:06 -0200 "Gustavo Feij=F3" wrote: > FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from " Try replacing with 'zen.spamhaus.org'. Can't comment on the others. Are you only using RBLs for spam prevention? HTH, Dominic From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 17:58:13 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCE5916A400 for ; Wed, 24 Jan 2007 17:58:13 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id 10CAA13C455 for ; Wed, 24 Jan 2007 17:58:12 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by wx-out-0506.google.com with SMTP id s18so233265wxc for ; Wed, 24 Jan 2007 09:58:12 -0800 (PST) Received: by 10.90.113.20 with SMTP id l20mr918540agc.1169661491435; Wed, 24 Jan 2007 09:58:11 -0800 (PST) Received: by 10.90.29.8 with HTTP; Wed, 24 Jan 2007 09:58:11 -0800 (PST) Message-ID: Date: Wed, 24 Jan 2007 19:58:11 +0200 From: "Vlad GALU" To: "=?ISO-8859-1?Q?Gustavo_Feij=F3?=" In-Reply-To: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 17:58:13 -0000 On 1/24/07, Gustavo Feij=F3 wrote: > Hi there, > I know it's not the right list to write to, but I'll still try a shot. There is freebsd-isp@, as well :) > I'm running sendmail in my FreeBSD box and wish to block mails comming > from domains with no ptr configs. > > Am I missing something? > > My sendmail-rx.mc is like this > FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl > FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl > FEATURE(redirect)dnl > define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl > define(`ALIAS_FILE', `/etc/mail/aliases')dnl > FEATURE(`blacklist_recipients')dnl > EXPOSED_USER(`root')dnl > FEATURE(`use_cw_file')dnl > FEATURE(`use_ct_file')dnl > FEATURE(`use_client_ptr')dnl > FEATURE(`delay_checks')dnl > dnl # > dnl # configuracoes de lista de spammers > dnl # > FEATURE(`dnsbl', `dul.dnsbl.sorbs.net', `"550 Mail from " > $`'&{client_addr} " refused - see http://www.dul.dnsbl.sorbs.net/"') > FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from " > $`'&{client_addr} " refused - see http://www.spamhaus.org/sbl/"') > FEATURE(`dnsbl', `list.dsbl.org', `"550 Mail from " $`'&{client_addr} > " refused - see http://dsbl.org/"') > FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from " $`'&{client_addr} > " refused - see http://spamcop.net/bl.shtml"') > dnl # > > > -- > []'s > chmod000 > "Microsoft butterfly is their way of telling you their system has a > lot of @#$ bugs!" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 18:28:08 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC41016A402 for ; Wed, 24 Jan 2007 18:28:08 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from mail.mda.gov.br (mail-pri.mda.gov.br [200.198.212.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7C17A13C459 for ; Wed, 24 Jan 2007 18:28:07 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mda.gov.br (Postfix) with ESMTP id 71AAC8058 for ; Wed, 24 Jan 2007 16:07:45 -0200 (BRST) Received: from mail.mda.gov.br ([127.0.0.1]) by localhost (mail-pri.mda.gov.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06504-43 for ; Wed, 24 Jan 2007 16:07:44 -0200 (BRST) Received: from [10.0.103.143] (fogosec.mda.gov.br [200.198.212.34]) by mail.mda.gov.br (Postfix) with ESMTP id 470B18094 for ; Wed, 24 Jan 2007 16:07:44 -0200 (BRST) Message-ID: <45B7A0FA.1050901@terceirizado.mda.gov.br> Date: Wed, 24 Jan 2007 16:10:02 -0200 From: Alexandre Vasconcelos User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mda.gov.br Subject: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 18:28:08 -0000 Hello, Working setup: - FreeBSD 6.2-PRERELEASE, firefox 2 and flash 7 patched with rtld_dlsym_hack.diff, like suggested on Handbook. After 6.2-STABLE upgrade reaplying the rtld_dlsym_hack.diff fails: root@alex src]# patch < rtld_dlsym_hack.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 |+++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 -------------------------- Patching file libexec/rtld-elf/rtld.c using Plan A... Hunk #1 failed at 129. Hunk #2 succeeded at 187 (offset 9 lines). Hunk #3 succeeded at 1820 (offset 82 lines). 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej done And make fails: [root@alex rtld-elf]# make cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/rtld_start.S cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/rtld.c /usr/src/libexec/rtld-elf/rtld.c:189: error: `_dlsym' undeclared here (not in a function) /usr/src/libexec/rtld-elf/rtld.c:189: error: initializer element is not constant /usr/src/libexec/rtld-elf/rtld.c:189: error: (near initialization for `exports[4]') *** Error code 1 Stop in /usr/src/libexec/rtld-elf. How to fix this? Thanks, Alex From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 18:36:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D692216A5C5 for ; Wed, 24 Jan 2007 18:36:08 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id AC93313C448 for ; Wed, 24 Jan 2007 18:36:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so219809uge for ; Wed, 24 Jan 2007 10:36:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f9vJcZsH2/7QiriH7GHGvGmcw3sFoZynrGX6+jK3X+ZeYUbug8HIBing9yUvuwAYTi5Ix5phaj+ZddCQYJCZMcVo020STnb36y4HBMXo9Ebx83DEGpKrQHdu6nPncd9kdmGRNWqyKyTmvM5a9VnFh4RRKzEp2BEUNhk5awDTwWs= Received: by 10.82.116.15 with SMTP id o15mr336721buc.1169663766309; Wed, 24 Jan 2007 10:36:06 -0800 (PST) Received: by 10.82.186.2 with HTTP; Wed, 24 Jan 2007 10:36:06 -0800 (PST) Message-ID: <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> Date: Wed, 24 Jan 2007 12:36:06 -0600 From: "Scot Hetzel" To: "Alexandre Vasconcelos" In-Reply-To: <45B7A0FA.1050901@terceirizado.mda.gov.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7A0FA.1050901@terceirizado.mda.gov.br> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 18:36:16 -0000 On 1/24/07, Alexandre Vasconcelos wrote: > root@alex src]# patch < rtld_dlsym_hack.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 > |+++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 > -------------------------- > Patching file libexec/rtld-elf/rtld.c using Plan A... > Hunk #1 failed at 129. > Hunk #2 succeeded at 187 (offset 9 lines). > Hunk #3 succeeded at 1820 (offset 82 lines). > 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej > done > > And make fails: > : > How to fix this? Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to libexec/rtld-elf/rtld.c. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 18:42:59 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43D2916A403 for ; Wed, 24 Jan 2007 18:42:59 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from mail.mda.gov.br (mail-pri.mda.gov.br [200.198.212.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8E56F13C44C for ; Wed, 24 Jan 2007 18:42:58 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mda.gov.br (Postfix) with ESMTP id 9E0E9807B for ; Wed, 24 Jan 2007 16:42:55 -0200 (BRST) Received: from mail.mda.gov.br ([127.0.0.1]) by localhost (mail-pri.mda.gov.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04574-19 for ; Wed, 24 Jan 2007 16:42:54 -0200 (BRST) Received: from [10.0.103.143] (fogosec.mda.gov.br [200.198.212.34]) by mail.mda.gov.br (Postfix) with ESMTP id 9A88F80B0 for ; Wed, 24 Jan 2007 16:42:54 -0200 (BRST) Message-ID: <45B7A937.2020007@terceirizado.mda.gov.br> Date: Wed, 24 Jan 2007 16:45:11 -0200 From: Alexandre Vasconcelos User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> In-Reply-To: <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mda.gov.br Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 18:42:59 -0000 Scot Hetzel wrote: > Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to > libexec/rtld-elf/rtld.c. Thanks for answering Scot, and sorry for ignorance.. how can I do it? Thanks again, Alex From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 18:54:04 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F363B16A402 for ; Wed, 24 Jan 2007 18:54:03 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id DE0B913C45D for ; Wed, 24 Jan 2007 18:54:03 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l0OIOCda020864; Wed, 24 Jan 2007 10:24:12 -0800 (PST) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 722A840028; Wed, 24 Jan 2007 10:24:12 -0800 (PST) X-AuditID: 11807126-a2682bb000000245-75-45b7a44cab73 Received: from [17.214.13.96] (unknown [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 645D840025; Wed, 24 Jan 2007 10:24:12 -0800 (PST) In-Reply-To: <45B751E0.5080907@mail.ru> References: <45B751E0.5080907@mail.ru> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 24 Jan 2007 10:24:11 -0800 To: Ilia Gorstkin X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-stable@freebsd.org Subject: Re: arp: unknown hardware address format X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 18:54:04 -0000 On Jan 24, 2007, at 4:32 AM, Ilia Gorstkin wrote: > I'm having trouble with arp: > arp: unknown hardware address format (0x4500) > and > arp: unknown hardware address format (0x4242) > these messages fall on the console in a plenty. > > I do tcpdump -exn "arp[0]=0x45 and arp[1]=0": > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on xl0, link-type EN10MB (Ethernet), capture size 68 bytes Please run "tcpdump -exxn -s 0 arp" to show the full packets including link-layer headers. You should be seeing a byte sequence more like: 0001 0800 0604 0001 ...followed by the sender's MAC address. This is from /usr/include/net/if_arp.h and means: ARPHRD_ETHER, ETHERTYPE_IP, hln=6, pln=4, ARPOP_REQUEST I don't know what 0x4500 means, but 0x4242 is: #define ETHERTYPE_PCS 0x4242 /* PCS Basic Block Protocol */ It seems more likely that you've got a hardware problem like a wacked out NIC or switch, or some really odd software bug... -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 19:08:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B671F16A402 for ; Wed, 24 Jan 2007 19:08:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4B20C13C45D for ; Wed, 24 Jan 2007 19:08:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so226743uge for ; Wed, 24 Jan 2007 11:08:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cBtnnL8bsRHGk3WWtJwipyuQdNOGfrKGUWePVqv7tE22fYT+LLQ2ved+Lv4AHbQuhqjum8IJj9PLYSfceC5h/ud4uUVGD7BSVFnd1XZBQlLMhjgcKMC/svu/+cnF5Kl8qmQswK+WVAggmAu+qpESYtHMSpoPegGNjHoNrQi/L6Y= Received: by 10.82.113.6 with SMTP id l6mr170864buc.1169665693505; Wed, 24 Jan 2007 11:08:13 -0800 (PST) Received: by 10.82.186.2 with HTTP; Wed, 24 Jan 2007 11:08:12 -0800 (PST) Message-ID: <790a9fff0701241108i2936d104t2bbbf6016bbe87b5@mail.gmail.com> Date: Wed, 24 Jan 2007 13:08:12 -0600 From: "Scot Hetzel" To: "Alexandre Vasconcelos" In-Reply-To: <45B7A937.2020007@terceirizado.mda.gov.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> <45B7A937.2020007@terceirizado.mda.gov.br> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 19:08:15 -0000 On 1/24/07, Alexandre Vasconcelos wrote: > Scot Hetzel wrote: > > > Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to > > libexec/rtld-elf/rtld.c. > > > Thanks for answering Scot, and sorry for ignorance.. how can I do it? > Open /usr/src/libexec/rtld-elf/rtld.c.rej in one window, and /usr/src/libexec/rtld-elf/rtld.c in another window. Goto line 129 in /usr/src/libexec/rtld-elf/rtld.c and add the missing _dlsym information from the *.rej file. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 19:38:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0BE516A402 for ; Wed, 24 Jan 2007 19:38:24 +0000 (UTC) (envelope-from eric.j.christeson@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8283813C448 for ; Wed, 24 Jan 2007 19:38:24 +0000 (UTC) (envelope-from eric.j.christeson@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so258041wxc for ; Wed, 24 Jan 2007 11:38:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OWCHw9aXyNWivB0CLXJ8k9OsPZnydNVw1YY9hSpNHWXXDC1qv79frdonhcRHm6tGz1inyMjJGIRQDuRQXijwOYxxF4RSHSQgZsgt8lXnTux54TjfnXncicsiFqi5f78cTmlg3J4j+CsOnjD2ySrYeYxlcz0sAMPxMfDJg9DgVgA= Received: by 10.90.116.6 with SMTP id o6mr1049504agc.1169665876817; Wed, 24 Jan 2007 11:11:16 -0800 (PST) Received: by 10.90.55.1 with HTTP; Wed, 24 Jan 2007 11:11:16 -0800 (PST) Message-ID: <7e3339060701241111s674800a4n4210fd756a27f59a@mail.gmail.com> Date: Wed, 24 Jan 2007 13:11:16 -0600 From: ejc To: "Alexandre Vasconcelos" In-Reply-To: <45B7A937.2020007@terceirizado.mda.gov.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> <45B7A937.2020007@terceirizado.mda.gov.br> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 19:38:24 -0000 On 1/24/07, Alexandre Vasconcelos wrote: > Scot Hetzel wrote: > > > Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to > > libexec/rtld-elf/rtld.c. > > > Thanks for answering Scot, and sorry for ignorance.. how can I do it? rtld.c has changed a bit over time so here's a patch against the new file. ****Begin Patch**** --- libexec/rtld-elf/rtld.c.orig Wed Jan 24 13:03:46 2007 +++ libexec/rtld-elf/rtld.c Wed Jan 24 13:04:43 2007 @@ -134,6 +134,7 @@ static void ref_dag(Obj_Entry *); static void ld_utrace_log(int, void *, void *, size_t, int, const char *); +void *_dlsym(void *, const char *); void r_debug_state(struct r_debug *, struct link_map *); /* @@ -186,6 +187,7 @@ (func_ptr_type) &dlclose, (func_ptr_type) &dlerror, (func_ptr_type) &dlopen, + (func_ptr_type) &_dlsym, (func_ptr_type) &dlsym, (func_ptr_type) &dladdr, (func_ptr_type) &dllockinit, @@ -1827,6 +1829,12 @@ trace_loaded_objects(obj); wlock_release(rtld_bind_lock, lockstate); exit(0); +} + +void * +_dlsym(void *handle, const char *name) +{ + return dlsym(handle, name); } void * ****End Patch**** -- Eric From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 19:50:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA8F616A400 for ; Wed, 24 Jan 2007 19:50:38 +0000 (UTC) (envelope-from ports@fsck.ch) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4104013C45A for ; Wed, 24 Jan 2007 19:50:38 +0000 (UTC) (envelope-from ports@fsck.ch) Received: from fac (84-73-229-8.dclient.hispeed.ch [84.73.229.8]) (authenticated bits=0) by smtp.hispeed.ch (8.12.11.20060308/8.12.11/taifun-1.0) with ESMTP id l0OIoWBj003200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 24 Jan 2007 19:50:33 +0100 Date: Wed, 24 Jan 2007 19:50:31 +0100 From: Tobias Roth To: freebsd-stable@freebsd.org Message-ID: <20070124195031.3561c85d@fac> In-Reply-To: <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-PGP-Key: http://fsck.ch/public_key.asc Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=MP_fwir4KT5UC2KQaboJqr_kt0 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on smtp-05.tornado.cablecom.ch X-Virus-Status: Clean X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-05.tornado.cablecom.ch 1378; Body=2 Fuz1=2 Fuz2=2 Cc: Alexandre Vasconcelos Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 19:50:38 -0000 --MP_fwir4KT5UC2KQaboJqr_kt0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 24 Jan 2007 12:36:06 -0600 "Scot Hetzel" wrote: > On 1/24/07, Alexandre Vasconcelos > wrote: > > root@alex src]# patch < rtld_dlsym_hack.diff > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 > > |+++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 > > -------------------------- > > Patching file libexec/rtld-elf/rtld.c using Plan A... > > Hunk #1 failed at 129. > > Hunk #2 succeeded at 187 (offset 9 lines). > > Hunk #3 succeeded at 1820 (offset 82 lines). > > 1 out of 3 hunks failed--saving rejects to > > libexec/rtld-elf/rtld.c.rej done > > > > And make fails: > > > : > > How to fix this? > > Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to > libexec/rtld-elf/rtld.c. For your convenience: http://fsck.ch/rtld_dlsym_hack_new.diff or the attached file (if it makes it through). cheers, Tobias --MP_fwir4KT5UC2KQaboJqr_kt0 Content-Type: text/x-patch; name=rtld_dlsym_hack_new.diff Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=rtld_dlsym_hack_new.diff --- libexec/rtld-elf/rtld.c.orig Tue Jan 16 08:51:04 2007 +++ libexec/rtld-elf/rtld.c Wed Jan 24 19:43:57 2007 @@ -129,6 +129,7 @@ static void unlink_object(Obj_Entry *); static void unload_object(Obj_Entry *); static void unref_dag(Obj_Entry *); +void *_dlsym(void *, const char *); static void ref_dag(Obj_Entry *); void r_debug_state(struct r_debug *, struct link_map *); @@ -182,6 +183,7 @@ (func_ptr_type) &dlclose, (func_ptr_type) &dlerror, (func_ptr_type) &dlopen, + (func_ptr_type) &_dlsym, (func_ptr_type) &dlsym, (func_ptr_type) &dladdr, (func_ptr_type) &dllockinit, @@ -1762,6 +1764,12 @@ trace_loaded_objects(obj); wlock_release(rtld_bind_lock, lockstate); exit(0); +} + +void * +_dlsym(void *handle, const char *name) +{ + return dlsym(handle, name); } void * --MP_fwir4KT5UC2KQaboJqr_kt0-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 19:54:37 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 130D416A400 for ; Wed, 24 Jan 2007 19:54:37 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from mail.mda.gov.br (mail-pri.mda.gov.br [200.198.212.40]) by mx1.freebsd.org (Postfix) with ESMTP id BB1C613C45A for ; Wed, 24 Jan 2007 19:54:36 +0000 (UTC) (envelope-from alexandre.barreto@terceirizado.mda.gov.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mda.gov.br (Postfix) with ESMTP id 72E7F807B for ; Wed, 24 Jan 2007 17:54:34 -0200 (BRST) Received: from mail.mda.gov.br ([127.0.0.1]) by localhost (mail-pri.mda.gov.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02094-06 for ; Wed, 24 Jan 2007 17:54:34 -0200 (BRST) Received: from [10.0.102.61] (fogosec.mda.gov.br [200.198.212.34]) by mail.mda.gov.br (Postfix) with ESMTP id 185D78063 for ; Wed, 24 Jan 2007 17:54:33 -0200 (BRST) Message-ID: <45B7BA04.80903@terceirizado.mda.gov.br> Date: Wed, 24 Jan 2007 17:56:52 -0200 From: Alexandre Vasconcelos User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> <20070124195031.3561c85d@fac> In-Reply-To: <20070124195031.3561c85d@fac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mda.gov.br Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 19:54:37 -0000 Tobias Roth wrote: > For your convenience: http://fsck.ch/rtld_dlsym_hack_new.diff > or the attached file (if it makes it through). Thank you guys, for all responses. Alex From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 21:46:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05D2416A400 for ; Wed, 24 Jan 2007 21:46:15 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id BAA4713C442 for ; Wed, 24 Jan 2007 21:46:14 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCE00CL47519IB0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 22:46:13 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCE00M97751ERX1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 22:46:13 +0100 (CET) Date: Wed, 24 Jan 2007 22:46:13 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <20070124092103.G3837@oak.packetdesign.com> To: freebsd-stable@freebsd.org Message-id: <20070124224613.420e8ae3.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20070123001343.J641@oak.packetdesign.com> <45B67968.2030304@FreeBSD.org> <20070124092103.G3837@oak.packetdesign.com> Subject: Re: System hang on laptop suspend/resume X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 21:46:15 -0000 On Wed, 24 Jan 2007 09:26:54 -0800 (PST) Stephen Casner wrote: > Do you know, though, whether there is any way in NEWCARD to power down > the PC Card / Cardbus slot? I didn't see anything in the 6.2 release > note regarding changes in that area. Hmm, doesn't 'pccardc power ...' already do that? See 'man pccardc' for more info. HTH -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 21:51:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22B2E16A415 for ; Wed, 24 Jan 2007 21:51:09 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id D593E13C4B9 for ; Wed, 24 Jan 2007 21:51:08 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCE00C1G7D89IC0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 22:51:08 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCE00MXL7D7EN12@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Jan 2007 22:51:08 +0100 (CET) Date: Wed, 24 Jan 2007 22:51:07 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <7e3339060701241111s674800a4n4210fd756a27f59a@mail.gmail.com> To: freebsd-stable@freebsd.org Message-id: <20070124225107.9db08d9d.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> <45B7A937.2020007@terceirizado.mda.gov.br> <7e3339060701241111s674800a4n4210fd756a27f59a@mail.gmail.com> Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 21:51:09 -0000 On Wed, 24 Jan 2007 13:11:16 -0600 ejc wrote: > rtld.c has changed a bit over time so here's a patch against the new > file. BTW, what is the reason this "hack" isn't included in the base kernel / code? -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 23:15:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 715F416A401 for ; Wed, 24 Jan 2007 23:15:42 +0000 (UTC) (envelope-from fkraiem@free.fr) Received: from smtp23.orange.fr (smtp23.orange.fr [193.252.23.111]) by mx1.freebsd.org (Postfix) with ESMTP id 12DB713C442 for ; Wed, 24 Jan 2007 23:15:42 +0000 (UTC) (envelope-from fkraiem@free.fr) Received: from smtp23.orange.fr (mwinf2346 [10.232.4.146]) by mwinf2310.orange.fr (SMTP Server) with ESMTP id 791E21C0DC56 for ; Wed, 24 Jan 2007 21:02:21 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2346.orange.fr (SMTP Server) with ESMTP id 54EBE1C0008D for ; Wed, 24 Jan 2007 21:02:20 +0100 (CET) Received: from ana.fkraiem.org (ABordeaux-256-1-6-52.w86-201.abo.wanadoo.fr [86.201.217.52]) by mwinf2346.orange.fr (SMTP Server) with ESMTP id 2BBAE1C000A6 for ; Wed, 24 Jan 2007 21:02:20 +0100 (CET) X-ME-UUID: 20070124200220179.2BBAE1C000A6@mwinf2346.orange.fr From: Firas Kraiem To: freebsd-stable@freebsd.org User-Agent: KMail/1.9.5 References: <45B7A0FA.1050901@terceirizado.mda.gov.br> In-Reply-To: <45B7A0FA.1050901@terceirizado.mda.gov.br> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 24 Jan 2007 21:02:16 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701242102.17116.fkraiem@free.fr> Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 23:15:42 -0000 On Wednesday 24 January 2007 19:10, Alexandre Vasconcelos wrote: > Hello, > > Working setup: > - FreeBSD 6.2-PRERELEASE, firefox 2 and flash 7 patched with > rtld_dlsym_hack.diff, like suggested on Handbook. > > After 6.2-STABLE upgrade reaplying the rtld_dlsym_hack.diff fails: > > root@alex src]# patch < rtld_dlsym_hack.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 > |+++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 > > -------------------------- > Patching file libexec/rtld-elf/rtld.c using Plan A... > Hunk #1 failed at 129. > Hunk #2 succeeded at 187 (offset 9 lines). > Hunk #3 succeeded at 1820 (offset 82 lines). > 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej > done > > And make fails: > > [root@alex rtld-elf]# make > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/rtld_start.S > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/reloc.c > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/rtld.c > /usr/src/libexec/rtld-elf/rtld.c:189: error: `_dlsym' undeclared here > (not in a function) > /usr/src/libexec/rtld-elf/rtld.c:189: error: initializer element is not > constant > /usr/src/libexec/rtld-elf/rtld.c:189: error: (near initialization for > `exports[4]') > *** Error code 1 > > Stop in /usr/src/libexec/rtld-elf. > > > How to fix this? > Thanks, > Alex > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hello I had the same problem, I've patched the library myself but I don't know how to make a proper "patch file" so if you want, here's my patched one : http://fkraiem.free.fr/rtld.c Copy into /usr/src/libexec/rtld-elf and follow the instructions given in the handbook. -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 23:29:28 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8268316A401 for ; Wed, 24 Jan 2007 23:29:28 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 22ABE13C457 for ; Wed, 24 Jan 2007 23:29:27 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l0ONAnNp005505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 08:10:50 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Thu, 25 Jan 2007 08:10:49 +0900 From: Norikatsu Shigemura To: Torfinn Ingolfsen Message-Id: <20070125081049.ef432569.nork@FreeBSD.org> In-Reply-To: <20070124225107.9db08d9d.torfinn.ingolfsen@broadpark.no> References: <45B7A0FA.1050901@terceirizado.mda.gov.br> <790a9fff0701241036l584c2ae9n52e4834d929b1104@mail.gmail.com> <45B7A937.2020007@terceirizado.mda.gov.br> <7e3339060701241111s674800a4n4210fd756a27f59a@mail.gmail.com> <20070124225107.9db08d9d.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.3.0rc (GTK+ 2.10.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Thu, 25 Jan 2007 08:10:50 +0900 (JST) Cc: freebsd-stable@FreeBSD.org, Norikatsu Shigemura Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 23:29:28 -0000 On Wed, 24 Jan 2007 22:51:07 +0100 Torfinn Ingolfsen wrote: > On Wed, 24 Jan 2007 13:11:16 -0600 > ejc wrote: > > rtld.c has changed a bit over time so here's a patch against the new > > file. > BTW, what is the reason this "hack" isn't included in the base kernel / > code? I suggested new patch. But no response:-(. SEE ALSO: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-January/019360.html From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 23:36:49 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F363716A400 for ; Wed, 24 Jan 2007 23:36:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 815C513C468 for ; Wed, 24 Jan 2007 23:36:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so280037uge for ; Wed, 24 Jan 2007 15:36:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AToOexL8KS+IaELIWQJU9B60eaOv0wVWWUgl3Oqn0Cuk59kqfSOXYeVSIrIe6Le1NSEVO35OnKk7+HQq+vaCscEgvAWpBhlEa7swiOWwXFVaMvmhDwLCc0tVqzb0d6YNF8VppCuBLafehsUskgavK8Q2dIlWMV3KZLjaeH4qMug= Received: by 10.82.169.4 with SMTP id r4mr573285bue.1169681807126; Wed, 24 Jan 2007 15:36:47 -0800 (PST) Received: by 10.82.127.12 with HTTP; Wed, 24 Jan 2007 15:36:47 -0800 (PST) Message-ID: <2a41acea0701241536y18826df0u3c27da5e7d611a0e@mail.gmail.com> Date: Wed, 24 Jan 2007 15:36:47 -0800 From: "Jack Vogel" To: "Gavin Atkinson" In-Reply-To: <1169640897.59181.20.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> <1169640897.59181.20.camel@buffy.york.ac.uk> Cc: Bill Paul , jon.otterholm@ide.resurscentrum.se, Gleb Smirnoff , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 23:36:49 -0000 On 1/24/07, Gavin Atkinson wrote: > On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote: > > On 1/22/07, Gleb Smirnoff wrote: > > > Jack, > > > > > > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: > > > J> >> Since this was just seen, and the patch below validated as working I > > > J> >wanted > > > J> >> to send general email to capture this: > > > J> >> > > > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN > > > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > > > J> >> not been decided on yet. Nevertheless, the patch below will work, but > > > J> >> I do not want to check it in as its still temporary. > > > J> >> > > > J> >> Address questions to me, > > > J> > > > > J> >Okay, I have a question. Could you elaborate on just what the problem is? > > > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time figuring > > > J> >out what problem could possibly be fixed by setting the RX interrupt > > > J> >delay timer to a non-zero value (especially since elsewhere in the em(4) > > > J> >source it says that doing so is a Bad Thing (tm)). > > > J> > > > J> saying its known to be a problem doesnt mean its cause is known :) > > > J> They discovered that setting this eliminated the problem, but we > > > J> immediately pointed out that this is, as you pointed out, a Bad > > > J> Thing on other hardware, so the investigation continues, there is > > > J> always a communication lag on these kind of things, so I dont know > > > J> if it has been resolved yet or not. > > > J> > > > J> I just dont think this patch will become the final way to solve this, > > > J> but we shall see :) > > > > > > Good to know that there is progress on this. Thanks! I will try the patch > > > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it > > > is present on any Lenovo notebook with 82573 NIC. > > > > > > Can you please acknowledge that another bug with Lenovo + em(4) is known? I > > > mean the problem, that em(4) isn't initialized properly on kernel boot, if > > > the link is down. I have already reported this to you, and you said that > > > I probably have bad hardware. Since that time, I've found several similar > > > reports about Lenovo notebooks and em(4) driver in FreeBSD. > > > > Hey Gleb, > > > > Acknowledge... I can do better than that, I have a fix for this problem, and > > its not temporary. Here is the code change (not a patch, I'm very busy), > > its in hardware_init, should be obvious how to patch: > > > > /* Make sure we have a good EEPROM before we read from it */ > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > /* > > ** Some PCI-E parts fail the first check due to > > ** the link being in sleep state, call it again, > > ** if it fails a second time its a real issue. > > */ > > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > > device_printf(dev, > > "The EEPROM Checksum Is Not Valid\n"); > > return (EIO); > > } > > } > > > > This is already checked into my code base at Intel, I've just been too > > busy to do anything with it, be my guest if you wish to check it in after > > testing... > > Just to add another datapoint - and for the archives - this also appears > to fix an issue with the Toshiba Tecra M5L. The "EEPROM Checksum Is Not > Valid" message would appear on boot if there was no link on the > interface, although the interface would appear to work fine from then > on. With this patch, the message no longer appears. > > I also have problems with connections to networks (only seen when > connected to 10 meg half duplex hubs) with long delays on some packets > (which I'm assuming is the issue that started this thread) - I haven't > been able to verify yet that either patch fixes that, though. Nice to know its fixing more than expected. Let me know about the last issue when you verify it. Crises have me consumed at work right now, will try to get time to commit by this weekend. Jack From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 00:08:58 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D6ED16A400 for ; Thu, 25 Jan 2007 00:08:58 +0000 (UTC) (envelope-from applecom@inbox.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.64]) by mx1.freebsd.org (Postfix) with ESMTP id E5AD213C45A for ; Thu, 25 Jan 2007 00:08:57 +0000 (UTC) (envelope-from applecom@inbox.ru) Received: from [85.115.165.63] (port=9797 helo=xml.opera.com) by mx27.mail.ru with asmtp id 1H9sAi-000K0j-00 for freebsd-stable@freebsd.org; Thu, 25 Jan 2007 03:08:56 +0300 Date: Thu, 25 Jan 2007 05:08:55 +0500 To: freebsd-stable@freebsd.org From: applecom@inbox.ru Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Message-ID: User-Agent: Opera Mail/9.10 (FreeBSD) Subject: 'make depend' fails with 'device viapm' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 00:08:58 -0000 I've just updated the sources and tried to rebuild kernel with 'device v= iapm' in kernel configuration file. 'make depend' fails: <..> awk -f ../../../tools/makeobjops.awk ../../../kern/device_if.m -h awk -f ../../../tools/makeobjops.awk ../../../kern/linker_if.m -h awk -f ../../../tools/makeobjops.awk ../../../dev/acpica/acpi_if.m -h rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=3D"cc -E" CC=3D= "cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=3Dc3 -Wall -= Wredundant- decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoint= er-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -= I. -I../../ .. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contri= b/pf -I. ./../../dev/ath -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -D= HAVE_KER NEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D80= 00 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -mno-al= ign-long-stri ngs -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-ss= e2 -ffrees tanding ../../../pci/viapm.c:55:22: iicbb_if.h: No such file or directory mkdep: compile failed *** Error code 1 My kernel configuration file: machine i386 cpu I686_CPU device isa device pci device agp device npx device io ident LOCALHOST options SCHED_4BSD options COMPAT_43 options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options SYSVSHM options SYSVMSG options SYSVSEM options INET device loop device bpf device ether device ppp options IPFIREWALL options FFS options PROCFS options PSEUDOFS options SOFTUPDATES options UFS_DIRHASH device random device mem device scbus device da device cd device pass device pty device atkbdc device atkbd device psm device vga device sc device ata device atadisk device atapicd options ATA_STATIC_ID device fdc device sio device miibus device vr device sound device snd_via8233 device smbus device smb device viapm device uhci device ehci device usb device ugen device ulpt device umass From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 03:43:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7813816A401 for ; Thu, 25 Jan 2007 03:43:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by mx1.freebsd.org (Postfix) with ESMTP id 44B9413C465 for ; Thu, 25 Jan 2007 03:43:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (failure[71.198.0.135]) by comcast.net (sccrmhc13) with ESMTP id <2007012503431401300i0sl1e>; Thu, 25 Jan 2007 03:43:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F1D841FA037; Wed, 24 Jan 2007 19:43:03 -0800 (PST) Date: Wed, 24 Jan 2007 19:43:03 -0800 From: Jeremy Chadwick To: applecom@inbox.ru Message-ID: <20070125034303.GA20539@icarus.home.lan> Mail-Followup-To: applecom@inbox.ru, freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: 'make depend' fails with 'device viapm' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 03:43:15 -0000 On Thu, Jan 25, 2007 at 05:08:55AM +0500, applecom@inbox.ru wrote: > I've just updated the sources and tried to rebuild kernel with 'device viapm' > in kernel configuration file. 'make depend' fails: You're missing the iicbus, iicbb, and iicsmb drivers. Taken from my kernel config: ## Power management controllers / hardware monitoring ## device smbus ## SMBus support device viapm ## VIA PM -- for hardware monitoring device smb ## SMBus support device iicbus ## I2C bus support (needed for I2C) device iicbb ## I2C bit-banging driver device iicsmb ## SMBus over I2C bridge -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 06:55:54 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A59016A401; Thu, 25 Jan 2007 06:55:54 +0000 (UTC) (envelope-from applecom@inbox.ru) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by mx1.freebsd.org (Postfix) with ESMTP id CC23F13C47E; Thu, 25 Jan 2007 06:55:53 +0000 (UTC) (envelope-from applecom@inbox.ru) Received: from mx2.mail.ru (mx2-2.mail.ru [194.67.23.122]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id A94B082B38A; Thu, 25 Jan 2007 06:45:56 +0300 (MSK) Received: from [85.115.165.63] (port=4196 helo=xml.opera.com) by mx2.mail.ru with asmtp id 1H9vYg-0009Ot-00; Thu, 25 Jan 2007 06:45:54 +0300 To: "Jeremy Chadwick" From: applecom@inbox.ru Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 References: <20070125034303.GA20539@icarus.home.lan> Content-Transfer-Encoding: 7bit Date: Thu, 25 Jan 2007 08:45:52 +0500 Message-ID: In-Reply-To: <20070125034303.GA20539@icarus.home.lan> User-Agent: Opera Mail/9.10 (FreeBSD) Cc: stable@freebsd.org Subject: Re: 'make depend' fails with 'device viapm' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 06:55:54 -0000 Jeremy Chadwick wrote: > You're missing the iicbus, iicbb, and iicsmb drivers. Yeah, of course, thank you. Sorry. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 07:30:03 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B68F16A400 for ; Thu, 25 Jan 2007 07:30:02 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.datadok.no (skapet.datadok.no [194.54.107.19]) by mx1.freebsd.org (Postfix) with ESMTP id ACCCC13C448 for ; Thu, 25 Jan 2007 07:30:02 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from thingy.bsdly.net ([10.168.103.11] helo=thingy.datadok.no.bsdly.net ident=peter) by skapet.datadok.no with esmtp (Exim 4.62) (envelope-from ) id 1H9yjB-00024U-QD for freebsd-stable@freebsd.org; Thu, 25 Jan 2007 08:08:58 +0100 To: freebsd-stable@freebsd.org References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> From: peter@bsdly.net (Peter N. M. Hansteen) Date: Thu, 25 Jan 2007 08:08:55 +0100 In-Reply-To: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> (Gustavo Feij's message of "Wed, 24 Jan 2007 15:03:06 -0200") Message-ID: <87ps93poqg.fsf@thingy.datadok.no> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 07:30:03 -0000 For purposes of making the subject less true, setting up greylisting with an optional tarpit for known baddies can be very effective. See Dan Langille's recent Onlamp article[1] or for that matter my tutorial[2] for how this is done using PF and spamd - this way it doesn't matter much which MTA(s) you use. [1] http://www.onlamp.com/pub/a/bsd/2007/01/18/greylisting-with-pf.html [2] http://home.nuug.no/~peter/pf/en/, with the specifics of spamd and greylisting starting at http://home.nuug.no/~peter/pf/en/spamd.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 10:29:02 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C77D216A401 for ; Thu, 25 Jan 2007 10:29:02 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2A713C45B for ; Thu, 25 Jan 2007 10:29:01 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0PASJ6d020354; Thu, 25 Jan 2007 08:28:20 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Thu, 25 Jan 2007 08:28:50 -0300 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <87ps93poqg.fsf@thingy.datadok.no> In-Reply-To: <87ps93poqg.fsf@thingy.datadok.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701250828.50540.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Peter N. M. Hansteen" Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 10:29:02 -0000 On Thursday 25 January 2007 04:08, Peter N. M. Hansteen wrote: > For purposes of making the subject less true, setting up greylisting > with an optional tarpit for known baddies can be very effective. See > Dan Langille's recent Onlamp article[1] or for that matter my tutorial[2] > for how this is done using PF and spamd - this way it doesn't matter much > which MTA(s) you use. > > [1] http://www.onlamp.com/pub/a/bsd/2007/01/18/greylisting-with-pf.html > [2] http://home.nuug.no/~peter/pf/en/, with the specifics of spamd and > greylisting starting at http://home.nuug.no/~peter/pf/en/spamd.html all this methods are certainly useless, stay calm ok the only way to block spam really is blocking any incoming tcp:25 ... any firewall based method you may use do block innocents as well, ike some = do=20 they block entire IP ranges from countries because most spam comes from the= m,=20 that is stupid, more brainless since the spam mostly is not generated by an= y=20 of this servers, it only goes through it, this method might cause *you* not= =20 getting this spam but does not stop spam at all ... probably better, if you like firewall blocks, cutting the complete US IP=20 address space from sending to any tcp:25 to stop spam definitly, because I= =20 never heard of chinese or african viagra hahahaha spam block list abviously are very usefull so long as they are maintained IMO a good way and probably the best way is to do some inicial checks like= =20 connection rate and limit them, then a spam checker like spamassassin for=20 regex and header checks still you get SPAM and you never can block spam 100%, spammers change serve= rs,=20 IPs, patterns faster then we can react, but we all know this right?=20 and even then if you get it all into your box you still get spam by whom se= nds=20 it out without caring of identity or hiding it, a correct email msg but spam where spam needs to be catched is at the origin, ISPs should take care of t= his=20 problem by not permitting access to outside servers but only passing throug= h=20 their smtp gateways, an outgoing spam check is what needs to be done but =20 here nobody cares ... =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 11:07:25 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B588616A402; Thu, 25 Jan 2007 11:07:25 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id 42FDE13C448; Thu, 25 Jan 2007 11:07:24 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0PB7MNc004552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 12:07:22 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0PB7Muw004551; Thu, 25 Jan 2007 12:07:22 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Thu, 25 Jan 2007 12:07:22 +0100 Message-ID: <20070125120722.si80d0rao8o8ow8w@server.yirdis.net> Date: Thu, 25 Jan 2007 12:07:22 +0100 From: Robin Gruyters To: Jeremy Chadwick References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> <20070124150143.GA8460@icarus.home.lan> In-Reply-To: <20070124150143.GA8460@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 11:07:25 -0000 Quoting Jeremy Chadwick : [...] > > Set your Cisco configuration to use 100/full, and edit the > ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media > 100baseTX mediaopt full-duplex", then reboot the FreeBSD box. > If the problem continues, there may be faulty cabling, but > usually errors on one direction are a sign of duplex mismatch. > If after replacing the cabling the issue continues, then there's > a chance the bge(4) driver may be obtaining statistics wrong for > the particular chip revision being used (this is hearsay on my > part; I'm just guessing...) > Ok, I have set the Cisco port to 100/full-duplex and update the bge* interfaces on the development server, but the problem still exists. I have also updated the other server, which is connected to another Cisco switch, but the same results. Regards, Robin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 11:11:48 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CDCB16A400 for ; Thu, 25 Jan 2007 11:11:48 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from mail.coruscant.info (coruscant.coruscant.info [88.198.12.237]) by mx1.freebsd.org (Postfix) with ESMTP id EC17013C45D for ; Thu, 25 Jan 2007 11:11:47 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from localhost (localhost [127.0.0.1]) by mail.coruscant.info (Postfix) with SMTP id 28E3A3CC548 for ; Thu, 25 Jan 2007 12:13:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.coruscant.info (Postfix) with ESMTP id 39FC93CC547; Thu, 25 Jan 2007 12:13:08 +0100 (CET) X-Virus-Scanned: amavisd-new at coruscant.info Received: from mail.coruscant.info ([127.0.0.1]) by localhost (mail.coruscant.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj4KefaZuoxn; Thu, 25 Jan 2007 12:13:04 +0100 (CET) Received: from [192.168.2.4] (p508B4E91.dip.t-dialin.net [80.139.78.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coruscant.info (Postfix) with ESMTP id 48D1E3CC4AF; Thu, 25 Jan 2007 12:13:04 +0100 (CET) Message-ID: <45B8906F.7000807@ninth-art.de> Date: Thu, 25 Jan 2007 12:11:43 +0100 From: Georg Bege User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: JoaoBR References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <87ps93poqg.fsf@thingy.datadok.no> <200701250828.50540.joao@matik.com.br> In-Reply-To: <200701250828.50540.joao@matik.com.br> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=5717E214; url=http://www.ninth-art.de/files/therion.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 25 12:13:08 2007 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 45b890c4896261974110222 X-DSPAM-Factors: 27, From*ninth+art.de>, 0.40000, N+M, 0.40000, References*<8a20e5000701240903q35b89e14k1ab977df62411784, 0.40000, spam, 0.40000, spam, 0.40000, but, 0.40000, but, 0.40000, Received*(localhost+[127.0.0.1]), 0.40000, still+get, 0.40000, just, 0.40000, generated+by, 0.40000, greylisting, 0.40000, greylisting, 0.40000, all+>, 0.40000, made, 0.40000, Received*localhost, 0.40000, Received*localhost, 0.40000, >+spam, 0.40000, Received*dialin.net, 0.40000, be+very, 0.40000, X-Virus-Scanned*new, 0.40000, based+method, 0.40000, or, 0.40000, or, 0.40000, methods, 0.40000, never, 0.40000, never, 0.40000 Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: therion@ninth-art.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 11:11:48 -0000 Woah you just made my day Saying dspam or greylisting is useless ;) I hope you mean that by ironic - no you cannot block 100% spam but 99.99% effectivly which I already do even productive. But not with sendmail (who is using sendmail these days?) cheers JoaoBR wrote: > On Thursday 25 January 2007 04:08, Peter N. M. Hansteen wrote: >> For purposes of making the subject less true, setting up greylisting >> with an optional tarpit for known baddies can be very effective. See >> Dan Langille's recent Onlamp article[1] or for that matter my tutorial[2] >> for how this is done using PF and spamd - this way it doesn't matter much >> which MTA(s) you use. >> >> [1] http://www.onlamp.com/pub/a/bsd/2007/01/18/greylisting-with-pf.html >> [2] http://home.nuug.no/~peter/pf/en/, with the specifics of spamd and >> greylisting starting at http://home.nuug.no/~peter/pf/en/spamd.html > > > all this methods are certainly useless, stay calm ok > > the only way to block spam really is blocking any incoming tcp:25 ... > > any firewall based method you may use do block innocents as well, ike some do > they block entire IP ranges from countries because most spam comes from them, > that is stupid, more brainless since the spam mostly is not generated by any > of this servers, it only goes through it, this method might cause *you* not > getting this spam but does not stop spam at all ... > > probably better, if you like firewall blocks, cutting the complete US IP > address space from sending to any tcp:25 to stop spam definitly, because I > never heard of chinese or african viagra hahahaha > > spam block list abviously are very usefull so long as they are maintained > > IMO a good way and probably the best way is to do some inicial checks like > connection rate and limit them, then a spam checker like spamassassin for > regex and header checks > > still you get SPAM and you never can block spam 100%, spammers change servers, > IPs, patterns faster then we can react, but we all know this right? > > and even then if you get it all into your box you still get spam by whom sends > it out without caring of identity or hiding it, a correct email msg but spam > > where spam needs to be catched is at the origin, ISPs should take care of this > problem by not permitting access to outside servers but only passing through > their smtp gateways, an outgoing spam check is what needs to be done but > here nobody cares ... > -- Georg 'Therion' Bege http://coruscant.info http://www.ninth-art.de therion@ninth-art.de GnuPG-Key-ID: 0x5717E214 FingerPrint: A8EC B4B2 C9A9 483B CC87 56EE 07A1 C78E 5717 E214 !DSPAM:45b890c4896261974110222! From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 11:58:45 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C27C316A401 for ; Thu, 25 Jan 2007 11:58:45 +0000 (UTC) (envelope-from estartu@etustar.ze.tum.de) Received: from titan.ze.tum.de (titan.ze.tum.de [129.187.39.12]) by mx1.freebsd.org (Postfix) with ESMTP id 534A813C448 for ; Thu, 25 Jan 2007 11:58:44 +0000 (UTC) (envelope-from estartu@etustar.ze.tum.de) Received: from etustar.ze.tum.de (etustar.ze.tum.de [129.187.39.96]) by titan.ze.tum.de (8.13.4/8.12.10) with ESMTP id l0PBRtdP019336; Thu, 25 Jan 2007 12:27:55 +0100 (CET) (envelope-from estartu@etustar.ze.tum.de) Received: from etustar.ze.tum.de (localhost [127.0.0.1]) by etustar.ze.tum.de (8.13.8/8.13.6) with ESMTP id l0PBS1Tb043426; Thu, 25 Jan 2007 12:28:01 +0100 (CET) (envelope-from estartu@etustar.ze.tum.de) Received: (from estartu@localhost) by etustar.ze.tum.de (8.13.8/8.13.6/Submit) id l0PBS1Ds043425; Thu, 25 Jan 2007 12:28:01 +0100 (CET) (envelope-from estartu) Date: Thu, 25 Jan 2007 12:28:01 +0100 From: Gerhard Schmidt To: Georg Bege Message-ID: <20070125112801.GA43212@augusta.de> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <87ps93poqg.fsf@thingy.datadok.no> <200701250828.50540.joao@matik.com.br> <45B8906F.7000807@ninth-art.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <45B8906F.7000807@ninth-art.de> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, JoaoBR Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 11:58:45 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 25, 2007 at 12:11:43PM +0100, Georg Bege wrote: > Woah you just made my day >=20 > Saying dspam or greylisting is useless ;) > I hope you mean that by ironic - > no you cannot block 100% spam but 99.99% effectivly which I already do > even productive. > But not with sendmail (who is using sendmail these days?) I do, and I have a hitquote arounf 99% as well. I'm using spamassassin and greylisting. Works pretty good.=20 Filter/Tagging spam isn't a MTA problem, it's a configuration problem. You can do anything on any MTA.=20 bye Estartu -- ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request=20 Germany | | =20 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iQCVAwUBRbiUQQzx22nOTJQRAQIpdAP+Kv1pyWWanvakR+QFYGGx0S6N00Sp3yrA VbdE6BFrF42IvmEDOARr6Vkx18G10jiE6ZtupoC8zyCDn/C00+Kr7YIgVOPCmJSB yNkuUYwSbW0ChpWqBhE2ofjxGzdnApldZvHQuBfCyhBLajBE5EAaiSA+9ZaxdfKA zhKiczyVJFc= =hXJw -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 13:07:58 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 497A816A402 for ; Thu, 25 Jan 2007 13:07:58 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from miram.origin-it.net (mail.de.atosorigin.com [194.8.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id CC4BA13C4A5 for ; Thu, 25 Jan 2007 13:07:57 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from markab.hbg.de.int.atosorigin.com (avior.origin-it.net [213.70.176.177]) by miram.origin-it.net (8.13.8/8.13.8/hmo020206) with ESMTP id l0PD7tpf047971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 14:07:55 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from DEHHX001.deuser.de.intra (dehhx001.hbg.de.int.atosorigin.com [161.90.164.119]) by markab.hbg.de.int.atosorigin.com (8.13.8/8.13.8/hmo020206) with ESMTP id l0PD7sPo056048; Thu, 25 Jan 2007 14:07:54 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 25 Jan 2007 14:07:51 +0100 Message-ID: <39AFDF50473FED469B15B6DFF2262F7A028D30A0@DEHHX001.deuser.de.intra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 6.2-STABLE and Flash 7 patch Thread-Index: AcdAAjoYuDfn1jzXRmS4AqGsp6So9gAfvi0g From: To: , X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (miram.origin-it.net [194.8.96.226]); Thu, 25 Jan 2007 14:07:55 +0100 (CET) Cc: Subject: RE: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 13:07:58 -0000 Torfinn Ingolfsen <> wrote on Wednesday, January 24, 2007 10:51 PM: > On Wed, 24 Jan 2007 13:11:16 -0600 > ejc wrote: >=20 >> rtld.c has changed a bit over time so here's a patch against the new >> file. >=20 > BTW, what is the reason this "hack" isn't included in the base kernel > / code? Because it is probably unnecessary? I run a recent 6-STABLE and use the = flash7 plugin *without* this patch. I am using Opera, though, not = Firefox... Helge From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 13:18:59 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23B5A16A401 for ; Thu, 25 Jan 2007 13:18:59 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.datadok.no (skapet.datadok.no [194.54.107.19]) by mx1.freebsd.org (Postfix) with ESMTP id B3AC513C45E for ; Thu, 25 Jan 2007 13:18:58 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from thingy.datadok.no ([194.54.103.97] helo=thingy.datadok.no.bsdly.net ident=peter) by skapet.datadok.no with esmtp (Exim 4.62) (envelope-from ) id 1HA4VE-0004Hp-W5; Thu, 25 Jan 2007 14:18:57 +0100 To: JoaoBR References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <87ps93poqg.fsf@thingy.datadok.no> <200701250828.50540.joao@matik.com.br> From: peter@bsdly.net (Peter N. M. Hansteen) Date: Thu, 25 Jan 2007 14:18:52 +0100 In-Reply-To: <200701250828.50540.joao@matik.com.br> (JoaoBR's message of "Thu, 25 Jan 2007 08:28:50 -0300") Message-ID: <87ac074537.fsf@thingy.datadok.no> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 13:18:59 -0000 JoaoBR writes: > all this methods are certainly useless, stay calm ok I fully sympathize with your need to rant, but in this context most of what you say is really quite beside the point. Please read what the material at the links provided actually says. > any firewall based method you may use do block innocents as well, ike some do > they block entire IP ranges from countries because most spam comes from them, Blocking entire subnets is generally not useful, and unmaintained blacklists are worse than useless. Which exactly is why I advocate using spamd in pure greylisting mode, possibly supplemented with aggressively maintained blacklists such as Bob Beck's traplist and potentially with local greytrapping. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 13:39:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78DB216A402 for ; Thu, 25 Jan 2007 13:39:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [206.18.177.51]) by mx1.freebsd.org (Postfix) with ESMTP id 5036413C44B for ; Thu, 25 Jan 2007 13:39:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (alnrmhc11) with ESMTP id <20070125133905b11000t8pse>; Thu, 25 Jan 2007 13:39:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CDA7C1FA037; Thu, 25 Jan 2007 05:39:04 -0800 (PST) Date: Thu, 25 Jan 2007 05:39:04 -0800 From: Jeremy Chadwick To: Robin Gruyters Message-ID: <20070125133904.GA30161@icarus.home.lan> Mail-Followup-To: Robin Gruyters , freebsd-stable@FreeBSD.org References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> <20070124150143.GA8460@icarus.home.lan> <20070125120722.si80d0rao8o8ow8w@server.yirdis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070125120722.si80d0rao8o8ow8w@server.yirdis.net> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 13:39:09 -0000 On Thu, Jan 25, 2007 at 12:07:22PM +0100, Robin Gruyters wrote: > Quoting Jeremy Chadwick : > [...] > > > >Set your Cisco configuration to use 100/full, and edit the > >ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media > >100baseTX mediaopt full-duplex", then reboot the FreeBSD box. > >If the problem continues, there may be faulty cabling, but > >usually errors on one direction are a sign of duplex mismatch. > >If after replacing the cabling the issue continues, then there's > >a chance the bge(4) driver may be obtaining statistics wrong for > >the particular chip revision being used (this is hearsay on my > >part; I'm just guessing...) > > > Ok, I have set the Cisco port to 100/full-duplex and update the bge* > interfaces on the development server, but the problem still exists. > > I have also updated the other server, which is connected to another > Cisco switch, but the same results. Okay so at least we know it's not specific to your switch, or to auto-neg nor the cabling (two different switches + boxes with the same problem probably isn't your fault. :) ). That's definitely evidence that it's a driver problem, probably specific to the 5704 (since I have two machines using 5750s without this problem). Looks like we'll need someone with the Broadcom data sheet for the 5704 to help out. There's also the Bill Paul and David Christensen (who worked on bce(4), but might know of some details here...) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 14:29:39 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FF1C16A401 for ; Thu, 25 Jan 2007 14:29:39 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB9B13C45D for ; Thu, 25 Jan 2007 14:29:38 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so840294nfc for ; Thu, 25 Jan 2007 06:29:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sRGih5EP1M1+PxMx6EE2oC0zKwrjJH9EdVLSW/105zXAJUC+XfXJB/ETIVHsGy3r+0TJZoJjYMFSK2mvqTqHiN86wHTs8d4PVtUOPa1vNJDRZSYBKIONhwopsOPvFHMnTQKcjuVrVF6tEZkFLnhTXbSUc33YZVgLZ5Ec4NS4Cuo= Received: by 10.48.202.14 with SMTP id z14mr4280573nff.1169733706761; Thu, 25 Jan 2007 06:01:46 -0800 (PST) Received: by 10.66.220.12 with HTTP; Thu, 25 Jan 2007 06:01:46 -0800 (PST) Message-ID: Date: Thu, 25 Jan 2007 12:01:46 -0200 From: "Eduardo Meyer" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Bridging problems on IP address conflict X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 14:29:39 -0000 Hello, I have the following bridge setups: bridge0: flags=8043 mtu 1500 ether ac:de:48:df:0d:8c priority 32768 hellotime 2 fwddelay 15 maxage 20 member: fxp0 flags=3 member: em0 flags=3 bridge1: flags=8043 mtu 1500 ether ac:de:48:fe:cd:41 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: xl1 flags=3 member: xl0 flags=3 And my system constantly reports: arp: 00:13:20:1c:33:22 is using my IP address XX.YY.ZZ.KK! several (thoundsands of) times. In fact this ARP is my own fxp0 interface, and this is the only interface that has this IP. What should I do? Ass IP on the bridge0 interface instead of the fxp0 bridge member? Or anything else? -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 14:46:07 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 685A016A407; Thu, 25 Jan 2007 14:46:07 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id CF3C513C45A; Thu, 25 Jan 2007 14:46:06 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0PEk1x1027582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 15:46:01 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l0PEk1du027581; Thu, 25 Jan 2007 15:46:01 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Thu, 25 Jan 2007 15:46:01 +0100 Message-ID: <20070125154601.5kyq29pqgow8kwwk@server.yirdis.net> Date: Thu, 25 Jan 2007 15:46:01 +0100 From: Robin Gruyters To: Jeremy Chadwick References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> <20070124150143.GA8460@icarus.home.lan> <20070125120722.si80d0rao8o8ow8w@server.yirdis.net> <20070125133904.GA30161@icarus.home.lan> In-Reply-To: <20070125133904.GA30161@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 14:46:07 -0000 Quoting Jeremy Chadwick : > On Thu, Jan 25, 2007 at 12:07:22PM +0100, Robin Gruyters wrote: >> Quoting Jeremy Chadwick : >> [...] >> > >> >Set your Cisco configuration to use 100/full, and edit the >> >ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media >> >100baseTX mediaopt full-duplex", then reboot the FreeBSD box. >> >If the problem continues, there may be faulty cabling, but >> >usually errors on one direction are a sign of duplex mismatch. >> >If after replacing the cabling the issue continues, then there's >> >a chance the bge(4) driver may be obtaining statistics wrong for >> >the particular chip revision being used (this is hearsay on my >> >part; I'm just guessing...) >> > >> Ok, I have set the Cisco port to 100/full-duplex and update the bge* >> interfaces on the development server, but the problem still exists. >> >> I have also updated the other server, which is connected to another >> Cisco switch, but the same results. > > Okay so at least we know it's not specific to your switch, or > to auto-neg nor the cabling (two different switches + boxes with > the same problem probably isn't your fault. :) ). That's definitely > evidence that it's a driver problem, probably specific to the 5704 > (since I have two machines using 5750s without this problem). > > Looks like we'll need someone with the Broadcom data sheet for > the 5704 to help out. There's also the Bill Paul > and David Christensen (who worked on bce(4), > but might know of some details here...) > Hmmm, ok. BTW, I found out there another thread going on on the =20 freebsd-net mailinglist about the same issue(s): http://marc.theaimsgroup.com/?l=3Dfreebsd-net&w=3D2&r=3D1&s=3Dbge+ierr&q=3Db There are some patches available, but looks like only for the -CURRENT =20 not for 6.x releases. Regards, Robin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 15:24:05 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11BB016A412 for ; Thu, 25 Jan 2007 15:24:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by mx1.freebsd.org (Postfix) with ESMTP id EF14A13C4BB for ; Thu, 25 Jan 2007 15:24:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (rwcrmhc15) with ESMTP id <20070125152404m1500l7h51e>; Thu, 25 Jan 2007 15:24:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C9CEC1FA038; Thu, 25 Jan 2007 07:24:03 -0800 (PST) Date: Thu, 25 Jan 2007 07:24:03 -0800 From: Jeremy Chadwick To: Robin Gruyters Message-ID: <20070125152403.GA32099@icarus.home.lan> Mail-Followup-To: Robin Gruyters , freebsd-stable@FreeBSD.org References: <20070124105741.cj2htvoxcs4gg8wk@server.yirdis.net> <20070124141737.GA7772@icarus.home.lan> <20070124152537.gk06yc8d3k8gwgo0@server.yirdis.net> <20070124150143.GA8460@icarus.home.lan> <20070125120722.si80d0rao8o8ow8w@server.yirdis.net> <20070125133904.GA30161@icarus.home.lan> <20070125154601.5kyq29pqgow8kwwk@server.yirdis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070125154601.5kyq29pqgow8kwwk@server.yirdis.net> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@FreeBSD.org Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 15:24:05 -0000 On Thu, Jan 25, 2007 at 03:46:01PM +0100, Robin Gruyters wrote: > Hmmm, ok. BTW, I found out there another thread going on on the > freebsd-net mailinglist about the same issue(s): > > http://marc.theaimsgroup.com/?l=freebsd-net&w=2&r=1&s=bge+ierr&q=b > > There are some patches available, but looks like only for the -CURRENT > not for 6.x releases. Definitely related, and probably the cause. I hope someone backports this to RELENG_6 once everything is tested thoroughly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 15:36:35 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C14416A402 for ; Thu, 25 Jan 2007 15:36:35 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4261513C46A for ; Thu, 25 Jan 2007 15:36:35 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HA6eP-0006ng-Os for freebsd-stable@FreeBSD.ORG; Thu, 25 Jan 2007 15:36:33 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HA6eP-000Fbi-E9 for freebsd-stable@FreeBSD.ORG; Thu, 25 Jan 2007 15:36:33 +0000 To: freebsd-stable@FreeBSD.ORG Message-Id: From: Pete French Date: Thu, 25 Jan 2007 15:36:33 +0000 Cc: Subject: Netgraph at startup - rc.conf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 15:36:35 -0000 I have a machine with two interfaces in it - bge0 and beg1. I now find I need to usse ng_fec to make these into one interface due to the way out networking contractors are installign a new site. Seems like no problem from the command line, but what I can't find anywhere in the documentation is how to make this happen at boot time using rc.conf. I am assuming my line which looks like: ifconfig_em0="inet 172.16.1.6 netmask 255.255.0.0" becomes ifconfig_fec0="inet 172.16.1.6 netmask 255.255.0.0" but obviously I need to do something to create fec0 before that happens. Preseumably something like cloned_interfaces="fce0", but where does it get the parameters from to create the interface ? cheers, -pcf. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 15:53:09 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF53316A405 for ; Thu, 25 Jan 2007 15:53:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7935913C448 for ; Thu, 25 Jan 2007 15:53:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (gfelop@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0PFquxe030873; Thu, 25 Jan 2007 16:53:01 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0PFqugQ030872; Thu, 25 Jan 2007 16:52:56 +0100 (CET) (envelope-from olli) Date: Thu, 25 Jan 2007 16:52:56 +0100 (CET) Message-Id: <200701251552.l0PFqugQ030872@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, torfinn.ingolfsen@broadpark.no, Helge.Oldach@atosorigin.com In-Reply-To: <39AFDF50473FED469B15B6DFF2262F7A028D30A0@DEHHX001.deuser.de.intra> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 25 Jan 2007 16:53:02 +0100 (CET) Cc: Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, torfinn.ingolfsen@broadpark.no, Helge.Oldach@atosorigin.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 15:53:10 -0000 Helge.Oldach@atosorigin.com wrote: > Torfinn Ingolfsen wrote: > > BTW, what is the reason this "hack" isn't included in the base kernel > > / code? > > Because it is probably unnecessary? I run a recent 6-STABLE and use > the flash7 plugin *without* this patch. I am using Opera, though, not > Firefox... Same here. I use Opera with the Flash plugin on 6-STABLE without any problems. I haven't applied a patch to rtld. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 16:14:28 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6AD316A400; Thu, 25 Jan 2007 16:14:28 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD2013C459; Thu, 25 Jan 2007 16:14:28 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l0PGEQcd081710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 01:14:27 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Fri, 26 Jan 2007 01:14:26 +0900 From: Norikatsu Shigemura To: Pete French Message-Id: <20070126011426.d7950892.nork@FreeBSD.org> In-Reply-To: References: X-Mailer: Sylpheed 2.3.0rc (GTK+ 2.10.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Fri, 26 Jan 2007 01:14:27 +0900 (JST) Cc: freebsd-stable@FreeBSD.org, Norikatsu Shigemura Subject: Re: Netgraph at startup - rc.conf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 16:14:28 -0000 On Thu, 25 Jan 2007 15:36:33 +0000 Pete French wrote: > I have a machine with two interfaces in it - bge0 and beg1. I now > find I need to usse ng_fec to make these into one interface due to > the way out networking contractors are installign a new site. > Seems like no problem from the command line, but what I can't > find anywhere in the documentation is how to make this happen > at boot time using rc.conf. I am assuming my line which > looks like: > ifconfig_em0="inet 172.16.1.6 netmask 255.255.0.0" > becomes > ifconfig_fec0="inet 172.16.1.6 netmask 255.255.0.0" > but obviously I need to do something to create fec0 before > that happens. Preseumably something like cloned_interfaces="fce0", > but where does it get the parameters from to create the interface ? SEE ALSO: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/104884 If you apply this patch, you can use ng_fec like following in your /etc/rc.conf: fec_interfaces="fec0" fecconfig_fec0="bge0 bge1" ifconfig_fec0="inet 172.16.1.6 netmask 255.255.0.0" From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 16:14:52 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 131CF16A4AC for ; Thu, 25 Jan 2007 16:14:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9B66113C441 for ; Thu, 25 Jan 2007 16:14:51 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so457220uge for ; Thu, 25 Jan 2007 08:14:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nj4+aeXoplV7QXbvAdZyHXCCAeLlXp/HmLIAwBeUjXwFUD64pI16ImOEn+mnLfrnad5OMvDLLoBGIgZFhsswAAwiWWnS+X77tZOJsolJnVJrrOuTIWHHEExWQfL4Ti3ms3x68nTaG+sAuASD8IOqMYsRFUo+dF9ZuxDS2bOYJGE= Received: by 10.82.120.15 with SMTP id s15mr1218905buc.1169741690127; Thu, 25 Jan 2007 08:14:50 -0800 (PST) Received: by 10.82.186.2 with HTTP; Thu, 25 Jan 2007 08:14:50 -0800 (PST) Message-ID: <790a9fff0701250814q3ad4ded4tf3e740075c2f61d1@mail.gmail.com> Date: Thu, 25 Jan 2007 10:14:50 -0600 From: "Scot Hetzel" To: "Pete French" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-stable@freebsd.org Subject: Re: Netgraph at startup - rc.conf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 16:14:52 -0000 On 1/25/07, Pete French wrote: > I have a machine with two interfaces in it - bge0 and beg1. I now > find I need to usse ng_fec to make these into one interface due to > the way out networking contractors are installign a new site. > > Seems like no problem from the command line, but what I can't > find anywhere in the documentation is how to make this happen > at boot time using rc.conf. I am assuming my line which > looks like: > > ifconfig_em0="inet 172.16.1.6 netmask 255.255.0.0" > > becomes > > ifconfig_fec0="inet 172.16.1.6 netmask 255.255.0.0" > > but obviously I need to do something to create fec0 before > that happens. Preseumably something like cloned_interfaces="fce0", > but where does it get the parameters from to create the interface ? > To run commands before a interface started, you need to create a /etc/start_if.fec0, #!/bin/sh /usr/sbin/ngctl -f- <<-SEQ mkpeer fec dummy fec msg fec0: add_iface "bge0" msg fec0: add_iface "bge1" msg fec0: set_mode_inet SEQ Then add fec0 to the network_interfaces variable in your /etc/rc.conf. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 17:04:39 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 898F116A407 for ; Thu, 25 Jan 2007 17:04:39 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.freebsd.org (Postfix) with SMTP id F01A613C468 for ; Thu, 25 Jan 2007 17:04:38 +0000 (UTC) (envelope-from reichert@numachi.com) Received: (qmail 88149 invoked from network); 25 Jan 2007 16:37:56 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 25 Jan 2007 16:37:56 -0000 Received: (qmail 79964 invoked by uid 1001); 25 Jan 2007 16:37:56 -0000 Date: Thu, 25 Jan 2007 11:37:56 -0500 From: Brian Reichert To: freebsd-stable@freebsd.org Message-ID: <20070125163756.GQ41546@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i Subject: does -STABLE support VIA VT6103 NIC? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 17:04:39 -0000 I'm looking at the release notes for 6.2-RELEASE: http://www.freebsd.org/releases/6.2R/hardware-i386.html#ETHERNET I'm considering the botherboard on this 1U system: http://www.ironsystems.com/Customkititems.asp?kc=SYS%2DS%2DA113%2D01&Cc=ACLASS Which describes a VIA 'VT6103 10/100 Base-T Ethernet PHY' interface. This is not specifically mentioned as supported; does anyone know for sure? -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 18:01:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5ADA616A402 for ; Thu, 25 Jan 2007 18:01:06 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail2.secureworks.net (mail2.secureworks.net [65.114.32.154]) by mx1.freebsd.org (Postfix) with ESMTP id 3729A13C44B for ; Thu, 25 Jan 2007 18:01:06 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from localhost (localhost [127.0.0.1]) by mail2.secureworks.net (Postfix) with ESMTP id 83AA51737F; Thu, 25 Jan 2007 13:01:05 -0500 (EST) X-Virus-Scanned: amavisd-new at secureworks.net Received: from mail2.secureworks.net ([127.0.0.1]) by localhost (mail2.secureworks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYAr5+ZU6p-x; Thu, 25 Jan 2007 13:01:05 -0500 (EST) Received: from [192.168.23.35] (mole1.secureworks.net [63.239.86.3]) by mail2.secureworks.net (Postfix) with ESMTP id 4CD941736B; Thu, 25 Jan 2007 13:01:05 -0500 (EST) Message-ID: <45B8F062.50802@jellydonut.org> Date: Thu, 25 Jan 2007 13:01:06 -0500 From: Michael Proto User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.9) Gecko/20070113 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Brian Reichert References: <20070125163756.GQ41546@numachi.com> In-Reply-To: <20070125163756.GQ41546@numachi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: does -STABLE support VIA VT6103 NIC? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 18:01:06 -0000 Brian Reichert wrote: > I'm looking at the release notes for 6.2-RELEASE: > > http://www.freebsd.org/releases/6.2R/hardware-i386.html#ETHERNET > > I'm considering the botherboard on this 1U system: > > http://www.ironsystems.com/Customkititems.asp?kc=SYS%2DS%2DA113%2D01&Cc=ACLASS > > Which describes a VIA 'VT6103 10/100 Base-T Ethernet PHY' interface. > > This is not specifically mentioned as supported; does anyone know for sure? > According to http://developer.novell.com/yes/66541.htm, the VT6105 is a Via Rhine III adapter, which is supported by the vr driver. -Proto From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 18:02:52 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5625C16A62F for ; Thu, 25 Jan 2007 18:02:52 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id D5E9D13C45D for ; Thu, 25 Jan 2007 18:02:51 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (cdsdyb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0PI2iak048726; Thu, 25 Jan 2007 19:02:50 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0PI2iof048725; Thu, 25 Jan 2007 19:02:44 +0100 (CET) (envelope-from olli) Date: Thu, 25 Jan 2007 19:02:44 +0100 (CET) Message-Id: <200701251802.l0PI2iof048725@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, reichert@numachi.com In-Reply-To: <20070125163756.GQ41546@numachi.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 25 Jan 2007 19:02:50 +0100 (CET) Cc: Subject: Re: does -STABLE support VIA VT6103 NIC? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, reichert@numachi.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 18:02:52 -0000 Brian Reichert wrote: > I'm looking at the release notes for 6.2-RELEASE: > > http://www.freebsd.org/releases/6.2R/hardware-i386.html#ETHERNET > > I'm considering the botherboard on this 1U system: > > http://www.ironsystems.com/Customkititems.asp?kc=SYS%2DS%2DA113%2D01&Cc=ACLASS > > Which describes a VIA 'VT6103 10/100 Base-T Ethernet PHY' interface. The actual interface is a VT6105. The 6103 is just the PHY. This chip is called "Rhine III", and it's listed in the FreeBSD release notes. > This is not specifically mentioned as supported; does anyone know for sure? It's supported by the vr(4) driver. I've got two VT610x NICs on my VIA EDEN PD10k board, too. They work perfectly fine. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 19:26:03 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDA8B16A404 for ; Thu, 25 Jan 2007 19:26:03 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.freebsd.org (Postfix) with SMTP id 4ECF113C46A for ; Thu, 25 Jan 2007 19:26:03 +0000 (UTC) (envelope-from reichert@numachi.com) Received: (qmail 95156 invoked from network); 25 Jan 2007 19:26:00 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 25 Jan 2007 19:26:00 -0000 Received: (qmail 81177 invoked by uid 1001); 25 Jan 2007 19:26:00 -0000 Date: Thu, 25 Jan 2007 14:26:00 -0500 From: Brian Reichert To: freebsd-stable@FreeBSD.ORG, reichert@numachi.com Message-ID: <20070125192600.GV41546@numachi.com> References: <20070125163756.GQ41546@numachi.com> <200701251802.l0PI2iof048725@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701251802.l0PI2iof048725@lurza.secnetix.de> User-Agent: Mutt/1.5.10i Cc: Subject: Re: does -STABLE support VIA VT6103 NIC? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 19:26:03 -0000 On Thu, Jan 25, 2007 at 07:02:44PM +0100, Oliver Fromme wrote: > Brian Reichert wrote: > > I'm looking at the release notes for 6.2-RELEASE: > > Which describes a VIA 'VT6103 10/100 Base-T Ethernet PHY' interface. > > The actual interface is a VT6105. The 6103 is just the PHY. > This chip is called "Rhine III", and it's listed in the > FreeBSD release notes. > > > This is not specifically mentioned as supported; does anyone know for sure? > > It's supported by the vr(4) driver. I've got two VT610x > NICs on my VIA EDEN PD10k board, too. They work perfectly > fine. Thanks, both of you, for your feedback. Off I go... > Best regards > Oliver -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 19:44:23 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3003516A401 for ; Thu, 25 Jan 2007 19:44:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 9784713C45B for ; Thu, 25 Jan 2007 19:44:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0PJiKdb003470; Fri, 26 Jan 2007 06:44:20 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0PJiKM6003469; Fri, 26 Jan 2007 06:44:20 +1100 (EST) (envelope-from peter) Date: Fri, 26 Jan 2007 06:44:20 +1100 From: Peter Jeremy To: Eduardo Meyer Message-ID: <20070125194420.GJ822@turion.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: stable@freebsd.org Subject: Re: Bridging problems on IP address conflict X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 19:44:23 -0000 --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2007-Jan-25 12:01:46 -0200, Eduardo Meyer wrote: >bridge0: flags=3D8043 mtu 1500 > ether ac:de:48:df:0d:8c > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: fxp0 flags=3D3 > member: em0 flags=3D3 > >bridge1: flags=3D8043 mtu 1500 > ether ac:de:48:fe:cd:41 > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: xl1 flags=3D3 > member: xl0 flags=3D3 > >And my system constantly reports: > >arp: 00:13:20:1c:33:22 is using my IP address XX.YY.ZZ.KK! > >several (thoundsands of) times. In fact this ARP is my own fxp0 >interface, and this is the only interface that has this IP. What >should I do? Ass IP on the bridge0 interface instead of the fxp0 >bridge member? Or anything else? You don't say what version of FreeBSD you are running (there were some bridge(4) fixes between 6.1 and 6.2) or what ifconfig shows for the bridge members. This may be indicative of a loop in your switch network - is there any way that packets leaving fxp0 can re-appear on em0, xl0 or xl1? Based on a previous thread, you probably should put the IP address on the bridge device, though that should not be related to your problem. --=20 Peter Jeremy --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFuQiU/opHv/APuIcRAhb7AJ9apJdfFcX/qOQgV3xXebmcSuCLZgCfaf4Y FdG+63md2R2Lf6PH7YuY7Tw= =Kt4n -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 21:07:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A403016A406 for ; Thu, 25 Jan 2007 21:07:40 +0000 (UTC) (envelope-from don_oles@able.com.ua) Received: from able.com.ua (able.com.ua [80.91.162.66]) by mx1.freebsd.org (Postfix) with ESMTP id 524C413C467 for ; Thu, 25 Jan 2007 21:07:40 +0000 (UTC) (envelope-from don_oles@able.com.ua) Received: from able.com.ua (localhost [127.0.0.1]) by able.com.ua (Postfix) with ESMTP id AD08744C50 for ; Thu, 25 Jan 2007 22:48:59 +0200 (EET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=able.com.ua; h=Received:Date:From:X-Mailer:Reply-To:X-Priority:Message-ID:X-Confirm-Reading-To:Disposition-Notification-To:Return-Receipt-To:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Rdetqu+a0B7RqX8N2Ovy+QkwUWjcQ1Lp/xxWlzHyHgkEoXdI1sPlHvFaYJejup0DGyq8PO5nWDJisjfgnmr3yt2KC3RwzbAiYDP31/aFSR63s9aGHUWt6blzahRFJBfzRNYRVlgBGdQNtL5Ij+2sJcox6F9gZEgr82yLHfWT82k=; Received: from vanta.oles.net (infering.opposite.volia.net [77.122.163.104]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by able.com.ua (Postfix) with ESMTP id 6282944C4F for ; Thu, 25 Jan 2007 22:48:58 +0200 (EET) Date: Thu, 25 Jan 2007 22:48:56 +0200 From: Oles Hnatkevych X-Mailer: The Bat! (v3.71.01) Professional X-Priority: 3 (Normal) Message-ID: <1638945315.20070125224856@able.com.ua> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP at ABLE Subject: second cpu not used on smp platform X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oles Hnatkevych List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 21:07:40 -0000 Hello! Just cvsup-ed and upgraded to 6.2-STABLE. The box has hyperthreading processor: # more /var/run/dmesg.boot |grep -i cpu CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.37-MHz 686-class CPU) Logical CPUs per core: 2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu0: on acpi0 cpu1: on acpi0 SMP: AP CPU #1 Launched! and also sysctl shows that it is: kern.threads.virtual_cpu: 2 kern.smp.cpus: 2 hw.ncpu: 2 machdep.hlt_cpus: 2 machdep.logical_cpus_mask: 2 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 0% When I run several concurrent processes I do not see that the CPU1 is used at all! The 'top' shows this, and the sysctl shows this: dev.cpu.0.cx_usage: 100.00% dev.cpu.1.cx_usage: 0% last pid: 732; load averages: 7.94, 5.19, 2.52 up 0+00:29:42 23:39:43 38 processes: 9 running, 29 sleeping CPU states: 99.3% user, 0.0% nice, 0.7% system, 0.0% interrupt, 0.0% idle Mem: 34M Active, 15M Inact, 40M Wired, 34M Buf, 145M Free Swap: 469M Total, 469M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 691 root 1 112 0 2628K 1984K RUN 0 0:45 12.01% perl5.8.8 693 root 1 112 0 2628K 1984K RUN 0 0:41 11.96% perl5.8.8 696 root 1 112 0 2628K 1984K RUN 0 0:40 11.96% perl5.8.8 698 root 1 112 0 2628K 1984K RUN 0 0:37 11.96% perl5.8.8 690 root 1 112 0 2628K 1984K RUN 0 0:44 11.91% perl5.8.8 694 root 1 112 0 2628K 1984K RUN 0 0:42 11.91% perl5.8.8 697 root 1 112 0 2628K 1984K RUN 0 0:38 11.91% perl5.8.8 723 root 1 112 0 2628K 1984K RUN 0 0:22 11.09% perl5.8.8 What it can be???? -- Oles mailto:don_oles@able.com.ua From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 21:13:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE5D316A403 for ; Thu, 25 Jan 2007 21:13:24 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.freebsd.org (Postfix) with ESMTP id B8AE713C442 for ; Thu, 25 Jan 2007 21:13:24 +0000 (UTC) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 0C883B80A for ; Thu, 25 Jan 2007 16:13:24 -0500 (EST) In-Reply-To: <1638945315.20070125224856@able.com.ua> References: <1638945315.20070125224856@able.com.ua> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Thu, 25 Jan 2007 16:13:23 -0500 To: FreeBSD Stable X-Mailer: Apple Mail (2.752.2) Subject: Re: second cpu not used on smp platform X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 21:13:24 -0000 On Jan 25, 2007, at 3:48 PM, Oles Hnatkevych wrote: > Hello! > > Just cvsup-ed and upgraded to 6.2-STABLE. > > The box has hyperthreading processor: > check value of machdep.hyperthreading_allowed sysctl. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 21:19:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D35816A401 for ; Thu, 25 Jan 2007 21:19:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4342713C469 for ; Thu, 25 Jan 2007 21:19:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 66CB7EB3634; Fri, 26 Jan 2007 05:19:23 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id JKdjIa0ZUXYP; Fri, 26 Jan 2007 05:19:14 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.129.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id B9A83EB31B2; Fri, 26 Jan 2007 05:19:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=mj/33kICOZkMORd0U5+NUpyfaWtgSPGvlp/9gTd3Iw5f0Cbus5Kq4XHB/x4vnmUbz GjXv0v2QPQ4mI6dKs5lZQ== Message-ID: <45B91ED2.6080800@delphij.net> Date: Fri, 26 Jan 2007 05:19:14 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Oles Hnatkevych References: <1638945315.20070125224856@able.com.ua> In-Reply-To: <1638945315.20070125224856@able.com.ua> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigFF772DEB971A04DB4E2FC8DD" Cc: freebsd-stable@freebsd.org Subject: Re: second cpu not used on smp platform X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 21:19:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF772DEB971A04DB4E2FC8DD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oles Hnatkevych wrote: > Hello! >=20 > Just cvsup-ed and upgraded to 6.2-STABLE. >=20 > The box has hyperthreading processor: >=20 > # more /var/run/dmesg.boot |grep -i cpu > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.37-MHz 686-class CPU) > Logical CPUs per core: 2 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu0: on acpi0 > cpu1: on acpi0 > SMP: AP CPU #1 Launched! [...] > What it can be???? This is done intentionally on all -STABLE branches, see http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc for detai= ls. Note that it is possible to re-enable htt if you know what you are doing, by setting machdep.hyperthreading_allowed. Please note that enabling hyperthreading does hurt performance for many cases, so you will want to evaluate if you really want it, or to disable it from BIOS. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigFF772DEB971A04DB4E2FC8DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFuR7SOfuToMruuMARAw1lAJ9lKAA4k/mztaoQmrC4GkKd9O4zbwCdFTTE 7MQUbULdZ3hAsnMEWwpam5c= =kr9r -----END PGP SIGNATURE----- --------------enigFF772DEB971A04DB4E2FC8DD-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 21:24:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B122916A400 for ; Thu, 25 Jan 2007 21:24:20 +0000 (UTC) (envelope-from don_oles@able.com.ua) Received: from able.com.ua (able.com.ua [80.91.162.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFF213C45A for ; Thu, 25 Jan 2007 21:24:20 +0000 (UTC) (envelope-from don_oles@able.com.ua) Received: from able.com.ua (localhost [127.0.0.1]) by able.com.ua (Postfix) with ESMTP id DEDEF44C51 for ; Thu, 25 Jan 2007 22:54:17 +0200 (EET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=able.com.ua; h=Received:Date:From:X-Mailer:Reply-To:X-Priority:Message-ID:To:Subject:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R62U8HkUWKw4m5jmJTWxcoEWafc226sKb5AuVtfbTF/aXbMjvhJodNrRjqHZgeOM6XshCf2tgjqZxQIgrXbN9UFSL0COA+aQdviOrPeMXGQWHlLxFJT9Nf73MoewLg3Q1Kcm+PaEzrzrbuoOWoz/sZErlyfaxT0Z/iyXX90Ciuw=; Received: from vanta.oles.net (infering.opposite.volia.net [77.122.163.104]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by able.com.ua (Postfix) with ESMTP id E412E44C4F for ; Thu, 25 Jan 2007 22:54:16 +0200 (EET) Date: Thu, 25 Jan 2007 22:54:14 +0200 From: Oles Hnatkevych X-Mailer: The Bat! (v3.71.01) Professional X-Priority: 3 (Normal) Message-ID: <735344005.20070125225414@able.com.ua> To: freebsd-stable@freebsd.org In-Reply-To: <1638945315.20070125224856@able.com.ua> References: <1638945315.20070125224856@able.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP at ABLE Subject: Re: second cpu not used on smp platform X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oles Hnatkevych List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 21:24:20 -0000 Hello! I believe that the kernel boot messages should explicitly tell that hyperthreading is disabled by default, so the guys like me won't be confused. ;-) OH> Hello! OH> Just cvsup-ed and upgraded to 6.2-STABLE. OH> The box has hyperthreading processor: OH> # more /var/run/dmesg.boot |grep -i cpu OH> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.37-MHz 686-class CPU) OH> Logical CPUs per core: 2 OH> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs OH> cpu0 (BSP): APIC ID: 0 OH> cpu1 (AP): APIC ID: 1 OH> cpu0: on acpi0 OH> cpu1: on acpi0 OH> SMP: AP CPU #1 Launched! -- freebsd-stable mailto:freebsd-stable@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Thu Jan 25 23:19:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30C4216A403 for ; Thu, 25 Jan 2007 23:19:42 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id C51E813C455 for ; Thu, 25 Jan 2007 23:19:41 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so545447uge for ; Thu, 25 Jan 2007 15:19:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=i/KUtaEWBoF6eEgRLcPI2eMvBvLZ9UlG0OHovN0EFKvGZ3TfHvmt/gCAoB28ciPlIGO3TOhwVrxmavwgZAn6d2lynRYFvDMPlzBQy9PCRlQ/JsSDtCXIxgCesE0BW1uM0rcUTniMOVbEFGjLhiHo69I/JrDWjMGn66EFWEZLleU= Received: by 10.78.201.10 with SMTP id y10mr1997253huf.1169765481510; Thu, 25 Jan 2007 14:51:21 -0800 (PST) Received: by 10.78.77.11 with HTTP; Thu, 25 Jan 2007 14:51:21 -0800 (PST) Message-ID: <70e8236f0701251451l35a59aebs9df53ca10568a618@mail.gmail.com> Date: Thu, 25 Jan 2007 22:51:21 +0000 From: "Joao Barros" To: freebsd-stable@freebsd.org, freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: SPARC64: Can't upgrade from 6.1 to 6.2 due to binutils X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 23:19:42 -0000 Hi, I was trying to upgrade my Sun Ultra 5 from 6.1R to 6.2R and bumped into this when doing a make buildword: building static binutils library ranlib libbinutils.a ===> gnu/usr.bin/binutils/addr2line (all) cc -O2 -pipe -I. -I/usr/src/gnu/usr.bin/binutils/addr2line -I/usr/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/usr/obj/u cc -O2 -pipe -I. -I/usr/src/gnu/usr.bin/binutils/addr2line -I/usr/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/usr/obj/u ../libbinutils/libbinutils.a(bucomm.o)(.text+0xb28): In function `make_tempname': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() ../libbfd/libbfd.a(libbfd.o)(.text+0xa2c): In function `_bfd_generic_verify_endian_match': : undefined reference to `libintl_dgettext' ../libbfd/libbfd.a(libbfd.o)(.text+0xa70): In function `_bfd_generic_verify_endian_match': : undefined reference to `libintl_dgettext' ../libbfd/libbfd.a(libbfd.o)(.text+0xaec): In function `warn_deprecated': : undefined reference to `libintl_dgettext' ../libbfd/libbfd.a(libbfd.o)(.text+0xb30): In function `warn_deprecated': : undefined reference to `libintl_dgettext' ../libbfd/libbfd.a(bfd.o)(.text+0x74): In function `bfd_errmsg': : undefined reference to `libintl_dgettext' ../libbfd/libbfd.a(bfd.o)(.text+0x2dc): more undefined references to `libintl_dgettext' follow *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/addr2line. *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I poked around binutils in the past trying to get firefox running with the info from this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=89486 Now I tried cvsuping the src, make clean and rebuilding binutils with no luck. Any pointers are most appreciated :) -- Joao Barros From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 01:13:09 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A917716A401 for ; Fri, 26 Jan 2007 01:13:09 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9A313C465 for ; Fri, 26 Jan 2007 01:13:09 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HAFeO-000DsZ-Ce; Fri, 26 Jan 2007 01:13:08 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HAFeO-00055s-5E; Fri, 26 Jan 2007 01:13:08 +0000 To: nork@FreeBSD.org In-Reply-To: <20070126011426.d7950892.nork@FreeBSD.org> Message-Id: From: Pete French Date: Fri, 26 Jan 2007 01:13:08 +0000 Cc: freebsd-stable@FreeBSD.org Subject: Re: Netgraph at startup - rc.conf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 01:13:09 -0000 > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/104884 Now that's an excellent patch - but not yet applied to STABLE I guess, and I don't want to have to re-patch every time I do an install unfortunately. Though if it gets commited in the near future I would definitely do it this way. thanks, -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 01:36:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF11716A400 for ; Fri, 26 Jan 2007 01:36:39 +0000 (UTC) (envelope-from fkraiem@enib.fr) Received: from smtp23.orange.fr (smtp23.orange.fr [193.252.23.111]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE7613C441 for ; Fri, 26 Jan 2007 01:36:39 +0000 (UTC) (envelope-from fkraiem@enib.fr) Received: from smtp23.orange.fr (mwinf2316 [10.232.4.116]) by mwinf2310.orange.fr (SMTP Server) with ESMTP id D5C251C1CEA3 for ; Wed, 24 Jan 2007 20:43:49 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2316.orange.fr (SMTP Server) with ESMTP id E0EBE7000096 for ; Wed, 24 Jan 2007 20:43:47 +0100 (CET) Received: from ana.fkraiem.org (ABordeaux-256-1-6-52.w86-201.abo.wanadoo.fr [86.201.217.52]) by mwinf2316.orange.fr (SMTP Server) with ESMTP id B6BDB700008C for ; Wed, 24 Jan 2007 20:43:47 +0100 (CET) X-ME-UUID: 20070124194347748.B6BDB700008C@mwinf2316.orange.fr From: Firas Kraiem To: freebsd-stable@freebsd.org Date: Wed, 24 Jan 2007 20:43:44 +0100 User-Agent: KMail/1.9.5 References: <45B7A0FA.1050901@terceirizado.mda.gov.br> In-Reply-To: <45B7A0FA.1050901@terceirizado.mda.gov.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701242043.44307.fkraiem@enib.fr> Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 01:36:40 -0000 On Wednesday 24 January 2007 19:10, Alexandre Vasconcelos wrote: > Hello, > > Working setup: > - FreeBSD 6.2-PRERELEASE, firefox 2 and flash 7 patched with > rtld_dlsym_hack.diff, like suggested on Handbook. > > After 6.2-STABLE upgrade reaplying the rtld_dlsym_hack.diff fails: > > root@alex src]# patch < rtld_dlsym_hack.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 > |+++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 > > -------------------------- > Patching file libexec/rtld-elf/rtld.c using Plan A... > Hunk #1 failed at 129. > Hunk #2 succeeded at 187 (offset 9 lines). > Hunk #3 succeeded at 1820 (offset 82 lines). > 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej > done > > And make fails: > > [root@alex rtld-elf]# make > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/rtld_start.S > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/reloc.c > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/rtld.c > /usr/src/libexec/rtld-elf/rtld.c:189: error: `_dlsym' undeclared here > (not in a function) > /usr/src/libexec/rtld-elf/rtld.c:189: error: initializer element is not > constant > /usr/src/libexec/rtld-elf/rtld.c:189: error: (near initialization for > `exports[4]') > *** Error code 1 > > Stop in /usr/src/libexec/rtld-elf. > > > How to fix this? > Thanks, > Alex > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hello I had the same problem, I've patched the library myself but I don't know how to make a proper "patch file" so if you want, here's my patched one : http://fkraiem.free.fr/rtld.c Copy into /usr/src/libexec/rtld-elf and follow the instructions given in the handbook. -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 03:17:52 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8867516A5FC; Fri, 26 Jan 2007 03:17:52 +0000 (UTC) (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 730B613C4B0; Fri, 26 Jan 2007 03:17:52 +0000 (UTC) (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 273901A3C1C; Thu, 25 Jan 2007 18:13:10 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B4E1D513BC; Thu, 25 Jan 2007 21:13:04 -0500 (EST) Date: Thu, 25 Jan 2007 21:13:04 -0500 From: Kris Kennaway To: Joao Barros Message-ID: <20070126021304.GA75601@xor.obsecurity.org> References: <70e8236f0701251451l35a59aebs9df53ca10568a618@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <70e8236f0701251451l35a59aebs9df53ca10568a618@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: SPARC64: Can't upgrade from 6.1 to 6.2 due to binutils X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 03:17:52 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 25, 2007 at 10:51:21PM +0000, Joao Barros wrote: > Hi, >=20 > I was trying to upgrade my Sun Ultra 5 from 6.1R to 6.2R and bumped > into this when doing a make buildword: >=20 > building static binutils library > ranlib libbinutils.a > =3D=3D=3D> gnu/usr.bin/binutils/addr2line (all) > cc -O2 -pipe -I. -I/usr/src/gnu/usr.bin/binutils/addr2line > -I/usr/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/usr/obj/u > cc -O2 -pipe -I. -I/usr/src/gnu/usr.bin/binutils/addr2line > -I/usr/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/usr/obj/u > ../libbinutils/libbinutils.a(bucomm.o)(.text+0xb28): In function > `make_tempname': > : warning: warning: mktemp() possibly used unsafely; consider using=20 > mkstemp() > ../libbfd/libbfd.a(libbfd.o)(.text+0xa2c): In function > `_bfd_generic_verify_endian_match': > : undefined reference to `libintl_dgettext' > ../libbfd/libbfd.a(libbfd.o)(.text+0xa70): In function > `_bfd_generic_verify_endian_match': > : undefined reference to `libintl_dgettext' > ../libbfd/libbfd.a(libbfd.o)(.text+0xaec): In function `warn_deprecated': > : undefined reference to `libintl_dgettext' > ../libbfd/libbfd.a(libbfd.o)(.text+0xb30): In function `warn_deprecated': > : undefined reference to `libintl_dgettext' > ../libbfd/libbfd.a(bfd.o)(.text+0x74): In function `bfd_errmsg': > : undefined reference to `libintl_dgettext' > ../libbfd/libbfd.a(bfd.o)(.text+0x2dc): more undefined references to > `libintl_dgettext' follow > *** Error code 1 >=20 > Stop in /usr/src/gnu/usr.bin/binutils/addr2line. FreeBSD doesn't and never has included libintl, so if your sources are trying to compile against it, then they or your world are probably contaminated somehow. > I poked around binutils in the past trying to get firefox running with > the info from this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D89486 Ah yes, that could do it ;) > Now I tried cvsuping the src, make clean and rebuilding binutils with no= =20 > luck. > Any pointers are most appreciated :) The easiest way to repair your system might be to just do a binary upgrade from new sysinstall media. Kris --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFuWOwWry0BWjoQKURAh0GAKDwe+EH2V3UAMg60suNpCERhu7k1QCeI0IC fmFOWIWOZKy4yVpchAqyiG4= =eomH -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 03:30:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4AD216AA47 for ; Fri, 26 Jan 2007 03:30:20 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 619D713C4A8 for ; Fri, 26 Jan 2007 03:30:20 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so582155uge for ; Thu, 25 Jan 2007 19:30:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JVhOBo1weno1rHohgGr+YPuTvtl4QycIrvA9gf4uWh+kER9sFhZiDXtgDUmyufcr7MD3viSmMJ0wAkoEt8Eb4jzxPUArE9xNxiqgkmQ+3m80IleB+dv58Vhk1bWGzjt+Mxm5F8r0bHld0ikr6A0OCi7oz6b5sQXCaOz5iaGQWJo= Received: by 10.78.118.19 with SMTP id q19mr2008301huc.1169782218782; Thu, 25 Jan 2007 19:30:18 -0800 (PST) Received: by 10.78.77.11 with HTTP; Thu, 25 Jan 2007 19:30:18 -0800 (PST) Message-ID: <70e8236f0701251930q5717e9c7n47cabb30952898e9@mail.gmail.com> Date: Fri, 26 Jan 2007 03:30:18 +0000 From: "Joao Barros" To: "Matthew Herzog" In-Reply-To: <7cf39bb60701251841k7d01c146qda1dd7a02deffbd8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0701251451l35a59aebs9df53ca10568a618@mail.gmail.com> <7cf39bb60701251841k7d01c146qda1dd7a02deffbd8@mail.gmail.com> Cc: freebsd-stable@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: SPARC64: Can't upgrade from 6.1 to 6.2 due to binutils X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 03:30:20 -0000 On 1/26/07, Matthew Herzog wrote: > I have never been able to upgrade Sparc64 from source. I suspect it is > nearly impossible. > Please let me know if you suceed. This particular box has been upgraded everytime from source for every release since 5.something. I can check the sources, but one thing comes to mind: the first install I did I noticed hme wasn't GIANT free and it has been for a while :) -- Joao Barros From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 04:00:44 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D8516A400; Fri, 26 Jan 2007 04:00:44 +0000 (UTC) (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 81D2A13C489; Fri, 26 Jan 2007 04:00:44 +0000 (UTC) (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 4A3DE1A3C1C; Thu, 25 Jan 2007 20:00:44 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DF28051DB7; Thu, 25 Jan 2007 23:00:38 -0500 (EST) Date: Thu, 25 Jan 2007 23:00:37 -0500 From: Kris Kennaway To: Joao Barros Message-ID: <20070126040037.GA80309@xor.obsecurity.org> References: <70e8236f0701251451l35a59aebs9df53ca10568a618@mail.gmail.com> <7cf39bb60701251841k7d01c146qda1dd7a02deffbd8@mail.gmail.com> <70e8236f0701251930q5717e9c7n47cabb30952898e9@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <70e8236f0701251930q5717e9c7n47cabb30952898e9@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Matthew Herzog , freebsd-sparc64@freebsd.org Subject: Re: SPARC64: Can't upgrade from 6.1 to 6.2 due to binutils X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 04:00:44 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 26, 2007 at 03:30:18AM +0000, Joao Barros wrote: > On 1/26/07, Matthew Herzog wrote: > >I have never been able to upgrade Sparc64 from source. I suspect it is > >nearly impossible. > >Please let me know if you suceed. Matthew, We established long ago that you have a trashed FreeBSD install. You can continue to choose not to believe in the existence the dozen or so sparc64 systems I run that successfully build world (let alone the many sparc64 systems run and updated by other freebsd users) if you wish, but that doesn't make your dreams any closer to reality ;-) Kris --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFuXzlWry0BWjoQKURAvFMAKDhPYtYSWlU2qCnOfyjUWJstJzX+wCguLBV nM8BwDS7lahCHEpdjTygFL8= =zjrs -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 04:41:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35FC616A401 for ; Fri, 26 Jan 2007 04:41:15 +0000 (UTC) (envelope-from kailockwood@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id C79D513C48C for ; Fri, 26 Jan 2007 04:41:14 +0000 (UTC) (envelope-from kailockwood@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so1009499nfc for ; Thu, 25 Jan 2007 20:41:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iP1g8NhbZV81zcxay6v+VrmZEPeyTkOsRiEco8sDbCAzAE6+EfBgBYrzFqm9XtBBPRJLZdMeO434lP3ZkPIt/Oa5qllPl8R8GvEAXEG31U+c7Qpa+vbyOl1I2XrtesAeAxEqa0KRN8Wq1C8gwQFHF1eQE8pGflrH43etaMmw0ag= Received: by 10.49.8.15 with SMTP id l15mr5148046nfi.1169784726288; Thu, 25 Jan 2007 20:12:06 -0800 (PST) Received: from ?192.168.1.104? ( [69.145.125.218]) by mx.google.com with ESMTP id p72sm11637496nfc.2007.01.25.20.12.05; Thu, 25 Jan 2007 20:12:05 -0800 (PST) Message-ID: <45B97F08.6040006@gmail.com> Date: Thu, 25 Jan 2007 21:09:44 -0700 From: Kai Lockwood User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG References: <200701251552.l0PFqugQ030872@lurza.secnetix.de> In-Reply-To: <200701251552.l0PFqugQ030872@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 04:41:15 -0000 This is a Firefox specific patch which requires the rtld be patched. Many thanks to those who have provided patch updates because I was at a lost without them. Oliver Fromme wrote: > Helge.Oldach@atosorigin.com wrote: > > Torfinn Ingolfsen wrote: > > > BTW, what is the reason this "hack" isn't included in the base kernel > > > / code? > > > > Because it is probably unnecessary? I run a recent 6-STABLE and use > > the flash7 plugin *without* this patch. I am using Opera, though, not > > Firefox... > > Same here. I use Opera with the Flash plugin on 6-STABLE > without any problems. I haven't applied a patch to rtld. > > Best regards > Oliver > > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 10:03:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0760016A401 for ; Fri, 26 Jan 2007 10:03:06 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from miram.origin-it.net (mail.de.atosorigin.com [194.8.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8D57C13C4AC for ; Fri, 26 Jan 2007 10:03:05 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from markab.hbg.de.int.atosorigin.com (avior.origin-it.net [213.70.176.177]) by miram.origin-it.net (8.13.8/8.13.8/hmo020206) with ESMTP id l0QA33TA074487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 11:03:03 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from DEHHX001.deuser.de.intra (dehhx001.hbg.de.int.atosorigin.com [161.90.164.119]) by markab.hbg.de.int.atosorigin.com (8.13.8/8.13.8/hmo020206) with ESMTP id l0QA32XS006468; Fri, 26 Jan 2007 11:03:02 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 26 Jan 2007 11:02:56 +0100 Message-ID: <39AFDF50473FED469B15B6DFF2262F7A028D334C@DEHHX001.deuser.de.intra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 6.2-STABLE and Flash 7 patch Thread-Index: AcdBBHJWz+7znITYRvWO9UaK7r42WgAK+iGA From: To: , X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (miram.origin-it.net [194.8.96.226]); Fri, 26 Jan 2007 11:03:04 +0100 (CET) Cc: Subject: RE: FreeBSD 6.2-STABLE and Flash 7 patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 10:03:06 -0000 Kai Lockwood <> wrote on Friday, January 26, 2007 5:10 AM: > Oliver Fromme wrote: >> Helge.Oldach@atosorigin.com wrote: >> > Torfinn Ingolfsen wrote: >> > > BTW, what is the reason this "hack" isn't included in the base = kernel > > / code? >> > >> > Because it is probably unnecessary? I run a recent 6-STABLE and = use >> > the flash7 plugin *without* this patch. I am using Opera, though, = not > Firefox... >>=20 >> Same here. I use Opera with the Flash plugin on 6-STABLE >> without any problems. I haven't applied a patch to rtld. >>=20 > This is a Firefox specific patch which requires the rtld be patched. > Many thanks to those who have provided patch updates because I was at > a lost without them. >=20 Ummm... In that case the application should be fixed rather than = patching the operating system. Which finally explains why this patch = should definitely not be included in the base. Helge From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 11:25:52 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 742C216A404 for ; Fri, 26 Jan 2007 11:25:52 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id EE77A13C494 for ; Fri, 26 Jan 2007 11:25:48 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0QBPAVf040484; Fri, 26 Jan 2007 09:25:11 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: "Peter N. M. Hansteen" Date: Fri, 26 Jan 2007 09:24:58 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701250828.50540.joao@matik.com.br> <87ac074537.fsf@thingy.datadok.no> In-Reply-To: <87ac074537.fsf@thingy.datadok.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701260924.59674.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 11:25:52 -0000 On Thursday 25 January 2007 11:18, Peter N. M. Hansteen wrote: > JoaoBR writes: > > all this methods are certainly useless, stay calm ok > > I fully sympathize with your need to rant, but in this context most of > what you say is really quite beside the point. Please read what the > material at the links provided actually says. > the articles you linked show how to implement pf like I said, for my understandings firewall implemention for spam fighting = is=20 wrong because you reject the message unless you are the man of a corporate network you do have *NO* right to dec= ide=20 which message your users receive or not. May be some *WANT* viagra offers a= nd=20 others *WANT* a bigger penis so the only correct decision is to filter spam and put it into a spam folde= r=20 where the user can review it and decide by his own if want it or not but may be, to change your opinion, you need to loose a case being=20 responsible for some having a small penis and pay him his losses hihihihi,= =20 100k/inch or something hihihi laugh with me and have a good day :) =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 16:10:32 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6102016A404 for ; Fri, 26 Jan 2007 16:10:32 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id DB98D13C491 for ; Fri, 26 Jan 2007 16:10:31 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id l0QGANV7029819 for ; Fri, 26 Jan 2007 11:10:23 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id l0QGAMtM029818 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 11:10:22 -0500 (EST) (envelope-from bv) Date: Fri, 26 Jan 2007 11:10:22 -0500 From: Bill Vermillion To: freebsd-stable@freebsd.org Message-ID: <20070126161022.GB29530@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Subject: 6.2 buildworld fails with NO_SHARED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 16:10:32 -0000 I had wanted to build static binaries in /bin and /sbin - so I set NO_SHARED. The man pages says "... this can be bad. If set every utility that uses bsd.prog.mk will be linked statically." I have problems in the past - on other platforms - where having statically linked tools in /bin saved the day. [Fixing things that some other SA's had no clue about as to what they were doing]. There really is nothing to indicated what 'bad' may be - other than statically linking these. I took the NO_SHARED out and the buildworld went just fine. Is this a bug? I would think if the variable is set and useable things should work. Here is the tail end of the output of make buildworld as I mailed it to me from the machine I was bringing up as we start to replace all the 4.11 servers. The verison is 6.2-STABLE with the tag in the cvsup set as RELENG_6_2. So this is exact with the release on Jan 19. Do I need to send this to anyone to look at. Any hints? Or should I just 'fugidaboudid' Bill ----- Forwarded message from Charlie Root ----- > From: Charlie Root > To: bv@wjv.com > Date: Fri, 26 Jan 2007 10:52:42 -0500 > Subject: errors on buldworkd with NO_SHARED > X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com > X-Spam-Level: > X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 > autolearn=ham version=3.1.7 > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -static -o getfmac getfmac.o > gzip -cn /usr/src/usr.sbin/getfmac/getfmac.8 > getfmac.8.gz > ===> usr.sbin/getpmac (all) > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/usr.sbin/getpmac/getpmac.c > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -static -o getpmac getpmac.o > gzip -cn /usr/src/usr.sbin/getpmac/getpmac.8 > getpmac.8.gz > ===> usr.sbin/gstat (all) > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -c /usr/src/usr.sbin/gstat/gstat.c > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1c): In function `StartElement': > : undefined reference to `sbuf_new' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x42e): In function `EndElement': > : undefined reference to `sbuf_finish' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x43b): In function `EndElement': > : undefined reference to `sbuf_data' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x453): In function `EndElement': > : undefined reference to `sbuf_delete' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x808): In function `CharData': > : undefined reference to `sbuf_bcat' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1538): In function `readkmem': > : undefined reference to `kvm_read' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1550): In function `readkmem': > : undefined reference to `kvm_geterr' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1591): In function `readkmem_nl': > : undefined reference to `kvm_nlist' > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x15b8): In function `readkmem_nl': > : undefined reference to `kvm_geterr' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3938): In function `term_deletechars': > : undefined reference to `tgoto' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3c56): In function `term_echotc': > : undefined reference to `tgetstr' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3dbc): In function `term_echotc': > : undefined reference to `tgoto' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4bd9): In function `term_set': > : undefined reference to `tgetent' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4bf7): In function `term_set': > : undefined reference to `tgetflag' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c0e): In function `term_set': > : undefined reference to `tgetflag' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c20): In function `term_set': > : undefined reference to `tgetflag' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c32): In function `term_set': > : undefined reference to `tgetflag' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c44): In function `term_set': > : undefined reference to `tgetflag' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c56): more undefined references to `tgetflag' follow > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c68): In function `term_set': > : undefined reference to `tgetnum' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4c7a): In function `term_set': > : undefined reference to `tgetnum' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x4cb6): In function `term_set': > : undefined reference to `tgetstr' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x509f): In function `term_move_to_char': > : undefined reference to `tgoto' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x5258): In function `term_move_to_line': > : undefined reference to `tgoto' > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x5381): In function `term_insertwrite': > : undefined reference to `tgoto' > *** Error code 1 > > Stop in /usr/src/usr.sbin/gstat. > *** Error code 1 > > Stop in /usr/src/usr.sbin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. ----- End forwarded message ----- -- Bill Vermillion - bv @ wjv . com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 17:11:25 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 559C816A406 for ; Fri, 26 Jan 2007 17:11:25 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id E40C413C48C for ; Fri, 26 Jan 2007 17:11:24 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so708225uge for ; Fri, 26 Jan 2007 09:11:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mh46ToU6VckQdxHUef7KAdT0bTOUyYmw6PHL2whLi7IexqInmUOzycJslrd+BgigQAOfN4iE37Eg7f4rTYkzSvBMhNYNInUbMW3j4EJNGYB1TvFqsm8YTeVRZsDLkF5M5izLgUzudwq370gYYij4NCtSrQ7YDW26l+bU1+WE68s= Received: by 10.82.152.16 with SMTP id z16mr1903906bud.1169831483305; Fri, 26 Jan 2007 09:11:23 -0800 (PST) Received: by 10.82.186.2 with HTTP; Fri, 26 Jan 2007 09:11:23 -0800 (PST) Message-ID: <790a9fff0701260911h7137c777p82376b633190718b@mail.gmail.com> Date: Fri, 26 Jan 2007 11:11:23 -0600 From: "Scot Hetzel" To: bv@wjv.com In-Reply-To: <20070126161022.GB29530@wjv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070126161022.GB29530@wjv.com> Cc: freebsd-stable@freebsd.org Subject: Re: 6.2 buildworld fails with NO_SHARED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 17:11:25 -0000 On 1/26/07, Bill Vermillion wrote: > I had wanted to build static binaries in /bin and /sbin - so > I set NO_SHARED. The man pages says "... this can be bad. If set > every utility that uses bsd.prog.mk will be linked statically." > > I have problems in the past - on other platforms - where having > statically linked tools in /bin saved the day. [Fixing things that > some other SA's had no clue about as to what they were doing]. > Since FreeBSD went to dynamically linked binaries, there is the /rescue directory which contains static binaries of the programs you would need to recover from a failure. > There really is nothing to indicated what 'bad' may be - other than > statically linking these. > > I took the NO_SHARED out and the buildworld went just fine. > > Is this a bug? I would think if the variable is set and useable > things should work. > Seems to be a bug, as their appears to be missing libraries in the NO_SHARED case. > Here is the tail end of the output of make buildworld as I mailed > it to me from the machine I was bringing up as we start to replace > all the 4.11 servers. > > The verison is 6.2-STABLE with the tag in the cvsup set > as RELENG_6_2. So this is exact with the release on Jan 19. > > Do I need to send this to anyone to look at. Any hints? Or should > I just 'fugidaboudid' > > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit sbuf(9) - sbuf_new, sbuf_clear, sbuf_setpos, sbuf_bcat, sbuf_bcopyin, sbuf_bcpy, sbuf_cat, sbuf_copyin, sbuf_cpy, sbuf_printf, sbuf_vprintf, sbuf_putc, sbuf_trim, sbuf_overflowed, sbuf_finish, sbuf_data, sbuf_len, sbuf_delete - safe string formatting > > : undefined reference to `sbuf_new' > > : undefined reference to `sbuf_finish' > > : undefined reference to `sbuf_data' > > : undefined reference to `sbuf_delete' > > : undefined reference to `sbuf_bcat' Not sure which library has the above function in them. The following functions seem to be defined in libkvm. > > : undefined reference to `kvm_read' > > : undefined reference to `kvm_geterr' > > : undefined reference to `kvm_nlist' > > : undefined reference to `kvm_geterr' curs_termcap (3X) - tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs - direct curses interface to the terminfo capability database > > : undefined reference to `tgoto' > > : undefined reference to `tgetstr' > > : undefined reference to `tgetent' > > : undefined reference to `tgetflag' > > : undefined reference to `tgetnum' These seem to come from curses, but are not in your libcurses library. Is there another library these functions come from? Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 17:15:53 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 615A416A400 for ; Fri, 26 Jan 2007 17:15:53 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC3E13C4A8 for ; Fri, 26 Jan 2007 17:15:52 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.6/8.13.8) id l0QHFqN9004651; Fri, 26 Jan 2007 11:15:52 -0600 (CST) (envelope-from dan) Date: Fri, 26 Jan 2007 11:15:52 -0600 From: Dan Nelson To: Bill Vermillion Message-ID: <20070126171552.GA24490@dan.emsphone.com> References: <20070126161022.GB29530@wjv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070126161022.GB29530@wjv.com> X-OS: FreeBSD 6.2-STABLE User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: 6.2 buildworld fails with NO_SHARED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 17:15:53 -0000 In the last episode (Jan 26), Bill Vermillion said: > I had wanted to build static binaries in /bin and /sbin - so > I set NO_SHARED. The man pages says "... this can be bad. If set > every utility that uses bsd.prog.mk will be linked statically." > > Here is the tail end of the output of make buildworld as I mailed > it to me from the machine I was bringing up as we start to replace > all the 4.11 servers. > > > ===> usr.sbin/gstat (all) > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -c /usr/src/usr.sbin/gstat/gstat.c > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit > > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1c): In function `StartElement': > > : undefined reference to `sbuf_new' > > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1538): In function `readkmem': > > : undefined reference to `kvm_read' > > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3938): In function `term_deletechars': > > : undefined reference to `tgoto' Looks like there are some missing/misordered library dependencies. Moving -lcurses after -ledit, and adding -lkvm and -lsbuf fixes it. The main thing you lose by statically linking is dlopen(), so nsswitch and pam modules from ports won't work. Modules built into libc.a or libpam.a (NIS and pam_unix for example) will work. Also, if you're on -current you can tell cached to do NSS lookups on behalf of static binaries. Index: Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/gstat/Makefile,v retrieving revision 1.6.2.1 diff -u -r1.6.2.1 Makefile --- Makefile 10 Jun 2006 15:40:10 -0000 1.6.2.1 +++ Makefile 26 Jan 2007 17:00:38 -0000 @@ -3,7 +3,7 @@ PROG= gstat MAN= gstat.8 WARNS?= 5 -DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBCURSES} ${LIBEDIT} -LDADD= -lgeom -ldevstat -lbsdxml -lcurses -ledit +DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBEDIT} ${LIBCURSES} +LDADD= -lgeom -ldevstat -lbsdxml -ledit -lcurses -lkvm -lsbuf .include -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 18:39:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0D9516A402 for ; Fri, 26 Jan 2007 18:39:33 +0000 (UTC) (envelope-from pekkas@netcore.fi) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4F84B13C494 for ; Fri, 26 Jan 2007 18:39:33 +0000 (UTC) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l0QHt3sL032667 for ; Fri, 26 Jan 2007 19:55:03 +0200 Date: Fri, 26 Jan 2007 19:55:03 +0200 (EET) From: Pekka Savola To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2492/Thu Jan 25 21:04:35 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi Subject: panic: kmem_malloc boot error w/ 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 18:39:33 -0000 Hello, (Not subscribed, let's hope this gets through..) I saw the strangest case I've yet seen today when upgrading a dual-P3 system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6 (6.2). The system paniced at boot with a message like: panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total allocated This seemed to be just before one would mount the root filesystem. GENERIC kernel on 6.2-RELEASE boot CD worked though. FreeSBIE 2.0 kernel (6.2-RELEASE) panicked in the same way, as well as another Rescue CD based on FreeBSD 6.1. I did a fair bit of bisecting (about 10 compiles) to find out which feature in GENERIC removes this panic, and came to a suprising conclusion: makeoptions DEBUG=-g .. when I added this, boot works fine. When removing it, you get the panic. Strange, huh? :-/ Below is a snippet of the boot log: ... acd0: DVDROM at ata0-master UDMA33 afd0: 6869804134400MB at ata2-master PIO3 acd1: CDROM at ata2-slave PIO3 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 139900MB (286515200 sectors) RAID 1 (optimal) panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total allocated Uptime: 2s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 20:05:27 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50ED416A403 for ; Fri, 26 Jan 2007 20:05:27 +0000 (UTC) (envelope-from archon_666@mail.ru) Received: from mx28.mail.ru (mx28.mail.ru [194.67.23.67]) by mx1.freebsd.org (Postfix) with ESMTP id F3A9C13C4B8 for ; Fri, 26 Jan 2007 20:05:22 +0000 (UTC) (envelope-from archon_666@mail.ru) Received: from mx7.mail.ru (mx7.mail.ru [194.67.23.27]) by mx28.mail.ru (mPOP.Fallback_MX) with ESMTP id E46FB3CA945 for ; Fri, 26 Jan 2007 18:46:38 +0300 (MSK) Received: from [81.30.209.11] (port=10019 helo=[192.168.28.9]) by mx7.mail.ru with asmtp id 1HATHd-0009M7-00 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 18:46:34 +0300 From: archon To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Fri, 26 Jan 2007 20:49:19 +0500 Message-Id: <1169826560.9859.15.camel@cameroon.enclave.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable Subject: 'make buildworld' fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 20:05:27 -0000 I've just updated the sources in FreeBSD 6.2-RELEASE and tried to rebuild world. With option 'NO_CXX=3DYES' in /etc/make.conf world compiled successful, if this option not added 'make buildworld' failed. 'make buildworld' fails: <..> =3D=3D=3D> gnu/usr.bin/groff/src/libs/libgroff (depend) Making version.cpp rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/gr= off/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src= /include /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../con= trib/groff/src/libs/libgroff/iftoa.c /usr/src/gnu/usr.bin/groff/src/libs/li= bgroff/../../../../../../contrib/groff/src/libs/libgroff/itoa.c /usr/src/gn= u/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/= libgroff/matherr.c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../..= /../../contrib/groff/src/libs/libgroff/progname.c mkdep -f .depend -a /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../co= ntrib/groff/src/libs/libgroff/assert.cpp /usr/src/gnu/usr.bin/groff/src/lib= s/libgroff/../../../../../../contrib/groff/src/libs/libgroff/change_lf.cpp = /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/cmap.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/.= ./../../../../../contrib/groff/src/libs/libgroff/color.cpp /usr/src/gnu/usr= .bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgr= off/cset.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../..= /contrib/groff/src/libs/libgroff/device.cpp /usr/src/gnu/usr.bin/groff/src/= libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/errarg.cpp = /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/error.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/= ../../../../../../contrib/groff/src/libs/libgroff/fatal.cpp /usr/src/gnu/us= r.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libg= roff/filename.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../= ../../contrib/groff/src/libs/libgroff/font.cpp /usr/src/gnu/usr.bin/groff/s= rc/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/fontfile= .cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib= /groff/src/libs/libgroff/geometry.cpp /usr/src/gnu/usr.bin/groff/src/libs/l= ibgroff/../../../../../../contrib/groff/src/libs/libgroff/glyphuni.cpp /usr= /src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/sr= c/libs/libgroff/htmlhint.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/.= ./../../../../../contrib/groff/src/libs/libgroff/hypot.cpp /usr/src/gnu/usr= .bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgr= off/invalid.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../..= /../contrib/groff/src/libs/libgroff/lf.cpp /usr/src/gnu/usr.bin/groff/src/l= ibs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/lineno.cpp /= usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff= /src/libs/libgroff/macropath.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgro= ff/../../../../../../contrib/groff/src/libs/libgroff/maxfilename.cpp /usr/s= rc/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/= libs/libgroff/mksdir.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../..= /../../../../contrib/groff/src/libs/libgroff/nametoindex.cpp /usr/src/gnu/u= sr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/lib= groff/new.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../.= ./contrib/groff/src/libs/libgroff/paper.cpp /usr/src/gnu/usr.bin/groff/src/= libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/prime.cpp /= usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff= /src/libs/libgroff/ptable.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/= ../../../../../../contrib/groff/src/libs/libgroff/searchpath.cpp /usr/src/g= nu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs= /libgroff/string.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../= ../../../contrib/groff/src/libs/libgroff/strsave.cpp /usr/src/gnu/usr.bin/g= roff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/sy= mbol.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../con= trib/groff/src/libs/libgroff/tmpfile.cpp /usr/src/gnu/usr.bin/groff/src/lib= s/libgroff/../../../../../../contrib/groff/src/libs/libgroff/tmpname.cpp /u= sr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/= src/libs/libgroff/unicode.cpp /usr/src/gnu/usr.bin/groff/src/libs/libgroff/= ../../../../../../contrib/groff/src/libs/libgroff/uniglyph.cpp /usr/src/gnu= /usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/l= ibgroff/uniuni.cpp version.cpp=20 /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/cmap.cpp:27:18: cmap.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/color.cpp:26:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/color.cpp:27:19: color.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/color.cpp:28:18: cset.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/color.cpp:37:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/color.cpp:38:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/cset.cpp:28:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/cset.cpp:29:18: cset.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/device.cpp:22:20: device.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/device.cpp:23:18: defs.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/errarg.cpp:24:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/error.cpp:24:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/error.cpp:25:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:28:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:29:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:30:18: cset.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:31:18: font.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/font.cpp:32:19: paper.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/fontfile.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/fontfile.cpp:27:18: font.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/fontfile.cpp:28:24: searchpath.h: No such file or direc= tory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/fontfile.cpp:29:20: device.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/fontfile.cpp:30:18: defs.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/glyphuni.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/glyphuni.cpp:23:25: stringclass.h: No such file or dire= ctory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/glyphuni.cpp:24:20: ptable.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/glyphuni.cpp:26:21: unicode.h: No such file or director= y /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/htmlhint.cpp:20:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/htmlhint.cpp:25:22: nonposix.h: No such file or directo= ry /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/htmlhint.cpp:26:25: stringclass.h: No such file or dire= ctory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/htmlhint.cpp:27:26: html-strings.h: No such file or dir= ectory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/invalid.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/lf.cpp:23:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/lf.cpp:24:18: cset.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/lf.cpp:25:25: stringclass.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/macropath.cpp:21:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/macropath.cpp:22:24: searchpath.h: No such file or dire= ctory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/macropath.cpp:23:23: macropath.h: No such file or direc= tory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/macropath.cpp:24:18: defs.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/maxfilename.cpp:23:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/nametoindex.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/nametoindex.cpp:27:20: errarg.h: No such file or direct= ory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/nametoindex.cpp:28:19: error.h: No such file or directo= ry /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/nametoindex.cpp:29:18: font.h: No such file or director= y /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/nametoindex.cpp:30:20: ptable.h: No such file or direct= ory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/new.cpp:21:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/new.cpp:26:19: posix.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/new.cpp:27:22: nonposix.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/paper.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/paper.cpp:23:19: paper.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/ptable.cpp:20:20: ptable.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/ptable.cpp:21:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/ptable.cpp:22:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/searchpath.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/searchpath.cpp:28:24: searchpath.h: No such file or dir= ectory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/searchpath.cpp:29:22: nonposix.h: No such file or direc= tory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/string.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/string.cpp:24:25: stringclass.h: No such file or direct= ory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/symbol.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/symbol.cpp:24:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/symbol.cpp:25:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/symbol.cpp:26:20: symbol.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpfile.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpfile.cpp:27:19: posix.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpfile.cpp:28:20: errarg.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpfile.cpp:29:19: error.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpfile.cpp:30:22: nonposix.h: No such file or director= y /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpname.cpp:25:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpname.cpp:32:19: posix.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/tmpname.cpp:33:22: nonposix.h: No such file or director= y /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/unicode.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/unicode.cpp:23:18: cset.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/unicode.cpp:24:25: stringclass.h: No such file or direc= tory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/unicode.cpp:26:21: unicode.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniglyph.cpp:22:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniglyph.cpp:23:25: stringclass.h: No such file or dire= ctory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniglyph.cpp:24:20: ptable.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniglyph.cpp:26:21: unicode.h: No such file or director= y /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniuni.cpp:25:17: lib.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniuni.cpp:26:25: stringclass.h: No such file or direct= ory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniuni.cpp:27:20: ptable.h: No such file or directory /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/grof= f/src/libs/libgroff/uniuni.cpp:29:21: unicode.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. My kernel configuration file: machine i386 cpu I686_CPU ident TRISHA 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 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 SCSI 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 ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # 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 kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc # Add suspend/resume support for the i8254. device pmtimer # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device ppp # Kernel PPP device tun # Packet tunnel. 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 DRIVER #device uhci #device ohci #device ehci #device usb #device ucom #device uplcom # SOUND DRIVER #device sound #device snd_ich # NETWORK DRIVER #device miibus #device sis # SERIAL PORT DRIVER device sio # ATA AND ATAPI DRIVER device ata device atadisk device atapicd device atapicam options ATA_STATIC_ID # SCSI DRIVER device cd device scbus device pass My /etc/make.conf configuration file: CPUTYPE?=3Dpentium4 CFLAGS=3D-O0 -g -pipe MAKE_SHELL?=3Dsh COPTFLAGS=3D-O0 -g -pipe CXXFLAGS=3D-O0 -g -pipe X_WINDOW_SYSTEM=3Dxorg KERNCONF=3DGENERIC # TRISHA ALWAYS_CHECK_MAKE=3DYES SUP_UPDATE=3DYES SUP=3D/usr/local/bin/cvsup SUPFLAGS=3D-g -L 2 SUPHOST=3Dcvsup.ru.FreeBSD.org SUPFILE=3D"/home/archon/etc/cvsup/src-supfile" PORTSSUPFILE=3D"/home/archon/etc/cvsup/ports-supfile" DOCSUPFILE=3D"/home/archon/etc/cvsup/doc-supfile" DOC_LANG=3Den_US.ISO8859-1 ru_RU.KOI8-R MODULES_OVERRIDE=3Dsound/sound sound/driver/ich mii sis ucom uplcom linprocfs linux acpi/acpi usb libiconv libmchain smbfs cd9660_iconv From owner-freebsd-stable@FreeBSD.ORG Fri Jan 26 23:14:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD62A16A400 for ; Fri, 26 Jan 2007 23:14:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7F70A13C481 for ; Fri, 26 Jan 2007 23:14:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0QMsujH049398; Fri, 26 Jan 2007 15:55:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45BA86B6.3090609@samsco.org> Date: Fri, 26 Jan 2007 15:54:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 26 Jan 2007 15:55:01 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: panic: kmem_malloc boot error w/ 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 23:14:06 -0000 Pekka Savola wrote: > Hello, > > (Not subscribed, let's hope this gets through..) > > I saw the strangest case I've yet seen today when upgrading a dual-P3 > system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6 > (6.2). The system paniced at boot with a message like: > > panic: kmem_malloc(-1059844096): kmem_map too small: 2990080 total > allocated > > This seemed to be just before one would mount the root filesystem. > > GENERIC kernel on 6.2-RELEASE boot CD worked though. FreeSBIE 2.0 > kernel (6.2-RELEASE) panicked in the same way, as well as another Rescue > CD based on FreeBSD 6.1. > > I did a fair bit of bisecting (about 10 compiles) to find out which > feature in GENERIC removes this panic, and came to a suprising conclusion: > > makeoptions DEBUG=-g > > .. when I added this, boot works fine. When removing it, you get the > panic. > > Strange, huh? :-/ > > > Below is a snippet of the boot log: Please compile KDB and DDB into your kernel so we can see exactly where the panic is happening. Scott From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 01:29:51 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C52F216A401 for ; Sat, 27 Jan 2007 01:29:51 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [216.177.243.35]) by mx1.freebsd.org (Postfix) with ESMTP id 707E313C46B for ; Sat, 27 Jan 2007 01:29:51 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l0R1CJd9066168 for ; Fri, 26 Jan 2007 17:13:45 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l0R1CI0f066167 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 17:12:18 -0800 (PST) (envelope-from chris#@1command.com) X-Authentication-Warning: mail.1command.com: www set sender to chris#@1command.com using -f Received: from demon.dnswatch.com (demon.dnswatch.com [216.177.243.42]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 26 Jan 2007 17:12:18 -0800 Message-ID: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 26 Jan 2007 17:12:18 -0800 From: "Chris H." To: "[FBSDS]" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 01:29:51 -0000 ...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the "norm" for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machine i386 cpu I686_CPU device apic uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 01:34:41 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6555116A405 for ; Sat, 27 Jan 2007 01:34:41 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [216.177.243.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1112513C489 for ; Sat, 27 Jan 2007 01:34:40 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l0R1XDvC068384 for ; Fri, 26 Jan 2007 17:34:39 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l0R1XD3B068383 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 17:33:13 -0800 (PST) (envelope-from chris#@1command.com) X-Authentication-Warning: mail.1command.com: www set sender to chris#@1command.com using -f Received: from demon.dnswatch.com (demon.dnswatch.com [216.177.243.42]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 26 Jan 2007 17:33:13 -0800 Message-ID: <20070126173313.y153cjd400so0kk8@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 26 Jan 2007 17:33:13 -0800 From: "Chris H." To: "[FBSDS]" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 01:34:41 -0000 ...or when will FreeBSD support Pentium features? I want to apologize in advance if this should be on the kern@ But it seemed apropriate for this list too and I'm already on it. I've noticed building kernels, that since v. >= 5 that during the phase 2/3 all the lines echoed to the screen contain: -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... As Pentium have been the "norm" for many years now, why aren't these /assumed/? I'm building on several SMP PIII's and a build is in process now on a PIV Athalon running 6.2 the source and ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this current kernel build is echoing these same -mno- lines. I have machine i386 cpu I686_CPU device apic uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES Yet the only case I find relating to this is on line: 130 in: /src/sys/i386/conf/NOTES which reads: # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default # on I686_CPU and above. Default? hmmm... not as far as I can tell. Anyway, I would *greatly* appreciate any insight on this issue. Do I need to pollute my make.conf file to achive a Pentium kernel? Thank you very much for all your time and consideration. --Chris -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 01:44:23 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6506916A402 for ; Sat, 27 Jan 2007 01:44:23 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id 04BFB13C483 for ; Sat, 27 Jan 2007 01:44:22 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id l0R19gev097292 for ; Fri, 26 Jan 2007 19:09:42 -0600 (CST) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id l0R19fDU097291 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 19:09:41 -0600 (CST) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Fri, 26 Jan 2007 19:09:41 -0600 From: Scott Lambert To: freebsd-stable@freebsd.org Message-ID: <20070127010941.GA50150@sysmon.tcworks.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Promise FastTrak SX4300 support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 01:44:23 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have installed FreeBSD 6.2-RELEASE on a server with a Promise FastTrak SX4300, currently installed in a 32-bit PCI slot. I'm booting off a drive which is connected to the onboard ICH7 SATA300 controller. I have made the minimal changes to dev/ata/ata-chipset.c and dev/ata/ata-pci.h to identify the card based on what I could decipher of the verbose dmesg. It now identifies the card but has problems and won't use it. I've tried a few different combinations of settings in ata-chipset. Changing the fourth column seemed to always give me the same errors in dmesg. Changing the third column to PRTX seemed to make progress. It changed my boot drive from ad7s1a to ad11s1a. Changing the third column to PRNEW caused a panic. :-) Does anybody have any suggestions? --- ata-pci.h.6.2 Fri Jan 26 22:21:21 2007 +++ ata-pci.h Fri Jan 26 22:23:18 2007 @@ -248,6 +248,7 @@ #define ATA_PDC40719 0x3515105a #define ATA_PDC40775 0x3d73105a #define ATA_PDC40779 0x3577105a +#define ATA_PDC41721 0x6302105a #define ATA_PDC20617 0x6617105a #define ATA_PDC20618 0x6626105a #define ATA_PDC20619 0x6629105a --- ata-chipset.c.6.2 Fri Jan 26 22:21:03 2007 +++ ata-chipset.c.PRTX.PRSATA2 Fri Jan 26 23:52:56 2007 @@ -3058,6 +3058,7 @@ { ATA_PDC40718, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40718" }, { ATA_PDC40719, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40719" }, { ATA_PDC40779, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40779" }, + { ATA_PDC41721, 0, PRTX, PRSATA2, ATA_SA300, "PDC41721" }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; uintptr_t devid = 0; --- ata-chipset.c.6.2 Fri Jan 26 22:21:03 2007 +++ ata-chipset.c.PRNEW.PRSATA2 Sat Jan 27 00:33:26 2007 @@ -3058,6 +3058,7 @@ { ATA_PDC40718, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40718" }, { ATA_PDC40719, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40719" }, { ATA_PDC40779, 0, PRMIO, PRSATA2, ATA_SA300, "PDC40779" }, + { ATA_PDC41721, 0, PRNEW, PRSATA2, ATA_SA300, "PDC41721" }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; uintptr_t devid = 0; The relevant parts of the dmesg of a verbose boot are: pcib4: at device 30.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x1000-0x1fff pcib4: memory decode 0x28400000-0x284fffff pcib4: prefetched decode 0x20000000-0x283fffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x105a, dev=0x6302, revid=0x00 bus=4, slot=1, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x60 (2880 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D3 current D0 MSI supports 16 messages, 64 bit map[10]: type 4, range 32, base 00001140, size 5, enabled pcib4: (null) requested I/O range 0x1140-0x115f: in range map[18]: type 1, range 64, base 28440000, size 16, enabled pcib4: (null) requested memory range 0x28440000-0x2844ffff: good map[20]: type 3, range 64, base 28000000, size 22, enabled pcib4: (null) requested memory range 0x28000000-0x283fffff: good pcib4: matched entry for 4.1.INTA pcib4: slot 1 INTA hardwired to IRQ 22 .... With PRMIO: atapci0: port 0x1140-0x115f mem 0x28440000-0x2844ffff,0x28000000-0x283fffff irq 22 at device 1.0 on pci4 pci4: child atapci0 requested type 4 for rid 0x20, but the BAR says it is an memio ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 atapci0: [MPSAFE] atapci0: Reserved 0x400000 bytes for rid 0x20 type 3 at 0x28000000 pci4: child atapci0 requested type 3 for rid 0x1c, but the BAR says it is an ioport device_attach: atapci0 attach returned 6 With PRTX: atapci0: port 0x1140-0x115f mem 0x28440000 -0x2844ffff,0x28000000-0x283fffff irq 22 at device 1.0 on pci4 pci4: child atapci0 requested type 4 for rid 0x20, but the BAR says it is an memio ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 atapci0: [MPSAFE] ata2: on atapci0 atapci0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x1140 device_attach: ata2 attach returned 6 ata3: on atapci0 pci4: child atapci0 requested type 4 for rid 0x18, but the BAR says it is an memio device_attach: ata3 attach returned 6 -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nm.dmesg.boot" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 26 09:15:25 CST 2007 root@kimsbox.lambertfam.org:/usr/obj/usr/src/sys/SMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b63000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b63174. Calibrating clock(s) ... i8254 clock: 1190812 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2998501350 Hz CPU: Intel(R) Pentium(R) D CPU 3.00GHz (2998.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 Features=0xbfebfbff Features2=0xe43d,> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 535162880 (510 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001f521fff, 512729088 bytes (125178 pages) avail memory = 514093056 (490 MB) MP Configuration Table version 1.4 found at 0xc00fec70 Table 'FACP' at 0x1fefcf10 Table 'APIC' at 0x1fefce10 MADT: Found table at 0x1fefce10 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled INTR: Adding local APIC 0 as a target ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 pnpbios: Found PnP BIOS data at 0xc00fe0e0 pnpbios: Entry = f0000:a507 Rev = 1.0 pnpbios: OEM ID 8224744e Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 5, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 5 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic1: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jan 26 2007 09:15:11) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa18 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27788086) pcibios: No call entry point acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xcd6b3000 pa 0x9b000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x27e0, revid=0x01 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x27e2, revid=0x01 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base 00003080, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003060, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 00003040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 00003020, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 28600400, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x01 (250 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 000030b0, size 4, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0047, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000030c8, size 3, enabled map[14]: type 4, range 32, base 000030e4, size 2, enabled map[18]: type 4, range 32, base 000030c0, size 3, enabled map[1c]: type 4, range 32, base 000030e0, size 2, enabled map[20]: type 4, range 32, base 000030a0, size 4, enabled map[24]: type 1, range 32, base 28600000, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0141, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 pcib2: at device 28.4 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 pcib3: at device 28.5 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x2000-0x2fff pcib3: memory decode 0x28500000-0x285fffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 28500000, size 17, enabled pcib3: (null) requested memory range 0x28500000-0x2851ffff: good map[18]: type 4, range 32, base 00002000, size 5, enabled pcib3: (null) requested I/O range 0x2000-0x201f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 em0: port 0x2000-0x201f mem 0x28500000-0x2851ffff irq 17 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0x28500000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0x2000 em0: bpf attached em0: Ethernet address: 00:19:d1:29:87:40 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 em0: [MPSAFE] uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3080 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci0: [GIANT-LOCKED] 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 uhci1: port 0x3060-0x307f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 uhci1: [GIANT-LOCKED] 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 uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3020-0x303f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x28600400-0x286007ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0x28600400 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x1000-0x1fff pcib4: memory decode 0x28400000-0x284fffff pcib4: prefetched decode 0x20000000-0x283fffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x105a, dev=0x6302, revid=0x00 bus=4, slot=1, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x60 (2880 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D3 current D0 MSI supports 16 messages, 64 bit map[10]: type 4, range 32, base 00001140, size 5, enabled pcib4: (null) requested I/O range 0x1140-0x115f: in range map[18]: type 1, range 64, base 28440000, size 16, enabled pcib4: (null) requested memory range 0x28440000-0x2844ffff: good map[20]: type 3, range 64, base 28000000, size 22, enabled pcib4: (null) requested memory range 0x28000000-0x283fffff: good pcib4: matched entry for 4.1.INTA pcib4: slot 1 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x515e, revid=0x02 bus=4, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 20000000, size 27, enabled pcib4: (null) requested memory range 0x20000000-0x27ffffff: good map[14]: type 4, range 32, base 00001000, size 8, enabled pcib4: (null) requested I/O range 0x1000-0x10ff: in range map[18]: type 1, range 32, base 28450000, size 16, enabled pcib4: (null) requested memory range 0x28450000-0x2845ffff: good pcib4: matched entry for 4.4.INTA pcib4: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=4, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 28420000, size 17, enabled pcib4: (null) requested memory range 0x28420000-0x2843ffff: good map[14]: type 1, range 32, base 28400000, size 17, enabled pcib4: (null) requested memory range 0x28400000-0x2841ffff: good map[18]: type 4, range 32, base 00001100, size 6, enabled pcib4: (null) requested I/O range 0x1100-0x113f: in range pcib4: matched entry for 4.5.INTA pcib4: slot 5 INTA hardwired to IRQ 17 atapci0: port 0x1140-0x115f mem 0x28440000-0x2844ffff,0x28000000-0x283fffff irq 22 at device 1.0 on pci4 pci4: child atapci0 requested type 4 for rid 0x20, but the BAR says it is an memio ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 atapci0: [MPSAFE] atapci0: Reserved 0x400000 bytes for rid 0x20 type 3 at 0x28000000 pci4: child atapci0 requested type 3 for rid 0x1c, but the BAR says it is an ioport device_attach: atapci0 attach returned 6 pci4: at device 4.0 (no driver attached) em1: port 0x1100-0x113f mem 0x28420000-0x2843ffff,0x28400000-0x2841ffff irq 17 at device 5.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0x28420000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0x1100 em1: bpf attached em1: Ethernet address: 00:19:d1:29:87:41 em1: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 18 at device 31.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56 ata1: [MPSAFE] atapci2: port 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af mem 0x28600000-0x286003ff irq 19 at device 31.2 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 atapci2: [MPSAFE] ata2: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30c8 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30e4 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30c0 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30e0 ata3: reset tp1 mask=03 ostat0=7f ostat1=50 ata3: stat0=0x7f err=0x00 lsb=0xff msb=0xff ata3: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=7f stat1=50 devices=0x2 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ sio0: irq maps: 0x4c01 0x4c11 0x4c01 0x4c01 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4c01 0x4c01 0x4c01 0x4c01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750294 hz Timecounter "TSC" frequency 2998501350 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata3-slave: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad7: 76319MB at ata3-slave SATA150 ad7: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad7 ad7: Intel check1 failed ad7: Adaptec check1 failed ad7: LSI (v3) check1 failed ad7: LSI (v2) check1 failed ad7: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 INTR: Assigning IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 1 to local APIC 0 INTR: Assigning IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 1 INTR: Assigning IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 0 INTR: Assigning IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 1 INTR: Assigning IRQ 15 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 0 INTR: Assigning IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 1 INTR: Assigning IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 0 INTR: Assigning IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 1 INTR: Assigning IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 0 INTR: Assigning IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 1 INTR: Assigning IRQ 23 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 0 Trying to mount root from ufs:/dev/ad7s1a start_init: trying /sbin/init --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.PRTX.PRSATA2" Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RC1 #4: Fri Jan 26 23:58:57 CST 2007 root@kimsbox.lambertfam.org:/usr/obj/usr/src/sys/SMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b61000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b61174. Calibrating clock(s) ... i8254 clock: 439 Hz 439 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2995507395 Hz CPU: Intel(R) Pentium(R) D CPU 3.00GHz (2995.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 Features=0xbfebfbff Features2=0xe43d,> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 535162880 (510 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001f521fff, 512729088 bytes (125178 pages) avail memory = 514093056 (490 MB) MP Configuration Table version 1.4 found at 0xc00fec70 Table 'FACP' at 0x1fefcf10 Table 'APIC' at 0x1fefce10 MADT: Found table at 0x1fefce10 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled INTR: Adding local APIC 0 as a target ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 pnpbios: Found PnP BIOS data at 0xc00fe0e0 pnpbios: Entry = f0000:a507 Rev = 1.0 pnpbios: OEM ID 8224744e Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 5, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 5 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic1: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jan 26 2007 23:57:46) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa18 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27788086) pcibios: No call entry point acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xcd6b3000 pa 0x9b000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 7 9 10 11 12 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 7 9 10 11 12 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x27e0, revid=0x01 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x8086, dev=0x27e2, revid=0x01 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base 00003080, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003060, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 00003040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 00003020, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 28600400, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x01 (250 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 000030b0, size 4, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0047, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000030c8, size 3, enabled map[14]: type 4, range 32, base 000030e4, size 2, enabled map[18]: type 4, range 32, base 000030c0, size 3, enabled map[1c]: type 4, range 32, base 000030e0, size 2, enabled map[20]: type 4, range 32, base 000030a0, size 4, enabled map[24]: type 1, range 32, base 28600000, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0141, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 pcib2: at device 28.4 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 pcib3: at device 28.5 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x2000-0x2fff pcib3: memory decode 0x28500000-0x285fffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 28500000, size 17, enabled pcib3: (null) requested memory range 0x28500000-0x2851ffff: good map[18]: type 4, range 32, base 00002000, size 5, enabled pcib3: (null) requested I/O range 0x2000-0x201f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 em0: port 0x2000-0x201f mem 0x28500000-0x2851ffff irq 17 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0x28500000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0x2000 em0: bpf attached em0: Ethernet address: 00:19:d1:29:87:40 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 em0: [MPSAFE] uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3080 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci0: [GIANT-LOCKED] 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 uhci1: port 0x3060-0x307f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 uhci1: [GIANT-LOCKED] 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 uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3020-0x303f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x28600400-0x286007ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0x28600400 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x1000-0x1fff pcib4: memory decode 0x28400000-0x284fffff pcib4: prefetched decode 0x20000000-0x283fffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x105a, dev=0x6302, revid=0x00 bus=4, slot=1, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x60 (2880 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D3 current D0 MSI supports 16 messages, 64 bit map[10]: type 4, range 32, base 00001140, size 5, enabled pcib4: (null) requested I/O range 0x1140-0x115f: in range map[18]: type 1, range 64, base 28440000, size 16, enabled pcib4: (null) requested memory range 0x28440000-0x2844ffff: good map[20]: type 3, range 64, base 28000000, size 22, enabled pcib4: (null) requested memory range 0x28000000-0x283fffff: good pcib4: matched entry for 4.1.INTA pcib4: slot 1 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x515e, revid=0x02 bus=4, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base 20000000, size 27, enabled pcib4: (null) requested memory range 0x20000000-0x27ffffff: good map[14]: type 4, range 32, base 00001000, size 8, enabled pcib4: (null) requested I/O range 0x1000-0x10ff: in range map[18]: type 1, range 32, base 28450000, size 16, enabled pcib4: (null) requested memory range 0x28450000-0x2845ffff: good pcib4: matched entry for 4.4.INTA pcib4: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=4, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 28420000, size 17, enabled pcib4: (null) requested memory range 0x28420000-0x2843ffff: good map[14]: type 1, range 32, base 28400000, size 17, enabled pcib4: (null) requested memory range 0x28400000-0x2841ffff: good map[18]: type 4, range 32, base 00001100, size 6, enabled pcib4: (null) requested I/O range 0x1100-0x113f: in range pcib4: matched entry for 4.5.INTA pcib4: slot 5 INTA hardwired to IRQ 17 atapci0: port 0x1140-0x115f mem 0x28440000-0x2844ffff,0x28000000-0x283fffff irq 22 at device 1.0 on pci4 pci4: child atapci0 requested type 4 for rid 0x20, but the BAR says it is an memio ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 atapci0: [MPSAFE] ata2: on atapci0 atapci0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x1140 device_attach: ata2 attach returned 6 ata3: on atapci0 pci4: child atapci0 requested type 4 for rid 0x18, but the BAR says it is an memio device_attach: ata3 attach returned 6 pci4: at device 4.0 (no driver attached) em1: port 0x1100-0x113f mem 0x28420000-0x2843ffff,0x28400000-0x2841ffff irq 17 at device 5.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0x28420000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0x1100 em1: bpf attached em1: Ethernet address: 00:19:d1:29:87:41 em1: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 18 at device 31.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56 ata1: [MPSAFE] atapci2: port 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af mem 0x28600000-0x286003ff irq 19 at device 31.2 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 atapci2: [MPSAFE] ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30c8 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30e4 ata4: reset tp1 mask=03 ostat0=7f ostat1=7f ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat1=0x7f err=0xff lsb=0xff msb=0xff ata4: reset tp2 stat0=ff stat1=ff devices=0x0 ata4: [MPSAFE] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30c0 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30e0 ata5: reset tp1 mask=03 ostat0=7f ostat1=50 ata5: stat0=0x7f err=0x00 lsb=0xff msb=0xff ata5: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata5: reset tp2 stat0=7f stat1=50 devices=0x2 ata5: [MPSAFE] pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ sio0: irq maps: 0x4c01 0x4c11 0x4c01 0x4c01 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4c01 0x4c01 0x4c01 0x4c01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750198 hz Timecounter "TSC" frequency 2995507395 Hz quality -100 Timecounters tick every 1.000 msec lo0: em1: Link is up 100 Mbps Full Duplex bpf attached rr232x: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata5-slave: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad11: 76319MB at ata5-slave SATA150 ad11: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad11 ad11: Intel check1 failed ad11: Adaptec check1 failed ad11: LSI (v3) check1 failed ad11: LSI (v2) check1 failed ad11: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 INTR: Assigning IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 1 to local APIC 0 INTR: Assigning IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 1 INTR: Assigning IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 0 INTR: Assigning IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 1 INTR: Assigning IRQ 15 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 0 INTR: Assigning IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 1 INTR: Assigning IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 0 INTR: Assigning IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 1 INTR: Assigning IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 0 INTR: Assigning IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 1 INTR: Assigning IRQ 23 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 0 Trying to mount root from ufs:/dev/ad7s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:ad11s1a\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H\^H \^H? List of GEOM managed disk devices: ad11s1d ad11s1c ad11s1b ad11s1a ad11s1 ad11 acd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:ad11s1a Trying to mount root from ufs:ad11s1a start_init: trying /sbin/init em1: Link is Down em1: Link is up 100 Mbps Full Duplex --xHFwDpU9dbj6ez1V-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 02:49:37 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 213EA16A400 for ; Sat, 27 Jan 2007 02:49:37 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [213.154.244.69]) by mx1.freebsd.org (Postfix) with ESMTP id DD82213C484 for ; Sat, 27 Jan 2007 02:49:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id E2683B80C; Sat, 27 Jan 2007 03:49:33 +0100 (CET) Message-ID: <45BABDBF.2090601@andric.com> Date: Sat, 27 Jan 2007 03:49:35 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0b2pre (Windows/20070124) MIME-Version: 1.0 To: "Chris H." References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> In-Reply-To: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 02:49:37 -0000 Chris H. wrote: > I've noticed building kernels, that since v. >= 5 that during > the phase 2/3 all the lines echoed to the screen contain: > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... See /usr/share/examples/etc/make.conf. > As Pentium have been the "norm" for many years now, why aren't > these /assumed/? Because i486 is still the lowest common denominator, at least for 6.x. > Default? hmmm... not as far as I can tell. Anyway, I would *greatly* > appreciate any insight on this issue. Do I need to pollute my make.conf > file to achive a Pentium kernel? Yes. Is this so horrible? From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 03:01:43 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1181B16A400 for ; Sat, 27 Jan 2007 03:01:43 +0000 (UTC) (envelope-from john_m_cooper@yahoo.com) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by mx1.freebsd.org (Postfix) with SMTP id B177913C483 for ; Sat, 27 Jan 2007 03:01:42 +0000 (UTC) (envelope-from john_m_cooper@yahoo.com) Received: (qmail 82592 invoked from network); 27 Jan 2007 02:35:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Cu1idbx2s4OlVxeGCE9TAOMRqA6BupgVuzMBfPTepHEf1ivDnImkYK+2eXWcQ9lNAZxKCVuWUW5vCZphsp49HQA/aH/tADzyWLFf0TKnq8sByMDVfq3o136KFyT1UDZreIo3ciCZKAehR0ZKZH/0kAzOt485RTczYHvip9fXJDU= ; Received: from unknown (HELO borgdemon2.10500cascaderuncourt.home) (j.m.cooper@borgsdemons.com@68.33.224.115 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 27 Jan 2007 02:35:00 -0000 X-YMail-OSG: AVhFBkEVM1mc86t9hXOkplc9RSFc33c6K_FWHhc1LZJrywBYOD14usgQuprB8LgvGhD2yMiJjdoTlxWqGNnOCB47RA_MBGPUZmZGy5i9IgpFxAIZpfab7vA6yCzEBpNE6nQxG0vOOKyBkBy_iQucEMLPng7ZaLWi4HNS0d5ZAY7gJe4U0F_bRScOi4VT Received: from [127.0.0.1] (localhost [127.0.0.1]) by borgdemon2.10500cascaderuncourt.home (Postfix) with ESMTP id 66A555C3A; Fri, 26 Jan 2007 21:35:00 -0500 (EST) Message-ID: <45BABA54.2020405@yahoo.com> Date: Fri, 26 Jan 2007 21:35:00 -0500 From: John Merryweather Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070121) MIME-Version: 1.0 To: "Chris H." References: <20070126173313.y153cjd400so0kk8@webmail.1command.com> In-Reply-To: <20070126173313.y153cjd400so0kk8@webmail.1command.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "\[FBSDS\]" Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 03:01:43 -0000 Chris H. wrote: > ...or when will FreeBSD support Pentium features? > > I want to apologize in advance if this should be on the kern@ > But it seemed apropriate for this list too and I'm already on it. > I've noticed building kernels, that since v. >= 5 that during > the phase 2/3 all the lines echoed to the screen contain: > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... > As Pentium have been the "norm" for many years now, why aren't > these /assumed/? I'm building on several SMP PIII's and a build > is in process now on a PIV Athalon running 6.2 the source and > ports tree were cvsupped 01-25 @02:03:00 -0800. Yet this > current kernel build is echoing these same -mno- lines. I have > machine i386 > cpu I686_CPU > device apic > uncommented and I386_CPU, I486_CPU & I586_CPU commented. I have > grepped the /src/sys/conf/NOTES as well as the /src/sys/i386/conf/NOTES > Yet the only case I find relating to this is on line: 130 in: > /src/sys/i386/conf/NOTES which reads: > # CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default > # on I686_CPU and above. > Default? hmmm... not as far as I can tell. Anyway, I would *greatly* > appreciate any insight on this issue. Do I need to pollute my make.conf > file to achive a Pentium kernel? > > Thank you very much for all your time and consideration. > > --Chris > > Context switching. We already preserve the "core" CPU state and the FPU state between context switches. Adding MMX into the mix means preserving an MMX state (since it can clobber the FPU state) and so forth. jmc From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 03:09:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A480116A405 for ; Sat, 27 Jan 2007 03:09:16 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [216.177.243.35]) by mx1.freebsd.org (Postfix) with ESMTP id 3EAB013C46B for ; Sat, 27 Jan 2007 03:09:16 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l0R37lXU077711 for ; Fri, 26 Jan 2007 19:09:13 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l0R37liC077710 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 19:07:47 -0800 (PST) (envelope-from chris#@1command.com) X-Authentication-Warning: mail.1command.com: www set sender to chris#@1command.com using -f Received: from demon.dnswatch.com (demon.dnswatch.com [216.177.243.42]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 26 Jan 2007 19:07:47 -0800 Message-ID: <20070126190747.2488s1r41sw0scgw@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 26 Jan 2007 19:07:47 -0800 From: "Chris H." To: freebsd-stable@freebsd.org References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> <45BABDBF.2090601@andric.com> In-Reply-To: <45BABDBF.2090601@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 03:09:16 -0000 > Context switching. > We already preserve the "core" CPU state and the FPU state between > context switches. Adding MMX into the mix means preserving an MMX > state (since it can clobber the FPU state) and so forth. > > jmc Quoting Dimitry Andric : > Chris H. wrote: >> I've noticed building kernels, that since v. >= 5 that during >> the phase 2/3 all the lines echoed to the screen contain: >> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... > > See /usr/share/examples/etc/make.conf. > > >> As Pentium have been the "norm" for many years now, why aren't >> these /assumed/? > > Because i486 is still the lowest common denominator, at least for 6.x. > > >> Default? hmmm... not as far as I can tell. Anyway, I would *greatly* >> appreciate any insight on this issue. Do I need to pollute my make.conf >> file to achive a Pentium kernel? > > Yes. Is this so horrible? > Hello Kris, John, Dimitry, and thank you for your taking the time to respond and the "wake-up call" (in regards to searching the list first) ;) Based on your responses and my research in that area: ---------------------------------------------------------------------- Yes, it's supposed to be that way. Certain parts of the FreeBSD system cannot use MMX or SSE instructions (e.g. the boot loader) but it's okay since they are absolutely not performance critical. Kris ###################################################################### The kernel will "support" MMX and SSE -- that is, any programs (root or userland) which use MMX/SSE will work just fine. That is: any programs built with gcc can indeed support MMX and SSE operations. The kernel itself _will not_ use any SSE or MMX operations when built. This is because these optimisations are known to break the FreeBSD kernel. This applies to all i386 architectures, and probably 64-bit architectures too (not sure). Chad ---------------------------------------------------------------------- Can I (pre || a)ssume that given my CPU echoes the following: CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 That I simply build world/kernel with an clean (empty) make.conf and add the following during port(s) building to attain optimum results given my CPU for this current biuld? CPUTYPE?=pentium4 COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Sorry, I'm new to Athlon. Does it show? Again, apologies for spamming this list, and thank you (and everyone else) very much for all your time. --Chris -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 03:15:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3157916A402 for ; Sat, 27 Jan 2007 03:15:56 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [216.177.243.35]) by mx1.freebsd.org (Postfix) with ESMTP id D5C2613C484 for ; Sat, 27 Jan 2007 03:15:55 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l0R3ERD6078390 for ; Fri, 26 Jan 2007 19:15:53 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l0R3ERdG078389 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 19:14:27 -0800 (PST) (envelope-from chris#@1command.com) X-Authentication-Warning: mail.1command.com: www set sender to chris#@1command.com using -f Received: from demon.dnswatch.com (demon.dnswatch.com [216.177.243.42]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 26 Jan 2007 19:14:26 -0800 Message-ID: <20070126191426.md1bqabhusksckcs@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 26 Jan 2007 19:14:26 -0800 From: "Chris H." To: freebsd-stable@freebsd.org References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> <45BABDBF.2090601@andric.com> In-Reply-To: <45BABDBF.2090601@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 03:15:56 -0000 Quoting Dimitry Andric : > Chris H. wrote: >> I've noticed building kernels, that since v. >= 5 that during >> the phase 2/3 all the lines echoed to the screen contain: >> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ... > > See /usr/share/examples/etc/make.conf. Sigh, the obvious is so /easily/ overlooked. Thanks for the "heads-up". :) That helps quite alot. --Chris > > >> As Pentium have been the "norm" for many years now, why aren't >> these /assumed/? > > Because i486 is still the lowest common denominator, at least for 6.x. > > >> Default? hmmm... not as far as I can tell. Anyway, I would *greatly* >> appreciate any insight on this issue. Do I need to pollute my make.conf >> file to achive a Pentium kernel? > > Yes. Is this so horrible? > > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 03:46:59 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F34016A400 for ; Sat, 27 Jan 2007 03:46:59 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.freebsd.org (Postfix) with SMTP id 1879B13C483 for ; Sat, 27 Jan 2007 03:46:58 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 73036 invoked from network); 27 Jan 2007 03:20:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vn/FaQ6MwBf0F9mrLwiHuBU7+1MGnDor9TuavrYzBnz+KHWkIctpjw6EHLPnpQUWdORBzXYfihN0k4tJ3dJ5BzVZM1yY6OZtg63nbJTHxWOsBJ0E/nCqsOPIMFfLVyHYbHSvwPBuccyScSZDWnZsIoVvIIKKTGMUMwL+vgyPcqM= ; Received: from unknown (HELO ?172.16.0.200?) (mikej@rogers.com@74.111.253.239 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 27 Jan 2007 03:20:17 -0000 X-YMail-OSG: LdyaWSgVM1nJ.uS14rKMHGAoMvrnMPOgDzdBnk_5pZa8ejc_6t2rn552OTczfygzgA-- Message-ID: <45BAC510.3050404@rogers.com> Date: Fri, 26 Jan 2007 22:20:48 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Chris H." References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> <45BABDBF.2090601@andric.com> <20070126190747.2488s1r41sw0scgw@webmail.1command.com> In-Reply-To: <20070126190747.2488s1r41sw0scgw@webmail.1command.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 03:46:59 -0000 Chris H. wrote: > > CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 > Features=0x383fbff > > AMD Features=0xc0400800 > > That I simply build world/kernel with an clean (empty) make.conf > and add the following during port(s) building to attain optimum results > given my CPU for this current biuld? > > CPUTYPE?=pentium4 > > COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp" instead. Also, don't modify the COPTFLAGS. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 04:16:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEE5F16A402 for ; Sat, 27 Jan 2007 04:16:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 597A613C46B for ; Sat, 27 Jan 2007 04:16:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0R4G96b013495; Sat, 27 Jan 2007 15:16:09 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0R4G8UX013494; Sat, 27 Jan 2007 15:16:08 +1100 (EST) (envelope-from peter) Date: Sat, 27 Jan 2007 15:16:08 +1100 From: Peter Jeremy To: JoaoBR Message-ID: <20070127041608.GG927@turion.vk2pj.dyndns.org> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701250828.50540.joao@matik.com.br> <87ac074537.fsf@thingy.datadok.no> <200701260924.59674.joao@matik.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wTWi5aaYRw9ix9vO" Content-Disposition: inline In-Reply-To: <200701260924.59674.joao@matik.com.br> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 04:16:12 -0000 --wTWi5aaYRw9ix9vO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2007-Jan-26 09:24:58 -0200, JoaoBR wrote: >like I said, for my understandings firewall implemention for spam fighting= is=20 >wrong > >because you reject the message Except that the original mail was talking about greylisting. This won't reject any mail sent from a MTA that correctly implements SMTP. According to the SMTP specs, I am perfectly at liberty to tell you that I can't accept your mail right now, please try again later. =20 --=20 Peter Jeremy --wTWi5aaYRw9ix9vO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFutII/opHv/APuIcRAgtbAKCG6f7m9MtyZc4GY5CA0ORugyzpHgCgv7+Q HEUJUYRRxZmOev++B573GYc= =BEPr -----END PGP SIGNATURE----- --wTWi5aaYRw9ix9vO-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 04:46:43 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 257C916A400 for ; Sat, 27 Jan 2007 04:46:43 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [216.177.243.35]) by mx1.freebsd.org (Postfix) with ESMTP id A6E9F13C483 for ; Sat, 27 Jan 2007 04:46:42 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l0R4jF2X087323 for ; Fri, 26 Jan 2007 20:46:41 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l0R4jFQ2087322 for freebsd-stable@freebsd.org; Fri, 26 Jan 2007 20:45:15 -0800 (PST) (envelope-from chris#@1command.com) X-Authentication-Warning: mail.1command.com: www set sender to chris#@1command.com using -f Received: from demon.dnswatch.com (demon.dnswatch.com [216.177.243.42]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 26 Jan 2007 20:45:15 -0800 Message-ID: <20070126204515.upi5vwtpu884w080@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 26 Jan 2007 20:45:15 -0800 From: "Chris H." To: freebsd-stable@freebsd.org References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> <45BABDBF.2090601@andric.com> <20070126190747.2488s1r41sw0scgw@webmail.1command.com> <45BAC510.3050404@rogers.com> In-Reply-To: <45BAC510.3050404@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 04:46:43 -0000 Hello and thank you for your response... Quoting Mike Jakubik : > Chris H. wrote: >> >> CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) >> Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 >> Features=0x383fbff AMD >> Features=0xc0400800 >> >> That I simply build world/kernel with an clean (empty) make.conf >> and add the following during port(s) building to attain optimum results >> given my CPU for this current biuld? >> >> CPUTYPE?=pentium4 >> >> COPTFLAGS= -march=pentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 > > Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp" > instead. Also, don't modify the COPTFLAGS. > Ooops. I've changed it to: CPUTYPE?=athlon-4 CFLAGS+= -march=athlon-4 -mmmx -m3dnow -m3dnow+ -msse -msse2 Look a little better? :) --Chris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 05:24:35 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D7D316A400 for ; Sat, 27 Jan 2007 05:24:35 +0000 (UTC) (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 881D713C481 for ; Sat, 27 Jan 2007 05:24:35 +0000 (UTC) (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 2D0971A4D82; Fri, 26 Jan 2007 21:24:35 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B4AD55156B; Sat, 27 Jan 2007 00:24:29 -0500 (EST) Date: Sat, 27 Jan 2007 00:24:29 -0500 From: Kris Kennaway To: "Chris H." Message-ID: <20070127052429.GA23476@xor.obsecurity.org> References: <20070126171218.2k25n1tt28c08wow@webmail.1command.com> <45BABDBF.2090601@andric.com> <20070126190747.2488s1r41sw0scgw@webmail.1command.com> <45BAC510.3050404@rogers.com> <20070126204515.upi5vwtpu884w080@webmail.1command.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20070126204515.upi5vwtpu884w080@webmail.1command.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: Why does FBSD always assume it's on an 8080 CPU? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 05:24:35 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2007 at 08:45:15PM -0800, Chris H. wrote: > Hello and thank you for your response... >=20 > Quoting Mike Jakubik : >=20 > >Chris H. wrote: > >> > >>CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU) > >>Origin =3D "AuthenticAMD" Id =3D 0x680 Stepping =3D 0 > >>Features=3D0x383fbff AMD=20 > >>Features=3D0xc0400800 > >> > >>That I simply build world/kernel with an clean (empty) make.conf > >>and add the following during port(s) building to attain optimum results > >>given my CPU for this current biuld? > >> > >>CPUTYPE?=3Dpentium4 > >> > >>COPTFLAGS=3D -march=3Dpentium4 -mmmx -m3dnow -m3dnow+ -msse -msse2 > > > >Why are you using "pentium4" with an Athlon XP CPU? use "athlonxp"=20 > >instead. Also, don't modify the COPTFLAGS. > > >=20 > Ooops. I've changed it to: >=20 > CPUTYPE?=3Dathlon-4 > CFLAGS+=3D -march=3Dathlon-4 -mmmx -m3dnow -m3dnow+ -msse -msse2 >=20 > Look a little better? :) No, the CFLAGS is still entirely superfluous. Just setting CPUTYPE will DTRT. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFuuINWry0BWjoQKURAoQWAKDMQCatMeC2xxozZiJqA4LEW9B05wCgjUHO h4IGzvwflQXgjSgZEwMWi9Y= =+ajq -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 07:22:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0825A16A404 for ; Sat, 27 Jan 2007 07:22:50 +0000 (UTC) (envelope-from pekkas@netcore.fi) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7531C13C483 for ; Sat, 27 Jan 2007 07:22:49 +0000 (UTC) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l0R7Mhn8017182; Sat, 27 Jan 2007 09:22:44 +0200 Date: Sat, 27 Jan 2007 09:22:43 +0200 (EET) From: Pekka Savola To: Scott Long In-Reply-To: <45BA86B6.3090609@samsco.org> Message-ID: References: <45BA86B6.3090609@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2493/Fri Jan 26 14:00:46 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi Cc: freebsd-stable@freebsd.org Subject: Re: panic: kmem_malloc boot error w/ 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 07:22:50 -0000 On Fri, 26 Jan 2007, Scott Long wrote: >> makeoptions DEBUG=-g >> >> .. when I added this, boot works fine. When removing it, you get the >> panic. >> >> Strange, huh? :-/ >> >> Below is a snippet of the boot log: > > Please compile KDB and DDB into your kernel so we can see exactly where > the panic is happening. Not sure what exactly I should be looking for, but removing the makeoptions line and adding those debuggers, and running 'trace' when it panics gives this: amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 139900MB (286515200 sectors) RAID 1 (optimal) ipmi0: IPMI device rev. 0, firmware rev. 1.81, version 1.5 ipmi0: Number of channels 4 ipmi0: Attached watchdog ATA PseudoRAID loaded GEOM: new disk afd0 GEOM: new disk amrd0 panic: kmem_malloc(-1059844096): kmem_map too small: 3084288 total allocated KDB: enter: panic [thread pid 2 tid 100002 ] Stopped at kdb_enter+0x2c: leave db> trace Tracing pid 2 tid 100002 td 0xc5fadc00 kdb_enter(c06bc072,100,2,c0c361c0,c0d41000,...) at kdb_enter+0x2c panic(c06cb66a,c0d41000,2f1000,e4bb8bb0,c0622016,...) at panic+0x122 kmem_malloc(c0c4b0c0,c0d41000,2,2) at kmem_malloc+0x44f uma_large_malloc(c0d41000,2,c0d40100,0,c6264a50,...) at uma_large_malloc+0x30 malloc(c0d40100,c06eab00,2,c620dc00,c5ff6600,...) at malloc+0x81 g_read_data(c60fb480,0,0,c0d40100,0,0) at g_read_data+0x3c g_mbr_taste(c0709040,c620dc00,0) at g_mbr_taste+0x127 g_new_provider_event(c620dc00,0,66666667,c5fadc00,0,...) at g_new_provider_event+0x6e g_run_events(0,c5fadc00,c5fac430,c04e5dd4,e4bb8d24,...) at g_run_events+0x13e g_event_procbody(0,e4bb8d38,0,c04e5dd4,0,...) at g_event_procbody+0x59 fork_exit(c04e5dd4,0,e4bb8d38) at fork_exit+0x4f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4bb8d6c, ebp = 0 --- HTH, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 09:57:53 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94D2C16A400 for ; Sat, 27 Jan 2007 09:57:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4AF13C46B for ; Sat, 27 Jan 2007 09:57:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 388EA993E4; Sat, 27 Jan 2007 04:57:53 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sat, 27 Jan 2007 04:57:53 -0500 X-Sasl-enc: ufNJq6Ax3CdRifNwmDvvnLqR4et7AhBlV5wG/LzFAo7B 1169891872 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 25BD6146D9; Sat, 27 Jan 2007 04:57:50 -0500 (EST) Message-ID: <45BB221D.3050508@FreeBSD.org> Date: Sat, 27 Jan 2007 09:57:49 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Luigi Rizzo References: <53B52415C756A84E8A169F0E3673A3290E8BA4@IMCSRV6.MITRE.ORG> <20070124071021.GG874@turion.vk2pj.dyndns.org> <20070124073602.B57678@xorpc.icir.org> In-Reply-To: <20070124073602.B57678@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Dummynet and simulating random delay X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 09:57:53 -0000 Luigi Rizzo wrote: > On Wed, Jan 24, 2007 at 06:10:21PM +1100, Peter Jeremy wrote: > >> On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: >> >>> I have a project that requires me to simulate a link with varying but >>> well defined delay. The link is guarenteed to deliver packets in >>> order, so I wish to maintain that behavior with Dummynet. >>> >> I don't think dummynet can do this in its current form. Based on >> > > actually dummynet never does reordering within a single pipe, even > if you change the delay on the fly. > > But this said, you should explain "varying but well defined delay", > Hitting up Google reveals someone hacked Dummynet to introduce per-flow randomness in a uniform distribution: http://www.cs.unc.edu/~jeffay/dirt/FAQ/dummynet-modifications.html However, they included entire source files against FreeBSD 4.5; forward-porting should hopefully not be too tedious for an interested party. Regards, BMS From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 11:29:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDEE316A400 for ; Sat, 27 Jan 2007 11:29:20 +0000 (UTC) (envelope-from vinny@tellurian.com) Received: from mail1.tellurian.net (mail1.tellurian.net [216.182.1.23]) by mx1.freebsd.org (Postfix) with ESMTP id 97F0513C458 for ; Sat, 27 Jan 2007 11:29:20 +0000 (UTC) (envelope-from vinny@tellurian.com) Received: from [216.182.1.34] (cactus.tellurian.net [216.182.1.34]) by mail1.tellurian.net ([216.182.1.23] Tellurian Networks Mail Server version v3.8f2-2) with ESMTP id 570826389-1926380 for ; Sat, 27 Jan 2007 01:23:30 -0500 Message-ID: <45BAEFE0.3080408@tellurian.com> Date: Sat, 27 Jan 2007 01:23:28 -0500 From: Vinny Abello Organization: Tellurian Networks User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: vinny@tellurian.com X-Ultimate-Internet-Connection: Tellurian Networks Subject: How to start rc script after sshd starts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 11:29:21 -0000 Hello, I think this is a relatively easy question to answer but couldn't find anything after some searching. I'm running: FreeBSD engbox.tellurian.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Jan 27 00:37:31 EST 2007 (yeah, pretty recent as of this email) :) I have a daemon that apparently does a check using ssh-keyscan against the loopback address when it starts up. The problem I have is that sshd is not started when the script runs to start this daemon, so it fails and I end up having to start it manually. What is the recommended way to get this script to start after sshd has started up? I was hoping to not have to hack any rc scripts up from their defaults for starting up the system if possible. It's a standard rc script in /usr/local/etc/rc.d. If it matters, the daemon is smokeping. I can stop it from using ssh-keyscan completely as I really don't use the probe at all in smokeping but I'm curious as to the proper way of making this work. Any pointers are appreciated. Thanks! -- Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 12:11:13 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAFFA16A40B for ; Sat, 27 Jan 2007 12:11:13 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 7153713C483 for ; Sat, 27 Jan 2007 12:11:13 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HAmOk-0007ox-PW; Sat, 27 Jan 2007 12:11:10 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HAmOk-0003yQ-Bh; Sat, 27 Jan 2007 12:11:10 +0000 To: joao@matik.com.br, peterjeremy@optushome.com.au In-Reply-To: <20070127041608.GG927@turion.vk2pj.dyndns.org> Message-Id: From: Pete French Date: Sat, 27 Jan 2007 12:11:10 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 12:11:13 -0000 > Except that the original mail was talking about greylisting. This won't > reject any mail sent from a MTA that correctly implements SMTP. According > to the SMTP specs, I am perfectly at liberty to tell you that I can't > accept your mail right now, please try again later. =20 But isn't the point of greylisting that it *will* reject spam, because the MTA won't retry. Indeeed I thought that was the basis of why greylisting is a good idea in the fight against spam. Ergo the guy is right you *are* rejecting the email - because you can talk about stndards all you like, but in practice you know that if it's spam then it isn't likely to come back, and hence saying 'try again' actually effectively rejects the message. That's the entire point isn't it ? Of course, most of us *do* want to achive that result - but what the previous poster seem to be trying to say (to me) is that rejecting mail instead of delivering it to a separate 'spam' inbox is wrong, because it is not our place to decide what our users may or may not want to recive and hence we should not discard email for them without giving them a say in the matter. In practical terms, of course, this is what the vast majority of users *do* want us to do - but in purely theoretical ethical terms the guy is actually right! -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 12:59:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E13B16A400 for ; Sat, 27 Jan 2007 12:59:06 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1605913C4A3 for ; Sat, 27 Jan 2007 12:59:05 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RCwxUL056181; Sat, 27 Jan 2007 10:59:00 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Sat, 27 Jan 2007 10:58:46 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701260924.59674.joao@matik.com.br> <20070127041608.GG927@turion.vk2pj.dyndns.org> In-Reply-To: <20070127041608.GG927@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271058.47517.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Peter Jeremy Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 12:59:06 -0000 On Saturday 27 January 2007 02:16, Peter Jeremy wrote: > On Fri, 2007-Jan-26 09:24:58 -0200, JoaoBR wrote: > >like I said, for my understandings firewall implemention for spam fighti= ng > > is wrong > > > >because you reject the message > > Except that the original mail was talking about greylisting. This won't > reject any mail sent from a MTA that correctly implements SMTP. According > to the SMTP specs, I am perfectly at liberty to tell you that I can't > accept your mail right now, please try again later. greylisting does not necessarily catch incorrectly implemented SMTP but=20 basicly catch any source not seen before with a correct greeting unless it = is=20 whitelisted then, spam is not necessarily incorrectly implemented SMTP and can be an=20 absolute correct email message (within SMTP specs) which then btw is reject= ed so the question is, if this is a correct way to handle it, rejecting I mean also a point to think about, most complains about spam talk about bandwidth= =20 consumption, by asking for resend later you certainly increase bandwidth=20 consumption and resources on both sides =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 14:10:56 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BD2616A405 for ; Sat, 27 Jan 2007 14:10:56 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 986B713C4B6 for ; Sat, 27 Jan 2007 14:10:55 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0REAqAS015974; Sat, 27 Jan 2007 15:10:53 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 80D8FB827; Sat, 27 Jan 2007 15:10:52 +0100 (CET) Date: Sat, 27 Jan 2007 15:10:52 +0100 From: Roland Smith To: JoaoBR Message-ID: <20070127141052.GA96039@slackbox.xs4all.nl> Mail-Followup-To: JoaoBR , freebsd-stable@freebsd.org References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701260924.59674.joao@matik.com.br> <20070127041608.GG927@turion.vk2pj.dyndns.org> <200701271058.47517.joao@matik.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <200701271058.47517.joao@matik.com.br> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 14:10:56 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2007 at 10:58:46AM -0200, JoaoBR wrote: > also a point to think about, most complains about spam talk about bandwid= th=20 > consumption, by asking for resend later you certainly increase bandwidth= =20 > consumption and resources on both sides Most spammers do not bother to return if they get a resend request. That's the whole point of doing this. So practically it doesn't increase bandwidth consumption. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFu11sEnfvsMMhpyURArllAJ90jGssvAVqls/Yb+ThkmtwJTRtWQCfbeG/ +a/ZlPFp46ycZMFPmK7opE4= =Mlmf -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 14:57:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84F6216A401 for ; Sat, 27 Jan 2007 14:57:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECA813C48D for ; Sat, 27 Jan 2007 14:57:23 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0REvL3B064625; Sat, 27 Jan 2007 12:57:21 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Roland Smith , freebsd-stable@freebsd.org Date: Sat, 27 Jan 2007 12:57:08 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271058.47517.joao@matik.com.br> <20070127141052.GA96039@slackbox.xs4all.nl> In-Reply-To: <20070127141052.GA96039@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271257.09365.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 14:57:24 -0000 On Saturday 27 January 2007 12:10, you wrote: > On Sat, Jan 27, 2007 at 10:58:46AM -0200, JoaoBR wrote: > > also a point to think about, most complains about spam talk about > > bandwidth consumption, by asking for resend later you certainly increase > > bandwidth consumption and resources on both sides > > Most spammers do not bother to return if they get a resend request. > That's the whole point of doing this. So practically it doesn't increase > bandwidth consumption. you must see both sides, following your theory, spammers stay away but good= =20 guys *are* coming back, greylisting is at the end the same only a little bi= t=20 less stupid than this anti-spam-send-and-ask-a-confirmation-mail things also that spammers don't come back is an illusion, firstable they do it for= =20 money and secondable if they don't come back from the same source they come= =20 back from another and either one might be spoofed so you can greylisting=20 yourself to death because sooner or later all sources are blacklisted or=20 you're rewriting continuously your whitelists and both are probably=20 unreliable at the end =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:04:31 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50A2B16A405 for ; Sat, 27 Jan 2007 15:04:31 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.freebsd.org (Postfix) with ESMTP id C33DA13C483 for ; Sat, 27 Jan 2007 15:04:30 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0RF4MsD050352; Sat, 27 Jan 2007 16:04:23 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 7C06FB827; Sat, 27 Jan 2007 16:04:22 +0100 (CET) Date: Sat, 27 Jan 2007 16:04:22 +0100 From: Roland Smith To: Jim Pingle Message-ID: <20070127150422.GA96846@slackbox.xs4all.nl> Mail-Followup-To: Jim Pingle , JoaoBR , freebsd-stable@freebsd.org References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701260924.59674.joao@matik.com.br> <20070127041608.GG927@turion.vk2pj.dyndns.org> <200701271058.47517.joao@matik.com.br> <20070127141052.GA96039@slackbox.xs4all.nl> <45BB6296.1080106@pingle.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <45BB6296.1080106@pingle.org> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org, JoaoBR Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:04:31 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2007 at 09:32:54AM -0500, Jim Pingle wrote: > To defeat this, wouldn't a spammer just have to send out the same spam tw= ice > in a row from the same machines, spaced apart by a little time? Yes. But in practice, most spammers don't bother. They don't use a real SMTP server, but custom apps that can be run from zombies to push out as much spam as possible. See http://projects.puremagic.com/greylisting/whitepaper.html > Bonus for the spammer: accounts on servers without greylisting would get = two > copies of the spam. That's not a bonus. Think about it. Sending a message twice will cut the spammer's mail delivery rate at least in half.=20 > Greylisting is a decent idea, but it seems to me that it's just another t= ool > in the ongoing arms race against spammers.=20 There is no silver bullit. But currently greylisting seems to stop around 95% of spam, and a lot of e-mail based virusus too. See the link abo= ve. > It may work for a while, but eventually they'll catch on and it will > only cause unnecessary delays for legitimate mail. Since the "cure" for greylisting involves at least cutting the spam rate in half, I doubt many spammers will adopt it. As for delaying legitimate mail, SMTP is considered an unreliable transport. That is why RFC 821 allows for temporary failures. If you want to contact someone about something that is time-critical, you shouldn't use e-mail anyway. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFu2n2EnfvsMMhpyURAiXEAJ0ZMNCCFCwZ04mZ6LB2dnxxYxP2IQCcDNBN 8J6yOkIALBdUj9L+pbNtPdM= =tXJN -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:04:43 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45DB916A401 for ; Sat, 27 Jan 2007 15:04:43 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id BBB8813C48C for ; Sat, 27 Jan 2007 15:04:42 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RF4fDw065055; Sat, 27 Jan 2007 13:04:41 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Jim Pingle Date: Sat, 27 Jan 2007 13:04:28 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <20070127141052.GA96039@slackbox.xs4all.nl> <45BB6296.1080106@pingle.org> In-Reply-To: <45BB6296.1080106@pingle.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271304.29216.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: rsmith@xs4all.nl, freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:04:43 -0000 On Saturday 27 January 2007 12:32, Jim Pingle wrote: > Roland Smith wrote: > > Most spammers do not bother to return if they get a resend request. > > That's the whole point of doing this. So practically it doesn't increase > > bandwidth consumption. > =2E.. > Greylisting is a decent idea, but it seems to me that it's just another > tool in the ongoing arms race against spammers. It may work for a while, > but eventually they'll catch on and it will only cause unnecessary delays > for legitimate mail. > finally some cares about the users here, that is a really important point, = how=20 do you justify that your client get the email he is waiting for an hour=20 later? Probably he looks then for a better service provider ... =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:06:27 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6568C16A40D for ; Sat, 27 Jan 2007 15:06:27 +0000 (UTC) (envelope-from lists@pingle.org) Received: from willow.pingle.org (willow.pingle.org [208.149.144.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2991F13C4DE for ; Sat, 27 Jan 2007 15:06:27 +0000 (UTC) (envelope-from lists@pingle.org) Received: from localhost (unknown [127.0.0.1]) by willow.pingle.org (Postfix) with ESMTP id 6C2E811477; Sat, 27 Jan 2007 09:33:14 -0500 (EST) X-Virus-Scanned: amavisd-new at pingle.org Received: from willow.pingle.org ([127.0.0.1]) by localhost (willow.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9EzTEN8qagB; Sat, 27 Jan 2007 09:33:12 -0500 (EST) Received: from [192.168.0.4] (josie.pingle.org [209.125.59.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by willow.pingle.org (Postfix) with ESMTP id E6D691144D; Sat, 27 Jan 2007 09:33:11 -0500 (EST) Message-ID: <45BB6296.1080106@pingle.org> Date: Sat, 27 Jan 2007 09:32:54 -0500 From: Jim Pingle User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JoaoBR , freebsd-stable@freebsd.org, rsmith@xs4all.nl References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701260924.59674.joao@matik.com.br> <20070127041608.GG927@turion.vk2pj.dyndns.org> <200701271058.47517.joao@matik.com.br> <20070127141052.GA96039@slackbox.xs4all.nl> In-Reply-To: <20070127141052.GA96039@slackbox.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:06:27 -0000 Roland Smith wrote: > Most spammers do not bother to return if they get a resend request. > That's the whole point of doing this. So practically it doesn't increase > bandwidth consumption. This conversation is getting rather OT for -stable, but I felt the need to ask a question: To defeat this, wouldn't a spammer just have to send out the same spam twice in a row from the same machines, spaced apart by a little time? Bonus for the spammer: accounts on servers without greylisting would get two copies of the spam. Greylisting is a decent idea, but it seems to me that it's just another tool in the ongoing arms race against spammers. It may work for a while, but eventually they'll catch on and it will only cause unnecessary delays for legitimate mail. Jim From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:14:06 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7040816A400 for ; Sat, 27 Jan 2007 15:14:06 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id E4C3513C46B for ; Sat, 27 Jan 2007 15:14:05 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0RFE3sJ033019; Sat, 27 Jan 2007 16:14:03 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id E3768B827; Sat, 27 Jan 2007 16:14:02 +0100 (CET) Date: Sat, 27 Jan 2007 16:14:02 +0100 From: Roland Smith To: JoaoBR Message-ID: <20070127151402.GB96846@slackbox.xs4all.nl> Mail-Followup-To: JoaoBR , freebsd-stable@freebsd.org References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271058.47517.joao@matik.com.br> <20070127141052.GA96039@slackbox.xs4all.nl> <200701271257.09365.joao@matik.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <200701271257.09365.joao@matik.com.br> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:14:06 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2007 at 12:57:08PM -0200, JoaoBR wrote: > On Saturday 27 January 2007 12:10, you wrote: > > On Sat, Jan 27, 2007 at 10:58:46AM -0200, JoaoBR wrote: > > > also a point to think about, most complains about spam talk about > > > bandwidth consumption, by asking for resend later you certainly incre= ase > > > bandwidth consumption and resources on both sides > > > > Most spammers do not bother to return if they get a resend request. > > That's the whole point of doing this. So practically it doesn't increase > > bandwidth consumption. >=20 > you must see both sides, following your theory, spammers stay away but go= od=20 > guys *are* coming back, greylisting is at the end the same only a little = bit=20 > less stupid than this anti-spam-send-and-ask-a-confirmation-mail things Greylisting makes use to the features of the SMTP protocol that spammers usually don't bother to implement, because it would make their programs more complicated and would decrease their delivery rate considerably. > also that spammers don't come back is an illusion,=20 According to http://projects.puremagic.com/greylisting/whitepaper.html it's not an illusion. > firstable they do it for=20 > money and secondable if they don't come back from the same source they co= me=20 > back from another and either one might be spoofed so you can greylisting= =20 > yourself to death because sooner or later all sources are blacklisted or= =20 > you're rewriting continuously your whitelists and both are probably=20 > unreliable at the end Read the abovementioned whitepaper. And remember that there is no silver bullit against spam. Greylisting, SPF, spamfilters etc. all have their place and use. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFu2w6EnfvsMMhpyURAoBhAKCRwfYmZjdpBHbA33w2mHRK95b8iACfTm9P No6ss/e0axXj0BhB4ioCej8= =i6eU -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:23:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A9EC16A400 for ; Sat, 27 Jan 2007 15:23:15 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 14BCD13C49D for ; Sat, 27 Jan 2007 15:23:14 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 3287E2D48AA; Sat, 27 Jan 2007 15:22:42 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 5B5321141D; Sat, 27 Jan 2007 16:23:13 +0100 (CET) Date: Sat, 27 Jan 2007 16:23:13 +0100 From: "Simon L. Nielsen" To: JoaoBR Message-ID: <20070127152312.GB1085@zaphod.nitro.dk> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <20070127141052.GA96039@slackbox.xs4all.nl> <45BB6296.1080106@pingle.org> <200701271304.29216.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701271304.29216.joao@matik.com.br> User-Agent: Mutt/1.5.11 Cc: rsmith@xs4all.nl, freebsd-stable@freebsd.org Subject: Re: Loosing spam fight -> devnull@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: devnull@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:23:15 -0000 On 2007.01.27 13:04:28 -0200, JoaoBR wrote: > On Saturday 27 January 2007 12:32, Jim Pingle wrote: > > Roland Smith wrote: > > > Most spammers do not bother to return if they get a resend request. > > > That's the whole point of doing this. So practically it doesn't increase > > > bandwidth consumption. > > > ... > > Greylisting is a decent idea, but it seems to me that it's just another > > tool in the ongoing arms race against spammers. It may work for a while, > > but eventually they'll catch on and it will only cause unnecessary delays > > for legitimate mail. > > finally some cares about the users here, that is a really important point, how > do you justify that your client get the email he is waiting for an hour > later? Probably he looks then for a better service provider ... Could this discussion please be continued on the apropriate list which is designed for spam - devnull@FreeBSD.org? Thanks. -- Simon L. Nielsen From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:23:57 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D61AA16A400 for ; Sat, 27 Jan 2007 15:23:57 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 7395C13C4B2 for ; Sat, 27 Jan 2007 15:23:57 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so1415162nfc for ; Sat, 27 Jan 2007 07:23:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sucva0U4z/LjVVtAdxmFtMmwqxv9XpnyhYbKwXGYL68qj9hx3RplLsYIfDHFSRhauCHPr5arJfgqiEi566rQyjxEy39rN+tSum0AeSZIJsDK2lksyZXR9nhUZBhmmA+tiq18cLLSVUqXqD7m5RpXRGTzC7hrwgMaqmdfnQxllUE= Received: by 10.82.118.2 with SMTP id q2mr2551837buc.1169911435340; Sat, 27 Jan 2007 07:23:55 -0800 (PST) Received: by 10.82.186.2 with HTTP; Sat, 27 Jan 2007 07:23:55 -0800 (PST) Message-ID: <790a9fff0701270723r10fa7fcen326214d393b174d8@mail.gmail.com> Date: Sat, 27 Jan 2007 09:23:55 -0600 From: "Scot Hetzel" To: "Vinny Abello" In-Reply-To: <45BAEFE0.3080408@tellurian.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45BAEFE0.3080408@tellurian.com> Cc: freebsd-stable@freebsd.org Subject: Re: How to start rc script after sshd starts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:23:57 -0000 On 1/27/07, Vinny Abello wrote: > Hello, > > I think this is a relatively easy question to answer but couldn't find anything after some searching. > : > I have a daemon that apparently does a check using ssh-keyscan against the > loopback address when it starts up. The problem I have is that sshd is not started > when the script runs to start this daemon, so it fails and I end up having to start it > manually. What is the recommended way to get this script to start after sshd has > started up? I was hoping to not have to hack any rc scripts up from their defaults for > starting up the system if possible. It's a standard rc script in /usr/local/etc/rc.d. If it > matters, the daemon is smokeping. I can stop it from using ssh-keyscan completely > as I really don't use the probe at all in smokeping but I'm curious as to the proper > way of making this work. > > Any pointers are appreciated. > You need to add: # REQUIRE: sshd to the rc script in /usr/local/etc/rc.d that you want to start after sshd. Another option is to create a dummy script: #!/bin/sh # # PROVIDE: FAKESCRIPT # REQUIRE: sshd # BEFORE: # This is a dummy dependency, to ensure that general purpose daemons # are run _after_ the above are. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:26:07 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A07D16A402 for ; Sat, 27 Jan 2007 15:26:07 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9B88E13C483 for ; Sat, 27 Jan 2007 15:26:06 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RFQ5Vq066617; Sat, 27 Jan 2007 13:26:05 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Roland Smith Date: Sat, 27 Jan 2007 13:25:52 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <45BB6296.1080106@pingle.org> <20070127150422.GA96846@slackbox.xs4all.nl> In-Reply-To: <20070127150422.GA96846@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271325.53070.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:26:07 -0000 On Saturday 27 January 2007 13:04, Roland Smith wrote: > > That's not a bonus. Think about it. Sending a message twice will cut the > spammer's mail delivery rate at least in half. > nobody cares about this, what counts is the hit rate, more you get delivere= d=20 merrier the return, that means more you reject more is send in order to get= =20 the desired profit > > Greylisting is a decent idea, but it seems to me that it's just another > > tool in the ongoing arms race against spammers. > > There is no silver bullit. But currently greylisting seems to stop > around 95% of spam, and a lot of e-mail based virusus too. See the link > above. this number is absolute not true, depending on how popular your mail server= is=20 or your domain names are you get a constant rate hammered into you network= =20 and it does not matter if you use greylists or whatever *rejecting* method the only real effective method is delaying the connection, counting on that= =20 the sending server is timing out without getting response. A correct smtp=20 server will wait enough but spammer servers/programms are not waiting a=20 minute for delivering each message > > It may work for a while, but eventually they'll catch on and it will > > only cause unnecessary delays for legitimate mail. > > Since the "cure" for greylisting involves at least cutting the spam rate > in half, I doubt many spammers will adopt it. > there is no cure=20 spammer will stop adopting when people stop getting horny or greedy so I gu= ess=20 your approach is failing sadly :) > As for delaying legitimate mail, SMTP is considered an unreliable > transport. That is why RFC 821 allows for temporary failures. If you > want to contact someone about something that is time-critical, you > shouldn't use e-mail anyway. people, as normal internet users, which are the main spammer target, do use= =20 email as it is and they do not care about *why* the message is not coming i= n=20 but they care about that it is *not* coming in within a acceptable time spa= n=20 of some minutes or so - which by the way is the correct thinking =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:28:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34E4416A401 for ; Sat, 27 Jan 2007 15:28:26 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id C280513C494 for ; Sat, 27 Jan 2007 15:28:25 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0RFSN31048617; Sat, 27 Jan 2007 16:28:23 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l0RFSMDp071337; Sat, 27 Jan 2007 16:28:22 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l0RFSM7v071336; Sat, 27 Jan 2007 16:28:22 +0100 (CET) (envelope-from wb) Date: Sat, 27 Jan 2007 16:28:22 +0100 From: Wilko Bulte To: devnull@freebsd.org Message-ID: <20070127152822.GA71323@freebie.xs4all.nl> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <20070127141052.GA96039@slackbox.xs4all.nl> <45BB6296.1080106@pingle.org> <200701271304.29216.joao@matik.com.br> <20070127152312.GB1085@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070127152312.GB1085@zaphod.nitro.dk> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: rsmith@xs4all.nl, freebsd-stable@freebsd.org, JoaoBR Subject: Re: Loosing spam fight -> devnull@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:28:26 -0000 On Sat, Jan 27, 2007 at 04:23:13PM +0100, Simon L. Nielsen wrote.. > On 2007.01.27 13:04:28 -0200, JoaoBR wrote: > > On Saturday 27 January 2007 12:32, Jim Pingle wrote: > > > Roland Smith wrote: > > > > Most spammers do not bother to return if they get a resend request. > > > > That's the whole point of doing this. So practically it doesn't increase > > > > bandwidth consumption. > > > > > ... > > > Greylisting is a decent idea, but it seems to me that it's just another > > > tool in the ongoing arms race against spammers. It may work for a while, > > > but eventually they'll catch on and it will only cause unnecessary delays > > > for legitimate mail. > > > > finally some cares about the users here, that is a really important point, how > > do you justify that your client get the email he is waiting for an hour > > later? Probably he looks then for a better service provider ... > > Could this discussion please be continued on the apropriate list which > is designed for spam - devnull@FreeBSD.org? Or -chat, or wherever, but not on -stable please. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:34:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D97B216A401 for ; Sat, 27 Jan 2007 15:34:21 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 64BE813C48D for ; Sat, 27 Jan 2007 15:34:21 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RFYKqM067073 for ; Sat, 27 Jan 2007 13:34:20 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Sat, 27 Jan 2007 13:34:07 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271304.29216.joao@matik.com.br> <20070127152312.GB1085@zaphod.nitro.dk> In-Reply-To: <20070127152312.GB1085@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271334.08050.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Loosing spam fight -> devnull@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:34:21 -0000 On Saturday 27 January 2007 13:23, Simon L. Nielsen wrote: > > Could this discussion please be continued on the apropriate list which > is designed for spam - devnull@FreeBSD.org? > lists.freebsd.org Mailing Lists No such list devnull could you please provide correct information in order to follow your=20 instructions? =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:40:02 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3842116A406 for ; Sat, 27 Jan 2007 15:40:02 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id B4FF913C48D for ; Sat, 27 Jan 2007 15:40:01 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0RFdrRQ089118; Sat, 27 Jan 2007 16:39:53 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 3F271B827; Sat, 27 Jan 2007 16:39:53 +0100 (CET) Date: Sat, 27 Jan 2007 16:39:53 +0100 From: Roland Smith To: JoaoBR Message-ID: <20070127153953.GC96846@slackbox.xs4all.nl> Mail-Followup-To: JoaoBR , Jim Pingle , freebsd-stable@freebsd.org References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <20070127141052.GA96039@slackbox.xs4all.nl> <45BB6296.1080106@pingle.org> <200701271304.29216.joao@matik.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <200701271304.29216.joao@matik.com.br> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:40:02 -0000 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2007 at 01:04:28PM -0200, JoaoBR wrote: > > Greylisting is a decent idea, but it seems to me that it's just another > > tool in the ongoing arms race against spammers. It may work for a while, > > but eventually they'll catch on and it will only cause unnecessary dela= ys > > for legitimate mail. > > >=20 > finally some cares about the users here, that is a really important > point, how do you justify that your client get the email he is waiting > for an hour later? Probably he looks then for a better service > provider ... The standard requires a retry time of at least 30 minutes: http://tools.ietf.org/html/rfc2821#section-4.5.3=20 But most open-source MTA's will try to resend after around 15 minutes: http://en.wikipedia.org/wiki/Greylisting=20 Note that the SMTP protocol does not guarantee delivery within a certain timeframe.=20 There are timeouts of several minutes for each of the SMTP commands. This means that a full SMTP conversation can last at least 1/2 hour, from one server to another. In short, an extra hour transit time is not a fault or bad service as far as SMTP is concerned. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFu3JJEnfvsMMhpyURAuj/AJ0R+CB0r+AXXndT/b1WwDwia/MWxACgr30s q9JgCt6ogvbmBvbAb7j3ltQ= =FE05 -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:50:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5CD216A400 for ; Sat, 27 Jan 2007 15:50:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4B83913C4A3 for ; Sat, 27 Jan 2007 15:50:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RFoclO068328; Sat, 27 Jan 2007 13:50:39 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Roland Smith Date: Sat, 27 Jan 2007 13:50:26 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271304.29216.joao@matik.com.br> <20070127153953.GC96846@slackbox.xs4all.nl> In-Reply-To: <20070127153953.GC96846@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271350.26787.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:50:40 -0000 On Saturday 27 January 2007 13:39, Roland Smith wrote: > On Sat, Jan 27, 2007 at 01:04:28PM -0200, JoaoBR wrote: > > > Greylisting is a decent idea, but it seems to me that it's just anoth= er > > > tool in the ongoing arms race against spammers. It may work for a > > > while, but eventually they'll catch on and it will only cause > > > unnecessary delays for legitimate mail. > > > > finally some cares about the users here, that is a really important > > point, how do you justify that your client get the email he is waiting > > for an hour later? Probably he looks then for a better service > > provider ... > > The standard requires a retry time of at least 30 minutes: > http://tools.ietf.org/html/rfc2821#section-4.5.3 > > But most open-source MTA's will try to resend after around 15 minutes: > http://en.wikipedia.org/wiki/Greylisting > > Note that the SMTP protocol does not guarantee delivery within a certain > timeframe. > I guess most servers do retry after 1-4 hours > There are timeouts of several minutes for each of the SMTP > commands. This means that a full SMTP conversation can last at least 1/2 > hour, from one server to another. yes, therefore it does not make sense retrying after 10 or even 31 minutes > > In short, an extra hour transit time is not a fault or bad service as > far as SMTP is concerned. that is certainly a technical and political excuse which nobody want to he= ar=20 for getting email late, because the common understanding is getting an emai= l=20 on earth within some minutes =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:56:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A064416A500 for ; Sat, 27 Jan 2007 15:56:21 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (ramstind.fig.ol.no [128.39.174.2]) by mx1.freebsd.org (Postfix) with ESMTP id 75CC613C481 for ; Sat, 27 Jan 2007 15:56:17 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (Ximalas@localhost [127.0.0.1]) by ramstind.fig.ol.no (8.13.6/8.13.6) with ESMTP id l0RFd5jn094821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jan 2007 16:39:06 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by ramstind.fig.ol.no (8.13.6/8.13.6/Submit) with ESMTP id l0RFd5rp094818 for ; Sat, 27 Jan 2007 16:39:05 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: ramstind.fig.ol.no: trond owned process doing -bs Date: Sat, 27 Jan 2007 16:39:05 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable In-Reply-To: <200701271334.08050.joao@matik.com.br> Message-ID: <20070127163834.X14770@ramstind.fig.ol.no> References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271304.29216.joao@matik.com.br> <20070127152312.GB1085@zaphod.nitro.dk> <200701271334.08050.joao@matik.com.br> Organization: =?ISO-8859-1?Q?Fagskolen_i_Gj=F8vik?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=failed X-Spam-Checker-Version: SpamAssassin on ramstind.fig.ol.no Subject: Re: Loosing spam fight -> devnull@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:56:21 -0000 On Sat, 27 Jan 2007 13:34-0200, JoaoBR wrote: > could you please provide correct information in order to follow your > instructions? plz From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 17:20:03 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAB3A16A404 for ; Sat, 27 Jan 2007 17:20:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF8E13C48A for ; Sat, 27 Jan 2007 17:20:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0JCJ0003EETAIX00@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 27 Jan 2007 18:19:58 +0100 (CET) Received: from kg-work.kg4.no ([80.203.66.169]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0JCJ00J9LETA6XN0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 27 Jan 2007 18:19:58 +0100 (CET) Date: Sat, 27 Jan 2007 18:19:58 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <200701271350.26787.joao@matik.com.br> To: freebsd-stable@freebsd.org Message-id: <20070127181958.e631dc34.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.8; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271304.29216.joao@matik.com.br> <20070127153953.GC96846@slackbox.xs4all.nl> <200701271350.26787.joao@matik.com.br> Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 17:20:04 -0000 On Sat, 27 Jan 2007 13:50:26 -0200 JoaoBR wrote: > that is certainly a technical and political excuse which nobody want > to hear for getting email late, because the common understanding is > getting an email on earth within some minutes everybody: ENOUGH ALREADY! Take this discussion off the -stable list! -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 18:23:29 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8432716A401 for ; Sat, 27 Jan 2007 18:23:29 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAD013C484 for ; Sat, 27 Jan 2007 18:23:29 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HAsD1-000B38-Fh for freebsd-stable@FreeBSD.ORG; Sat, 27 Jan 2007 18:23:27 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HAsD1-0004VZ-3B for freebsd-stable@FreeBSD.ORG; Sat, 27 Jan 2007 18:23:27 +0000 To: freebsd-stable@FreeBSD.ORG Message-Id: From: Pete French Date: Sat, 27 Jan 2007 18:23:27 +0000 Cc: Subject: impossible rc.d ordering problem with stf and pf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 18:23:29 -0000 Am trying to solve a little problem with 'pf'. I have a ruleset which has some firewall rules for the IPv6 interface stf0. This works fine, except when I rreboot the machine, as the pf script is run before the network_ipv6 script - so stf0 does not exist. but I cannot work out how to arrange for stf0 to be created before the pf script is run - as network_ipv6 requires 'routing', but the pf script says it must be run before 'routing', if I am reading the 'REQUIRE' and 'BEFORE' lines correctly. Any solutions ? -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 21:52:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFC4516A402 for ; Sat, 27 Jan 2007 21:52:21 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 422F513C481 for ; Sat, 27 Jan 2007 21:52:20 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RLqGuK094894; Sat, 27 Jan 2007 19:52:17 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org, Torfinn Ingolfsen Date: Sat, 27 Jan 2007 19:52:47 -0300 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271350.26787.joao@matik.com.br> <20070127181958.e631dc34.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20070127181958.e631dc34.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271952.47337.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 21:52:21 -0000 On Saturday 27 January 2007 14:19, Torfinn Ingolfsen wrote: > everybody: ENOUGH ALREADY! > Take this discussion off the -stable list! are you my boss or something?=20 go swimming in your fjord, eat some lemmings and cool down man =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 22:47:55 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1473416A401; Sat, 27 Jan 2007 22:47:55 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5D91613C48D; Sat, 27 Jan 2007 22:47:53 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (wireless58.dhcp.tao.org.uk [87.74.4.58]) by mailhost.tao.org.uk (Postfix) with ESMTP id 9DCFD5E98; Sat, 27 Jan 2007 22:47:51 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id 6EF7140A8; Sat, 27 Jan 2007 22:47:49 +0000 (GMT) Date: Sat, 27 Jan 2007 22:47:49 +0000 From: Josef Karthauser To: Joe Koberg Message-ID: <20070127224749.GA8203@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Joe Koberg , stable@freebsd.org, fs@freebsd.org References: <20070115112106.GA2304@genius.tao.org.uk> <20070115115650.GB2304@genius.tao.org.uk> <45AB9BE4.1030606@osoft.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <45AB9BE4.1030606@osoft.us> User-Agent: Mutt/1.5.11 Cc: stable@freebsd.org, fs@freebsd.org Subject: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 22:47:55 -0000 --i0/AhcQY5QxfSsSZ Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2007 at 09:21:08AM -0600, Joe Koberg wrote: >=20 > I just bought two Dell PE-1950's to use as routers. They have LSI Logic= =20 > PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the=20 > same card used for SAS. >=20 > One thing is for sure, the mfi(4) card and driver aren't shy! See below= =20 > for examples of the kernel messages I get regularly. I am sure drive=20 > failure would be well noted. >=20 > As to rebuilding on-line, I suspect a drive (hot-)swap will initiate the= =20 > rebuild. There is a CLI tool (megarc) in ports/sysutils/megarc but I=20 > haven't tried to use it yet. >=20 > All in all I would recommend the PERC/5i. >=20 So I've just picked up a Dell PE-860, with the SAS card. However it doesn't appear to be an mfi(4) card, instead it's an mpt(4) card. And, it doesn't appear to work properly; at least something isn't quite right. I've installed 6.2 on the box, and I'm attempting to create a gmirror with both of the disks attached to the mpt. I've created the filesystem on one of the disks ok (gmirror boot0 on da1s1), and then I attempt to insert the second disk (da0s1). The problem is that the synchronisation appears to progress ok, but when I add some additional load, like cvsuping the ports collection at the same time, after a short period I get loads of errors from the mpt controller and then geom disconnects the drive (da0s1). Wierdly when I reboot the machine the mpt controller refuses to probe da0, and I have to physically power cycle the machine before it sees the drive again. The error messages from mpt are attached in the file called 'messages'. The kernel probe boot time log is attached as dmesg.log. I hope there's a simple fix; I was hoping to commission this machine at the end of this coming week!!!! Joe --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=messages Jan 27 18:42:03 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x01 Depth 121 Jan 27 18:44:01 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x00 Depth 121 Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756328:48785 timed out for ccb 0xca8f0c00 (req->ccb 0xca8f0c00) Jan 27 18:51:06 littoralis kernel: mpt0: attempting to abort req 0xca756328:48785 function 0 Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755c28:48786 timed out for ccb 0xcc213800 (req->ccb 0xcc213800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758078:48787 timed out for ccb 0xca743000 (req->ccb 0xca743000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758468:48793 timed out for ccb 0xca8ee800 (req->ccb 0xca8ee800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755ec8:48795 timed out for ccb 0xcc214800 (req->ccb 0xcc214800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7527e0:48797 timed out for ccb 0xca8f2000 (req->ccb 0xca8f2000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7552f8:48801 timed out for ccb 0xca75a000 (req->ccb 0xca75a000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758af8:48803 timed out for ccb 0xca773c00 (req->ccb 0xca773c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752620:48805 timed out for ccb 0xca8e1400 (req->ccb 0xca8e1400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755218:48807 timed out for ccb 0xca8e1000 (req->ccb 0xca8e1000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752850:48809 timed out for ccb 0xca8e3800 (req->ccb 0xca8e3800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752f88:48811 timed out for ccb 0xca914400 (req->ccb 0xca914400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757c50:48813 timed out for ccb 0xca749000 (req->ccb 0xca749000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753b58:48815 timed out for ccb 0xca8e7c00 (req->ccb 0xca8e7c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757780:48817 timed out for ccb 0xca672c00 (req->ccb 0xca672c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754b50:48819 timed out for ccb 0xcc211800 (req->ccb 0xcc211800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7554b8:48821 timed out for ccb 0xca744400 (req->ccb 0xca744400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753688:48823 timed out for ccb 0xca749800 (req->ccb 0xca749800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753880:48825 timed out for ccb 0xca771400 (req->ccb 0xca771400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756fd8:48827 timed out for ccb 0xcc208400 (req->ccb 0xcc208400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754a00:48829 timed out for ccb 0xca774800 (req->ccb 0xca774800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7527a8:48831 timed out for ccb 0xca907c00 (req->ccb 0xca907c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756ad0:48833 timed out for ccb 0xcc219c00 (req->ccb 0xcc219c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754f40:48835 timed out for ccb 0xca915000 (req->ccb 0xca915000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758d28:48837 timed out for ccb 0xca90fc00 (req->ccb 0xca90fc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757b38:48839 timed out for ccb 0xcc216800 (req->ccb 0xcc216800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7553d8:48841 timed out for ccb 0xca910800 (req->ccb 0xca910800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757a58:48843 timed out for ccb 0xca774c00 (req->ccb 0xca774c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752f50:48845 timed out for ccb 0xcc20f000 (req->ccb 0xcc20f000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758cb8:48847 timed out for ccb 0xca910000 (req->ccb 0xca910000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7568d8:48849 timed out for ccb 0xcc21d000 (req->ccb 0xcc21d000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757e48:48851 timed out for ccb 0xca8da800 (req->ccb 0xca8da800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7563d0:48853 timed out for ccb 0xcc214400 (req->ccb 0xcc214400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757c18:48855 timed out for ccb 0xca8e4c00 (req->ccb 0xca8e4c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754958:48857 timed out for ccb 0xca917400 (req->ccb 0xca917400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755480:48859 timed out for ccb 0xca74a800 (req->ccb 0xca74a800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757ac8:48861 timed out for ccb 0xcc216c00 (req->ccb 0xcc216c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7569f0:48863 timed out for ccb 0xca904400 (req->ccb 0xca904400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757978:48865 timed out for ccb 0xca75a800 (req->ccb 0xca75a800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754b18:48867 timed out for ccb 0xcc20c400 (req->ccb 0xcc20c400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758740:48869 timed out for ccb 0xcc222800 (req->ccb 0xcc222800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7538f0:48871 timed out for ccb 0xca8dc000 (req->ccb 0xca8dc000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752ff8:48873 timed out for ccb 0xca762000 (req->ccb 0xca762000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7562b8:48875 timed out for ccb 0xca761c00 (req->ccb 0xca761c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758970:48877 timed out for ccb 0xca8f7800 (req->ccb 0xca8f7800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758820:48879 timed out for ccb 0xca908800 (req->ccb 0xca908800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757be0:48881 timed out for ccb 0xca905400 (req->ccb 0xca905400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753500:48883 timed out for ccb 0xcc21c400 (req->ccb 0xcc21c400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752d90:48885 timed out for ccb 0xcc212400 (req->ccb 0xcc212400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757a20:48887 timed out for ccb 0xca8ef000 (req->ccb 0xca8ef000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756670:48889 timed out for ccb 0xca75b800 (req->ccb 0xca75b800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7551a8:48891 timed out for ccb 0xcc218800 (req->ccb 0xcc218800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758318:48893 timed out for ccb 0xca905000 (req->ccb 0xca905000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757908:48895 timed out for ccb 0xca74a400 (req->ccb 0xca74a400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752930:48897 timed out for ccb 0xca917c00 (req->ccb 0xca917c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757b70:48899 timed out for ccb 0xcc211c00 (req->ccb 0xcc211c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7528c0:48901 timed out for ccb 0xca743c00 (req->ccb 0xca743c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755988:48903 timed out for ccb 0xcc211400 (req->ccb 0xcc211400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758e08:48905 timed out for ccb 0xcc20ac00 (req->ccb 0xcc20ac00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757470:48907 timed out for ccb 0xca8ef400 (req->ccb 0xca8ef400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752e70:48909 timed out for ccb 0xcc21c000 (req->ccb 0xcc21c000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756520:48911 timed out for ccb 0xcc218000 (req->ccb 0xcc218000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757940:48913 timed out for ccb 0xcc20ec00 (req->ccb 0xcc20ec00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755058:48915 timed out for ccb 0xca794c00 (req->ccb 0xca794c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758eb0:48917 timed out for ccb 0xca776c00 (req->ccb 0xca776c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7542c8:48919 timed out for ccb 0xca8ebc00 (req->ccb 0xca8ebc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7570b8:48921 timed out for ccb 0xcc215800 (req->ccb 0xcc215800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7587e8:48923 timed out for ccb 0xca8dd800 (req->ccb 0xca8dd800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7556b0:48925 timed out for ccb 0xca775400 (req->ccb 0xca775400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7533e8:48927 timed out for ccb 0xca773000 (req->ccb 0xca773000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7553a0:48929 timed out for ccb 0xca740800 (req->ccb 0xca740800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752fc0:48931 timed out for ccb 0xcc212000 (req->ccb 0xcc212000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755d78:48933 timed out for ccb 0xca76f800 (req->ccb 0xca76f800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753148:48935 timed out for ccb 0xca744000 (req->ccb 0xca744000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755b10:48937 timed out for ccb 0xca793800 (req->ccb 0xca793800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7572e8:48939 timed out for ccb 0xca673400 (req->ccb 0xca673400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754300:48941 timed out for ccb 0xca776000 (req->ccb 0xca776000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756a60:48943 timed out for ccb 0xca770000 (req->ccb 0xca770000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752348:48945 timed out for ccb 0xca8edc00 (req->ccb 0xca8edc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753810:48947 timed out for ccb 0xca73f000 (req->ccb 0xca73f000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754c30:48949 timed out for ccb 0xca909400 (req->ccb 0xca909400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7544f8:48951 timed out for ccb 0xca762400 (req->ccb 0xca762400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754098:48953 timed out for ccb 0xca915800 (req->ccb 0xca915800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7584d8:48955 timed out for ccb 0xcc209c00 (req->ccb 0xcc209c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754028:48957 timed out for ccb 0xca761400 (req->ccb 0xca761400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7538b8:48959 timed out for ccb 0xca76f400 (req->ccb 0xca76f400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752230:48961 timed out for ccb 0xca8f2c00 (req->ccb 0xca8f2c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7581c8:48963 timed out for ccb 0xcc20d400 (req->ccb 0xcc20d400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7523b8:48965 timed out for ccb 0xcc209000 (req->ccb 0xcc209000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755100:48967 timed out for ccb 0xca73f400 (req->ccb 0xca73f400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7543a8:48969 timed out for ccb 0xcc215000 (req->ccb 0xcc215000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754cd8:48971 timed out for ccb 0xca75b000 (req->ccb 0xca75b000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753d88:48973 timed out for ccb 0xcc21c800 (req->ccb 0xcc21c800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755fa8:48975 timed out for ccb 0xca8db800 (req->ccb 0xca8db800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755f70:48977 timed out for ccb 0xca75b400 (req->ccb 0xca75b400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753378:48979 timed out for ccb 0xca903800 (req->ccb 0xca903800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7535e0:48981 timed out for ccb 0xca8f8400 (req->ccb 0xca8f8400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758270:48983 timed out for ccb 0xcc215c00 (req->ccb 0xcc215c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752658:48985 timed out for ccb 0xca8f1800 (req->ccb 0xca8f1800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7523f0:48987 timed out for ccb 0xca916000 (req->ccb 0xca916000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7567c0:48989 timed out for ccb 0xca773800 (req->ccb 0xca773800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757e10:48991 timed out for ccb 0xca771000 (req->ccb 0xca771000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756be8:48993 timed out for ccb 0xca8ed400 (req->ccb 0xca8ed400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755790:48995 timed out for ccb 0xcc20f800 (req->ccb 0xcc20f800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7522a0:48997 timed out for ccb 0xca908c00 (req->ccb 0xca908c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752770:48999 timed out for ccb 0xca8e5400 (req->ccb 0xca8e5400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757390:49001 timed out for ccb 0xca75ac00 (req->ccb 0xca75ac00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7582e0:49003 timed out for ccb 0xca8f6000 (req->ccb 0xca8f6000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756638:49005 timed out for ccb 0xca8e8400 (req->ccb 0xca8e8400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755448:49007 timed out for ccb 0xca8f0800 (req->ccb 0xca8f0800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752a48:49009 timed out for ccb 0xca8dcc00 (req->ccb 0xca8dcc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755e58:49011 timed out for ccb 0xca8dc400 (req->ccb 0xca8dc400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7564e8:49013 timed out for ccb 0xca784c00 (req->ccb 0xca784c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758a50:49015 timed out for ccb 0xca914000 (req->ccb 0xca914000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756830:49017 timed out for ccb 0xcc213c00 (req->ccb 0xcc213c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758890:49019 timed out for ccb 0xca785400 (req->ccb 0xca785400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7535a8:49021 timed out for ccb 0xcc213400 (req->ccb 0xcc213400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757208:49025 timed out for ccb 0xca759400 (req->ccb 0xca759400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756f30:49027 timed out for ccb 0xca916c00 (req->ccb 0xca916c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753fb8:49029 timed out for ccb 0xcc222c00 (req->ccb 0xcc222c00) Jan 27 18:51:21 littoralis kernel: mpt0: mpt_wait_req(1) timed out Jan 27 18:51:21 littoralis kernel: mpt0: mpt_recover_commands: abort timed-out. Resetting controller Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x74 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0xead5cc74 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756328:48785 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755c28:48786 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758078:48787 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758468:48793 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755ec8:48795 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7527e0:48797 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7552f8:48801 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758af8:48803 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752620:48805 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755218:48807 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752850:48809 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752f88:48811 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757c50:48813 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753b58:48815 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757780:48817 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754b50:48819 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7554b8:48821 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753688:48823 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753880:48825 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756fd8:48827 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754a00:48829 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7527a8:48831 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756ad0:48833 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754f40:48835 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758d28:48837 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757b38:48839 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7553d8:48841 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757a58:48843 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752f50:48845 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758cb8:48847 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7568d8:48849 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757e48:48851 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7563d0:48853 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757c18:48855 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754958:48857 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755480:48859 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757ac8:48861 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7569f0:48863 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757978:48865 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754b18:48867 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758740:48869 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7538f0:48871 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752ff8:48873 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7562b8:48875 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758970:48877 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758820:48879 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757be0:48881 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753500:48883 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752d90:48885 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757a20:48887 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756670:48889 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7551a8:48891 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758318:48893 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757908:48895 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752930:48897 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757b70:48899 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7528c0:48901 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755988:48903 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758e08:48905 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757470:48907 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752e70:48909 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756520:48911 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757940:48913 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755058:48915 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758eb0:48917 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7542c8:48919 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7570b8:48921 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7587e8:48923 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7556b0:48925 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7533e8:48927 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7553a0:48929 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752fc0:48931 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755d78:48933 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753148:48935 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755b10:48937 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7572e8:48939 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754300:48941 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756a60:48943 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752348:48945 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753810:48947 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754c30:48949 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7544f8:48951 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754098:48953 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7584d8:48955 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754028:48957 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7538b8:48959 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752230:48961 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7581c8:48963 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7523b8:48965 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755100:48967 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7543a8:48969 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754cd8:48971 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753d88:48973 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755fa8:48975 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755f70:48977 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753378:48979 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7535e0:48981 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758270:48983 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752658:48985 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7523f0:48987 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7567c0:48989 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757e10:48991 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756be8:48993 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755790:48995 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7522a0:48997 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752770:48999 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757390:49001 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7582e0:49003 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756638:49005 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755448:49007 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752a48:49009 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755e58:49011 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7564e8:49013 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758a50:49015 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756830:49017 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758890:49019 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7535a8:49021 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757208:49025 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756f30:49027 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753fb8:49029 Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): lost device Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): Invalidating pack Jan 27 18:51:21 littoralis last message repeated 119 times Jan 27 18:51:21 littoralis kernel: GEOM_MIRROR: Device boot0: provider da0s1 disconnected. Jan 27 18:51:21 littoralis kernel: GEOM_MIRROR: Device boot0: rebuilding provider da0s1 stopped. Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): removing device entry --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Description: dmesg.log Content-Disposition: attachment; filename=q Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #10: Sat Jan 27 20:19:48 GMT 2007 joe@littoralis.tao.org.uk:/usr/obj/usr/src/sys/LITTORALIS-SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2400.10-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6f7 Stepping =3D 7 Features=3D0xbfebfbff Features2=3D0xe3bd,CX16,,> AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 4 real memory =3D 5368709120 (5120 MB) avail memory =3D 4185096192 (3991 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic1: WARNING: intbase 32 !=3D expected base 24 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 mpt0: port 0xec00-0xecff mem 0xdfdfc000-0xdfdff= fff,0xdfde0000-0xdfdeffff irq 16 at device 8.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=3D1.5.12.0 mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). pci1: at device 0.1 (no driver atta= ched) pcib3: at device 28.0 on pci0 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 2.0 on pci4 pci5: on pcib5 pci5: at device 2.0 (no driver attached) pci5: at device 4.0 (no driver attached) pci5: at device 4.1 (no driver attached) pci5: at device 4.2 (no driver attached) atapci0: port 0xd8f0-0xd8f7,0xd8e4-0xd8e7,0xd= 8d8-0xd8df,0xd8d0-0xd8d3,0xd870-0xd87f mem 0xdf9eec00-0xdf9eecff irq 32 at = device 7.0 on pci5 ata2: on atapci0 ata3: on atapci0 pcib6: at device 28.4 on pci0 pci6: on pcib6 bge0: mem 0xdf5f0000-0xdf5fffff irq= 16 at device 0.0 on pci6 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge0: Ethernet address: 00:15:c5:fc:22:17 pcib7: at device 28.5 on pci0 pci7: on pcib7 bge1: mem 0xdf3f0000-0xdf3fffff irq= 17 at device 0.0 on pci7 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge1: Ethernet address: 00:15:c5:fc:22:18 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib8: at device 30.0 on pci0 pci8: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled,= default to accept, logging disabled acd0: CDRW at ata0-master UDMA33 device_attach: afd0 attach returned 6 acd1: CDROM at ata2-slave PIO3 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device=20 da0: 300.000MB/s transfers, Tagged Queueing Enabled da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device=20 da1: 300.000MB/s transfers, Tagged Queueing Enabled da1: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! GEOM_MIRROR: Device boot0 created (id=3D1393958858). GEOM_MIRROR: Device boot0: provider da0s1 detected. GEOM_MIRROR: Device boot0: provider da1s1 detected. GEOM_MIRROR: Device boot0: provider da1s1 activated. GEOM_MIRROR: Device boot0: provider mirror/boot0 launched. GEOM_MIRROR: Device boot0: rebuilding provider da0s1. Trying to mount root from ufs:/dev/mirror/boot0a --NzB8fVQJ5HfG6fxh-- --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkW71pQACgkQXVIcjOaxUBYfrwCdHI1lfDAa/G1L/h4KSQW2bIi5 BP0An1dDcr7fAQAcmbMseRxzPcvwmbgV =IidI -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 23:46:28 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2A0916A4C1 for ; Sat, 27 Jan 2007 23:46:28 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 85B8813C4B7 for ; Sat, 27 Jan 2007 23:46:28 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1191681wxc for ; Sat, 27 Jan 2007 15:46:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jbZd4xjBgX0Y1P0If+fRvBnBl5361dHO7voWA1eDvU6lphuubBm8ASS+HPFda/xT0TXSECFNR77EiMHK0LmUUDGVNxa/i0MMbeP/qwe6PWdG3gM8LAfAElefmuum4CUcFR5lp/sdrqWZab0nS+8fgpeQy3l+aCyn5uBl1RmOUwE= Received: by 10.70.35.1 with SMTP id i1mr9327137wxi.1169940057085; Sat, 27 Jan 2007 15:20:57 -0800 (PST) Received: by 10.70.40.11 with HTTP; Sat, 27 Jan 2007 15:20:56 -0800 (PST) Message-ID: Date: Sun, 28 Jan 2007 00:20:56 +0100 From: "Juraj Lutter" To: "Josef Karthauser" , "Joe Koberg" , stable@freebsd.org, fs@freebsd.org In-Reply-To: <20070127224749.GA8203@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070115112106.GA2304@genius.tao.org.uk> <20070115115650.GB2304@genius.tao.org.uk> <45AB9BE4.1030606@osoft.us> <20070127224749.GA8203@genius.tao.org.uk> Cc: Subject: Re: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:46:28 -0000 On 1/27/07, Josef Karthauser wrote: > The problem is that the synchronisation appears to progress ok, but > when I add some additional load, like cvsuping the ports collection > at the same time, after a short period I get loads of errors from > the mpt controller and then geom disconnects the drive (da0s1). > Wierdly when I reboot the machine the mpt controller refuses to > probe da0, and I have to physically power cycle the machine before > it sees the drive again. I've been observing very similar behavriour with recent 6.2-STABLE on i386 with either Silicon Image 3114 or Promise FastTrak TX4. gmirror synchronisation worked OK until I've added some additional load on the synchronised volume. Unfortunately I haven't been able to take any reasonable DDB output :-( -- Sincerely yours, Juraj Lutter From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 23:46:32 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1151116A4D2 for ; Sat, 27 Jan 2007 23:46:32 +0000 (UTC) (envelope-from freebsd@mail.gbch.net) Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by mx1.freebsd.org (Postfix) with SMTP id 47C0513C491 for ; Sat, 27 Jan 2007 23:46:30 +0000 (UTC) (envelope-from freebsd@mail.gbch.net) Received: (qmail 94258 invoked from network); 28 Jan 2007 09:46:28 +1000 Received: from joker.gbch.net (172.16.1.10) by gw.gbch.net with SMTP; 28 Jan 2007 09:46:28 +1000 Received: (qmail 71353 invoked by uid 1001); 28 Jan 2007 09:46:27 +1000 Message-ID: Date: Sun, 28 Jan 2007 09:46:27 +1000 From: freebsd@mail.gbch.net To: JoaoBR References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271350.26787.joao@matik.com.br> <20070127181958.e631dc34.torfinn.ingolfsen@broadpark.no> <200701271952.47337.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701271952.47337.joao@matik.com.br> User-Agent: Mutt/1.4.2.2i; gjb-muttsend.sh 1.7 2004-10-05 X-Uptime: 3 days X-Operating-System: FreeBSD 6.2-PRERELEASE i386 Cc: freebsd-stable@freebsd.org Subject: Enough already [was: Re: Loosing spam fight] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:46:32 -0000 On 2007-01-27, JoaoBR wrote: > On Saturday 27 January 2007 14:19, Torfinn Ingolfsen wrote: > > everybody: ENOUGH ALREADY! > > Take this discussion off the -stable list! > > are you my boss or something? > go swimming in your fjord, eat some lemmings and cool down man No, he's not your boss. You, on the other hand, are a moron and a complete menace to the usefulness of this mailing list. Take your whining about whatever it is to some place that wants to hear it and leave the FreeBSD-stable list to those of us who want to address matters that pertain to the list's purpose. The mere fact that you want to waste our time with off-topic crap does not give you any right to do that. People have asked you politely and you have been too stupid to take any notice, so now it's time for us to treat you with the same rudeness that you have shown us. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 23:49:16 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0939816A4A0 for ; Sat, 27 Jan 2007 23:49:16 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC3313C4DA for ; Sat, 27 Jan 2007 23:49:13 +0000 (UTC) (envelope-from clay@milos.co.za) Received: (qmail 82865 invoked by uid 89); 27 Jan 2007 23:21:41 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.254) by bart.milos.co.za with ESMTPA; 27 Jan 2007 23:21:41 -0000 Message-ID: <058601c7426a$04728890$fe03a8c0@claylaptop> From: "Clayton Milos" To: "Josef Karthauser" References: <20070115112106.GA2304@genius.tao.org.uk><20070115115650.GB2304@genius.tao.org.uk><45AB9BE4.1030606@osoft.us> <20070127224749.GA8203@genius.tao.org.uk> Date: Sun, 28 Jan 2007 01:22:30 +0200 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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: stable@freebsd.org, fs@freebsd.org Subject: Re: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:49:16 -0000 On Mon, Jan 15, 2007 at 09:21:08AM -0600, Joe Koberg wrote: > > I just bought two Dell PE-1950's to use as routers. They have LSI Logic > PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the > same card used for SAS. > > One thing is for sure, the mfi(4) card and driver aren't shy! See below > for examples of the kernel messages I get regularly. I am sure drive > failure would be well noted. > > As to rebuilding on-line, I suspect a drive (hot-)swap will initiate the > rebuild. There is a CLI tool (megarc) in ports/sysutils/megarc but I > haven't tried to use it yet. > > All in all I would recommend the PERC/5i. > So I've just picked up a Dell PE-860, with the SAS card. However it doesn't appear to be an mfi(4) card, instead it's an mpt(4) card. And, it doesn't appear to work properly; at least something isn't quite right. I've installed 6.2 on the box, and I'm attempting to create a gmirror with both of the disks attached to the mpt. I've created the filesystem on one of the disks ok (gmirror boot0 on da1s1), and then I attempt to insert the second disk (da0s1). The problem is that the synchronisation appears to progress ok, but when I add some additional load, like cvsuping the ports collection at the same time, after a short period I get loads of errors from the mpt controller and then geom disconnects the drive (da0s1). Wierdly when I reboot the machine the mpt controller refuses to probe da0, and I have to physically power cycle the machine before it sees the drive again. The error messages from mpt are attached in the file called 'messages'. The kernel probe boot time log is attached as dmesg.log. I hope there's a simple fix; I was hoping to commission this machine at the end of this coming week!!!! Joe Hey Joe If you have to power cycle the box for it to work again I'd say the problem is more than likely hardware related and not something FreeBSD unless the driver for the card has the ability to disable the drive on the raid controller which I doubt. -Clay From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 23:54:34 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E38A616A401 for ; Sat, 27 Jan 2007 23:54:33 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0D113C4A8 for ; Sat, 27 Jan 2007 23:54:33 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id l0RNsEYZ050554; Sat, 27 Jan 2007 18:54:14 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id l0RNs8uv050553; Sat, 27 Jan 2007 18:54:08 -0500 (EST) (envelope-from bv) Date: Sat, 27 Jan 2007 18:54:08 -0500 From: Bill Vermillion To: Dan Nelson Message-ID: <20070127235408.GA50433@wjv.com> References: <20070126161022.GB29530@wjv.com> <20070126171552.GA24490@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070126171552.GA24490@dan.emsphone.com> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-stable@freebsd.org Subject: Re: 6.2 buildworld fails with NO_SHARED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:54:34 -0000 Even though on Fri, Jan 26, 2007 at 11:15 Dan Nelson realized that everything he says should be taken 'cum grano salis', he unhesitatingly continued with this missive: Took me awhile to get some time to try this again - wjv > In the last episode (Jan 26), Bill Vermillion said: > > I had wanted to build static binaries in /bin and /sbin - so > > I set NO_SHARED. The man pages says "... this can be bad. If set > > every utility that uses bsd.prog.mk will be linked statically." > > Here is the tail end of the output of make buildworld as I mailed > > it to me from the machine I was bringing up as we start to replace > > all the 4.11 servers. > > > ===> usr.sbin/gstat (all) > > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -c /usr/src/usr.sbin/gstat/gstat.c > > > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -static -o gstat gstat.o -lgeom -ldevstat -lbsdxml -lcurses -ledit > > > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1c): In function `StartElement': > > > : undefined reference to `sbuf_new' > > > /usr/obj/usr/src/tmp/usr/lib/libdevstat.a(devstat.o)(.text+0x1538): In function `readkmem': > > > : undefined reference to `kvm_read' > > > /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o)(.text+0x3938): In function `term_deletechars': > > > : undefined reference to `tgoto' > Looks like there are some missing/misordered library dependencies. > Moving -lcurses after -ledit, and adding -lkvm and -lsbuf fixes it. > The main thing you lose by statically linking is dlopen(), so nsswitch > and pam modules from ports won't work. Modules built into libc.a or > libpam.a (NIS and pam_unix for example) will work. Also, if you're on > -current you can tell cached to do NSS lookups on behalf of static > binaries. > > Index: Makefile > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/gstat/Makefile,v > retrieving revision 1.6.2.1 > diff -u -r1.6.2.1 Makefile > --- Makefile 10 Jun 2006 15:40:10 -0000 1.6.2.1 > +++ Makefile 26 Jan 2007 17:00:38 -0000 > @@ -3,7 +3,7 @@ > PROG= gstat > MAN= gstat.8 > WARNS?= 5 > -DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBCURSES} ${LIBEDIT} > -LDADD= -lgeom -ldevstat -lbsdxml -lcurses -ledit > +DPADD= ${LIBGEOM} ${LIBDEVSTAT} ${LIBBSDXML} ${LIBEDIT} ${LIBCURSES} > +LDADD= -lgeom -ldevstat -lbsdxml -ledit -lcurses -lkvm -lsbuf > > .include > -- > Dan Nelson > dnelson@allantgroup.com That fixed the errors as above. However now I get errors further down. But first - should this not be fixed in the Makefile. make.conf(5) says in part using the NO_SHARED ".. can be bad. ..." I would think the above info about breaking the ports of nsswitch and the PAM modules wouldn't work might be listed as >some< of the possibilities instead of 'can be bad'. The other respondant to this post mentioned that the statically built pieces of /bin and /sbin are in rescue. I see those are all in one large file that is linked to all the possible names. No real problem there, but that brings up another question. If - as documented in make.conf(5) - I put use the variable NO_DYNAMIC_ROOT it says "set this is you do not want to link /bin and /sbin dynamically". Would that be the way to build statics in /bin and /sbin instead of NO_SHARED. And now onto the current thing I see. I removed all of /usr/obj/src to be sure I started clean. I had the variable NO_SHARED in /etc/make.conf. The compile passed the place where it failed before as your fix to the make file seem to cure that. Now this is what I see when NO_SHARED is used. This is just the tail end of the nohup output. ------------- cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/info/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -static -o pkg_info main.o perform.o show.o /usr/obj/usr/src/usr.sbin/pkg_install/info/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /usr/src/usr.sbin/pkg_install/info/pkg_info.1 > pkg_info.1.gz ===> usr.sbin/pkg_install/sign (all) cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/main.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/check.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/common.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/gzip.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/pgp_check.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/pgp_sign.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/sha1.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/sign.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/stand.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -c /usr/src/usr.sbin/pkg_install/sign/x509.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.sbin/pkg_install/sign/../lib -static -o pkg_sign main.o check.o common.o gzip.o pgp_check.o pgp_sign.o sha1.o sign.o stand.o x509.o /usr/obj/usr/src/usr.sbin/pkg_install/sign/../lib/libinstall.a -lmd -lcrypto /usr/obj/usr/src/tmp/usr/lib/libc.a(err.o)(.text+0x33c): In function `warnx': : multiple definition of `warnx' stand.o(.text+0xb0): first defined here /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `warnx' changed from 81 in stand.o to 20 in /usr/obj/usr/src/tmp/usr/lib/libc.a(err.o) *** Error code 1 Stop in /usr/src/usr.sbin/pkg_install/sign. *** Error code 1 Stop in /usr/src/usr.sbin/pkg_install. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 3189.30 real 2863.34 user 288.46 sys ------------- Bill -- Bill Vermillion - bv @ wjv . com