From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 00:15:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBD6E16A4CE for ; Sun, 26 Dec 2004 00:15:53 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29A7343D49 for ; Sun, 26 Dec 2004 00:15:52 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 5956A85641; Sun, 26 Dec 2004 10:45:50 +1030 (CST) Date: Sun, 26 Dec 2004 10:45:50 +1030 From: Greg 'groggy' Lehey To: Kris Kennaway Message-ID: <20041226001550.GA19771@wantadilla.lemis.com> References: <20041225234236.GA65841@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20041225234236.GA65841@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: current@FreeBSD.org Subject: Re: deadc0de panic in unmount() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:15:54 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 25 December 2004 at 15:42:36 -0800, Kris Kennaway wrote: > -current from a few days ago. It was probably unmounting a nullfs, > devfs or linprocfs. > > panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac > _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin > lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132 > dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5 > unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4 > syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (22, FreeBSD ELF32, unmount), eip = 0x82a21df, esp = 0xbfbfe0ac, ebp = 0xbfbfe168 --- Do you have a dump? Greg -- See complete headers for address and phone numbers. --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzgK2IubykFB6QiMRAjpWAJ0Z0WxK31jpGRAstBkGjQmE4r4NDwCgrV2k lJHXHK9qrT92xD5dhrIexl8= =kyxK -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 00:22:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA74116A4CE; Sun, 26 Dec 2004 00:22:55 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC2043D3F; Sun, 26 Dec 2004 00:22:55 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8838F51255; Sat, 25 Dec 2004 16:22:34 -0800 (PST) Date: Sat, 25 Dec 2004 16:22:34 -0800 From: Kris Kennaway To: Greg 'groggy' Lehey Message-ID: <20041226002234.GA81810@xor.obsecurity.org> References: <20041225234236.GA65841@xor.obsecurity.org> <20041226001550.GA19771@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20041226001550.GA19771@wantadilla.lemis.com> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: deadc0de panic in unmount() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:22:55 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 26, 2004 at 10:45:50AM +1030, Greg 'groggy' Lehey wrote: > On Saturday, 25 December 2004 at 15:42:36 -0800, Kris Kennaway wrote: > > -current from a few days ago. It was probably unmounting a nullfs, > > devfs or linprocfs. > > > > panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac > > _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin > > lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132 > > dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5 > > unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4 > > syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (22, FreeBSD ELF32, unmount), eip =3D 0x82a21df, esp =3D 0x= bfbfe0ac, ebp =3D 0xbfbfe168 --- >=20 > Do you have a dump? No, dumping is broken for me on this and some other machines (it starts with 'Dumping 2047 MB' but immediately returns). Kris --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzgRKWry0BWjoQKURAv8pAKCPLEGb+Osp9QzshDEfZCLA2vvZ6ACgljF5 KzfVoVZIa40pY3NtsY8Xo4k= =B0G1 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 00:27:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A75E16A4CE for ; Sun, 26 Dec 2004 00:27:24 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED7343D3F for ; Sun, 26 Dec 2004 00:27:23 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 135A68561F; Sun, 26 Dec 2004 10:57:21 +1030 (CST) Date: Sun, 26 Dec 2004 10:57:21 +1030 From: Greg 'groggy' Lehey To: Kris Kennaway Message-ID: <20041226002721.GB19771@wantadilla.lemis.com> References: <20041225234236.GA65841@xor.obsecurity.org> <20041226001550.GA19771@wantadilla.lemis.com> <20041226002234.GA81810@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: <20041226002234.GA81810@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: current@FreeBSD.org Subject: Re: deadc0de panic in unmount() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:27:24 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 25 December 2004 at 16:22:34 -0800, Kris Kennaway wrote: > On Sun, Dec 26, 2004 at 10:45:50AM +1030, Greg 'groggy' Lehey wrote: >> On Saturday, 25 December 2004 at 15:42:36 -0800, Kris Kennaway wrote: >>> -current from a few days ago. It was probably unmounting a nullfs, >>> devfs or linprocfs. >>> >>> panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac >>> _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin >>> lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132 >>> dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5 >>> unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4 >>> syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b >>> Xint0x80_syscall() at Xint0x80_syscall+0x1f >>> --- syscall (22, FreeBSD ELF32, unmount), eip = 0x82a21df, esp = 0xbfbfe0ac, ebp = 0xbfbfe168 --- >> >> Do you have a dump? > > No, dumping is broken for me on this and some other machines (it > starts with 'Dumping 2047 MB' but immediately returns). Does this happen if you do 'call doadump' as well? Greg -- See complete headers for address and phone numbers. --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzgVpIubykFB6QiMRApxAAKCIeGAC3pAyCYICzjo1JTeznktCfgCggIZ3 BkSXYFBP01lUlXV1XxCkWdc= =Yt79 -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 00:31:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D19F416A4CE for ; Sun, 26 Dec 2004 00:31:22 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 333F243D45 for ; Sun, 26 Dec 2004 00:31:22 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id iBQ0VLOx015371 for ; Sat, 25 Dec 2004 19:31:21 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)iBQ0VKr1015349 for ; Sat, 25 Dec 2004 19:31:20 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Sat, 25 Dec 2004 19:31:19 -0500 (EST) From: Jeff Roberson To: current@freebsd.org Message-ID: <20041225191637.K60504@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: schedgraph.py X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:31:23 -0000 I took a break from working on VFS to implement a tool that will help me further refine the ULE scheduler. This may also be interesting in understanding application behavior under load, analyzing lock contention and preemption in the kernel, etc. To use the tool, you will need to define KTR_SCHED in KTR_COMPILE and KTR_MASK. I'd also bump entires up to 32768 or larger so you can grab a few seconds of data. Run your workload, and then capture the data with 'ktrdump -ct > ktr.out'. Then you simply run python schedgraph.py ktr.out. This requires a recent version of python and ports/x11-toolkits/py-tkinter. Here's a screenshot from a recent run: http://www.chesapeake.net/~jroberson/schedgraph.jpg I also have some sample data at http://www.chesapeake.net/~jroberson/smp.out.gz if you want to play with the tool without capturing data. The configuration page acts as a legend so you can understand the colors. The least obvious feature of the display is that the background color changes according to the cpu that the thread is executing on. In the screenshot I posted, light grey is cpu 0 and dark grey is cpu 1. You can also click on any event for greater detail. For events that exist on two threads, you may click on the corrisponding thread's name in the event popup to change to that event. Feedback welcome, patches for new features are even more welcome. Cheers, Jeff ---------- Forwarded message ---------- Date: Sun, 26 Dec 2004 00:13:07 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/tools/sched schedgraph.py jeff 2004-12-26 00:13:07 UTC FreeBSD src repository Added files: tools/sched schedgraph.py Log: - Add 'schedgraph' a scheduler trace visualization tool written with python and tkinter. Schedgraph takes input from files produces by ktrdump -ct when KTR_SCHED is compiled into the kernel. The output represents the states of each thread with colored line segments as well as colored points for non-state scheduler events. Each line segment and point is clickable to obtain extra detail. Revision Changes Path 1.1 +1209 -0 src/tools/sched/schedgraph.py (new) From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 00:31:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04EE616A4FB; Sun, 26 Dec 2004 00:31:27 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B8743D2D; Sun, 26 Dec 2004 00:31:26 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 60EA051255; Sat, 25 Dec 2004 16:31:05 -0800 (PST) Date: Sat, 25 Dec 2004 16:31:05 -0800 From: Kris Kennaway To: Greg 'groggy' Lehey Message-ID: <20041226003105.GB81940@xor.obsecurity.org> References: <20041225234236.GA65841@xor.obsecurity.org> <20041226001550.GA19771@wantadilla.lemis.com> <20041226002234.GA81810@xor.obsecurity.org> <20041226002721.GB19771@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20041226002721.GB19771@wantadilla.lemis.com> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: deadc0de panic in unmount() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:31:27 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 26, 2004 at 10:57:21AM +1030, Greg 'groggy' Lehey wrote: > On Saturday, 25 December 2004 at 16:22:34 -0800, Kris Kennaway wrote: > > On Sun, Dec 26, 2004 at 10:45:50AM +1030, Greg 'groggy' Lehey wrote: > >> On Saturday, 25 December 2004 at 15:42:36 -0800, Kris Kennaway wrote: > >>> -current from a few days ago. It was probably unmounting a nullfs, > >>> devfs or linprocfs. > >>> > >>> panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac > >>> _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin > >>> lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132 > >>> dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5 > >>> unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4 > >>> syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b > >>> Xint0x80_syscall() at Xint0x80_syscall+0x1f > >>> --- syscall (22, FreeBSD ELF32, unmount), eip =3D 0x82a21df, esp =3D = 0xbfbfe0ac, ebp =3D 0xbfbfe168 --- > >> > >> Do you have a dump? > > > > No, dumping is broken for me on this and some other machines (it > > starts with 'Dumping 2047 MB' but immediately returns). >=20 > Does this happen if you do 'call doadump' as well? Yeah, that's how I always try and dump since I learned that relying on the kernel to try and dump itself was .. not reliable. Kris --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzgZJWry0BWjoQKURAokoAJkBmXe5PF456/M31RtTCpDsFpA35wCgx10f 78rLEWTuK86Q8Mh2F92jlzk= =NjwG -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 02:09:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1016716A4CE; Sun, 26 Dec 2004 02:09:38 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C3C43D1F; Sun, 26 Dec 2004 02:09:37 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 577724EFCDD; Sun, 26 Dec 2004 10:09:33 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 4CA5B4EFCDC; Sun, 26 Dec 2004 10:09:33 +0800 (CST) Date: Sun, 26 Dec 2004 10:09:33 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: Message-ID: <0412260955570.90805@www.mmlab.cse.yzu.edu.tw> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Chuck Robey cc: FreeBSD-current@FreeBSD.org Subject: Re: Reboot instead of debugger/dump from X11? (Re: an accidental way to pull the plug) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 02:09:38 -0000 On Sat, 25 Dec 2004, Robert Watson wrote: > On Sat, 25 Dec 2004, Chuck Robey wrote: > >> I got a little too fast just now, and did something that I shouldn't >> have done, but what's interesting is, FreeBSD decided to pull the plug >> and instantly reboot, which is usually something to be regarded as >> pathological, so I am letting you folks know. I haven't analyzed >> exactly what happened to cause it, actually. > > With the recent 802.11 panic I posted about a bit earlier, I saw something > rather odd: when the panic took place on the normal text console, the > system dropped to the debugger. However, when it took place with X11 > running, I got an "instant reboot" -- no dump, etc. So something odd is > happening during even normal failure modes when X11 is running for me. I > wonder if anyone else is seeing this? Just a "me too" for observing exactly the same symptom on a Thinkpad R40. At the first time I thought the reboot-without-panic-to-ddb was associated with improper kernel debug settings; however, after lots of fscking and rebooting, I finally realised that all I have to do is to disable xdm on startup and switch back to the text console. And yes, the panic was from if_wi. According to sys/ddb/db_main.c:195, it appears that the panic would never get into ddb if the console is unavailable. I'm curious about whether the doadump() would also be suppressed or not at that moment? > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > >> >> Anyhow, I have been using FreeBSD as a fine platform for a Free database I >> am constructing for a buddy of mine who has a video rental store. The >> database, which was active at the time (the app is nearly complete) is >> made with Python, gtk, pygtk (obviously) and the Sleepycat database. I >> called those folks up and got the opinion that, as long as I didn't try to >> distribute the software, the way I'm handling it (for free) it generally >> falls under their free license, so I'm ok on that. >> >> Anyhow, I was talking screen dump pictures of the 6 data entry screens, in >> X11, using xv to grab the windows. I got a bit confused with mouse >> clicks, and actually asked it to do a grab while another grab was in delay >> wait (it has a timer delay, which I set to 5 seconds). Result: reboot, >> instant. >> >> I think that's it, although I will try to answer any questions. If you >> folks are all too tied up with your own projects, it won't bother me, I'm >> only trying to be conscientious about things. >> >> ---------------------------------------------------------------------------- >> Chuck Robey | Interests include C & Java programming, FreeBSD, >> chuckr@chuckr.org | electronics, communications, and SF/Fantasy. >> >> New Year's Resolution: I will not sphroxify gullible people into looking up >> fictitious words in the dictionary (on the wall at my old fraternity, >> Signa Phi Nothing). From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 02:49:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 242D016A4CE; Sun, 26 Dec 2004 02:49:48 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78F8943D46; Sun, 26 Dec 2004 02:49:47 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id A78FB4EFCDE; Sun, 26 Dec 2004 10:49:46 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 9E8DF4EFCDD; Sun, 26 Dec 2004 10:49:46 +0800 (CST) Date: Sun, 26 Dec 2004 10:49:46 +0800 (CST) From: Tai-hwa Liang To: Robert Watson In-Reply-To: Message-ID: <041226100944A.93815@www.mmlab.cse.yzu.edu.tw> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@FreeBSD.org Subject: Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 02:49:48 -0000 On Sat, 25 Dec 2004, Robert Watson wrote: > > I recently upgraded a kernel on my notebook to Dec 23. I don't have the > date of the previous kernel on-hand, but I suspect it was late November > from before I was on travel. I have a local configuration I sometimes use > with adhoc 802.11 on a prism card using WEP, using a FreeBSD notebook as a > proxy to reach a wired network. The other system is a Mac OS X notebook. > As of the upgrade, I get a kernel page fault on the FreeBSD system > whenever I attempt to use the Mac OS X box with wireless. In fact, > booting the Mac OS X box causes the FreeBSD box to panic, presumably as > the Mac OS X box says "Hi, I'm here!". The panic is a NULL pointer > derefernece in ieee80211_find_rxnode(). I don't have the complete trap > message due to not having a serial console for the box, but below is some > core information. This is highly reproduceable; please let me know if > more information is needed. In this case, ieee80211_find_rxnode() needs to lock the node table before further operations; however, IEEE80211_NODE_LOCK() panics due to the node lock mutex was never initialised. From my observation, the proper path to initialise the mutex is through ieee80211_create_ibss() -> ieee80211_node_table_alloc(): the "neighbor" case in this example; however, I suspect that the panic would also take place in if_wi HOSTAP mode.... The latest net80211 has some assumptions and basic requirements whilst the station is going to join the IBSS. Since most of the 802.11 state transitions(such like state involes probing/authentication/association frames) in if_wi were firmware based, most of them would be bypassed in wi_newstate and thus some vital initialisation functions such like ieee80211_create_ibss() within ieee80211_end_scan() never get called. Sam said that unless someone steps out and deals with that, this issue will have to wait until he has free time: http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044462.html BTW, I'm still trying to figure out a workaround/bandaid to get over this but still have no luck. One of the problem is that I'm not sure how to tell that the hardware is associated with the IBSS. The other problem is that the right path to ieee80211_create_ibss() is not very clear to me: through ieee80211_newstate(S_INIT -> S_SCAN) or just create_ibss() directly? > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > #21 0x00000002 in ?? () > #22 0xc05a6b2b in ieee80211_find_rxnode (ic=0xc1bcf25c, wh=0xc1bb8730) > at atomic.h:365 > #23 0xc04ca7c7 in wi_intr (arg=0xc1bcf000) at > /usr/src/sys/dev/wi/if_wi.c:1533 > #24 0xc0506d8d in ithread_loop (arg=0xc197b780) > at /usr/src/sys/kern/kern_intr.c:547 > #25 0xc0505e8c in fork_exit (callout=0xc0506ce0 , > arg=0xc197b780, frame=0xd418fd48) at /usr/src/sys/kern/kern_fork.c:790 > #26 0xc069619c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:209 > (kgdb) frame 22 > #22 0xc05a6b2b in ieee80211_find_rxnode (ic=0xc1bcf25c, wh=0xc1bb8730) > at atomic.h:365 > 365 { > (kgdb) list > 360 #define atomic_readandclear_32 atomic_readandclear_int > 361 > 362 #if !defined(WANT_FUNCTIONS) > 363 static __inline int > 364 atomic_cmpset_ptr(volatile void *dst, void *exp, void *src) > 365 { > 366 > 367 return (atomic_cmpset_int((volatile u_int *)dst, (u_int)exp, > 368 (u_int)src)); > 369 } > (kgdb) inspect nt > $1 = (struct ieee80211_node_table *) 0x0 > [...] From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 04:02:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3420516A4CF; Sun, 26 Dec 2004 04:02:04 +0000 (GMT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A292D43D58; Sun, 26 Dec 2004 04:02:03 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041226040203.SYHZ10436.out012.verizon.net@RabbitsDen>; Sat, 25 Dec 2004 22:02:03 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Robert Watson In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-5 Date: Sat, 25 Dec 2004 23:01:55 -0500 Message-Id: <1104033715.1729.5.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [70.21.161.195] at Sat, 25 Dec 2004 22:02:02 -0600 cc: current@FreeBSD.org Subject: Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 04:02:04 -0000 On Sat, 2004-12-25 at 20:29 +0000, Robert Watson wrote: > I recently upgraded a kernel on my notebook to Dec 23. I don't have the > date of the previous kernel on-hand, but I suspect it was late November > from before I was on travel. I have a local configuration I sometimes use > with adhoc 802.11 on a prism card using WEP, using a FreeBSD notebook as a > proxy to reach a wired network. The other system is a Mac OS X notebook. > As of the upgrade, I get a kernel page fault on the FreeBSD system > whenever I attempt to use the Mac OS X box with wireless. In fact, > booting the Mac OS X box causes the FreeBSD box to panic, presumably as > the Mac OS X box says "Hi, I'm here!". The panic is a NULL pointer > derefernece in ieee80211_find_rxnode(). I don't have the complete trap > message due to not having a serial console for the box, but below is some > core information. This is highly reproduceable; please let me know if > more information is needed. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research If you are after quick-and-dirty workaround, you can use NDIS wrapper with your card -- I just checked this setup on my (non-prism) NDIS-wrapped card and my FreeBSD laptop was just happy talking to my iBook over adhoc network. I know that it is not a solution, but if you need connectivity now it just might get you over the hump. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 04:43:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B852D16A4CE for ; Sun, 26 Dec 2004 04:43:54 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B8E643D1D for ; Sun, 26 Dec 2004 04:43:54 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBQ4hrXI001271 for ; Sat, 25 Dec 2004 20:43:54 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Sat, 25 Dec 2004 21:44:22 -0700 User-Agent: KMail/1.7.2 References: <200412221315.47189.lists@jnielsen.net> <200412232134.38577.lists@jnielsen.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200412252144.23047.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 04:43:54 -0000 On Friday 24 December 2004 05:23 pm, Dag-Erling Sm=F8rgrav wrote: > John Nielsen writes: > > The SATA controller has a device ID of 0x00e510de. > > ...so it's not a real SATA controller at all, but a PATA controller > with a converter chip in front. That's good to know. What's the practical difference and how can you tell= =20 just given the device ID? JN From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 06:30:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D512D16A4CE for ; Sun, 26 Dec 2004 06:30:13 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591BD43D1D for ; Sun, 26 Dec 2004 06:30:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])iBQ6U2Gr257776; Sun, 26 Dec 2004 01:30:07 -0500 Message-ID: <41CE5A6A.4090101@elischer.org> Date: Sat, 25 Dec 2004 22:30:02 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Jeff Roberson References: <20041225191637.K60504@mail.chesapeake.net> In-Reply-To: <20041225191637.K60504@mail.chesapeake.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: schedgraph.py X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 06:30:13 -0000 Jeff Roberson wrote: > I took a break from working on VFS to implement a tool that will help me > further refine the ULE scheduler. This may also be interesting in > understanding application behavior under load, analyzing lock contention > and preemption in the kernel, etc. > [...] robert watson has been doing some work in a similar (but not as detailed) vein. he has some code that produces some quite nice graphs of threads and cpus using KTR. From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 07:41:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8599516A4CE; Sun, 26 Dec 2004 07:41:32 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD3D43D49; Sun, 26 Dec 2004 07:41:31 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:896d:2657:a83f:e731]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 247AE15210; Sun, 26 Dec 2004 16:41:30 +0900 (JST) Date: Sun, 26 Dec 2004 16:41:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Scott Long In-Reply-To: <41C8BD1C.9090507@freebsd.org> References: <41C8BD1C.9090507@freebsd.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 07:41:32 -0000 >>>>> On Tue, 21 Dec 2004 17:17:32 -0700, >>>>> Scott Long said: >> C. (for comparison) SuSE Linux (kernel 2.6.4, glibc 2.3.3) on the >> same box I used with experiment B >> >> threads BIND BIND++ >> 0 16117 >> 1 13707 17835 >> 2 16493 26946 >> 3 16478 32688 >> 4 14517 36090 >> >> While "pure BIND9" does not provide better performance with multiple >> CPUs either (and the optimizations in BIND++ are equally effective), >> the penalty with multiple threads is much smaller. I guess this is >> because Linux handles lock contentions much better than FreeBSD. >> > Do you have any comparisons to NetBSD or Solaris? Comparing to Linux > often results in comparing apples to oranges since there is > long-standing suspicion that Linux cuts corners where BSD does not. I've never done this type of test for NetBSD, since as far as I know NetBSD is not very SMP-aware (does this change in, e.g., NetBSD 2.0?). I've checked Solaris with similar tests, but I could only use a 2-processor sparc box. So, the results would not be very informative. FWIW, however, Solaris performed quite well with 2 processors. > Also, would you be able to re-run your tests using the THR thread > package? If I have another chance and test environments (I've lost the access to the test environments). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 11:06:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FD3516A4CE for ; Sun, 26 Dec 2004 11:06:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A9EC43D41 for ; Sun, 26 Dec 2004 11:06:05 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBQB2mIo058514; Sun, 26 Dec 2004 06:02:48 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBQB2mTx058511; Sun, 26 Dec 2004 11:02:48 GMT (envelope-from robert@fledge.watson.org) Date: Sun, 26 Dec 2004 11:02:48 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <20041225191637.K60504@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: schedgraph.py X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 11:06:05 -0000 On Sat, 25 Dec 2004, Jeff Roberson wrote: > To use the tool, you will need to define KTR_SCHED in KTR_COMPILE and > KTR_MASK. I'd also bump entires up to 32768 or larger so you can grab a > few seconds of data. Run your workload, and then capture the data with > 'ktrdump -ct > ktr.out'. Then you simply run python schedgraph.py > ktr.out. This requires a recent version of python and > ports/x11-toolkits/py-tkinter. Great! For those who need a little more hand-holding getting KTR running, here's a URL to try: http://www.watson.org/~robert/freebsd/netperf/ktr/ It's been my hope people would start producing more post-processing tools -- KTR can collect some really great data that's just sitting there waiting to be mined. I'd be interested in seeing post-processing tools for locking as well. This looks like a great tool that will be really helpful in understanding behavior and performance. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 16:12:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 541D516A4CE for ; Sun, 26 Dec 2004 16:12:01 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 856EB43D45 for ; Sun, 26 Dec 2004 16:12:00 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 44716 invoked from network); 26 Dec 2004 16:11:58 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 Dec 2004 16:11:58 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBQGBvdE075405; Sun, 26 Dec 2004 17:11:57 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBQGBrXm075404; Sun, 26 Dec 2004 17:11:53 +0100 (CET) (envelope-from pho) Date: Sun, 26 Dec 2004 17:11:53 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041226161153.GA74592@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222221540.GA70052@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 16:12:01 -0000 On Wed, Dec 22, 2004 at 05:15:40PM -0500, Bosko Milekic wrote: > > On Wed, Dec 22, 2004 at 10:05:53PM +0100, Peter Holm wrote: > > On Mon, Dec 20, 2004 at 06:41:04PM -0500, Bosko Milekic wrote: > > > > > > I realize it's been a while. > > > > > > Anyway, what I *think* is going on here is that slab_zalloc() is > > > actually returning NULL even when called with M_WAITOK. Further > > > inspection in slab_zalloc() reveals that this could come from several > > > places. One of them is kmem_malloc() itself, which I doubt will ever > > > return NULL if called with M_WAITOK. If this assumption is indeed > > > correct, then the NULL must be being returned by slab_zalloc() itself, > > > or due to a failed uma_zalloc_internal() call. It is also possible > > > that slab_zalloc() returns NULL if the init that gets called for the > > > zone fails. However, judging from the stack trace you provided, the > > > init in question is mb_init_pack() (kern_mbuf.c). This particular > > > init DOES perform an allocation and CAN in theory fail, but I believe > > > it should be called with M_WAITOK as well, and so it should also never > > > fail in theory. > > > > > > Have you gotten any further with the analysis of this particular > > > trace? If not, I would suggest adding some more printf()s and > > > analysis into slab_zalloc() itself, to see if that is indeed what is > > > causing the infinite looping in uma_zone_slab() and, if so, attempt to > > > figure out what part of slab_zalloc() is returning the NULL. > > > > OK, did that: http://www.holm.cc/stress/log/freeze03.html > > OK, well, I think I know what's happening. See if you can confirm > this with me. > > I'll start with your trace and describe the analysis, please bear with > me because it's long and painful. > > Your trace indicates that the NULL allocation failure, despite a call > with M_WAITOK, is coming from slab_zalloc(). The particular thing > that should also be mentionned about this trace, and your previous > one, is that they both show a call path that goes through an init > which performs an allocation, also with M_WAITOK. Currently, only the > "packet zone" does this. It looks something like this: > > 1. UMA allocation is performed for a "packet." A "packet" is an mbuf > with a pre-attached cluster. > > 2. UMA dips into the packet zone and finds it empty. Additionally, it > determines that it is unable to get a bucket to fill up the zone > (presumably there is a lot of memory request load). So it calls > uma_zalloc_internal on the packet zone (frame 18). > > 3. Perhaps after some blocking, a slab is obtained from the packet > zone's backing keg (which coincidentally is the same keg as the > mbuf zone's backing keg -- let's call it the MBUF KEG). So now > that an mbuf item is taken from the freshly allocated slab obtained > from the MBUF KEG, uma_zalloc_internal() needs to init and ctor it, > since it is about to return it to the top (calling) layer. It > calls the initializer on it for the packet zone, mbuf_init_pack(). > This corresponds to frame 17. > > 4. The packet zone's initializer needs to call into UMA again to get > and attach an mbuf cluster to the mbuf being allocated, because mbufs > residing within the packet zone (or obtained from the packet zone) > MUST have clusters attached to them. It attempts to perform this > allocation with M_WAITOK, because that's what the initial caller > was calling with. This is frame 16. > > 5. Now the cluster zone is also completely empty and we can't get a > bucket (surprise, surprise, the system is under high memory-request > load). UMA calls uma_zalloc_internal() on the cluster zone as well. > This is frame 15. > > 6. uma_zalloc_internal() calls uma_zone_slab(). Its job is to find a > slab from the cluster zone's backing keg (a separate CLUSTER KEG) > and return it. Unfortunately, memory-request load is high, so it's > going to have a difficult time. The uma_zone_slab() call is frame > 14. > > 7. uma_zone_slab() can't find a locally cached slab (hardly > surprising, due to load) and calls slab_zalloc() to actually go to > VM and get one. Before calling, it increments a special "recurse" > flag so that we do not recurse on calling into the VM. This is > because the VM itself might call back into UMA when it attempts to > allocate vm_map_entries which could cause it to recurse on > allocating buckets. This recurse flag is PER zone, and really only > exists to protect the bucket zone. Crazy, crazy shit indeed. > Pardon the language. This is frame 13. > > 8. Now slab_zalloc(), called for the CLUSTER zone, determines that the > cluster zone (for space efficiency reasons) is in fact an OFFPAGE > zone, so it needs to grab a slab header structure from a separate > UMA "slab header" zone. It calls uma_zalloc_internal() from > slab_zalloc(), but it calls it on the SLAB HEADER zone. It passes > M_WAITOK down to it, but for some reason IT returns NULL and the > failure is propagated back up which causes the uma_zone_slab() to > keep looping. Go back to step 7. > > This is the infinite loop 7 -> 8 -> 7 -> 8 -> ... which you seem to > have caught. > > The question now is why does the uma_zalloc_internal() fail on the > SLAB HEADER zone, even though it is called with M_WAITOK. > Unfortunately, your stack trace does not provide enough depth to be > able to continue an accurate deductive analysis from this point on > (you would need to sprinkle MORE KASSERTs). > > However, here are some hypotheses. > > The uma_zalloc_internal() which ends up getting called also ends up > calling uma_zone_slab(), but uma_zone_slab() eventually fails (this is > a fact, this is the only reason that the uma_zalloc_internal() could > in turn fail for the SLAB HEADER zone, which doesn't have an init or a > ctor). > > So why does the uma_zone_slab() fail with M_WAITOK on the slab header > zone? Possibilities: > > 1. The recurse flag is at some point determined non-zero FOR THE SLAB > HEADER backing keg. If the VM ends up getting called from the > subsequent slab_zalloc() and ends up calling back into UMA for > whatever allocations, and "whatever allocations" are also > potentially offpage, and a slab header is ALSO required, then we > could also be recursing on the slab header zone from VM, so this > could cause the failure. > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > /* ADD PRINTF HERE */ > printf("This zone: %s, forced fail due to recurse non-null", > zone->uz_name); > return NULL; > } > > If you get the print to trigger right before the panic (last one > before the panic), see if it is on the SLAB HEADER zone. In > theory, it should only happen for the BUCKET ZONE. Yes, I think that I have verified your exelent analysis of the problem: http://www.holm.cc/stress/log/freeze04.html So, do have any fix suggenstons? :-) > > 2. M_WAITOK really isn't set. Unlikely. > > If (1) is really happening, we'll need to think about it a little more > before deciding how to fix it. As you can see, due to the recursive > nature of UMA/VM, things can get really tough when resources are > scarce. > > Regards, > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 18:17:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A1D916A4CE for ; Sun, 26 Dec 2004 18:17:41 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD8943D39 for ; Sun, 26 Dec 2004 18:17:40 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBQIHcCw023379; Sun, 26 Dec 2004 13:17:38 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBQIHcuW023377; Sun, 26 Dec 2004 13:17:38 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sun, 26 Dec 2004 13:17:38 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041226181738.GA21533@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226161153.GA74592@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 18:17:41 -0000 On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > Yes, I think that I have verified your exelent analysis of the > problem: http://www.holm.cc/stress/log/freeze04.html > > So, do have any fix suggenstons? :-) Not yet, because the problem is non-obvious from the trace. I need to know exactly when the UMA RCntSlabs zone recurses _first_, and I need to confirm that it is an actual recursion. I've looked at the VM code and I don't see how/why recursion on the RCntSlabs zone would happen. Please modify the printf code to look exactly like this: if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { if ((zone == slabzone) || (zone == slabrefzone)) panic("Zone %s forced to fail due to recurse non-null: %d\n", zone->uz_name, keg->uk_recurse); return (NULL); } (You don't need to check any global counter -- the counter is imperfect anyway -- because even a single recursion on slabzone or slabrefzone should be illegal). I'd like to see the trace from the above panic, if possible. Also, from your current crash dump, see if you can print the value of keg->uk_recurse (from frame 11, pid 74804). It appears that the other KASSERT being triggered from propagate_priority() is due to some weird side-effect of process 74804 looping with the UMA RCntSlabs zone lock held (without it ever being dropped). We'll have to see. The point is: the trace is useless unless it shows where/when the recursion on slabrefzone _begins_ to happen (not that it has already happened, that part is obvious now). Happy holidays, -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 18:17:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CFAE16A4F5; Sun, 26 Dec 2004 18:17:45 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8846C43D2D; Sun, 26 Dec 2004 18:17:44 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id iBQIHhOx056059; Sun, 26 Dec 2004 13:17:43 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)iBQIHhDp056047; Sun, 26 Dec 2004 13:17:43 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Sun, 26 Dec 2004 13:17:41 -0500 (EST) From: Jeff Roberson To: Robert Watson In-Reply-To: Message-ID: <20041226131611.I60504@mail.chesapeake.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: schedgraph.py X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 18:17:45 -0000 On Sun, 26 Dec 2004, Robert Watson wrote: > > On Sat, 25 Dec 2004, Jeff Roberson wrote: > > > To use the tool, you will need to define KTR_SCHED in KTR_COMPILE and > > KTR_MASK. I'd also bump entires up to 32768 or larger so you can grab a > > few seconds of data. Run your workload, and then capture the data with > > 'ktrdump -ct > ktr.out'. Then you simply run python schedgraph.py > > ktr.out. This requires a recent version of python and > > ports/x11-toolkits/py-tkinter. > > Great! > > For those who need a little more hand-holding getting KTR running, here's > a URL to try: > > http://www.watson.org/~robert/freebsd/netperf/ktr/ > > It's been my hope people would start producing more post-processing tools > -- KTR can collect some really great data that's just sitting there > waiting to be mined. I'd be interested in seeing post-processing tools > for locking as well. This looks like a great tool that will be really > helpful in understanding behavior and performance. Well, if you want to display contention, you can filter on that using the configuration menu, and display only contested locks. This tool could be easily extended to add events for picking up and droping mutexes as well. It would only require a new KTR and a regexp to match it. > > Thanks! > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 18:55:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFC316A4CE for ; Sun, 26 Dec 2004 18:55:20 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id B974543D1D for ; Sun, 26 Dec 2004 18:55:19 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 89101 invoked from network); 26 Dec 2004 18:55:18 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 Dec 2004 18:55:18 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBQItH6m076667; Sun, 26 Dec 2004 19:55:17 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBQItHup076666; Sun, 26 Dec 2004 19:55:17 +0100 (CET) (envelope-from pho) Date: Sun, 26 Dec 2004 19:55:17 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041226185517.GB76499@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226181738.GA21533@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 18:55:20 -0000 On Sun, Dec 26, 2004 at 01:17:38PM -0500, Bosko Milekic wrote: > > On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > > > Yes, I think that I have verified your exelent analysis of the > > problem: http://www.holm.cc/stress/log/freeze04.html > > > > So, do have any fix suggenstons? :-) > > Not yet, because the problem is non-obvious from the trace. > > I need to know exactly when the UMA RCntSlabs zone recurses _first_, > and I need to confirm that it is an actual recursion. I've looked at > the VM code and I don't see how/why recursion on the RCntSlabs zone > would happen. > > Please modify the printf code to look exactly like this: > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > if ((zone == slabzone) || (zone == slabrefzone)) > panic("Zone %s forced to fail due to recurse non-null: %d\n", > zone->uz_name, keg->uk_recurse); > return (NULL); > } > OK, I'll apply your latest patch and hope for a fast panic (I've been running for "1+02:20:48" without any problems). - Peter > (You don't need to check any global counter -- the counter is imperfect > anyway -- because even a single recursion on slabzone or slabrefzone > should be illegal). > > I'd like to see the trace from the above panic, if possible. > > Also, from your current crash dump, see if you can print the value of > keg->uk_recurse (from frame 11, pid 74804). > How do I do that? > It appears that the other KASSERT being triggered from > propagate_priority() is due to some weird side-effect of process > 74804 looping with the UMA RCntSlabs zone lock held (without it > ever being dropped). We'll have to see. > > The point is: the trace is useless unless it shows where/when the > recursion on slabrefzone _begins_ to happen (not that it has already > happened, that part is obvious now). > > Happy holidays, > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 19:00:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08B5516A4CE for ; Sun, 26 Dec 2004 19:00:36 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id E633B43D46 for ; Sun, 26 Dec 2004 19:00:34 +0000 (GMT) (envelope-from mwisnicki@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so147210rnz for ; Sun, 26 Dec 2004 11:00:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=PiqYfMP8oShCBWOMNt15yyYo3PxGah4JGjwc36pUALWvfD13RuuJsPVI3A2oUzc8aXdScNCuLB/YpVqyuhpxylml2G2va+5ltfF62wCJMhX/r0pM5sVaHNKKKhKM6RVog5YJB8JgpqlCZQ6NmjP0b6Xc5RAna7igemDUywNbxMo= Received: by 10.38.179.4 with SMTP id b4mr61961rnf; Sun, 26 Dec 2004 11:00:33 -0800 (PST) Received: from localhost.localdomain ([62.87.243.101]) by smtp.gmail.com with ESMTP id 62sm18138rna.2004.12.26.11.00.16; Sun, 26 Dec 2004 11:00:33 -0800 (PST) From: Marcin Wisnicki To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="=-ELE70YifvxOtgdFPgykr" Date: Sun, 26 Dec 2004 20:00:10 +0100 Message-Id: <1104087611.62361.13.camel@ghost.pnet.one.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Subject: FreeBSD 5.3 and 6 hangs on panic (in ata_shutdown) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 19:00:36 -0000 --=-ELE70YifvxOtgdFPgykr Content-Type: text/plain Content-Transfer-Encoding: 7bit After upgrade from 5.2.1 to 5.3 (and 5-STABLE after that), my both machines would always hang on panic (with and without acpi, dumps, sync on panic), just after printing uptime. This problem looks identical to the one described here: http://lists.freebsd.org/pipermail/freebsd-current/2004-May/026881.html I've also reproduced it on most recent 6-CURRENT kernel from ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/i386/livetree/ With ata debugging enabled I got this output: > Uptime: 1m41s > eventhandler_invoke("shutdown_post_sync") > eventhandler_invoke: executing 0xc066dbd0 # kproc_shutdown() > eventhandler_invoke: executing 0xc04d0dc0 # ata_shutdown() > ad0: req=0xc23e8258 FLUSHCACHE queued > ad0: req=0xc23e8258 FLUSHCACHE starting > ad0: req=0xc23e8258 FLUSHCACHE begin transaction > ad0: req=0xc23e8258 FLUSHCACHE wait for completition And then it locks up. I've tried single stepping from the line after the last ATA_DEBUG_RQ printf and found this loop: > Breakpoint at cv_wait: pushl %ebp > db> tr > cv_wait(c23e8750,c08a6272,67,c08a694f,c23e8708) at cv_wait # missing _sema_wait() (at the end of ata_queue_reqeust()) ? > ata_queue_request(c23e8708,0,101,0,3af0) at ata_queue_request+0x254 > ata_controlcmd(c21608ac,e7,0,0,0) at ata_controlcmd+0x8b > ata_shutdown(0,104,194,c089d209,c04d0d40) at ata_shutdown+0x7b > boot(104,0,c08d251c,233,100) at boot+0x727 > panic(c24ae5ad,d57e3bac,0,d57e3bf8,1) at panic+0x138 ... kern/kern_sema.c:_sema_wait(): 95 while (sema->sema_value == 0) { 96 sema->sema_waiters++; ->97 cv_wait(&sema->sema_cv, &sema->sema_mtx); 98 sema->sema_waiters--; 99 } But because panicstr is set, cv_wait() immediately returns, so _sema_wait() goes into a tight loop. kern/kern_condvar.c:cv_wait(): 111 if (cold || panicstr) { 112 /* 113 * During autoconfiguration, just give interrupts 114 * a chance, then just return. Don't run any other 115 * thread or panic below, in case this is the idle 116 * process and already asleep. 117 */ 118 return; 119 } As a workaround I tried the following change: ------------------------------------------------------------------- --- src/sys/kern/kern_condvar.c.orig Tue Nov 9 23:51:16 2004 +++ src/sys/kern/kern_condvar.c Thu Dec 23 18:04:46 2004 @@ -108,7 +108,7 @@ "Waiting on \"%s\"", cvp->cv_description); WITNESS_SAVE(&mp->mtx_object, mp); - if (cold || panicstr) { + if (cold) { /* * During autoconfiguration, just give interrupts * a chance, then just return. Don't run any other ------------------------------------------------------------------- This is what I get now instead of hang: > ad0: req=0xc23e8708 FLUSHCACHE interrupt > ad0: req=0xc23e8708 FLUSHCACHE end transaction > ad0: req=0xc23e8708 FLUSHCACHE finish taskqueue_thread > ad0: req=0xc23e8708 FLUSHCACHE completed entered > ad0: req=0xc23e8708 FLUSHCACHE completed callback/wakeup And it almost works now, normal panics (like "uhci_abort_xfer: not in process context" that I sometimes get under heavy load or a panic triggered by sysctl using a simple module) succeed, including crashdumps (even if panic happened while I was in X). There is a following problem when I call panic from ddb with this, so I guess a proper fix is more complicated but I don't know much about kernel programming. # sysctl debug.kdb.enter=1 debug.kdb.enter:K D0B: enter: sysctl debug.kdb.enter [thread 100036] Stopped at kdb_enter+0x30: leave db> panic panic: from debugger Uptime: 22s panic: mi_switch: switch in a critical section KDB: enter: panic [thread 100036] Stopped at kdb_enter+0x30: leave db> tr kdb_enter(c08d24f8,d57dd7b4,d57dd804,c068d3fe,104) at kdb_enter+0x30 panic(c08d2e6c,2,c08d2e04,11d,c08ef77c) at panic+0xcc mi_switch(1,0,c08d5556,196,127) at mi_switch+0xbc sleepq_switch(c23e81fc,1,c21a1960,c23e81fc,d57dd8a0) at sleepq_switch +0x134 sleepq_wait(c23e81fc,c23e81fc,c23e81d8,c08a6261,1) at sleepq_wait+0x41 cv_wait(c23e81fc,c23e81d8,c08d23f9,5e,d57dd8d8) at cv_wait+0x1e7 _sema_wait(c23e81d8,c08a6272,67,5b,c23e8190) at _sema_wait+0x43 ata_queue_request(c23e8190,0,101,0,d920) at ata_queue_request+0x254 ata_controlcmd(c21608ac,e7,0,0,0) at ata_controlcmd+0x8b ata_shutdown(0,104,194,c089d209,c04d0d40) at ata_shutdown+0x7b boot(104,0,c08d251c,233,100) at boot+0x727 panic(c089d08e,d57dda88,c046c2d2,c068a090,0) at panic+0x138 db_panic(c068a090,0,ffffffff,d57dd9fc,d57dd9f8) at db_panic+0x12 db_command(c0979124,c0902060,c08f90ec,c08f9108,d57ddaf4) at db_command +0x2b2 db_command_loop(c068a090,0,0,0,0) at db_command_loop+0x6a db_trap(3,0,3,d57ddb40,c086457a) at db_trap+0xe5 kdb_trap(3,0,d57ddb48,1,0) at kdb_trap+0x77 trap(18,10,10,0,0) at trap+0x4ea calltrap() at calltrap+0x5 --- trap 0x3, eip = 0xc068a090, esp = 0xd57ddb88, ebp = 0xd57ddb90 --- kdb_enter(c08d4b7a,d57ddba8,0,d57ddbf8,1) at kdb_enter+0x30 kdb_sysctl_enter(c0933dc0,0,0,d57ddbf8,d57ddbf8) at kdb_sysctl_enter +0x67 sysctl_root(0,d57ddc64,3,d57ddbf8,c21a1960) at sysctl_root+0x14e userland_sysctl(c21a1960,d57ddc64,3,0,0) at userland_sysctl+0x11f __sysctl(c21a1960,d57ddd14,3d8,c08f38de,c21a1960) at __sysctl+0xaf syscall(2f,2f,2f,0,0) at syscall+0x2c2 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280c82ef, esp = 0xbfbfe53c, ebp = 0xbfbfe568 ---db> Attachments: DEBUG: kernel configuration /usr/src/sys/i386/conf/DEBUG dmesg-verbose-ghost.txt: verbose dmesg from the first machine dmesg-verbose-wisnia.txt: verbose dmesg from the second machine ktr-hang-wisnia.txt: ktr output [ktr.mask=KTR_ALL] from the second machine, with DEBUG kernel, without workaround. This is from after print_uptime() up to hang --=-ELE70YifvxOtgdFPgykr Content-Disposition: attachment; filename=DEBUG Content-Type: text/plain; name=DEBUG; charset=UTF-8 Content-Transfer-Encoding: 7bit include GENERIC ident GENERIC_DEBUG makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options KTR options KTR_COMPILE=(KTR_ALL) options KTR_ENTRIES=131072 options KTR_VERBOSE --=-ELE70YifvxOtgdFPgykr Content-Disposition: attachment; filename=dmesg-verbose-ghost.txt Content-Type: text/plain; name=dmesg-verbose-ghost.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #6: Thu Dec 23 18:59:09 CET 2004 root@ghost.pnet.one.pl:/usr/obj/usr/src/sys/DEBUG WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/gendebug/kernel" at 0xc111c000. Preloaded elf module "/boot/gendebug/acpi.ko" at 0xc111c27c. Calibrating clock(s) ... i8254 clock: 1193255 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1000046717 Hz CPU: AMD Duron(tm) (1000.05-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x670 Stepping = 0 Features=0x383f9ff AMD Features=0xc0440000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 528416768 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x000000001eee3fff, 497803264 bytes (121534 pages) avail memory = 499052544 (475 MB) bios32: Found BIOS32 Service Directory header at 0xc00fdac0 bios32: Entry = 0xfdad0 (c00fdad0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xdaf1 pnpbios: Found PnP BIOS data at 0xc00f7790 pnpbios: Entry = f0000:65ab Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=31161106) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f7e00 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 1 A 0x01 3 4 5 6 7 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 6 7 10 11 12 14 15 embedded 0 17 A 0xfe 14 embedded 0 17 B 0xff 15 embedded 0 17 C 0x03 3 4 5 6 7 10 11 12 14 15 slot 1 0 8 A 0x01 3 4 5 6 7 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 6 7 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 6 7 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 6 7 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 6 7 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 6 7 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 6 7 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 6 7 10 11 12 14 15 embedded 0 16 A 0x01 3 4 5 6 7 10 11 12 14 15 embedded 0 16 B 0x02 3 4 5 6 7 10 11 12 14 15 embedded 0 16 C 0x03 3 4 5 6 7 10 11 12 14 15 embedded 0 16 D 0x05 3 4 5 6 7 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 6 7 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 17 func 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.1.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 10 11 12 14 15] 6+ low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.17.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.8.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 10 11 12 14 15] 6+ low,level,sharable 0.8.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.8.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.8.3 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 10 11 12 14 15] 6+ low,level,sharable 0.9.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.9.1 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.9.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.9.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.16.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 10 11 12 14 15] 6+ low,level,sharable 0.16.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.16.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.16.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.18.0 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x3116, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb091, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0xa230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000e400, size 5, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.LNKA) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 5, priority 63325): interrupts: 11 10 5 12 7 6 4 3 15 14 penalty: 160 160 210 5160 5160 5160 5160 5160 50160 50160 \\_SB_.LNKB (references 4, priority 50660): interrupts: 11 10 5 12 7 6 4 3 15 14 penalty: 160 160 210 5160 5160 5160 5160 5160 50160 50160 \\_SB_.LNKC (references 4, priority 50660): interrupts: 11 10 5 12 7 6 4 3 15 14 penalty: 160 160 210 5160 5160 5160 5160 5160 50160 50160 \\_SB_.LNKD (references 3, priority 37995): interrupts: 11 10 5 12 7 6 4 3 15 14 penalty: 160 160 210 5160 5160 5160 5160 5160 50160 50160 pcib0: slot 16 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000e800, size 5, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.LNKB) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKB (references 4, priority 51320): interrupts: 10 11 5 12 7 6 4 3 15 14 penalty: 320 370 370 5320 5320 5320 5320 5320 50320 50320 \\_SB_.LNKC (references 4, priority 51320): interrupts: 10 11 5 12 7 6 4 3 15 14 penalty: 320 370 370 5320 5320 5320 5320 5320 50320 50320 \\_SB_.LNKD (references 3, priority 38490): interrupts: 10 11 5 12 7 6 4 3 15 14 penalty: 320 370 370 5320 5320 5320 5320 5320 50320 50320 pcib0: slot 16 INTB routed to irq 6 via \\_SB_.LNKB found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000ec00, size 5, enabled pcib0: matched entry for 0.16.INTC (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKC (references 4, priority 51976): interrupts: 10 11 5 12 7 4 3 6 15 14 penalty: 480 530 530 5480 5480 5480 5480 5520 50480 50480 \\_SB_.LNKD (references 3, priority 38982): interrupts: 10 11 5 12 7 4 3 6 15 14 penalty: 480 530 530 5480 5480 5480 5480 5520 50480 50480 pcib0: slot 16 INTC routed to irq 5 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dfffff00, size 8, enabled pcib0: matched entry for 0.16.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 3, priority 39474): interrupts: 10 11 5 12 7 4 3 6 15 14 penalty: 640 690 730 5640 5640 5640 5640 5680 50640 50640 pcib0: slot 16 INTD routed to irq 10 via \\_SB_.LNKD found-> vendor=0x1106, dev=0x3104, revid=0x82 bus=0, slot=16, func=3 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1106, dev=0x3177, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000fc00, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib0: matched entry for 0.17.INTC (src \\_SB_.LNKC) pcib0: slot 17 INTC is already routed to irq 5 found-> vendor=0x1106, dev=0x3059, revid=0x50 bus=0, slot=17, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 1, range 32, base dffffe00, size 8, enabled pcib0: matched entry for 0.18.INTA (src \\_SB_.LNKA) pcib0: slot 18 INTA is already routed to irq 11 found-> vendor=0x1106, dev=0x3065, revid=0x74 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xdfd00000-0xdfefffff pcib1: prefetched decode 0xcfc00000-0xdfbfffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base dfe80000, size 19, enabled pcib1: device (null) requested decoded memory range 0xdfe80000-0xdfefffff map[14]: type 3, range 32, base d0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd0000000-0xd7ffffff pcib0: matched entry for 0.1.INTA (src \\_SB_.LNKA) pcib0: slot 1 INTA is already routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x5333, dev=0x8d04, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0xe400-0xe41f irq 11 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard DeskJet 920C, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode ugen0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR UC232A), rev 1.10/2.02, addr 3 uhci1: port 0xe800-0xe81f irq 6 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe800 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xec00-0xec1f irq 5 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xec00 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 16.3 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 ata0: channel #0 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=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 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=03 ostat0=20 ostat1=30 ata1-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata1-slave: stat=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ata1: [MPSAFE] pci0: at device 17.5 (no driver attached) vr0: port 0xdc00-0xdcff mem 0xdffffe00-0xdffffeff irq 11 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 miibus0: on vr0 ukphy0: on miibus0 ukphy0: OUI 0x004063, model 0x0032, rev. 5 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 42:00:e6:65:9b:11 vr0: [MPSAFE] acpi_button1: on acpi0 unknown: not probed (disabled) psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 atpic: Programming IRQ6 as edge/high fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP SPP ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() 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 ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed 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 0xcc000-0xdbfff,0xc0000-0xcbfff on isa0 pmtimer0 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) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, 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: 0x1 0x1 0x1 0x1 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 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 0e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 0e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1000046717 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 8235 chip ata0-master: setting UDMA100 on VIA 8235 chip ad0: ATA-6 disk at ata0-master ad0: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:00 typ:131 s(CHS):0/1/1 e(CHS):3/254/63 s:63 l:64197 [1] f:00 typ:4 s(CHS):4/0/1 e(CHS):7/254/63 s:64260 l:64260 [2] f:80 typ:165 s(CHS):8/0/1 e(CHS):1023/254/63 s:128520 l:24579450 [3] f:00 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:24707970 l:209728575 GEOM: Configure ad0s1, start 32256 length 32868864 end 32901119 GEOM: Configure ad0s2, start 32901120 length 32901120 end 65802239 GEOM: Configure ad0s3, start 65802240 length 12584678400 end 12650480639 GEOM: Configure ad0s4, start 12650480640 length 107381030400 end 120031511039 GEOM: Configure ad0s3a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s3b, start 536870912 length 805306368 end 1342177279 GEOM: Configure ad0s3c, start 0 length 12584678400 end 12584678399 GEOM: Configure ad0s3d, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0s3e, start 1342177280 length 268435456 end 1610612735 GEOM: Configure ad0s3f, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad0s3g, start 2147483648 length 2147483648 end 4294967295 GEOM: Configure ad0s3h, start 4294967296 length 8289711104 end 12584678399 GEOM: Configure ad0s4c, start 0 length 107381030400 end 107381030399 GEOM: Configure ad0s4d, start 0 length 80530636800 end 80530636799 GEOM: Configure ad0s4e, start 80530636800 length 26850393600 end 107381030399 Mounting root from ufs:/dev/ad0s3a start_init: trying /sbin/init --=-ELE70YifvxOtgdFPgykr Content-Disposition: attachment; filename=dmesg-verbose-wisnia.txt Content-Type: text/plain; name=dmesg-verbose-wisnia.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit OK boot -shv GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000001fef0000 SMAP type=03 base=000000001fff3000 len=000000000000d000 SMAP type=04 base=000000001fff0000 len=0000000000003000 Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #6: Thu Dec 23 18:59:09 CET 2004 root@ghost.pnet.one.pl:/usr/obj/usr/src/sys/DEBUG WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/gendebug/kernel" at 0xc111e000. Preloaded elf module "/boot/gendebug/acpi.ko" at 0xc111e1e0. Calibrating clock(s) ... i8254 clock: 1193091 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1750008683 Hz CPU: AMD Athlon(tm) XP 2100+ (1750.01-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383f9ff AMD Features=0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x000000001f6bffff, 506044416 bytes (123546 pages) avail memory = 507363328 (483 MB) bios32: Found BIOS32 Service Directory header at 0xc00fafd0 bios32: Entry = 0xfb440 (c00fb440) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb470 pnpbios: Found PnP BIOS data at 0xc00fbf30 pnpbios: Entry = f0000:bf60 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=30991106) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00fdf10 PCI-Only Interrupts: 5 11 12 Location Bus Device Pin Link IRQs slot 1 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 10 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 10 C 0x04 3 4 5 7 9 10 11 12 14 15 slot 1 0 10 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 11 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 11 B 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 11 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 11 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 12 A 0x04 3 4 5 7 9 10 11 12 14 15 slot 3 0 12 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 12 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 12 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 9 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 9 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 9 D 0x04 3 4 5 7 9 10 11 12 14 15 slot 5 0 14 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 14 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 14 C 0x04 3 4 5 7 9 10 11 12 14 15 slot 5 0 14 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x04 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.10.0 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.10.1 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.10.2 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.10.3 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.11.0 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.11.1 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.11.2 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.11.3 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.12.0 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.12.1 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.12.2 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.12.3 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.9.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.9.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.9.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.9.3 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.14.0 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.14.1 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.14.2 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.14.3 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.17.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.17.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.17.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.17.3 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.1.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.1.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.1.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.1.3 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.18.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.18.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.18.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.18.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base d0000000, size 27, enabled found-> vendor=0x1106, dev=0x3099, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb099, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000d000, size 8, enabled map[14]: type 1, range 32, base ea000000, size 8, enabled pcib0: matched entry for 0.11.INTA (src \_SB_.PCI0.LNKC) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKB (references 8, priority 166232): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 320 320 370 5320 5320 5320 5320 5320 50320 50320100320 \_SB_.PCI0.LNKC (references 8, priority 166232): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 320 320 370 5320 5320 5320 5320 5320 50320 50320100320 \_SB_.PCI0.LNKD (references 8, priority 166232): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 320 320 370 5320 5320 5320 5320 5320 50320 50320100320 \_SB_.PCI0.LNKA (references 8, priority 166232): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 320 320 370 5320 5320 5320 5320 5320 50320 50320100320 pcib0: slot 11 INTA routed to irq 12 via \_SB_.PCI0.LNKC found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base ea001000, size 12, enabled pcib0: matched entry for 0.12.INTA (src \_SB_.PCI0.LNKD) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKB (references 8, priority 168850): interrupts: 11 10 5 7 6 4 3 12 15 14 1 penalty: 640 640 690 5640 5640 5640 5640 5720 50640 50640100640 \_SB_.PCI0.LNKD (references 8, priority 168850): interrupts: 11 10 5 7 6 4 3 12 15 14 1 penalty: 640 640 690 5640 5640 5640 5640 5720 50640 50640100640 \_SB_.PCI0.LNKA (references 8, priority 168850): interrupts: 11 10 5 7 6 4 3 12 15 14 1 penalty: 640 640 690 5640 5640 5640 5640 5720 50640 50640100640 pcib0: slot 12 INTA routed to irq 5 via \_SB_.PCI0.LNKD found-> vendor=0x109e, dev=0x036e, revid=0x11 bus=0, slot=12, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base ea002000, size 12, enabled pcib0: matched entry for 0.12.INTA (src \_SB_.PCI0.LNKD) pcib0: slot 12 INTA is already routed to irq 5 found-> vendor=0x109e, dev=0x0878, revid=0x11 bus=0, slot=12, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3074, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 5, enabled pcib0: matched entry for 0.17.INTD (src \_SB_.PCI0.LNKD) pcib0: slot 17 INTD is already routed to irq 5 found-> vendor=0x1106, dev=0x3038, revid=0x1b bus=0, slot=17, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dc00, size 5, enabled pcib0: matched entry for 0.17.INTD (src \_SB_.PCI0.LNKD) pcib0: slot 17 INTD is already routed to irq 5 found-> vendor=0x1106, dev=0x3038, revid=0x1b bus=0, slot=17, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000e000, size 5, enabled pcib0: matched entry for 0.17.INTD (src \_SB_.PCI0.LNKD) pcib0: slot 17 INTD is already routed to irq 5 found-> vendor=0x1106, dev=0x3038, revid=0x1b bus=0, slot=17, func=4 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled pcib0: matched entry for 0.17.INTC (src \_SB_.PCI0.LNKC) pcib0: slot 17 INTC is already routed to irq 12 found-> vendor=0x1106, dev=0x3059, revid=0x30 bus=0, slot=17, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=12 powerspec 2 supports D0 D3 current D0 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe8000000-0xe9ffffff pcib1: prefetched decode 0xd8000000-0xe7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base e8000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xe8000000-0xe8ffffff map[14]: type 3, range 32, base d8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd8000000-0xdfffffff map[18]: type 3, range 32, base e0000000, size 19, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe007ffff pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKB (references 8, priority 171469): interrupts: 11 10 5 7 6 4 3 12 15 14 1 penalty: 960 960 1090 5960 5960 5960 5960 6040 50960 50960100960 \_SB_.PCI0.LNKA (references 8, priority 171469): interrupts: 11 10 5 7 6 4 3 12 15 14 1 penalty: 960 960 1090 5960 5960 5960 5960 6040 50960 50960100960 pcib0: slot 1 INTA routed to irq 11 via \_SB_.PCI0.LNKA pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x10de, dev=0x0253, revid=0xa3 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd000 rl0: port 0xd000-0xd0ff mem 0xea000000-0xea0000ff irq 12 at device 11.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:e0:7d:b4:31:c2 rl0: [MPSAFE] pci0: at device 12.0 (no driver attached) pci0: at device 12.1 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xd400-0xd40f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd400 ata0: channel #0 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=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 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=03 ostat0=50 ostat1=50 ata1-master: stat=0x90 err=0x01 lsb=0x14 msb=0xeb ata1-master: stat=0x90 err=0x01 lsb=0x14 msb=0xeb ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] uhci0: port 0xd800-0xd81f irq 5 at device 17.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB Mouse, rev 1.10/6.20, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ukbd0: BTC USB Keyboard and Mouse, rev 1.00/21.10, addr 3, iclass 3/1 kbd0 at ukbd0 kbd0: ukbd0, generic (0), config:0x0, flags:0x1d0000 ums1: BTC USB Keyboard and Mouse, rev 1.00/21.10, addr 3, iclass 3/1 ums1: 3 buttons and Z dir. uhci1: port 0xdc00-0xdc1f irq 5 at device 17.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc00 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe000-0xe01f irq 5 at device 17.4 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 17.5 (no driver attached) fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x21 0x31 0x21 0x21 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x21 0x29 0x21 0x21 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed fe 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 ahc_isa_probe 13: ioport 0xdc00 alloc failed 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-0xcefff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: not probed (disabled) psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: 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=0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5e 4f 50 81 53 80 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 18 18 18 18 1f 00 00 00 18 18 18 18 ff 00 00 00 00 00 00 00 ff 18 18 18 18 18 18 18 1f 18 18 18 00 00 00 00 ff 00 00 00 18 18 18 18 ff 18 18 18 18 18 1f 18 1f 18 18 18 36 36 36 36 37 36 36 36 EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5e 4f 50 81 53 80 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1750008683 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x46 cable=80pin ata0-master: setting PIO4 on VIA 8233 chip ata0-master: setting UDMA100 on VIA 8233 chip ad0: ATA-7 disk at ata0-master ad0: 39205MB (80293248 sectors), 79656 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin [0] f:00 typ:11 s(CHS):47/13/1 e(CHS):1023/7/63 s:48195 l:4192965 [1] f:00 typ:7 s(CHS):1023/255/63 e(CHS):1023/13/63 s:4241160 l:20980890 [2] f:00 typ:15 s(CHS):1023/255/63 e(CHS):1023/10/63 s:25222050 l:41945715 [3] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/9/63 s:67167765 l:13125105 GEOM: Configure ad0s1, start 24675840 length 2146798080 end 2171473919 GEOM: Configure ad0s2, start 2171473920 length 10742215680 end 12913689599 GEOM: Configure ad0s3, start 12913689600 length 21476206080 end 343898956stray irq7 79 GEOM: Configure ad0s4, start 34389895680 length 6720053760 end 41109949439 ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin MBREXT Slice 5 on ad0s3: [0] f:00 typ:11 s(CHS):1023/1/1 e(CHS):1023/254/63 s:63 l:41945652 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s5, start 32256 length 214stray irq7 76173824 end 21476206079 ata1-master: setting PIO4 on VIA 8233 chip GEOM: Configure ad0s4a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s4b, start 268435456 length 805306368 end 1073741823 GEOM: Configure ad0s4c, start 0 length 6720053760 end 6720053759 GEOM: Configure ad0s4d, start 1073741824 length 268435456 end 1342177279 GEOM: Configure ad0s4e, start 1342177280 length 268435456 end 1610612735 GEOM: Configure ad0s4f, start 1610612736 length 5109441024 end 6720053759 ata1-master: setting UDMA33 on VIA 8233 chip ata1-slave: setting PIO4 on VIA 8233 chip ata1-slave: setting UDMA33 on VIA 8233 chip acd0: DVDR drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: CDRW drive at ata1 as slave acd1: read 33171KB/s (8250KB/s) write 172KB/s (6875KB/s), 1984KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc Mounting root from ufs:/dev/ad0s4a start_init: trying /sbin/init --=-ELE70YifvxOtgdFPgykr Content-Disposition: attachment; filename=ktr-hang-wisnia.txt Content-Type: text/plain; name=ktr-hang-wisnia.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Uptime: 33s LOCK (sleep mutex) eventhandler r = 0 at /usr/src/sys/kern/subr_eventhandler.c:213 LOCK (sleep mutex) shutdown_post_sync r = 0 at /usr/src/sys/kern/subr_eventhandler.c:216 UNLOCK (sleep mutex) eventhandler r = 0 at /usr/src/sys/kern/subr_eventhandler.c:217 eventhandler_invoke("shutdown_post_sync") UNLOCK (sleep mutex) shutdown_post_sync r = 0 at /usr/src/sys/kern/kern_shutdown.c:416 eventhandler_invoke: executing 0xc066d8e0 # % addr2line -e /usr/obj/usr/src/sys/DEBUG/kernel.debug -f 0xc066d8e0 # kproc_shutdown # /usr/src/sys/kern/kern_shutdown.c:625 LOCK (sleep mutex) shutdown_post_sync r = 0 at /usr/src/sys/kern/kern_shutdown.c:416 UNLOCK (sleep mutex) shutdown_post_sync r = 0 at /usr/src/sys/kern/kern_shutdown.c:416 eventhandler_invoke: executing 0xc04d0da0 # % addr2line -e /usr/obj/usr/src/sys/DEBUG/kernel.debug -f 0xc04d0da0 # ata_shutdown # /usr/src/sys/dev/ata/ata-all.c:374 uma_zalloc_arg thread c2181c80 zone ata_request flags 257 LOCK (sleep mutex) UMA pcpu r = 0 at /usr/src/sys/vm/uma_core.c:1803 LOCK (sleep mutex) ata_request r = 0 at /usr/src/sys/vm/uma_core.c:1820 UNLOCK (sleep mutex) ata_request r = 0 at /usr/src/sys/vm/uma_core.c:1822 UNLOCK (sleep mutex) UMA pcpu r = 0 at /usr/src/sys/vm/uma_core.c:1824 LOCK (sleep mutex) All locks list r = 0 at /usr/src/sys/kern/subr_witness.c:528 UNLOCK (sleep mutex) All locks list r = 0 at /usr/src/sys/kern/subr_witness.c:534 sema_init(0xc23ec048, 0, "ATA request done") LOCK (sleep mutex) ATA queue lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:86 UNLOCK (sleep mutex) ATA queue lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:91 LOCK (sleep mutex) ATA queue lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:166 LOCK (sleep mutex) ATA state lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:183 LOCK (spin mutex) callout r = 0 at /usr/src/sys/kern/kern_timeout.c:398 UNLOCK (spin mutex) callout r = 0 at /usr/src/sys/kern/kern_timeout.c:439 LOCK (spin mutex) clk r = 0 at /usr/src/sys/i386/isa/clock.c:404 UNLOCK (spin mutex) clk r = 0 at /usr/src/sys/i386/isa/clock.c:412 LOCK (spin mutex) clk r = 0 at /usr/src/sys/i386/isa/clock.c:404 UNLOCK (spin mutex) clk r = 0 at /usr/src/sys/i386/isa.clock.c:412 UNLOCK (sleep mutex) ATA queue lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:202 UNLOCK (sleep mutex) ATA queue lock r = 0 at /usr/src/sys/dev/ata/ata-queue.c:205 --=-ELE70YifvxOtgdFPgykr-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 20:33:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72B0516A4CF for ; Sun, 26 Dec 2004 20:33:41 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id CDDB043D3F for ; Sun, 26 Dec 2004 20:33:40 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 85602 invoked from network); 26 Dec 2004 20:33:39 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 Dec 2004 20:33:39 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBQKXcZk077318; Sun, 26 Dec 2004 21:33:38 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBQKXcG6077317; Sun, 26 Dec 2004 21:33:38 +0100 (CET) (envelope-from pho) Date: Sun, 26 Dec 2004 21:33:38 +0100 From: Peter Holm To: Andre Oppermann Message-ID: <20041226203338.GA77287@peter.osted.lan> References: <20041220194742.GA89598@peter.osted.lan> <41C73CBC.9000106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C73CBC.9000106@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: rwatson@freebsd.org cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 20:33:41 -0000 On Mon, Dec 20, 2004 at 09:57:32PM +0100, Andre Oppermann wrote: > Peter Holm wrote: > >During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > > >panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > >tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > >ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > >netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > > at netisr_processqueue+0xf > >swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > >ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > >ithread_loop+0x19e > >fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > >fork_trampoline() at fork_trampoline+0x8 > > > >http://www.holm.cc/stress/log/cons96.html > > Duh. This is really strange. t_state is 0x1 which is TCPS_LISTEN. > Listen is only checked on the socket not on the tcpcb. However there > is a panic after "after_listen:" that checks for exactly TCPS_LISTEN. > It should never have made it past this one. That it did suggests > some kind of race condition wrt. sockets and the tcpcb creation for > the listening socket. Though even more strange is how this KASSERT > can be reached; Only if the segment has FIN set. /me puzzled. > > Ok, we know the segment had FIN set. We know the tcpcb is in LISTEN > state. We know in_pcblookup_hash() found this inpcb. We don't know > how the segment processing made it past all the checks prior to this > KASSERT. > > -- > Andre Here's a new one: http://www.holm.cc/stress/log/cons98.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 20:53:40 2004 Return-Path: Delivered-To: freebsd-current@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6615716A4CE; Sun, 26 Dec 2004 20:53:40 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F3F43D54; Sun, 26 Dec 2004 20:53:38 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-b122.otenet.gr [212.205.244.130]) iBQKrY0V031265; Sun, 26 Dec 2004 22:53:35 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBQKrYlR002167; Sun, 26 Dec 2004 22:53:34 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id iBQKrXr6002166; Sun, 26 Dec 2004 22:53:33 +0200 (EET) (envelope-from keramida@linux.gr) Date: Sun, 26 Dec 2004 22:53:33 +0200 From: Giorgos Keramidas To: Darren Reed Message-ID: <20041226205333.GA2039@gothmog.gr> References: <20041226182240.GA20920@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226182240.GA20920@hub.freebsd.org> cc: Scott Long cc: freebsd-current@hub.freebsd.org cc: Robert Watson Subject: Re: witness found wanting (was Re: LORs in ipfilter) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 20:53:40 -0000 On 2004-12-26 18:22, Darren Reed wrote: >In some mail from Giorgos Keramidas, sie said: >> The locking changes of ipfilter have introduced a few LORs, which >> became visible right after the build fixes committed by Scott. >> Here are the ones I've seen so far. >> >>: lock order reversal >>: 1st 0xc072d0a0 ifnet (ifnet) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:2146 >>: 2nd 0xc06f9380 ipf IP NAT rwlock (ipf IP NAT rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2836 >>: KDB: stack backtrace: >>: kdb_backtrace(0,ffffffff,c0708df8,c07083f8,c06d9aac) at kdb_backtrace+0x29 >>: witness_checkorder(c06f9380,9,c0676e6c,b14) at witness_checkorder+0x54c >>: _sx_xlock(c06f9380,c0676e6c,b14,3,c1e9a000) at _sx_xlock+0x50 >>: ip_natsync(c1e9a000,0,d95f9c84,c0448dd9,0) at ip_natsync+0x20 >>: frsync(0,c04f7994,c1d55fac,0,c068949f) at frsync+0x2e >>: iplioctl(c1e98b00,80047249,c1fa09e0,3,c1fba450) at iplioctl+0x551 >>: devfs_ioctl_f(c1ff1d48,80047249,c1fa09e0,c1d67d80,c1fba450) at devfs_ioctl_f+0x87 >>: ioctl(c1fba450,d95f9d14,3,1,246) at ioctl+0x370 >>: syscall(2f,2f,2f,280556c0,bfbfeed4) at syscall+0x213 >>: Xint0x80_syscall() at Xint0x80_syscall+0x1f >>: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c67e7, esp = 0xbfbfea7c, ebp = 0xbfbfea98 --- > > What exactly is it complaining about ? > > The first two LORs in your email are similar - threads that start in > a system call, filter through to the ipfilter code that acquires an > sx lock after the system has acquireqd a mutex. In neither case does > the mutex provide any protection against what is being achieved by > getting the sx lock. Hi Darren, I modified subr_witness.c here to print the w_level of each lock when a reversal is reported to see if that was the cause of the warning: : lock order reversal : 1st 0xc06fa1c0 [12] ipf IP state rwlock (ipf IP state rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:793 : 2nd 0xc072df00 [11] ifnet (ifnet) @ /usr/src/sys/net/if.c:1068 : KDB: stack backtrace: : kdb_backtrace(0,ffffffff,c0709258,c0709c58,c06d947c) at kdb_backtrace+0x29 : witness_checkorder(c072df00,9,c069674f,42c) at witness_checkorder+0x559 : _mtx_lock_flags(c072df00,0,c069674f,42c,2) at _mtx_lock_flags+0x5b : ifunit(c1d644dc,da7dda2c,c1d64400,5006,da7dd9f8) at ifunit+0x1e : fr_stinsert(c1d64400,1,0,0,0) at fr_stinsert+0x67 : fr_addstate(c1f992c4,da7dda2c,0,0) at fr_addstate+0x5f7 : fr_check(c1f992c4,14,c1e93014,1,da7ddad4) at fr_check+0x7cc : fr_check_wrapper(0,da7ddad4,c1e93014,2,c2101bf4) at fr_check_wrapper+0x2a : pfil_run_hooks(c0730440,da7ddb48,c1e93014,2,c2101bf4) at pfil_run_hooks+0xbd : ip_output(c1f99200,0,da7ddb14,0,0) at ip_output+0x57e : udp_output(c2101bf4,c1f99200,c1e893f0,0,c2015450) at udp_output+0x47d : udp_send(c20ff3cc,0,c1f99200,c1e893f0,0) at udp_send+0x1a : sosend(c20ff3cc,c1e893f0,da7ddc4c,c1f99200,0) at sosend+0x70f : kern_sendit(c2015450,16,da7ddcc4,0,0) at kern_sendit+0x104 : sendit(c2015450,16,da7ddcc4,0,c1e598b0) at sendit+0x159 : sendmsg(c2015450,da7ddd14,3,0,282) at sendmsg+0x5a : syscall(2f,2f,2f,1,82cb12c) at syscall+0x213 : Xint0x80_syscall() at Xint0x80_syscall+0x1f : --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x28322a27, esp = 0xbfaed73c, ebp = 0xbfaed8b8 --- Note the [12] and [11] after the lock pointer. This is, as far as I can tell by reading the witness_checkorder() function, the cause of the warning. I've already emailed John Baldwin, asking him how witness levels are assigned. It's a holiday season though, so I'm not sure if he will have the time to reply for a few days. > > Converting the sx locks used by ipfilter to mutexes fixed these LORs but > > introduced a new one, which I'm not sure how to fix: > > Which is surprising because it doesn't really fix the problem, in my > eyes, it just highlights the above weakness/bug in the witness code. > > It also seriously degrades the performance of ipfilter on an smp system. > That this sort of change makes the witness code silent is further > evidence that it is not really doing its job. Is this performance hit FreeBSD specific? I saw in ip_compat.h that on __sgi systems mutexes are used instead of rwlocks. Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 22:40:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33CC616A4CE for ; Sun, 26 Dec 2004 22:40:48 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E7543D41 for ; Sun, 26 Dec 2004 22:40:47 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBQMbWrv067105 for ; Sun, 26 Dec 2004 17:37:32 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBQMbWhn067102 for ; Sun, 26 Dec 2004 22:37:32 GMT (envelope-from robert@fledge.watson.org) Date: Sun, 26 Dec 2004 22:37:32 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Occasional wedging entering DDB via serial break X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 22:40:48 -0000 I'm seeing occasional wedging attempting to enter DDB via a serial break on a dual-Xeon box (4 logical processors). The symptoms usually look something like this: hippy# ./tmp.csh ~KDB: enter: Line break on console [thread pid 560 tid 100202 ] Stopped at kdb_enter+0x2c: leave db> show alllocks db> cont load: 0.04 cmd: super-smack 619 [runnable] 0.02u 0.51s 2% 2216k ~KDB: enter: Line break on console [thread pid 560 tid 100201 ] Stopped at kdb_enter+0x2c: leave db> show alllocks Process 560 (mysqld) Thread 0x18769 exclusive sleep mutex so_rcv r = 0 (0xc2a25bcc) locked @ kern/uipc_usrreq.c:464 exclusive sleep mutex unp r = 0 (0xc091a740) locked @ kern/uipc_usrreq.c:392 db> cont load: 0.92 cmd: super-smack 619 [runnable] 0.05u 1.36s 6% 2216k ~KDB: enter: Line break on console [thread pid 560 tid 100199 ] Stopped at kdb_enter+0x2c: leave db> show alllocks db> cont load: 2.12 cmd: super-smack 616 [running] 0.08u 2.90s 10% 2216k ~KDB: enter: Line break on console After that point, a serial break will no longer drop to DDB, respond to pings, etc. The box is running 6.x-CURRENT from this morning. Is anyone else seeing this, or does anyone else have ideas about what might cause this? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 22:56:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C898316A4DC for ; Sun, 26 Dec 2004 22:56:54 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id F38BF43D1D for ; Sun, 26 Dec 2004 22:56:53 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 95535 invoked from network); 26 Dec 2004 22:56:52 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 Dec 2004 22:56:52 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBQMupIu087196; Sun, 26 Dec 2004 23:56:51 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBQMupPB087195; Sun, 26 Dec 2004 23:56:51 +0100 (CET) (envelope-from pho) Date: Sun, 26 Dec 2004 23:56:51 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041226225651.GA87178@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226181738.GA21533@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 22:56:55 -0000 On Sun, Dec 26, 2004 at 01:17:38PM -0500, Bosko Milekic wrote: > > On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > > > Yes, I think that I have verified your exelent analysis of the > > problem: http://www.holm.cc/stress/log/freeze04.html > > > > So, do have any fix suggenstons? :-) > > Not yet, because the problem is non-obvious from the trace. > > I need to know exactly when the UMA RCntSlabs zone recurses _first_, > and I need to confirm that it is an actual recursion. I've looked at > the VM code and I don't see how/why recursion on the RCntSlabs zone > would happen. > > Please modify the printf code to look exactly like this: > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > if ((zone == slabzone) || (zone == slabrefzone)) > panic("Zone %s forced to fail due to recurse non-null: %d\n", > zone->uz_name, keg->uk_recurse); > return (NULL); > } > > (You don't need to check any global counter -- the counter is imperfect > anyway -- because even a single recursion on slabzone or slabrefzone > should be illegal). > > I'd like to see the trace from the above panic, if possible. Here it is: http://www.holm.cc/stress/log/freeze05.html > > Also, from your current crash dump, see if you can print the value of > keg->uk_recurse (from frame 11, pid 74804). > > It appears that the other KASSERT being triggered from > propagate_priority() is due to some weird side-effect of process > 74804 looping with the UMA RCntSlabs zone lock held (without it > ever being dropped). We'll have to see. > > The point is: the trace is useless unless it shows where/when the > recursion on slabrefzone _begins_ to happen (not that it has already > happened, that part is obvious now). > > Happy holidays, > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 00:48:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B850C16A4CE; Mon, 27 Dec 2004 00:48:55 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D4343D1D; Mon, 27 Dec 2004 00:48:55 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AD581512C9; Sun, 26 Dec 2004 16:47:59 -0800 (PST) Date: Sun, 26 Dec 2004 16:47:59 -0800 From: Kris Kennaway To: Robert Watson Message-ID: <20041227004759.GA57634@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org Subject: Re: Occasional wedging entering DDB via serial break X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 00:48:55 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 26, 2004 at 10:37:32PM +0000, Robert Watson wrote: >=20 > I'm seeing occasional wedging attempting to enter DDB via a serial break > on a dual-Xeon box (4 logical processors). The symptoms usually look > something like this: >=20 > hippy# ./tmp.csh > ~KDB: enter: Line break on console > [thread pid 560 tid 100202 ] > Stopped at kdb_enter+0x2c: leave > db> show alllocks > db> cont > load: 0.04 cmd: super-smack 619 [runnable] 0.02u 0.51s 2% 2216k > ~KDB: enter: Line break on console > [thread pid 560 tid 100201 ] > Stopped at kdb_enter+0x2c: leave > db> show alllocks > Process 560 (mysqld) > Thread 0x18769 > exclusive sleep mutex so_rcv r =3D 0 (0xc2a25bcc) locked @ > kern/uipc_usrreq.c:464 > exclusive sleep mutex unp r =3D 0 (0xc091a740) locked @ > kern/uipc_usrreq.c:392 > db> cont > load: 0.92 cmd: super-smack 619 [runnable] 0.05u 1.36s 6% 2216k > ~KDB: enter: Line break on console > [thread pid 560 tid 100199 ] > Stopped at kdb_enter+0x2c: leave > db> show alllocks > db> cont > load: 2.12 cmd: super-smack 616 [running] 0.08u 2.90s 10% 2216k > ~KDB: enter: Line break on console > >=20 > After that point, a serial break will no longer drop to DDB, respond to > pings, etc. The box is running 6.x-CURRENT from this morning. Is anyone > else seeing this, or does anyone else have ideas about what might cause > this? I see much the same..it seems to be just one more way in which DDB is broken on SMP machines. Setting debug.kdb.stop_cpus=3D0 tends to fix this for me, but then I get the joy of overlapping panics from multiple CPUs. Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBz1u/Wry0BWjoQKURAvn9AKDEIprV38dRcL710zE01/+piVrUDgCgkxTc mpZV5mVVCFDq5kVed82CqWk= =jnDR -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 01:33:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B34E216A4CE for ; Mon, 27 Dec 2004 01:33:58 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3021D43D3F for ; Mon, 27 Dec 2004 01:33:58 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-208-232.ny325.east.verizon.net [68.160.208.232]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iBR1XpwD026402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Dec 2004 20:33:53 -0500 (EST) Message-ID: <41CF6672.7080503@mac.com> Date: Sun, 26 Dec 2004 20:33:38 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41C8BD1C.9090507@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.8 required=5.5 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on pi.codefab.com Subject: Re: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 01:33:58 -0000 JINMEI Tatuya / $B?@L@C#:H wrote: >On Tue, 21 Dec 2004 17:17:32 -0700, Scott Long said: [ ... ] >>Do you have any comparisons to NetBSD or Solaris? Comparing to Linux >>often results in comparing apples to oranges since there is >>long-standing suspicion that Linux cuts corners where BSD does not. > > I've never done this type of test for NetBSD, since as far as I know > NetBSD is not very SMP-aware (does this change in, e.g., NetBSD 2.0?). Indeed, from http://www.netbsd.org/Releases/formal-2.0/NetBSD-2.0.html "The addition of a native threads implementation for all platforms and symmetrical multiprocessing (SMP) on i386 and other popular platforms were long-standing goals for NetBSD 2.0. Both of these goals have now been met—SMP support has been added for i386, SPARC, and PowerPC, the SMP support on Alpha and VAX has been improved, and the new port to the 64-bit AMD/Opteron also supports SMP." > I've checked Solaris with similar tests, but I could only use > a 2-processor sparc box. So, the results would not be very > informative. FWIW, however, Solaris performed quite well with 2 > processors. Solaris probably has the best SMP/threading implementation available today, and the SPARCv8 and v9 architectures were highly oriented towards supporting parallel execution and dealing with SMP cache coherency issues. Solaris on SPARC scales up with more CPUs added against workload very well, the only real problem the platform had is that individual SPARC CPU's aren't especially fast to begin with. Solaris is also using streams rather than a classic BSD TCP/IP network stack, although FreeBSD itself is going beyond classic TCP/IP stuff via Netgraph... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 01:37:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D832116A4CE for ; Mon, 27 Dec 2004 01:37:50 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CA6C43D5C for ; Mon, 27 Dec 2004 01:37:50 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBR1bj3T014459; Sun, 26 Dec 2004 20:37:45 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBR1bjMa014457; Sun, 26 Dec 2004 20:37:45 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sun, 26 Dec 2004 20:37:45 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041227013745.GA5267@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226225651.GA87178@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 01:37:51 -0000 On Sun, Dec 26, 2004 at 11:56:51PM +0100, Peter Holm wrote: > On Sun, Dec 26, 2004 at 01:17:38PM -0500, Bosko Milekic wrote: > > On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > > > > > Yes, I think that I have verified your exelent analysis of the > > > problem: http://www.holm.cc/stress/log/freeze04.html > > > > > > So, do have any fix suggenstons? :-) > > > > Not yet, because the problem is non-obvious from the trace. > > > > I need to know exactly when the UMA RCntSlabs zone recurses _first_, > > and I need to confirm that it is an actual recursion. I've looked at > > the VM code and I don't see how/why recursion on the RCntSlabs zone > > would happen. > > > > Please modify the printf code to look exactly like this: > > > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > > if ((zone == slabzone) || (zone == slabrefzone)) > > panic("Zone %s forced to fail due to recurse non-null: %d\n", > > zone->uz_name, keg->uk_recurse); > > return (NULL); > > } > > > > (You don't need to check any global counter -- the counter is imperfect > > anyway -- because even a single recursion on slabzone or slabrefzone > > should be illegal). > > > > I'd like to see the trace from the above panic, if possible. > > Here it is: http://www.holm.cc/stress/log/freeze05.html I have checked the code here and looked at possible code paths and have unfortunately resorted to reguessing, and now I believe I have identified a problematic scenario. Consider this particular timeline (time moves downward): [I hope you can handle ASCII art] By the way, the stack trace you show would correspond to that of thread 2. I refer to a frame number below. thread 1 (t1) thread 2 (t2) ------------------------------------------------------------------------- t1.a) Allocating from a zone, needs slab header from one of the slab header zones (either slabzone or slabrefzone). Let's assume it is slabzone, as in your trace above. The allocation is performed with M_WAITOK. t2.a) Needs to allocate from a zone, and it needs a slab header too. The allocation will be performed with M_WAITOK. Let's assume that the slab header zone we're allocating is also slabzone. t1.b) in uma_zone_slab(), has slabzone's keg lock, increments keg's uk_recurse. Enters slab_zalloc(). t2.b) Blocks on zone lock. t1.c) Drops zone lock to allocate from VM, uk_recurse for the slabzone is currently 1 (we incremented it in t1.b). t2.c) Takes zone lock for slabzone, now in uma_zone_slab() (Frame 11), and since uk_recurse is 1, it decides recursion happened. Wants to return NULL even though allocation was done with M_WAITOK. Our panic is triggered. I'll have to reserve some more time to think about this. One way I think it might be solvable would be to change that check that triggers the NULL return explicitly check for the bucketzone, and not for all UMA_ZONE_INTERNAL zones; I need to think this through a little more. Does the scenario seem likely to you? Cheers, -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 04:02:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BE516A4CE for ; Mon, 27 Dec 2004 04:02:20 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0014543D46 for ; Mon, 27 Dec 2004 04:02:19 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBR42G4I045388; Sun, 26 Dec 2004 23:02:16 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBR42GMV045387; Sun, 26 Dec 2004 23:02:16 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sun, 26 Dec 2004 23:02:16 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041227040216.GA44588@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20041227013745.GA5267@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 04:02:20 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'll have to reserve some more time to think about this. One way I > think it might be solvable would be to change that check that > triggers the NULL return explicitly check for the bucketzone, and not > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > more. Please try the attached patch and let me know if with it you can or cannot trigger the original (seemingly infinite) looping. Although I still haven't quite figured out how the described scenario could lead to infinite looping exactly (I did conclude that it could lead to some looping, though), the patch is worth trying as I believe the scenario *could* occur. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uma_mwaitok_null.diff" Index: uma_core.c =================================================================== RCS file: /home/ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.111 diff -u -r1.111 uma_core.c --- uma_core.c 26 Dec 2004 00:35:12 -0000 1.111 +++ uma_core.c 27 Dec 2004 03:58:25 -0000 @@ -1939,9 +1939,19 @@ * buckets there too we will recurse in kmem_alloc and bad * things happen. So instead we return a NULL bucket, and make * the code that allocates buckets smart enough to deal with it + * + * XXX: While we want this protection for the bucket zones so that + * recursion from the VM is handled (and the calling code that + * allocates buckets knows how to deal with it), we do not want + * to prevent allocation from the slab header zones (slabzone + * and slabrefzone) if uk_recurse is not zero for them. The + * reason is that it could lead to NULL being returned for + * slab header allocations even in the M_WAITOK case, and the + * caller can't handle that. */ if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) - return (NULL); + if ((zone != slabzone) && (zone != slabrefzone)) + return (NULL); slab = NULL; --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 09:40:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A91E016A4CE for ; Mon, 27 Dec 2004 09:40:08 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330DD43D1D for ; Mon, 27 Dec 2004 09:40:08 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so199371rne for ; Mon, 27 Dec 2004 01:40:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Begn/rNVEfyMP/n7usBzzk3GIXYiN7/cjNEIvz3borxY4c+KTb0t39u2zUPZrizSluRAsPuCF0mi7BZ4L7We28/ISt+XZbK8mC4668EmsoA7tQUaxhCIntikNKz6kk0ANGS/Sa2KZEeccxIpAEijBciJEPRnnnmLx32XHJLeJqM= Received: by 10.38.207.38 with SMTP id e38mr452289rng; Mon, 27 Dec 2004 01:40:07 -0800 (PST) Received: by 10.38.22.72 with HTTP; Mon, 27 Dec 2004 01:40:07 -0800 (PST) Message-ID: Date: Mon, 27 Dec 2004 17:40:07 +0800 From: Mikore Li To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ndis wrapper can't work on ferrari 3400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 09:40:08 -0000 Hi, My ferrari 3400 using broadcom 4320 802.11 b/g card. I successfully installed freebsd 5.3-release(i386) on it, but when I kldload if_ndis, it panic and hang my laptop, although some card information has been display out. Is there anyone make it work successfully? Thanks Mikore From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 10:39:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919C116A4CE for ; Mon, 27 Dec 2004 10:39:59 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4505A43D4C for ; Mon, 27 Dec 2004 10:39:59 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so202563rne for ; Mon, 27 Dec 2004 02:39:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CWQL5ACqu4ihc7XbSiiConUNYl1lXqoGhS39pwOZetH3nXfKNdZuIULXwgBXUUQM97NnKQx0H/d1TyqWaZElRZWNDpNky9GUNB4flDz9acGZviDhAT7MCvXsZtMahdsYqOl4cI2EgBUe07Q93I/mmD2bT/7PYmZ+C51iqKr06Cs= Received: by 10.38.151.48 with SMTP id y48mr467536rnd; Mon, 27 Dec 2004 02:39:58 -0800 (PST) Received: by 10.38.22.72 with HTTP; Mon, 27 Dec 2004 02:39:58 -0800 (PST) Message-ID: Date: Mon, 27 Dec 2004 18:39:58 +0800 From: Mikore Li To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ndis on ferrari 3400(AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 10:39:59 -0000 Hi, following is that last messages when I install if_ndis to ferrari3400, on freebsd5.3-release(i386) ============================================== ndis0: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FB6B16A4CE for ; Mon, 27 Dec 2004 11:06:54 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEA9343D49 for ; Mon, 27 Dec 2004 11:06:53 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so204010rne for ; Mon, 27 Dec 2004 03:06:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=kzO80M8DyleIFalBUJ3+uTuEdGMn9i9WKPnFQaAHbUaVAW5+aM7pVo3aWPEXg1yE/JaH1tOWy/73E6VjH9IuOqR5x/FvaP4vos3gwnIYTxqHn1074foJTDh+Bw/LnpuFO8zsbSS9x+W1qu94MGc0Uta/TADtc6CEjp2skmo3SgM= Received: by 10.38.67.76 with SMTP id p76mr20854rna; Mon, 27 Dec 2004 03:06:53 -0800 (PST) Received: by 10.38.22.72 with HTTP; Mon, 27 Dec 2004 03:06:53 -0800 (PST) Message-ID: Date: Mon, 27 Dec 2004 19:06:53 +0800 From: Mikore Li To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_290_10251800.1104145613267" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: dmesg on ferrari3400 laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 11:06:54 -0000 ------=_Part_290_10251800.1104145613267 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hope it will help find the bug related. Thanks Mikore ------=_Part_290_10251800.1104145613267-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 11:19:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D04416A4CE; Mon, 27 Dec 2004 11:19:54 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D28643D45; Mon, 27 Dec 2004 11:19:53 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBRBJlDM058058; Mon, 27 Dec 2004 12:19:49 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41CFEFAF.8040100@DeepCore.dk> Date: Mon, 27 Dec 2004 12:19:11 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> In-Reply-To: <20041224233021.GA43419@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Daniel Eriksson cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 11:19:54 -0000 Ruslan Ermilov wrote: > I don't have a serial console attached here, so below was cut-n-pasted > by hands: >=20 > : ata4-master: FAILURE - ATA_IDENTIFY timed out > : ata4-master: FAILURE - ATA_IDENTIFY timed out > : ata4-master: FAILURE - ATA_IDENTIFY timed out > : Trying to mount root from ufs:/dev/ad0a > : ata4-master: FAILURE - ATA_IDENTIFY timed out > : Slab at 0xffffff003d7e1f38, freei 15 =3D 0. > : panic: Duplicate free of item 0xffffff003d7e1ca8 from zone 0xffffff00= 3ffaf500(g_bio) > :=20 > : cpuid =3D 0 > : KDB: enter: panic > : [thread pid 3 tid 100029 ] > : Stopped at kdb_enter+0x2f: nop > : db> where > : kdb_enter() at ... > : panic() at ... > : uma_dbg_free() at ... > : uma_zfree_arg() at ... > : g_disk_done() at ... > : ad_done() at ... > : ata_completed() at ... > : g_io_schedule_up() at ... > : g_up_procbody() at ... > : fork_exit() at ... > : fork_trampoline() at ... > : --- trap 0, rip =3D 0, rsp =3D 0xffffffffa509dd00, rbp =3D 0 --- > : db> >=20 > A panic can be avoided by reverting the ata-queue.c,v 1.41. > But even after this, I get ATA_IDENTIFY failures. And as I > said, reverting to a somewhat earlier version makes it all > work. Hmm, on the exact same controller with two SATA drives on it and stock=20 current it "just works" (tm) here, I cannot reproduce the problem... Are you sure its a stock GENERIC kernel with no local mods/patches ? --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 11:56:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AD4D16A4CE for ; Mon, 27 Dec 2004 11:56:55 +0000 (GMT) Received: from cny.innet.yaroslavl.su (cny.innet.yaroslavl.su [217.15.134.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA82343D1D for ; Mon, 27 Dec 2004 11:56:46 +0000 (GMT) (envelope-from freebsd@azimut-tour.ru) Received: from tac.innet.yaroslavl.su (tac.innet.yaroslavl.su [217.15.135.68]) by cny.innet.yaroslavl.su (8.11.6/8.11.6) with ESMTP id iBRBuWj01779 for ; Mon, 27 Dec 2004 14:56:32 +0300 (MSK) Received: from [192.168.3.3] (198.ppp146.yaroslavl.ru [217.15.146.198]) iBRBuT0I002148 for ; Mon, 27 Dec 2004 14:56:32 +0300 (MSK) Date: Mon, 27 Dec 2004 14:56:16 +0300 From: freebsd@azimut-tour.ru X-Priority: 3 (Normal) Message-ID: <34363233952.20041227145616@azimut-tour.ru> To: current@freebsd.org In-Reply-To: <41CC9BDA.7020203@DeepCore.dk> References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd@azimut-tour.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 11:56:55 -0000 Hi, I too have problems with controller Promise PDC20378 SATA150 TX. Periodically at loading system the fourth HDD "falls off". (Connected on PATA the interface of the controller on ata4-slave channel) The main thing that I can not understand law. HDDs interchanged the position, but does not work on last channel. dmesg writes instead of the normal message => ad9: 78167MB [158816/16/63] at ata4-slave UDMA100 the following => ad9: 77815MB [34652/73/63] at ata4-slave SATA150 or following => ad9: 76151MB [72236/17/127] at ata4-slave SATA150 And is farther or a panic or will swear and further it is loaded. Promise stands on matherboard ASUS P4C800 E-DELUXE. HDDs Maxtor 2 - 6Y080P0 and 2 - 6Y080M0. RAID 0+1. Though raid it similar does not depend on type - experimented. I apologize for my English, I at all do not know him{it}:) From owner-freebsd-current@FreeBSD.ORG Sun Dec 26 18:22:40 2004 Return-Path: Delivered-To: freebsd-current@hub.freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id 7018216A4CF; Sun, 26 Dec 2004 18:22:40 +0000 (GMT) Date: Sun, 26 Dec 2004 18:22:40 +0000 From: Darren Reed To: keramida@freebsd.org Message-ID: <20041226182240.GA20920@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Mon, 27 Dec 2004 13:07:45 +0000 cc: Scott Long cc: freebsd-current@hub.freebsd.org cc: Robert Watson Subject: witness found wanting (was Re: LORs in ipfilter) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 18:22:40 -0000 In some mail from Giorgos Keramidas, sie said: > The locking changes of ipfilter have introduced a few LORs, which became > visible right after the build fixes committed by Scott. Here are the > ones I've seen so far. > > : lock order reversal > : 1st 0xc072d0a0 ifnet (ifnet) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:2146 > : 2nd 0xc06f9380 ipf IP NAT rwlock (ipf IP NAT rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2836 > : KDB: stack backtrace: > : kdb_backtrace(0,ffffffff,c0708df8,c07083f8,c06d9aac) at kdb_backtrace+0x29 > : witness_checkorder(c06f9380,9,c0676e6c,b14) at witness_checkorder+0x54c > : _sx_xlock(c06f9380,c0676e6c,b14,3,c1e9a000) at _sx_xlock+0x50 > : ip_natsync(c1e9a000,0,d95f9c84,c0448dd9,0) at ip_natsync+0x20 > : frsync(0,c04f7994,c1d55fac,0,c068949f) at frsync+0x2e > : iplioctl(c1e98b00,80047249,c1fa09e0,3,c1fba450) at iplioctl+0x551 > : devfs_ioctl_f(c1ff1d48,80047249,c1fa09e0,c1d67d80,c1fba450) at devfs_ioctl_f+0x87 > : ioctl(c1fba450,d95f9d14,3,1,246) at ioctl+0x370 > : syscall(2f,2f,2f,280556c0,bfbfeed4) at syscall+0x213 > : Xint0x80_syscall() at Xint0x80_syscall+0x1f > : --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c67e7, esp = 0xbfbfea7c, ebp = 0xbfbfea98 --- What exactly is it complaining about ? The first two LORs in your email are similar - threads that start in a system call, filter through to the ipfilter code that acquires an sx lock after the system has acquireqd a mutex. In neither case does the mutex provide any protection against what is being achieved by getting the sx lock. If there is a bug here, it is in the assumptions that are built into the "witness code" checking of how locks can be used together. It may be that these need to be "blessed" (and you use the BLESSED option) because this behaviour is absolutely required and is not a "bug" or flaw. What is strange, I find, is that with witness turned on, you have not reported a panic for the recusrive acquiring of the ifnet lock. I suppose we're still approaching the point where it is safe to do that sort of recusive checking on mutexes ? > Converting the sx locks used by ipfilter to mutexes fixed these LORs but > introduced a new one, which I'm not sure how to fix: Which is surprising because it doesn't really fix the problem, in my eyes, it just highlights the above weakness/bug in the witness code. It also seriously degrades the performance of ipfilter on an smp system. That this sort of change makes the witness code silent is further evidence that it is not really doing its job. If you like, this is a classic case of bottom/top half driver locking where shared locks are used, instead of mutexes, to provide the requried synchronisation. In summary, what you've reported is not a problem with ipfilter code or use of locks, as far as I can tell. I could go on... Darren From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 04:25:22 2004 Return-Path: Delivered-To: freebsd-current@hub.freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id EF5DA16A4D0; Mon, 27 Dec 2004 04:25:22 +0000 (GMT) Date: Mon, 27 Dec 2004 04:25:22 +0000 From: Darren Reed To: Giorgos Keramidas Message-ID: <20041227042522.GC18879@hub.freebsd.org> References: <20041226182240.GA20920@hub.freebsd.org> <20041226205333.GA2039@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041226205333.GA2039@gothmog.gr> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Mon, 27 Dec 2004 13:07:45 +0000 cc: Scott Long cc: freebsd-current@hub.freebsd.org cc: Robert Watson Subject: Re: witness found wanting (was Re: LORs in ipfilter) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 04:25:23 -0000 On Sun, Dec 26, 2004 at 10:53:33PM +0200, Giorgos Keramidas wrote: > > Is this performance hit FreeBSD specific? I saw in ip_compat.h that on > __sgi systems mutexes are used instead of rwlocks. When I first ported IPFilter to IRIX, their equivalent of sx locks did not work in interrupt context (I think this was also true of lockmgr locks in BSD, too.) To work around this, I used mutexes instead. The #ifdef maze in 3.4's ip_compat.h is delicate so I try not to mess with it more than I have to, but later versions of IRIX do have a working lock type of this nature and I use it where available. In this case, "do not work" means "panic when attempted". Darren From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 13:53:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 337DB16A4CE for ; Mon, 27 Dec 2004 13:53:09 +0000 (GMT) Received: from smtp-relay1.uni-bielefeld.de (smtp-relay1.uni-bielefeld.de [129.70.4.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFFB343D39 for ; Mon, 27 Dec 2004 13:53:07 +0000 (GMT) (envelope-from hhasenbe@techfak.uni-bielefeld.de) Received: from conversion-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) id <0I9D00F01VHAFW@mail1.hrz.uni-bielefeld.de> (original mail from hhasenbe@techfak.uni-bielefeld.de) for freebsd-current@freebsd.org; Mon, 27 Dec 2004 14:53:06 +0100 (MET) Received: from [127.0.0.1] ([129.70.170.32]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPP id <0I9D008NQVWFTJ@mail1.hrz.uni-bielefeld.de>; Mon, 27 Dec 2004 14:53:06 +0100 (MET) Date: Mon, 27 Dec 2004 14:52:58 +0100 From: Hendrik Hasenbein In-reply-to: To: Mikore Li Message-id: <41D013BA.2010107@techfak.uni-bielefeld.de> MIME-version: 1.0 Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms080303040405010501040603 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) References: cc: freebsd-current@freebsd.org Subject: Re: ndis wrapper can't work on ferrari 3400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 13:53:09 -0000 --------------ms080303040405010501040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mikore Li wrote: > Hi, > > My ferrari 3400 using broadcom 4320 802.11 b/g card. I successfully installed > freebsd 5.3-release(i386) on it, but when I kldload if_ndis, it panic > and hang my > laptop, although some card information has been display out. > > Is there anyone make it work successfully? I got an non-Ferrari Aspire with almost identical hardware, but the driver wont find the hardware. How did you configure your ACPI? Hendrik --------------ms080303040405010501040603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCC AxMwggJ8oAMCAQICAw1rczANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMTEzMDcxOTMyWhcNMDUxMTEzMDcxOTMy WjBTMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMTAwLgYJKoZIhvcNAQkBFiFo aGFzZW5iZUB0ZWNoZmFrLnVuaS1iaWVsZWZlbGQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhhSdN6xXVFX2PGSBtWFVArdLV/tAFfPJI+z2G7Euzfet95G2wVEeE54w Ak7+Zfng6bw8ALVkke02vhHaIUdTgFRlKnHWUB8WoIWTdu7mU2zy+5+JqP8h9/9fdlYrtmFx nlv4ya8A16klzw3RBWI3Y+7tWqS0lgMQM22Zd0jKhNE1Wu6zpWRfbY9SIrkpm0M6FyWrwpUi ZlwqiOSaH7XLFoHio67ZAFXIXxb+vwFFFE+JT5yKW0inqe25K3rJEm16wI2wk/ZojE4+8dly 5ZXADQtHYPwP9WWo5187Vx1gl/qK1SBebcWMtyaBDTcGYppa7am2Eq5/sf1yPmhyhPBtAgMB AAGjYjBgMA8GA1UdDwEB/wQFAwMH+YAwEQYJYIZIAYb4QgEBBAQDAgUgMCwGA1UdEQQlMCOB IWhoYXNlbmJlQHRlY2hmYWsudW5pLWJpZWxlZmVsZC5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAGFUnTUwhATV+gNaw2r1J7tJR66wotyx9bT7yahFsaRineKHi+15Quxe 2njoUsMeIRbYlTo5ukgxoEExUxuhORz8qxomYSDkZrudakqQjPJjmX4Fjx0YV2Wm/kVNWPJ7 cOw6Yeh0oS5jZKvwrSuI1TwuwHy6/4ODWqKDJ8RzwJrlMIIDEzCCAnygAwIBAgIDDWtzMA0G CSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTAeFw0wNDExMTMwNzE5MzJaFw0wNTExMTMwNzE5MzJaMFMxHzAdBgNVBAMTFlRoYXd0 ZSBGcmVlbWFpbCBNZW1iZXIxMDAuBgkqhkiG9w0BCQEWIWhoYXNlbmJlQHRlY2hmYWsudW5p LWJpZWxlZmVsZC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALOGFJ03rFdU VfY8ZIG1YVUCt0tX+0AV88kj7PYbsS7N9633kbbBUR4TnjACTv5l+eDpvDwAtWSR7Ta+Edoh R1OAVGUqcdZQHxaghZN27uZTbPL7n4mo/yH3/192Viu2YXGeW/jJrwDXqSXPDdEFYjdj7u1a pLSWAxAzbZl3SMqE0TVa7rOlZF9tj1IiuSmbQzoXJavClSJmXCqI5JoftcsWgeKjrtkAVchf Fv6/AUUUT4lPnIpbSKep7bkreskSbXrAjbCT9miMTj7x2XLllcANC0dg/A/1ZajnXztXHWCX +orVIF5txYy3JoENNwZimlrtqbYSrn+x/XI+aHKE8G0CAwEAAaNiMGAwDwYDVR0PAQH/BAUD Awf5gDARBglghkgBhvhCAQEEBAMCBSAwLAYDVR0RBCUwI4EhaGhhc2VuYmVAdGVjaGZhay51 bmktYmllbGVmZWxkLmRlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAYVSdNTCE BNX6A1rDavUnu0lHrrCi3LH1tPvJqEWxpGKd4oeL7XlC7F7aeOhSwx4hFtiVOjm6SDGgQTFT G6E5HPyrGiZhIORmu51qSpCM8mOZfgWPHRhXZab+RU1Y8ntw7Dph6HShLmNkq/CtK4jVPC7A fLr/g4NaooMnxHPAmuUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1rczAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEyMjcxMzUyNThaMCMGCSqGSIb3DQEJBDEWBBRk6xB5ge+CMiRqCPAlMPY2F816SDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWtzMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1r czANBgkqhkiG9w0BAQEFAASCAQAxZdelRjLqgGG7sq0szdTXrX9xvxaIGYuW0zZACyg+h1Pp r8DJ5kgy2nvPc1KkYbnmUnHhM7BGirYGuYT3Leqg24O8+/pPhMq+/Az6GmOMNw1BELLLO9vK JO24MqSabkesphfWfS55qnimCd8AojiOiDVSafBtI/8FD8e5lhebjdMW8k/CwVJGwR1mxnIH fv42GvQ1DLk3rq9Oj00Ih0dPKl3OOFJ+o+lf/ttYCcYwoKrAheS/5Kx+bpNAgYmDTkgAYHNt MZRfzwKX6GFc9Ej3SRje5boqcgWNr30Kn6i83bbySNowXiAWEpLMqkXoLGYXx6Unj1VidXX4 8xuK2lp1AAAAAAAA --------------ms080303040405010501040603-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 14:13:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7BE316A4CE; Mon, 27 Dec 2004 14:13:13 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE71D43D3F; Mon, 27 Dec 2004 14:13:12 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBRED30B048074; Mon, 27 Dec 2004 16:13:03 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 49407-16; Mon, 27 Dec 2004 16:13:02 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBRED1De048071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Dec 2004 16:13:02 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBREDAcl095911; Mon, 27 Dec 2004 16:13:11 +0200 (EET) (envelope-from ru) Date: Mon, 27 Dec 2004 16:13:10 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041227141310.GA95767@ip.net.ua> References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <41CFEFAF.8040100@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 14:13:14 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 27, 2004 at 12:19:11PM +0100, S?ren Schmidt wrote: > Ruslan Ermilov wrote: >=20 > >I don't have a serial console attached here, so below was cut-n-pasted > >by hands: > > > >: ata4-master: FAILURE - ATA_IDENTIFY timed out > >: ata4-master: FAILURE - ATA_IDENTIFY timed out > >: ata4-master: FAILURE - ATA_IDENTIFY timed out > >: Trying to mount root from ufs:/dev/ad0a > >: ata4-master: FAILURE - ATA_IDENTIFY timed out > >: Slab at 0xffffff003d7e1f38, freei 15 =3D 0. > >: panic: Duplicate free of item 0xffffff003d7e1ca8 from zone=20 > >0xffffff003ffaf500(g_bio) > >:=20 > >: cpuid =3D 0 > >: KDB: enter: panic > >: [thread pid 3 tid 100029 ] > >: Stopped at kdb_enter+0x2f: nop > >: db> where > >: kdb_enter() at ... > >: panic() at ... > >: uma_dbg_free() at ... > >: uma_zfree_arg() at ... > >: g_disk_done() at ... > >: ad_done() at ... > >: ata_completed() at ... > >: g_io_schedule_up() at ... > >: g_up_procbody() at ... > >: fork_exit() at ... > >: fork_trampoline() at ... > >: --- trap 0, rip =3D 0, rsp =3D 0xffffffffa509dd00, rbp =3D 0 --- > >: db> > > > >A panic can be avoided by reverting the ata-queue.c,v 1.41. > >But even after this, I get ATA_IDENTIFY failures. And as I > >said, reverting to a somewhat earlier version makes it all > >work. >=20 > Hmm, on the exact same controller with two SATA drives on it and stock=20 > current it "just works" (tm) here, I cannot reproduce the problem... > Are you sure its a stock GENERIC kernel with no local mods/patches ? >=20 Yes. This is the Asus SK8N motherboard, but I only have one PATA drive attached to 3rd (PATA) channel; first two channels (SATA) don't have any drives attached. Can you check in this configuration? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0Bh2qRfpzJluFF4RAo38AKCbOVhIheenFq1bz5LK2Y1Fhr7j3QCfehN7 bjsgBSpwlYnt0+fABr2hI74= =wLwf -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 15:50:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A919E16A4CE for ; Mon, 27 Dec 2004 15:50:55 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB5243D31 for ; Mon, 27 Dec 2004 15:50:54 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I9E00CT51CTOO@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Mon, 27 Dec 2004 16:50:53 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 27 Dec 2004 16:50:52 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149])iBRFoqae006781 for ; Mon, 27 Dec 2004 16:50:52 +0100 (MET) Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 452F528439; Mon, 27 Dec 2004 16:50:47 +0100 (CET) Date: Mon, 27 Dec 2004 16:50:47 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20041227155046.GA16444@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=HlL+5n6rz5pIUxbD; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.6i X-Operating-System: FreeBSD 5.3-STABLE X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Subject: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netgraph/ng_base.c:1189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 15:50:55 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I get the following reproducible panic when booting a kernel with 'options NETGRAPH_BLUETOOTH_UBT' compiled in. The panic does not occur when loading the ng_ubt module from the loader. The kernel config is available at: http://people.freebsd.org/~brueffer/FANGORN panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netgraph/ng_base.c:11= 89 KDB: enter: panic Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> tr Tracing pid 0 tid 0 td 0xc0809980 kdb_enter(c07a3b3d,c080bc80,c07a3012,c0c20cb0,c0809980) at kdb_enter+0x32 panic(c07a3012,0,c07b1161,4a5,cb) at panic+0x14d _mtx_lock_flags(c0836280,0,c07b1161,4a5,1000a) at _mtx_lock_flags+0x114 ng_findtype(c07b003f,101,c1046a00,0,0) at ng_findtype+0x2f ng_newtype(c07e8600,c079778f,101,0,c19d9a00) at ng_newtype+0x60 ubt_modevent(c196d500,0,0,c196d500,c1945630) at ubt_modevent+0x3f driver_module_handler(c196d500,0,c07e856c,c0c20d78,c050913f) at driver_modu= le_handler+0xa5 module_register_init(c07e8560,0,c1945a54,c1ec00,c1e000) at module_register_= init+0x75 mi_startup() at mi_startup+0xd6 begin() at begin+0x2c db> - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0C9WbHYXjKDtmC0RAkE4AKCt+HYiZJtCPiNhicDI/Kb6FCsDIwCcCZrP nVGqR1wB/btOJAtyjTCXmnA= =RFD2 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 16:39:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E89C16A4CE; Mon, 27 Dec 2004 16:39:42 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B297D43D46; Mon, 27 Dec 2004 16:39:41 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBRGdaGO060725; Mon, 27 Dec 2004 17:39:39 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41D03AA4.3020908@DeepCore.dk> Date: Mon, 27 Dec 2004 17:39:00 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> In-Reply-To: <20041227141310.GA95767@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 16:39:42 -0000 Ruslan Ermilov wrote: >>Hmm, on the exact same controller with two SATA drives on it and stock = >>current it "just works" (tm) here, I cannot reproduce the problem... >>Are you sure its a stock GENERIC kernel with no local mods/patches ? >> > Yes. This is the Asus SK8N motherboard, but I only have one PATA > drive attached to 3rd (PATA) channel; first two channels (SATA) > don't have any drives attached. Can you check in this configuration? atapci0: port=20 0xb800-0xb87f,0xd000-0xd00f,0xd400-0xd43f mem=20 0xfc800000-0xfc81ffff,0xfd000000-0xfd000fff irq 18 at device 5.0 on pci0 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 =2E.. atapci1: port=20 0xb000-0xb00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 =2E.. ad0: 13042MB [26500/16/63] at ata0-master UDMA= 33 acd0: DVDRAM at ata0-slave PIO4 afd0: REMOVABLE at ata1-master PIO3 acd1: CDRW at ata1-slave PIO4 ad1: 38166MB [77545/16/63] at ata4-master UDMA100 That works just as well... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 18:05:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC32216A4CE for ; Mon, 27 Dec 2004 18:05:18 +0000 (GMT) Received: from av1-2-sn1.fre.skanova.net (av1-2-sn1.fre.skanova.net [81.228.11.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A3A043D41 for ; Mon, 27 Dec 2004 18:05:18 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id B512837F09; Mon, 27 Dec 2004 19:05:17 +0100 (CET) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id A62EC37F06; Mon, 27 Dec 2004 19:05:17 +0100 (CET) Received: from sentinel (h211n1fls11o822.telia.com [213.64.66.211]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 7646F37E50; Mon, 27 Dec 2004 19:05:17 +0100 (CET) From: "Daniel Eriksson" To: Date: Mon, 27 Dec 2004 19:05:11 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcTsPpt7uagmBtiHSrCjbIztvx5gHg== cc: 'Poul-Henning Kamp' Subject: "Last mounted on" no longer correct X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 18:05:19 -0000 When running fsck on a filesystem it reports where it was last mounted. Since a few weeks back this information is no longer updated it seems. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 22:11:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D26816A53C for ; Mon, 27 Dec 2004 22:11:11 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D2543D1D for ; Mon, 27 Dec 2004 22:11:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5975 invoked from network); 27 Dec 2004 22:11:11 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 27 Dec 2004 22:11:10 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBRMArTN089244; Mon, 27 Dec 2004 17:11:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 27 Dec 2004 16:41:51 -0500 User-Agent: KMail/1.6.2 References: <6.0.3.0.0.20040517154946.06d23d60@64.7.153.2> <6.0.3.0.0.20040603220621.045655e0@64.7.153.2> <20041208184326.W1740@epsplex.bde.org> In-Reply-To: <20041208184326.W1740@epsplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412271641.51744.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Bruce Evans cc: Mike Tancsa Subject: Re: sio / puc wedging on both -current and -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:11:13 -0000 On Wednesday 08 December 2004 02:52 am, Bruce Evans wrote: > Long ago, On Thu, 3 Jun 2004, Mike Tancsa wrote: > > Just a quick recap. I can fairly easily trigger an interrupt storm on > > these machines with USB enabled in the BIOS. If I disable it, I dont > > have a problem and all works well.... However, what I accidently came > > across today, was that if I load the USB drivers as a kld, I can *not* > > wedge the machine. Note the bottom of the following diff > > I can now explain this. When usb is in the kernel proper, it normally > gets the interrupt first and exposes bugs in sio (see other mail -- > there is a conflict but sio ignores the error). When usb is in a > module, sio normally gets the interrupt first. There is again a > conflict but usb doesn't ignore the error. > > > diff dmesg.kld dmesg.static > > > > < uhci2: port 0xb400-0xb41f > > irq 12 at device 29.2 on pci0 > > < uhci2: Could not allocate irq > > < device_probe_and_attach: uhci2 attach returned 6 > > < uhci2: port 0xb400-0xb41f > > irq 12 at device 29.2 on pci0 > > < uhci2: Could not allocate irq > > < device_probe_and_attach: uhci2 attach returned 6 > > This shows uhci2 not ignoring the error. I'd like to force sio(4) devices attached via PCI to just always share the interrupt and not use INTR_FAST for now. That would allow sio and usb to play well in both situations. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 22:11:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD26B16A4DA for ; Mon, 27 Dec 2004 22:11:15 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C0F843D41 for ; Mon, 27 Dec 2004 22:11:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 27941 invoked from network); 27 Dec 2004 22:11:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 27 Dec 2004 22:11:14 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBRMArTO089244; Mon, 27 Dec 2004 17:11:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 27 Dec 2004 17:05:31 -0500 User-Agent: KMail/1.6.2 References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <20041220110411.GA87750@peter.osted.lan> In-Reply-To: <20041220110411.GA87750@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412271705.31625.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: jeffr@FreeBSD.org cc: bmilekic@FreeBSD.org cc: jroberson@chesapeake.net Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:11:16 -0000 On Monday 20 December 2004 06:04 am, Peter Holm wrote: > On Thu, Dec 16, 2004 at 03:21:44PM -0500, John Baldwin wrote: > > On Monday 06 December 2004 08:59 am, Peter Holm wrote: > > > On Fri, Nov 19, 2004 at 05:10:19PM -0500, John Baldwin wrote: > > > > On Friday 19 November 2004 02:59 am, Peter Holm wrote: > > > > > On Mon, Nov 15, 2004 at 03:46:15PM -0500, John Baldwin wrote: > > > > > > On Friday 12 November 2004 07:33 am, Peter Holm wrote: > > > > > > > GENERIC HEAD from Nov 11 08:05 UTC > > > > > > > > > > > > > > The following stack traces etc. was done before my first > > > > > > > cup of coffee, so it's not so informative as it could have been > > > > > > > :-( > > > > > > > > > > > > > > The test box appeared to have been frozen for more than 6 > > > > > > > hours, but was pingable. > > > > > > > > > > > > > > http://www.holm.cc/stress/log/cons86.html > > > > > > > > > > > > A weak guess is that you have the system in some sort of livelock > > > > > > due to fork()? Have you tried running with 'debug.mpsafevm=1' > > > > > > set from the loader? > > > > > > > > > > > > -- > > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > > > OK, I've got some more info: > > > > > > > > > > http://www.holm.cc/stress/log/cons88.html > > > > > > > > > > Looks like a spin in uma_zone_slab() when slab_zalloc() fails? > > > > > > > > Yes, I think if you specify M_WAITOK, then that might happen. > > > > slab_zalloc() can fail if any of the init functions fail for example, > > > > in which case it would loop forever. You can try this hack (though > > > > it may very well be wrong) to return failure if that is what is > > > > triggering: > > > > > > > > Index: uma_core.c > > > > =================================================================== > > > > RCS file: /usr/cvs/src/sys/vm/uma_core.c,v > > > > retrieving revision 1.110 > > > > diff -u -r1.110 uma_core.c > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > +++ uma_core.c 19 Nov 2004 22:08:26 -0000 > > > > @@ -1998,6 +1998,10 @@ > > > > */ > > > > if (flags & M_NOWAIT) > > > > flags |= M_NOVM; > > > > + > > > > + /* XXXHACK */ > > > > + if (flags & M_WAITOK) > > > > + break; > > > > } > > > > return (slab); > > > > } > > > > > > > > -- > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > I instrumented the code with this: > > > $ cvs diff -u > > > cvs diff: Diffing . > > > Index: uma_core.c > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > > retrieving revision 1.110 > > > diff -u -r1.110 uma_core.c > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > +++ uma_core.c 6 Dec 2004 13:49:36 -0000 > > > @@ -1926,6 +1926,7 @@ > > > { > > > uma_slab_t slab; > > > uma_keg_t keg; > > > + int i; > > > > > > keg = zone->uz_keg; > > > > > > @@ -1943,7 +1944,8 @@ > > > > > > slab = NULL; > > > > > > - for (;;) { > > > + for (i = 0;;i++) { > > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > > /* > > > * Find a slab with some space. Prefer slabs that are > > > partially * used over those that are totally full. This helps to > > > reduce > > > > > > and now during test of Jeff Roberson's "SMP FFS" patch the assert > > > triggered: http://www.holm.cc/stress/log/cons92.html > > > > Hmm. Does the hack patch above make the hang go away or does it just > > break things worse? > > I have been testing your patch for quite a while. If it's OK for > m_getcl with M_TRYWAIT to return NULL, your patch reviled a missing > test for NULL in kern/uipc_socket.c:750 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x1c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0647d77 > stack pointer = 0x10:0xcfa9cbf0 > frame pointer = 0x10:0xcfa9cc38 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 67417 (net) > [thread pid 67417 tid 100890 ] > Stopped at sosend+0x227: movl $0,0x1c(%eax) > db> where > Tracing pid 67417 tid 100890 td 0xc1ae8000 > sosend(c3454dec,0,cfa9cc90,0,0) at sosend+0x227 > soo_write(c1db9374,cfa9cc90,c1aa6180,0,c1ae8000) at > soo_write+0x2d > dofilewrite(3,bfbfe740,400,ffffffff,ffffffff) at dofilewrite+0x99 > write(c1ae8000,cfa9cd14,3,d,246) at write+0x48 > syscall(2f,bfbf002f,bfbf002f,3,bfbfe740) at syscall+0x128 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (4, FreeBSD ELF32, write), eip = 0x280bfbf7, esp = > 0xbfbfe71c, ebp = 0xbfbfeb68 --- Hmm, it looks like M_TRYWAIT isn't allowed to return NULL. Unfortunately, I think my hack basically lets UMA return NULL instead of spinning forever, so it's not that useful. I'm not sure how to really fix this problem in UMA. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 22:33:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46AD816A4CE for ; Mon, 27 Dec 2004 22:33:38 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 3FA4243D53 for ; Mon, 27 Dec 2004 22:33:37 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 50676 invoked from network); 27 Dec 2004 22:33:35 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 27 Dec 2004 22:33:35 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBRMXY0p000800; Mon, 27 Dec 2004 23:33:34 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBRMXYTq000799; Mon, 27 Dec 2004 23:33:34 +0100 (CET) (envelope-from pho) Date: Mon, 27 Dec 2004 23:33:33 +0100 From: Peter Holm To: John Baldwin Message-ID: <20041227223333.GA750@peter.osted.lan> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <20041220110411.GA87750@peter.osted.lan> <200412271705.31625.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412271705.31625.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: bmilekic@FreeBSD.org cc: jeffr@FreeBSD.org cc: jroberson@chesapeake.net Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:33:38 -0000 On Mon, Dec 27, 2004 at 05:05:31PM -0500, John Baldwin wrote: > On Monday 20 December 2004 06:04 am, Peter Holm wrote: > > On Thu, Dec 16, 2004 at 03:21:44PM -0500, John Baldwin wrote: > > > On Monday 06 December 2004 08:59 am, Peter Holm wrote: > > > > On Fri, Nov 19, 2004 at 05:10:19PM -0500, John Baldwin wrote: > > > > > On Friday 19 November 2004 02:59 am, Peter Holm wrote: > > > > > > On Mon, Nov 15, 2004 at 03:46:15PM -0500, John Baldwin wrote: > > > > > > > On Friday 12 November 2004 07:33 am, Peter Holm wrote: > > > > > > > > GENERIC HEAD from Nov 11 08:05 UTC > > > > > > > > > > > > > > > > The following stack traces etc. was done before my first > > > > > > > > cup of coffee, so it's not so informative as it could have been > > > > > > > > :-( > > > > > > > > > > > > > > > > The test box appeared to have been frozen for more than 6 > > > > > > > > hours, but was pingable. > > > > > > > > > > > > > > > > http://www.holm.cc/stress/log/cons86.html > > > > > > > > > > > > > > A weak guess is that you have the system in some sort of livelock > > > > > > > due to fork()? Have you tried running with 'debug.mpsafevm=1' > > > > > > > set from the loader? > > > > > > > > > > > > > > -- > > > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > > > > > OK, I've got some more info: > > > > > > > > > > > > http://www.holm.cc/stress/log/cons88.html > > > > > > > > > > > > Looks like a spin in uma_zone_slab() when slab_zalloc() fails? > > > > > > > > > > Yes, I think if you specify M_WAITOK, then that might happen. > > > > > slab_zalloc() can fail if any of the init functions fail for example, > > > > > in which case it would loop forever. You can try this hack (though > > > > > it may very well be wrong) to return failure if that is what is > > > > > triggering: > > > > > > > > > > Index: uma_core.c > > > > > =================================================================== > > > > > RCS file: /usr/cvs/src/sys/vm/uma_core.c,v > > > > > retrieving revision 1.110 > > > > > diff -u -r1.110 uma_core.c > > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > > +++ uma_core.c 19 Nov 2004 22:08:26 -0000 > > > > > @@ -1998,6 +1998,10 @@ > > > > > */ > > > > > if (flags & M_NOWAIT) > > > > > flags |= M_NOVM; > > > > > + > > > > > + /* XXXHACK */ > > > > > + if (flags & M_WAITOK) > > > > > + break; > > > > > } > > > > > return (slab); > > > > > } > > > > > > > > > > -- > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > I instrumented the code with this: > > > > $ cvs diff -u > > > > cvs diff: Diffing . > > > > Index: uma_core.c > > > > =================================================================== > > > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > > > retrieving revision 1.110 > > > > diff -u -r1.110 uma_core.c > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > +++ uma_core.c 6 Dec 2004 13:49:36 -0000 > > > > @@ -1926,6 +1926,7 @@ > > > > { > > > > uma_slab_t slab; > > > > uma_keg_t keg; > > > > + int i; > > > > > > > > keg = zone->uz_keg; > > > > > > > > @@ -1943,7 +1944,8 @@ > > > > > > > > slab = NULL; > > > > > > > > - for (;;) { > > > > + for (i = 0;;i++) { > > > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > > > /* > > > > * Find a slab with some space. Prefer slabs that are > > > > partially * used over those that are totally full. This helps to > > > > reduce > > > > > > > > and now during test of Jeff Roberson's "SMP FFS" patch the assert > > > > triggered: http://www.holm.cc/stress/log/cons92.html > > > > > > Hmm. Does the hack patch above make the hang go away or does it just > > > break things worse? > > > > I have been testing your patch for quite a while. If it's OK for > > m_getcl with M_TRYWAIT to return NULL, your patch reviled a missing > > test for NULL in kern/uipc_socket.c:750 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x1c > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc0647d77 > > stack pointer = 0x10:0xcfa9cbf0 > > frame pointer = 0x10:0xcfa9cc38 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 67417 (net) > > [thread pid 67417 tid 100890 ] > > Stopped at sosend+0x227: movl $0,0x1c(%eax) > > db> where > > Tracing pid 67417 tid 100890 td 0xc1ae8000 > > sosend(c3454dec,0,cfa9cc90,0,0) at sosend+0x227 > > soo_write(c1db9374,cfa9cc90,c1aa6180,0,c1ae8000) at > > soo_write+0x2d > > dofilewrite(3,bfbfe740,400,ffffffff,ffffffff) at dofilewrite+0x99 > > write(c1ae8000,cfa9cd14,3,d,246) at write+0x48 > > syscall(2f,bfbf002f,bfbf002f,3,bfbfe740) at syscall+0x128 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (4, FreeBSD ELF32, write), eip = 0x280bfbf7, esp = > > 0xbfbfe71c, ebp = 0xbfbfeb68 --- > > Hmm, it looks like M_TRYWAIT isn't allowed to return NULL. Unfortunately, I > think my hack basically lets UMA return NULL instead of spinning forever, so > it's not that useful. I'm not sure how to really fix this problem in UMA. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org I've been testing bmilekic@'s patch for "0+13:56:12", so it's still a bit too early to tell if it fixes the problem. -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 23:59:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3836416A4CE for ; Mon, 27 Dec 2004 23:59:29 +0000 (GMT) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by mx1.FreeBSD.org (Postfix) with SMTP id EBB8F43D39 for ; Mon, 27 Dec 2004 23:59:28 +0000 (GMT) (envelope-from gilham@csl.sri.com) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 27 Dec 2004 23:59:28 -0000 Received: from mx1.csl.sri.com ([130.107.1.29])M2004122715592722019 for ; Mon, 27 Dec 2004 15:59:27 -0800 Received: from snapdragon.csl.sri.com (snapdragon.csl.sri.com [130.107.19.20]) by mx1.csl.sri.com (8.12.11/8.12.11) with ESMTP id iBRNxSja062231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Dec 2004 15:59:28 -0800 (PST) (envelope-from gilham@snapdragon.csl.sri.com) Received: from snapdragon (localhost [127.0.0.1])iBRNxSMv087132 for ; Mon, 27 Dec 2004 15:59:28 -0800 (PST) (envelope-from gilham@snapdragon.csl.sri.com) Message-Id: <200412272359.iBRNxSMv087132@snapdragon.csl.sri.com> To: freebsd-current@freebsd.org Date: Mon, 27 Dec 2004 15:59:28 -0800 From: Fred Gilham Subject: Rio Riot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 23:59:29 -0000 Hello, Is anyone using a Rio Riot player with FreeBSD 5? I have tried installing rioutil and riotware. They both use the libusb port. This uses the ugen interface. Attempts to use either program result in an error that shows up on the console: usbd_setup_pipe: failed to start endpoint, TIMEOUT I'm wondering if anyone at all has gotten this combination to work. -- Fred Gilham gilham@csl.sri.com When trying to reach the lowest common denominator, you have to be prepared for the occasional division by zero. From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 01:09:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E2816A4CE for ; Tue, 28 Dec 2004 01:09:41 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310AB43D48 for ; Tue, 28 Dec 2004 01:09:40 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id D3D726AA01; Tue, 28 Dec 2004 12:09:38 +1100 (EST) Date: Tue, 28 Dec 2004 12:09:38 +1100 From: John Birrell To: current@freebsd.org Message-ID: <20041228010938.GA39686@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: USB problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 01:09:41 -0000 [ I'm not sure who the maintainer for FreeBSD's code is these days. ] I've been encountering a number of problems with the USB implementation in current. Although this message refers to current, I think the problems are in RELENG_5 too. 1. The USB sub-system doesn't handle loading and unloading drivers properly. If a driver is unloaded when a USB device is still attached, the next time the driver is loaded, the kernel panics. This might not be such a problem to normal users because they don't have a need to do that, but during driver development when you want to load and unload repeatedly, it's a pain. 2. I have two devices that are based on Philips' ISP1581 USB 2.0 controller. Both are MPEG encoders and one has a TV tuner. The one without the tuner is Philips' USB-MPEG2 evaluation board which has example firmware on-board as a reference design. It isn't possible to use either of these boards with FreeBSD's USB implementation because of the over-zealous firmware code which stalls the control endpoint at every opportunity. The Windows driver that Philips' supply without source code appears to have no problems talking to the device. When I do the same things with FreeBSD, the continual control endpoint stalls result in not being able to even get the string descriptors for manufacturer and product (the firmware code stalls those requests). I think what is happening is that the uhci (and ehci etc) drivers are detecting the stall and not processing the data that is actually returned with the stall status. When I move the code: if (nstatus & UHCI_TD_ACTIVE) break; in uhci_idone() to the bottom of the loop, it returns the actlen properly (I think). At least I can get the data from the device despite the stall. 3. The usbd_bulk_transfer function calls tsleep() to wait for streaming data to become available. On current, this bumps into a KASSERT in msleep because Giant is not locked and no mutex has been supplied. In my driver, I need to run an 'encoder' thread which calls usbd_bulk_transfer() to gobble the incoming MPEG data stream. While this is going on, there is no syscall in progress because the application is off doing other things. It might be looking at the mmaped buffer or it may not. For FreeBSD, usbd_bulk_transfer() needs to change to allow the driver to specify it's mutex. I don't know what the implications are for uhci given that it hasn't been converted to use mutexes. Can anyone comment on that? Where do we stand making architectural changes to the USB code given the efforts to stay in sync with NetBSD/OpenBSD? I'd love to get rid of the attach_args structure and just pass a usbd_device_handle into the drivers, with struct usbd_device containing a couple of extra variables for use during matching. I'd like to remove the subdevs array from struct usbd_device under FreeBSD because the parent/child device tree should only be managed by bus routines. The relationship between a USB device and it's device_t should just be a field in struct usbd_device and it should be cleared when there is no device_t. Leaving a device_t hanging around when a driver had been unloaded is what is causing the panics I am seeing. I think that the uhub driver should have a uhub_driver_added routine rather than using the generic one. I'd really like to see the uhub code re-match vendor/product codes when a new driver is added, and if the new driver matches, then uhub should detach ugen and use the new driver. Similarly, when a driver is unloaded, if a USB device is still present, it should go back to ugen. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 02:34:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A851E16A4CE for ; Tue, 28 Dec 2004 02:34:39 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E5DA43D53 for ; Tue, 28 Dec 2004 02:34:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 32BBE7A425; Mon, 27 Dec 2004 18:34:39 -0800 (PST) Message-ID: <41D0C63F.3000702@elischer.org> Date: Mon, 27 Dec 2004 18:34:39 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Birrell References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> In-Reply-To: <20041228010938.GA39686@freebsd3.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: USB problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 02:34:39 -0000 John Birrell wrote: >[ I'm not sure who the maintainer for FreeBSD's code is these days. ] > It's a consortium of time strapped people who have lots of other stuff to do :-) > >I've been encountering a number of problems with the USB implementation >in current. Although this message refers to current, I think the problems >are in RELENG_5 too. > >1. The USB sub-system doesn't handle loading and unloading drivers properly. > If a driver is unloaded when a USB device is still attached, the next > time the driver is loaded, the kernel panics. This might not be such > a problem to normal users because they don't have a need to do that, but > during driver development when you want to load and unload repeatedly, > it's a pain. > One would think it would refuse to unload if it was still in use.. possibly one for imp.. he's doing stuff in that part at the moment I think. > >2. I have two devices that are based on Philips' ISP1581 USB 2.0 controller. > Both are MPEG encoders and one has a TV tuner. The one without the > tuner is Philips' USB-MPEG2 evaluation board which has example firmware > on-board as a reference design. It isn't possible to use either of these > boards with FreeBSD's USB implementation because of the over-zealous > firmware code which stalls the control endpoint at every opportunity. > can you be a bi tmore explicit abuot what you mena by "stalls the control endpoint at every opportunity". The linux libusb has code in its' timeout code that "unstalls" endpoints if they timeout. I p[resume becasue they have seen this as a common reason for timeouts. FreeBSD issues teh same command on endpoint open.. try closing and reopenning the endpoint. > The Windows driver that Philips' supply without source code appears to > have no problems talking to the device. When I do the same things with > FreeBSD, the continual control endpoint stalls result in not being > able to even get the string descriptors for manufacturer and product > (the firmware code stalls those requests). > > > I think what is happening is that the uhci (and ehci etc) drivers are > detecting the stall and not processing the data that is actually > returned with the stall status. When I move the code: hmm I'll have to look at the spec to see if a stall status can come back with data? There are two 'stalls'.. the endpoint stalls, and the local status word reflects that. (at least in EHCI), so you'd need to clear both.. one with a write and teh other with a memory write.. > if (nstatus & UHCI_TD_ACTIVE) > break; > >> in uhci_idone() to the bottom of the loop, it returns the actlen > properly (I think). At least I can get the data from the device despite > the stall. can it then proceed? >3. The usbd_bulk_transfer function calls tsleep() to wait for streaming > data to become available. On current, this bumps into a KASSERT in > msleep because Giant is not locked and no mutex has been supplied. > In my driver, I need to run an 'encoder' thread which calls > usbd_bulk_transfer() to gobble the incoming MPEG data stream. While > this is going on, there is no syscall in progress because the > application is off doing other things. It might be looking at the > mmaped buffer or it may not. > > For FreeBSD, usbd_bulk_transfer() needs to change to allow the driver > to specify it's mutex. I don't know what the implications are for > uhci given that it hasn't been converted to use mutexes. Can anyone > comment on that? > Where do we stand making architectural changes to the USB code given the > efforts to stay in sync with NetBSD/OpenBSD? I'm trying to address that issue right now.. If we can't bring netBSD withus in some architectural changes than at some stage we'll have to go it ourselves. Which I'd rather not do.. but they are hard to contact.. (probably also short of time) > > I'd love to get rid of the attach_args structure and just pass a > usbd_device_handle into the drivers, with struct usbd_device containing > a couple of extra variables for use during matching. sure.. there are a number of architectural changes "in the wings" that I'd like ot thrash out with the NetBSD guys but I have found it hard to find a forum to communicate with tehm on.. the suggestion "send a NetBSD PR" is the best I've got back so far.. Though they have seemed friendly enough. > > I'd like to remove the subdevs array from struct usbd_device under > FreeBSD because the parent/child device tree should only be managed by > bus routines. The relationship between a USB device and it's device_t > should just be a field in struct usbd_device and it should be cleared > when there is no device_t. Leaving a device_t hanging around when a > driver had been unloaded is what is causing the panics I am seeing. talk to imp@ > > I think that the uhub driver should have a uhub_driver_added routine rather > than using the generic one. I'd really like to see the uhub code re-match > vendor/product codes when a new driver is added, and if the new driver > matches, then uhub should detach ugen and use the new driver. Similarly, > when a driver is unloaded, if a USB device is still present, it should go > back to ugen. yes yes yes etc. > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 03:54:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 889C716A4CE for ; Tue, 28 Dec 2004 03:54:36 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB1043D31 for ; Tue, 28 Dec 2004 03:54:36 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so269839rne for ; Mon, 27 Dec 2004 19:54:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Rg/+0CrTFz/fLwSJkNs0G+hllGnJkpMNdI2ozUqt0ulAO+uHmz6U0ZB/yLBEtuJMoEwhWn2QwulIOWi1Sw0y4GZmPzL0D4qbT7MetkW5w9EkHGl5zonYCbxxJBAx8bUxtpjlMc6KdaOLnsuv09Iv7LNV0I11eAKxgniPYus4cn0= Received: by 10.38.73.46 with SMTP id v46mr218453rna; Mon, 27 Dec 2004 19:54:32 -0800 (PST) Received: by 10.38.22.72 with HTTP; Mon, 27 Dec 2004 19:54:32 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 11:54:32 +0800 From: Mikore Li To: Hendrik Hasenbein In-Reply-To: <41D013BA.2010107@techfak.uni-bielefeld.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_394_5834466.1104206072427" References: <41D013BA.2010107@techfak.uni-bielefeld.de> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-current@freebsd.org Subject: Re: ndis wrapper can't work on ferrari 3400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 03:54:36 -0000 ------=_Part_394_5834466.1104206072427 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 27 Dec 2004 14:52:58 +0100, Hendrik Hasenbein wrote: > Mikore Li wrote: > > Hi, > > > > My ferrari 3400 using broadcom 4320 802.11 b/g card. I successfully installed > > freebsd 5.3-release(i386) on it, but when I kldload if_ndis, it panic > > and hang my > > laptop, although some card information has been display out. > > > > Is there anyone make it work successfully? > > I got an non-Ferrari Aspire with almost identical hardware, but the > driver wont find the hardware. How did you configure your ACPI? > > Hendrik > > > Hi, Hendrik, I don't configure ACPI on ferrari 3400. Here is my dmesg after it boot up: (Attachment) Thanks Mikore ------=_Part_394_5834466.1104206072427-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 04:33:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D289E16A4CE; Tue, 28 Dec 2004 04:33:32 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5041043D39; Tue, 28 Dec 2004 04:33:32 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBS4XRbF097507; Mon, 27 Dec 2004 23:33:27 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBS4XRWG097506; Mon, 27 Dec 2004 23:33:27 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 27 Dec 2004 23:33:27 -0500 From: Bosko Milekic To: John Baldwin Message-ID: <20041228043327.GA96744@technokratis.com> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <20041220110411.GA87750@peter.osted.lan> <200412271705.31625.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412271705.31625.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: jeffr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 04:33:33 -0000 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current (and see previous in thread for context). Let's hope. -Bosko On Mon, Dec 27, 2004 at 05:05:31PM -0500, John Baldwin wrote: > On Monday 20 December 2004 06:04 am, Peter Holm wrote: > > On Thu, Dec 16, 2004 at 03:21:44PM -0500, John Baldwin wrote: > > > On Monday 06 December 2004 08:59 am, Peter Holm wrote: > > > > On Fri, Nov 19, 2004 at 05:10:19PM -0500, John Baldwin wrote: > > > > > On Friday 19 November 2004 02:59 am, Peter Holm wrote: > > > > > > On Mon, Nov 15, 2004 at 03:46:15PM -0500, John Baldwin wrote: > > > > > > > On Friday 12 November 2004 07:33 am, Peter Holm wrote: > > > > > > > > GENERIC HEAD from Nov 11 08:05 UTC > > > > > > > > > > > > > > > > The following stack traces etc. was done before my first > > > > > > > > cup of coffee, so it's not so informative as it could have been > > > > > > > > :-( > > > > > > > > > > > > > > > > The test box appeared to have been frozen for more than 6 > > > > > > > > hours, but was pingable. > > > > > > > > > > > > > > > > http://www.holm.cc/stress/log/cons86.html > > > > > > > > > > > > > > A weak guess is that you have the system in some sort of livelock > > > > > > > due to fork()? Have you tried running with 'debug.mpsafevm=1' > > > > > > > set from the loader? > > > > > > > > > > > > > > -- > > > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > > > > > OK, I've got some more info: > > > > > > > > > > > > http://www.holm.cc/stress/log/cons88.html > > > > > > > > > > > > Looks like a spin in uma_zone_slab() when slab_zalloc() fails? > > > > > > > > > > Yes, I think if you specify M_WAITOK, then that might happen. > > > > > slab_zalloc() can fail if any of the init functions fail for example, > > > > > in which case it would loop forever. You can try this hack (though > > > > > it may very well be wrong) to return failure if that is what is > > > > > triggering: > > > > > > > > > > Index: uma_core.c > > > > > =================================================================== > > > > > RCS file: /usr/cvs/src/sys/vm/uma_core.c,v > > > > > retrieving revision 1.110 > > > > > diff -u -r1.110 uma_core.c > > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > > +++ uma_core.c 19 Nov 2004 22:08:26 -0000 > > > > > @@ -1998,6 +1998,10 @@ > > > > > */ > > > > > if (flags & M_NOWAIT) > > > > > flags |= M_NOVM; > > > > > + > > > > > + /* XXXHACK */ > > > > > + if (flags & M_WAITOK) > > > > > + break; > > > > > } > > > > > return (slab); > > > > > } > > > > > > > > > > -- > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > I instrumented the code with this: > > > > $ cvs diff -u > > > > cvs diff: Diffing . > > > > Index: uma_core.c > > > > =================================================================== > > > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > > > retrieving revision 1.110 > > > > diff -u -r1.110 uma_core.c > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > +++ uma_core.c 6 Dec 2004 13:49:36 -0000 > > > > @@ -1926,6 +1926,7 @@ > > > > { > > > > uma_slab_t slab; > > > > uma_keg_t keg; > > > > + int i; > > > > > > > > keg = zone->uz_keg; > > > > > > > > @@ -1943,7 +1944,8 @@ > > > > > > > > slab = NULL; > > > > > > > > - for (;;) { > > > > + for (i = 0;;i++) { > > > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > > > /* > > > > * Find a slab with some space. Prefer slabs that are > > > > partially * used over those that are totally full. This helps to > > > > reduce > > > > > > > > and now during test of Jeff Roberson's "SMP FFS" patch the assert > > > > triggered: http://www.holm.cc/stress/log/cons92.html > > > > > > Hmm. Does the hack patch above make the hang go away or does it just > > > break things worse? > > > > I have been testing your patch for quite a while. If it's OK for > > m_getcl with M_TRYWAIT to return NULL, your patch reviled a missing > > test for NULL in kern/uipc_socket.c:750 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x1c > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc0647d77 > > stack pointer = 0x10:0xcfa9cbf0 > > frame pointer = 0x10:0xcfa9cc38 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 67417 (net) > > [thread pid 67417 tid 100890 ] > > Stopped at sosend+0x227: movl $0,0x1c(%eax) > > db> where > > Tracing pid 67417 tid 100890 td 0xc1ae8000 > > sosend(c3454dec,0,cfa9cc90,0,0) at sosend+0x227 > > soo_write(c1db9374,cfa9cc90,c1aa6180,0,c1ae8000) at > > soo_write+0x2d > > dofilewrite(3,bfbfe740,400,ffffffff,ffffffff) at dofilewrite+0x99 > > write(c1ae8000,cfa9cd14,3,d,246) at write+0x48 > > syscall(2f,bfbf002f,bfbf002f,3,bfbfe740) at syscall+0x128 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (4, FreeBSD ELF32, write), eip = 0x280bfbf7, esp = > > 0xbfbfe71c, ebp = 0xbfbfeb68 --- > > Hmm, it looks like M_TRYWAIT isn't allowed to return NULL. Unfortunately, I > think my hack basically lets UMA return NULL instead of spinning forever, so > it's not that useful. I'm not sure how to really fix this problem in UMA. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 05:37:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B71016A4CE for ; Tue, 28 Dec 2004 05:37:48 +0000 (GMT) Received: from mimoza.pantel.net (mimoza.pantel.net [212.24.191.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F75E43D5F for ; Tue, 28 Dec 2004 05:37:48 +0000 (GMT) (envelope-from arutz@mimoza.pantel.net) Received: by mimoza.pantel.net (Postfix, from userid 1000) id C922F12059; Tue, 28 Dec 2004 06:37:46 +0100 (CET) Date: Tue, 28 Dec 2004 06:37:46 +0100 From: Antal Rutz To: current@freebsd.org Message-ID: <20041228053746.GA96544@mimoza.pantel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: firefox makes faster net.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 05:37:48 -0000 Environment: 5.3-stable (26th Dec), KDE 3.3.1, firefox-1.0_3,1, aironet 350 pcmcia card with 1M/s dsl connection. (the same with debug.mpsafevm=(0|1) ) Strange things: when I ftp(scp or cvsup) some files the net is used around 80%, but when I launch firefox I can use the full bandwidth. I couldn't believe it but it also negatively affects net performance when I minimize the firefox window... hm. -- --rutz From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 06:21:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE3A216A4CE for ; Tue, 28 Dec 2004 06:21:44 +0000 (GMT) Received: from starlite.ispworkshop.com (starlite.ispworkshop.com [202.73.37.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 4945C43D39 for ; Tue, 28 Dec 2004 06:21:43 +0000 (GMT) (envelope-from ongbh@ispworkshop.com) Received: (qmail 18035 invoked from network); 28 Dec 2004 06:21:41 -0000 Received: from cm168.omega0.maxonline.com.sg (HELO ?192.168.10.100?) (218.186.0.168) by starlite.ispworkshop.com with SMTP; 28 Dec 2004 06:21:41 -0000 Message-ID: <41D0FB74.2000901@ispworkshop.com> Date: Tue, 28 Dec 2004 14:21:40 +0800 From: Ong Beng Hui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 06:21:45 -0000 Hi, Looking thru the FreeBSD handbook... http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html and Advanced Networking... http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/advanced-networking.html Under Building a Router, it said... "Even when FreeBSD is configured in this way, it does not completely comply with the Internet standard requirements for routers. It comes close enough for ordinary use, however." Could someone advise, in what way FreeBSD doesn't comply with Internet standard requirements for routers ? Which internet standard it might be referencing to. Thanks. From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 07:48:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 058A316A4CE for ; Tue, 28 Dec 2004 07:48:03 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FAC943D48 for ; Tue, 28 Dec 2004 07:48:02 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so282014rne for ; Mon, 27 Dec 2004 23:48:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EALJCxy0/JXJ5lrNryv3ASDvu89e9bbOzmnls4tJuCzDI6W4HkPxxhYzyAx4OEZCDvbiUAv5LwM0p9vYNB+ILyGZFl1c2+RfpbbKqnpCV842Q56OmQdlvwgOlD7poMzcB/KPEU8mVtBJnIF2NvJIZ3fdOV+fCx+Xxa7lrT/nf/U= Received: by 10.38.98.7 with SMTP id v7mr26443rnb; Mon, 27 Dec 2004 23:48:01 -0800 (PST) Received: by 10.38.22.72 with HTTP; Mon, 27 Dec 2004 23:48:01 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 15:48:01 +0800 From: Mikore Li To: Hendrik Hasenbein In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41D013BA.2010107@techfak.uni-bielefeld.de> cc: freebsd-current@freebsd.org Subject: Re: ndis wrapper can't work on ferrari 3400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 07:48:03 -0000 Today, I reinstall freebsd5.3(i386), if using defaul option boot from CD, it will reboot and can't install system. While after I boot without ACPI enable, I can then install system on my ferrari !! Mikore On Tue, 28 Dec 2004 11:54:32 +0800, Mikore Li wrote: > On Mon, 27 Dec 2004 14:52:58 +0100, Hendrik Hasenbein > wrote: > > Mikore Li wrote: > > > Hi, > > > > > > My ferrari 3400 using broadcom 4320 802.11 b/g card. I successfully installed > > > freebsd 5.3-release(i386) on it, but when I kldload if_ndis, it panic > > > and hang my > > > laptop, although some card information has been display out. > > > > > > Is there anyone make it work successfully? > > > > I got an non-Ferrari Aspire with almost identical hardware, but the > > driver wont find the hardware. How did you configure your ACPI? > > > > Hendrik > > > > > > > Hi, Hendrik, > > I don't configure ACPI on ferrari 3400. Here is my dmesg after it boot up: > (Attachment) > > Thanks > Mikore > > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 08:23:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 249F516A4CE for ; Tue, 28 Dec 2004 08:23:08 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id B660943D49 for ; Tue, 28 Dec 2004 08:23:07 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so283848rne for ; Tue, 28 Dec 2004 00:23:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YFMuLt2/hQObT9GClCbs3Zwz2CmdjQD4ACW6dqWelAZ2pwp0peD/QTW4/hYCE6X4EJBSuF2URXEBxqrVZ6B5GOR9tSqmo/Wm965wsGgekKnarrncZjYCWE5k8N/Bs/Pudm8l2jHqCpkjjYEMacXuYX4PvcF6gKfKWVkHUtRMaqI= Received: by 10.38.155.16 with SMTP id c16mr34987rne; Tue, 28 Dec 2004 00:23:07 -0800 (PST) Received: by 10.38.22.72 with HTTP; Tue, 28 Dec 2004 00:23:07 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 16:23:07 +0800 From: Mikore Li To: Hendrik Hasenbein In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41D013BA.2010107@techfak.uni-bielefeld.de> cc: freebsd-current@freebsd.org Subject: Re: ndis wrapper can't work on ferrari 3400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 08:23:08 -0000 Please forget my last mail. I make mistake and installed build for amd64 not i386. After reinstall a real i386 system, everything is ok, and dell truemobile 1300 card work!! BTW, the source code is in the CD while yesterday, I use a old version. Thanks Mikore On Tue, 28 Dec 2004 15:48:01 +0800, Mikore Li wrote: > Today, > I reinstall freebsd5.3(i386), if using defaul option boot from CD, it > will reboot and can't > install system. While after I boot without ACPI enable, I can then > install system on my > ferrari !! > > Mikore > > > On Tue, 28 Dec 2004 11:54:32 +0800, Mikore Li wrote: > > On Mon, 27 Dec 2004 14:52:58 +0100, Hendrik Hasenbein > > wrote: > > > Mikore Li wrote: > > > > Hi, > > > > > > > > My ferrari 3400 using broadcom 4320 802.11 b/g card. I successfully installed > > > > freebsd 5.3-release(i386) on it, but when I kldload if_ndis, it panic > > > > and hang my > > > > laptop, although some card information has been display out. > > > > > > > > Is there anyone make it work successfully? > > > > > > I got an non-Ferrari Aspire with almost identical hardware, but the > > > driver wont find the hardware. How did you configure your ACPI? > > > > > > Hendrik > > > > > > > > > > > Hi, Hendrik, > > > > I don't configure ACPI on ferrari 3400. Here is my dmesg after it boot up: > > (Attachment) > > > > Thanks > > Mikore > > > > > > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 08:47:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06E1F16A4CE for ; Tue, 28 Dec 2004 08:47:39 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 528E543D53 for ; Tue, 28 Dec 2004 08:47:38 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 7038 invoked from network); 28 Dec 2004 08:47:37 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 28 Dec 2004 08:47:37 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBS8lahR006647; Tue, 28 Dec 2004 09:47:36 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBS8lVe4006646; Tue, 28 Dec 2004 09:47:31 +0100 (CET) (envelope-from pho) Date: Tue, 28 Dec 2004 09:47:31 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041228084731.GA766@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <20041227040216.GA44588@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041227040216.GA44588@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 08:47:39 -0000 On Sun, Dec 26, 2004 at 11:02:16PM -0500, Bosko Milekic wrote: > > > I'll have to reserve some more time to think about this. One way I > > think it might be solvable would be to change that check that > > triggers the NULL return explicitly check for the bucketzone, and not > > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > > more. > > Please try the attached patch and let me know if with it you can or > cannot trigger the original (seemingly infinite) looping. Although I > still haven't quite figured out how the described scenario could lead > to infinite looping exactly (I did conclude that it could lead to some > looping, though), the patch is worth trying as I believe the scenario > *could* occur. > After more than 18 hours of testing with your patch I ran into a (unrelated ?) "panic: mutex vm object not owned": http://www.holm.cc/stress/log/freeze06.html > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org > Index: uma_core.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > retrieving revision 1.111 > diff -u -r1.111 uma_core.c > --- uma_core.c 26 Dec 2004 00:35:12 -0000 1.111 > +++ uma_core.c 27 Dec 2004 03:58:25 -0000 > @@ -1939,9 +1939,19 @@ > * buckets there too we will recurse in kmem_alloc and bad > * things happen. So instead we return a NULL bucket, and make > * the code that allocates buckets smart enough to deal with it > + * > + * XXX: While we want this protection for the bucket zones so that > + * recursion from the VM is handled (and the calling code that > + * allocates buckets knows how to deal with it), we do not want > + * to prevent allocation from the slab header zones (slabzone > + * and slabrefzone) if uk_recurse is not zero for them. The > + * reason is that it could lead to NULL being returned for > + * slab header allocations even in the M_WAITOK case, and the > + * caller can't handle that. > */ > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) > - return (NULL); > + if ((zone != slabzone) && (zone != slabrefzone)) > + return (NULL); > > slab = NULL; > -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 11:06:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D88B516A4CE; Tue, 28 Dec 2004 11:06:49 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D131643D31; Tue, 28 Dec 2004 11:06:48 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSB6bm7008869; Tue, 28 Dec 2004 13:06:37 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 37033-13; Tue, 28 Dec 2004 13:06:35 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSB6Znb008863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Dec 2004 13:06:35 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBSB6i7A017290; Tue, 28 Dec 2004 13:06:44 +0200 (EET) (envelope-from ru) Date: Tue, 28 Dec 2004 13:06:44 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041228110644.GB14010@ip.net.ua> References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <41D03AA4.3020908@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 11:06:50 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 27, 2004 at 05:39:00PM +0100, S?ren Schmidt wrote: > Ruslan Ermilov wrote: >=20 > >>Hmm, on the exact same controller with two SATA drives on it and stock= =20 > >>current it "just works" (tm) here, I cannot reproduce the problem... > >>Are you sure its a stock GENERIC kernel with no local mods/patches ? > >> > >Yes. This is the Asus SK8N motherboard, but I only have one PATA > >drive attached to 3rd (PATA) channel; first two channels (SATA) > >don't have any drives attached. Can you check in this configuration? >=20 >=20 > atapci0: port=20 > 0xb800-0xb87f,0xd000-0xd00f,0xd400-0xd43f mem=20 > 0xfc800000-0xfc81ffff,0xfd000000-0xfd000fff irq 18 at device 5.0 on pci0 > atapci0: failed: rid 0x20 is memory, requested 4 > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 > ata4: channel #2 on atapci0 > ... > atapci1: port=20 > 0xb000-0xb00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 > ata0: channel #0 on atapci1 > ata1: channel #1 on atapci1 > ... > ad0: 13042MB [26500/16/63] at ata0-master UDMA= 33 > acd0: DVDRAM at ata0-slave PIO4 > afd0: REMOVABLE at ata1-master PIO3 > acd1: CDRW at ata1-slave PIO4 > ad1: 38166MB [77545/16/63] at ata4-master UDMA100 >=20 > That works just as well... >=20 OK, but the fact is that if I revert sys/dev/ata/ to just before this change, with otherwise -CURRENT sources (except for keeping atapi-cd.c at its current version), it all works perfectly again. : sos 2004-12-08 10:02:41 UTC : : FreeBSD src repository : : Modified files: : sys/dev/ata ata-chipset.c ata-pci.h : Log: : Add first shot on support for the new Promise SATAII chips. : : HW donated by: pil.dk : : Revision Changes Path : 1.93 +109 -49 src/sys/dev/ata/ata-chipset.c : 1.36 +10 -2 src/sys/dev/ata/ata-pci.h So I analyzed what was changed in this ata-chipset.c revision when it comes to my chip, and tried the following patch, and it brought me back my ad8 drive: %%% Index: ata-chipset.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.97 diff -u -p -r1.97 ata-chipset.c --- ata-chipset.c 24 Dec 2004 13:36:04 -0000 1.97 +++ ata-chipset.c 28 Dec 2004 10:59:06 -0000 @@ -1607,7 +1607,7 @@ ata_promise_mio_reset(struct ata_channel (ATA_INL(ctlr->r_res2, 0xc012c) & ~0x00000f9f)); mtx_unlock(&hpktp->mtx); } - else if (ctlr->chip->cfg2 & PRSATA) { + else if (ctlr->chip->cfg2 & (PRSATA | PRCMBO)) { u_int32_t status =3D 0; int timeout; =20 %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0T5EqRfpzJluFF4RAtnQAJ4uLQba1W5ijzm1uTXK8v364uCI+QCgisYZ CUNMPFi5Uk1gJNtwSurhc7k= =uyTT -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 12:50:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FF8416A4CE; Tue, 28 Dec 2004 12:50:03 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F5943D54; Tue, 28 Dec 2004 12:50:02 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBSCnvak071262; Tue, 28 Dec 2004 13:49:59 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41D15650.7080504@DeepCore.dk> Date: Tue, 28 Dec 2004 13:49:20 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> In-Reply-To: <20041228110644.GB14010@ip.net.ua> Content-Type: multipart/mixed; boundary="------------000403030802040804010706" X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 12:50:03 -0000 This is a multi-part message in MIME format. --------------000403030802040804010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ruslan Ermilov wrote: > So I analyzed what was changed in this ata-chipset.c revision > when it comes to my chip, and tried the following patch, and > it brought me back my ad8 drive: Hmm, there are grimlins in there alright. Could you try the attached=20 patch as thats what I have in my WIP and it cleans up the code a bit as=20 well.. --=20 -S=F8ren --------------000403030802040804010706 Content-Type: text/plain; name="promdiff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="promdiff" Index: ata-chipset.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.97 diff -u -r1.97 ata-chipset.c --- ata-chipset.c 24 Dec 2004 13:36:04 -0000 1.97 +++ ata-chipset.c 28 Dec 2004 12:47:10 -0000 @@ -1367,6 +1367,11 @@ return ENXIO; } + if (ctlr->chip->max_dma >= ATA_SA150) + ctlr->setmode = ata_sata_setmode; + else + ctlr->setmode = ata_promise_setmode; + switch (ctlr->chip->cfg1) { case PRNEW: /* setup clocks */ @@ -1413,22 +1418,33 @@ ctlr->dmainit = ata_promise_mio_dmainit; ctlr->allocate = ata_promise_mio_allocate; - if (ctlr->chip->cfg2 & PRPATA) { - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + - ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; - } - else if (ctlr->chip->cfg2 & PRCMBO) { - ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; - } - else if (ctlr->chip->cfg2 & PRCMBO2) { - ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); - ctlr->channels = 3; - } - else - ctlr->channels = 4; + switch (ctlr->chip->cfg2) { + case PRPATA: + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + + ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; + break; - if (ctlr->chip->cfg2 & PRSX4X) { + case PRCMBO: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; + break; + + case PRSATA: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = 4; + break; + + case PRCMBO2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 3; + break; + + case PRSATA2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 4; + break; + + case PRSX4X: { struct ata_promise_sx4 *hpkt; u_int32_t dimm = ATA_INL(ctlr->r_res2, 0x000c0080); @@ -1448,26 +1464,25 @@ mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); hpkt->busy = hpkt->head = hpkt->tail = 0; + ctlr->channels = 4; + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, ata_promise_sx4_intr, ctlr, &ctlr->handle))) { device_printf(dev, "unable to setup interrupt\n"); return ENXIO; } - } - else { - if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, - ata_promise_mio_intr, ctlr, &ctlr->handle))) { - device_printf(dev, "unable to setup interrupt\n"); - return ENXIO; + return 0; } } - break; + + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, + ata_promise_mio_intr, ctlr, &ctlr->handle))) { + device_printf(dev, "unable to setup interrupt\n"); + return ENXIO; + } + return 0; } - if (ctlr->chip->max_dma >= ATA_SA150) - ctlr->setmode = ata_sata_setmode; - else - ctlr->setmode = ata_promise_setmode; - return 0; + return ENXIO; } static int --------------000403030802040804010706-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 18:00:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD9F16A4CE for ; Mon, 27 Dec 2004 18:00:32 +0000 (GMT) Received: from imo-m26.mx.aol.com (imo-m26.mx.aol.com [64.12.137.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBD4A43D49 for ; Mon, 27 Dec 2004 18:00:31 +0000 (GMT) (envelope-from Smcmillan1967@aol.com) Received: from Smcmillan1967@aol.com by imo-m26.mx.aol.com (mail_out_v37_r3.8.) id n.1a3.2d0162df (25508) for ; Mon, 27 Dec 2004 13:00:27 -0500 (EST) From: Smcmillan1967@aol.com Message-ID: <1a3.2d0162df.2f01a7ba@aol.com> Date: Mon, 27 Dec 2004 13:00:26 EST To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: 9.0 for Windows sub 5033 X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Sound stopped working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 18:00:32 -0000 Our sound stopped working on our PS2, can you tell me what the problem could be? Thank you From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 01:27:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 572C116A4CE for ; Tue, 28 Dec 2004 01:27:07 +0000 (GMT) Received: from infor.ck.tp.edu.tw (infor.ck.tp.edu.tw [203.64.26.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1543743D49 for ; Tue, 28 Dec 2004 01:27:07 +0000 (GMT) (envelope-from llwang@infor.ck.tp.edu.tw) Received: by infor.ck.tp.edu.tw (Postfix, from userid 1001) id 4AE612DA780; Tue, 28 Dec 2004 09:27:05 +0800 (CST) Date: Tue, 28 Dec 2004 09:27:05 +0800 From: "Li-Lun Wang (Leland Wang)" To: freebsd-current@freebsd.org Message-ID: <20041228012705.GA89824@Athena.infor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 01:27:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have been having a similar problem for quite a while on 5.3 on my X31. I am not sure about 5.2.1. If if_fxp is compiled into the kernel or if the first module I load after I boot is if_fxp.ko, there is no problem. If I enter X window (and thus load radeon.ko) before I load if_fxp.ko, I always have the mismatch. Sometimes the problem goes away when I reload the kernel module, and sometimes I have to reboot the system in order to attach my fxp. I am quite sure I had not had the problem sometime earlier on 5.2. - -- Leland Wang -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0LZmCQM7t5B2mhARAkp/AJ427NA2vhn86fmoMlnR8GrqWSVOagCZARvd Jhr4/UtGzk9SHnTwgruKpcU= =izkU -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 02:27:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F170A16A4CE; Tue, 28 Dec 2004 02:27:37 +0000 (GMT) Received: from diligence.flag.rootnode.com (adsl-65-67-81-98.dsl.ltrkar.swbell.net [65.67.81.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DEC943D46; Tue, 28 Dec 2004 02:27:37 +0000 (GMT) (envelope-from joe@osoft.us) Received: from [10.0.1.105] (coherence.flag.rootnode.com [10.0.1.105]) by diligence.flag.rootnode.com (Postfix) with ESMTP id 95AD7D4BA; Mon, 27 Dec 2004 20:27:36 -0600 (CST) Message-ID: <41D0C51D.8020800@osoft.us> Date: Mon, 27 Dec 2004 20:29:49 -0600 From: Joe Koberg User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Zsolt_K=FAti?= References: <20041209183911.068c9a84.kutizs@axelero.hu> In-Reply-To: <20041209183911.068c9a84.kutizs@axelero.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 02:27:38 -0000 Zsolt Kњti wrote: >My system produces these messages that I already know well from this >list (as well ;): >ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=213249674 > > Like many people I was confronted with "TIMEOUT - READ_DMA" and "TIMEOUT - WRITE_DMA" errors on my drives. I was frustrated. But I found a workaround: Turning off ACPI. I just received a Highpoint RocketRaid 1640 controller, 2 Maxtor 300GB drives, and a Supermicro 5-drive SATA cage. I am testing this configuration for a storage server. I am using an old motherboard, DTK brand, Slot 1. 300A Celeron. Under a fresh install of 5.3-RELEASE I am unable to read or write both drives heavily at the same time. One drive alone seems to work OK. When I run dd blasting both drives with seqential IO, I get TIMEOUT - WRITE(READ)_DMA. Repeatably, within 15 seconds. However I got a good test before I installed 5.3-R, the box was running with 5.3-BETA. Only difference was I booted without ACPI. So I rebooted the freshly installed 5.3-R without ACPI, and It works! I can read at 50MB/s per drive concurrently (hitting PCI bus speed limit?), and write at 30MB/s per drive concurrently. No errors so far, and its been dd'ing for a half hour. I hope this report helps someone! Joe Koberg joe at osoft dot us dmesg: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (307.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 402587648 (383 MB) avail memory = 384270336 (366 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb000-0xb01f irq 10 at device 7.2 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 ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. pci0: at device 7.3 (no driver attached) atapci1: port 0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07,0xb800-0xb803,0xb400-0xb407 irq 11 at device 17.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 atapci2: port 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007,0xcc00-0xcc03,0xc800-0xc807 irq 11 at device 17.1 on pci0 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 dc0: port 0xdc00-0xdcff mem 0xec000000-0xec0003ff irq 12 at device 18.0 on pci0 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:04:5a:56:80:76 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] pci0: at device 19.0 (no driver attached) cpu0 on motherboard orm0: at iomem 0xcc000-0xcdfff,0xc0000-0xc8fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 307842170 Hz quality 800 Timecounters tick every 10.000 msec ad0: 43979MB [89355/16/63] at ata0-master UDMA33 ad4: 286188MB [581463/16/63] at ata2-master UDMA133 ad6: 286188MB [581463/16/63] at ata3-master UDMA133 Mounting root from ufs:/dev/ad0s1a >After these messages the two former cases result in FAILURE and finally >in panic. Even background fsck cannot run without another panic, only >single user mode can help. All these prevent using them on my HW. >However B7, although displays the messages as well, works seemingly >fine. For the time being this version is sufficent, but I'd like to >know - if possible at all - what the difference could be between the >versions and if one can expect to bring the actual 5.3 version's >state to B7's in this respect? > >Further to this, the different versions display the behavior of >relatively frequently (many time in an hour?) stalling their >responsivity for some seconds. Most of the times no message can be seen >on the consol after this. It is also more rare on B7. > >I also found that pendrive's sensing by 5.3 RELEASE/STABLE more >frequently results in panic than B7's. (As a matter of fact I have not >seen it with B7 for weeks since I installed it.) > >I use the following either with GENERIC or custom kernel: >Abit NF7-S (nVidia chipsets, SiI3112 on board), Athlon 2600+, >Samsung 120G SATA, LEXAR MEDIA JUMPDRIVE, rev 1.10/0.01 > > >Please cc it to me as well, since I'am not on the list for the time >being. >Many thanks! > >Zsolt > >-------------------- >Zsolt Kuti >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 02:47:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8473E16A4E1; Tue, 28 Dec 2004 02:47:01 +0000 (GMT) Received: from hotmail.com (bay103-dav4.bay103.hotmail.com [65.54.174.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5DA643D53; Tue, 28 Dec 2004 02:47:00 +0000 (GMT) (envelope-from whitevamp47@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Dec 2004 18:47:00 -0800 Message-ID: Received: from 65.102.125.195 by BAY103-DAV4.phx.gbl with DAV; Tue, 28 Dec 2004 02:46:34 +0000 X-Originating-IP: [65.102.125.195] X-Originating-Email: [whitevamp47@hotmail.com] X-Sender: whitevamp47@hotmail.com From: "whitevamp" To: "Joe Koberg" , =?iso-8859-1?Q?Zsolt_K=FAti?= References: <20041209183911.068c9a84.kutizs@axelero.hu> <41D0C51D.8020800@osoft.us> Date: Mon, 27 Dec 2004 18:46:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 28 Dec 2004 02:47:00.0574 (UTC) FILETIME=[8135BFE0:01C4EC87] X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 02:47:01 -0000 ----- Original Message ----- From: "Joe Koberg" To: "Zsolt Kњti" Cc: ; Sent: Monday, December 27, 2004 6:29 PM Subject: Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI > Zsolt Kњti wrote: > > >My system produces these messages that I already know well from this > >list (as well ;): > >ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=213249674 > > > > > Like many people I was confronted with "TIMEOUT - READ_DMA" > and "TIMEOUT - WRITE_DMA" errors on my drives. I was frustrated. > But I found a workaround: Turning off ACPI. > > I just received a Highpoint RocketRaid 1640 controller, > 2 Maxtor 300GB drives, and a Supermicro 5-drive SATA cage. > I am testing this configuration for a storage server. > > I am using an old motherboard, DTK brand, Slot 1. 300A Celeron. > > Under a fresh install of 5.3-RELEASE I am unable to read or write > both drives heavily at the same time. One drive alone seems to work > OK. When I run dd blasting both drives with seqential IO, I get > TIMEOUT - WRITE(READ)_DMA. Repeatably, within 15 seconds. > > However I got a good test before I installed 5.3-R, the box was running > with 5.3-BETA. Only difference was I booted without ACPI. > > So I rebooted the freshly installed 5.3-R without ACPI, and It works! > I can read at 50MB/s per drive concurrently (hitting PCI bus speed > limit?), and write at 30MB/s per drive concurrently. No errors so > far, and its been dd'ing for a half hour. > > I hope this report helps someone! > > > > Joe Koberg > joe at osoft dot us I 2 have been seeing this error sence 4.9 with my westeren digital 80gig hd the error message has changed a little between the two vers .. but i do have this in device.hints , hint.acpi.0.disabled="1" , and i still see the error messages . any way i just whanted to post in and let every one know that turning off ACPI , might not work for you. ohh and off subject here , i had acpi turned off becouse my net cards wouldnt work with it on .. > dmesg: > > FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 > root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium II/Pentium II Xeon/Celeron (307.84-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x660 Stepping = 0 > > Features=0x183f9ff > real memory = 402587648 (383 MB) > avail memory = 384270336 (366 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pcib0: pcibus 0 on motherboard > pir0: on motherboard > pci0: on pcib0 > agp0: mem > 0xe0000000-0xe3ffffff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port > 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > uhci0: port 0xb000-0xb01f irq > 10 at device 7.2 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 > ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev > 1.10/3.00, addr 2, iclass 3/1 > ums0: 5 buttons and Z dir. > pci0: at device 7.3 (no driver attached) > atapci1: port > 0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07,0xb800-0xb803,0xb400-0xb407 > irq 11 at device 17.0 on pci0 > ata2: channel #0 on atapci1 > ata3: channel #1 on atapci1 > atapci2: port > 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007,0xcc00-0xcc03,0xc800-0xc807 > irq 11 at device 17.1 on pci0 > ata4: channel #0 on atapci2 > ata5: channel #1 on atapci2 > dc0: port 0xdc00-0xdcff mem > 0xec000000-0xec0003ff irq 12 at device 18.0 on pci0 > miibus0: on dc0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:04:5a:56:80:76 > dc0: if_start running deferred for Giant > dc0: [GIANT-LOCKED] > pci0: at device 19.0 (no driver attached) > cpu0 on motherboard > orm0: at iomem 0xcc000-0xcdfff,0xc0000-0xc8fff on isa0 > pmtimer0 on isa0 > atkbdc0: at port 0x64,0x60 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > unknown: can't assign resources (port) > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > Timecounter "TSC" frequency 307842170 Hz quality 800 > Timecounters tick every 10.000 msec > ad0: 43979MB [89355/16/63] at ata0-master UDMA33 > ad4: 286188MB [581463/16/63] at ata2-master > UDMA133 > ad6: 286188MB [581463/16/63] at ata3-master > UDMA133 > Mounting root from ufs:/dev/ad0s1a > > > > > > > > > > > >After these messages the two former cases result in FAILURE and finally > >in panic. Even background fsck cannot run without another panic, only > >single user mode can help. All these prevent using them on my HW. > >However B7, although displays the messages as well, works seemingly > >fine. For the time being this version is sufficent, but I'd like to > >know - if possible at all - what the difference could be between the > >versions and if one can expect to bring the actual 5.3 version's > >state to B7's in this respect? > > > >Further to this, the different versions display the behavior of > >relatively frequently (many time in an hour?) stalling their > >responsivity for some seconds. Most of the times no message can be seen > >on the consol after this. It is also more rare on B7. > > > >I also found that pendrive's sensing by 5.3 RELEASE/STABLE more > >frequently results in panic than B7's. (As a matter of fact I have not > >seen it with B7 for weeks since I installed it.) > > > >I use the following either with GENERIC or custom kernel: > >Abit NF7-S (nVidia chipsets, SiI3112 on board), Athlon 2600+, > >Samsung 120G SATA, LEXAR MEDIA JUMPDRIVE, rev 1.10/0.01 > > > > > >Please cc it to me as well, since I'am not on the list for the time > >being. > >Many thanks! > > > >Zsolt > > > >-------------------- > >Zsolt Kuti > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > _______________________________________________ > 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-current@FreeBSD.ORG Tue Dec 28 02:58:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13BBF16A4CE; Tue, 28 Dec 2004 02:58:39 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEDDF43D49; Tue, 28 Dec 2004 02:58:37 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 7018E6AA01; Tue, 28 Dec 2004 13:58:36 +1100 (EST) Date: Tue, 28 Dec 2004 13:58:36 +1100 From: John Birrell To: Julian Elischer Message-ID: <20041228025836.GA53223@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D0C63F.3000702@elischer.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 cc: usb@freebsd.org Subject: Re: USB problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 02:58:39 -0000 On Mon, Dec 27, 2004 at 06:34:39PM -0800, Julian Elischer wrote: > can you be a bi tmore explicit abuot what you mena by "stalls the > control endpoint at > every opportunity". > > The linux libusb has code in its' timeout code that "unstalls" > endpoints if they timeout. I p[resume becasue they have seen this as > a common reason for timeouts. FreeBSD issues teh same command on > endpoint open.. try closing and reopenning the endpoint. The stall I'm referring to is a bit in the ISP1581 controller. According to the USB spec, a device sets the stall bit if it can't do something it is asked to do. In the case of this Philips device, it sends a descriptor (for instance) and then sets the stall bit on the control endpoint for seemingly no good reason. If you ask for device status, the firware sends it, then stalls the control endpoint. I have to set the NO_STRINGS quirk to stop FreeBSD from ignoring th device simply because it stalls the control endpoint after sending a string descriptor. > hmm I'll have to look at the spec to see if a stall status can > come back with data? My reading of the spec is that, yes it can. In 8.5.3 they refer to 'setup', 'data' and 'status' stages of a control transfer. > There are two 'stalls'.. the endpoint stalls, and the local status > word reflects that. (at least in EHCI), so you'd need to clear both.. > one with a write and teh other with a memory write.. Are you referring to the 'control' endpoint? The FreeBSD code seems to infer that the control endpoint shouldn't stall. > > if (nstatus & UHCI_TD_ACTIVE) > > break; > > > >> in uhci_idone() to the bottom of the loop, it returns the actlen > > properly (I think). At least I can get the data from the device despite > > the stall. > > can it then proceed? Yes, it can. I talk to the device with that change. I'm just not sure whether it makes sense. > I'm trying to address that issue right now.. > If we can't bring netBSD withus in some architectural changes than at > some stage we'll have to go it ourselves. Which I'd rather not do.. > but they are hard to contact.. (probably also short of time) No doubt. > >I'd love to get rid of the attach_args structure and just pass a > >usbd_device_handle into the drivers, with struct usbd_device containing > >a couple of extra variables for use during matching. > > sure.. there are a number of architectural changes "in the wings" > that I'd like ot thrash out with the NetBSD guys but I have found > it hard to find a forum to communicate with tehm on.. > the suggestion "send a NetBSD PR" is the best I've got back so far.. > Though they have seemed friendly enough. Who from NetBSD? If it's one of the 'elephants' (with long memories and who hold a grudge), they might react badly to my name. 8-) [ BTW, I just noticed there is a freebsd-usb list. I must have missed the announcement. ] -- John Birrell From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 13:53:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D08816A4CE for ; Tue, 28 Dec 2004 13:53:41 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EAE43D1D for ; Tue, 28 Dec 2004 13:53:40 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBSDrdHx080631; Tue, 28 Dec 2004 08:53:39 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBSDrdMk080626; Tue, 28 Dec 2004 08:53:39 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 28 Dec 2004 08:53:39 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041228135339.GA80377@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <20041227040216.GA44588@technokratis.com> <20041228084731.GA766@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228084731.GA766@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 13:53:41 -0000 On Tue, Dec 28, 2004 at 09:47:31AM +0100, Peter Holm wrote: > On Sun, Dec 26, 2004 at 11:02:16PM -0500, Bosko Milekic wrote: > > > I'll have to reserve some more time to think about this. One way I > > > think it might be solvable would be to change that check that > > > triggers the NULL return explicitly check for the bucketzone, and not > > > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > > > more. > > > > Please try the attached patch and let me know if with it you can or > > cannot trigger the original (seemingly infinite) looping. Although I > > still haven't quite figured out how the described scenario could lead > > to infinite looping exactly (I did conclude that it could lead to some > > looping, though), the patch is worth trying as I believe the scenario > > *could* occur. > > > > After more than 18 hours of testing with your patch I ran into a > (unrelated ?) "panic: mutex vm object not owned": > http://www.holm.cc/stress/log/freeze06.html Your other (private) Email to me mentions that another developer has claimed this one. If/when he fixes it, it would be worthwhile to give it another consecutive 18 hours before we decide that "yes, it's good and it works." I am optimistic, but we have to be thorough. Good work, so far! Cheers, -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 14:16:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB45916A4CE; Tue, 28 Dec 2004 14:16:28 +0000 (GMT) Received: from relay.dk (relay.dk [80.63.235.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F5D43D2D; Tue, 28 Dec 2004 14:16:27 +0000 (GMT) (envelope-from ns@got2get.net) Received: from 12TICKETDEVEL (avizion@relay.dk [10.0.0.1]) by relay.dk (8.13.1/8.13.1) with SMTP id iBSEGKgG068613; Tue, 28 Dec 2004 15:16:20 +0100 (CET) (envelope-from ns@got2get.net) Message-ID: <00c601c4ece7$ce685100$c91b46d4@12TICKETDEVEL> From: "Nicolai Schlenzig" To: =?iso-8859-1?Q?S=F8ren_Schmidt?= , "Ruslan Ermilov" References: <20041223221047.GB6049@ip.net.ua><20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk><20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk><20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk><20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk><20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> Date: Tue, 28 Dec 2004 15:16:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 cc: current@freebsd.org Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 14:16:29 -0000 Is there any way for me to compile just this little part of world and install it (after applying that patch)? Doing "make buildworld" for CURRENT takes 8+ hours on my system... but this is exactly what I'm looking for. My Promise SATA TX2IIplus 150 gives "ATA_IDENTIFY" timeouts for anything I attach. I'd sure like to give it a try - but if you guys find a new and better patch within, say, 4 hours - I have to sit tight for 4 more only to restart my compile ;) Thanks in advance. // Nicolai ----- Original Message ----- From: "Sјren Schmidt" To: "Ruslan Ermilov" Cc: ; "Soren Schmidt" Sent: Tuesday, December 28, 2004 1:49 PM Subject: Re: ATA regression [PATCH] Ruslan Ermilov wrote: > So I analyzed what was changed in this ata-chipset.c revision > when it comes to my chip, and tried the following patch, and > it brought me back my ad8 drive: Hmm, there are grimlins in there alright. Could you try the attached patch as thats what I have in my WIP and it cleans up the code a bit as well.. -- -Sјren -------------------------------------------------------------------------------- Index: ata-chipset.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.97 diff -u -r1.97 ata-chipset.c --- ata-chipset.c 24 Dec 2004 13:36:04 -0000 1.97 +++ ata-chipset.c 28 Dec 2004 12:47:10 -0000 @@ -1367,6 +1367,11 @@ return ENXIO; } + if (ctlr->chip->max_dma >= ATA_SA150) + ctlr->setmode = ata_sata_setmode; + else + ctlr->setmode = ata_promise_setmode; + switch (ctlr->chip->cfg1) { case PRNEW: /* setup clocks */ @@ -1413,22 +1418,33 @@ ctlr->dmainit = ata_promise_mio_dmainit; ctlr->allocate = ata_promise_mio_allocate; - if (ctlr->chip->cfg2 & PRPATA) { - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + - ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; - } - else if (ctlr->chip->cfg2 & PRCMBO) { - ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; - } - else if (ctlr->chip->cfg2 & PRCMBO2) { - ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); - ctlr->channels = 3; - } - else - ctlr->channels = 4; + switch (ctlr->chip->cfg2) { + case PRPATA: + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + + ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; + break; - if (ctlr->chip->cfg2 & PRSX4X) { + case PRCMBO: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; + break; + + case PRSATA: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = 4; + break; + + case PRCMBO2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 3; + break; + + case PRSATA2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 4; + break; + + case PRSX4X: { struct ata_promise_sx4 *hpkt; u_int32_t dimm = ATA_INL(ctlr->r_res2, 0x000c0080); @@ -1448,26 +1464,25 @@ mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); hpkt->busy = hpkt->head = hpkt->tail = 0; + ctlr->channels = 4; + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, ata_promise_sx4_intr, ctlr, &ctlr->handle))) { device_printf(dev, "unable to setup interrupt\n"); return ENXIO; } - } - else { - if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, - ata_promise_mio_intr, ctlr, &ctlr->handle))) { - device_printf(dev, "unable to setup interrupt\n"); - return ENXIO; + return 0; } } - break; + + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, + ata_promise_mio_intr, ctlr, &ctlr->handle))) { + device_printf(dev, "unable to setup interrupt\n"); + return ENXIO; + } + return 0; } - if (ctlr->chip->max_dma >= ATA_SA150) - ctlr->setmode = ata_sata_setmode; - else - ctlr->setmode = ata_promise_setmode; - return 0; + return ENXIO; } static int -------------------------------------------------------------------------------- _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 14:48:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F93116A4CE; Tue, 28 Dec 2004 14:48:20 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF99343D2D; Tue, 28 Dec 2004 14:48:19 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from localhost (localhost [127.0.0.1])AD12E4D04B; Tue, 28 Dec 2004 15:48:18 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11803-02; Tue, 28 Dec 2004 15:48:17 +0100 (CET) Received: from m2a2.dyndns.org (pD9FFB674.dip.t-dialin.net [217.255.182.116]) 63CEA4D047; Tue, 28 Dec 2004 15:48:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 0B01677A3C; Tue, 28 Dec 2004 15:48:17 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27582-03; Tue, 28 Dec 2004 15:48:16 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 235D077A3D; Tue, 28 Dec 2004 15:48:16 +0100 (CET) From: Matthias Andree To: "Nicolai Schlenzig" In-Reply-To: <00c601c4ece7$ce685100$c91b46d4@12TICKETDEVEL> (Nicolai Schlenzig's message of "Tue, 28 Dec 2004 15:16:20 +0100") References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> <00c601c4ece7$ce685100$c91b46d4@12TICKETDEVEL> Date: Tue, 28 Dec 2004 15:48:16 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de cc: current@freebsd.org cc: =?iso-8859-15?Q?S=F8ren?= Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 14:48:20 -0000 "Nicolai Schlenzig" writes: > Is there any way for me to compile just this little part of world and > install it (after applying that patch)? Check the manual. -DNOCLEAN is your friend. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 14:42:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C041316A4CE for ; Tue, 28 Dec 2004 14:42:25 +0000 (GMT) Received: from avout2.midco.net (avout2.midco.net [24.220.0.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C3CF43D5E for ; Tue, 28 Dec 2004 14:42:22 +0000 (GMT) (envelope-from pete@beforever.com) Received: (qmail 4027 invoked by uid 1010); 28 Dec 2004 14:42:22 -0000 Received: from pete@beforever.com by avout2 by uid 1003 with qmail-scanner-1.22 (f-prot: 4.4.2/3.14.11. Clear:RC:1(24.220.221.53):. Processed in 0.012015 secs); 28 Dec 2004 14:42:22 -0000 X-Qmail-Scanner-Mail-From: pete@beforever.com via avout2 X-Qmail-Scanner: 1.22 (Clear:RC:1(24.220.221.53):. Processed in 0.012015 secs) Received: from host-53-221-220-24.midco.net (HELO [192.168.1.101]) ([24.220.221.53]) (envelope-sender ) by avout2.midco.net (qmail-ldap-1.03) with SMTP for ; 28 Dec 2004 14:42:22 -0000 In-Reply-To: <00c601c4ece7$ce685100$c91b46d4@12TICKETDEVEL> References: <20041223221047.GB6049@ip.net.ua><20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk><20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk><20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk><20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk><20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> <00c601c4ece7$ce685100$c91b46d4@12TICKETDEVEL> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Peter Schultz Date: Tue, 28 Dec 2004 08:42:16 -0600 To: "Nicolai Schlenzig" X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Tue, 28 Dec 2004 15:04:22 +0000 cc: current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 14:42:25 -0000 On Dec 28, 2004, at 8:16 AM, Nicolai Schlenzig wrote: > Is there any way for me to compile just this little part of world and > install it (after applying that patch)? > > RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v > [lots of snipping] This applies to src/sys so the kernel is all you need to rebuild. Pete... From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 15:05:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF91316A4CE for ; Tue, 28 Dec 2004 15:05:01 +0000 (GMT) Received: from fmmailgate05.web.de (fmmailgate05.web.de [217.72.192.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971F043D2D for ; Tue, 28 Dec 2004 15:05:00 +0000 (GMT) (envelope-from lukas@razik.de) Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id iBSF4xCB031592 for freebsd-current@freebsd.org; Tue, 28 Dec 2004 16:04:59 +0100 Received: from [217.229.206.126] by freemailng5302.web.de with HTTP; Tue, 28 Dec 2004 16:04:58 +0100 Date: Tue, 28 Dec 2004 16:04:58 +0100 Message-Id: <228428214@web.de> MIME-Version: 1.0 From: "Lukas Razik" To: freebsd-current@freebsd.org Precedence: fm-user X-WEBDE-Sender: Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [current on amd64] 'make buildworld' failure: /usr/src/lib/libkvm/kvm_proc.c:202: error: structure has no member named `p_uarea' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 15:05:01 -0000 Hi! System: AMD64 Acer ASPIRE 1513LMI If I try to buildworld from current sources (cvsup some minutes ago) I get these errors: ===> lib/libkvm rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -I/usr/src/lib/libkvm /usr/src/lib/libkvm/kvm.c /usr/src/lib/libkvm/kvm_amd64.c /usr/src/lib/libkvm/kvm_file.c /usr/src/lib/libkvm/kvm_getloadavg.c /usr/src/lib/libkvm/kvm_getswapinfo.c /usr/src/lib/libkvm/kvm_proc.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_amd64.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_file.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getloadavg.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getswapinfo.c cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:202: error: structure has no member named `p_uarea' /usr/src/lib/libkvm/kvm_proc.c:269: warning: assignment makes integer from pointer without a cast /usr/src/lib/libkvm/kvm_proc.c:341: error: structure has no member named `p_runtime' *** Error code 1 Stop in /usr/src/lib/libkvm. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Has anyone the same problem or a solution??? Kind regards, Lukas From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 15:26:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F47C16A4CE; Tue, 28 Dec 2004 15:26:46 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 231AC43D1F; Tue, 28 Dec 2004 15:26:45 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSFQb0i024296; Tue, 28 Dec 2004 17:26:38 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 54480-08; Tue, 28 Dec 2004 17:26:37 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSFQb4D024293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Dec 2004 17:26:37 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBSFQkSJ018100; Tue, 28 Dec 2004 17:26:46 +0200 (EET) (envelope-from ru) Date: Tue, 28 Dec 2004 17:26:41 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041228152641.GC14010@ip.net.ua> References: <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eRtJSFbw+EEWtPj3" Content-Disposition: inline In-Reply-To: <41D15650.7080504@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 15:26:46 -0000 --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Dec 28, 2004 at 01:49:20PM +0100, S?ren Schmidt wrote: > Ruslan Ermilov wrote: >=20 > >So I analyzed what was changed in this ata-chipset.c revision > >when it comes to my chip, and tried the following patch, and > >it brought me back my ad8 drive: >=20 > Hmm, there are grimlins in there alright. Could you try the attached=20 > patch as thats what I have in my WIP and it cleans up the code a bit as= =20 > well.. >=20 Tried that -- got the same identification failure followed by the double free panic. But it cannot obviously help -- this patch is for ata_promise_chipinit(), and it by itself might be needed for something else, but my patch was for ata_promise_mio_reset() which doesn't seem to handle PRCMBO controllers at all in its current version. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0XsxqRfpzJluFF4RAkWTAKCRgGkYqEs67rxHM8n2fkXfI3sj0gCgkSnZ pS5X4NGbPE+lEZmw8tDwb+w= =lRtH -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 15:45:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A85616A4CE for ; Tue, 28 Dec 2004 15:45:29 +0000 (GMT) Received: from fmmailgate05.web.de (fmmailgate05.web.de [217.72.192.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id C284143D4C for ; Tue, 28 Dec 2004 15:45:28 +0000 (GMT) (envelope-from lukas@razik.de) Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id iBSFiLCL006953 for freebsd-current@freebsd.org; Tue, 28 Dec 2004 16:45:27 +0100 Received: from [217.229.206.126] by freemailng5302.web.de with HTTP; Tue, 28 Dec 2004 16:45:24 +0100 Date: Tue, 28 Dec 2004 16:45:24 +0100 Message-Id: <228451129@web.de> MIME-Version: 1.0 From: "Lukas Razik" To: freebsd-current@freebsd.org Precedence: fm-user X-WEBDE-Sender: Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [current on amd64] 'make buildworld' failure: /usr/src/lib/libkvm/kvm_proc.c:202: error: structure has no member named `p_uarea' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 15:45:29 -0000 Sorry, I had a wrong cvs-supfile! Best regards, Lukas "Lukas Razik" schrieb am 28.12.04 16:06:00: > > Hi! > > System: AMD64 Acer ASPIRE 1513LMI > > If I try to buildworld from current sources (cvsup some minutes ago) I get these errors: > > ===> lib/libkvm > rm -f .depend > mkdep -f .depend -a -DLIBC_SCCS -I/usr/src/lib/libkvm /usr/src/lib/libkvm/kvm.c /usr/src/lib/libkvm/kvm_amd64.c /usr/src/lib/libkvm/kvm_file.c /usr/src/lib/libkvm/kvm_getloadavg.c /usr/src/lib/libkvm/kvm_getswapinfo.c /usr/src/lib/libkvm/kvm_proc.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_amd64.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_file.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getloadavg.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_getswapinfo.c > cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c > /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': > /usr/src/lib/libkvm/kvm_proc.c:202: error: structure has no member named `p_uarea' > /usr/src/lib/libkvm/kvm_proc.c:269: warning: assignment makes integer from pointer without a cast > /usr/src/lib/libkvm/kvm_proc.c:341: error: structure has no member named `p_runtime' > *** Error code 1 > > Stop in /usr/src/lib/libkvm. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Has anyone the same problem or a solution??? > > > Kind regards, > Lukas > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 18:24:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61AA616A4D0; Tue, 28 Dec 2004 18:24:05 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5590343D2F; Tue, 28 Dec 2004 18:24:04 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id iBSIO2Ox073256; Tue, 28 Dec 2004 13:24:02 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)iBSIO1cK073248; Tue, 28 Dec 2004 13:24:02 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 28 Dec 2004 13:24:01 -0500 (EST) From: Jeff Roberson To: Bosko Milekic In-Reply-To: <20041228043327.GA96744@technokratis.com> Message-ID: <20041228132209.G60504@mail.chesapeake.net> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <200412271705.31625.jhb@FreeBSD.org> <20041228043327.GA96744@technokratis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jeffr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 18:24:05 -0000 On Mon, 27 Dec 2004, Bosko Milekic wrote: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current > > (and see previous in thread for context). > > Let's hope. It might be better for the slab zones to msleep there rather than flood the system with allocation requests. Imagine if many threads were to hit this code path, the slabzone would get a new slab for each calling thread, when really we only want one more. It seems like this bug should have been caught sooner with asserts rather than a hang somewhere. Can you investigate why this did not happen? > > -Bosko > > On Mon, Dec 27, 2004 at 05:05:31PM -0500, John Baldwin wrote: > > On Monday 20 December 2004 06:04 am, Peter Holm wrote: > > > On Thu, Dec 16, 2004 at 03:21:44PM -0500, John Baldwin wrote: > > > > On Monday 06 December 2004 08:59 am, Peter Holm wrote: > > > > > On Fri, Nov 19, 2004 at 05:10:19PM -0500, John Baldwin wrote: > > > > > > On Friday 19 November 2004 02:59 am, Peter Holm wrote: > > > > > > > On Mon, Nov 15, 2004 at 03:46:15PM -0500, John Baldwin wrote: > > > > > > > > On Friday 12 November 2004 07:33 am, Peter Holm wrote: > > > > > > > > > GENERIC HEAD from Nov 11 08:05 UTC > > > > > > > > > > > > > > > > > > The following stack traces etc. was done before my first > > > > > > > > > cup of coffee, so it's not so informative as it could have been > > > > > > > > > :-( > > > > > > > > > > > > > > > > > > The test box appeared to have been frozen for more than 6 > > > > > > > > > hours, but was pingable. > > > > > > > > > > > > > > > > > > http://www.holm.cc/stress/log/cons86.html > > > > > > > > > > > > > > > > A weak guess is that you have the system in some sort of livelock > > > > > > > > due to fork()? Have you tried running with 'debug.mpsafevm=1' > > > > > > > > set from the loader? > > > > > > > > > > > > > > > > -- > > > > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > > > > > > > OK, I've got some more info: > > > > > > > > > > > > > > http://www.holm.cc/stress/log/cons88.html > > > > > > > > > > > > > > Looks like a spin in uma_zone_slab() when slab_zalloc() fails? > > > > > > > > > > > > Yes, I think if you specify M_WAITOK, then that might happen. > > > > > > slab_zalloc() can fail if any of the init functions fail for example, > > > > > > in which case it would loop forever. You can try this hack (though > > > > > > it may very well be wrong) to return failure if that is what is > > > > > > triggering: > > > > > > > > > > > > Index: uma_core.c > > > > > > =================================================================== > > > > > > RCS file: /usr/cvs/src/sys/vm/uma_core.c,v > > > > > > retrieving revision 1.110 > > > > > > diff -u -r1.110 uma_core.c > > > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > > > +++ uma_core.c 19 Nov 2004 22:08:26 -0000 > > > > > > @@ -1998,6 +1998,10 @@ > > > > > > */ > > > > > > if (flags & M_NOWAIT) > > > > > > flags |= M_NOVM; > > > > > > + > > > > > > + /* XXXHACK */ > > > > > > + if (flags & M_WAITOK) > > > > > > + break; > > > > > > } > > > > > > return (slab); > > > > > > } > > > > > > > > > > > > -- > > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > > > I instrumented the code with this: > > > > > $ cvs diff -u > > > > > cvs diff: Diffing . > > > > > Index: uma_core.c > > > > > =================================================================== > > > > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > > > > retrieving revision 1.110 > > > > > diff -u -r1.110 uma_core.c > > > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > > > +++ uma_core.c 6 Dec 2004 13:49:36 -0000 > > > > > @@ -1926,6 +1926,7 @@ > > > > > { > > > > > uma_slab_t slab; > > > > > uma_keg_t keg; > > > > > + int i; > > > > > > > > > > keg = zone->uz_keg; > > > > > > > > > > @@ -1943,7 +1944,8 @@ > > > > > > > > > > slab = NULL; > > > > > > > > > > - for (;;) { > > > > > + for (i = 0;;i++) { > > > > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > > > > /* > > > > > * Find a slab with some space. Prefer slabs that are > > > > > partially * used over those that are totally full. This helps to > > > > > reduce > > > > > > > > > > and now during test of Jeff Roberson's "SMP FFS" patch the assert > > > > > triggered: http://www.holm.cc/stress/log/cons92.html > > > > > > > > Hmm. Does the hack patch above make the hang go away or does it just > > > > break things worse? > > > > > > I have been testing your patch for quite a while. If it's OK for > > > m_getcl with M_TRYWAIT to return NULL, your patch reviled a missing > > > test for NULL in kern/uipc_socket.c:750 > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x1c > > > fault code = supervisor write, page not present > > > instruction pointer = 0x8:0xc0647d77 > > > stack pointer = 0x10:0xcfa9cbf0 > > > frame pointer = 0x10:0xcfa9cc38 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 67417 (net) > > > [thread pid 67417 tid 100890 ] > > > Stopped at sosend+0x227: movl $0,0x1c(%eax) > > > db> where > > > Tracing pid 67417 tid 100890 td 0xc1ae8000 > > > sosend(c3454dec,0,cfa9cc90,0,0) at sosend+0x227 > > > soo_write(c1db9374,cfa9cc90,c1aa6180,0,c1ae8000) at > > > soo_write+0x2d > > > dofilewrite(3,bfbfe740,400,ffffffff,ffffffff) at dofilewrite+0x99 > > > write(c1ae8000,cfa9cd14,3,d,246) at write+0x48 > > > syscall(2f,bfbf002f,bfbf002f,3,bfbfe740) at syscall+0x128 > > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > --- syscall (4, FreeBSD ELF32, write), eip = 0x280bfbf7, esp = > > > 0xbfbfe71c, ebp = 0xbfbfeb68 --- > > > > Hmm, it looks like M_TRYWAIT isn't allowed to return NULL. Unfortunately, I > > think my hack basically lets UMA return NULL instead of spinning forever, so > > it's not that useful. I'm not sure how to really fix this problem in UMA. > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 18:38:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE22D16A4CE; Tue, 28 Dec 2004 18:38:51 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C38543D1F; Tue, 28 Dec 2004 18:38:51 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBSIclq7026137; Tue, 28 Dec 2004 13:38:47 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBSIclS3026136; Tue, 28 Dec 2004 13:38:47 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 28 Dec 2004 13:38:47 -0500 From: Bosko Milekic To: Jeff Roberson Message-ID: <20041228183847.GA24514@technokratis.com> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <200412271705.31625.jhb@FreeBSD.org> <20041228043327.GA96744@technokratis.com> <20041228132209.G60504@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228132209.G60504@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i cc: jeffr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 18:38:51 -0000 On Tue, Dec 28, 2004 at 01:24:01PM -0500, Jeff Roberson wrote: > On Mon, 27 Dec 2004, Bosko Milekic wrote: > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current > > > > (and see previous in thread for context). > > > > Let's hope. > > It might be better for the slab zones to msleep there rather than flood > the system with allocation requests. Imagine if many threads were to hit > this code path, the slabzone would get a new slab for each calling thread, > when really we only want one more. They will not flood the system with allocation requests. They will merely block in the VM if they need to (if the allocation is M_WAITOK, otherwise they will return NULL shortly thereafter). This is because after that check, in uma_zalloc_internal(), we enter the loop which performs a slab_zalloc() call (which dips into VM). The dipping into VM will not occur repeatedly, but only once, as it is supposed to; the change merely gives it a chance to do so. The uk_recurse check was designed to protect from recursion occuring from the VM itself and so should not prevent multiple threads from dipping into the VM, even if it is for the same zone. This is perhaps an implementation flaw (but it is separate), that under a starvation situation you might have two or more separate threads ask the VM for pages (when in fact only one slab needs to be allocated to satisfy N requests), but this scenario is rare and is in my opinion not worth changing the implementation for (in that kind of long-term starvation, you're likely facing serious problems that UMA alone cannot address anyway). > It seems like this bug should have been caught sooner with asserts rather > than a hang somewhere. Can you investigate why this did not happen? I don't see why the bug would have been hit sooner. The likelihood of another allocation request coming in through uma_zalloc_internal() _exactly_ when another is allocating a slab header within the window where uk_recurse > 0 is small. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 19:02:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5CFA16A4CE for ; Tue, 28 Dec 2004 19:02:39 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A836343D58 for ; Tue, 28 Dec 2004 19:02:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 446DB7A453; Tue, 28 Dec 2004 11:02:39 -0800 (PST) Message-ID: <41D1ADCE.1020902@elischer.org> Date: Tue, 28 Dec 2004 11:02:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Smcmillan1967@aol.com References: <1a3.2d0162df.2f01a7ba@aol.com> In-Reply-To: <1a3.2d0162df.2f01a7ba@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Sound stopped working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 19:02:39 -0000 when? what kind of sound? what age kernel? Smcmillan1967@aol.com wrote: >Our sound stopped working on our PS2, can you tell me what the problem could >be? Thank you >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 19:28:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F4BF16A4CE; Tue, 28 Dec 2004 19:28:13 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A261643D2D; Tue, 28 Dec 2004 19:28:12 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id iBSJSBOx098960; Tue, 28 Dec 2004 14:28:11 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)iBSJSBrQ098954; Tue, 28 Dec 2004 14:28:11 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 28 Dec 2004 14:28:10 -0500 (EST) From: Jeff Roberson To: Bosko Milekic In-Reply-To: <20041228183847.GA24514@technokratis.com> Message-ID: <20041228142659.O60504@mail.chesapeake.net> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <20041228043327.GA96744@technokratis.com> <20041228183847.GA24514@technokratis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jeffr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 19:28:13 -0000 On Tue, 28 Dec 2004, Bosko Milekic wrote: > > On Tue, Dec 28, 2004 at 01:24:01PM -0500, Jeff Roberson wrote: > > On Mon, 27 Dec 2004, Bosko Milekic wrote: > > > > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current > > > > > > (and see previous in thread for context). > > > > > > Let's hope. > > > > It might be better for the slab zones to msleep there rather than flood > > the system with allocation requests. Imagine if many threads were to hit > > this code path, the slabzone would get a new slab for each calling thread, > > when really we only want one more. > > They will not flood the system with allocation requests. They > will merely block in the VM if they need to (if the allocation is > M_WAITOK, otherwise they will return NULL shortly thereafter). > This is because after that check, in uma_zalloc_internal(), we enter > the loop which performs a slab_zalloc() call (which dips into VM). > The dipping into VM will not occur repeatedly, but only once, as it is > supposed to; the change merely gives it a chance to do so. > > The uk_recurse check was designed to protect from recursion occuring > from the VM itself and so should not prevent multiple threads from > dipping into the VM, even if it is for the same zone. > > This is perhaps an implementation flaw (but it is separate), that > under a starvation situation you might have two or more separate > threads ask the VM for pages (when in fact only one slab needs to be > allocated to satisfy N requests), but this scenario is rare and is in > my opinion not worth changing the implementation for (in that kind of > long-term starvation, you're likely facing serious problems that UMA > alone cannot address anyway). This is the issue that I was talking about. We'll have too many threads simultaneously doing allocations for the same zone. I thought I had some code to address this situation, but I can't remeber where now. > > > It seems like this bug should have been caught sooner with asserts rather > > than a hang somewhere. Can you investigate why this did not happen? > > I don't see why the bug would have been hit sooner. The likelihood of > another allocation request coming in through uma_zalloc_internal() > _exactly_ when another is allocating a slab header within the window > where uk_recurse > 0 is small. Not that we would have found it sooner, but we should have paniced somewhere before returning with NULL and looping forever. > > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org > From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 19:58:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B5716A4CE; Tue, 28 Dec 2004 19:58:55 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7942F43D49; Tue, 28 Dec 2004 19:58:54 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBSJwncJ074991; Tue, 28 Dec 2004 20:58:51 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41D1BAD3.5020804@DeepCore.dk> Date: Tue, 28 Dec 2004 20:58:11 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> <20041228152641.GC14010@ip.net.ua> In-Reply-To: <20041228152641.GC14010@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 19:58:55 -0000 Ruslan Ermilov wrote: > Hi, >=20 > On Tue, Dec 28, 2004 at 01:49:20PM +0100, S?ren Schmidt wrote: >=20 >>Ruslan Ermilov wrote: >> >> >>>So I analyzed what was changed in this ata-chipset.c revision >>>when it comes to my chip, and tried the following patch, and >>>it brought me back my ad8 drive: >> >>Hmm, there are grimlins in there alright. Could you try the attached=20 >>patch as thats what I have in my WIP and it cleans up the code a bit as= =20 >>well.. >> >=20 > Tried that -- got the same identification failure followed by > the double free panic. But it cannot obviously help -- this > patch is for ata_promise_chipinit(), and it by itself might be > needed for something else, but my patch was for > ata_promise_mio_reset() which doesn't seem to handle PRCMBO > controllers at all in its current version. Oh crap! I just got the first half of the patch in the diff, sorry 'bout = that. I'll get the rest along when I get back to the lab tomorrow... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 20:23:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D4D616A4CE; Tue, 28 Dec 2004 20:23:26 +0000 (GMT) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E325843D3F; Tue, 28 Dec 2004 20:23:25 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [IPv6:2001:960:301:3:a00:20ff:fe85:fa39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id 1B27A3E434; Tue, 28 Dec 2004 21:23:24 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 8D3D3272; Tue, 28 Dec 2004 21:23:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 7B12A231; Tue, 28 Dec 2004 21:23:23 +0100 (CET) Date: Tue, 28 Dec 2004 21:23:23 +0100 (CET) From: Sten Spans To: Joe Koberg In-Reply-To: <41D0C51D.8020800@osoft.us> Message-ID: References: <20041209183911.068c9a84.kutizs@axelero.hu> <41D0C51D.8020800@osoft.us> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1104265403=:22265" cc: =?ISO-8859-1?Q?Zsolt_K=FAti?= cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 20:23:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1104265403=:22265 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 27 Dec 2004, Joe Koberg wrote: > Zsolt Kњti wrote: > >> My system produces these messages that I already know well from this >> list (as well ;): >> ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=213249674 >> >> > So I rebooted the freshly installed 5.3-R without ACPI, and It works! > I can read at 50MB/s per drive concurrently (hitting PCI bus speed > limit?), and write at 30MB/s per drive concurrently. No errors so > far, and its been dd'ing for a half hour. Regular PCI and PCI-X (eXtended) is: 33hmz/32bits 132 Megabyte 66mhz/32bits 264 Megabyte 66mhz/64bits 520 Megabyte 100mhz/64bits 784 Megabyte 133mhz/64bits 1040 Megabyte etc. With overhead included I'd say 100 Megabyte is pretty reasonable for a normal pci bus. Keep in mind that this is for the whole bus, which is why most server motherboard have multiple seperate busses. PCI-X is an extension to regular pci, with more mhz/bits. PCI-E ( Express ) is a redesign with higher speeds and fewer traces needed. The big problem with 64bits pci is not the slot but the fact that you have to run all those extra (fast) lines to the slots which means that you'll need extra space (mainly layers) to store them, ergo an expensive motherboard. HTH, HAND. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem ---559023410-851401618-1104265403=:22265-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 21:27:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D2516A4CF; Tue, 28 Dec 2004 21:27:20 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B263B43D4C; Tue, 28 Dec 2004 21:27:19 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBSLRE3Y075768; Tue, 28 Dec 2004 22:27:16 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41D1CF8C.20802@DeepCore.dk> Date: Tue, 28 Dec 2004 22:26:36 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> <20041228152641.GC14010@ip.net.ua> <41D1BAD3.5020804@DeepCore.dk> In-Reply-To: <41D1BAD3.5020804@DeepCore.dk> Content-Type: multipart/mixed; boundary="------------070806000507090003070405" X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: Ruslan Ermilov cc: current@FreeBSD.ORG cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 21:27:20 -0000 This is a multi-part message in MIME format. --------------070806000507090003070405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable S=F8ren Schmidt wrote: > Oh crap! I just got the first half of the patch in the diff, sorry 'bou= t=20 > that. I'll get the rest along when I get back to the lab tomorrow... OK, try this instead, I hope I managed to get it all pulled over this=20 time... --=20 -S=F8ren --------------070806000507090003070405 Content-Type: text/plain; name="promdiff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="promdiff" Index: ata-chipset.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.97 diff -u -r1.97 ata-chipset.c --- ata-chipset.c 24 Dec 2004 13:36:04 -0000 1.97 +++ ata-chipset.c 28 Dec 2004 21:24:08 -0000 @@ -1367,6 +1367,11 @@ return ENXIO; } + if (ctlr->chip->max_dma >= ATA_SA150) + ctlr->setmode = ata_sata_setmode; + else + ctlr->setmode = ata_promise_setmode; + switch (ctlr->chip->cfg1) { case PRNEW: /* setup clocks */ @@ -1413,22 +1418,33 @@ ctlr->dmainit = ata_promise_mio_dmainit; ctlr->allocate = ata_promise_mio_allocate; - if (ctlr->chip->cfg2 & PRPATA) { - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + - ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; - } - else if (ctlr->chip->cfg2 & PRCMBO) { - ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); - ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; - } - else if (ctlr->chip->cfg2 & PRCMBO2) { - ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); - ctlr->channels = 3; - } - else - ctlr->channels = 4; + switch (ctlr->chip->cfg2) { + case PRPATA: + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x01) > 0) + + ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 2; + break; + + case PRCMBO: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = ((ATA_INL(ctlr->r_res2, 0x48) & 0x02) > 0) + 3; + break; - if (ctlr->chip->cfg2 & PRSX4X) { + case PRSATA: + ATA_OUTL(ctlr->r_res2, 0x06c, 0x000000ff); + ctlr->channels = 4; + break; + + case PRCMBO2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 3; + break; + + case PRSATA2: + ATA_OUTL(ctlr->r_res2, 0x060, 0x000000ff); + ctlr->channels = 4; + break; + + case PRSX4X: { struct ata_promise_sx4 *hpkt; u_int32_t dimm = ATA_INL(ctlr->r_res2, 0x000c0080); @@ -1448,26 +1464,25 @@ mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); hpkt->busy = hpkt->head = hpkt->tail = 0; + ctlr->channels = 4; + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, ata_promise_sx4_intr, ctlr, &ctlr->handle))) { device_printf(dev, "unable to setup interrupt\n"); return ENXIO; } - } - else { - if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, - ata_promise_mio_intr, ctlr, &ctlr->handle))) { - device_printf(dev, "unable to setup interrupt\n"); - return ENXIO; + return 0; } } - break; + + if ((bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, + ata_promise_mio_intr, ctlr, &ctlr->handle))) { + device_printf(dev, "unable to setup interrupt\n"); + return ENXIO; + } + return 0; } - if (ctlr->chip->max_dma >= ATA_SA150) - ctlr->setmode = ata_sata_setmode; - else - ctlr->setmode = ata_promise_setmode; - return 0; + return ENXIO; } static int @@ -1587,13 +1602,13 @@ struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(ch->dev)); - if (ctlr->chip->cfg2 & PRSX4X) { + switch (ctlr->chip->cfg2) { + case PRSX4X: { struct ata_promise_sx4 *hpktp = ctlr->driver; - /* softreset channels ATA module */ + /* softreset channel ATA module */ ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1); DELAY(1000); - ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), (ATA_INL(ctlr->r_res2, 0xc0260 + (ch->unit << 7)) & ~0x00003f9f) | (ch->unit + 1)); @@ -1606,8 +1621,20 @@ ATA_OUTL(ctlr->r_res2, 0xc012c, (ATA_INL(ctlr->r_res2, 0xc012c) & ~0x00000f9f)); mtx_unlock(&hpktp->mtx); - } - else if (ctlr->chip->cfg2 & PRSATA) { + } + break; + + case PRCMBO: + case PRCMBO2: + /* softreset channel ATA module */ + ATA_OUTL(ctlr->r_res2, 0x0260 + (ch->unit << 7), (1 << 11)); + ata_udelay(10000); + ATA_OUTL(ctlr->r_res2, 0x0260 + (ch->unit << 7), + (ATA_INL(ctlr->r_res2, 0x0260 + (ch->unit << 7)) & + ~0x00003f9f) | (ch->unit + 1)); + break; + + case PRSATA: { u_int32_t status = 0; int timeout; @@ -1633,14 +1660,16 @@ if (timeout >= 1000000) device_printf(ch->dev, "connect status=%08x\n", status); - /* enable plug/unplug intr */ + /* reset and enable plug/unplug intr */ ATA_OUTL(ctlr->r_res2, 0x06c, (0x00000011 << ch->unit)); - } - else if (ctlr->chip->cfg2 & PRSATA2) { + } + break; + + case PRSATA2: { u_int32_t status = 0; int timeout; - /* set PM port */ + /* set portmultiplier port */ ATA_OUTL(ctlr->r_res2, 0x4e8 + (ch->unit << 8), 0x0f); /* mask plug/unplug intr */ @@ -1670,11 +1699,13 @@ if (timeout >= 1000000) device_printf(ch->dev, "connect status=%08x\n", status); - /* enable plug/unplug intr */ + /* reset and enable plug/unplug intr */ ATA_OUTL(ctlr->r_res2, 0x060, (0x00000011 << ch->unit)); - /* set PM port */ - ATA_OUTL(ctlr->r_res2, 0x4e8 + (ch->unit * 0x100), 0x00); + /* set portmultiplier port */ + ATA_OUTL(ctlr->r_res2, 0x4e8 + (ch->unit << 8), 0x00); + } + break; } } --------------070806000507090003070405-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 21:50:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA0D916A507 for ; Tue, 28 Dec 2004 21:50:51 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29ABF43D39 for ; Tue, 28 Dec 2004 21:50:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10499 invoked from network); 28 Dec 2004 21:50:51 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 28 Dec 2004 21:50:50 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBSLoQg9095856; Tue, 28 Dec 2004 16:50:46 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 28 Dec 2004 15:38:15 -0500 User-Agent: KMail/1.6.2 References: <20041209144233.GA46928@peter.osted.lan> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> In-Reply-To: <20041227013745.GA5267@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412281538.15251.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Bosko Milekic cc: current@FreeBSD.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 21:50:51 -0000 On Sunday 26 December 2004 08:37 pm, Bosko Milekic wrote: > On Sun, Dec 26, 2004 at 11:56:51PM +0100, Peter Holm wrote: > > On Sun, Dec 26, 2004 at 01:17:38PM -0500, Bosko Milekic wrote: > > > On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > > > Yes, I think that I have verified your exelent analysis of the > > > > problem: http://www.holm.cc/stress/log/freeze04.html > > > > > > > > So, do have any fix suggenstons? :-) > > > > > > Not yet, because the problem is non-obvious from the trace. > > > > > > I need to know exactly when the UMA RCntSlabs zone recurses _first_, > > > and I need to confirm that it is an actual recursion. I've looked at > > > the VM code and I don't see how/why recursion on the RCntSlabs zone > > > would happen. > > > > > > Please modify the printf code to look exactly like this: > > > > > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > > > if ((zone == slabzone) || (zone == slabrefzone)) > > > panic("Zone %s forced to fail due to recurse non-null: %d\n", > > > zone->uz_name, keg->uk_recurse); > > > return (NULL); > > > } > > > > > > (You don't need to check any global counter -- the counter is > > > imperfect anyway -- because even a single recursion on slabzone or > > > slabrefzone should be illegal). > > > > > > I'd like to see the trace from the above panic, if possible. > > > > Here it is: http://www.holm.cc/stress/log/freeze05.html > > I have checked the code here and looked at possible code paths and > have unfortunately resorted to reguessing, and now I believe I have > identified a problematic scenario. > > Consider this particular timeline (time moves downward): > [I hope you can handle ASCII art] > > By the way, the stack trace you show would correspond to that of > thread 2. I refer to a frame number below. > > thread 1 (t1) thread 2 (t2) > ------------------------------------------------------------------------- > > t1.a) Allocating from a zone, > needs slab header from one of > the slab header zones (either > slabzone or slabrefzone). Let's > assume it is slabzone, as in > your trace above. The allocation > is performed with M_WAITOK. > > t2.a) Needs to allocate from > a zone, and it needs a > slab header too. The allocation will > be performed with M_WAITOK. Let's > assume that the slab header zone > we're allocating is also slabzone. > > t1.b) in uma_zone_slab(), has > slabzone's keg lock, increments > keg's uk_recurse. > Enters slab_zalloc(). > > t2.b) Blocks on zone lock. > > t1.c) Drops zone lock to > allocate from VM, uk_recurse > for the slabzone is currently > 1 (we incremented it in t1.b). > > t2.c) Takes zone lock for slabzone, > now in uma_zone_slab() (Frame 11), > and since uk_recurse is 1, it > decides recursion happened. Wants > to return NULL even though > allocation was done with M_WAITOK. > Our panic is triggered. > > I'll have to reserve some more time to think about this. One way I > think it might be solvable would be to change that check that > triggers the NULL return explicitly check for the bucketzone, and not > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > more. > > Does the scenario seem likely to you? This is what I wondered about earlier in the thread. The problem is that recursion needs to be a per-allocation (or per-thread) state, not per-zone, since a zone may be used by multiple threads at the same time. Is it really desired behavior of the bucket zone that if two threads alloc at the same time one gets NULL because it sees the other's use and thinks it is recursing? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 21:50:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C40D316A582 for ; Tue, 28 Dec 2004 21:50:51 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A62443D41 for ; Tue, 28 Dec 2004 21:50:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10499 invoked from network); 28 Dec 2004 21:50:51 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 28 Dec 2004 21:50:50 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBSLoQg9095856; Tue, 28 Dec 2004 16:50:46 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 28 Dec 2004 15:38:15 -0500 User-Agent: KMail/1.6.2 References: <20041209144233.GA46928@peter.osted.lan> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> In-Reply-To: <20041227013745.GA5267@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412281538.15251.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Bosko Milekic cc: current@FreeBSD.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 21:50:52 -0000 On Sunday 26 December 2004 08:37 pm, Bosko Milekic wrote: > On Sun, Dec 26, 2004 at 11:56:51PM +0100, Peter Holm wrote: > > On Sun, Dec 26, 2004 at 01:17:38PM -0500, Bosko Milekic wrote: > > > On Sun, Dec 26, 2004 at 05:11:53PM +0100, Peter Holm wrote: > > > > Yes, I think that I have verified your exelent analysis of the > > > > problem: http://www.holm.cc/stress/log/freeze04.html > > > > > > > > So, do have any fix suggenstons? :-) > > > > > > Not yet, because the problem is non-obvious from the trace. > > > > > > I need to know exactly when the UMA RCntSlabs zone recurses _first_, > > > and I need to confirm that it is an actual recursion. I've looked at > > > the VM code and I don't see how/why recursion on the RCntSlabs zone > > > would happen. > > > > > > Please modify the printf code to look exactly like this: > > > > > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > > > if ((zone == slabzone) || (zone == slabrefzone)) > > > panic("Zone %s forced to fail due to recurse non-null: %d\n", > > > zone->uz_name, keg->uk_recurse); > > > return (NULL); > > > } > > > > > > (You don't need to check any global counter -- the counter is > > > imperfect anyway -- because even a single recursion on slabzone or > > > slabrefzone should be illegal). > > > > > > I'd like to see the trace from the above panic, if possible. > > > > Here it is: http://www.holm.cc/stress/log/freeze05.html > > I have checked the code here and looked at possible code paths and > have unfortunately resorted to reguessing, and now I believe I have > identified a problematic scenario. > > Consider this particular timeline (time moves downward): > [I hope you can handle ASCII art] > > By the way, the stack trace you show would correspond to that of > thread 2. I refer to a frame number below. > > thread 1 (t1) thread 2 (t2) > ------------------------------------------------------------------------- > > t1.a) Allocating from a zone, > needs slab header from one of > the slab header zones (either > slabzone or slabrefzone). Let's > assume it is slabzone, as in > your trace above. The allocation > is performed with M_WAITOK. > > t2.a) Needs to allocate from > a zone, and it needs a > slab header too. The allocation will > be performed with M_WAITOK. Let's > assume that the slab header zone > we're allocating is also slabzone. > > t1.b) in uma_zone_slab(), has > slabzone's keg lock, increments > keg's uk_recurse. > Enters slab_zalloc(). > > t2.b) Blocks on zone lock. > > t1.c) Drops zone lock to > allocate from VM, uk_recurse > for the slabzone is currently > 1 (we incremented it in t1.b). > > t2.c) Takes zone lock for slabzone, > now in uma_zone_slab() (Frame 11), > and since uk_recurse is 1, it > decides recursion happened. Wants > to return NULL even though > allocation was done with M_WAITOK. > Our panic is triggered. > > I'll have to reserve some more time to think about this. One way I > think it might be solvable would be to change that check that > triggers the NULL return explicitly check for the bucketzone, and not > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > more. > > Does the scenario seem likely to you? This is what I wondered about earlier in the thread. The problem is that recursion needs to be a per-allocation (or per-thread) state, not per-zone, since a zone may be used by multiple threads at the same time. Is it really desired behavior of the bucket zone that if two threads alloc at the same time one gets NULL because it sees the other's use and thinks it is recursing? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 21:50:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3225716A5EC for ; Tue, 28 Dec 2004 21:50:54 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3994E43D46 for ; Tue, 28 Dec 2004 21:50:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17027 invoked from network); 28 Dec 2004 21:50:54 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 28 Dec 2004 21:50:53 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBSLoQgA095856; Tue, 28 Dec 2004 16:50:49 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, pawel.worach@telia.com Date: Tue, 28 Dec 2004 15:39:38 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> In-Reply-To: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412281539.38333.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 21:50:56 -0000 On Thursday 09 December 2004 04:13 pm, Pawel Worach wrote: > Finally got around to fetch some more info about this. > > boot output and kgdb symbol decodes. > > pcib0: matched entry for 0.15.INTA (src \LPUS:0) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc051d7a7 > stack pointer = 0x10:0xc08208d8 > frame pointer = 0x10:0xc08208ec > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_get_softc+0x7: movl 0x48(%eax),%eax > db> tr > Tracing pid 0 tid 0 td 0xc06eda40 > device_get_softc(c07db4a0,c07d690d,35a,c0820928,c07b0e59) at > device_get_softc+0x7 acpi_pci_link_route_interrupt(0,0,c0820a28,f,41) at > acpi_pci_link_route_interrupt+0x37 Are you still seeing this? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 22:05:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43AB016A4CE; Tue, 28 Dec 2004 22:05:54 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3BE43D1F; Tue, 28 Dec 2004 22:05:53 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBSM5pPK063676; Tue, 28 Dec 2004 17:05:51 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBSM5px7063675; Tue, 28 Dec 2004 17:05:51 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 28 Dec 2004 17:05:51 -0500 From: Bosko Milekic To: John Baldwin Message-ID: <20041228220551.GA62320@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <200412281538.15251.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412281538.15251.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:05:54 -0000 On Tue, Dec 28, 2004 at 03:38:15PM -0500, John Baldwin wrote: > This is what I wondered about earlier in the thread. The problem is that > recursion needs to be a per-allocation (or per-thread) state, not per-zone, > since a zone may be used by multiple threads at the same time. Is it really > desired behavior of the bucket zone that if two threads alloc at the same > time one gets NULL because it sees the other's use and thinks it is > recursing? Not really, but in the bucket zone case it is less of a problem because a failed bucket allocation will just result in a uma_zalloc_internal() from occuring, and the probability of the bucket allocation failing because of that uk_recurse being [bogusely] non-zero and forcing a failure is relatively small, in that it might not be worth the effort of further instrumenting. In theory, the uk_recurse per-keg/zone flag is supposed to protect from re-entry from the VM, but in practise this is only really possible (or should only be possible) with the bucket zone itself. We should not have any OFFPAGE allocations from below (VM) requiring separate slab headers. The uk_recurse flag is imperfect in that sometimes it'll tell you it thinks there is a recursion but when in fact there isn't. As long as the behavior is constrained to solely the bucket zone and the probability of occurance of the latter event is small (even if it does occur for the bucket zone, it is not fatal, like it could be for other zones), it shouldn't matter. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 22:05:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43AB016A4CE; Tue, 28 Dec 2004 22:05:54 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3BE43D1F; Tue, 28 Dec 2004 22:05:53 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBSM5pPK063676; Tue, 28 Dec 2004 17:05:51 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBSM5px7063675; Tue, 28 Dec 2004 17:05:51 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 28 Dec 2004 17:05:51 -0500 From: Bosko Milekic To: John Baldwin Message-ID: <20041228220551.GA62320@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <200412281538.15251.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412281538.15251.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:05:54 -0000 On Tue, Dec 28, 2004 at 03:38:15PM -0500, John Baldwin wrote: > This is what I wondered about earlier in the thread. The problem is that > recursion needs to be a per-allocation (or per-thread) state, not per-zone, > since a zone may be used by multiple threads at the same time. Is it really > desired behavior of the bucket zone that if two threads alloc at the same > time one gets NULL because it sees the other's use and thinks it is > recursing? Not really, but in the bucket zone case it is less of a problem because a failed bucket allocation will just result in a uma_zalloc_internal() from occuring, and the probability of the bucket allocation failing because of that uk_recurse being [bogusely] non-zero and forcing a failure is relatively small, in that it might not be worth the effort of further instrumenting. In theory, the uk_recurse per-keg/zone flag is supposed to protect from re-entry from the VM, but in practise this is only really possible (or should only be possible) with the bucket zone itself. We should not have any OFFPAGE allocations from below (VM) requiring separate slab headers. The uk_recurse flag is imperfect in that sometimes it'll tell you it thinks there is a recursion but when in fact there isn't. As long as the behavior is constrained to solely the bucket zone and the probability of occurance of the latter event is small (even if it does occur for the bucket zone, it is not fatal, like it could be for other zones), it shouldn't matter. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 22:16:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 138AA16A4CE; Tue, 28 Dec 2004 22:16:15 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCD143D39; Tue, 28 Dec 2004 22:16:14 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSMG7rr054761; Wed, 29 Dec 2004 00:16:07 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 88373-09; Wed, 29 Dec 2004 00:16:07 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBSMG77w054758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 00:16:07 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBSMGHFh033189; Wed, 29 Dec 2004 00:16:17 +0200 (EET) (envelope-from ru) Date: Wed, 29 Dec 2004 00:16:16 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041228221616.GA29931@ip.net.ua> References: <41CC9BDA.7020203@DeepCore.dk> <20041224233021.GA43419@ip.net.ua> <41CFEFAF.8040100@DeepCore.dk> <20041227141310.GA95767@ip.net.ua> <41D03AA4.3020908@DeepCore.dk> <20041228110644.GB14010@ip.net.ua> <41D15650.7080504@DeepCore.dk> <20041228152641.GC14010@ip.net.ua> <41D1BAD3.5020804@DeepCore.dk> <41D1CF8C.20802@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <41D1CF8C.20802@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org cc: Soren Schmidt Subject: Re: ATA regression [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:16:15 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Soren, On Tue, Dec 28, 2004 at 10:26:36PM +0100, S?ren Schmidt wrote: > S?ren Schmidt wrote: >=20 > >Oh crap! I just got the first half of the patch in the diff, sorry 'bout= =20 > >that. I'll get the rest along when I get back to the lab tomorrow... >=20 > OK, try this instead, I hope I managed to get it all pulled over this=20 > time... >=20 That one works, thank you! Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0dswqRfpzJluFF4RAroIAJ4+qAnJ7YsRxQf/Yx0QTEN/IrnSogCfV+w0 7Kep1e9QAqXku2AygtAvD64= =CswB -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 22:53:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C547016A4CE for ; Tue, 28 Dec 2004 22:53:03 +0000 (GMT) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D0FE43D1F for ; Tue, 28 Dec 2004 22:53:03 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from [192.168.0.12] (CPE-24-166-129-93.new.rr.com [24.166.129.93]) (authenticated bits=0) by quark.cs.earlham.edu (8.13.1/8.12.9) with ESMTP id iBSMqtvq038975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Dec 2004 17:53:01 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Message-ID: <41D1E3DA.4080704@cs.earlham.edu> Date: Tue, 28 Dec 2004 16:53:14 -0600 From: Skylar Thompson Organization: Earlham College Computer Science Department User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ong Beng Hui References: <41D0FB74.2000901@ispworkshop.com> In-Reply-To: <41D0FB74.2000901@ispworkshop.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE531468BE1618695A0C99DA5" X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on quark.cs.earlham.edu X-Earlham-CS-Dept-MailScanner-Information: Please contact the ISP for more information X-Earlham-CS-Dept-MailScanner: Found to be clean X-MailScanner-From: skylar@cs.earlham.edu cc: current@freebsd.org Subject: Re: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: skylar@cs.earlham.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:53:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE531468BE1618695A0C99DA5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ong Beng Hui wrote: > Hi, > > Looking thru the FreeBSD handbook... > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html > > and Advanced Networking... > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/advanced-networking.html > > > Under Building a Router, it said... > > "Even when FreeBSD is configured in this way, it does not completely > comply with the Internet standard requirements for routers. It comes > close enough for ordinary use, however." > > Could someone advise, in what way FreeBSD doesn't comply with Internet > standard requirements for routers ? Which internet standard it might be > referencing to. The first thing that comes to mind is that FreeBSD doesn't pass on network broadcast packets by default. This violates RFC1812 , which mandates that subnet broadcast packets must be passed on as specified in STD3 . This actually is no longer good practice, so I'd say it's more prudence than an outright design flaw that FreeBSD doesn't comply with this. -- -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --------------enigE531468BE1618695A0C99DA5 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.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0ePhsc4yyULgN4YRAnffAJ9rNtScAYToVLf5tyKT41tQMNo0yACfc6Vj 37CQErxjwJs/ihZvHD1MJSE= =fM7i -----END PGP SIGNATURE----- --------------enigE531468BE1618695A0C99DA5-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 22:59:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD1A16A4CE; Tue, 28 Dec 2004 22:59:31 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A46DB43D45; Tue, 28 Dec 2004 22:59:31 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iBSMxTHC013799; Tue, 28 Dec 2004 14:59:29 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBSMxTto013798; Tue, 28 Dec 2004 14:59:29 -0800 Date: Tue, 28 Dec 2004 14:59:29 -0800 From: Brooks Davis To: Skylar Thompson Message-ID: <20041228225929.GA13275@odin.ac.hmc.edu> References: <41D0FB74.2000901@ispworkshop.com> <41D1E3DA.4080704@cs.earlham.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <41D1E3DA.4080704@cs.earlham.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: doc@freebsd.org cc: current@freebsd.org cc: Ong Beng Hui Subject: Re: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:59:32 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [cc'ing doc since I think this is really a doc issue. Please trim your reply list as needed] On Tue, Dec 28, 2004 at 04:53:14PM -0600, Skylar Thompson wrote: > Ong Beng Hui wrote: >=20 > >Hi, > > > >Looking thru the FreeBSD handbook... > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html > > > >and Advanced Networking... > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/advanced-netwo= rking.html=20 > > > > > >Under Building a Router, it said... > > > >"Even when FreeBSD is configured in this way, it does not completely=20 > >comply with the Internet standard requirements for routers. It comes=20 > >close enough for ordinary use, however." > > > >Could someone advise, in what way FreeBSD doesn't comply with Internet > >standard requirements for routers ? Which internet standard it might be > >referencing to.=20 >=20 > The first thing that comes to mind is that FreeBSD doesn't pass on=20 > network broadcast packets by default. This violates RFC1812=20 > , which mandates that=20 > subnet broadcast packets must be passed on as specified in STD3=20 > . This actually is no=20 > longer good practice, so I'd say it's more prudence than an outright=20 > design flaw that FreeBSD doesn't comply with this. It's highly unlikely that any router ever built met every requirement of every relevant RFC at the time it shipped. As the above example demonstrates, doing so would not only be practically impossible, but quite stupid to boot. This paragraph should be taken out and shot. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB0eVRXY6L6fI4GtQRArBcAJ9WKKjJWbLuk5HJVVQJocunf8biKwCgvChy w4MmMBN3UB1aWckUtdRmWnM= =tpPn -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 23:32:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6508B16A4CE; Tue, 28 Dec 2004 23:32:56 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFB3D43D3F; Tue, 28 Dec 2004 23:32:55 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.6) (authenticated as u86211448) id 4199C6960002AF52; Wed, 29 Dec 2004 00:32:54 +0100 Message-ID: <41D1ED23.6060207@telia.com> Date: Wed, 29 Dec 2004 00:32:51 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20041223) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> In-Reply-To: <200412281539.38333.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 23:32:56 -0000 John Baldwin wrote: > Are you still seeing this? Yes I am, updated boot -v with debug.rman_debug=1 below. Sources are from 16:00 UTC today. Last working kernel I have is from November 20, I can start a binary search if you want. OK set debug.rman_debug=1 OK boot -v /boot/kernel/acpi.ko text=0x488ac data=0x1ea4+0x110c syms=[0x4+0x7320+0x4+0x9889] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009d400 SMAP type=02 base=000000000009d400 len=0000000000002c00 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000003fedb300 SMAP type=02 base=000000003ffe0000 len=0000000000020000 SMAP type=03 base=000000003ffdb300 len=0000000000004d00 SMAP type=02 base=00000000fec00000 len=0000000001400000 Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #0: Tue Dec 28 23:56:00 CET 2004 root@zero:/usr/obj/usr/src/sys/ZERO Preloaded elf kernel "/boot/kernel/kernel" at 0xc07f0000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07f016c. Calibrating clock(s) ... i8254 clock: 1193153 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2793897432 Hz CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 1073590272 (1023 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000828000 - 0x000000003edaafff, 1045966848 bytes (255363 pages) avail memory = 1046142976 (997 MB) MP Configuration Table version 1.4 found at 0xc009e2a0 Table 'FACP' at 0x3ffdff00 Table 'APIC' at 0x3ffdfe80 MADT: Found table at 0x3ffdfe80 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 6 ACPI ID 1: enabled SMP: Added CPU 6 (AP) ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 6, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 bios32: Found BIOS32 Service Directory header at 0xc00fd790 bios32: Entry = 0xfd7a1 (c00fd7a1) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xd7dc pnpbios: Found PnP BIOS data at 0xc00fdf90 pnpbios: Entry = f0000:444c Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 14, Interrupt 0 at 0xfec00000 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) MADT: Found IO APIC ID 13, Interrupt 16 at 0xfec01000 ioapic1: intpin 0 -> PCI IRQ 16 (level, low) ioapic1: intpin 1 -> PCI IRQ 17 (level, low) ioapic1: intpin 2 -> PCI IRQ 18 (level, low) ioapic1: intpin 3 -> PCI IRQ 19 (level, low) ioapic1: intpin 4 -> PCI IRQ 20 (level, low) ioapic1: intpin 5 -> PCI IRQ 21 (level, low) ioapic1: intpin 6 -> PCI IRQ 22 (level, low) ioapic1: intpin 7 -> PCI IRQ 23 (level, low) ioapic1: intpin 8 -> PCI IRQ 24 (level, low) ioapic1: intpin 9 -> PCI IRQ 25 (level, low) ioapic1: intpin 10 -> PCI IRQ 26 (level, low) ioapic1: intpin 11 -> PCI IRQ 27 (level, low) ioapic1: intpin 12 -> PCI IRQ 28 (level, low) ioapic1: intpin 13 -> PCI IRQ 29 (level, low) ioapic1: intpin 14 -> PCI IRQ 30 (level, low) ioapic1: intpin 15 -> PCI IRQ 31 (level, low) MADT: Found IO APIC ID 12, Interrupt 32 at 0xfec02000 ioapic2: intpin 0 -> PCI IRQ 32 (level, low) ioapic2: intpin 1 -> PCI IRQ 33 (level, low) ioapic2: intpin 2 -> PCI IRQ 34 (level, low) ioapic2: intpin 3 -> PCI IRQ 35 (level, low) ioapic2: intpin 4 -> PCI IRQ 36 (level, low) ioapic2: intpin 5 -> PCI IRQ 37 (level, low) ioapic2: intpin 6 -> PCI IRQ 38 (level, low) ioapic2: intpin 7 -> PCI IRQ 39 (level, low) ioapic2: intpin 8 -> PCI IRQ 40 (level, low) ioapic2: intpin 9 -> PCI IRQ 41 (level, low) ioapic2: intpin 10 -> PCI IRQ 42 (level, low) ioapic2: intpin 11 -> PCI IRQ 43 (level, low) ioapic2: intpin 12 -> PCI IRQ 44 (level, low) ioapic2: intpin 13 -> PCI IRQ 45 (level, low) ioapic2: intpin 14 -> PCI IRQ 46 (level, low) ioapic2: intpin 15 -> PCI IRQ 47 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high lapic0: Routing NMI -> LINT1 MADT: Ignoring local NMI routed to ACPI CPU 6 MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 3 polarity: low ioapic0: intpin 3 trigger: level ioapic2 irqs 32-47 on motherboard ioapic1 irqs 16-31 on motherboard ioapic0 irqs 0-15 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 io: mem: Pentium Pro MTRR support enabled null: random: rman_manage_region: request: start 0, end 0x1 rman_manage_region: request: start 0x3, end 0x2f rman_manage_region: request: start 0, end 0x7 rman_manage_region: request: start 0, end 0xffff rman_manage_region: request: start 0, end 0xffffffff rman_reserve_resource: request: [0xf0, 0xf0], length 0x10, flags 0, device npx0 considering [0, 0xffff] truncated region: [0xf0, 0xff]; size 0x10 (requested 0x10) candidate region: [0xff, 0xf0], size 0x10 splitting region in three parts: [0, 0xef]; [0xf0, 0xff]; [0x100, 0xffff] rman_reserve_resource: request: [0xd, 0xd], length 0x1, flags 0, device npx0 considering [0x3, 0x2f] truncated region: [0xd, 0xd]; size 0x1 (requested 0x1) candidate region: [0xd, 0xd], size 0x1 splitting region in three parts: [0x3, 0xc]; [0xd, 0xd]; [0xe, 0x2f] npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard rman_reserve_resource: request: [0x3, 0x3], length 0x1, flags 4, device acpi0 considering [0x3, 0x2f] truncated region: [0x3, 0x3]; size 0x1 (requested 0x1) candidate region: [0x3, 0x3], size 0x1 allocating from the beginning acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80002800 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00141166) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 15 func 2 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 AcpiOsDerivePciId: bus 0 dev 16 func 2 AcpiOsDerivePciId: bus 0 dev 17 func 0 AcpiOsDerivePciId: bus 0 dev 17 func 2 rman_reserve_resource: request: [0x92, 0x92], length 0x1, flags 0, device acpi0 considering [0, 0xffff] truncated region: [0x92, 0x92]; size 0x1 (requested 0x1) candidate region: [0x92, 0x92], size 0x1 splitting region in three parts: [0, 0x91]; [0x92, 0x92]; [0x93, 0xffff] rman_manage_region: request: start 0x92, end 0x92 rman_reserve_resource: request: [0xeb, 0xec], length 0x2, flags 0, device acpi0 considering [0x93, 0xffff] truncated region: [0xeb, 0xec]; size 0x2 (requested 0x2) candidate region: [0xec, 0xeb], size 0x2 splitting region in three parts: [0x93, 0xea]; [0xeb, 0xec]; [0xed, 0xffff] rman_manage_region: request: start 0xeb, end 0xec rman_reserve_resource: request: [0x1ec, 0x1ef], length 0x4, flags 0, device acpi0 considering [0xed, 0xffff] truncated region: [0x1ec, 0x1ef]; size 0x4 (requested 0x4) candidate region: [0x1ef, 0x1ec], size 0x4 splitting region in three parts: [0xed, 0x1eb]; [0x1ec, 0x1ef]; [0x1f0, 0xffff] rman_manage_region: request: start 0x1ec, end 0x1ef rman_reserve_resource: request: [0x600, 0x600], length 0x1, flags 0, device acpi0 considering [0x1f0, 0xffff] truncated region: [0x600, 0x600]; size 0x1 (requested 0x1) candidate region: [0x600, 0x600], size 0x1 splitting region in three parts: [0x1f0, 0x5ff]; [0x600, 0x600]; [0x601, 0xffff] rman_manage_region: request: start 0x600, end 0x600 rman_reserve_resource: request: [0x800, 0x80f], length 0x10, flags 0, device acpi0 considering [0x601, 0xffff] truncated region: [0x800, 0x80f]; size 0x10 (requested 0x10) candidate region: [0x80f, 0x800], size 0x10 splitting region in three parts: [0x601, 0x7ff]; [0x800, 0x80f]; [0x810, 0xffff] rman_manage_region: request: start 0x800, end 0x80f rman_reserve_resource: request: [0xc00, 0xcfe], length 0xff, flags 0, device acpi0 considering [0x810, 0xffff] truncated region: [0xc00, 0xcfe]; size 0xff (requested 0xff) candidate region: [0xcfe, 0xc00], size 0xff splitting region in three parts: [0x810, 0xbff]; [0xc00, 0xcfe]; [0xcff, 0xffff] rman_manage_region: request: start 0xc00, end 0xcfe rman_reserve_resource: request: [0xf50, 0xf58], length 0x9, flags 0, device acpi0 considering [0xcff, 0xffff] truncated region: [0xf50, 0xf58]; size 0x9 (requested 0x9) candidate region: [0xf58, 0xf50], size 0x9 splitting region in three parts: [0xcff, 0xf4f]; [0xf50, 0xf58]; [0xf59, 0xffff] rman_manage_region: request: start 0xf50, end 0xf58 rman_reserve_resource: request: [0xfec00000, 0xffffffff], length 0x1400000, flags 0, device acpi0 considering [0, 0xffffffff] truncated region: [0xfec00000, 0xffffffff]; size 0x1400000 (requested 0x1400000) candidate region: [0xffffffff, 0xfec00000], size 0x1400000 allocating at the end rman_manage_region: request: start 0xfec00000, end 0xffffffff rman_reserve_resource: request: [0x510, 0x517], length 0x8, flags 0, device acpi0 considering [0x1f0, 0x5ff] truncated region: [0x510, 0x517]; size 0x8 (requested 0x8) candidate region: [0x517, 0x510], size 0x8 splitting region in three parts: [0x1f0, 0x50f]; [0x510, 0x517]; [0x518, 0x5ff] rman_manage_region: request: start 0x510, end 0x517 rman_reserve_resource: request: [0x504, 0x507], length 0x4, flags 0, device acpi0 considering [0x1f0, 0x50f] truncated region: [0x504, 0x507]; size 0x4 (requested 0x4) candidate region: [0x507, 0x504], size 0x4 splitting region in three parts: [0x1f0, 0x503]; [0x504, 0x507]; [0x508, 0x50f] rman_manage_region: request: start 0x504, end 0x507 rman_reserve_resource: request: [0x500, 0x503], length 0x4, flags 0, device acpi0 considering [0x1f0, 0x503] truncated region: [0x500, 0x503]; size 0x4 (requested 0x4) candidate region: [0x503, 0x500], size 0x4 allocating at the end rman_manage_region: request: start 0x500, end 0x503 rman_reserve_resource: request: [0x400, 0x4fe], length 0xff, flags 0, device acpi0 considering [0x1f0, 0x4ff] truncated region: [0x400, 0x4fe]; size 0xff (requested 0xff) candidate region: [0x4fe, 0x400], size 0xff splitting region in three parts: [0x1f0, 0x3ff]; [0x400, 0x4fe]; [0x4ff, 0x4ff] rman_manage_region: request: start 0x400, end 0x4fe rman_reserve_resource: request: [0x460, 0x461], length 0x2, flags 0, device acpi0 considering [0x400, 0x4fe] region is allocated considering [0x4ff, 0x4ff] s->r_start (0x4ff) > end (0x461) no unshared regions found acpi0: reservation of 460, 2 (4) failed rman_reserve_resource: request: [0x2e, 0x2f], length 0x2, flags 0, device acpi0 considering [0, 0x91] truncated region: [0x2e, 0x2f]; size 0x2 (requested 0x2) candidate region: [0x2f, 0x2e], size 0x2 splitting region in three parts: [0, 0x2d]; [0x2e, 0x2f]; [0x30, 0x91] rman_manage_region: request: start 0x2e, end 0x2f rman_reserve_resource: request: [0x488, 0x48b], length 0x4, flags 0, device acpi_timer0 considering [0x400, 0x4fe] truncated region: [0x488, 0x48b]; size 0x4 (requested 0x4) candidate region: [0x48b, 0x488], size 0x4 splitting region in three parts: [0x400, 0x487]; [0x488, 0x48b]; [0x48c, 0x4fe] ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 rman_reserve_resource: request: [0x488, 0x48b], length 0x4, flags 0, device acpi_timer0 considering [0x400, 0x4fe] truncated region: [0x488, 0x48b]; size 0x4 (requested 0x4) candidate region: [0x48b, 0x488], size 0x4 splitting region in three parts: [0x400, 0x487]; [0x488, 0x48b]; [0x48c, 0x4fe] cpu0: on acpi0 cpu1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1166, dev=0x0014, revid=0x33 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0014, revid=0x00 bus=0, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0014, revid=0x00 bus=0, slot=0, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base fd000000, size 24, enabled rman_reserve_resource: request: [0xfd000000, 0xfdffffff], length 0x1000000, flags 0, device (null) considering [0, 0xfebfffff] truncated region: [0xfd000000, 0xfdffffff]; size 0x1000000 (requested 0x1000000) candidate region: [0xfdffffff, 0xfd000000], size 0x1000000 splitting region in three parts: [0, 0xfcffffff]; [0xfd000000, 0xfdffffff]; [0xfe000000, 0xfebfffff] map[14]: type 4, range 32, base 00002400, size 8, enabled rman_reserve_resource: request: [0x2400, 0x24ff], length 0x100, flags 0, device (null) considering [0xf59, 0xffff] truncated region: [0x2400, 0x24ff]; size 0x100 (requested 0x100) candidate region: [0x24ff, 0x2400], size 0x100 splitting region in three parts: [0xf59, 0x23ff]; [0x2400, 0x24ff]; [0x2500, 0xffff] map[18]: type 1, range 32, base febff000, size 12, enabled rman_reserve_resource: request: [0xfebff000, 0xfebfffff], length 0x1000, flags 0, device (null) considering [0xfe000000, 0xfebfffff] truncated region: [0xfebff000, 0xfebfffff]; size 0x1000 (requested 0x1000) candidate region: [0xfebfffff, 0xfebff000], size 0x1000 allocating at the end pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 26 found-> vendor=0x1002, dev=0x4752, revid=0x27 bus=0, slot=6, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=26 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1166, dev=0x0201, revid=0x93 bus=0, slot=15, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x2200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) rman_reserve_resource: request: [0x1f0, 0x1f7], length 0x8, flags 0, device (null) considering [0x1f0, 0x3ff] truncated region: [0x1f0, 0x1f7]; size 0x8 (requested 0x8) candidate region: [0x1f7, 0x1f0], size 0x8 allocating from the beginning rman_reserve_resource: request: [0x3f6, 0x3f6], length 0x1, flags 0, device (null) considering [0x1f8, 0x3ff] truncated region: [0x3f6, 0x3f6]; size 0x1 (requested 0x1) candidate region: [0x3f6, 0x3f6], size 0x1 splitting region in three parts: [0x1f8, 0x3f5]; [0x3f6, 0x3f6]; [0x3f7, 0x3ff] rman_reserve_resource: request: [0x170, 0x177], length 0x8, flags 0, device (null) considering [0xed, 0x1eb] truncated region: [0x170, 0x177]; size 0x8 (requested 0x8) candidate region: [0x177, 0x170], size 0x8 splitting region in three parts: [0xed, 0x16f]; [0x170, 0x177]; [0x178, 0x1eb] rman_reserve_resource: request: [0x376, 0x376], length 0x1, flags 0, device (null) considering [0x1f8, 0x3f5] truncated region: [0x376, 0x376]; size 0x1 (requested 0x1) candidate region: [0x376, 0x376], size 0x1 splitting region in three parts: [0x1f8, 0x375]; [0x376, 0x376]; [0x377, 0x3f5] map[20]: type 4, range 32, base 00000700, size 4, enabled rman_reserve_resource: request: [0x700, 0x70f], length 0x10, flags 0, device (null) considering [0x601, 0x7ff] truncated region: [0x700, 0x70f]; size 0x10 (requested 0x10) candidate region: [0x70f, 0x700], size 0x10 splitting region in three parts: [0x601, 0x6ff]; [0x700, 0x70f]; [0x710, 0x7ff] found-> vendor=0x1166, dev=0x0212, revid=0x93 bus=0, slot=15, func=1 class=01-01-82, hdrtype=0x00, mfdev=1 cmdreg=0x0155, statreg=0x0200, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base febfe000, size 12, enabled rman_reserve_resource: request: [0xfebfe000, 0xfebfefff], length 0x1000, flags 0, device (null) considering [0xfe000000, 0xfebfefff] truncated region: [0xfebfe000, 0xfebfefff]; size 0x1000 (requested 0x1000) candidate region: [0xfebfefff, 0xfebfe000], size 0x1000 allocating at the end pcib0: matched entry for 0.15.INTA (src \LPUS:0) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051edc7 stack pointer = 0x10:0xc082095c frame pointer = 0x10:0xc0820970 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at device_get_softc+0x7: movl 0x48(%eax),%eax db> trace Tracing pid 0 tid 0 td 0xc06ef1e0 device_get_softc(c07dd4a0,c07d894d,355,c1e841c0,c1e841c0) at device_get_softc+0x7 acpi_pci_link_route_interrupt(0,0,c0820a28,f,41) at acpi_pci_link_route_interrupt+0x3a acpi_pcib_route_interrupt(c1f16d00,c1f8b780,1,c1f7e214,1) at acpi_pcib_route_interrupt+0x33c acpi_pcib_acpi_route_interrupt(c1f16d00,c1f8b780,1,c06c7850,c1f8b808) at acpi_pcib_acpi_route_interrupt+0x2f pci_assign_interrupt_method(c1f16a00,c1f8b780,f,2,24) at pci_assign_interrupt_method+0x71 pci_add_child(c1f16a00,c1f8b800,f,2,80) at pci_add_child+0x207 pci_add_children(c1f16a00,0,80,c0820b54,c05211cf) at pci_add_children+0x123 acpi_pci_attach(c1f16a00,c1f4484c,c06c0e3c,c06aa034,0) at acpi_pci_attach+0x86 device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c435c,c1f16d00) at device_attach+0x2c9 bus_generic_attach(c1f16d00,c07d8227,0,c0820bcc,0) at bus_generic_attach+0x18 acpi_pcib_attach(c1f16d00,c1f7e214,0,c0820c04,c07bef67) at acpi_pcib_attach+0xec acpi_pcib_acpi_attach(c1f16d00,c1f4384c,c06c0e3c,c06aa034,0) at acpi_pcib_acpi_attach+0xf9 device_attach(c1f16d00,2f,c0820cbc,c07c1794,c1ed5d80) at device_attach+0x2c9 bus_generic_attach(c1ed5d80,2e,2f,c1f7dc48,2e) at bus_generic_attach+0x18 acpi_attach(c1ed5d80,c1f4604c,c06c0e3c,c06aa034,0) at acpi_attach+0x7b4 device_attach(c1ed5d80,c1f15000,c0820d18,c06799ca,c1f15000) at device_attach+0x2c9 bus_generic_attach(c1f15000,c1f1504c,c0820d54,c0520179,c1f15000) at bus_generic_attach+0x18 nexus_attach(c1f15000,c1f3c04c,c06c0e3c,c06aa034,0) at nexus_attach+0x1a device_attach(c1f15000,c06dd2b0,c0820d78,c0666aa8,c1f15680) at device_attach+0x2c9 root_bus_configure(c1f15680,c06bacbe,0,c0820d98,c04d09c6) at root_bus_configure+0x19 configure(0,0,c1e6f774,81ec00,81e000) at configure+0x28 mi_startup() at mi_startup+0xd6 begin() at begin+0x2c (gdb) l *device_get_softc+0x7 0xc051edc7 is in device_get_softc (/usr/src/sys/kern/subr_bus.c:1937). 1932 * on the size field of the driver. 1933 */ 1934 void * 1935 device_get_softc(device_t dev) 1936 { 1937 return (dev->softc); 1938 } 1939 1940 /** 1941 * @brief Set the device's softc field (gdb) l *acpi_pci_link_route_interrupt+0x3a 0x3602a is in acpi_pci_link_route_interrupt (/usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci_link.c:855). 850 { 851 struct link *link; 852 853 ACPI_SERIAL_BEGIN(pci_link); 854 link = acpi_pci_link_lookup(dev, index); 855 if (link == NULL) 856 panic("%s: apparently invalid index %d", __func__, index); 857 858 /* 859 * If this link device is already routed to an interrupt, just return (gdb) l *acpi_pcib_route_interrupt+0x33c 0x327ec is in acpi_pcib_route_interrupt (acpivar.h:208). 203 acpivar.h: No such file or directory. in acpivar.h (gdb) l *acpi_pcib_acpi_route_interrupt+0x2f 0x32daf is in acpi_pcib_acpi_route_interrupt (/usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pcib_acpi.c:303). 298 acpi_pcib_acpi_route_interrupt(device_t pcib, device_t dev, int pin) 299 { 300 struct acpi_hpcib_softc *sc = device_get_softc(pcib); 301 302 return (acpi_pcib_route_interrupt(pcib, dev, pin, &sc->ap_prt)); 303 } 304 305 static u_long acpi_host_mem_start = 0x80000000; 306 TUNABLE_ULONG("hw.acpi.host_mem_start", &acpi_host_mem_start); 307 -- Pawel From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 01:10:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F31916A507 for ; Wed, 29 Dec 2004 01:10:23 +0000 (GMT) Received: from vsmtp3alice.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E32143D45 for ; Wed, 29 Dec 2004 01:10:22 +0000 (GMT) (envelope-from giupil@aliceposta.it) Received: from [82.55.81.74] (82.55.81.74) by vsmtp3alice.tin.it (7.0.027) id 414A736800798A96 for freebsd-current@freebsd.org; Wed, 29 Dec 2004 02:10:21 +0100 Message-ID: <41D203DF.1030002@aliceposta.it> Date: Wed, 29 Dec 2004 02:09:51 +0100 From: giupil User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <228428214@web.de> In-Reply-To: <228428214@web.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [current on amd64] 'make buildworld' failure: /usr/src/lib/libkvm/kvm_proc.c:202: error: structure has no member named `p_uarea' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 01:10:23 -0000 Hi, I've your same system: 1513lmi+Freebsd/amd64. But I've not this problem. My commands: cd /usr/src make update cd /usr/src/lib/libkvm make clean make and the compilation is correct. Well I don't know how I can help you. Bye Giuseppe From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 01:56:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B10E16A4CE for ; Wed, 29 Dec 2004 01:56:53 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD39A43D1D for ; Wed, 29 Dec 2004 01:56:52 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) iBT1ucwN080301; Tue, 28 Dec 2004 17:56:38 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id iBT1uUMi050641; Tue, 28 Dec 2004 17:56:34 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Wed, 29 Dec 2004 10:56:26 +0900 Message-ID: From: "George V. Neville-Neil" To: Brooks Davis In-Reply-To: <20041228225929.GA13275@odin.ac.hmc.edu> References: <41D0FB74.2000901@ispworkshop.com> <41D1E3DA.4080704@cs.earlham.edu> <20041228225929.GA13275@odin.ac.hmc.edu> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable cc: Ong Beng Hui cc: Skylar Thompson cc: current@FreeBSD.org Subject: Re: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 01:56:53 -0000 At Tue, 28 Dec 2004 14:59:29 -0800, Brooks Davis wrote: >=20 > [1 ] > [cc'ing doc since I think this is really a doc issue. Please trim your > reply list as needed] >=20 Sorry to chime in late on this. I suspect the assertion about FreeBSD and building a router does have to do with complete RFC compliance. As Brooks pointed out, no router ever built actually complied with all the RFCs. In another life I worked for a company using the BSD stack in an RTOS and many non-US customers wanted strict adherence to the RFCs and/or specific statements of non-compliance. This is an arduous job that no one is going to do for free (and that company never did it either). =46rom a practical standpoint building an Internet router from FreeBSD is quite "doable" and has been done. Depending on where that router lives the network (core, edge, enterprise, etc.) you will have to customize the system, but then, that's what engineering is about :-) Later, George From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 05:09:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3509C16A4CE for ; Wed, 29 Dec 2004 05:09:18 +0000 (GMT) Received: from sbk-gw.sibnet.ru (sbk-gw.sibnet.ru [217.70.96.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F72643D2F for ; Wed, 29 Dec 2004 05:09:16 +0000 (GMT) (envelope-from stranger@sberbank.sibnet.ru) Received: from sbk-gw.sibnet.ru (localhost [127.0.0.1]) by sbk-gw.sibnet.ru (8.13.1/8.13.1) with ESMTP id iBT58nJL031190; Wed, 29 Dec 2004 11:08:49 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) Received: from localhost (stranger@localhost)iBT58mVh031187; Wed, 29 Dec 2004 11:08:48 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) X-Authentication-Warning: sbk-gw.sibnet.ru: stranger owned process doing -bs Date: Wed, 29 Dec 2004 11:08:47 +0600 (NOVT) From: "Maxim M. Kazachek" X-X-Sender: stranger@sbk-gw.sibnet.ru To: John Nielsen In-Reply-To: <200412231545.32246.lists@jnielsen.net> Message-ID: <20041229110338.A31157@sbk-gw.sibnet.ru> References: <200412221315.47189.lists@jnielsen.net> <20041223121128.G21793@sbk-gw.sibnet.ru> <200412231545.32246.lists@jnielsen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.8 required=7.5 tests=ALL_TRUSTED,AWL,BAYES_20 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on sbk-gw.sibnet.ru cc: freebsd-current@freebsd.org Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 05:09:18 -0000 BTW, many motherboards with AWARD BIOS able to support NCR (or SymBIOS Logic) SCSI controllers. Those that ships without BIOS. So you want to tell, that, for instance, i440BX have SCSI support? You don't need a flash chip for Silicon's BIOS. And, perhaps, you don't need a message for this BIOS. Sincerely, Maxim M. Kazachek mailto:stranger@sberbank.sibnet.ru mailto:stranger@fpm.ami.nstu.ru On Thu, 23 Dec 2004, John Nielsen wrote: > On Wednesday 22 December 2004 11:32 pm, Jeremy Messenger wrote: >> On Thu, 23 Dec 2004 12:19:58 +0600 (NOVT), Maxim M. Kazachek >> >> wrote: >>> MCP 2 doesn't have ANY SATA support. MCP have 6ch codec, 2xATA133, >> >> I have the same (maybe, mine is 7N2 Delta2 Platinum) motherboard as his >> and it does has SATA support. Mine SATA is disabled in BIOS, which I >> don't have any SATA HD. >> >> ===================================== >> ? nVIDIA nForce2 Gigabit MCP Chipset >> - Integrated Ethernet MAC >> - Integrated Hardware Sound Blaster/Direct Sound AC97 audio >> - Ultra DMA 66/100/133 master mode PCI EIDE controller >> - Supports USB 2.0 >> - Integrated SATA Interface >> ===================================== > > It is indeed integrated on this mainboard. Just from looking at the chips > on the board, it appears that the Ethernet and SATA are both handled by the > same MCP2 chip. I was surprised myself not to see a Silicon Image or > silicon image controller/BIOS when I booted it up. > > I haven't yet had any luck with the onboard ethernet, even with the > net/nvnet port. I guess that's what PCI slots are for.. :) > > JN > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 05:11:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA8F716A4CE for ; Wed, 29 Dec 2004 05:11:24 +0000 (GMT) Received: from sbk-gw.sibnet.ru (sbk-gw.sibnet.ru [217.70.96.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id A16DD43D66 for ; Wed, 29 Dec 2004 05:11:23 +0000 (GMT) (envelope-from stranger@sberbank.sibnet.ru) Received: from sbk-gw.sibnet.ru (localhost [127.0.0.1]) by sbk-gw.sibnet.ru (8.13.1/8.13.1) with ESMTP id iBT5Avk7031213; Wed, 29 Dec 2004 11:10:57 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) Received: from localhost (stranger@localhost)iBT5AueY031210; Wed, 29 Dec 2004 11:10:56 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) X-Authentication-Warning: sbk-gw.sibnet.ru: stranger owned process doing -bs Date: Wed, 29 Dec 2004 11:10:56 +0600 (NOVT) From: "Maxim M. Kazachek" X-X-Sender: stranger@sbk-gw.sibnet.ru To: Lawrence Farr In-Reply-To: <20041223211430.517A667AF4@gunfright.epcdirect.co.uk> Message-ID: <20041229110957.W31157@sbk-gw.sibnet.ru> References: <20041223211430.517A667AF4@gunfright.epcdirect.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-5.0 required=7.5 tests=ALL_TRUSTED,AWL,BAYES_20 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on sbk-gw.sibnet.ru cc: freebsd-current@freebsd.org cc: 'Evren Yurtesen' cc: 'Stefan Cars' Subject: RE: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 05:11:25 -0000 Is EM64T is capable to support more that 4Gb RAM? AMD64 does. The news I know told me that Intel have problems with more than 32 bit addressing. Sincerely, Maxim M. Kazachek mailto:stranger@sberbank.sibnet.ru mailto:stranger@fpm.ami.nstu.ru On Thu, 23 Dec 2004, Lawrence Farr wrote: > The Xeon EMT64 is 64 bit, and the amd64 port of FreeBSD runs > on it just fine apparently. > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org >> [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Evren Yurtesen >> Sent: 24 December 2004 07:10 >> To: Stefan Cars >> Cc: freebsd-current@freebsd.org >> Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 >> >> amd64 on intel? I dont think it would work. >> >> You should use i386. >> >> To use amd64, you should get an 64bit AMD processor like AMD Athlon 64 >> http://www.amd.com/us-en/Processors/ProductInformation/0,,30_1 > 18_9484,00.html >> >> Evren >> >> Stefan Cars wrote: >>> Hi! >>> >>> How stable is amd64 on Intel Xeon with EMT64 ? We have a >> new PE 1850 >>> with 4GB memory and two dual 2.8 Xeons. Should I go with >> i386 or amd64 ? >>> Which one is most stable and what will I gain from amd64 ? >>> >>> Kind Regards, >>> Stefan Cars >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 08:30:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C61D16A4CE for ; Wed, 29 Dec 2004 08:30:33 +0000 (GMT) Received: from zed.bpsw.biz (zed.bpsw.biz [67.18.135.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09FE443D39 for ; Wed, 29 Dec 2004 08:30:33 +0000 (GMT) (envelope-from lists@bridgeportsoftware.com) Received: from fez.bpsw.biz (unknown [10.0.1.3]) by zed.bpsw.biz (Postfix) with ESMTP id 0C0635941; Wed, 29 Dec 2004 00:26:31 -0800 (PST) Received: from [10.0.1.53] (gigante.bpsw.biz [10.0.1.53]) by fez.bpsw.biz (Postfix) with ESMTP id A363F3E8854; Wed, 29 Dec 2004 00:30:31 -0800 (PST) In-Reply-To: <20041229110957.W31157@sbk-gw.sibnet.ru> References: <20041223211430.517A667AF4@gunfright.epcdirect.co.uk> <20041229110957.W31157@sbk-gw.sibnet.ru> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Max Campos Date: Wed, 29 Dec 2004 00:30:31 -0800 To: "Maxim M. Kazachek" X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 08:30:33 -0000 Yes it can do > 4GB. We have a few EM64T's running with 8 GB of ram, though not under FreeBSD. - Max On Dec 28, 2004, at 9:10pm, Maxim M. Kazachek wrote: > Is EM64T is capable to support more that 4Gb RAM? AMD64 does. The news > I know told me that Intel have problems with more than 32 bit > addressing. From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 11:36:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9942E16A4CE for ; Wed, 29 Dec 2004 11:36:42 +0000 (GMT) Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id A68ED43D5C for ; Wed, 29 Dec 2004 11:36:41 +0000 (GMT) (envelope-from antoine.brodin@laposte.net) Received: from localhost (82.67.196.50) by mx.laposte.net (7.0.028) (authenticated as antoine.brodin@laposte.net) id 41B63F920078BEFF for freebsd-current@freebsd.org; Wed, 29 Dec 2004 12:36:40 +0100 Date: Wed, 29 Dec 2004 12:36:40 +0100 From: Antoine Brodin To: freebsd-current@freebsd.org Message-Id: <20041229123640.449339e1.antoine.brodin@laposte.net> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: acquiring duplicate lock of same type: "network driver" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 11:36:42 -0000 Hi, Witness reports this on a recent -current box (2 days old) doing nat with pf : acquiring duplicate lock of same type: "network driver" 1st nv0 @ /usr/ports/net/nvnet/work/nvnet/module/../src/if_nv.c:1511 2nd skc0 @ /usr/src/sys/modules/sk/../../pci/if_sk.c:1112 KDB: stack backtrace: witness_checkorder(c2855c44,9,c07316ba,458) at witness_checkorder+0x500 _mtx_lock_flags(c2855c44,0,c07316ba,458,c2ac4e00) at _mtx_lock_flags+0x40 sk_jfree(e5a44340,c28e3000,0,c2857c00,e3c79c80) at sk_jfree+0x33 mb_free_ext(c2ac4e00) at mb_free_ext+0x36 m_freem(c2ac4e00,c2857c00,e5901000,e56fb0e0,c2857e60) at m_freem+0x21 nv_ospackettx(c2857c00,e56fb0e0,1,e5901000,0) at nv_ospackettx+0x73 UpdateTransmitDescRingData() at UpdateTransmitDescRingData+0xd3 (it probably happened before but I didn't have witness enabled) This could perhaps deadlock a box with 2 sk(4) interfaces... Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 12:44:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF8E16A4CE for ; Wed, 29 Dec 2004 12:44:34 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBA643D31 for ; Wed, 29 Dec 2004 12:44:34 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so16402wri for ; Wed, 29 Dec 2004 04:44:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ayYUu+dIdTGru6ycPKFFZFcfJeutD3SNivNQ8/z8673igKPXjns0xOsqyzG6F3hn9yydC85amiwwbLkBt8ySIy3msJ1iEW5pxr+z7Ho9OA77g5PMJcxFH24hzMnNco40GDjSzImO556F0LmP0LGTmm8J8FpcNJd7CuodvR5LO/g= Received: by 10.54.11.9 with SMTP id 9mr131894wrk; Wed, 29 Dec 2004 04:44:33 -0800 (PST) Received: by 10.54.57.76 with HTTP; Wed, 29 Dec 2004 04:44:33 -0800 (PST) Message-ID: <34cb7c840412290444497d2dd7@mail.gmail.com> Date: Wed, 29 Dec 2004 12:44:33 +0000 From: Peter Edwards To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , "Li-Lun Wang (Leland Wang)" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_487_11899736.1104324273433" References: cc: current@freebsd.org Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: peadar@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 12:44:34 -0000 ------=_Part_487_11899736.1104324273433 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 25 Dec 2004 19:26:57 +0100, Dag-Erling Sm=F8rgrav wrot= e: > Yesterday's -CURRENT fails to attach the onboard fxp on my Gigabyte > motherboard: >=20 > fxp0: port 0xb000-0xb03f mem 0= xfb050000-0xfb050fff irq 20 at device 8.0 on pci2 > fxp0: Disabling dynamic standby mode in EEPROM > fxp0: New EEPROM ID: 0xfffd > fxp0: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9 > fxp0: MII without any PHY! > device_attach: fxp0 attach returned 6 I had this problem, but had put it down to dodgy hardware. Seeing as a few = other people saw it, I had a look: It turns out that the problems are due to the base address register for the device's memory range being bogus when you get into fxp_attach. Tracing further, it looks like on waking up from D3 into D0, the fxp device needs some time to settle, or the config write to restore the BAR doesn't "take". That explains why it works if it's dragged in from the loader: the device probes without ever going to sleep. The attached ugly hack makes my fxp module behave. I'm not sure if this is a good idea for the general case, or if a quirk entry of some sort might be preferrable. I'd imagine this is probably an issue that might happen with other devices. Any PCI gurus have an opinion? --=20 peadar ------=_Part_487_11899736.1104324273433 Content-Type: text/plain; name="pcipatch.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pcipatch.txt" ? sys/dev/pci/.pci.c.swp ? sys/dev/pci/.swp Index: sys/dev/pci/pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/FreeBSD-CVS/src/sys/dev/pci/pci.c,v retrieving revision 1.273 diff -u -r1.273 pci.c --- sys/dev/pci/pci.c=098 Dec 2004 04:35:19 -0000=091.273 +++ sys/dev/pci/pci.c=0929 Dec 2004 12:38:48 -0000 @@ -534,9 +534,11 @@ =09=09default: =09=09=09result =3D EINVAL; =09=09} -=09=09if (result =3D=3D 0) +=09=09if (result =3D=3D 0) { =09=09=09PCI_WRITE_CONFIG(dev, child, cfg->pp.pp_status, status, =09=09=09=09=09 2); +=09=09=09DELAY(10); +=09=09} =09} else { =09=09result =3D ENXIO; =09} ------=_Part_487_11899736.1104324273433-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 13:36:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28F0B16A4CE for ; Wed, 29 Dec 2004 13:36:08 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDF5C43D31 for ; Wed, 29 Dec 2004 13:36:07 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so26028wri for ; Wed, 29 Dec 2004 05:36:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=UfpTW0tcyWq/k1jccnMnqDTTbOVKM3WmUDQYitfii1Zgo4kS334vHGV1+iDzz/7663sCm+E6WthnbUTHIGhzvV3SlB+VgVImkTPf273EpCdpTktjg3lNoqdb63trf9hlWHu6YKnJKySnpYo4DJdI1AR0m5rHzyNeuEC5xQwIuf8= Received: by 10.54.5.32 with SMTP id 32mr151247wre; Wed, 29 Dec 2004 05:36:07 -0800 (PST) Received: by 10.54.7.75 with HTTP; Wed, 29 Dec 2004 05:36:07 -0800 (PST) Message-ID: <6eb82e04122905361ccd6af0@mail.gmail.com> Date: Wed, 29 Dec 2004 21:36:07 +0800 From: Rong-En Fan To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rong-En Fan List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 13:36:08 -0000 Hello, I'm playing with WPA-PSK (AES and TKIP) with my Linksys WRT54G on recently current, but no luck :( Basically I use [http://people.zoy.org/~hpreg/wifi/] to set up my ap and wpa_supplicant. Somehow, I can associate to the ap and ifconfig ath0 does show the key. but i can't send any packet or receive any packet. I found that the transmission key is changing every 1 second?? I don't think this is right. My notebook is IBM X31 with built-in Atheros a/b/g. And wrt54g's wpa-psk works fine under windows. So, is there any information that i can provide to work this out? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 13:40:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80F7516A4CE; Wed, 29 Dec 2004 13:40:51 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0737F43D1D; Wed, 29 Dec 2004 13:40:51 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id C2890530C; Wed, 29 Dec 2004 14:40:49 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id A580E5308; Wed, 29 Dec 2004 14:40:28 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 25BD1B874; Wed, 29 Dec 2004 14:40:28 +0100 (CET) To: peadar@freebsd.org References: <34cb7c840412290444497d2dd7@mail.gmail.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 29 Dec 2004 14:40:28 +0100 In-Reply-To: <34cb7c840412290444497d2dd7@mail.gmail.com> (Peter Edwards's message of "Wed, 29 Dec 2004 12:44:33 +0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: "Li-Lun Wang \(Leland Wang\)" cc: current@freebsd.org Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 13:40:51 -0000 Peter Edwards writes: > Tracing further, it looks like on waking up from D3 into D0, the fxp > device needs some time to settle, or the config write to restore the > BAR doesn't "take". That explains why it works if it's dragged in from > the loader: the device probes without ever going to sleep. That explains why the problem disappeared when I compiled fxp into the kernel. Great detective work! I'll test your patch and let you know if it works for me. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 13:53:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C922E16A4CE; Wed, 29 Dec 2004 13:53:38 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 423A243D2F; Wed, 29 Dec 2004 13:53:38 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CjeGc-0001Hp-5h; Wed, 29 Dec 2004 16:53:34 +0300 From: Vladimir Grebenschikov To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 29 Dec 2004 16:53:33 +0300 Message-Id: <1104328413.4852.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: peadar@freebsd.org cc: "current@freebsd.org" Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 13:53:38 -0000 =D0=92 =D1=81=D1=80, 29/12/2004 =D0=B2 14:40 +0100, Dag-Erling Sm=C3=B8rgra= v =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Peter Edwards writes: > > Tracing further, it looks like on waking up from D3 into D0, the fxp > > device needs some time to settle, or the config write to restore the > > BAR doesn't "take". That explains why it works if it's dragged in from > > the loader: the device probes without ever going to sleep. >=20 > That explains why the problem disappeared when I compiled fxp into the > kernel. Great detective work! I'll test your patch and let you know > if it works for me. Good research ! I have seen this bug twice, and both times it disappears after some days and influenced by previous loaded OS, module reload and etc.=20 > DES --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 14:46:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB55C16A4CE for ; Wed, 29 Dec 2004 14:46:04 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4990F43D5E for ; Wed, 29 Dec 2004 14:46:04 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so24552wri for ; Wed, 29 Dec 2004 06:46:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FBJFNkLVpYTdz3CoajUMxm8jvMx3RDGh4yeLRxduen9+UPtjoJnkdFuvXFs1wXRmhwcYNK7V3ws8iNNM6XDiYbkuKp9avJ+rBTMNbzAs67vuAjN9ackxlDtn+G5NE3URGht7iDoBBXQvu2tNl/IC8MyHMQXNoZR5PkEVm4SNDFo= Received: by 10.54.53.76 with SMTP id b76mr173644wra; Wed, 29 Dec 2004 06:46:03 -0800 (PST) Received: by 10.54.57.76 with HTTP; Wed, 29 Dec 2004 06:46:03 -0800 (PST) Message-ID: <34cb7c840412290646f4392bd@mail.gmail.com> Date: Wed, 29 Dec 2004 14:46:03 +0000 From: Peter Edwards To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <34cb7c840412290444497d2dd7@mail.gmail.com> cc: "Li-Lun Wang \(Leland Wang\)" cc: current@freebsd.org Subject: Re: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: peadar@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 14:46:04 -0000 Actually, looking at: http://www.intel.com/technology/IAPC/downloads/pm1_1.pdf If I'm reading it right, the delays for each state change need to be implemented as per the "minimum system software guaranteed delays" column in table 18 (in section 5.6.1, on page 50) I'll fix up the patch to implement this, and post it for review if no one gets there before me. On Wed, 29 Dec 2004 14:40:28 +0100, Dag-Erling Sm=F8rgrav wrot= e: > Peter Edwards writes: > > Tracing further, it looks like on waking up from D3 into D0, the fxp > > device needs some time to settle, or the config write to restore the > > BAR doesn't "take". That explains why it works if it's dragged in from > > the loader: the device probes without ever going to sleep. >=20 > That explains why the problem disappeared when I compiled fxp into the > kernel. Great detective work! I'll test your patch and let you know > if it works for me. >=20 > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 16:19:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A3F516A4CE for ; Wed, 29 Dec 2004 16:19:54 +0000 (GMT) Received: from avout3.midco.net (avout3.midco.net [24.220.0.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B23A843D1D for ; Wed, 29 Dec 2004 16:19:53 +0000 (GMT) (envelope-from pmes@bis.midco.net) Received: (qmail 26879 invoked by uid 1009); 29 Dec 2004 16:19:53 -0000 Received: from pmes@bis.midco.net by avout3 by uid 1003 with qmail-scanner-1.22 (f-prot: 4.4.2/3.14.11. Clear:RC:1(24.220.217.79):. Processed in 0.011793 secs); 29 Dec 2004 16:19:53 -0000 X-Qmail-Scanner-Mail-From: pmes@bis.midco.net via avout3 X-Qmail-Scanner: 1.22 (Clear:RC:1(24.220.217.79):. Processed in 0.011793 secs) Received: from host-79-217-220-24.midco.net (HELO [10.0.0.3]) ([24.220.217.79]) (envelope-sender ) by avout3.midco.net (qmail-ldap-1.03) with SMTP for ; 29 Dec 2004 16:19:53 -0000 In-Reply-To: References: <41D0FB74.2000901@ispworkshop.com> <41D1E3DA.4080704@cs.earlham.edu> <20041228225929.GA13275@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <778E3F3E-59B5-11D9-AB97-000D936BE398@bis.midco.net> Content-Transfer-Encoding: 7bit From: Peter Schultz Date: Wed, 29 Dec 2004 10:19:51 -0600 To: "George V. Neville-Neil" X-Mailer: Apple Mail (2.619) cc: Ong Beng Hui cc: Skylar Thompson cc: current@FreeBSD.org Subject: Re: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 16:19:54 -0000 On Dec 28, 2004, at 7:56 PM, George V. Neville-Neil wrote: > At Tue, 28 Dec 2004 14:59:29 -0800, > Brooks Davis wrote: >> >> [1 ] >> [cc'ing doc since I think this is really a doc issue. Please trim >> your >> reply list as needed] >> > > Sorry to chime in late on this. I suspect the assertion about FreeBSD > and building a router does have to do with complete RFC compliance. > As Brooks pointed out, no router ever built actually complied with all > the RFCs. I got into FreeBSD starting with release 3.2, and I remember reading and asking about this then. The answer I got was not as explanatory, it was more like, "FreeBSD routing works great, get 'er done!" How about changing it around to put FreeBSD in a more positive light: FreeBSD is a highly reliable solution for your routing needs. However, configured in this way, it does not completely comply with the Internet standard requirements for routers. The fact is, these same standards are not implemented by dedicated routing hardware either, and not only that, but it would be unwise to implement some of them. Or something like that, so that people don't jump to the conclusion that FreeBSD is behind the times or somehow inferior. Cheers, Pete... From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 16:41:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8912016A4CE for ; Wed, 29 Dec 2004 16:41:12 +0000 (GMT) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 239F443D2F for ; Wed, 29 Dec 2004 16:41:12 +0000 (GMT) (envelope-from don@SANDVINE.com) 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.0.6603.0 Date: Wed, 29 Dec 2004 11:40:10 -0500 Message-ID: <2BCEB9A37A4D354AA276774EE13FB8C219AE75@mailserver.sandvine.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: machine hangs with ida(4), can't panic Thread-Index: AcTtxQ3d27Kj0hS/SWSftVFdvwTplw== From: "Don Bowman" To: Subject: machine hangs with ida(4), can't panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 16:41:12 -0000 I have a machine running 5.3. It is a compaq dl380. It has ida0: as the controller for the disk. It has hung a couple of times in the last week in 'getblk'. When I try to panic it, I get 'ida_command: out of QCBs' (as below). I'm not exactly sure what the 'QCB' is, a control block for the scsi controller of some sort. Can these be tuned up? could there be a leak? ida0: port 0x2000-0x20ff mem 0xc4000000-0xc4ffffff,0xc5000000-0xc5ffffff irq 10 at device 1.0 on pci0 ida0: [GIANT-LOCKED] ida0: drives=3D2 firm_rev=3D1.42 idad0: on ida0 idad0: 12498MB (25597920 sectors), blocksize=3D512 idad1: on ida0 idad1: 115180MB (235889280 sectors), blocksize=3D512 Mounting root from ufs:/dev/idad0s2a db> call doadump Dumping 1279 MB ida_command: out of QCBs Dump failed writing header (35) ida_command: out of QCBs Dump failed writing data (35) ida_command: out of QCBs Dump failed writing trailer (35) Dump complete From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 17:24:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B604716A4CE; Wed, 29 Dec 2004 17:24:10 +0000 (GMT) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DC4043D54; Wed, 29 Dec 2004 17:24:10 +0000 (GMT) (envelope-from aurelien.nephtali@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1004.wanadoo.fr (SMTP Server) with SMTP id 916352400162; Wed, 29 Dec 2004 18:24:08 +0100 (CET) Received: from [192.168.2.30] (ca-sqy-4-49.w80-8.abo.wanadoo.fr [80.8.57.49]) by mwinf1004.wanadoo.fr (SMTP Server) with ESMTP id A30432400173; Wed, 29 Dec 2004 18:24:07 +0100 (CET) Message-ID: <41D2E837.8030105@wanadoo.fr> Date: Wed, 29 Dec 2004 18:24:07 +0100 From: Aurelien Nephtali User-Agent: Mozilla Thunderbird 1.0 (X11/20041219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: exclusive sleep mutex acpica subsystem lock r = 0 (0xc14d5300)locked @ /usr/src,/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:360 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 17:24:10 -0000 Hi, I got this at boot with a fresh -CURRENT : Sleeping on "acsem" with the following non-sleepable locks held: exclusive sleep mutex acpica subsystem lock r = 0 (0xc14d5300) locked @ /usr/src /sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:360 KDB: stack backtrace: witness_warn(5,c14d5480,c082b6fb,c0a765dd,c9b7fbe8) at witness_warn+0x1a8 msleep(c14d5480,c14d5480,100,c0a765dd,0) at msleep+0x37 AcpiOsWaitSemaphore(c14d5480,1,ffff,c14dee00,1) at AcpiOsWaitSemaphore+0x140 AcpiUtAcquireMutex(7,c14dee00,18,c9b7fc9c,c0a6a962) at AcpiUtAcquireMutex+0x55 AcpiDisableGpe(0,18,1,c13ee520,c9b7fcb0) at AcpiDisableGpe+0x17 EcGpeHandler(c14dee00,0,c14ee100,c9b7fce4,c0a4acb1) at EcGpeHandler+0x1a AcpiEvGpeDispatch(c13ee520,18,51,3,1000000) at AcpiEvGpeDispatch+0x81 AcpiEvGpeDetect(c14f3650,c14f4c80,c9b7fd1c,c05ffb36,c14f3650) at AcpiEvGpeDetect +0xd1 AcpiEvSciXruptHandler(c14f3650,0,0,c1423000,0) at AcpiEvSciXruptHandler+0x13 ithread_loop(c141c900,c9b7fd48,c141c900,c05ff998,0) at ithread_loop+0x19e fork_exit(c05ff998,c141c900,c9b7fd48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc9b7fd7c, ebp = 0 --- naboo# uname -a FreeBSD naboo 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Wed Dec 29 10:00:40 CET 2004 dak@naboo:/usr/obj/usr/src/sys/GENERIC i386 -- NEPHTALI 'dak' Aurelien TEK2 - Promo 2008 06.19.84.90.10 From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 19:17:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 419A316A4CE for ; Wed, 29 Dec 2004 19:17:19 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B1143D46 for ; Wed, 29 Dec 2004 19:17:18 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C182051194; Wed, 29 Dec 2004 11:17:13 -0800 (PST) Date: Wed, 29 Dec 2004 11:17:13 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041229191713.GA24848@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: INVARIANTS panics on RELENG_5 and HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 19:17:19 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm regularly getting panics of the following form, on both RELENG_5 systems (UP and SMP sparc64) and HEAD (UP amd64): Memory modified after free 0xfffff8000446c800(504) val=deadc0dd @ 0xfffff8000446c920 panic: Most recently used by file desc cpuid = 2 KDB: enter: panic Dumping 512 MB (1 chunks) chunk at 0: 536870912 bytes |\^H --- #0 doadump () at ../../../kern/kern_shutdown.c:246 246 savectx(&dumppcb); (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:246 #1 0x00000000c005dbf4 in db_fncall (dummy1=0, dummy2=0, dummy3=4, dummy4=0xddb4aaf0 "") at ../../../ddb/db_command.c:531 #2 0x00000000c005dde4 in db_command_loop () at ../../../ddb/db_command.c:349 #3 0x00000000c0060808 in db_trap (type=107, code=0) at ../../../ddb/db_main.c:210 #4 0x00000000c015afa8 in kdb_trap (type=107, code=0, tf=0x1) at ../../../kern/subr_kdb.c:418 #5 0x00000000c02ac0e0 in trap (tf=0xddb4aec0) at ../../../sparc64/sparc64/trap.c:308 #6 0x00000000c015a9b8 in kdb_enter (msg=---Can't read userspace from dump, or kernel process--- ) at ../../../kern/subr_kdb.c:238 #7 0x00000000c015a9b0 in kdb_enter (msg=0xc0343988 "panic") at ../../../kern/subr_kdb.c:238 #8 0x00000000c013e47c in panic (fmt=0xc035e3a8 "Most recently used by %s\n") at ../../../kern/kern_shutdown.c:527 #9 0x00000000c028dd5c in mtrash_ctor (mem=0xc03400b8, size=71748088, arg=0x0, flags=258) at ../../../vm/uma_dbg.c:134 #10 0x00000000c028ca8c in uma_zalloc_arg (zone=0xfffff8001e3fcee0, udata=0x0, flags=258) at ../../../vm/uma_core.c:1826 #11 0x00000000c0133d68 in malloc (size=5, type=0xc0381118, flags=507507200) at uma.h:274 #12 0x00000000c011d320 in fdinit (fdp=0x689) at ../../../kern/kern_descrip.c:1409 #13 0x00000000c011d4a8 in fdcopy (fdp=0xfffff80016ed2800) at ../../../kern/kern_descrip.c:1462 #14 0x00000000c0128128 in fork1 (td=0xfffff80011d37710, flags=20, pages=0, procp=0xddb4b6a8) at ../../../kern/kern_fork.c:432 #15 0x00000000c0128d10 in fork (td=0x40349548, uap=0xddb4b8c0) at ../../../kern/kern_fork.c:97 #16 0x00000000c02ac4a0 in syscall (tf=0xddb4b880) at ../../../sparc64/sparc64/trap.c:593 Memory modified after free 0xffffff001235b000(4088) val=adc0de @ 0xffffff001235bac4 panic: Most recently used by subproc KDB: enter: panic [thread pid 72540 tid 100233 ] Stopped at kdb_enter+0x2f: nop dbtr Tracing pid 72540 tid 100233 td 0xffffff0011c8fc80 kdb_enter() at kdb_enter+0x2f panic() at panic+0x1d2 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x421 malloc() at malloc+0x9c sigacts_alloc() at sigacts_alloc+0x1f fork1() at fork1+0x118a fork() at fork+0x1c syscall() at syscall+0x4ab Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (2, FreeBSD ELF64, fork), rip = 0x8009176c0, rsp = 0x7fffffffe1d8, rbp = 0x527000 --- Memory modified after free 0xfffff80010400200(504) val=deadc0dd @ 0xfffff80010400320 panic: Most recently used by subproc cpuid = 1 KDB: enter: panic [thread 100139] Stopped at kdb_enter+0x38: ta %xcc, 1 db> tr panic() at panic+0x19c mtrash_ctor() at mtrash_ctor+0x7c uma_zalloc_arg() at uma_zalloc_arg+0x42c malloc() at malloc+0xa8 sysarch() at sysarch+0x1b4 syscall() at syscall+0x220 -- syscall (165, FreeBSD ELF64, sysarch) %o7=0x40370a9c -- I'm also getting other panics relating to the filedesc code, on RELENG_5: panic: fdrop: count < 0 panic messages: --- panic: fdrop: count < 0 cpuid = 2 KDB: enter: panic Dumping 512 MB (1 chunks) chunk at 0: 536870912 bytes |\^H --- #0 doadump () at ../../../kern/kern_shutdown.c:246 246 savectx(&dumppcb); (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:246 #1 0x00000000c005d9d4 in db_fncall (dummy1=3, dummy2=0, dummy3=-1, dummy4=0xd6918de0 "") at ../../../ddb/db_command.c:531 #2 0x00000000c005dbc4 in db_command_loop () at ../../../ddb/db_command.c:349 #3 0x00000000c0060608 in db_trap (type=107, code=0) at ../../../ddb/db_main.c:210 #4 0x00000000c0167dc8 in kdb_trap (type=107, code=0, tf=0x1) at ../../../kern/subr_kdb.c:418 #5 0x00000000c02d30a4 in trap (tf=0xd69191b0) at ../../../sparc64/sparc64/trap.c:308 #6 0x00000000c01677d8 in kdb_enter (msg=---Can't read userspace from dump, or kernel process--- ) at ../../../kern/subr_kdb.c:238 #7 0x00000000c01677d0 in kdb_enter (msg=0xc03675c0 "panic") at ../../../kern/subr_kdb.c:238 #8 0x00000000c0148d34 in panic (fmt=0xc0364f80 "fdrop: count < 0") at atomic.h:278 #9 0x00000000c0120804 in fdrop_locked (fp=0xfffff80008c9d730, td=0xfffff8001775b480) at ../../../kern/kern_descrip.c:2092 #10 0x00000000c01208a8 in closef (fp=0xfffff80008c9d730, td=0xfffff8001775b480) at ../../../kern/kern_descrip.c:1883 #11 0x00000000c0120f54 in close (td=0xfffff8001775b480, uap=0x4) at ../../../kern/kern_descrip.c:997 #12 0x00000000c02d348c in syscall (tf=0xd6919880) at ../../../sparc64/sparc64/trap.c:593 (kgdb) --- panic: trap: fast data access mmu miss cpuid = 2 KDB: enter: panic Dumping 512 MB (1 chunks) chunk at 0: 536870912 bytes |\^H --- #0 doadump () at ../../../kern/kern_shutdown.c:246 246 savectx(&dumppcb); (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:246 #1 0x00000000c005d9d4 in db_fncall (dummy1=0, dummy2=0, dummy3=4, dummy4=0xd76a2a70 "") at ../../../ddb/db_command.c:531 #2 0x00000000c005dbc4 in db_command_loop () at ../../../ddb/db_command.c:349 #3 0x00000000c0060608 in db_trap (type=107, code=0) at ../../../ddb/db_main.c:210 #4 0x00000000c0167dc8 in kdb_trap (type=107, code=0, tf=0x1) at ../../../kern/subr_kdb.c:418 #5 0x00000000c02d30a4 in trap (tf=0xd76a2e40) at ../../../sparc64/sparc64/trap.c:308 #6 0x00000000c01677d8 in kdb_enter (msg=---Can't read userspace from dump, or kernel process--- ) at ../../../kern/subr_kdb.c:238 #7 0x00000000c01677d0 in kdb_enter (msg=0xc03675c0 "panic") at ../../../kern/subr_kdb.c:238 #8 0x00000000c0148d34 in panic (fmt=0xc037f2c8 "trap: %s") at atomic.h:278 #9 0x00000000c02d2fbc in trap (tf=0xd76a3240) at ../../../sparc64/sparc64/trap.c:370 #10 0x00000000c013e2a4 in _mtx_lock_sleep (m=0x0, td=0xfffff800026ee7b0, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:531 #11 0x00000000c013e2f0 in _mtx_lock_sleep (m=0xfffff80018e32a48, td=0xfffff800026ee7b0, opts=0, file=0x0, line=0) at atomic.h:278 #12 0x00000000c0121938 in fdfree (td=0xfffff800026ee7b0) at ../../../kern/kern_descrip.c:1596 #13 0x00000000c012aad8 in exit1 (td=0xfffff800026ee7b0, rv=0) at ../../../kern/kern_exit.c:231 #14 0x00000000c012bdb0 in sys_exit (td=0xfffff800026ee7b0, uap=0xd76a38c0) at ../../../kern/kern_exit.c:94 #15 0x00000000c02d348c in syscall (tf=0xd76a3880) at ../../../sparc64/sparc64/trap.c:593 (kgdb) --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0wK5Wry0BWjoQKURAn8oAKDKhfndkeJlRVafE4ss8IFKUcjuqACcDsoj OKozgQtWnH5zmfskUoKOsmk= =3N1q -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 20:28:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B9A916A4CE for ; Wed, 29 Dec 2004 20:28:48 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB70C43D53 for ; Wed, 29 Dec 2004 20:28:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iBTKSsNi015534; Wed, 29 Dec 2004 12:28:54 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBTKSs4L015533; Wed, 29 Dec 2004 12:28:54 -0800 Date: Wed, 29 Dec 2004 12:28:54 -0800 From: Brooks Davis To: Peter Schultz Message-ID: <20041229202854.GC10293@odin.ac.hmc.edu> References: <41D0FB74.2000901@ispworkshop.com> <41D1E3DA.4080704@cs.earlham.edu> <20041228225929.GA13275@odin.ac.hmc.edu> <778E3F3E-59B5-11D9-AB97-000D936BE398@bis.midco.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <778E3F3E-59B5-11D9-AB97-000D936BE398@bis.midco.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: "George V. Neville-Neil" cc: Ong Beng Hui cc: Skylar Thompson cc: current@FreeBSD.org Subject: Re: FreeBsd as internet router X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 20:28:48 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 29, 2004 at 10:19:51AM -0600, Peter Schultz wrote: > On Dec 28, 2004, at 7:56 PM, George V. Neville-Neil wrote: > >At Tue, 28 Dec 2004 14:59:29 -0800, > >Brooks Davis wrote: > >> > >>[1 ] > >>[cc'ing doc since I think this is really a doc issue. Please trim=20 > >>your > >>reply list as needed] > >> > > > >Sorry to chime in late on this. I suspect the assertion about FreeBSD > >and building a router does have to do with complete RFC compliance. > >As Brooks pointed out, no router ever built actually complied with all > >the RFCs. >=20 > I got into FreeBSD starting with release 3.2, and I remember reading=20 > and asking about this then. The answer I got was not as explanatory,=20 > it was more like, "FreeBSD routing works great, get 'er done!" How=20 > about changing it around to put FreeBSD in a more positive light: >=20 > FreeBSD is a highly reliable solution for your routing needs. > However, configured in this way, it does not completely comply > with the Internet standard requirements for routers. The fact is, > these same standards are not implemented by dedicated routing > hardware either, and not only that, but it would be unwise to > implement some of them. >=20 > Or something like that, so that people don't jump to the conclusion=20 > that FreeBSD is behind the times or somehow inferior. The offending paragraph has been taken out and shot. If someone find a real issue we will document it, but until then, the warning serves not purpose. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB0xOFXY6L6fI4GtQRAtvpAJ9JoLG+zF3CWazX01HS8YuLrhI2bACgqzxE QoFrMSaF88JPPc5Tf1PjDAg= =g4yH -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:03:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6EB416A4CE; Wed, 29 Dec 2004 21:03:18 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CED3543D31; Wed, 29 Dec 2004 21:03:17 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([193.28.87.111]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBTL3CYj005741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 22:03:14 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D31B8E.7030305@portaone.com> Date: Wed, 29 Dec 2004 23:03:10 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: re@FreeBSD.ORG cc: "current@freebsd.org" Subject: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:03:18 -0000 Does anybody knows if subject is possible? I guess that it is not due to usage of vn(4) in the release building process, has anybody any insights about actual state of things and/or another potential problems in mind. If the only problem is vn(4) vs. md(4), I think it can be solved quite easily, while providing a good way to avoid having separate test machines for oldest branches. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:09:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F401816A4CE; Wed, 29 Dec 2004 21:09:04 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7652743D58; Wed, 29 Dec 2004 21:09:04 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr6so.prod.shaw.ca (pd4mr6so-qfe3.prod.shaw.ca [10.0.141.69])2004)) with ESMTP id <0I9I0024B5F4ZHF0@l-daemon>; Wed, 29 Dec 2004 14:09:04 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd4mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9I00GDW5F45G90@pd4mr6so.prod.shaw.ca>; Wed, 29 Dec 2004 14:09:04 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I9I00M3K5F3O4@l-daemon>; Wed, 29 Dec 2004 14:09:04 -0700 (MST) Date: Wed, 29 Dec 2004 13:09:02 -0800 From: Colin Percival In-reply-to: <41D31B8E.7030305@portaone.com> To: Maxim Sobolev Message-id: <41D31CEE.5040803@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=KOI8-U Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <41D31B8E.7030305@portaone.com> User-Agent: Mozilla Thunderbird 0.9 (X11/20041107) cc: re@freebsd.org cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:09:05 -0000 Maxim Sobolev wrote: > Does anybody knows if subject is possible? I guess that it is not due to > usage of vn(4) in the release building process, has anybody any insights > about actual state of things and/or another potential problems in mind. > If the only problem is vn(4) vs. md(4), I think it can be solved quite > easily, while providing a good way to avoid having separate test > machines for oldest branches. I'm fairly certain that this is possible; certainly what I do on my FreeBSD Update buildbox (building 4.x worlds and kernels inside jails while running a 5.x kernel) is pretty much equivalent. One problem you may encounter involves /dev -- you'll need to mount a devfs inside the 4.x chroot rather than trying to MAKEDEV everything. I'm not sure if the `make release` code handles this. Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:33:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CB8616A4CE for ; Wed, 29 Dec 2004 21:33:33 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id D426743D1D for ; Wed, 29 Dec 2004 21:33:32 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I9I00CN76JVQQ@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Wed, 29 Dec 2004 22:33:31 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Wed, 29 Dec 2004 22:33:31 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149])iBTLXUwj024808 for ; Wed, 29 Dec 2004 22:33:30 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id 79D7F2842E for ; Wed, 29 Dec 2004 22:33:25 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id D002622859; Wed, 29 Dec 2004 22:33:24 +0100 (CET) Date: Wed, 29 Dec 2004 22:33:24 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20041229213324.GD759@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=Lb0e7rgc7IsuDeGj; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Subject: Looking for vge(4) users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:33:33 -0000 --Lb0e7rgc7IsuDeGj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, if you're using the vge(4) driver and you're willing to test a patch, please do the following: 1. Apply the patch located at: http://people.freebsd.org/~brueffer/vge_altq.diff 2. Follow the instructions located at http://people.freebsd.org/~mlaier/ALTQ_driver/ to test the NIC with and without ALTQ enabled. 3. Report success or failure. The patch converts a piece of code to the ALTQ world order. Apart from that, the driver is already ALTQ-safe. Thanks. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Lb0e7rgc7IsuDeGj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0yKkbHYXjKDtmC0RAt2fAKDs6BJdi0VfzQYNENeWcXyL9fV/KACgvM5h fNlb4KctqWIqKEHzGfWQnFo= =h2Qp -----END PGP SIGNATURE----- --Lb0e7rgc7IsuDeGj-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:39:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A46216A4CF; Wed, 29 Dec 2004 21:39:25 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED53443D55; Wed, 29 Dec 2004 21:39:24 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([193.28.87.111]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBTLGx7K007416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 22:17:00 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D31EC9.5050909@portaone.com> Date: Wed, 29 Dec 2004 23:16:57 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> In-Reply-To: <41D31CEE.5040803@wadham.ox.ac.uk> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: re@freebsd.org cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:39:25 -0000 Colin Percival wrote: > Maxim Sobolev wrote: > >> Does anybody knows if subject is possible? I guess that it is not due >> to usage of vn(4) in the release building process, has anybody any >> insights about actual state of things and/or another potential >> problems in mind. If the only problem is vn(4) vs. md(4), I think it >> can be solved quite easily, while providing a good way to avoid having >> separate test machines for oldest branches. > > > I'm fairly certain that this is possible; certainly what I do on my FreeBSD > Update buildbox (building 4.x worlds and kernels inside jails while running > a 5.x kernel) is pretty much equivalent. Making buildworld & buildkernel is not the same as building release, since make release involves creating floppies, even for the CD-based install, which in turn requires vn(4) or md(4). > One problem you may encounter involves /dev -- you'll need to mount a devfs > inside the 4.x chroot rather than trying to MAKEDEV everything. I'm not > sure if the `make release` code handles this. Checked release building scripts and found that there is some conditional code already which uses vn(4) on older system and md(4) on newer ones. Will try now to see if I can get it working. Thanks for turning me in the right direction. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:43:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2304D16A4CE; Wed, 29 Dec 2004 21:43:11 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07D0C43D49; Wed, 29 Dec 2004 21:43:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id DC9087A425; Wed, 29 Dec 2004 13:43:10 -0800 (PST) Message-ID: <41D324EE.6070409@elischer.org> Date: Wed, 29 Dec 2004 13:43:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maxim Sobolev References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> In-Reply-To: <41D31EC9.5050909@portaone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: re@freebsd.org cc: "current@freebsd.org" cc: Colin Percival Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:43:11 -0000 Maxim Sobolev wrote: > > Checked release building scripts and found that there is some > conditional code already which uses vn(4) on older system and md(4) on > newer ones. Will try now to see if I can get it working. > > Thanks for turning me in the right direction. Didn't jkh point us at a utility that allows the generation of an image without requiring any media? Or was it someone else? From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 21:50:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AF0D16A4CE; Wed, 29 Dec 2004 21:50:38 +0000 (GMT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C5543D1D; Wed, 29 Dec 2004 21:50:38 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr2so.prod.shaw.ca (pd4mr2so-qfe3.prod.shaw.ca [10.0.141.213]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9I0032A7C0MB80@l-daemon>; Wed, 29 Dec 2004 14:50:24 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd4mr2so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9I00EHD7C0BSX2@pd4mr2so.prod.shaw.ca>; Wed, 29 Dec 2004 14:50:24 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I9I0071R7BYBD@l-daemon>; Wed, 29 Dec 2004 14:50:24 -0700 (MST) Date: Wed, 29 Dec 2004 13:50:21 -0800 From: Colin Percival In-reply-to: <41D324EE.6070409@elischer.org> To: Julian Elischer Message-id: <41D3269D.6020406@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <41D324EE.6070409@elischer.org> User-Agent: Mozilla Thunderbird 0.9 (X11/20041107) cc: Maxim Sobolev cc: re@freebsd.org cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 21:50:38 -0000 Julian Elischer wrote: > Maxim Sobolev wrote: >> Checked release building scripts and found that there is some >> conditional code already which uses vn(4) on older system and md(4) on >> newer ones. Will try now to see if I can get it working. > > Didn't jkh point us at a utility that allows the generation of an image > without requiring any media? > > Or was it someone else? You're probably thinking of my ports/sysutils/makefs (borrowed shamelessly from NetBSD). Given a directory tree and some options (size of disk image, number of inodes, UFS1 vs. UFS2, etc.) it will create a UFS image. I use it in my depenguinator to install FreeBSD onto remote linux systems. (Extract the release tarballs into a staging directory, add some magic, build a UFS2 image, dd the image to the hard drive, and reboot.) Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:05:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95F6F16A4CE; Wed, 29 Dec 2004 22:05:23 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 441C943D4C; Wed, 29 Dec 2004 22:05:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 23C617A425; Wed, 29 Dec 2004 14:05:23 -0800 (PST) Message-ID: <41D32A23.1000304@elischer.org> Date: Wed, 29 Dec 2004 14:05:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Colin Percival References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <41D324EE.6070409@elischer.org> <41D3269D.6020406@wadham.ox.ac.uk> In-Reply-To: <41D3269D.6020406@wadham.ox.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Maxim Sobolev cc: re@freebsd.org cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:05:23 -0000 Colin Percival wrote: > Julian Elischer wrote: > >> Maxim Sobolev wrote: >> >>> Checked release building scripts and found that there is some >>> conditional code already which uses vn(4) on older system and md(4) >>> on newer ones. Will try now to see if I can get it working. >> >> >> Didn't jkh point us at a utility that allows the generation of an image >> without requiring any media? >> >> Or was it someone else? > > > You're probably thinking of my ports/sysutils/makefs (borrowed > shamelessly > from NetBSD). Given a directory tree and some options (size of disk > image, > number of inodes, UFS1 vs. UFS2, etc.) it will create a UFS image. > > I use it in my depenguinator to install FreeBSD onto remote linux > systems. > (Extract the release tarballs into a staging directory, add some magic, > build a UFS2 image, dd the image to the hard drive, and reboot.) yep that's it.. we REALLY should use this in the release. I though t I saw jhb using it in a p4 tree at one time (but I may have been dreaming). does it work for machines other than i386 (e.g. machines with big-endian UFS)? > > > Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:10:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B1A216A4CE; Wed, 29 Dec 2004 22:10:35 +0000 (GMT) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF04943D45; Wed, 29 Dec 2004 22:10:34 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr8so.prod.shaw.ca (pd4mr8so-qfe3.prod.shaw.ca [10.0.141.101]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9I00ASR89M6170@l-daemon>; Wed, 29 Dec 2004 15:10:34 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd4mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9I00A2E89MJBB0@pd4mr8so.prod.shaw.ca>; Wed, 29 Dec 2004 15:10:34 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I9I0097189LM4@l-daemon>; Wed, 29 Dec 2004 15:10:34 -0700 (MST) Date: Wed, 29 Dec 2004 14:10:33 -0800 From: Colin Percival In-reply-to: <41D32A23.1000304@elischer.org> To: Julian Elischer Message-id: <41D32B59.3020108@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <41D324EE.6070409@elischer.org> <41D3269D.6020406@wadham.ox.ac.uk> <41D32A23.1000304@elischer.org> User-Agent: Mozilla Thunderbird 0.9 (X11/20041107) cc: Maxim Sobolev cc: re@freebsd.org cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:10:35 -0000 Julian Elischer wrote: > Colin Percival wrote: >> ports/sysutils/makefs (borrowed >> shamelessly >> from NetBSD). > > yep that's it.. we REALLY should use this in the release. Last time this discussion arose, the conclusion was that we didn't want to use ports in the release-building process if it could be avoided; and I didn't (and still don't) have time to clean it up appropriately for inclusion in the base system. (My "port" includes NetBSD's make and a number of libraries because I figured it was easier to include those than it would be to rewrite the Makefiles.) > does it work for machines other than i386 (e.g. machines with big-endian > UFS)? I don't have any personal experience here... but since this code came from NetBSD, I certainly hope so! Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:12:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F62D16A4CE for ; Wed, 29 Dec 2004 22:12:37 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF06643D86 for ; Wed, 29 Dec 2004 22:12:36 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id iBTMCXKs074172; Wed, 29 Dec 2004 17:12:36 -0500 (EST) (envelope-from mdodd@FreeBSD.ORG) Date: Wed, 29 Dec 2004 17:12:33 -0500 (EST) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Don Bowman In-Reply-To: <2BCEB9A37A4D354AA276774EE13FB8C219AE75@mailserver.sandvine.com> Message-ID: <20041229171055.D22202@sasami.jurai.net> References: <2BCEB9A37A4D354AA276774EE13FB8C219AE75@mailserver.sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Wed, 29 Dec 2004 17:12:36 -0500 (EST) cc: current@FreeBSD.ORG Subject: Re: machine hangs with ida(4), can't panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:12:37 -0000 On Wed, 29 Dec 2004, Don Bowman wrote: > I have a machine running 5.3. It is a compaq dl380. It has > ida0: as the controller > for the disk. > > It has hung a couple of times in the last week in 'getblk'. > When I try to panic it, I get 'ida_command: out of QCBs' (as below). Make sure you're running up to date firmware; I've seen older firmware hang. I've got some command timeout code that might provide positive verification that this is the condition you're encountering. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:15:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB9516A4CE for ; Wed, 29 Dec 2004 22:15:38 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5B3C43D67 for ; Wed, 29 Dec 2004 22:15:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2448 invoked from network); 29 Dec 2004 22:15:37 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 29 Dec 2004 22:15:37 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBTMFN34005110; Wed, 29 Dec 2004 17:15:24 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pawel Worach Date: Wed, 29 Dec 2004 17:15:51 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> <41D1ED23.6060207@telia.com> In-Reply-To: <41D1ED23.6060207@telia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412291715.51125.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: njl@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:15:38 -0000 On Tuesday 28 December 2004 06:32 pm, Pawel Worach wrote: > John Baldwin wrote: > > Are you still seeing this? > > Yes I am, updated boot -v with debug.rman_debug=1 below. > Sources are from 16:00 UTC today. Last working kernel I > have is from November 20, I can start a binary search if > you want. No, I'm fairly sure I know what the search would find. :) Nate, I think the problem here is that his link device doesn't have an associated device_t yet when he gets to this point. Can we force ACPI to enumerate all its devices and assign the associated device_t's via the GetData/SetData stuff before we actually probe any of the children, or do we do that already? > found-> vendor=0x1166, dev=0x0212, revid=0x93 > bus=0, slot=15, func=1 > class=01-01-82, hdrtype=0x00, mfdev=1 > cmdreg=0x0155, statreg=0x0200, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base febfe000, size 12, enabled > rman_reserve_resource: request: [0xfebfe000, > 0xfebfefff], length 0x1000, flags 0, device (null) > considering [0xfe000000, 0xfebfefff] > truncated region: [0xfebfe000, 0xfebfefff]; size 0x1000 (requested 0x1000) > candidate region: [0xfebfefff, 0xfebfe000], size 0x1000 > allocating at the end > pcib0: matched entry for 0.15.INTA (src \LPUS:0) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc051edc7 > stack pointer = 0x10:0xc082095c > frame pointer = 0x10:0xc0820970 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_get_softc+0x7: movl 0x48(%eax),%eax > db> trace > Tracing pid 0 tid 0 td 0xc06ef1e0 > device_get_softc(c07dd4a0,c07d894d,355,c1e841c0,c1e841c0) at > device_get_softc+0x7 acpi_pci_link_route_interrupt(0,0,c0820a28,f,41) at > acpi_pci_link_route_interrupt+0x3a > acpi_pcib_route_interrupt(c1f16d00,c1f8b780,1,c1f7e214,1) at > acpi_pcib_route_interrupt+0x33c > acpi_pcib_acpi_route_interrupt(c1f16d00,c1f8b780,1,c06c7850,c1f8b808) at > acpi_pcib_acpi_route_interrupt+0x2f > pci_assign_interrupt_method(c1f16a00,c1f8b780,f,2,24) at > pci_assign_interrupt_method+0x71 > pci_add_child(c1f16a00,c1f8b800,f,2,80) at pci_add_child+0x207 > pci_add_children(c1f16a00,0,80,c0820b54,c05211cf) at pci_add_children+0x123 > acpi_pci_attach(c1f16a00,c1f4484c,c06c0e3c,c06aa034,0) at > acpi_pci_attach+0x86 > device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c435c,c1f16d00) at > device_attach+0x2c9 bus_generic_attach(c1f16d00,c07d8227,0,c0820bcc,0) at > bus_generic_attach+0x18 > acpi_pcib_attach(c1f16d00,c1f7e214,0,c0820c04,c07bef67) at > acpi_pcib_attach+0xec > acpi_pcib_acpi_attach(c1f16d00,c1f4384c,c06c0e3c,c06aa034,0) at > acpi_pcib_acpi_attach+0xf9 > device_attach(c1f16d00,2f,c0820cbc,c07c1794,c1ed5d80) at > device_attach+0x2c9 bus_generic_attach(c1ed5d80,2e,2f,c1f7dc48,2e) at > bus_generic_attach+0x18 acpi_attach(c1ed5d80,c1f4604c,c06c0e3c,c06aa034,0) > at acpi_attach+0x7b4 > device_attach(c1ed5d80,c1f15000,c0820d18,c06799ca,c1f15000) at > device_attach+0x2c9 > bus_generic_attach(c1f15000,c1f1504c,c0820d54,c0520179,c1f15000) at > bus_generic_attach+0x18 > nexus_attach(c1f15000,c1f3c04c,c06c0e3c,c06aa034,0) at nexus_attach+0x1a > device_attach(c1f15000,c06dd2b0,c0820d78,c0666aa8,c1f15680) at > device_attach+0x2c9 > root_bus_configure(c1f15680,c06bacbe,0,c0820d98,c04d09c6) at > root_bus_configure+0x19 configure(0,0,c1e6f774,81ec00,81e000) at > configure+0x28 > mi_startup() at mi_startup+0xd6 > begin() at begin+0x2c -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:25:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F15616A4CE for ; Wed, 29 Dec 2004 22:25:30 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66BA543D1D for ; Wed, 29 Dec 2004 22:25:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTMPR2D055891; Thu, 30 Dec 2004 00:25:27 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 84602-10; Thu, 30 Dec 2004 00:25:26 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTMPQGi055888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 00:25:26 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBTMPaX1074580; Thu, 30 Dec 2004 00:25:37 +0200 (EET) (envelope-from ru) Date: Thu, 30 Dec 2004 00:25:36 +0200 From: Ruslan Ermilov To: Maxim Sobolev Message-ID: <20041229222536.GD36053@ip.net.ua> References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YToU2i3Vx8H2dn7O" Content-Disposition: inline In-Reply-To: <41D31EC9.5050909@portaone.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:25:30 -0000 --YToU2i3Vx8H2dn7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Maxim, On Wed, Dec 29, 2004 at 11:16:57PM +0200, Maxim Sobolev wrote: > Colin Percival wrote: > >Maxim Sobolev wrote: > > > >>Does anybody knows if subject is possible? I guess that it is not due= =20 > >>to usage of vn(4) in the release building process, has anybody any=20 > >>insights about actual state of things and/or another potential=20 > >>problems in mind. If the only problem is vn(4) vs. md(4), I think it=20 > >>can be solved quite easily, while providing a good way to avoid having= =20 > >>separate test machines for oldest branches. > > > > > >I'm fairly certain that this is possible; certainly what I do on my Free= BSD > >Update buildbox (building 4.x worlds and kernels inside jails while runn= ing > >a 5.x kernel) is pretty much equivalent. >=20 > Making buildworld & buildkernel is not the same as building release,=20 > since make release involves creating floppies, even for the CD-based=20 > install, which in turn requires vn(4) or md(4). >=20 The doFS.sh script (even in 4.x) supports both vn(4) and md(4). > >One problem you may encounter involves /dev -- you'll need to mount a de= vfs > >inside the 4.x chroot rather than trying to MAKEDEV everything. I'm not > >sure if the `make release` code handles this. >=20 > Checked release building scripts and found that there is some=20 > conditional code already which uses vn(4) on older system and md(4) on=20 > newer ones. Will try now to see if I can get it working. >=20 > Thanks for turning me in the right direction. >=20 One thing you'll definitely need is to install the Perl port in LOCAL_SCRIPT. Mounting /dev (much like the RELENG_5 and HEAD versions of release/Makefile do) will also be needed. Note that you should be using the 4.x version of release/Makefile* to start "make release", and use WORLDDIR to point to your /usr/src, something like this: cd /tmp cvs co -rRELENG_4 -l release cd /usr/src/release make -f /tmp/Makefile release ... P.S. Last time I tried it (more than a year ago), it worked. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YToU2i3Vx8H2dn7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0y7gqRfpzJluFF4RAir4AJ9Tf7WhVDHKak4LvLyKCdjmlAbkmwCeMuma dERI2Kt54b7xgOhSebS6yA0= =teW5 -----END PGP SIGNATURE----- --YToU2i3Vx8H2dn7O-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:34:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A47E816A4CE; Wed, 29 Dec 2004 22:34:20 +0000 (GMT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B7443D31; Wed, 29 Dec 2004 22:34:19 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id iBTMYAN5002404; Wed, 29 Dec 2004 23:34:10 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.1/8.12.9) with ESMTP id iBTMYAIS002858; Wed, 29 Dec 2004 23:34:10 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.1/8.13.1/Submit) id iBTMYAsH002857; Wed, 29 Dec 2004 23:34:10 +0100 (CET) (envelope-from wb) Date: Wed, 29 Dec 2004 23:34:10 +0100 From: Wilko Bulte To: Colin Percival Message-ID: <20041229223410.GB2628@freebie.xs4all.nl> References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <41D324EE.6070409@elischer.org> <41D3269D.6020406@wadham.ox.ac.uk> <41D32A23.1000304@elischer.org> <41D32B59.3020108@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D32B59.3020108@wadham.ox.ac.uk> X-OS: FreeBSD 4.11-PRERELEASE X-PGP: finger wilko@freebsd.org User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Maxim Sobolev cc: re@freebsd.org cc: Julian Elischer cc: "current@freebsd.org" Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:34:20 -0000 On Wed, Dec 29, 2004 at 02:10:33PM -0800, Colin Percival wrote.. > Julian Elischer wrote: > >Colin Percival wrote: > >>ports/sysutils/makefs (borrowed > >>shamelessly > >>from NetBSD). > > > >yep that's it.. we REALLY should use this in the release. > > Last time this discussion arose, the conclusion was that we didn't want > to use ports in the release-building process if it could be avoided; and Hear hear... just things like the docproj port already give rise to premature baldness in re@ .... W/ (Alpha re builder at large) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:45:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC1BE16A4CE; Wed, 29 Dec 2004 22:45:23 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07D9443D1D; Wed, 29 Dec 2004 22:45:23 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([193.28.87.111]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBTMjGUI018481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 23:45:19 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D33379.10203@portaone.com> Date: Thu, 30 Dec 2004 00:45:13 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <20041229222536.GD36053@ip.net.ua> In-Reply-To: <20041229222536.GD36053@ip.net.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: current@FreeBSD.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:45:24 -0000 Ruslan Ermilov wrote: > Hi Maxim, > > One thing you'll definitely need is to install the Perl port in > LOCAL_SCRIPT. Mounting /dev (much like the RELENG_5 and HEAD > versions of release/Makefile do) will also be needed. Note that > you should be using the 4.x version of release/Makefile* to > start "make release", and use WORLDDIR to point to your > /usr/src, something like this: > > cd /tmp > cvs co -rRELENG_4 -l release > cd /usr/src/release > make -f /tmp/Makefile release ... Do you mean that I need to have 5.x/6.x in /usr/src pointed to by WORLDDIR, while 4.x in /tmp/src and start making release in /tmp/src/release? I am not sure about perl, why do I need it? Isn't initial make buildworld expected to build it and install into pristive chroot'ed tree? -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:04:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F201216A4CF for ; Wed, 29 Dec 2004 23:04:34 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302DF43D45 for ; Wed, 29 Dec 2004 23:04:34 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTN4X5l059240; Thu, 30 Dec 2004 01:04:33 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 88310-08; Thu, 30 Dec 2004 01:04:32 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTN4WhB059237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 01:04:32 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBTN4gWL030360; Thu, 30 Dec 2004 01:04:42 +0200 (EET) (envelope-from ru) Date: Thu, 30 Dec 2004 01:04:42 +0200 From: Ruslan Ermilov To: Maxim Sobolev Message-ID: <20041229230442.GA3389@ip.net.ua> References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <20041229222536.GD36053@ip.net.ua> <41D33379.10203@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <41D33379.10203@portaone.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:04:35 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 12:45:13AM +0200, Maxim Sobolev wrote: > Ruslan Ermilov wrote: > >Hi Maxim, > > > >One thing you'll definitely need is to install the Perl port in > >LOCAL_SCRIPT. Mounting /dev (much like the RELENG_5 and HEAD > >versions of release/Makefile do) will also be needed. Note that > >you should be using the 4.x version of release/Makefile* to > >start "make release", and use WORLDDIR to point to your > >/usr/src, something like this: > > > > cd /tmp > > cvs co -rRELENG_4 -l release > > cd /usr/src/release > > make -f /tmp/Makefile release ... >=20 > Do you mean that I need to have 5.x/6.x in /usr/src pointed to by=20 > WORLDDIR, while 4.x in /tmp/src and start making release in=20 > /tmp/src/release? >=20 I eman what I said: you need to use the target (4.x) version of release/Makefile*, and /usr/src matching your running world and kernel (5.x). WORLDDIR is not supported by 4.x release/Makefile, hence the sequence above. > I am not sure about perl, why do I need it? Isn't initial make=20 > buildworld expected to build it and install into pristive chroot'ed tree? >=20 You need Perl because 5.x doesn't have Perl in the base system, hence initial "make installworld" (which will install 5.x world into ${CHROOTDIR}) will not install Perl needed to build a 4.x kernel. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0zgKqRfpzJluFF4RAkmcAJ4ioQx+keYP+IO2QowaaIFxrWZ6oQCdHw4x 0yG6ViozJ6TWjBOLMzUCu50= =gICH -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:19:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7E6A16A4CE; Wed, 29 Dec 2004 23:19:37 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67FE843D5E; Wed, 29 Dec 2004 23:19:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBTNJZGV002630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Dec 2004 15:19:36 -0800 Message-ID: <41D33B86.3060109@root.org> Date: Wed, 29 Dec 2004 15:19:34 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> <41D1ED23.6060207@telia.com> <200412291715.51125.jhb@FreeBSD.org> In-Reply-To: <200412291715.51125.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:19:37 -0000 John Baldwin wrote: > On Tuesday 28 December 2004 06:32 pm, Pawel Worach wrote: > >>John Baldwin wrote: >> >>>Are you still seeing this? >> >>Yes I am, updated boot -v with debug.rman_debug=1 below. >>Sources are from 16:00 UTC today. Last working kernel I >>have is from November 20, I can start a binary search if >>you want. > > > No, I'm fairly sure I know what the search would find. :) Nate, I think the > problem here is that his link device doesn't have an associated device_t yet > when he gets to this point. Can we force ACPI to enumerate all its devices > and assign the associated device_t's via the GetData/SetData stuff before we > actually probe any of the children, or do we do that already? What you want, my friend, is multi-pass newbus. Oh wait, you were one of the proponents of that. :) You can overload the hack I have in acpi_probe_order() for sysresource objects. Just do a manual check for the PNPID for PCI links and have them probe first. -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:26:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2711A16A4CF; Wed, 29 Dec 2004 23:26:48 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4D543D55; Wed, 29 Dec 2004 23:26:47 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([193.28.87.111]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBTNQfrN022924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 00:26:44 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D33D2A.9080308@portaone.com> Date: Thu, 30 Dec 2004 01:26:34 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <20041229222536.GD36053@ip.net.ua> <41D33379.10203@portaone.com> <20041229230442.GA3389@ip.net.ua> <41D33B15.8050401@portaone.com> In-Reply-To: <41D33B15.8050401@portaone.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: current@FreeBSD.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:26:48 -0000 Maxim Sobolev wrote: > Ruslan Ermilov wrote: > >> On Thu, Dec 30, 2004 at 12:45:13AM +0200, Maxim Sobolev wrote: >> >>> Ruslan Ermilov wrote: >>> >>>> Hi Maxim, >>>> >>>> One thing you'll definitely need is to install the Perl port in >>>> LOCAL_SCRIPT. Mounting /dev (much like the RELENG_5 and HEAD >>>> versions of release/Makefile do) will also be needed. Note that >>>> you should be using the 4.x version of release/Makefile* to >>>> start "make release", and use WORLDDIR to point to your >>>> /usr/src, something like this: >>>> >>>> cd /tmp >>>> cvs co -rRELENG_4 -l release >>>> cd /usr/src/release >>>> make -f /tmp/Makefile release ... >>> >>> >>> Do you mean that I need to have 5.x/6.x in /usr/src pointed to by >>> WORLDDIR, while 4.x in /tmp/src and start making release in >>> /tmp/src/release? >>> >> >> I eman what I said: you need to use the target (4.x) version of >> release/Makefile*, and /usr/src matching your running world and >> kernel (5.x). WORLDDIR is not supported by 4.x release/Makefile, >> hence the sequence above. >> >> >>> I am not sure about perl, why do I need it? Isn't initial make >>> buildworld expected to build it and install into pristive chroot'ed >>> tree? >>> >> >> You need Perl because 5.x doesn't have Perl in the base system, >> hence initial "make installworld" (which will install 5.x world >> into ${CHROOTDIR}) will not install Perl needed to build a 4.x >> kernel. > > > Maybe I am missing something obvious, but what if I'll build 4.x chroot > on 5.x/6.x system, put 4.x sources into /usr/src and will try to build > 5.x release from within that chroot. As far as I can see, only > operations that use some devices (e.g. md(4) vs vn(4)) can lead to a > problem, but this . Anyway, pretty soon we will know for sure - it is > now rolling distribution tarballs here. OK, I see what you mean now. doFS supports usage of mdconfig instead of vnconfig, but since world built from 4.x used to create pristine environment from make release doesn't have one it doesn't work. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:39:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9093F16A4CE; Wed, 29 Dec 2004 23:39:25 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id E063B43D1D; Wed, 29 Dec 2004 23:39:24 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([193.28.87.111]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBTNHi8C021943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 00:17:48 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D33B15.8050401@portaone.com> Date: Thu, 30 Dec 2004 01:17:41 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <20041229222536.GD36053@ip.net.ua> <41D33379.10203@portaone.com> <20041229230442.GA3389@ip.net.ua> In-Reply-To: <20041229230442.GA3389@ip.net.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: current@FreeBSD.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:39:25 -0000 Ruslan Ermilov wrote: > On Thu, Dec 30, 2004 at 12:45:13AM +0200, Maxim Sobolev wrote: > >>Ruslan Ermilov wrote: >> >>>Hi Maxim, >>> >>>One thing you'll definitely need is to install the Perl port in >>>LOCAL_SCRIPT. Mounting /dev (much like the RELENG_5 and HEAD >>>versions of release/Makefile do) will also be needed. Note that >>>you should be using the 4.x version of release/Makefile* to >>>start "make release", and use WORLDDIR to point to your >>>/usr/src, something like this: >>> >>> cd /tmp >>> cvs co -rRELENG_4 -l release >>> cd /usr/src/release >>> make -f /tmp/Makefile release ... >> >>Do you mean that I need to have 5.x/6.x in /usr/src pointed to by >>WORLDDIR, while 4.x in /tmp/src and start making release in >>/tmp/src/release? >> > > I eman what I said: you need to use the target (4.x) version of > release/Makefile*, and /usr/src matching your running world and > kernel (5.x). WORLDDIR is not supported by 4.x release/Makefile, > hence the sequence above. > > >>I am not sure about perl, why do I need it? Isn't initial make >>buildworld expected to build it and install into pristive chroot'ed tree? >> > > You need Perl because 5.x doesn't have Perl in the base system, > hence initial "make installworld" (which will install 5.x world > into ${CHROOTDIR}) will not install Perl needed to build a 4.x > kernel. Maybe I am missing something obvious, but what if I'll build 4.x chroot on 5.x/6.x system, put 4.x sources into /usr/src and will try to build 5.x release from within that chroot. As far as I can see, only operations that use some devices (e.g. md(4) vs vn(4)) can lead to a problem, but this . Anyway, pretty soon we will know for sure - it is now rolling distribution tarballs here. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:40:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3233316A4CF for ; Wed, 29 Dec 2004 23:40:51 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681D043D46 for ; Wed, 29 Dec 2004 23:40:50 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTNenLs063412; Thu, 30 Dec 2004 01:40:49 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 92789-18; Thu, 30 Dec 2004 01:40:48 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBTNemE5063409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 01:40:48 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBTNewY5060471; Thu, 30 Dec 2004 01:40:58 +0200 (EET) (envelope-from ru) Date: Thu, 30 Dec 2004 01:40:58 +0200 From: Ruslan Ermilov To: Maxim Sobolev Message-ID: <20041229234058.GB40328@ip.net.ua> References: <41D31B8E.7030305@portaone.com> <41D31CEE.5040803@wadham.ox.ac.uk> <41D31EC9.5050909@portaone.com> <20041229222536.GD36053@ip.net.ua> <41D33379.10203@portaone.com> <20041229230442.GA3389@ip.net.ua> <41D33B15.8050401@portaone.com> <41D33D2A.9080308@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <41D33D2A.9080308@portaone.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@freebsd.org Subject: Re: Building 4.x releases on 5.x and 6.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:40:51 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 01:26:34AM +0200, Maxim Sobolev wrote: [...] > >Maybe I am missing something obvious, but what if I'll build 4.x chroot= =20 > >on 5.x/6.x system, put 4.x sources into /usr/src and will try to build= =20 > >5.x release from within that chroot. As far as I can see, only=20 > >operations that use some devices (e.g. md(4) vs vn(4)) can lead to a=20 > >problem, but this . Anyway, pretty soon we will know for sure - it is=20 > >now rolling distribution tarballs here. >=20 > OK, I see what you mean now. doFS supports usage of mdconfig instead of= =20 > vnconfig, but since world built from 4.x used to create pristine=20 > environment from make release doesn't have one it doesn't work. >=20 The way you cross-build 4.x release on 5.x/6.x is by installing the 5.x/6.x world into ${CHROOTDIR}, and using that to cross- build the 4.x world and kernel, and other bits specific to "make release". And yes, on a 5.x system, you want to use the 5.x tools to build file system images, including using the md(4) and mdconfig(8) (5.x kernel doesn't have vn(4)). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB00CKqRfpzJluFF4RApHiAJ9TAitLobroC5FH96VSKudfcr61UgCfcbK7 lAHzNwYu9My6jI4KYDJRJjE= =ofjV -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 02:29:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C701316A4CE for ; Thu, 30 Dec 2004 02:29:08 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7783B43D48 for ; Thu, 30 Dec 2004 02:29:08 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I9I00CI0K8JQQ@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Thu, 30 Dec 2004 03:29:07 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 30 Dec 2004 03:29:06 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149])iBU2T6kZ011953 for ; Thu, 30 Dec 2004 03:29:06 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id 63C1F2842E for ; Thu, 30 Dec 2004 03:29:01 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 3A65622859; Thu, 30 Dec 2004 03:29:01 +0100 (CET) Date: Thu, 30 Dec 2004 03:29:01 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20041230022900.GF759@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary="Q6STzHxy03qt/hK9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Subject: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 02:29:09 -0000 --Q6STzHxy03qt/hK9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, with a kernel build from sources from Dec 30, approximately 00:30:00 UTC, I'm getting the following reproducible trap during startup: Memory modified after free 0xc1c06600(508) val=3D1ff01ff @ 0xc1c06600 Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x1ff021f fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc0706823 stack pointer =3D 0x10:0xe53cf730 frame pointer =3D 0x10:0xe53cf750 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupts enabled, resume, IOPL =3D 0 current process =3D 61 (rcorder) [thread pid 61 tid 100051 ] Stopped at mtrash_ctor+0x63: movl 0x20(%eax),%edx db> tr Tracing pid 61 tid 100051 td 0xc1ab4170 mtrash_ctor(c1c06600,200,0,101,c07dbf04) at mtrash_ctor+0x63 uma_zalloc_arg(c10456c0,0,101,c1046be0,c07b77c6) at uma_zalloc_arg+0x484 malloc(168,c07ee200,101,b2,0) at malloc+0x84 ufsdirhash_build(c1c4b7a8,c0818348,c08386e0,0,0) at ufsdirhash_build+0x376 ufs_lookup(e53cf944,e53cfbec,e53cfc00,c057aa65,c1ab4170) at ufs_lookup+0x129 vfs_cache_lookup(e53cf9c0,20002,c1ab4170,c07aaca7,e53cfbec) at vfs_cache_lo= okup+0x278 lookup(e53cfbd8,0,c07aa52c,a7,c0838700) at lookup+0x274 namei(a53cfbd8,1,c07ab4bd,78,c079f15a) at namei+0x27d vn_open_cred(e53cfbd8,e53cfcd8,1a4,c1978d80,3) at vn_open_cred+0x192 vn_open(e53cfbd8,e53cfcd8,1a4,3,0) at vn_open+0x33 kern_open(c1ab4170,bfbfe6d3,0,1,1b6) at kern_open+0xf9 open(c1ab4170,e53cfd14,c,c1ab4170,3) at open+0x2e syscall(2f,2f,2f,bfbfe63c,4) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip =3D 0x80573a7, esp =3D 0xbfbfe2cc= m, ebp =3D 0xbfbfe2f8 --- db> This doesn't happen with a kernel from Dec 23. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Q6STzHxy03qt/hK9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB02fsbHYXjKDtmC0RAkHsAKD+f2KBnHuXW6Zb+PwaMZ1iTKaPTQCbBt10 H4hhpRR9K86c9Eu899vvnKI= =A7t/ -----END PGP SIGNATURE----- --Q6STzHxy03qt/hK9-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 05:18:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4482B16A4CE for ; Thu, 30 Dec 2004 05:18:52 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05F5343D46 for ; Thu, 30 Dec 2004 05:18:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iBU5IoWi045018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 21:18:51 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41D38FBF.5070701@errno.com> Date: Wed, 29 Dec 2004 21:18:55 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rong-En Fan References: <6eb82e04122905361ccd6af0@mail.gmail.com> In-Reply-To: <6eb82e04122905361ccd6af0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 05:18:52 -0000 Rong-En Fan wrote: > Hello, > > I'm playing with WPA-PSK (AES and TKIP) with my Linksys > WRT54G on recently current, but no luck :( > > Basically I use [http://people.zoy.org/~hpreg/wifi/] to set > up my ap and wpa_supplicant. Somehow, I can associate > to the ap and ifconfig ath0 does show the key. but i can't > send any packet or receive any packet. I found that the > transmission key is changing every 1 second?? I don't > think this is right. > > My notebook is IBM X31 with built-in Atheros a/b/g. > And wrt54g's wpa-psk works fine under windows. > So, is there any information that i can provide to work > this out? wpa_supplicant has a -d option to enable debugging; use it and if you can't find your problem provide the wpa_supplicant config file and log output. Sam From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 05:40:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E71616A4D0 for ; Thu, 30 Dec 2004 05:40:23 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [64.42.246.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id B456A43D53 for ; Thu, 30 Dec 2004 05:40:09 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id 5C31561E49; Wed, 29 Dec 2004 23:40:10 -0600 (CST) From: Mark Johnston To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Date: Wed, 29 Dec 2004 23:40:09 -0600 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200412292340.09775.mjohnston@skyweb.ca> Subject: cvs-src summary news and improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 05:40:23 -0000 Hi folks, Those of you who watch out for the cvs-src summaries would have noticed there wasn't one last week - sorry about that. I'll be posting last week's and this week's, bundled together, right after this post. The main news about the summaries is that I no longer write them in reStructuredText, in favor of a small XML dialect. This gives the following new features: - Text summaries are no longer speckled with funny punctuation. - HTML and text summaries now have links to man pages and files in CVS. - As often requested, the summaries are now available in RSS. - If you want to do anything with the summary data, you can use the XML (but see below.) The "feedback requested" is mostly on the RSS, since I don't use RSS myself and know very little about it. All I've done is validate the feed. If you want to see the data in other RSS flavors, or Atom or whatever, drop me an e-mail with a link to a reasonable spec on the format, and I can likely accomodate you. Also, it currently just serves up the latest summary, with a hard cutover when a new one is posted; I don't know whether this pleases RSS browsers (aggregators?) or not. If you want to deal with the XML directly, please let me know. I'm still getting the XML format itself sorted out, so I'd like to hear interested parties' thoughts on it and know who I have to warn if I play with the format. I can also send you a copy of the Python scripts I process the XML with, although the code is intensely ugly. Also, don't base your concept of the XML version on the text summary, since some of the data is thrown away; you can get the XML source at the Web page (http://excel.xl0.org/FreeBSD). All that said, consider using the RSS if you don't need the XML metadata, since the RSS format is much less likely to fluctuate. If you have any comments or suggestions on the changes, or on changes you'd like to see, now is the perfect time to tell me. Otherwise, thanks for reading the summaries. Mark From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 05:43:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36CF016A4CE for ; Thu, 30 Dec 2004 05:43:51 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [64.42.246.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2EC743D54 for ; Thu, 30 Dec 2004 05:43:50 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id A47B561E49; Wed, 29 Dec 2004 23:43:46 -0600 (CST) From: Mark Johnston To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Date: Wed, 29 Dec 2004 23:43:46 -0600 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200412292343.46524.mjohnston@skyweb.ca> Subject: cvs-src summary double feature for December 14-27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 05:43:51 -0000 [Scroll down for 21-27] [Also, I forgot to mention in my last mail that I haven't yet created a stylesheet for the new HTML summaries, so they look pretty bare. If you have the inclination, by all means please submit one, or I'll make one in the next couple of days.] FreeBSD cvs-src summary for 2004-12-14 to 2004-12-20 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). ============ New Features ============ Improvements to jail startup/shutdown ------------------------------------- Ralf S. Engelschall (rse) updated the jail[1] subsystem to improve the startup and shutdown of jails. He added an rc.conf[2] variable named jail__exec_stop that contains a command to be run when the jail is stopped; this matches jail__exec_start, which is run when the jail starts. [1] http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html [2] http://www.freebsd.org/cgi/man.cgi?query=rc.conf&apropos=0&sektion=5&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412141436.iBEEaZ66050476 Pinnacle PCTV Rave cards supported ---------------------------------- Julian Elischer (julian) committed Branko Lankester's patches to the bktr[1] driver, for TV input cards, to support the Pinnacle PCTV Rave card. [1] http://www.freebsd.org/cgi/man.cgi?query=bktr&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html Submitted by: Branko Lankester PR: 73669 (http://www.freebsd.org/cgi/query-pr.cgi?pr=73669) http://www.freebsd.org/cgi/mid.cgi?200412162337.iBGNbgmQ075418 Initial NFS Direct I/O support ------------------------------ Paul Saab (ps) committed initial support for NFS Network File System Direct I/O. Direct I/O disables all caching in the NFS client, which is useful for programs that do their own caching, like clustered database servers, or applications that have no use for caching, like streaming video. Submitted by: Mohan Srinivasan http://www.freebsd.org/cgi/mid.cgi?200412152220.iBFMKMKa081446 ================= Discussion Topics ================= Sorting of make.conf variables ------------------------------ Tom Rhodes (trhodes) added a couple of options to make.conf[1], also re-sorting the file. Ruslan Ermilov (ru) replied that Tom's change had actually unsorted the list, and that it should be in dictionary order. After some discussion, Tom committed a patch that Ruslan had developed to restore the sorting to its previous state. [1] http://www.freebsd.org/cgi/man.cgi?query=make.conf&apropos=0&sektion=5&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412150210.iBF2AodY094280 Working towards packaging the base system ----------------------------------------- Paul Richards (paul) committed code that lays out a base for packaging the base system. Colin Percival (cperciva) replied, noting that Colin had been working on similar patches as well. They were joined by Ruslan Ermilov (ru) and John Baldwin (jhb), and they briefly discussed the benefits of each method. http://www.freebsd.org/cgi/mid.cgi?200412201546.iBKFkuTK047592 ================= Committer Changes ================= Sam Hopkins (sah) has joined the project as a src committer. He will be working on integrating his ATA-over-Ethernet code, among other things. Scott Long (scottl) will be his mentor. http://www.freebsd.org/cgi/mid.cgi?200412150804.iBF84Fdj021038 Daniel Hartmeier (dhartmei) is no longer under mentorship. http://www.freebsd.org/cgi/mid.cgi?200412160224.iBG2OxP6096193 =================== Important Bug Fixes =================== Potential system lockup in pf fixed ----------------------------------- Daniel Hartmeier (dhartmei) fixed a bug in PF[1], the OpenBSD packet filter, that could result in an infinite loop and system hang when using NAT Network Address Translation with the static-port directive. This may be exploitable by LAN clients in a NAT configuration to lock up the system. [1] http://www.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html Reported by: Hugo Silva, Srebrenco Sehic PR: 74930 (http://www.freebsd.org/cgi/query-pr.cgi?pr=74930) http://www.freebsd.org/cgi/mid.cgi?200412191943.iBJJh4Mr070637 =============== Other Bug Fixes =============== Darren Reed (darrenr) committed a fix to IPFilter[1] to a bug that was causing IPv6 path MTU (Maximum Transmission Unit, The maximum size of a packet that can be sent across a given link or path) discovery to fail, by blocking the outgoing notifications of too-large packets. The bug was also fixed in RELENG_4 and RELENG_5. [1] http://www.freebsd.org/cgi/man.cgi?query=ipf&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html Submitted by: Mark Andrews PR: 70399 (http://www.freebsd.org/cgi/query-pr.cgi?pr=70399) http://www.freebsd.org/cgi/mid.cgi?200412162102.iBGL2GCT069715 Maxim Konovalov (maxim) committed a fix to repquota[1], a disk quota reporting tool, so that its output can properly be sorted with sort[2]. Previously, usernames of the maximum length would run into the quota and break sorting. [1] http://www.freebsd.org/cgi/man.cgi?query=repquota&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html [2] http://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=1&manpath=FreeBSD+6.0-current&format=html Submitted by: Matthew D. Fuller PR: 75259 (http://www.freebsd.org/cgi/query-pr.cgi?pr=75259) http://www.freebsd.org/cgi/mid.cgi?200412191802.iBJI2jUp066876 FreeBSD cvs-src summary for 2004-12-21 to 2004-12-27 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). ============ New Features ============ IPFilter gains fine-grained locking ----------------------------------- Darren Reed (darrenr) added fine-grained locking to IPFilter[1], one of the system firewalls, to enable it to run without the Giant system lock. This should improve firewall performance, especially on multiprocessor machines. [1] http://www.freebsd.org/cgi/man.cgi?query=ipf&apropos=0&sektion=5&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412240914.iBO9EQwi030378 Enhancements to USB audio ------------------------- Julian Elischer (julian) committed several patches from Kazuhito Honda, originally obtained from NetBSD, to drastically improve USB audio support. USB audio should now support multiple volume controls and, on some devices, recording, and should no longer break when audio data is fed in with an incorrect sampling rate. Submitted by: Kazuhito Honda PR: 75274 (http://www.freebsd.org/cgi/query-pr.cgi?pr=75274) http://www.freebsd.org/cgi/mid.cgi?200412250620.iBP6Ko2q007287 New scheduler analysis tool --------------------------- Jeff Roberson (jeff) committed a new tool called schedgraph.py. It takes trace output generated by the system scheduler and displays details on what different threads are doing at different times. Jeff reported shortly afterwards that schedgraph.py had already paid off in the form of a significant process-switching performance improvement. http://www.freebsd.org/cgi/mid.cgi?200412260013.iBQ0D7AF074474 =============== Notable Changes =============== NOxxx variables become NO_xxx ----------------------------- Ruslan Ermilov (ru) made sweeping commits to change all NO variables, usually used when compiling to include or exclude parts of the system, to be named NO_. Previously, many variables used each form, and there was no way to tell which should be used. The variables currently affected are: NOATM NOCLEAN NOCLEANDIR NOCRYPT NODOCCOMPRESS NOEXTRADEPEND NOFORTH NOFSCHG NOGAMES NOHTML NOINET6 NOINFO NOINFOCOMPRESS NOINSTALLLIB NOIPSEC NOLIBC_R NOLIBPTHREAD NOLIBTHR NOLINT NOMAN NOMANCOMPRESS NOMLINKS NOOBJ NOPAM NOPIC NOPROFILE NOSHARE NOSHARED NOTAGS All of these have simply had an underscore added after the initial NO. For an up-to-date list, see /usr/share/mk/bsd.compat.mk[1]. The build options for ppp[2] have also been changed to prepend PPP so they can be used in make.conf.[3] [1] http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/share/mk/bsd.compat.mk [2] http://www.freebsd.org/cgi/man.cgi?query=ppp&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html [3] http://www.freebsd.org/cgi/man.cgi?query=make.conf&apropos=0&sektion=5&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412210847.iBL8lZdJ029897 ================= Discussion Topics ================= Running out of KTRs ------------------- Jeff Roberson (jeff) added a KTR Kernel tracing identifier for his above-mentioned schedule analysis tool. This prompted some discussion about KTR IDs, since there are only two free IDs left. Dag-Erling Smorgrav (des) offered some, but found that his cats had eaten them. Jeff wondered about having reserved IDs for local use, allowing global IDs to be reclaimed. Nate Lawson (njl) suggested using dynamically allocated IDs, but the implementation was a problem. http://www.freebsd.org/cgi/mid.cgi?200412260013.iBQ0DcJ1074546 Spurious lock order reversal reports? ------------------------------------- Darren Reed (darrenr) tweaked the IPFilter[1] firewall, prompting Scott Long (scottl) to ask whether the lock order reversal in IPFilter had been fixed. Lock order reversals result when two locks are released in the opposite order that they were acquired, leading to possible deadlock. Darren wondered whether the problem could be in the reporting code; several people disagreed with this. Alan and John Baldwin (jhb) later explained that the sx[2] locks in FreeBSD are unlike Solaris's rwlocks, which Darren was used to. [1] http://www.freebsd.org/cgi/man.cgi?query=ipf&apropos=0&sektion=5&manpath=FreeBSD+6.0-current&format=html [2] http://www.freebsd.org/cgi/man.cgi?query=sx&apropos=0&sektion=9&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412260909.iBQ99TV1011796 =================== Important Bug Fixes =================== libarchive MFC'ed to 5.x ------------------------ Tim Kientzle (kientzle) has MFC'ed libarchive, a library for dealing with various kinds of archives, to 5-STABLE. This fixes numerous bugs, including improving error handling, correcting possible device number corruption, and improving handling of empty files. http://www.freebsd.org/cgi/mid.cgi?200412220001.iBM01trs089465 =============== Other Bug Fixes =============== Pyun YongHyeon (yongari) fixed a memory leak in the libdisk[1] disk interface library. [1] http://www.freebsd.org/cgi/man.cgi?query=libdisk&apropos=0&sektion=3&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200412220817.iBM8HIVe021963 Ruslan Ermilov (ru) fixed a problem in catman[1], which preformats manual pages for faster access. The bug was preventing it from working on machine-specific pages. [1] http://www.freebsd.org/cgi/man.cgi?query=catman&apropos=0&sektion=1&manpath=FreeBSD+6.0-current&format=html Submitted by: Scot W. Hetzel PR: 72243 (http://www.freebsd.org/cgi/query-pr.cgi?pr=72243) http://www.freebsd.org/cgi/mid.cgi?200412221604.iBMG4wEE052662 Pawel Jakub Dawidek (pjd) patched a memory buffer leak in the bpf[1] packet sniffing/injection device. [1] http://www.freebsd.org/cgi/man.cgi?query=bpf&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html Submitted by: Johnny Eriksson http://www.freebsd.org/cgi/mid.cgi?200412271553.iBRFrj4i035263 From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 08:52:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2989016A4CE for ; Thu, 30 Dec 2004 08:52:51 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 016D543D45 for ; Thu, 30 Dec 2004 08:52:51 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9F7A8512D9; Thu, 30 Dec 2004 00:52:50 -0800 (PST) Date: Thu, 30 Dec 2004 00:52:50 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041230085250.GB59271@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: mdmfs: mdconfig (attach) exited with error code 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 08:52:51 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I get the following error while trying to diskless boot: mdmfs: mdconfig (attach) exited with error code 1 Did someone break mdconfig binary compatibility? Kris --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB08HiWry0BWjoQKURAqJSAKCuWcKJcSjW+IZwY3XBQkHh9Tpi9wCdFdnr yjmazsf/0J3aVjkfyyGiGOQ= =IqjP -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 09:04:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDAF016A4CE for ; Thu, 30 Dec 2004 09:04:57 +0000 (GMT) Received: from pd2mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9A5143D3F for ; Thu, 30 Dec 2004 09:04:57 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd5mr8so.prod.shaw.ca (pd5mr8so-qfe3.prod.shaw.ca [10.0.141.184]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9J006H12JM0D70@l-daemon> for current@freebsd.org; Thu, 30 Dec 2004 02:04:34 -0700 (MST) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd5mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9J00BSY2JML1L0@pd5mr8so.prod.shaw.ca> for current@freebsd.org; Thu, 30 Dec 2004 02:04:34 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0I9J00J4D2JLZJ@l-daemon> for current@freebsd.org; Thu, 30 Dec 2004 02:04:34 -0700 (MST) Date: Thu, 30 Dec 2004 01:04:33 -0800 From: Colin Percival In-reply-to: <20041230085250.GB59271@xor.obsecurity.org> To: Kris Kennaway Message-id: <41D3C4A1.4020808@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <20041230085250.GB59271@xor.obsecurity.org> User-Agent: Mozilla Thunderbird 0.9 (X11/20041107) cc: current@freebsd.org Subject: Re: mdmfs: mdconfig (attach) exited with error code 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 09:04:58 -0000 Kris Kennaway wrote: > I get the following error while trying to diskless boot: > > mdmfs: mdconfig (attach) exited with error code 1 > > Did someone break mdconfig binary compatibility? Yes, pjd changed the ABI to be compatible with RELENG_5 (and thus incompatible with recent -currents): :pjd 2004-12-27 17:20:06 UTC : : FreeBSD src repository : : Modified files: : sys/dev/md md.c : sys/sys mdioctl.h : sbin/mdconfig mdconfig.c : Log: : Rewrite piece of code which I committed some time ago that allows to : show file name for 'mdconfig -l -u ' command. : This allows to preserve API/ABI compatibility with version 0 (that's why : I changed version number back to 0) and will allow to merge this change : to RELENG_5. Colin Percival From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 12:48:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BFBD16A4CF for ; Thu, 30 Dec 2004 12:48:01 +0000 (GMT) Received: from fep1.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35FEF43D4C for ; Thu, 30 Dec 2004 12:48:01 +0000 (GMT) (envelope-from paul.murphy@cogeco.ca) Received: from earth.upton.net (d141-23-108.home.cgocable.net [24.141.23.108]) by fep1.cogeco.net (Postfix) with SMTP id 4483E6377 for ; Thu, 30 Dec 2004 07:48:00 -0500 (EST) Date: Thu, 30 Dec 2004 07:47:52 -0500 From: Paul Murphy To: freebsd-current@freebsd.org Message-ID: <20041230074752.3918d76c@earth.upton.net> In-Reply-To: <200412292340.09775.mjohnston@skyweb.ca> References: <200412292340.09775.mjohnston@skyweb.ca> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd6.0) X-Face: -Q/~XHbe$z/a List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:48:01 -0000 --Signature=_Thu__30_Dec_2004_07_47_52_-0500_o8VwiSs1PfXAv6UU Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wed, 29 Dec 2004 23:40:09 -0600 Mark Johnston wrote: > The "feedback requested" is mostly on the RSS, since I don't use RSS > myself and know very little about it. All I've done is validate the > feed. If you want to see the data in other RSS flavors, or Atom or > whatever, drop me an e-mail with a link to a reasonable spec on the > format, and I can likely accomodate you. Also, it currently just > serves up the latest summary, with a hard cutover when a new one is > posted; I don't know whether this pleases RSS browsers (aggregators?) > or not. > Clicking on a RSS news item (in both Firefox and KNewsTicker) results in a bad URL (eg. /FreeBSD//var/www/excel.xl0.org/FreeBSD/2004-12-27.html) -- Cogeco ergo sum --Signature=_Thu__30_Dec_2004_07_47_52_-0500_o8VwiSs1PfXAv6UU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0/j/tvR7Iq3g7n0RAmtZAJ9ryRDAa19Sgu7urK8qZEn6rzj9MwCfW1vc zage5GygS6AiiriAnYFupL4= =s+p3 -----END PGP SIGNATURE----- --Signature=_Thu__30_Dec_2004_07_47_52_-0500_o8VwiSs1PfXAv6UU-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 13:20:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D472F16A4CE for ; Thu, 30 Dec 2004 13:20:42 +0000 (GMT) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03CE443D49 for ; Thu, 30 Dec 2004 13:20:41 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id iBUDKLLc088135; Thu, 30 Dec 2004 15:20:21 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.185] (ajax.ebs.gr [10.1.1.185]) by ebs.gr (8.12.11/8.12.11) with ESMTP id iBUDKJIX017664; Thu, 30 Dec 2004 15:20:20 +0200 (EET) (envelope-from past@ebs.gr) Received: from 127.0.0.1 (AVG SMTP 7.0.298 [265.6.6]); Thu, 30 Dec 2004 15:20:13 +0200 Message-ID: <41D4008D.2040508@ebs.gr> Date: Thu, 30 Dec 2004 15:20:13 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Murphy References: <200412292340.09775.mjohnston@skyweb.ca> <20041230074752.3918d76c@earth.upton.net> In-Reply-To: <20041230074752.3918d76c@earth.upton.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cvs-src summary news and improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 13:20:42 -0000 Paul Murphy wrote: > On Wed, 29 Dec 2004 23:40:09 -0600 > Mark Johnston wrote: > > >>The "feedback requested" is mostly on the RSS, since I don't use RSS >>myself and know very little about it. All I've done is validate the >>feed. If you want to see the data in other RSS flavors, or Atom or >>whatever, drop me an e-mail with a link to a reasonable spec on the >>format, and I can likely accomodate you. Also, it currently just >>serves up the latest summary, with a hard cutover when a new one is >>posted; I don't know whether this pleases RSS browsers (aggregators?) >>or not. >> > > > Clicking on a RSS news item (in both Firefox and KNewsTicker) results > in a bad URL (eg. > /FreeBSD//var/www/excel.xl0.org/FreeBSD/2004-12-27.html) I noticed it too, on rssowl. Nevertheless, I would like to (once again) express my gratitude to Mark for still doing this (after almost a whole year) and to point out that this RSS feed would be an excellent addition to the right-side pane of www.freebsd.org. It would freshen up the site content-wise. Cheers, Panagiotis From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 18:03:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88B5916A4CE for ; Thu, 30 Dec 2004 18:03:09 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 336A843D45 for ; Thu, 30 Dec 2004 18:03:09 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so267635wri for ; Thu, 30 Dec 2004 10:03:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bp2KowhomsjQlFW6epnIbQENE1+N9ZXvtnk7XK72uu4OycCqsAtRQ+vKlazTF3sa/qAjPSsUtJJyuZSbMT8dD2nsEhAbG4Dxe8RmwNLEaT39N454d21JUl7NHdUBLUBtUEP9rSFsgH2xvL6zvbnjl3HxOsWLevN2l3TE1eb6V0M= Received: by 10.54.51.36 with SMTP id y36mr200725wry; Thu, 30 Dec 2004 10:03:08 -0800 (PST) Received: by 10.54.7.75 with HTTP; Thu, 30 Dec 2004 10:03:08 -0800 (PST) Message-ID: <6eb82e04123010035e379e48@mail.gmail.com> Date: Fri, 31 Dec 2004 02:03:08 +0800 From: Rong-En Fan To: current@freebsd.org In-Reply-To: <41D38FBF.5070701@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6eb82e04122905361ccd6af0@mail.gmail.com> <41D38FBF.5070701@errno.com> cc: Sam Leffler Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rong-En Fan List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 18:03:09 -0000 On Wed, 29 Dec 2004 21:18:55 -0800, Sam Leffler wrote: > wpa_supplicant has a -d option to enable debugging; use it and if you > can't find your problem provide the wpa_supplicant config file and log > output. My current is just built tonight. I took a look at -d output, however, i can't find any notable error messages. I put wpa_supplicant (0.3.2 [1]) -d output and its conf along with dmesg, sysctl that related to ath here: http://rafan.infor.org/tmp/wpa/ Any help are appreciated :-) -rafan [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/75609 From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 18:20:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0249816A4CE for ; Thu, 30 Dec 2004 18:20:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A53243D39 for ; Thu, 30 Dec 2004 18:20:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBUIGOFT010775; Thu, 30 Dec 2004 11:17:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Dec 2004 11:16:31 -0700 (MST) Message-Id: <20041230.111631.13597845.imp@bsdimp.com> To: jb@cimlogic.com.au From: "M. Warner Losh" In-Reply-To: <20041228010938.GA39686@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> 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: current@freebsd.org Subject: Re: USB problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 18:20:21 -0000 In message: <20041228010938.GA39686@freebsd3.cimlogic.com.au> John Birrell writes: : 1. The USB sub-system doesn't handle loading and unloading drivers properly. : If a driver is unloaded when a USB device is still attached, the next : time the driver is loaded, the kernel panics. This might not be such : a problem to normal users because they don't have a need to do that, but : during driver development when you want to load and unload repeatedly, : it's a pain. I don't see this. Can you give a more concrete example? I've done work in this area and I believe that it is almost working correctly. : 3. The usbd_bulk_transfer function calls tsleep() to wait for streaming : data to become available. On current, this bumps into a KASSERT in : msleep because Giant is not locked and no mutex has been supplied. : In my driver, I need to run an 'encoder' thread which calls : usbd_bulk_transfer() to gobble the incoming MPEG data stream. While : this is going on, there is no syscall in progress because the : application is off doing other things. It might be looking at the : mmaped buffer or it may not. : : For FreeBSD, usbd_bulk_transfer() needs to change to allow the driver : to specify it's mutex. I don't know what the implications are for : uhci given that it hasn't been converted to use mutexes. Can anyone : comment on that? I have changes to make sure this can't happen as well. But you must hold Giant whenever you call into the usb subsystem. : I'd love to get rid of the attach_args structure and just pass a : usbd_device_handle into the drivers, with struct usbd_device containing : a couple of extra variables for use during matching. I'd love to remove that attach_args and replace it with nothing. : I'd like to remove the subdevs array from struct usbd_device under : FreeBSD because the parent/child device tree should only be managed by : bus routines. The relationship between a USB device and it's device_t : should just be a field in struct usbd_device and it should be cleared : when there is no device_t. Leaving a device_t hanging around when a : driver had been unloaded is what is causing the panics I am seeing. I'm working on this. However, many of the panics around this area were fixed just before 5.3. : I think that the uhub driver should have a uhub_driver_added routine rather : than using the generic one. I'd really like to see the uhub code re-match : vendor/product codes when a new driver is added, and if the new driver : matches, then uhub should detach ugen and use the new driver. Similarly, : when a driver is unloaded, if a USB device is still present, it should go : back to ugen. I already deal with these things, are you sure you're looking at the current code? Well, I Don't deal with ugen, but when I have to load drivers I don't include it in my kernel. There's no harm in that. I'm working on a generic newbus way of dealing with this situation, but acpi does non-idempotent things in its probe routines :-(. Warner From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 20:33:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C5816A4CF for ; Thu, 30 Dec 2004 20:33:51 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D38E743D1D for ; Thu, 30 Dec 2004 20:33:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1144 invoked from network); 30 Dec 2004 20:33:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 30 Dec 2004 20:33:50 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBUKXLCs011963; Thu, 30 Dec 2004 15:33:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Thu, 30 Dec 2004 15:27:07 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412291715.51125.jhb@FreeBSD.org> <41D33B86.3060109@root.org> In-Reply-To: <41D33B86.3060109@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412301527.07327.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 20:33:51 -0000 On Wednesday 29 December 2004 06:19 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Tuesday 28 December 2004 06:32 pm, Pawel Worach wrote: > >>John Baldwin wrote: > >>>Are you still seeing this? > >> > >>Yes I am, updated boot -v with debug.rman_debug=1 below. > >>Sources are from 16:00 UTC today. Last working kernel I > >>have is from November 20, I can start a binary search if > >>you want. > > > > No, I'm fairly sure I know what the search would find. :) Nate, I think > > the problem here is that his link device doesn't have an associated > > device_t yet when he gets to this point. Can we force ACPI to enumerate > > all its devices and assign the associated device_t's via the > > GetData/SetData stuff before we actually probe any of the children, or do > > we do that already? > > What you want, my friend, is multi-pass newbus. Oh wait, you were one > of the proponents of that. :) > > You can overload the hack I have in acpi_probe_order() for sysresource > objects. Just do a manual check for the PNPID for PCI links and have > them probe first. I don't need them to probe first, I just need them to have a device_t associated with each ACPI handle (even an unprobed one) before any of the child devices are probed and attached. It actually wouldn't hurt to go ahead and probe them up front if that is easy to do though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 30 23:15:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6179016A4CE for ; Thu, 30 Dec 2004 23:15:28 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2AD943D73 for ; Thu, 30 Dec 2004 23:15:24 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ck9Vs-0006tl-9v for freebsd-current@freebsd.org; Thu, 30 Dec 2004 23:15:24 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ck9Vr-00032X-CM for freebsd-current@freebsd.org; Thu, 30 Dec 2004 15:15:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16852.35850.551321.875260@roam.psg.com> Date: Thu, 30 Dec 2004 13:15:22 -1000 To: FreeBSD Current Subject: netstat build problem in current of 2004.12.30 22:49 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 23:15:28 -0000 ===> usr.bin/ncplist (all) cc -O -pipe -march=pentiumpro -c /usr/src/usr.bin/ncplist/ncplist.c cc -O -pipe -march=pentiumpro -o ncplist ncplist.o -lncp -lipx gzip -cn /usr/src/usr.bin/ncplist/ncplist.1 > ncplist.1.gz ===> usr.bin/ncplogin (all) cc -O -pipe -march=pentiumpro -c /usr/src/usr.bin/ncplogin/ncplogin.c cc -O -pipe -march=pentiumpro -o ncplogin ncplogin.o -lncp -lipx gzip -cn /usr/src/usr.bin/ncplogin/ncplogin.1 > ncplogin.1.gz gzip -cn /usr/src/usr.bin/ncplogin/ncplogout.1 > ncplogout.1.gz ===> usr.bin/netstat (all) cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/if.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/inet.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/inet6.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/main.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/mbuf.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/mcast.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/mroute.c cc -O -pipe -march=pentiumpro -DIPSEC -DINET6 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.bin/netstat/ipx.c /usr/src/usr.bin/netstat/ipx.c: In function `ipxprotopr': /usr/src/usr.bin/netstat/ipx.c:100: error: structure has no member named `ipxp_next' /usr/src/usr.bin/netstat/ipx.c:102: error: structure has no member named `ipxp_next' /usr/src/usr.bin/netstat/ipx.c:105: error: structure has no member named `ipxp_next' /usr/src/usr.bin/netstat/ipx.c:107: error: structure has no member named `ipxp_prev' *** Error code 1 Stop in /usr/src/usr.bin/netstat. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 00:45:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62C0216A4CE for ; Fri, 31 Dec 2004 00:45:48 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F6F43D4C for ; Fri, 31 Dec 2004 00:45:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iBV0jlWi049977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 16:45:47 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41D4A140.8060502@errno.com> Date: Thu, 30 Dec 2004 16:45:52 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rong-En Fan References: <6eb82e04122905361ccd6af0@mail.gmail.com> <41D38FBF.5070701@errno.com> <6eb82e04123010035e379e48@mail.gmail.com> In-Reply-To: <6eb82e04123010035e379e48@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 00:45:48 -0000 Rong-En Fan wrote: > On Wed, 29 Dec 2004 21:18:55 -0800, Sam Leffler wrote: > >>wpa_supplicant has a -d option to enable debugging; use it and if you >>can't find your problem provide the wpa_supplicant config file and log >>output. > > > My current is just built tonight. I took a look at -d output, > however, i can't find any notable error messages. > > I put wpa_supplicant (0.3.2 [1]) -d output and its conf > along with dmesg, sysctl that related to ath here: > > http://rafan.infor.org/tmp/wpa/ > > Any help are appreciated :-) The log shows the WPA-PSK handshake completed but you were then deauthenticated by your AP. You need to look on your AP to find out why. It's possible that WME is being negotiated and confusing the AP. There are issues with sending QoS-encapsulated EAPOL frames to certain AP's. You can try disabling wme use with ifconfig ath0 -wme before starting wpa_supplicant. Sam From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 03:06:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB6C116A4CE; Fri, 31 Dec 2004 03:06:30 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18B2E43D5A; Fri, 31 Dec 2004 03:06:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV36Ssh051985; Thu, 30 Dec 2004 22:06:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV36S8r086756; Thu, 30 Dec 2004 22:06:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C42187306E; Thu, 30 Dec 2004 22:06:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231030628.C42187306E@freebsd-current.sentex.ca> Date: Thu, 30 Dec 2004 22:06:28 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 14:53:11 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 03:06:31 -0000 TB --- 2004-12-31 01:30:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 01:30:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-12-31 01:30:01 - checking out the source tree TB --- 2004-12-31 01:30:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-12-31 01:30:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 01:35:58 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 01:35:58 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-31 01:35:58 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 02:42:56 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 02:42:56 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-31 02:42:56 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 02:42:56 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Dec 31 02:56:33 UTC 2004 TB --- 2004-12-31 02:56:33 - generating LINT kernel config TB --- 2004-12-31 02:56:33 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-12-31 02:56:33 - /usr/bin/make -B LINT TB --- 2004-12-31 02:56:33 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 02:56:33 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-31 02:56:33 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 31 02:56:33 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/netinet6/udp6_output.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/netinet6/udp6_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx.c In file included from /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx.c:52: /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx_var.h:88: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx_var.h:88: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx_var.h:94: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/alpha/alpha/src/sys/netipx/ipx_var.h:96: warning: "struct ipxpcb" declared inside parameter list *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-12-31 03:06:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 03:06:28 - ERROR: failed to build lint kernel TB --- 2004-12-31 03:06:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 04:11:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CF5516A4CF for ; Fri, 31 Dec 2004 04:11:09 +0000 (GMT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 7549D43D5C for ; Fri, 31 Dec 2004 04:11:08 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 31 Dec 2004 04:11:07 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej); by 172.16.0.1 with HTTP; Thu, 30 Dec 2004 23:11:07 -0500 (EST) Message-ID: <1141.172.16.0.199.1104466267.squirrel@172.16.0.199> In-Reply-To: <16852.35850.551321.875260@roam.psg.com> References: <16852.35850.551321.875260@roam.psg.com> Date: Thu, 30 Dec 2004 23:11:07 -0500 (EST) From: "Mike Jakubik" To: "Randy Bush" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: FreeBSD Current Subject: Re: netstat build problem in current of 2004.12.30 22:49 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 04:11:09 -0000 Randy Bush said: > /usr/src/usr.bin/netstat/ipx.c:107: error: structure has no member named > `ipxp_prev' > *** Error code 1 Re cvsup, a fix has been commited. From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 04:43:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D418916A4CE for ; Fri, 31 Dec 2004 04:43:47 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B654243D45 for ; Fri, 31 Dec 2004 04:43:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CkEdf-000EXs-2p; Fri, 31 Dec 2004 04:43:47 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CkEdd-0000HY-4K; Thu, 30 Dec 2004 18:43:45 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16852.55551.857512.848445@roam.psg.com> Date: Thu, 30 Dec 2004 18:43:43 -1000 To: "Mike Jakubik" References: <16852.35850.551321.875260@roam.psg.com> <1141.172.16.0.199.1104466267.squirrel@172.16.0.199> cc: FreeBSD Current Subject: Re: netstat build problem in current of 2004.12.30 22:49 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 04:43:47 -0000 >> /usr/src/usr.bin/netstat/ipx.c:107: error: structure has no member named >> `ipxp_prev' >> *** Error code 1 > Re cvsup, a fix has been commited. fix confirmed randy From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 04:44:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8DAF16A4CE; Fri, 31 Dec 2004 04:44:47 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F2F143D1F; Fri, 31 Dec 2004 04:44:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV4ikSK090197; Thu, 30 Dec 2004 23:44:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV4ik8c081958; Thu, 30 Dec 2004 23:44:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7FA817306E; Thu, 30 Dec 2004 23:44:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231044446.7FA817306E@freebsd-current.sentex.ca> Date: Thu, 30 Dec 2004 23:44:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 04:44:47 -0000 TB --- 2004-12-31 03:06:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 03:06:28 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-12-31 03:06:28 - checking out the source tree TB --- 2004-12-31 03:06:28 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-12-31 03:06:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 03:12:29 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 03:12:29 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-12-31 03:12:29 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 04:19:31 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 04:19:31 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-12-31 04:19:31 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 04:19:31 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Dec 31 04:34:11 UTC 2004 TB --- 2004-12-31 04:34:12 - generating LINT kernel config TB --- 2004-12-31 04:34:12 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-12-31 04:34:12 - /usr/bin/make -B LINT TB --- 2004-12-31 04:34:12 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 04:34:12 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-12-31 04:34:12 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 31 04:34:12 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/netinet6/udp6_output.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/netinet6/udp6_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/netipx/ipx.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/netipx/ipx.c:52: /tinderbox/CURRENT/amd64/amd64/src/sys/netipx/ipx_var.h:88: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/amd64/amd64/src/sys/netipx/ipx_var.h:88: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/CURRENT/amd64/amd64/src/sys/netipx/ipx_var.h:94: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/amd64/amd64/src/sys/netipx/ipx_var.h:96: warning: "struct ipxpcb" declared inside parameter list *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-12-31 04:44:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 04:44:46 - ERROR: failed to build lint kernel TB --- 2004-12-31 04:44:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 06:53:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0553016A4CE; Fri, 31 Dec 2004 06:53:10 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 801B443D3F; Fri, 31 Dec 2004 06:53:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV6r9Ds093546; Fri, 31 Dec 2004 01:53:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV6r8mO040354; Fri, 31 Dec 2004 01:53:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFFAF7306E; Fri, 31 Dec 2004 01:53:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231065308.DFFAF7306E@freebsd-current.sentex.ca> Date: Fri, 31 Dec 2004 01:53:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 06:53:10 -0000 TB --- 2004-12-31 04:44:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 04:44:46 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-12-31 04:44:46 - checking out the source tree TB --- 2004-12-31 04:44:46 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-12-31 04:44:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 04:50:47 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 04:50:47 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-12-31 04:50:47 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 06:12:15 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 06:12:15 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-12-31 06:12:15 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 06:12:15 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Dec 31 06:37:18 UTC 2004 TB --- 2004-12-31 06:37:18 - generating LINT kernel config TB --- 2004-12-31 06:37:18 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2004-12-31 06:37:18 - /usr/bin/make -B LINT TB --- 2004-12-31 06:37:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 06:37:18 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-12-31 06:37:18 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 31 06:37:20 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/netinet6/udp6_outp ut.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/netinet6/udp6_usrr eq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx.c:52: /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:88: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:88: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:94: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:96: warning: "struct ipxpcb" declared inside parameter list *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-12-31 06:53:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 06:53:08 - ERROR: failed to build lint kernel TB --- 2004-12-31 06:53:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 07:05:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BBA516A4CF; Fri, 31 Dec 2004 07:05:17 +0000 (GMT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8045D43D48; Fri, 31 Dec 2004 07:05:16 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd3mr5so.prod.shaw.ca (pd3mr5so-qfe3.prod.shaw.ca [10.0.141.12])2004)) with ESMTP id <0I9K00GN7RO45560@l-daemon>; Fri, 31 Dec 2004 00:04:52 -0700 (MST) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd3mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I9K009BBRO4UM20@pd3mr5so.prod.shaw.ca>; Fri, 31 Dec 2004 00:04:52 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I9K00L2JRO3HL@l-daemon>; Fri, 31 Dec 2004 00:04:52 -0700 (MST) Date: Thu, 30 Dec 2004 23:04:47 -0800 From: Colin Percival To: rwatson@freebsd.org Message-id: <41D4FA0F.7000600@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime User-Agent: Mozilla Thunderbird 0.9 (X11/20041107) cc: current@freebsd.org Subject: [Fwd: [current tinderbox] failure on i386/i386] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 07:05:17 -0000 Robert, Looks like you need to add "struct ipxpcb;" somewhere around line 80 of src/sys/netipx/ipx_var.h Colin Percival -------- Original Message -------- Subject: [current tinderbox] failure on i386/i386 Date: Fri, 31 Dec 2004 01:53:08 -0500 (EST) From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx.c:52: /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:88: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:88: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:94: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/i386/i386/src/sys/netipx/ipx_var.h:96: warning: "struct ipxpcb" declared inside parameter list *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 08:10:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5064D16A4CE; Fri, 31 Dec 2004 08:10:37 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E488E43D2D; Fri, 31 Dec 2004 08:10:36 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV8AaRQ061708; Fri, 31 Dec 2004 03:10:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBV8AZqs072680; Fri, 31 Dec 2004 03:10:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4EB207306E; Fri, 31 Dec 2004 03:10:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231081035.4EB207306E@freebsd-current.sentex.ca> Date: Fri, 31 Dec 2004 03:10:35 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 14:53:11 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 08:10:37 -0000 TB --- 2004-12-31 06:53:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 06:53:09 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-12-31 06:53:09 - checking out the source tree TB --- 2004-12-31 06:53:09 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-12-31 06:53:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 06:59:09 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 06:59:09 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-12-31 06:59:09 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 08:07:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 08:07:05 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-12-31 08:07:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 08:07:05 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ln -s /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC/opt_usb.h opt_usb.h awk -f @/tools/usbdevs2h.awk @/dev/usb/usbdevs -h ln -s /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC/opt_bus.h opt_bus.h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -DPC98 -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC usb_if.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/hid.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/uhub.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb_mem.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb_quirks.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb_subr.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usbdi.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usbdi_util.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb_ethersubr.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/uhci_pci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/ usb/../../dev/usb/uhci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/ohci_pci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/ohci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/ehci_pci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/ehci.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb/../../dev/usb/usb_subr.c:122:26: usbdevs_data.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/usb. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-12-31 08:10:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 08:10:35 - ERROR: failed to build generic kernel TB --- 2004-12-31 08:10:35 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 09:54:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E60C16A4CE for ; Fri, 31 Dec 2004 09:54:11 +0000 (GMT) Received: from msr22.hinet.net (msr22.hinet.net [168.95.4.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA4A243D39 for ; Fri, 31 Dec 2004 09:54:10 +0000 (GMT) (envelope-from d9364104@mail.nchu.edu.tw) Received: from localhost.localdomain (61-221-58-28.HINET-IP.hinet.net [61.221.58.28]) by msr22.hinet.net (8.9.3/8.9.3) with ESMTP id RAA19456; Fri, 31 Dec 2004 17:54:03 +0800 (CST) From: Chen Lihong To: current@freebsd.org In-Reply-To: <41D4A140.8060502@errno.com> References: <6eb82e04122905361ccd6af0@mail.gmail.com> <6eb82e04123010035e379e48@mail.gmail.com> <41D4A140.8060502@errno.com> Content-Type: text/plain Date: Fri, 31 Dec 2004 17:54:04 +0800 Message-Id: <1104486844.43764.6.camel@OmniBook.accton.com.tw> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: Sam Leffler cc: Rong-En Fan Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 09:54:11 -0000 I am using wpa_supplicant 0.3.2. I can associated and authenticated with my AP with WPA/TKIP/1X-KEY-MGMT. The hosts that at wired side can send packets to my FreeBSD station, but wired hosts can not receive any station's packets. Then, I use AiroPeek to capture wireless packets. I saw that any data packet sent by wired side is encrypted, and station can decrypte that well. When station reply or send any packet it is not encrypted, at this time AP may drop the packet. On Thu, 2004-12-30 at 16:45 -0800, Sam Leffler wrote: > Rong-En Fan wrote: > > On Wed, 29 Dec 2004 21:18:55 -0800, Sam Leffler wrote: > > > >>wpa_supplicant has a -d option to enable debugging; use it and if you > >>can't find your problem provide the wpa_supplicant config file and log > >>output. > > > > > > My current is just built tonight. I took a look at -d output, > > however, i can't find any notable error messages. > > > > I put wpa_supplicant (0.3.2 [1]) -d output and its conf > > along with dmesg, sysctl that related to ath here: > > > > http://rafan.infor.org/tmp/wpa/ > > > > Any help are appreciated :-) > > The log shows the WPA-PSK handshake completed but you were then > deauthenticated by your AP. You need to look on your AP to find out why. > > It's possible that WME is being negotiated and confusing the AP. There > are issues with sending QoS-encapsulated EAPOL frames to certain AP's. > You can try disabling wme use with > > ifconfig ath0 -wme > > before starting wpa_supplicant. > > Sam > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 10:33:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A68F16A4CE; Fri, 31 Dec 2004 10:33:28 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEFD943D41; Fri, 31 Dec 2004 10:33:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVAXRpT065827; Fri, 31 Dec 2004 05:33:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVAXQQ1011002; Fri, 31 Dec 2004 05:33:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B64B07306E; Fri, 31 Dec 2004 05:33:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231103326.B64B07306E@freebsd-current.sentex.ca> Date: Fri, 31 Dec 2004 05:33:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 14:53:11 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 10:33:28 -0000 TB --- 2004-12-31 08:10:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 08:10:35 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-12-31 08:10:35 - checking out the source tree TB --- 2004-12-31 08:10:35 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-12-31 08:10:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 08:24:06 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 08:24:06 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-12-31 08:24:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 09:59:14 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 09:59:14 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-12-31 09:59:14 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 09:59:14 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Dec 31 10:19:14 UTC 2004 TB --- 2004-12-31 10:19:14 - generating LINT kernel config TB --- 2004-12-31 10:19:14 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2004-12-31 10:19:14 - /usr/bin/make -B LINT TB --- 2004-12-31 10:19:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 10:19:14 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-12-31 10:19:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 31 10:19:14 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/netinet6/udp6_output.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/netinet6/udp6_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx.c In file included from /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx.c:52: /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx_var.h:88: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx_var.h:88: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx_var.h:94: warning: "struct ipxpcb" declared inside parameter list /tinderbox/CURRENT/ia64/ia64/src/sys/netipx/ipx_var.h:96: warning: "struct ipxpcb" declared inside parameter list *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-12-31 10:33:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 10:33:26 - ERROR: failed to build lint kernel TB --- 2004-12-31 10:33:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 12:57:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4D8416A4CE for ; Fri, 31 Dec 2004 12:57:02 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF6843D31 for ; Fri, 31 Dec 2004 12:57:02 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.6) (authenticated as u86211448) id 4199C6960002EE62; Fri, 31 Dec 2004 13:56:55 +0100 Message-ID: <41D54C92.3010407@telia.com> Date: Fri, 31 Dec 2004 13:56:50 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20041223) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chen Lihong References: <6eb82e04122905361ccd6af0@mail.gmail.com> <6eb82e04123010035e379e48@mail.gmail.com> <41D4A140.8060502@errno.com> <1104486844.43764.6.camel@OmniBook.accton.com.tw> In-Reply-To: <1104486844.43764.6.camel@OmniBook.accton.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Sam Leffler cc: Rong-En Fan cc: current@freebsd.org Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 12:57:02 -0000 Chen Lihong wrote: > I am using wpa_supplicant 0.3.2. > I can associated and authenticated with my AP with WPA/TKIP/1X-KEY-MGMT. > The hosts that at wired side can send packets to my FreeBSD station, but > wired hosts can not receive any station's packets. > Then, I use AiroPeek to capture wireless packets. I saw that any data > packet sent by wired side is encrypted, and station can decrypte that > well. > When station reply or send any packet it is not encrypted, at this time > AP may drop the packet. > I think I see the same problem, enabling 802.11 and ath debugging yields this "kernel: [00:11:95:3a:46:39] no default transmit key". I have no idea how my AP can give me an IP address but I still can't send any traffic. This was using WPA-PSK/TKIP with wpa_supplicant 0.3.0. Try enabling some debugging and check if you see the same thing: sysctl dev.ath.0.debug=0x20000 sysctl net.wlan.0.debug=0x10001000 Full kernel debug output: kernel: ath_key_update_begin: kernel: ath_key_delete: delete key 0 kernel: ath_key_update_end: kernel: ath_key_update_begin: kernel: ath_key_delete: delete key 1 kernel: ath_key_update_end: kernel: ath_key_update_begin: kernel: ath_key_delete: delete key 2 kernel: ath_key_update_end: kernel: ath_key_update_begin: kernel: ath_key_delete: delete key 3 kernel: ath_key_update_end: kernel: ath_init: if_flags 0x8903 kernel: ath_stop_locked: invalid 0 if_flags 0x8903 kernel: ath_initkeytable: reset key 0 kernel: ath_initkeytable: reset key 1 kernel: ath_initkeytable: reset key 2 kernel: ath_initkeytable: reset key 3 kernel: ieee80211_newstate: INIT -> SCAN kernel: ieee80211_newstate: SCAN -> SCAN [more scanning] kernel: ieee80211_newstate: SCAN -> SCAN kernel: [ff:ff:ff:ff:ff:ff] send probe_req on channel 10 kernel: ath_start: ignore data packet, state 1 last message repeated 2 times kernel: ath0: received probe_resp from 00:11:95:3a:46:39 rssi 32 kernel: ath0: received beacon from 00:11:95:3a:46:39 rssi 32 kernel: ath0: received beacon from 00:11:95:3a:46:39 rssi 30 kernel: ath_key_update_begin: kernel: ath_key_update_end: kernel: ieee80211_newstate: SCAN -> AUTH kernel: [00:11:95:3a:46:39] send auth on channel 10 kernel: ath_staath_start: ignore data packet, state 2 kernel: rt: ignore data packet, state 2 kernel: ath_start: ignore data packet, state 2 kernel: ath0: received auth from 00:11:95:3a:46:39 rssi 28 kernel: ieee80211_newstate: AUTH -> ASSOC kernel: [00:11:95:3a:46:39] send assoc_req on channel 10 kernel: ath_start: ignore data packet, state 3 last message repeated 2 times kernel: ath0: received assoc_resp from 00:11:95:3a:46:39 rssi 28 kernel: ieee80211_newstate: ASSOC -> RUN kernel: ath0: associated with 00:11:95:3a:46:39 ssid "Unknown10" channel 10 start 36Mb kernel: ath_key_update_begin: kernel: ath_keyset_tkip: [00] TKIP 2135386f071435017a6381ace441f9de mac 00:00:00:00:00:00 mic f536ed0931076b74 kernel: ath_keyset_tkip: [32] TKIP 2135386f071435017a6381ace441f9de mac 00:11:95:3a:46:39 mic 2ea713b61a53cdc2 kernel: ath_key_update_end: kernel: ath_key_update_begin: kernel: ath_keyset_tkip: [02] TKIP fe34c355fc29db8723c490390296706a mac 00:00:00:00:00:00 mic 729fa3ee38c77f87 kernel: ath_key_update_end: kernel: [00:11:95:3a:46:39] TKIP replay detected kernel: [00:11:95:3a:46:39] no default transmit key kernel: [00:11:95:3a:46:39] no default transmit key dhclient: New IP Address (ath0): 192.168.10.102 dhclient: New Subnet Mask (ath0): 255.255.255.0 dhclient: New Broadcast Address (ath0): 192.168.10.255 dhclient: New Routers: 192.168.10.1 kernel: [00:11:95:3a:46:39] no default transmit key last message repeated 2 times -- Pawel From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 13:05:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BABF616A4CE; Fri, 31 Dec 2004 13:05:09 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B13743D3F; Fri, 31 Dec 2004 13:05:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVD58O1070455; Fri, 31 Dec 2004 08:05:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVD58aa050981; Fri, 31 Dec 2004 08:05:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 64DD87306E; Fri, 31 Dec 2004 08:05:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231130508.64DD87306E@freebsd-current.sentex.ca> Date: Fri, 31 Dec 2004 08:05:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 13:05:10 -0000 TB --- 2004-12-31 11:51:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 11:51:08 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-12-31 11:51:08 - checking out the source tree TB --- 2004-12-31 11:51:08 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-12-31 11:51:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 11:57:17 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 11:57:17 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-12-31 11:57:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 13:03:16 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 13:03:16 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-12-31 13:03:16 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 13:03:17 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ln -s /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC/opt_usb.h opt_usb.h awk -f @/tools/usbdevs2h.awk @/dev/usb/usbdevs -h ln -s /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC/opt_bus.h opt_bus.h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC usb_if.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/hid.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/uhub.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb_mem.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb_quirks.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb_subr.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usbdi.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usbdi_util.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb_ethersubr.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/.. /../dev/usb/uhci_pci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/uhci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/ohci_pci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/ohci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/ehci_pci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/ehci.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb/../../dev/usb/usb_subr.c:122:26: usbdevs_data.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/usb. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-12-31 13:05:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 13:05:08 - ERROR: failed to build generic kernel TB --- 2004-12-31 13:05:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 15:05:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FCCD16A4CF for ; Fri, 31 Dec 2004 15:05:37 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBFC243D49 for ; Fri, 31 Dec 2004 15:05:36 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CkOLP-000514-Qe; Fri, 31 Dec 2004 15:05:35 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CkOLN-0000z0-Ib; Fri, 31 Dec 2004 05:05:33 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16853.27324.504672.6086@roam.psg.com> Date: Fri, 31 Dec 2004 05:05:32 -1000 To: "M. Warner Losh" References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <20041230.111631.13597845.imp@bsdimp.com> cc: FreeBSD Current Subject: Re: USB problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 15:05:37 -0000 possibly related? just so you know, on a thinkpad t41 with any current in the last few weeks, i kernel panic on boot if a usb device is not plugged in. turning off acpi also allows boot. see i can help debug if anyone is on the trail randy From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 18:18:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 113F416A4CE for ; Fri, 31 Dec 2004 18:18:35 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D690C43D31 for ; Fri, 31 Dec 2004 18:18:34 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iBVIIXWi053970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2004 10:18:34 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41D597F1.4000902@errno.com> Date: Fri, 31 Dec 2004 10:18:25 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chen Lihong References: <6eb82e04122905361ccd6af0@mail.gmail.com> <6eb82e04123010035e379e48@mail.gmail.com> <41D4A140.8060502@errno.com> <1104486844.43764.6.camel@OmniBook.accton.com.tw> In-Reply-To: <1104486844.43764.6.camel@OmniBook.accton.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Rong-En Fan cc: current@freebsd.org Subject: Re: 802.11 WPA and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 18:18:35 -0000 Chen Lihong wrote: > I am using wpa_supplicant 0.3.2. > I can associated and authenticated with my AP with WPA/TKIP/1X-KEY-MGMT. > The hosts that at wired side can send packets to my FreeBSD station, but > wired hosts can not receive any station's packets. > Then, I use AiroPeek to capture wireless packets. I saw that any data > packet sent by wired side is encrypted, and station can decrypte that > well. > When station reply or send any packet it is not encrypted, at this time > AP may drop the packet. > Looks like I need to push some changes from perforce into CVS. Sam From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 23:00:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B64716A4CE; Fri, 31 Dec 2004 23:00:57 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E70E043D2D; Fri, 31 Dec 2004 23:00:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVN0u7D096371; Fri, 31 Dec 2004 18:00:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBVN0tI3034915; Fri, 31 Dec 2004 18:00:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CC3E87306E; Fri, 31 Dec 2004 18:00:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041231230055.CC3E87306E@freebsd-current.sentex.ca> Date: Fri, 31 Dec 2004 18:00:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 14:53:11 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 23:00:57 -0000 TB --- 2004-12-31 21:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-31 21:45:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-12-31 21:45:00 - checking out the source tree TB --- 2004-12-31 21:45:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-12-31 21:45:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-31 21:50:56 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-31 21:50:56 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-31 21:50:56 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-12-31 22:57:37 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-31 22:57:37 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-31 22:57:37 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 31 22:57:37 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/ignore_pci.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/isa_pci.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c: In function `pci_set_powerstate_method': /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c:528: error: `PCI_POWER_STATE_D3' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c:528: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c:528: error: for each function it appears in.) /tinderbox/CURRENT/alpha/alpha/src/sys/dev/pci/pci.c:530: error: `PCI_POWER_STATE_D2' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-12-31 23:00:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-31 23:00:55 - ERROR: failed to build generic kernel TB --- 2004-12-31 23:00:55 - tinderbox aborted