From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 00:31: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 EB6AE16A4CE for ; Sun, 25 Jan 2004 00:31:07 -0800 (PST) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [209.5.243.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D52743D39 for ; Sun, 25 Jan 2004 00:31:06 -0800 (PST) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id DE1C862721; Sun, 25 Jan 2004 02:31:21 -0600 (CST) Date: Sun, 25 Jan 2004 02:31:21 -0600 From: Mark Johnston To: current@freebsd.org Message-ID: <20040125083121.GE1314@omoikane.mb.skyweb.ca> Mail-Followup-To: current@freebsd.org References: <20040124070846.GA595@omoikane.mb.skyweb.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040124070846.GA595@omoikane.mb.skyweb.ca> User-Agent: Mutt/1.4.1i Subject: Re: RFC: Weekly status update 17/01/04-23/01/04 (cvs-src summary) 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, 25 Jan 2004 08:31:08 -0000 This is a multi-followup that covers a few different things I got replies on. The question asked most was, essentially, "How did you decide what to rate where?" The answer is "Arbitrarily", but I'll be tuning the process up next week, mostly by looking at PRs closed as an indicator of how important a commit was. The most-requested addition was a link to the discussion thread/CVS commit message. I wasn't sure whether to add this initially, not knowing whether it would be used, but it sounds like it's worth the extra work for the number of people that would use it. I also had some suggestions on things that could be included and easier ways to publish - I'll be talking those over with Jonathan Sage and Matteo Riondato, both of whom are working on reports as well. Mark From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 00:53: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 4C40F16A4CE for ; Sun, 25 Jan 2004 00:53:39 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2CA543D39 for ; Sun, 25 Jan 2004 00:53:36 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i0P8rTLE018985; Sun, 25 Jan 2004 19:53:29 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0P8rPdC023836; Sun, 25 Jan 2004 19:53:27 +1100 Date: Sun, 25 Jan 2004 19:53:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp In-Reply-To: <44827.1074974041@critter.freebsd.dk> Message-ID: <20040125183335.B30359@gamplex.bde.org> References: <44827.1074974041@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: 'Bill Moran' cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 08:53:39 -0000 On Sat, 24 Jan 2004, Poul-Henning Kamp wrote: > In message <200401241948.i0OJmDpo036688@apollo.backplane.com>, Matthew Dillon w > rites: > > There are a couple of things going on here... it isn't all just fluff. > > > > First, the basic problem is that nanosleep() (aka sleep() aka > > usleep()) consistently sleeps for far longer then the requested time. > > I think this was subject to Brucification last it was raised on our > lists. Do you mean "subject to getting the details right"? [Some context recovered] > > Second, the fractional compensation code for the 8254. The 8254 runs > > at 1193182 Hz. If your 'hz' is set to 100, a fixed clock reload value > > of 11931 looses significant precision. The higher your 'hz' setting, > > the more precision is lost and the greater the error verses real time. (The rounding is actually to nearest so 1193182 / 100 is rounded to 11932, not 11931.) 1193182 is only a nominal frequency. On machines I'm running right now, the actual frequency is 1193202, 1193211 and 1193276 (+-2 most days). So using the default of 11932 loses quite a bit to both accuracy and precision. However, small errors are unimportant in most or all applications, and the accuracy is easy to fix using "sysctl machdep.i8254_freq=whatever". I set all my clocks using the relevant sysctl so that they are all as accurate as possible. For the i8254 clock, the best possible is 0.5 / 1193182 seconds or about 0.5 ppm, since fractional frequencies can't be set. 0.5 ppm is a good practical accuracy to aim for since the frequencies of all clocks on all my machines drift with the temperature by about +- 2 ppm every day. I try for 0.1 ppm long term accuracy using the TSC timecounter and only use other timecounters for testing. > > If you are using the 8254 as your wallclock, then you will see a > > significant 'speed up' of the wall clock at higher hz settings. > Unless you have replaced timecounters this is not true. Timecounters > are insensitive to how your Hz ticks, as long as it does it often > enough. (You should probably pull in the code from -current though, > the 4.x code has some marginal issues). > > > hz will wind up being far higher then the true frequency you > > requested. It isn't just jitter... it's a permanent error factor and > > it can create significant problems if you are running ntpd. > > Only if you replaced timecounters. Indeed. The long-term drift from lost precision in scaling 1193182 by HZ is zero, and the long-term drift from 1193182 being accurate is whatever it is (can be quite large). After fixing the inaccuracy as above, the long-term drift due to innacuracy is significantly smaller than the combination of short-term drifts due to nondeterministic temperature. ntp can handle innacuracy well enough (better than it can handle short-term drifts) provided it is not too large (too large is hundreds of ppm). Short-term innaccuracy and imprecision is seen mainly by select() and related timeouts, but it doesn't really matter in most cases since it doesn't (or shouldn't) get a chance to build up. E.g., if there is an off-by-1 error setting the i8254 maxiumum count, then the period between timeouts will be wrong by about 1 usec (1/1193182). 1 usec just doesn't matter even on a pseudo-real-time system because interrupt latency is more than that even without -current's pessimization of interrupts. The inaccuracy can build up in some cases, but not in places like nanotime() which don't simply count off a number of ticks. nanotime()'s innacuracy has differenct sources. > > Third, if you are not using the 8254 for your wallclock there will be > > persistent drift between clocks based on the 8254's hz-based interface > > (ticks) and clocks based on realtime. The PLL part of the fix simply > > compensates for the 8254's constant drift relative to the wallclock > > by occassionally adding one or subtracting one from the 8254's reload > > value. > > This is harmless but IMO also pointless. Setting the frequencies of all the clocks as above gives this to within the precision of the frequency setting. Synchronizing the frequencies is useful mainly for testing. It's annoying for ntp to see large changes in the drift when you switch the timecounter. Keeping the nominal frequencies of all the clocks relatively correct to within 0.5 ppm limits the drift to this amount and ntp can't tell the difference between this and a drift from temperature changes. Bruce From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 01:10: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 52CAE16A4CE for ; Sun, 25 Jan 2004 01:10:01 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1F6A43D1F for ; Sun, 25 Jan 2004 01:09:59 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0P99juO050876; Sun, 25 Jan 2004 10:09:50 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 24 Jan 2004 20:45:14 MST." <20040124.204514.109171577.imp@bsdimp.com> Date: Sun, 25 Jan 2004 10:09:45 +0100 Message-ID: <50875.1075021785@critter.freebsd.dk> cc: wmoran@potentialtech.com cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 09:10:01 -0000 In message <20040124.204514.109171577.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <200401242031.i0OKVD8A037265@apollo.backplane.com> > Matthew Dillon writes: >: No apic timer. No acpi timer. No TSC garbage. none of that. > >Maybe there are better ways to obtain these results. While not >directly releated to the nanosleep work, but just another point of >view. Most of the uglyness in timecounters comes in for the hardware independence. A major design goal was to make it as totally trivial at write the code necessary for a hardware-gadget to feed timecounters. I didn't want to see people who port to new archs run into code where they have to sit and do fixed-point binary math and worry about accumulative rounding errors and other weirdness. I also made the interfaces to the entire timecounter code very simple so that it could be replaced by an optimized platform specific implementation. (For instance on platforms which have a good calibrated nanosecond counter, s390 comes to mind). Knowing the precision you need to support up front means that you don't need the hysteric precision of timecounters. If Matt is only interested in the PC platform with sufficiently clued users, he can afford to make the choice of timekeeping a boot-time or even compile-time fixable just like it is in so many other UNIX kernels. A very good place to start is the "nanokernel" from Dave Mills, and I hope that Matt will consider it, even if I'm listed as co-author on the paper :-) It does suffer from a number of gremlins down in the weeniesecond domain, but I don't think Matt will need to worry about that but it would give him all the ntpd magic for free. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 01:21: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 E80B116A4CE for ; Sun, 25 Jan 2004 01:21:02 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A04A143D49 for ; Sun, 25 Jan 2004 01:20:57 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0P9KquO051124; Sun, 25 Jan 2004 10:20:53 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jan 2004 19:53:26 +1100." <20040125183335.B30359@gamplex.bde.org> Date: Sun, 25 Jan 2004 10:20:52 +0100 Message-ID: <51123.1075022452@critter.freebsd.dk> cc: 'Bill Moran' cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 09:21:03 -0000 In message <20040125183335.B30359@gamplex.bde.org>, Bruce Evans writes: >relevant sysctl so that they are all as accurate as possible. For the >i8254 clock, the best possible is 0.5 / 1193182 seconds or about 0.5 >ppm, since fractional frequencies can't be set. 0.5 ppm is a good >practical accuracy to aim for since the frequencies of all clocks on >all my machines drift with the temperature by about +- 2 ppm every >day. It is indeed worth noting that while quartz crystals has just the right combination of properties to be our only affordable timekeeping device of any precision (in fact: no other crystals have the right combination of properties), it is even better at measuring temperature. For anybody venturing into timekeeping I would really urge you to start by reading John. R Vig's tutorial "Introduction to Quartz Frequency Standards" before you attempt anything: http://www.ieee-uffc.org/fcmain.asp?view=review Also, you have to realize that you need _three_ identically good oscillators for measuring anything, unless you have a GPS receiver with precision PPS output. It's an expensive hobby, but very rewarding, for people with an inclination to physics: http://www.leapsecond.com/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:00: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 918AC16A4CE for ; Sun, 25 Jan 2004 03:00:41 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AE143D1D for ; Sun, 25 Jan 2004 03:00:40 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 96707530A; Sun, 25 Jan 2004 12:00:38 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id BCD825308; Sun, 25 Jan 2004 12:00:28 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 259DF33C9A; Sun, 25 Jan 2004 12:00:28 +0100 (CET) To: Bruce Evans References: <20040124074052.GA12597@cirb503493.alcatel.com.au> <20040125143203.G29442@gamplex.bde.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 25 Jan 2004 12:00:27 +0100 In-Reply-To: <20040125143203.G29442@gamplex.bde.org> (Bruce Evans's message of "Sun, 25 Jan 2004 17:28:31 +1100 (EST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 cc: Peter Jeremy cc: freebsd-current@freebsd.org Subject: Re: 80386 support in -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: Sun, 25 Jan 2004 11:00:41 -0000 Bruce Evans writes: > This is the specious reason. The synchronization code relies on a > particular instruction that might be very inefficient to emulate on a > 386, but emulation is not done; the instruction is just replaced by > an instruction or sequence of instructions that is slower in some cases > and faster in others (mostly slower, but not especially so, except > probably on P4's). that's actually what I meant by emulated... as for the rest, I bow to your superior knowledge. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:04: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 07ED116A4CE; Sun, 25 Jan 2004 03:04:29 -0800 (PST) Received: from happygiraffe.net (happygiraffe.net [81.6.215.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F00E43D31; Sun, 25 Jan 2004 03:04:27 -0800 (PST) (envelope-from dom@happygiraffe.net) Received: from localhost (localhost.happygiraffe.net [127.0.0.1]) by happygiraffe.net (Postfix) with ESMTP id 02B4AB83E; Sun, 25 Jan 2004 11:04:26 +0000 (GMT) Received: from happygiraffe.net ([127.0.0.1]) by localhost (ppe.happygiraffe.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 35528-04-2; Sun, 25 Jan 2004 11:04:25 +0000 (GMT) Received: by happygiraffe.net (Postfix, from userid 1001) id 52A31B80A; Sun, 25 Jan 2004 11:04:25 +0000 (GMT) Date: Sun, 25 Jan 2004 11:04:25 +0000 To: Robert Watson Message-ID: <20040125110425.GA35789@ppe.happygiraffe.net> References: <003c01c3de8d$d569edb0$471b3dd4@dual> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i From: dom@happygiraffe.net (Dominic Mitchell) X-Virus-Scanned: by amavisd-new at happygiraffe.net cc: performance@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: Old SUN NFS performance papers. 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, 25 Jan 2004 11:04:29 -0000 On Sat, Jan 24, 2004 at 09:14:51PM -0500, Robert Watson wrote: > I haven't done much benchmarking on NFS lately, but something worth > remembering is that people have spent a lot of time researching and > optimizing TCP for a variety of connection types, whereas the NFS code > basically has a static implementation of RPC backoff and flow control that > hasn't evolved much. TCP is aware of things like the pathwise-mtu to the > server and adapts, whereas UDP just loses packets due to fragmentation, > especially if you are using larger block sizes. Please do post your > discoveries on performance@, and perhaps we could build an NFS performance > tuning section in the FreeBSD Handbook (or if there's not that much > content, add it to the FAQ)? I'm just playing with this... The first thing to note (probably) is to check that you can ping your server with a similiar size packet to the one you're using. I realised that my network isn't as robust as I thought it was very quickly yesterday, when pinging my server with an 8k packet. I was seeing 70% packet loss. The default ping showed no problems at all. The reason I mention it is that I'd been playing with NFS tuning because I had been seeing lockups. But the fault really lies at a lower level than NFS, it appears. -Dom From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:17: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 42E7216A4CE for ; Sun, 25 Jan 2004 03:17:44 -0800 (PST) Received: from forthnet.gr (athmta05.forthnet.gr [193.92.150.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD5DE43D39 for ; Sun, 25 Jan 2004 03:17:41 -0800 (PST) (envelope-from lefcha@hellug.gr) Received: from localhost.my.domain (ppp2-isdn-64.the.forthnet.gr [213.16.247.64]) by forthnet.gr (8.12.2-20030919/8.12.2) with ESMTP id i0PBHd58026656 for ; Sun, 25 Jan 2004 13:17:40 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.12.10/8.12.10) with ESMTP id i0PBHi4R000609 for ; Sun, 25 Jan 2004 13:17:44 +0200 (EET) (envelope-from lefcha@hellug.gr) Received: (from lefcha@localhost) by localhost.my.domain (8.12.10/8.12.10/Submit) id i0PBHifg000608 for freebsd-current@freebsd.org; Sun, 25 Jan 2004 13:17:44 +0200 (EET) (envelope-from lefcha@hellug.gr) X-Authentication-Warning: localhost.my.domain: lefcha set sender to lefcha@hellug.gr using -f Date: Sun, 25 Jan 2004 13:17:44 +0200 From: Lefteris Chatzibarbas To: freebsd-current@freebsd.org Message-ID: <20040125111743.GA564@bsd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: System still hangs with "ata1-master: TIMEOUT - SETFEATURES SET TRANSFER 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: Sun, 25 Jan 2004 11:17:44 -0000 Hello, Devices are: ad0: ATA-6 disk at ata0-master acd0: DVDROM drive at ata1 as master acd1: CDRW drive at ata1 as slave Verbose boot of a good kernel: http://members.hellug.gr/lefcha/dmesg.out System still hangs during boot with the message: ata1-master: TIMEOUT - SETFEATURES SET TRANSFER MODE retrying (0 retries left) ... and verbose boot: ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x10 err=0x01 lib=0x14 msb=0xeb ata1-slave: stat=0x10 err=0x01 lib=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=10 stat1=00 devices=0xc ata1: resetting done .. ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=80pin ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x10 err=0x01 lib=0x14 msb=0xeb ata1-slave: stat=0x10 err=0x01 lib=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=10 stat1=00 devices=0xc ata1: resetting done .. ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=80pin Soren Schmidt's commit 2004/01/19 07:20:00 PST: 1.202 +2 -1 src/sys/dev/ata/ata-all.c 1.71 +1 -1 src/sys/dev/ata/ata-all.h 1.17 +23 -21 src/sys/dev/ata/ata-queue.c 1.161 +1 -1 src/sys/dev/ata/atapi-cd.c ... or: http://lists.freebsd.org/pipermail/cvs-src/2004-January/016880.html ... didn't correct the problem. Thanks From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:19: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 234DC16A4CE; Sun, 25 Jan 2004 03:19:51 -0800 (PST) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [62.58.162.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBBFD43D5F; Sun, 25 Jan 2004 03:19:43 -0800 (PST) (envelope-from sten@blinkenlights.nl) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 3B7F9383; Sun, 25 Jan 2004 12:15:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 2E49C1C4; Sun, 25 Jan 2004 12:15:36 +0100 (CET) Date: Sun, 25 Jan 2004 12:15:36 +0100 (CET) From: Sten Spans To: Mike Jakubik In-Reply-To: <20040125012602.XMOS163351.fep03-mail.bloor.is.net.cable.rogers.com@win2000> Message-ID: References: <20040125012602.XMOS163351.fep03-mail.bloor.is.net.cable.rogers.com@win2000> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hardware@freebsd.org cc: current@freebsd.org Subject: Re: LSI MegaRAID SCSI 320-0 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, 25 Jan 2004 11:19:51 -0000 On Sat, 24 Jan 2004, Mike Jakubik wrote: > Does anyone know if the LSI Logic MegaRAID SCSI 320-0 Zero-channel > (ZCR) Ultra320 SCSI RAID card is supported? I know the amr man page doesn't > list the ZCR card specifically, but im hoping someone forgot to list it :) The serial ata raid cards ( Megaraid 150-x ) aint listed either but do work with the amr driver. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:24: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 1B1AF16A4CF; Sun, 25 Jan 2004 03:24:34 -0800 (PST) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7298C43D45; Sun, 25 Jan 2004 03:24:32 -0800 (PST) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 3000) id 1456C11858; Sun, 25 Jan 2004 12:24:31 +0100 (CET) Date: Sun, 25 Jan 2004 12:24:30 +0100 From: "Simon L. Nielsen" To: Sten Spans Message-ID: <20040125112429.GA921@arthur.nitro.dk> References: <20040125012602.XMOS163351.fep03-mail.bloor.is.net.cable.rogers.com@win2000> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i cc: Mike Jakubik cc: hardware@freebsd.org cc: current@freebsd.org Subject: Re: LSI MegaRAID SCSI 320-0 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, 25 Jan 2004 11:24:34 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.01.25 12:15:36 +0100, Sten Spans wrote: > On Sat, 24 Jan 2004, Mike Jakubik wrote: >=20 > > Does anyone know if the LSI Logic MegaRAID SCSI 320-0 Zero-channel > > (ZCR) Ultra320 SCSI RAID card is supported? I know the amr man page doe= sn't > > list the ZCR card specifically, but im hoping someone forgot to list it= :) >=20 > The serial ata raid cards ( Megaraid 150-x ) aint listed either but do > work with the amr driver. Then it would be great if you file a PR about it so it can be listed :-). The lists (unfortunatly) doesn't update themself ;-). --=20 Simon L. Nielsen FreeBSD Documentation Team --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAE6dth9pcDSc1mlERAlcRAJ9X9lU0xzCQsG4TmA59vKhaajgUdACdE/m1 0pQtPRQ9Xw8QNbNocxfJQNQ= =J0IR -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:51: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 E159016A4CF; Sun, 25 Jan 2004 03:51:58 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D8EE43D55; Sun, 25 Jan 2004 03:51:56 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i0PBpaN1091909 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 25 Jan 2004 12:51:47 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i0PBpFFq075666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2004 12:51:16 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i0PBpEPw096176; Sun, 25 Jan 2004 12:51:15 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i0PBpDd5096175; Sun, 25 Jan 2004 12:51:13 +0100 (CET) (envelope-from ticso) Date: Sun, 25 Jan 2004 12:51:12 +0100 From: Bernd Walter To: Tom Ponsford Message-ID: <20040125115111.GN77998@cicely12.cicely.de> References: <4011B6F6.5040306@theriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4011B6F6.5040306@theriver.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Same problem, new year 2100A machine check X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 11:51:59 -0000 On Fri, Jan 23, 2004 at 05:06:14PM -0700, Tom Ponsford wrote: > I decided to replace a disk on the ol' 2100A. I had been running VMS on it > without any troubles, until a disk started giving me errors. After > replacing the disk, I decided to give 5.2 a go, thinking maybe some of the > problems of last year may have been resolved. > > No such luck. > > As you can see below, it's doing the machine check at almost the same point > as last year. In combing the archives, it seems that there were problems > with some cards, so I yanked out all the pci cards (there were no EISA > cards), still a machine check. > > This machine booted and ran stable under 4-xx with a uniprocessor kernel > > It seems you may have to disable the machine checks in order to get this > beast to boot, any pointers on where to start? > I'd like to play with it with FBSD before going back to VMS. > > Below is the console firmware pre-boot diag and then the actual boot -v > output and then the show config and show fru. > > Cheers > > Tom > > > eisab0: at device 2.0 on pci0 > > unexpected machine check: > > mces = 0x1 > vector = 0x670 > param = 0xfffffc0000006000 > pc = 0xfffffc00003b48d4 > ra = 0xfffffc00003b4908 > curproc = 0xfffffc0000810ee0 > pid = 0, comm = swapper > > panic: machine check > cpuid = 0; > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort Maybe there is something wrong with the EISA configuration on your machine. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:52: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 331A816A4DA for ; Sun, 25 Jan 2004 03:52:19 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6B9D43D1F for ; Sun, 25 Jan 2004 03:52:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0PBqF82042053; Sun, 25 Jan 2004 03:52:16 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0PBqFui042052; Sun, 25 Jan 2004 03:52:15 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Jan 2004 03:52:15 -0800 (PST) From: Matthew Dillon Message-Id: <200401251152.i0PBqFui042052@apollo.backplane.com> To: "Poul-Henning Kamp" References: <50875.1075021785@critter.freebsd.dk> cc: wmoran@potentialtech.com cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 11:52:19 -0000 :If Matt is only interested in the PC platform with sufficiently :clued users, he can afford to make the choice of timekeeping a :boot-time or even compile-time fixable just like it is in so many :other UNIX kernels. Since you can't seem to stop attributing nonsense to my name, I'll elucidate a bit. The problem with the timecounter API is that it takes a kitchen sink approach to a problem that doesn't need a kitchen sink approach to solve. You are fiddling with fractional calculations on 64 bit values in three different numerical domains and you have switching logic to switch time counters on the fly that is all entirely unnecessary. ALL YOU NEED to be able to use a stable time source to calculate phase drift against, say, an NTP time source, is a relative count value. No microseconds, nanoseconds, seconds, or fractional 2^X junk is required. You certainly don't need to be calling nanotime() or friends. You have an API to do that, the problem is that it's mixed in with everything else. You just need a count value. That value, say from a TSC, can be used as the basis for phase drift calculations from things like NTP sources and then used to compensate the master clock (e.g. say the 8254) without 'switching timecounters' or doing anything fancy. In fact, you could use *several* time sources in parallel and choose the one with the lowest drift on an ongoing basis... all without having to mess with the system's core clock functions. Even without a temperature compensation resistor a crystal oscillator is not going to drift so quickly that software can't compensate for it a few times a second given another more accurate time source. There is no reason and no need to 'integrate' that alternate time source into the core of the system. It's unnecessary, it's a waste of time, and it introduces an excessive amount of complexity. So, yes, I am ripping timecounter out of DFly... because it's ridiculous overkill. -Matt From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 03:57: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 70B4216A4D1; Sun, 25 Jan 2004 03:57:50 -0800 (PST) Received: from smtp-out3.xs4all.nl (smtp-out3.xs4all.nl [194.109.24.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2701443D4C; Sun, 25 Jan 2004 03:57:48 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-out3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0PBvggh035174; Sun, 25 Jan 2004 12:57:42 +0100 (CET) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.10/8.12.9) with ESMTP id i0PBvgvE086082; Sun, 25 Jan 2004 12:57:42 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.10/8.12.9/Submit) id i0PBvfVZ086081; Sun, 25 Jan 2004 12:57:41 +0100 (CET) (envelope-from wkb) Date: Sun, 25 Jan 2004 12:57:41 +0100 From: Wilko Bulte To: ticso@cicely.de Message-ID: <20040125115741.GA86058@freebie.xs4all.nl> References: <4011B6F6.5040306@theriver.com> <20040125115111.GN77998@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125115111.GN77998@cicely12.cicely.de> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-STABLE X-PGP: finger wilko@freebsd.org cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Same problem, new year 2100A machine check 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, 25 Jan 2004 11:57:52 -0000 On Sun, Jan 25, 2004 at 12:51:12PM +0100, Bernd Walter wrote: > On Fri, Jan 23, 2004 at 05:06:14PM -0700, Tom Ponsford wrote: > > I decided to replace a disk on the ol' 2100A. I had been running VMS on it > > without any troubles, until a disk started giving me errors. After > > replacing the disk, I decided to give 5.2 a go, thinking maybe some of the > > problems of last year may have been resolved. > > > > No such luck. ... > > unexpected machine check: > > > > mces = 0x1 > > vector = 0x670 > > param = 0xfffffc0000006000 > > pc = 0xfffffc00003b48d4 > > ra = 0xfffffc00003b4908 > > curproc = 0xfffffc0000810ee0 > > pid = 0, comm = swapper > > > > panic: machine check > > cpuid = 0; > > Uptime: 1s > > Automatic reboot in 15 seconds - press a key on the console to abort > > Maybe there is something wrong with the EISA configuration on your > machine. Hmm, could be. But 2100[a] are not really well supported/tested.. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 04:14: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 77E5F16A4CF; Sun, 25 Jan 2004 04:14:05 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id B048443D39; Sun, 25 Jan 2004 04:14:02 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i0PCDhN1092193 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 25 Jan 2004 13:13:57 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i0PCDMFq075859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2004 13:13:23 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i0PCDLPw096260; Sun, 25 Jan 2004 13:13:21 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i0PCDJFU096259; Sun, 25 Jan 2004 13:13:19 +0100 (CET) (envelope-from ticso) Date: Sun, 25 Jan 2004 13:13:18 +0100 From: Bernd Walter To: Wilko Bulte Message-ID: <20040125121318.GO77998@cicely12.cicely.de> References: <4011B6F6.5040306@theriver.com> <20040125115111.GN77998@cicely12.cicely.de> <20040125115741.GA86058@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125115741.GA86058@freebie.xs4all.nl> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-alpha@freebsd.org Subject: Re: Same problem, new year 2100A machine check X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 12:14:05 -0000 On Sun, Jan 25, 2004 at 12:57:41PM +0100, Wilko Bulte wrote: > On Sun, Jan 25, 2004 at 12:51:12PM +0100, Bernd Walter wrote: > > On Fri, Jan 23, 2004 at 05:06:14PM -0700, Tom Ponsford wrote: > > > I decided to replace a disk on the ol' 2100A. I had been running VMS on it > > > without any troubles, until a disk started giving me errors. After > > > replacing the disk, I decided to give 5.2 a go, thinking maybe some of the > > > problems of last year may have been resolved. > > > > > > No such luck. > > ... > > > > unexpected machine check: > > > > > > mces = 0x1 > > > vector = 0x670 > > > param = 0xfffffc0000006000 > > > pc = 0xfffffc00003b48d4 > > > ra = 0xfffffc00003b4908 > > > curproc = 0xfffffc0000810ee0 > > > pid = 0, comm = swapper > > > > > > panic: machine check > > > cpuid = 0; > > > Uptime: 1s > > > Automatic reboot in 15 seconds - press a key on the console to abort > > > > Maybe there is something wrong with the EISA configuration on your > > machine. > > Hmm, could be. But 2100[a] are not really well supported/tested.. It's mostly guessing, because it's probing the bridge and EISA support is a difference between 4.x, which works acording to the originator. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 05:33: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 D4F3416A4CE for ; Sun, 25 Jan 2004 05:33:03 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED06243D39 for ; Sun, 25 Jan 2004 05:33:02 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1AkkNk-0004ZG-CW for freebsd-current@freebsd.org; Sun, 25 Jan 2004 15:32:56 +0200 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Jan 2004 15:32:55 +0200 From: Danny Braniss Message-Id: Subject: machine hangs up solid. 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, 25 Jan 2004 13:33:03 -0000 im trying to compile a kernel module, via nfs: /usr/src is nfs mounted and so is /usr/obj. The server is running 4.9. it starts working, but then the machines hangs solid, nothing moves, I can get into the kernel debugger: (i've done this several times, and it's always hangs in the sames spot) ~Stopped at siointr1+0xec: jmp siointr1+0x220 db> tr siointr1(c626a800,df8acc50,c615f4c0,16,c61614c0) at siointr1+0xec siointr(c626a800,c21cfc08,df8acc74,4,c21d0690) at siointr+0x88 intr_execute_handlers(c09a04d0,df8acca4,c21cfcb4,83,4) at intr_execute_handlers+0x98 atpic_handle_intr(4) at atpic_handle_intr+0xef Xatpic_intr4() at Xatpic_intr4+0x1e --- interrupt, eip = 0xc0880665, esp = 0xdf8acce8, ebp = 0xdf8acce8 --- cpu_idle_default(df8acd14,c068b9b5,0,0,0) at cpu_idle_default+0x5 cpu_idle(0,0,0,0,c21cfc08) at cpu_idle+0x28 idle_proc(0,df8acd48,0,0,0) at idle_proc+0x25 fork_exit(c068b990,0,df8acd48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdf8acd7c, ebp = 0 --- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 07:19: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 5F52416A4CE for ; Sat, 24 Jan 2004 07:19:34 -0800 (PST) Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CAB43D48 for ; Sat, 24 Jan 2004 07:19:27 -0800 (PST) (envelope-from genew@rogers.com) Received: from GUEST ([24.43.163.180]) by fep01-mail.bloor.is.net.cable.rogers.comESMTP <20040124151647.RYAL286904.fep01-mail.bloor.is.net.cable.rogers.com@GUEST> for ; Sat, 24 Jan 2004 10:16:47 -0500 From: genew@rogers.com To: current@freebsd.org Date: Sat, 24 Jan 2004 10:19:18 -0500 MIME-Version: 1.0 Message-ID: <401246A6.8691.16F82959@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.43.163.180] using ID at Sat, 24 Jan 2004 10:16:40 -0500 X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 Subject: build failure on new 5.2 src? 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: Sat, 24 Jan 2004 15:19:34 -0000 On source cvsup'd this morning and a clean /usr/obj I get this error. sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/i386/legacy/usr/include/c++/3.3 install: /usr/obj/usr/src/i386/legacy/usr/include/c++/3.3: No such file or directory Error code 71 1 error Error code 2 1 error Error code 2 1 error Error code 2 1 error I am assuming that it is trying to use C++ which would have to have been built before it but searching /usr/obj shows it does not exist at this point in the build. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:35: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 C51AA16A4CE for ; Sat, 24 Jan 2004 09:35:37 -0800 (PST) Received: from gwoffice.united.net.ua (office-l6-gw.united.net.ua [193.111.8.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A16E43D9F for ; Sat, 24 Jan 2004 09:34:42 -0800 (PST) (envelope-from sobomax@portaone.com) Received: from portaone.com (localhost [127.0.0.1])i0OHX5uc034083; Sat, 24 Jan 2004 19:33:09 +0200 (EET) (envelope-from sobomax@portaone.com) Message-ID: <4012AC47.4020409@portaone.com> Date: Sat, 24 Jan 2004 19:32:55 +0200 From: Maxim Sobolev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, ru, uk MIME-Version: 1.0 To: Bill Moran References: <4012806B.7090102@potentialtech.com> In-Reply-To: <4012806B.7090102@potentialtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 cc: current@FreeBSD.ORG Subject: Re: DragonflyBSD kernel clock 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: Sat, 24 Jan 2004 17:35:37 -0000 Bill Moran wrote: > Hello all, > > I saw this recently: > http://www.dragonflybsd.org/Docs/nanosleep/ > > I was wondering if anyone on the FreeBSD team has looked at this. It > doesn't > appear as if any recent change have been made in the FreeBSD tree regarding > this. > > It's probably not a big deal, but I just thought I'd point it out. I've ported PLL part (sys/i386/isa/clock.c change) and now I'm testing it. I'll post the patch to this list once I will have finished. Right now it works like a charm, but I need to get rid of the constant skew introduced in tvtohz(). -Maxim From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16: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 2245A16A4CE; Sat, 24 Jan 2004 16:45:23 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6657443D31; Sat, 24 Jan 2004 16:45:21 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) i0P0jKv9011074; Sat, 24 Jan 2004 19:45:20 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id i0P0jKlE011073; Sat, 24 Jan 2004 19:45:20 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Sat, 24 Jan 2004 19:45:20 -0500 (EST) Message-Id: <200401250045.i0P0jKlE011073@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 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: Sun, 25 Jan 2004 00:45:23 -0000 TB --- 2004-01-24 23:36:50 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2004-01-24 23:36:50 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-01-24 23:36:50 - cvsupping the source tree TB --- /home/des/bin/cvsup -1 -g -L 2 /home/des/tinderbox/CURRENT/sparc64/sparc64/supfile TB --- 2004-01-24 23:44:52 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /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-01-25 00:40:15 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 25 00:40:15 GMT 2004 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mcmodel=medlow -msoft-float -ffreestanding -Werror vers.c linking kernel.debug exception.o: In function `tl0_intr': /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/exception.S:753: undefined reference to `panic' exception.o: In function `tl1_intr': /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/exception.S:1887: undefined reference to `panic' support.o: In function `longjmp': /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/support.S:735: undefined reference to `panic' *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-01-25 00:45:20 - TB --- /usr/bin/make returned exit code 1 TB --- 2004-01-25 00:45:20 - TB --- ERROR: failed to build generic kernel TB --- 2004-01-25 00:45:20 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:05:40 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 A351D16A4CE for ; Sat, 24 Jan 2004 19:05:40 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ECD243D1D for ; Sat, 24 Jan 2004 19:05:39 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id i0P35dw85888 for ; Sat, 24 Jan 2004 22:05:39 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 24 Jan 2004 22:05:38 -0500 (EST) From: Jeff Roberson To: current@freebsd.org Message-ID: <20040124220307.N36463-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 Subject: HEADS UP: ULE is the default scheduler now 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, 25 Jan 2004 03:05:40 -0000 ULE has entered into its probationary period as the default scheduler. This is intended to give it wider exposure to work out the last few kinks. If all goes well it will remain the default through the rest of the 5.x series. If you aren't running it now, please switch over. I have been out of town or very busy over the last few months. I should be more available to address things as they come up now. If anyone is aware of any current issues, please contact me with any details you may have. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:12: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 846F816A4CE for ; Sat, 24 Jan 2004 19:12:42 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DB6843D2D for ; Sat, 24 Jan 2004 19:12:41 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id i0P3Cem88843 for ; Sat, 24 Jan 2004 22:12:40 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 24 Jan 2004 22:12:40 -0500 (EST) From: Jeff Roberson To: current@freebsd.org In-Reply-To: <20040124220307.N36463-100000@mail.chesapeake.net> Message-ID: <20040124220826.P36463-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 Subject: Re: HEADS UP: ULE is the default scheduler now 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, 25 Jan 2004 03:12:42 -0000 On Sat, 24 Jan 2004, Jeff Roberson wrote: > ULE has entered into its probationary period as the default scheduler. > This is intended to give it wider exposure to work out the last few kinks. > If all goes well it will remain the default through the rest of the 5.x > series. If you aren't running it now, please switch over. > > I have been out of town or very busy over the last few months. I should > be more available to address things as they come up now. If anyone is > aware of any current issues, please contact me with any details you may > have. I was asked to follow up with a summary of why you might want to use ULE. For the average user, interactivity is reported to be better in many cases. This means less skipping, jerking, etc. in interactive applications while the machine is very busy. This will not prevent problems due to overload disk subsystems, but it does help with overloaded CPUs. On SMP machines ULE has per cpu run queues which allow for CPU affinity, CPU binding, advanced HyperThreading support, as well as providing a framework for more optimizations in the future. This means that as our kernel is locked better the scheduler will be able to make more efficient use of the available parallel resources. ULE has been stable for some time. The only problems that are likely to remain are corner cases where interactivity is not as good or where performance is not as good as with the old scheduler. Cheers, Jeff > > Thanks, > Jeff > > From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:34:40 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 4C75716A4CE for ; Sat, 24 Jan 2004 19:34:40 -0800 (PST) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id E680443D46 for ; Sat, 24 Jan 2004 19:34:36 -0800 (PST) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (mi@localhost [127.0.0.1]) by aldan.algebra.com (8.12.10/8.12.10) with ESMTP id i0P3YXtu028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 24 Jan 2004 22:34:34 -0500 (EST) (envelope-from mi@aldan.algebra.com) Received: (from mi@localhost) by aldan.algebra.com (8.12.10/8.12.10/Submit) id i0P3YWJX028845 for current@FreeBSD.org; Sat, 24 Jan 2004 22:34:32 -0500 (EST) (envelope-from mi) Date: Sat, 24 Jan 2004 22:34:32 -0500 (EST) From: Mikhail Teterin Message-Id: <200401250334.i0P3YWJX028845@aldan.algebra.com> To: current@FreeBSD.org X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 03:34:40 -0000 Hello! With the correct DHCP setup, etc. I managed to get it to download pxeboot over tftp. pxeboot mounts the root filesystem over NFS properly and loads the kernel. However, when it tries to boot the said kernel, the whole box freezes up (before even displaying the kernel info or FreeBSD Copyright). My only guess is, I'm screwing up the kernel config (below)... Did anyone else succeed in booting a reasonably fresh -current on a ThinkNIC? Thanks! -mi # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394 2003/12/03 21:13:06 jhb Exp $ machine i386 cpu I486_CPU # Which one for Cyrix MII? cpu I586_CPU cpu I686_CPU ident NIC #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler options INET #InterNETworking #options INET6 #IPv6 communications protocols #options FFS #Berkeley Fast Filesystem #options SOFTUPDATES #Enable FFS soft updates support #options UFS_ACL #Support for access control lists #options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client #options NFSSERVER #Network Filesystem Server options NFS_ROOT #NFS usable as /, requires NFSCLIENT #options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 #options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. # Debugging for use in -current options DDB #Enable the kernel debugger #options INVARIANTS #Enable calls of extra sanity checking #options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC device isa #device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata #device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion ##device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters # #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x and SK-982x gigabit ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard nics included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of ethernet chips #device xe # Xircom pccard ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device wlan # 802.11 support #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device axe # ASIX Electronics USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) device pcm #options CPU_WT_ALLOC From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:59: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 2F2C616A4CE; Sat, 24 Jan 2004 19:59:34 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B5A243D60; Sat, 24 Jan 2004 19:59:03 -0800 (PST) (envelope-from dark@perfora.net) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AkbQM-0000mL-00; Sat, 24 Jan 2004 22:59:02 -0500 Received: from [24.169.60.91] (helo=mxus.perfora.net) by smtp.perfora.net with asmtp (Exim 3.35 #1) id 1AkbQM-0005el-00; Sat, 24 Jan 2004 22:59:02 -0500 Received: by mxus.perfora.net (Postfix, from userid 1001) id 74A3B5EDD; Sat, 24 Jan 2004 22:58:58 -0500 (EST) Date: Sat, 24 Jan 2004 22:58:58 -0500 From: Dev Tugnait To: Bill Paul Message-ID: <20040125035858.GB82300@daemon.unixdaemon.org> References: <20040125034900.1570F16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125034900.1570F16A4CF@hub.freebsd.org> X-Editor: Vim http://www.vim.org/ X-Info: http://unixdaemon.org X-Operating-System: Unix/5.2-RELEASE (i386) X-Uptime: 10:58PM up 1 day, 9:26, 16 users, load averages: 0.05, 0.18, 0.20 User-Agent: Mutt/1.5.5.1i X-Mailman-Approved-At: Sun, 25 Jan 2004 05:47:34 -0800 cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Project Evil: The Evil Continues 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, 25 Jan 2004 03:59:34 -0000 What in the world is Project Evil? * Bill Paul (wpaul@FreeBSD.ORG) wrote: > > Previously, I had asked for help getting the Intel Centrino wireless > cards to work with Project Evil, and thanks to various wonderful people, > a couple of Centrino cards and a miniPCI-to-PCI adapter turned up on > Project Evil Labs' doorstep. The Centrino NDIS driver now works > correctly. (The problem turned out to be that I wasn't initializing > some special flags in ndis_packet structures). > > Now I'm trying to get a handle on getting support done for all > the remaining unsupported 802.11 chipsets out there. There are a > couple that I know don't work, and a few which might work, but I > don't know for sure since I don't have them. > > Right now, it looks like all of the Broadcom-based cards should be > supported, as well as the Centrino cards. There are various ethernet > cards that I've tested which work as well. I am looking for success > or failure reports concerning the following devices: > > - nVidia MCP ethernet, integrated into the nVidia nForce2 chipset. > This driver should work using the nvenet.sys driver for Windows > which is available from nVidia's web site. Note: recent versions > of the driver consist of just two files: the nvenet.sys binary > module, and its accompanying .inf file. However some of the older > driver distributions included a couple of additional firmware/microcode > files that nvenet.sys would try to load at runtime. If you have one > of these older drivers, put the firmware/microcode files in > /compat/ndis, and the driver should load them correctly. > > - RealTek RTL8180 wireless LAN chipset. I have been unable to find > a card with this chip in any of my local computer stores. The > RealTek driver for this chip _should_ work. I'm pretty sure all > of the routines it calls are implemented. > > - ADMtek 8211 wireless LAN chipset. This one should also work, but I > can't find any cards with this chipset in my local computer stores. > > - Intel PRO/5000 wirless card. This is apparently an Atheros 5210 > chipset. I have been told the wl50nd5.sys driver for this card > crashes when you call its reset method, but again I don't have one of > these so I can't confirm this or figure out what the problem is. > > - AMD Am1771/Am1772 wireless LAN chipset. This one probably won't > work: the supplied AMD driver calls lots of functions in ntoskrnl.exe > which I haven't implemented yet. This chipset is present on the > SMC 2602w version 3 card. I repeat: that's the SMC 2602w VERSION THREE. > The version 1 card is a Prism chipset. I don't know what the v2 card is. > > - Texas Instruments ax100 chipset. I'm not sure if this one works or > not. This chipset has been reverse-engineered and there is a native > FreeBSD driver available, but I'm still curious to see if it works > with the NDISulator. > > - Atheros chipsets. Of course, we have the ath(4) driver to support > these, but it would be nice to know which ones work (or do not work) > with the NDISulator. > > - Any other PCI or cardbus NIC that I've overlooked which isn't currently > supported by an existing native driver. > > If you have a system with one of these chipsets, please give the > NDISulator a try. Note: you do NOT have to recompile your kernel to > test it. Find the .sys and .inf files from your Windows driver media > and do the following: > > # cp foo.sys foo.inf /sys/modules/if_ndis > # cd /sys/modules/ndis > # make; make load > # cd /sys/modules/if_ndis > # ndiscvt -i foo.inf -s foo.sys -o ndis_driver_data.h > # make; make load > > You don't even have to reboot. Well, not unless the driver causes > a panic. :/ > > If the NIC works, that's great! Drop me a line letting me know, so I > can cross it off the list. If it doesn't work, please do the > following: > > - Describe the failure to me _in_ _detail_. DON'T LOAD THE DRIVER > WITH X RUNNING. (I hate it when people do that. If for some reason > there's a panic, you'll never see it unless you're watching the > console. If X is running, it will just look like the system froze, > and you won't be able to tell what happened.) If you see messages > of the form "No match for " on the > console, then the driver is trying to call some functions that I > haven't implemented yet. In very rare cases, the driver may still > work, but don't bet on it. Make a note of all console messages that > appear when you try to load the driver module. And send them to me, > along with a description of what card you have and whar Windows driver > module you used. > > - Tell me where you got your card so I can try to get one too. As with > the Centrino, it's not always possible to debug these problems without > actual hardware. > > - If you're feeling really generous, loan me your card for a while so > I can coerce^Wcoax it into working. (This doesn't apply to NICs > that are integrated into your system.) > > Again, we at Project Evil appreciate your assistance in our efforts > to dominate^Wimprove the world. If you decide to loan us your hardware, > please send it do: > > Attn: Bill Paul > Wind River Systems > 500 Wind River Way > Alameda, CA. 94102 > USA > > Project Evil: when it absolutely, positively has to be evil overnight. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > 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" ---++--- ---------GnuPGPVer 1.2.3-------------------------------------------------- pub 1024D/B9046473 2003-11-21 Dev Tugnait (Freebsd) Key fingerprint = F690 6725 1930 6FBE C05A FE4D 6CB1 34C1 B904 6473 sub 1024g/F8F019DF 2003-11-21 -------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 06:18: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 7613916A4CE for ; Sun, 25 Jan 2004 06:18:09 -0800 (PST) Received: from cmailm5.svr.pol.co.uk (cmailm5.svr.pol.co.uk [195.92.193.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 035CB43D3F for ; Sun, 25 Jan 2004 06:18:08 -0800 (PST) (envelope-from mtm98@mcgoldrick.org) Received: from modem-2719.javan.dialup.pol.co.uk ([81.78.170.159] helo=mcgoldrick.org) by cmailm5.svr.pol.co.uk with esmtp (Exim 4.14) id 1Akl4v-0000Rs-F2 for current@freebsd.org; Sun, 25 Jan 2004 14:17:34 +0000 Received: by mcgoldrick.org (Postfix, from userid 1000) id 62CA8512D; Sun, 25 Jan 2004 14:18:03 +0000 (GMT) Date: Sun, 25 Jan 2004 14:18:03 +0000 From: Michael McGoldrick To: current@freebsd.org Message-ID: <20040125141802.GA879@uriel.mcgoldrick.org> References: <20040124133246.GA862@uriel.mcgoldrick.org> <20040124190618.GN64193@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040124190618.GN64193@cnd.mcgill.ca> User-Agent: Mutt/1.4.1i Subject: Re: Fatal trap 12 pcm / devfs related? 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, 25 Jan 2004 14:18:09 -0000 This patch seems to work perfectly. Thanks! On Sat, Jan 24, 2004 at 02:06:18PM -0500, Mathew Kanner wrote: > On Jan 24, Michael McGoldrick wrote: > > (kgdb) l *0xc051be9a > > 0xc051be9a is in dsp_clone (/usr/src/sys/dev/sound/pcm/dsp.c:1096). > > 1091 if (unit == -1 || unit >= devclass_get_maxunit(pcm_devclass)) > > 1092 return; > > 1093 > > 1094 pcm_dev = devclass_get_softc(pcm_devclass, unit); > > 1095 > > 1096 SLIST_FOREACH(pcm_chan, &pcm_dev->channels, link) { > > 1097 > > 1098 switch(devtype) { > > 1099 case SND_DEV_DSP: > > 1100 pdev = pcm_chan->dsp_devt; > > (kgdb) > > Hello Michael, > I'm not exactly sure why this is happening and I'm not really > in a place to do debugging, but could you try sticking a > > if (pcm_dev == NULL) > return; > > at line 1095 and try again. > > Thanks, > --Mat > > -- > sig machine broken -- Michael McGoldrick: michael@mcgoldrick.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 06:38: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 E3C3416A4CE; Sun, 25 Jan 2004 06:38:45 -0800 (PST) Received: from server019.webpack.hosteurope.de (server019.webpack.hosteurope.de [80.237.130.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB05043D1F; Sun, 25 Jan 2004 06:38:43 -0800 (PST) (envelope-from bfischer@Techfak.Uni-Bielefeld.DE) Received: from no-support.loc (p5082BAD4.dip.t-dialin.net [80.130.186.212]) (authenticated bits=0)i0PEcemC008118; Sun, 25 Jan 2004 15:38:41 +0100 Received: from frolic.no-support.loc (localhost.no-support.loc [127.0.0.1]) by no-support.loc (8.12.9/8.12.9) with ESMTP id i0PEd8fh000515; Sun, 25 Jan 2004 15:39:08 +0100 (CET) (envelope-from bjoern@frolic.no-support.loc) Received: (from bjoern@localhost) by frolic.no-support.loc (8.12.9/8.12.9/Submit) id i0PEd7te000514; Sun, 25 Jan 2004 15:39:07 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Sun, 25 Jan 2004 15:39:07 +0100 To: Stephan Uphoff Message-ID: <20040125143907.GA460@frolic.no-support.loc> References: <200312211039.FAA21799@stups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312211039.FAA21799@stups.com> User-Agent: Mutt/1.4.1i cc: Robert Watson cc: current@freebsd.org Subject: Re: getblk(): panic: lockmgr: locking against myself 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, 25 Jan 2004 14:38:46 -0000 Hello, > This looks like a ufs2 snapshot bug when initializing more > inodes in a cylinder group. > bawrite for newly initialized inode block is called while the thread > still owns the cylinder group block. > The snapshot copy-on-write code tries to save the old (uninitialized) > block and might need the cg block to do so => panic. > > Not saving the uninitialized inode block does not look like an > option as inode access functions do not check the cg for cg_initediblk. > > The ugly patch below calls the bawrite for the inode block after > it releases (bdwrites) the cg block and should prevent the panic. is this issue resolved already? I just got a panic with latest -CURRENT that looks exactly the same. The machine paniced while performing background fsck on a very busy file system. If I can reproduce the panic I will try your patch. Bjoern -- -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ ------END GEEK CODE BLOCK------ From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 06:39: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 F1C5E16A4CE for ; Sun, 25 Jan 2004 06:39:08 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7291B43D39 for ; Sun, 25 Jan 2004 06:39:07 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0PEcruO052722; Sun, 25 Jan 2004 15:38:53 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Matthew Dillon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jan 2004 03:52:15 PST." <200401251152.i0PBqFui042052@apollo.backplane.com> Date: Sun, 25 Jan 2004 15:38:53 +0100 Message-ID: <52721.1075041533@critter.freebsd.dk> cc: wmoran@potentialtech.com cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 14:39:09 -0000 In message <200401251152.i0PBqFui042052@apollo.backplane.com>, Matthew Dillon w rites: >:If Matt is only interested in the PC platform with sufficiently >:clued users, he can afford to make the choice of timekeeping a >:boot-time or even compile-time fixable just like it is in so many >:other UNIX kernels. > > Since you can't seem to stop attributing nonsense to my name, I'll > elucidate a bit. Matt, whatever... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 06:46: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 9699A16A4D1 for ; Sun, 25 Jan 2004 06:46:48 -0800 (PST) Received: from mailhub1.midco.net (mailhub1.midco.net [24.220.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB1043D5E for ; Sun, 25 Jan 2004 06:46:41 -0800 (PST) (envelope-from pmes@bis.midco.net) Received: (qmail 3315 invoked by uid 0); 25 Jan 2004 14:46:41 -0000 Received: from host-195-219-220-24.midco.net (HELO bis.midco.net) ([24.220.219.195]) (envelope-sender ) by lvs-pop.midco.net (qmail-ldap-1.03) with SMTP for ; 25 Jan 2004 14:46:41 -0000 Message-ID: <4013D6D0.5010406@bis.midco.net> Date: Sun, 25 Jan 2004 08:46:40 -0600 From: Peter Schultz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031215 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johny Mattsson References: <44827.1074974041@critter.freebsd.dk> <200401242031.i0OKVD8A037265@apollo.backplane.com> <40130F5A.1060709@earthmagic.org> In-Reply-To: <40130F5A.1060709@earthmagic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 14:46:48 -0000 Johny Mattsson wrote: > let's not pick > on each other unnecessarily. Let's just work towards making each of the > BSDs the best it can be. :) > This is just part of the "sport of hacking" for them. Remember, these guys are the pros, and their going back and forth is a natural part of the competition for world domination. It basically amounts to this: I am the world's greatest BSD hacker, here is the idea I have. If you think that's true, prove it you lazy SOB! Pete... From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 06:59: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 292A316A4CE for ; Sun, 25 Jan 2004 06:59:24 -0800 (PST) Received: from tx0.oucs.ox.ac.uk (tx0.oucs.ox.ac.uk [129.67.1.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B031743D8F for ; Sun, 25 Jan 2004 06:58:43 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan0.oucs.ox.ac.uk ([129.67.1.162] helo=localhost) by tx0.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1Aklik-0000KO-Fi for current@freebsd.org; Sun, 25 Jan 2004 14:58:42 +0000 Received: from rx0.oucs.ox.ac.uk ([129.67.1.161]) by localhost (scan0.oucs.ox.ac.uk [129.67.1.162]) (amavisd-new, port 25) with ESMTP id 01170-02 for ; Sun, 25 Jan 2004 14:58:42 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx0.oucs.ox.ac.uk with smtp (Exim 4.24) id 1Aklik-0000KF-2G for current@freebsd.org; Sun, 25 Jan 2004 14:58:42 +0000 Received: (qmail 7495 invoked by uid 0); 25 Jan 2004 14:58:42 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.406247 secs); 25 Jan 2004 14:58:42 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.406247 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 25 Jan 2004 14:58:41 -0000 Message-Id: <6.0.1.1.1.20040125144442.044a3228@imap.sfu.ca> X-Sender: cperciva@imap.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 25 Jan 2004 14:58:30 +0000 To: Matthew Dillon From: Colin Percival In-Reply-To: <200401251152.i0PBqFui042052@apollo.backplane.com> References: <50875.1075021785@critter.freebsd.dk> <200401251152.i0PBqFui042052@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 14:59:24 -0000 At 11:52 25/01/2004, Matthew Dillon wrote: > So, yes, I am ripping timecounter out of DFly... because it's ridiculous > overkill. There are lots of things in FreeBSD which will seem like overkill to some people. Most people don't need the complexity of the timecounter system; most people don't need the generality of GEOM classes; most people don't need to be able to update to any point on any CVS branch; many people don't need fine-grained locking... you get the picture. The only problem is that "overkill" depends upon your point of view. Matt has decided that, for what he wants DFly to be, the timecounter system is overkill; phk decided that for FreeBSD, it isn't overkill. There is no contradiction here, merely different goals. Colin Percival From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 07:18:06 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 5D3BE16A4CF for ; Sun, 25 Jan 2004 07:18:06 -0800 (PST) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F3B143D49 for ; Sun, 25 Jan 2004 07:18:04 -0800 (PST) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 8BE6BFEC1; Sun, 25 Jan 2004 16:18:02 +0100 (CET) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) i0PFIOYn080281 for ; Sun, 25 Jan 2004 16:18:24 +0100 (CET) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.12.10/8.12.10/Submit) id i0PFIOSm080280 for current@freebsd.org; Sun, 25 Jan 2004 16:18:24 +0100 (CET) (envelope-from schweikh) Date: Sun, 25 Jan 2004 16:18:24 +0100 From: Jens Schweikhardt To: current@freebsd.org Message-ID: <20040125151824.GA79958@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i Subject: make(1) and SUBDIR assignments 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, 25 Jan 2004 15:18:06 -0000 hello, world\n I'm trying to selectively install binaries in the source tree, i.e. to only install bin/dd and bin/df this is what I hoped would work: root@hal9000:/usr/src # make buildworld # succeeds root@hal9000:/usr/src # cd bin root@hal9000:/usr/src/bin # make install SUBDIR='dd df' But it fails: ===> dd "/usr/share/mk/bsd.subdir.mk", line 60: Inconsistent operator for dd "/usr/share/mk/bsd.subdir.mk", line 66: warning: duplicate script for target "dd" ignored make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /share/HEAD/src/bin. (-CURRENT sources and /usr/share/mk/* as of today). Is this 1) a bug somewhere (though nothings seems to be wrong with bsd.subdir.mk) 2) me being confused about how SUBDIR is intended to be used 3) something else Yes, I know I can workaround by cd /usr/src/bin/dd; make install cd /usr/src/bin/df; make install But why do all the src/*/Makefiles assign the list of subdirs to SUBDIR and DTRT, but I can't from the outside? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 07:58: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 7297616A4D8 for ; Sun, 25 Jan 2004 07:58:58 -0800 (PST) Received: from mail.gactr.uga.edu (mail.gactr.uga.edu [128.192.37.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A09B43D49 for ; Sun, 25 Jan 2004 07:58:57 -0800 (PST) (envelope-from robin.blanchard@gactr.uga.edu) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id B1E1C7727A for ; Sun, 25 Jan 2004 10:58:56 -0500 (EST) Received: from EBE1.gc.nat (E2K1.gc.nat [10.10.11.21]) by mail.gactr.uga.edu (Postfix) with ESMTP id 5F6D9771D8 for ; Sun, 25 Jan 2004 10:58:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 25 Jan 2004 10:58:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strange behaviour Thread-Index: AcPhGJzsVZ6cc4QDQrKmb8yUL7LbpQBf4/+RADB4jyA= From: "Robin P. Blanchard" To: "Robin P. Blanchard" , "Ken Smith" cc: Ken Smith cc: current@freebsd.org cc: Kris Kennaway Subject: RE: Strange behaviour (processes "hung" in getblk state) 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, 25 Jan 2004 15:58:59 -0000 b2suLi4NCkkgbGV0IHRoZSBtYWNoaW5lIHN0YXkgImFzIGlzIiBzaW5jZSBwb3N0aW5nIHllc3Rl cmRheS4gQWxtb3N0IDI0IGhvdXJzDQpsYXRlciwgbm90aGluZyBhcHBlYXJzIHRvIGhhdmUgY2hh bmdlZC4gQW55IGlkZWFzID8NCiANCiA0NDk0ICBwMCAgUysgICAgIDA6MDAuMDIgbWFrZSBpbnN0 YWxsd29ybGQNCiA0NDk5ICBwMCAgUysgICAgIDA6MDAuMDEgL2Jpbi9zaCAtZWMgY2QgL3Vzci9z cmM7DQpQQVRIPS9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluIGBpZiBbIC14IC91c3Ivb2Jq L3Vzci9zcmMvbWFrZS5pMzg2L21ha2UNCl07IHRoZW4gZWMNCiA0NTAxICBwMCAgUysgICAgIDA6 MDAuMDQgbWFrZSAtbSAvdXNyL3NyYy9zaGFyZS9tayAtZiBNYWtlZmlsZS5pbmMxDQppbnN0YWxs d29ybGQNCiA0NTY4ICBwMCAgUysgICAgIDA6MDAuMDEgIChzaCkNCiA0NTY5ICBwMCAgUysgICAg IDA6MDAuMDMgbWFrZSAtZiBNYWtlZmlsZS5pbmMxIHJlaW5zdGFsbA0KIDQ2MTkgIHAwICBTKyAg ICAgMDowMC4wMSAvYmluL3NoIC1lYyBjZCAvdXNyL3NyYzsgbWFrZSAtZiBNYWtlZmlsZS5pbmMx DQppbnN0YWxsDQogNDYyMCAgcDAgIFMrICAgICAwOjAwLjAzIG1ha2UgLWYgTWFrZWZpbGUuaW5j MSBpbnN0YWxsDQogNDYyNyAgcDAgIFMrICAgICAwOjAwLjA2ICAoc2gpDQoyMDk3NyAgcDAgIFMr ICAgICAwOjAwLjAyIG1ha2UgaW5zdGFsbCBESVJQUkZYPWV0Yy8NCjIwOTgyICBwMCAgUysgICAg IDA6MDAuMDEgL2Jpbi9zaCAtZWMgY2QgL3Vzci9zcmMvZXRjLy4uL3NoYXJlL21hbjsgbWFrZQ0K bWFrZWRiDQoyMDk4MyAgcDAgIFMrICAgICAwOjAwLjAxIG1ha2UgbWFrZWRiDQoyMDk4NCAgcDAg IEQrICAgICAwOjAyLjg1IG1ha2V3aGF0aXMgL3Vzci9zaGFyZS9tYW4NCjIwOTg1ICBwMSAgU3Mg ICAgIDA6MDAuMzEgLWJhc2ggKGJhc2gpDQogDQpkYj4gdHIgMjA5ODINCnNjaGVkX3N3aXRjaChj NjJlOWE4MCwyLGMwNjdjYjJhLDFkNCw5ZTkwODkwYikgYXQgc2NoZWRfc3dpdGNoKzB4MTU1DQpt aV9zd2l0Y2goYzYyZTlhODAsNWMsYzA2N2NiMmEsZWUsMSkgYXQgbWlfc3dpdGNoKzB4MjQ4DQpt c2xlZXAoYzYyZmFkYzAsYzYyZmFlMmMsMTVjLGMwNjdjNDk2LDApIGF0IG1zbGVlcCsweDRmZg0K d2FpdDEoYzYyZTlhODAsZWJlN2FkMTQsMCxlYmU3YWQ0MCxjMDYzNjQxMCkgYXQgd2FpdDErMHg5 YTANCndhaXQ0KGM2MmU5YTgwLGViZTdhZDE0LGMwNjkyMzdhLDNlZSw0KSBhdCB3YWl0NCsweDIw DQpzeXNjYWxsKDJmLDJmLDJmLGJmYmZlOTA0LDExOGUpIGF0IHN5c2NhbGwrMHgyYzANClhpbnQw eDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWQNCi0tLSBzeXNjYWxsICg3LCBG cmVlQlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4MjgxMzYwZGYsIGVzcCA9IDB4YmZiZmU4NGMs DQplYnAgPQ0KIDB4YmZiZmU4NjggLS0tDQpkYj4gdHIgMjA5ODMNCnNjaGVkX3N3aXRjaChjNmI0 ZTE1MCwyLGMwNjdjYjJhLDFkNCxlNzQ1ODM1ZCkgYXQgc2NoZWRfc3dpdGNoKzB4MTU1DQptaV9z d2l0Y2goYzZiNGUxNTAsNWMsYzA2N2NiMmEsZWUsMSkgYXQgbWlfc3dpdGNoKzB4MjQ4DQptc2xl ZXAoYzZiNGRhNTAsYzZiNGRhYmMsMTVjLGMwNjdjNDk2LDApIGF0IG1zbGVlcCsweDRmZg0Kd2Fp dDEoYzZiNGUxNTAsZWJmOWNkMTQsMCxlYmY5Y2Q0MCxjMDYzNjQxMCkgYXQgd2FpdDErMHg5YTAN CndhaXQ0KGM2YjRlMTUwLGViZjljZDE0LGMwNjkyMzdhLDNlZSw0KSBhdCB3YWl0NCsweDIwDQpz eXNjYWxsKDJmLDJmLDJmLGJmYmZkZDI0LDUxZjgpIGF0IHN5c2NhbGwrMHgyYzANClhpbnQweDgw X3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWQNCi0tLSBzeXNjYWxsICg3LCBGcmVl QlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4ODA2NDQyMywgZXNwID0gMHhiZmJmZGNjYywgZWJw DQo9DQoweGJmYmZkY2U4IC0tLQ0KZGI+IHRyIDIwOTg0DQpzY2hlZF9zd2l0Y2goYzVmZjEwMDAs MixjMDY3Y2IyYSwxZDQsNGE0NjMzMjEpIGF0IHNjaGVkX3N3aXRjaCsweDE1NQ0KbWlfc3dpdGNo KGM1ZmYxMDAwLDUwLGMwNjdjYjJhLGNhLDEpIGF0IG1pX3N3aXRjaCsweDI0OA0KbXNsZWVwKGQy NmU5MjQ0LGMwNmNjNjg4LDUwLGMwNjgyZTIwLDApIGF0IG1zbGVlcCsweDRmZg0KYWNxdWlyZShl OWI5N2EzYywyMDAwMDIwLDYwMCxlNyxjMDY4MmFhNykgYXQgYWNxdWlyZSsweGFlDQpsb2NrbWdy KGQyNmU5MjQ0LDIwOTAwMjIsYzY5NTVlMzgsYzVmZjEwMDAsYzA2ZDg5ZTgpIGF0IGxvY2ttZ3Ir MHg0NTcNCmdldGJsayhjNjk1NWUzOCwwLDAsODAwLDApIGF0IGdldGJsaysweDE4Zg0KYnJlYWRu KGM2OTU1ZTM4LDAsMCw4MDAsMCkgYXQgYnJlYWRuKzB4NTINCmJyZWFkKGM2OTU1ZTM4LDAsMCw4 MDAsMCkgYXQgYnJlYWQrMHg0Yw0KZmZzX3JlYWQoZTliOTdiZTQsYzA2ODRhNmIsYzVmZjEwMDAs MWZmLGMwNmQ4NmYwKSBhdCBmZnNfcmVhZCsweDNmZg0Kdm5fcmVhZChjNjJmN2I2YyxlOWI5N2M4 MCxjNjI5MjE4MCwwLGM1ZmYxMDAwKSBhdCB2bl9yZWFkKzB4MWY1DQpkb2ZpbGVyZWFkKGM1ZmYx MDAwLGM2MmY3YjZjLDQsODBlZTAwMCw0MDAwKSBhdCBkb2ZpbGVyZWFkKzB4ZGMNCnJlYWQoYzVm ZjEwMDAsZTliOTdkMTQsYzA2OTIzN2EsM2VlLDMpIGF0IHJlYWQrMHg2Yg0Kc3lzY2FsbCg4MDYw MDJmLDJmLGJmYmYwMDJmLDgwNmMxNTgsNDAwMCkgYXQgc3lzY2FsbCsweDJjMA0KWGludDB4ODBf c3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgxZA0KLS0tIHN5c2NhbGwgKDMsIEZyZWVC U0QgRUxGMzIsIHJlYWQpLCBlaXAgPSAweDgwNjFhNGYsIGVzcCA9IDB4YmZiZmQzYWMsIGVicA0K PSAwDQp4YmZiZmQzYzggLS0tDQpkYj4gdHIgMjA5ODUNCnNjaGVkX3N3aXRjaChjNWQ4MTY5MCwy LGMwNjdjYjJhLDFkNCwzZjFjNjlkMykgYXQgc2NoZWRfc3dpdGNoKzB4MTU1DQptaV9zd2l0Y2go YzVkODE2OTAsNTksYzA2N2NiMmEsZWUsMSkgYXQgbWlfc3dpdGNoKzB4MjQ4DQptc2xlZXAoYzYw NDllNDAsMCwxNTksYzA2ODE1M2QsMCkgYXQgbXNsZWVwKzB4NGZmDQp0dHlzbGVlcChjNjA0OWUz MCxjNjA0OWU0MCwxNTksYzA2ODE1M2QsMCkgYXQgdHR5c2xlZXArMHgzZA0KdHRyZWFkKGM2MDQ5 ZTMwLGUxNDU0YzgwLDdmMDAwMCw2LGM2MWViNjE4KSBhdCB0dHJlYWQrMHg0ODMNCnB0c3JlYWQo YzZmOTFjMDAsZTE0NTRjODAsN2YwMDAwLGMwNTczOWU4LGMwNmFjYTIwKSBhdCBwdHNyZWFkKzB4 MzBkDQpzcGVjX3JlYWQoZTE0NTRiZTQsZTE0NTRjMzAsYzA1N2U0YzUsZTE0NTRiZTQsYzA2ODRh NmIpIGF0IHNwZWNfcmVhZCsweDFlMw0Kc3BlY192bm9wZXJhdGUoZTE0NTRiZTQsYzA2ODRhNmIs YzVkODE2OTAsMWZmLGMwNmQ4NmYwKSBhdA0Kc3BlY192bm9wZXJhdGUrMHgxOA0Kdm5fcmVhZChj NjJmNzYxYyxlMTQ1NGM4MCxjNmU5OTU4MCwwLGM1ZDgxNjkwKSBhdCB2bl9yZWFkKzB4MWY1DQpk b2ZpbGVyZWFkKGM1ZDgxNjkwLGM2MmY3NjFjLDAsYmZiZmUzNmYsMSkgYXQgZG9maWxlcmVhZCsw eGRjDQpyZWFkKGM1ZDgxNjkwLGUxNDU0ZDE0LGMwNjkyMzdhLDNlZSwzKSBhdCByZWFkKzB4NmIN CnN5c2NhbGwoYmZiZjAwMmYsODBiMDAyZixiZmJmMDAyZixiZmJmZWIyMCwyODIyNWYwMCkgYXQg c3lzY2FsbCsweDJjMA0KWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgx ZA0KLS0tIHN5c2NhbGwgKDMsIEZyZWVCU0QgRUxGMzIsIHJlYWQpLCBlaXAgPSAweDI4MWFhMTVm LCBlc3AgPSAweGJmYmZlMzVjLCBlYnANCj0NCjB4YmZiZmUzNzggLS0tDQogDQogDQoNCgktLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBSb2JpbiBQLiBCbGFuY2hhcmQgDQoJU2Vu dDogU2F0IDEvMjQvMjAwNCAxMTo0MSBBTSANCglUbzogS2VuIFNtaXRoIA0KCUNjOiBLZW4gU21p dGg7IEtyaXMgS2VubmF3YXk7IGN1cnJlbnRAZnJlZWJzZC5vcmcgDQoJU3ViamVjdDogUkU6IFN0 cmFuZ2UgYmVoYXZpb3VyIChwcm9jZXNzZXMgImh1bmciIGluIGdldGJsayBzdGF0ZSkNCgkNCgkN Cg0KCSMgdG9wIHxmZ3JlcCBtYWtld2hhdGlzDQoJMjA5ODQgcm9vdCAgICAgIC00ICAgIDAgICA4 MTJLICAgNzE2SyBnZXRibGsgMSAgIDA6MDMgIDAuMDAlICAwLjAwJQ0KbWFrZXdoYXRpcw0KDQoJ IyBzeXNjdGwgZGVidWcuZW50ZXJfZGVidWdnZXI9ZGRiDQoJZGVidWcuZW50ZXJfZGVidURnZ2Vy OiBlYnVnZ2VyKCJkZWJ1Zy5lbnRlcl9kZWJ1Z2dlciIpDQoJU3RvcHBlZCBhdCAgICAgIERlYnVn Z2VyKzB4NTU6ICB4Y2hnbCAgICVlYngsaW5fRGVidWdnZXIuMA0KCWRiPiB0ciAyMDk4NA0KCXNj aGVkX3N3aXRjaChjNWZmMTAwMCwyLGMwNjdjYjJhLDFkNCw0YTQ2MzMyMSkgYXQgc2NoZWRfc3dp dGNoKzB4MTU1DQoJbWlfc3dpdGNoKGM1ZmYxMDAwLDUwLGMwNjdjYjJhLGNhLDEpIGF0IG1pX3N3 aXRjaCsweDI0OA0KCW1zbGVlcChkMjZlOTI0NCxjMDZjYzY4OCw1MCxjMDY4MmUyMCwwKSBhdCBt c2xlZXArMHg0ZmYNCglhY3F1aXJlKGU5Yjk3YTNjLDIwMDAwMjAsNjAwLGU3LGMwNjgyYWE3KSBh dCBhY3F1aXJlKzB4YWUNCglsb2NrbWdyKGQyNmU5MjQ0LDIwOTAwMjIsYzY5NTVlMzgsYzVmZjEw MDAsYzA2ZDg5ZTgpIGF0IGxvY2ttZ3IrMHg0NTcNCglnZXRibGsoYzY5NTVlMzgsMCwwLDgwMCww KSBhdCBnZXRibGsrMHgxOGYNCglicmVhZG4oYzY5NTVlMzgsMCwwLDgwMCwwKSBhdCBicmVhZG4r MHg1Mg0KCWJyZWFkKGM2OTU1ZTM4LDAsMCw4MDAsMCkgYXQgYnJlYWQrMHg0Yw0KCWZmc19yZWFk KGU5Yjk3YmU0LGMwNjg0YTZiLGM1ZmYxMDAwLDFmZixjMDZkODZmMCkgYXQgZmZzX3JlYWQrMHgz ZmYNCgl2bl9yZWFkKGM2MmY3YjZjLGU5Yjk3YzgwLGM2MjkyMTgwLDAsYzVmZjEwMDApIGF0IHZu X3JlYWQrMHgxZjUNCglkb2ZpbGVyZWFkKGM1ZmYxMDAwLGM2MmY3YjZjLDQsODBlZTAwMCw0MDAw KSBhdCBkb2ZpbGVyZWFkKzB4ZGMNCglyZWFkKGM1ZmYxMDAwLGU5Yjk3ZDE0LGMwNjkyMzdhLDNl ZSwzKSBhdCByZWFkKzB4NmINCglzeXNjYWxsKDgwNjAwMmYsMmYsYmZiZjAwMmYsODA2YzE1OCw0 MDAwKSBhdCBzeXNjYWxsKzB4MmMwDQoJWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5 c2NhbGwrMHgxZA0KCS0tLSBzeXNjYWxsICgzLCBGcmVlQlNEIEVMRjMyLCByZWFkKSwgZWlwID0g MHg4MDYxYTRmLCBlc3AgPQ0KMHhiZmJmZDNhYywgZWJwID0gMA0KCXhiZmJmZDNjOCAtLS0NCglk Yj4NCg0KCQktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgkJRnJvbTogS2VuIFNtaXRoIFtt YWlsdG86a2Vuc21pdGhAY3NlLkJ1ZmZhbG8uRURVXSANCgkJU2VudDogVGh1IDEvMjIvMjAwNCAx OjUwIFBNIA0KCQlUbzogUm9iaW4gUC4gQmxhbmNoYXJkIA0KCQlDYzogS2VuIFNtaXRoOyBLcmlz IEtlbm5hd2F5IA0KCQlTdWJqZWN0OiBSZTogU3RyYW5nZSBiZWhhdmlvdXINCgkJDQoJCQ0KDQoJ CU9uIFRodSwgSmFuIDIyLCAyMDA0IGF0IDAxOjM0OjM5UE0gLTA1MDAsIFJvYmluIFAuIEJsYW5j aGFyZA0Kd3JvdGU6DQoJCQ0KCQk+IEkgYWxzbyBlbmFibGVkIERFQlVHX1ZGU19MT0NLUzsgYnV0 IG5vdGhpbmcgb2YgaW50ZXJlc3QNCnNob3dzIHVwIG9uY2UNCgkJPiAnbWFrZXNoYXRpcycgZ2V0 cyBzdHVjayBpbiBnZXRibGsuIEkndmUganVzdCBzZXR1cCBzZXJpYWwNCmNvbnNvbGUgb24gdGhp cw0KCQk+IHRoaW5nIChhbG9uZyB3aXRoIEJSRUFLX1RPX0RFQlVHR0VSKS4gSG93IGRvIEkgZW50 ZXIgdGhlDQpkZWJ1Z2dlciBvdmVyIHRoZQ0KCQk+IHNlcmlhbCBsaW5rIChJIGtub3cgaG93IGZy b20gdGhlIHRlcm1pbmFsIGNvbnNvbGUpPyBPbmNlDQp0aGVyZSBkbyBqdXN0IGRvIGENCgkJPiAi dHIgJHBpZCIgdG8gKGhvcGVmdWxseSkgZ2V0IHNvbWUgdXNlZnVsIGluZm8gPw0KCQkNCgkJSSB3 YXMgYWJsZSB0byBnZXQgdGhlcmUgYnkgbG9nZ2luZyBpbiBhcyByb290LCB0aGVuIGRvOg0KCQkN CgkJICAgICAgICBzeXNjdGwgZGVidWcuZW50ZXJfZGVidWdnZXI9ZGRiDQoJCQ0KCQlUaGF0IHNl ZW1zIHRvIGRyb3AgdGhlIGtlcm5lbCB0byBEREIgb24gdGhlIHNlcmlhbCBwb3J0Lg0KCQkNCgkJ SGVyZSBpcyB3aGF0IHNlZW1zIHR5cGljYWwgb2YgdGhlIHByb2Nlc3NlcyB0aGF0IGFyZSB3ZWRn ZWQNCm9uIG15DQoJCW1hY2hpbmU6DQoJCQ0KCQlkYj4gdHIgMTQyOQ0KCQlzY2hlZF9zd2l0Y2go YzllMGY2OTAsMixjMDg3MjExMSwxZDQsNzU3NTI2OTkpIGF0DQpzY2hlZF9zd2l0Y2grMHhiNQ0K CQltaV9zd2l0Y2goYzllMGY2OTAsNTAsYzA4NzIxMTEsY2EsMSkgYXQgbWlfc3dpdGNoKzB4MjQ4 DQoJCW1zbGVlcChkM2JiMzU2NCxjMDkyZjlkYyw1MCxjMDg3ODJhMCwwKSBhdCBtc2xlZXArMHg0 ZmYNCgkJYWNxdWlyZShlZGMyNmFiNCwyMDAwMDIwLDYwMCxlNyxjMDg3N2YyNykgYXQgYWNxdWly ZSsweGFlDQoJCWxvY2ttZ3IoZDNiYjM1NjQsMjA5MDAyMixjNzhhZjQxMCxjOWUwZjY5MCxjMDY2 OWFlMykgYXQNCmxvY2ttZ3IrMHg0NTcNCgkJZ2V0YmxrKGM3OGFmNDEwLDI3N2I0NDAsMCw0MDAw LDApIGF0IGdldGJsaysweDE5MA0KCQlicmVhZG4oYzc4YWY0MTAsMjc3YjQ0MCwwLDQwMDAsMCkg YXQgYnJlYWRuKzB4NTINCgkJYnJlYWQoYzc4YWY0MTAsMjc3YjQ0MCwwLDQwMDAsMCkgYXQgYnJl YWQrMHg0Yw0KCQlmZnNfdXBkYXRlKGM5NjUwMjA4LDAsMSw1NCxlZGMyNmM0YykgYXQgZmZzX3Vw ZGF0ZSsweDIzNQ0KCQl1ZnNfaW5hY3RpdmUoZWRjMjZjNzgsZWRjMjZjOTQsYzA2OWU3N2UsZWRj MjZjNzgsYzA4Nzk4MmMpIGF0DQp1ZnNfaW5hY3RpdmUrMHgyMDV1ZnNfdm5vcGVyYXRlKGVkYzI2 Yzc4LGMwODc5ODJjLGMwODc5NGFkLDdjYyxjMDkxMGNlMCkgYXQNCnVmc192bm9wZXJhdGUrMHgx OA0KCQl2cmVsZShjOTY1MDIwOCwwLGMwODc5ZDczLDJjYixjOWI1YWIwMCkgYXQgdnJlbGUrMHgx NmUNCgkJZmNoZGlyKGM5ZTBmNjkwLGVkYzI2ZDE0LGMwODhmZjhkLDNlZSwxKSBhdCBmY2hkaXIr MHgyMjcNCgkJc3lzY2FsbCg4MDUwMDJmLDgwNTAwMmYsYmZiZjAwMmYsNSw4MDU4ZjAwKSBhdCBz eXNjYWxsKzB4MmMwDQoJCVhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4 MWQNCgkJLS0tIHN5c2NhbGwgKDEzLCBGcmVlQlNEIEVMRjMyLCBmY2hkaXIpLCBlaXAgPSAweDI4 MGM2MTZmLA0KZXNwID0gMHhiZmJmZTkyYywgZWJwID0gMHhiZmJmZTljOCAtLS0NCgkJZGI+DQoJ CQ0KCQlUaGVyZSBpcyBvbmUgdGhhdCdzIHdlZGdlZCBpbiAidWZzIiBpbnN0ZWFkIG9mICJnZXRi bGsiLCBhbmQNCml0IGxvb2tzDQoJCWxpa2UgdGhpczoNCgkJDQoJCWRiPiB0ciAyMDYyDQoJCXNj aGVkX3N3aXRjaChjNzg1ZTkzMCwyLGMwODcyMTExLDFkNCw5YzBlMjk5NSkgYXQNCnNjaGVkX3N3 aXRjaCsweGI1DQoJCW1pX3N3aXRjaChjNzg1ZTkzMCw1MCxjMDg3MjExMSxjYSwxKSBhdCBtaV9z d2l0Y2grMHgyNDgNCgkJbXNsZWVwKGM4M2Q1NWMwLGMwOTJmOGUwLDUwLGMwODdkMDRjLDApIGF0 IG1zbGVlcCsweDRmZg0KCQlhY3F1aXJlKGVkYjY4YTU0LDEwMDAwNDAsNjAwLGU3LDE0YikgYXQg YWNxdWlyZSsweGFlDQoJCWxvY2ttZ3IoYzgzZDU1YzAsMTAxMDAwMixjODNkNTUxNCxjNzg1ZTkz MCxlZGI2OGE3MCkgYXQNCmxvY2ttZ3IrMHg0NTcNCgkJdm9wX3N0ZGxvY2soZWRiNjhhOTgsZWRi NjhhN2MsYzA3YWRkYTgsZWRiNjhhOTgsZWRiNjhhYjQpIGF0DQp2b3Bfc3RkbG9jaysweDJjDQoJ CXZvcF9kZWZhdWx0b3AoZWRiNjhhOTgsZWRiNjhhYjQsYzA2YWQ0YTksZWRiNjhhOTgsZWRiNjhh YjQpDQphdCB2b3BfZGVmYXVsdG9wKzB4MTgNCgkJdWZzX3Zub3BlcmF0ZShlZGI2OGE5OCxlZGI2 OGFiNCxjMDYzNWYzYSxjODNkNTUxNCw4KSBhdA0KdWZzX3Zub3BlcmF0ZSsweDE4DQoJCXZuX2xv Y2soYzgzZDU1MTQsMTAwMDIsYzc4NWU5MzAsNzYwLDApIGF0IHZuX2xvY2srMHhmOQ0KCQl2Z2V0 KGM4M2Q1NTE0LDIsYzc4NWU5MzAsZGJkZGUsYzc4NWU5MzApIGF0IHZnZXQrMHgxMTYNCgkNCnZm c19jYWNoZV9sb29rdXAoZWRiNjhiOGMsZWRiNjhiYTgsYzA2OTc1NTYsZWRiNjhiOGMsYzA4ODdj ZDEpIGF0DQp2ZnNfY2FjaGVfbG9va3VwKzB4MmUyDQoJCXVmc192bm9wZXJhdGUoZWRiNjhiOGMs YzA4ODdjZDEsYzc4NWU5MzAsYzA2MzYwMGQsYzc4NWU5MzApDQphdCB1ZnNfdm5vcGVyYXRlKzB4 MTgNCgkJbG9va3VwKGVkYjY4YzI4LDAsYzA4NzhmMTIsYTYsYzc4NWU5MzApIGF0IGxvb2t1cCsw eDM3Ng0KCQluYW1laShlZGI2OGMyOCxlZGI2OGM0NCxjMDY2OWFlMyxjMDkzNGU4MCxjMDkzNGRl MCkgYXQNCm5hbWVpKzB4MjdlDQoJCWxzdGF0KGM3ODVlOTMwLGVkYjY4ZDE0LGMwODhmZjhkLDNl ZSwyKSBhdCBsc3RhdCsweDUyDQoJCXN5c2NhbGwoODA2MDAyZiw4MDUwMDJmLGJmYmYwMDJmLDgw NWU1MDAsODA1ZTU0OCkgYXQNCnN5c2NhbGwrMHgyYzANCgkJWGludDB4ODBfc3lzY2FsbCgpIGF0 IFhpbnQweDgwX3N5c2NhbGwrMHgxZA0KCQktLS0gc3lzY2FsbCAoMTkwLCBGcmVlQlNEIEVMRjMy LCBsc3RhdCksIGVpcCA9IDB4MjgwYzU1NmYsDQplc3AgPSAweGJmYmZlYmZjLCBlYnAgPSAweGJm YmZlYzk4IC0tLQ0KCQlkYj4NCgkJDQoJCS0tDQoJCSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEtlbiBTbWl0aA0KCQktIEZyb20gdGhlcmUgdG8gaGVyZSwg ZnJvbSBoZXJlIHRvICAgICAgfA0Ka2Vuc21pdGhAY3NlLmJ1ZmZhbG8uZWR1DQoJCSAgdGhlcmUs IGZ1bm55IHRoaW5ncyBhcmUgZXZlcnl3aGVyZS4gICB8DQoJCSAgICAgICAgICAgICAgICAgICAg ICAtIFRoZW9kb3JlIEdlaXNlbCB8DQoJCQ0KCQkNCg0K From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 08:11: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 0081F16A4CE for ; Sun, 25 Jan 2004 08:11:52 -0800 (PST) Received: from praetor.linc-it.com (adsl-068-157-070-217.sip.jan.bellsouth.net [68.157.70.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8975143D31 for ; Sun, 25 Jan 2004 08:11:50 -0800 (PST) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-81-240-202.jan.bellsouth.net [65.81.240.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by praetor.linc-it.com (Postfix) with ESMTP id 2D9C3155E4; Sun, 25 Jan 2004 10:11:49 -0600 (CST) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 0548D20F94; Sun, 25 Jan 2004 10:11:46 -0600 (CST) Date: Sun, 25 Jan 2004 10:11:46 -0600 From: "Matthew D. Fuller" To: Mikhail Teterin Message-ID: <20040125161146.GA13101@over-yonder.net> References: <200401250334.i0P3YWJX028845@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401250334.i0P3YWJX028845@aldan.algebra.com> User-Agent: Mutt/1.4.1i-fullermd.1 X-Editor: vi X-OS: FreeBSD cc: current@FreeBSD.org Subject: Re: netbooting -current on ThinkNIC 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, 25 Jan 2004 16:11:52 -0000 On Sat, Jan 24, 2004 at 10:34:32PM -0500 I heard the voice of Mikhail Teterin, and lo! it spake thus: > > However, when it tries to boot the said kernel, the whole box freezes up > (before even displaying the kernel info or FreeBSD Copyright). My only > guess is, I'm screwing up the kernel config (below)... Well, I'm hardly an expert, but... > #options FFS #Berkeley Fast Filesystem What sort of filesystem are you expecting to have the kernel running off of, if not FFS? md is just a pseudo-physical layer that a FFS sits on top of. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 08:27:43 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 AD32D16A4CE; Sun, 25 Jan 2004 08:27:43 -0800 (PST) Received: from smtp.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E6D43D41; Sun, 25 Jan 2004 08:27:42 -0800 (PST) (envelope-from der_julian@web.de) Received: from [141.30.207.25] (helo=jmmr.boelthorn.wh29.tu-dresden.de) by smtp.web.de with smtp (WEB.DE 4.99 #566) id 1Akn6r-0002Vm-00; Sun, 25 Jan 2004 17:27:41 +0100 Date: Sun, 25 Jan 2004 17:27:33 +0100 From: "Julian St." To: wpaul@FreeBSD.ORG (Bill Paul) Message-Id: <20040125172733.4749dc9a@jmmr.boelthorn.wh29.tu-dresden.de> In-Reply-To: <20040125045117.BA32B16A4CF@hub.freebsd.org> References: <20040125035858.GB82300@daemon.unixdaemon.org> <20040125045117.BA32B16A4CF@hub.freebsd.org> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sun__25_Jan_2004_17_27_33_+0100_v0K+VKwDKMPXJVlN" X-WEBDE-TAG: W Sender: der_julian@web.de cc: freebsd-current@freebsd.org Subject: Re: Project Evil: The Evil Continues 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, 25 Jan 2004 16:27:43 -0000 --Signature=_Sun__25_Jan_2004_17_27_33_+0100_v0K+VKwDKMPXJVlN Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Sat, 24 Jan 2004 20:51:17 -0800 (PST) wpaul@FreeBSD.ORG (Bill Paul) wrote: > What doesn't Project Evil do: > > - Provide support for USB network devices (this would require > emulating portions of USBD.SYS and portitions of the Windows > I/O model outside of the NDIS API). Is this planned for the future? I have a PRISM3-based WLAN card attached via USB, that is hard to get working on any non-Windows OS. addr 1: OHCI root hub, AcerLabs addr 2: IEEE 802.11b PRISM3 USB, AirVast Taiwan Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming --Signature=_Sun__25_Jan_2004_17_27_33_+0100_v0K+VKwDKMPXJVlN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAE+58NdiNDtZbKrURArYJAJsExPeBDZCAPlXD+nnlmpSzGyjBvACfRjYE MyWbm20imrOYTgk73QFnSLM= =N2km -----END PGP SIGNATURE----- --Signature=_Sun__25_Jan_2004_17_27_33_+0100_v0K+VKwDKMPXJVlN-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 08:40: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 2B9C416A4CE for ; Sun, 25 Jan 2004 08:40:25 -0800 (PST) Received: from sarajevo.pacific.net.sg (sarajevo.pacific.net.sg [203.120.90.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 8397743D62 for ; Sun, 25 Jan 2004 08:40:09 -0800 (PST) (envelope-from oceanare@pacific.net.sg) Received: (qmail 19807 invoked from network); 25 Jan 2004 16:40:07 -0000 Received: from unknown (HELO maxwell6.pacific.net.sg) (203.120.90.212) by sarajevo with SMTP; 25 Jan 2004 16:40:06 -0000 Received: from pacific.net.sg ([210.24.202.41]) by maxwell6.pacific.net.sg with ESMTP id <20040125164005.RLPN9972.maxwell6.pacific.net.sg@pacific.net.sg>; Mon, 26 Jan 2004 00:40:05 +0800 Message-ID: <4013F165.6090307@pacific.net.sg> Date: Mon, 26 Jan 2004 00:40:05 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us, de MIME-Version: 1.0 To: Peter Schultz References: <4010B736.1060105@pacific.net.sg> <40112435.9080902@bis.midco.net> <4011381F.5060709@pacific.net.sg> <40113AD1.3040408@bis.midco.net> In-Reply-To: <40113AD1.3040408@bis.midco.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: ACPI on Fujitsu P2120 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, 25 Jan 2004 16:40:25 -0000 Hi Peter, Peter Schultz wrote: > I think your kernel needs to be built with 'options DDB'. Please let me > know if that fixes it. > I got this now but I feel somehow lost in space. What I wonder most that disabling APM does not remove it from dmesg's output. My main problem is that it is some time ago that I wrote drivers for Unix. I lost this feeling where to start looking for the problem. I looked at the code in acpi.c but did not find any hints to continue with. I was also able to install this: http://www.stalker.org/~sean/freebsd-p2040/FujiApp/index.html It is a small utility to emulate the original behaviour of the "Fn" key on a P2120. It works as expected. Do you know the name of the modules where the ACPI information is read from the BIOS and where the machine is actually shutdown and restarted again when the lid opens and closes. Thanks! Erich From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 09:36: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 58A1816A4CE; Sun, 25 Jan 2004 09:36:52 -0800 (PST) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C3EB43D1D; Sun, 25 Jan 2004 09:36:30 -0800 (PST) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id i0PHWipq000452; Sun, 25 Jan 2004 12:32:44 -0500 (EST) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id i0PHWiPX000451; Sun, 25 Jan 2004 12:32:44 -0500 (EST) Date: Sun, 25 Jan 2004 12:32:44 -0500 From: Mathew Kanner To: Don Lewis Message-ID: <20040125173244.GA95238@cnd.mcgill.ca> References: <200401250204.i0P2427E073698@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401250204.i0P2427E073698@gw.catspoiler.org> User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.62 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on hak.cnd.mcgill.ca cc: cg@freebsd.org cc: current@freebsd.org Subject: Re: dev/sound/pcm/* patch testers wanted 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, 25 Jan 2004 17:36:52 -0000 On Jan 24, Don Lewis wrote: > The is a buffer overflow in the interrupt handler in the vchan code that > occasionally stomps on something on the kernel heap and causes panics in > other parts of the kernel. I tracked down the cause of the buffer > overflow with the help of Stefan Ehmann and made a number of changes to > the sound/pcm/* code to try to avoid triggering the overflow. > [...] Don, I think it should be noted that vchans aren't always enabled by default and those testing this patch should explicitly make sure that vchans are enabled either via sysctl hw.snd.pcmX.vchans=5 I've tested this patch with xmms and mplayer and forcing them to cycle through many songs, and it seems at least functional. I would like to see the patch commited very soon. (Say tommorow?) btw, the locking cleanup is very helpful. --Mat > > Because of the architecture of the sound code, it may not be totally > possible to avoid the potential for a buffer overflow, so I added code > to print a diagnostic message if this situation occurs, as well as code > to panic() the machine if an interrupt happens at the "wrong" time in > this situation and a buffer overflow is imminent. > > I cleaned up the channel locking code, but there are still issues with > the usage of pcm_lock() that have not been addressed. > > I also fixed up a NULL pointer dereference that was noticed by Ryan > Somers. > > You will need a fairly recent version of -CURRENT, with > src/sys/dev/sound/pcm/dsp.c rev 1.70. I highly recommend testing this > patch with the INVARIANTS kernel option, as well as WITNESS, if > possible, to flush out any potential problems and track them quickly to > their source. > > Please let me know if you get the "Danger!" diagnostic message. > > > Here is the complete list of changes: > > Change KASSERT() in feed_vchan16() into an explicit test and call to > panic() so that the buffer overflow just beyond this point is always > caught, even when the code is not compiled with INVARIANTS. > > Change chn_setblocksize() buffer reallocation code to attempt to avoid > the feed_vchan16() buffer overflow by attempting to always keep the > bufsoft buffer at least as large as the bufhard buffer. > > Print a diagnositic message > Danger! %s bufsoft size increasing from %d to %d after CHANNEL_SETBLOCKSIZE() > if our best attempts fail. If feed_vchan16() were to be called by > the interrupt handler while locks are dropped in chn_setblocksize() > to increase the size bufsoft to match the size of bufhard, the panic() > code in feed_vchan16() will be triggered. If the diagnostic message > is printed, it is a warning that a panic is possible if the system > were to see events in an "unlucky" order. > > Change the locking code to avoid the need for MTX_RECURSIVE mutexes. > > Add the MTX_DUPOK option to the channel mutexes and change the locking > sequence to always lock the parent channel before its children to avoid > the possibility of deadlock. > > Actually implement locking assertions for the channel mutexes and fix > the problems found by the resulting assertion violations. > > Clean up the locking code in dsp_ioctl(). > > Allocate the channel buffers using the malloc() M_WAITOK option instead > of M_NOWAIT so that buffer allocation won't fail. Drop locks across > the malloc() calls. > > Add/modify KASSERTS() in attempt to detect problems early. > > Don't dereference a NULL pointer when setting hw.snd.maxautovchans > if a hardware driver is not loaded. Noticed by Ryan Sommers > . > > > Index: sys/dev/sound/pcm/buffer.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/buffer.c,v > retrieving revision 1.21 > diff -u -r1.21 buffer.c > --- sys/dev/sound/pcm/buffer.c 27 Nov 2003 19:51:44 -0000 1.21 > +++ sys/dev/sound/pcm/buffer.c 19 Jan 2004 00:33:51 -0000 > @@ -30,6 +30,14 @@ > > SND_DECLARE_FILE("$FreeBSD: src/sys/dev/sound/pcm/buffer.c,v 1.21 2003/11/27 19:51:44 matk Exp $"); > > +#ifdef USING_MUTEX > +#define MTX_LOCK(lock) mtx_lock(lock); > +#define MTX_UNLOCK(lock) mtx_unlock(lock); > +#else > +#define MTX_LOCK(lock) > +#define MTX_UNLOCK(lock) > +#endif > + > struct snd_dbuf * > sndbuf_create(device_t dev, char *drv, char *desc) > { > @@ -128,7 +136,7 @@ > b->blksz = blksz; > b->bufsize = blkcnt * blksz; > > - tmpbuf = malloc(b->bufsize, M_DEVBUF, M_NOWAIT); > + tmpbuf = malloc(b->bufsize, M_DEVBUF, M_WAITOK); > if (tmpbuf == NULL) > return ENOMEM; > free(b->tmpbuf, M_DEVBUF); > @@ -138,25 +146,32 @@ > } > > int > -sndbuf_remalloc(struct snd_dbuf *b, unsigned int blkcnt, unsigned int blksz) > +sndbuf_remalloc(struct snd_dbuf *b, unsigned int blkcnt, unsigned int blksz, > + struct mtx *lock) > { > u_int8_t *buf, *tmpbuf, *f1, *f2; > unsigned int bufsize; > + int ret; > > if (blkcnt < 2 || blksz < 16) > return EINVAL; > > bufsize = blksz * blkcnt; > > - buf = malloc(bufsize, M_DEVBUF, M_NOWAIT); > - if (buf == NULL) > - return ENOMEM; > + MTX_UNLOCK(lock); > + buf = malloc(bufsize, M_DEVBUF, M_WAITOK); > + if (buf == NULL) { > + ret = ENOMEM; > + goto out; > + } > > - tmpbuf = malloc(bufsize, M_DEVBUF, M_NOWAIT); > + tmpbuf = malloc(bufsize, M_DEVBUF, M_WAITOK); > if (tmpbuf == NULL) { > free(buf, M_DEVBUF); > - return ENOMEM; > + ret = ENOMEM; > + goto out; > } > + MTX_LOCK(lock); > > b->blkcnt = blkcnt; > b->blksz = blksz; > @@ -167,13 +182,18 @@ > b->buf = buf; > b->tmpbuf = tmpbuf; > > + sndbuf_reset(b); > + > + MTX_UNLOCK(lock); > if (f1) > free(f1, M_DEVBUF); > if (f2) > free(f2, M_DEVBUF); > > - sndbuf_reset(b); > - return 0; > + ret = 0; > +out: > + MTX_LOCK(lock); > + return ret; > } > > void > Index: sys/dev/sound/pcm/buffer.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/buffer.h,v > retrieving revision 1.8 > diff -u -r1.8 buffer.h > --- sys/dev/sound/pcm/buffer.h 27 Nov 2003 19:51:44 -0000 1.8 > +++ sys/dev/sound/pcm/buffer.h 17 Jan 2004 05:40:24 -0000 > @@ -65,7 +65,7 @@ > int sndbuf_setup(struct snd_dbuf *b, void *buf, unsigned int size); > void sndbuf_free(struct snd_dbuf *b); > int sndbuf_resize(struct snd_dbuf *b, unsigned int blkcnt, unsigned int blksz); > -int sndbuf_remalloc(struct snd_dbuf *b, unsigned int blkcnt, unsigned int blksz); > +int sndbuf_remalloc(struct snd_dbuf *b, unsigned int blkcnt, unsigned int blksz, struct mtx *lock); > void sndbuf_reset(struct snd_dbuf *b); > void sndbuf_clear(struct snd_dbuf *b, unsigned int length); > void sndbuf_fillsilence(struct snd_dbuf *b); > Index: sys/dev/sound/pcm/channel.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v > retrieving revision 1.93 > diff -u -r1.93 channel.c > --- sys/dev/sound/pcm/channel.c 5 Dec 2003 02:08:13 -0000 1.93 > +++ sys/dev/sound/pcm/channel.c 20 Jan 2004 20:19:37 -0000 > @@ -70,9 +70,9 @@ > chn_lockinit(struct pcm_channel *c, int dir) > { > if (dir == PCMDIR_PLAY) > - c->lock = snd_mtxcreate(c->name, "pcm play channel"); > + c->lock = snd_chnmtxcreate(c->name, "pcm play channel"); > else > - c->lock = snd_mtxcreate(c->name, "pcm record channel"); > + c->lock = snd_chnmtxcreate(c->name, "pcm record channel"); > } > > static void > @@ -205,16 +205,19 @@ > unsigned int ret, amt; > > CHN_LOCKASSERT(c); > - DEB( > +/* DEB( > if (c->flags & CHN_F_CLOSING) { > sndbuf_dump(b, "b", 0x02); > sndbuf_dump(bs, "bs", 0x02); > - }) > + }) */ > > if (c->flags & CHN_F_MAPPED) > sndbuf_acquire(bs, NULL, sndbuf_getfree(bs)); > > amt = sndbuf_getfree(b); > + KASSERT(amt <= sndbuf_getsize(bs), > + ("%s(%s): amt %d > source size %d, flags 0x%x", __func__, c->name, > + amt, sndbuf_getsize(bs), c->flags)); > if (sndbuf_getready(bs) < amt) > c->xruns++; > > @@ -746,13 +749,6 @@ > c->devinfo = NULL; > c->feeder = NULL; > > - ret = EINVAL; > - fc = feeder_getclass(NULL); > - if (fc == NULL) > - goto out; > - if (chn_addfeeder(c, fc, NULL)) > - goto out; > - > ret = ENOMEM; > b = sndbuf_create(c->dev, c->name, "primary"); > if (b == NULL) > @@ -760,6 +756,16 @@ > bs = sndbuf_create(c->dev, c->name, "secondary"); > if (bs == NULL) > goto out; > + > + CHN_LOCK(c); > + > + ret = EINVAL; > + fc = feeder_getclass(NULL); > + if (fc == NULL) > + goto out; > + if (chn_addfeeder(c, fc, NULL)) > + goto out; > + > sndbuf_setup(bs, NULL, 0); > c->bufhard = b; > c->bufsoft = bs; > @@ -767,7 +773,9 @@ > c->feederflags = 0; > > ret = ENODEV; > + CHN_UNLOCK(c); /* XXX - Unlock for CHANNEL_INIT() malloc() call */ > c->devinfo = CHANNEL_INIT(c->methods, devinfo, b, c, dir); > + CHN_LOCK(c); > if (c->devinfo == NULL) > goto out; > > @@ -789,6 +797,7 @@ > > > out: > + CHN_UNLOCK(c); > if (ret) { > if (c->devinfo) { > if (CHANNEL_FREE(c->methods, c->devinfo)) > @@ -971,11 +980,17 @@ > { > struct snd_dbuf *b = c->bufhard; > struct snd_dbuf *bs = c->bufsoft; > - int bufsz, irqhz, tmp, ret; > + int irqhz, tmp, ret, maxsize, reqblksz, tmpblksz; > > CHN_LOCKASSERT(c); > - if (!CANCHANGE(c) || (c->flags & CHN_F_MAPPED)) > + if (!CANCHANGE(c) || (c->flags & CHN_F_MAPPED)) { > + KASSERT(sndbuf_getsize(bs) == 0 || > + sndbuf_getsize(bs) >= sndbuf_getsize(b), > + ("%s(%s): bufsoft size %d < bufhard size %d", __func__, > + c->name, sndbuf_getsize(bs), sndbuf_getsize(b))); > return EINVAL; > + } > + c->flags |= CHN_F_SETBLOCKSIZE; > > ret = 0; > DEB(printf("%s(%d, %d)\n", __func__, blkcnt, blksz)); > @@ -1007,36 +1022,68 @@ > c->flags |= CHN_F_HAS_SIZE; > } > > - bufsz = blkcnt * blksz; > - > - ret = sndbuf_remalloc(bs, blkcnt, blksz); > - if (ret) > - goto out; > + reqblksz = blksz; > > /* adjust for different hw format/speed */ > - irqhz = (sndbuf_getbps(bs) * sndbuf_getspd(bs)) / sndbuf_getblksz(bs); > + irqhz = (sndbuf_getbps(bs) * sndbuf_getspd(bs)) / blksz; > DEB(printf("%s: soft bps %d, spd %d, irqhz == %d\n", __func__, sndbuf_getbps(bs), sndbuf_getspd(bs), irqhz)); > RANGE(irqhz, 16, 512); > > - sndbuf_setblksz(b, (sndbuf_getbps(b) * sndbuf_getspd(b)) / irqhz); > + tmpblksz = (sndbuf_getbps(b) * sndbuf_getspd(b)) / irqhz; > > /* round down to 2^x */ > blksz = 32; > - while (blksz <= sndbuf_getblksz(b)) > + while (blksz <= tmpblksz) > blksz <<= 1; > blksz >>= 1; > > /* round down to fit hw buffer size */ > - RANGE(blksz, 16, sndbuf_getmaxsize(b) / 2); > + if (sndbuf_getmaxsize(b) > 0) > + RANGE(blksz, 16, sndbuf_getmaxsize(b) / 2); > + else > + /* virtual channels don't appear to allocate bufhard */ > + RANGE(blksz, 16, CHN_2NDBUFMAXSIZE / 2); > DEB(printf("%s: hard blksz requested %d (maxsize %d), ", __func__, blksz, sndbuf_getmaxsize(b))); > > + /* Increase the size of bufsoft if before increasing bufhard. */ > + maxsize = sndbuf_getsize(b); > + if (sndbuf_getsize(bs) > maxsize) > + maxsize = sndbuf_getsize(bs); > + if (reqblksz * blkcnt > maxsize) > + maxsize = reqblksz * blkcnt; > + if (sndbuf_getsize(bs) != maxsize || sndbuf_getblksz(bs) != reqblksz) { > + ret = sndbuf_remalloc(bs, maxsize/reqblksz, reqblksz, c->lock); > + if (ret) > + goto out1; > + } > + > sndbuf_setblksz(b, CHANNEL_SETBLOCKSIZE(c->methods, c->devinfo, blksz)); > > + /* Decrease the size of bufsoft after decreasing bufhard. */ > + maxsize = sndbuf_getsize(b); > + if (reqblksz * blkcnt > maxsize) > + maxsize = reqblksz * blkcnt; > + if (maxsize > sndbuf_getsize(bs)) > + printf("Danger! %s bufsoft size increasing from %d to %d after CHANNEL_SETBLOCKSIZE()\n", > + c->name, sndbuf_getsize(bs), maxsize); > + if (sndbuf_getsize(bs) != maxsize || sndbuf_getblksz(bs) != reqblksz) { > + ret = sndbuf_remalloc(bs, maxsize/reqblksz, reqblksz, c->lock); > + if (ret) > + goto out1; > + } > + > irqhz = (sndbuf_getbps(b) * sndbuf_getspd(b)) / sndbuf_getblksz(b); > DEB(printf("got %d, irqhz == %d\n", sndbuf_getblksz(b), irqhz)); > > chn_resetbuf(c); > +out1: > + KASSERT(sndbuf_getsize(bs) == 0 || > + sndbuf_getsize(bs) >= sndbuf_getsize(b), > + ("%s(%s): bufsoft size %d < bufhard size %d, reqblksz=%d blksz=%d maxsize=%d blkcnt=%d", > + __func__, c->name, sndbuf_getsize(bs), sndbuf_getsize(b), reqblksz, > + blksz, maxsize, blkcnt)); > out: > + c->flags &= ~CHN_F_SETBLOCKSIZE; > return ret; > } > > @@ -1216,8 +1263,12 @@ > struct pcm_channel *child; > int run; > > - if (SLIST_EMPTY(&c->children)) > + CHN_LOCK(c); > + > + if (SLIST_EMPTY(&c->children)) { > + CHN_UNLOCK(c); > return ENODEV; > + } > > run = (c->flags & CHN_F_TRIGGERED)? 1 : 0; > /* > @@ -1253,8 +1304,10 @@ > blksz = sndbuf_getmaxsize(c->bufhard) / 2; > SLIST_FOREACH(pce, &c->children, link) { > child = pce->channel; > + CHN_LOCK(child); > if (sndbuf_getblksz(child->bufhard) < blksz) > blksz = sndbuf_getblksz(child->bufhard); > + CHN_UNLOCK(child); > } > chn_setblocksize(c, 2, blksz); > } > @@ -1268,13 +1321,16 @@ > nrun = 0; > SLIST_FOREACH(pce, &c->children, link) { > child = pce->channel; > + CHN_LOCK(child); > if (child->flags & CHN_F_TRIGGERED) > nrun = 1; > + CHN_UNLOCK(child); > } > if (nrun && !run) > chn_start(c, 1); > if (!nrun && run) > chn_abort(c); > } > + CHN_UNLOCK(c); > return 0; > } > Index: sys/dev/sound/pcm/channel.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.h,v > retrieving revision 1.28 > diff -u -r1.28 channel.h > --- sys/dev/sound/pcm/channel.h 7 Sep 2003 16:28:03 -0000 1.28 > +++ sys/dev/sound/pcm/channel.h 19 Jan 2004 04:32:36 -0000 > @@ -103,7 +103,7 @@ > #ifdef USING_MUTEX > #define CHN_LOCK(c) mtx_lock((struct mtx *)((c)->lock)) > #define CHN_UNLOCK(c) mtx_unlock((struct mtx *)((c)->lock)) > -#define CHN_LOCKASSERT(c) > +#define CHN_LOCKASSERT(c) mtx_assert((struct mtx *)((c)->lock), MA_OWNED) > #else > #define CHN_LOCK(c) > #define CHN_UNLOCK(c) > @@ -134,6 +134,7 @@ > #define CHN_F_MAPPED 0x00010000 /* has been mmap()ed */ > #define CHN_F_DEAD 0x00020000 > #define CHN_F_BADSETTING 0x00040000 > +#define CHN_F_SETBLOCKSIZE 0x00080000 > > #define CHN_F_VIRTUAL 0x10000000 /* not backed by hardware */ > > Index: sys/dev/sound/pcm/dsp.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/dsp.c,v > retrieving revision 1.70 > diff -u -r1.70 dsp.c > --- sys/dev/sound/pcm/dsp.c 20 Jan 2004 05:30:09 -0000 1.70 > +++ sys/dev/sound/pcm/dsp.c 23 Jan 2004 09:47:54 -0000 > @@ -113,8 +113,8 @@ > > flags = dsp_get_flags(dev); > d = dsp_get_info(dev); > - pcm_lock(d); > pcm_inprog(d, 1); > + pcm_lock(d); > KASSERT((flags & SD_F_PRIO_SET) != SD_F_PRIO_SET, \ > ("getchns: read and write both prioritised")); > > @@ -159,9 +159,7 @@ > CHN_UNLOCK(wrch); > if (rdch && rdch != pcm_getfakechan(d) && (prio & SD_F_PRIO_RD)) > CHN_UNLOCK(rdch); > - pcm_lock(d); > pcm_inprog(d, -1); > - pcm_unlock(d); > } > > static int > @@ -476,6 +474,11 @@ > wrch = NULL; > if (kill & 2) > rdch = NULL; > + > + if (rdch != NULL) > + CHN_LOCK(rdch); > + if (wrch != NULL) > + CHN_LOCK(wrch); > > switch(cmd) { > #ifdef OLDPCM_IOCTL > @@ -497,16 +500,12 @@ > p->play_size = 0; > p->rec_size = 0; > if (wrch) { > - CHN_LOCK(wrch); > chn_setblocksize(wrch, 2, p->play_size); > p->play_size = sndbuf_getblksz(wrch->bufsoft); > - CHN_UNLOCK(wrch); > } > if (rdch) { > - CHN_LOCK(rdch); > chn_setblocksize(rdch, 2, p->rec_size); > p->rec_size = sndbuf_getblksz(rdch->bufsoft); > - CHN_UNLOCK(rdch); > } > } > break; > @@ -526,16 +525,12 @@ > snd_chan_param *p = (snd_chan_param *)arg; > > if (wrch) { > - CHN_LOCK(wrch); > chn_setformat(wrch, p->play_format); > chn_setspeed(wrch, p->play_rate); > - CHN_UNLOCK(wrch); > } > if (rdch) { > - CHN_LOCK(rdch); > chn_setformat(rdch, p->rec_format); > chn_setspeed(rdch, p->rec_rate); > - CHN_UNLOCK(rdch); > } > } > /* FALLTHROUGH */ > @@ -557,14 +552,10 @@ > struct pcmchan_caps *pcaps = NULL, *rcaps = NULL; > dev_t pdev; > > - if (rdch) { > - CHN_LOCK(rdch); > + if (rdch) > rcaps = chn_getcaps(rdch); > - } > - if (wrch) { > - CHN_LOCK(wrch); > + if (wrch) > pcaps = chn_getcaps(wrch); > - } > p->rate_min = max(rcaps? rcaps->minspeed : 0, > pcaps? pcaps->minspeed : 0); > p->rate_max = min(rcaps? rcaps->maxspeed : 1000000, > @@ -580,10 +571,6 @@ > p->mixers = 1; /* default: one mixer */ > p->inputs = pdev->si_drv1? mix_getdevs(pdev->si_drv1) : 0; > p->left = p->right = 100; > - if (wrch) > - CHN_UNLOCK(wrch); > - if (rdch) > - CHN_UNLOCK(rdch); > } > break; > > @@ -646,59 +633,42 @@ > > case SNDCTL_DSP_SETBLKSIZE: > RANGE(*arg_i, 16, 65536); > - if (wrch) { > - CHN_LOCK(wrch); > + if (wrch) > chn_setblocksize(wrch, 2, *arg_i); > - CHN_UNLOCK(wrch); > - } > - if (rdch) { > - CHN_LOCK(rdch); > + if (rdch) > chn_setblocksize(rdch, 2, *arg_i); > - CHN_UNLOCK(rdch); > - } > break; > > case SNDCTL_DSP_RESET: > DEB(printf("dsp reset\n")); > if (wrch) { > - CHN_LOCK(wrch); > chn_abort(wrch); > chn_resetbuf(wrch); > - CHN_UNLOCK(wrch); > } > if (rdch) { > - CHN_LOCK(rdch); > chn_abort(rdch); > chn_resetbuf(rdch); > - CHN_UNLOCK(rdch); > } > break; > > case SNDCTL_DSP_SYNC: > DEB(printf("dsp sync\n")); > /* chn_sync may sleep */ > - if (wrch) { > - CHN_LOCK(wrch); > + if (wrch) > chn_sync(wrch, sndbuf_getsize(wrch->bufsoft) - 4); > - CHN_UNLOCK(wrch); > - } > break; > > case SNDCTL_DSP_SPEED: > /* chn_setspeed may sleep */ > tmp = 0; > if (wrch) { > - CHN_LOCK(wrch); > ret = chn_setspeed(wrch, *arg_i); > tmp = wrch->speed; > - CHN_UNLOCK(wrch); > } > if (rdch && ret == 0) { > - CHN_LOCK(rdch); > ret = chn_setspeed(rdch, *arg_i); > if (tmp == 0) > tmp = rdch->speed; > - CHN_UNLOCK(rdch); > } > *arg_i = tmp; > break; > @@ -711,17 +681,13 @@ > tmp = -1; > *arg_i = (*arg_i)? AFMT_STEREO : 0; > if (wrch) { > - CHN_LOCK(wrch); > ret = chn_setformat(wrch, (wrch->format & ~AFMT_STEREO) | *arg_i); > tmp = (wrch->format & AFMT_STEREO)? 1 : 0; > - CHN_UNLOCK(wrch); > } > if (rdch && ret == 0) { > - CHN_LOCK(rdch); > ret = chn_setformat(rdch, (rdch->format & ~AFMT_STEREO) | *arg_i); > if (tmp == -1) > tmp = (rdch->format & AFMT_STEREO)? 1 : 0; > - CHN_UNLOCK(rdch); > } > *arg_i = tmp; > break; > @@ -732,22 +698,17 @@ > tmp = 0; > *arg_i = (*arg_i != 1)? AFMT_STEREO : 0; > if (wrch) { > - CHN_LOCK(wrch); > ret = chn_setformat(wrch, (wrch->format & ~AFMT_STEREO) | *arg_i); > tmp = (wrch->format & AFMT_STEREO)? 2 : 1; > - CHN_UNLOCK(wrch); > } > if (rdch && ret == 0) { > - CHN_LOCK(rdch); > ret = chn_setformat(rdch, (rdch->format & ~AFMT_STEREO) | *arg_i); > if (tmp == 0) > tmp = (rdch->format & AFMT_STEREO)? 2 : 1; > - CHN_UNLOCK(rdch); > } > *arg_i = tmp; > - } else { > + } else > *arg_i = ((wrch? wrch->format : rdch->format) & AFMT_STEREO)? 2 : 1; > - } > break; > > case SOUND_PCM_READ_CHANNELS: > @@ -763,17 +724,13 @@ > if ((*arg_i != AFMT_QUERY)) { > tmp = 0; > if (wrch) { > - CHN_LOCK(wrch); > ret = chn_setformat(wrch, (*arg_i) | (wrch->format & AFMT_STEREO)); > tmp = wrch->format & ~AFMT_STEREO; > - CHN_UNLOCK(wrch); > } > if (rdch && ret == 0) { > - CHN_LOCK(rdch); > ret = chn_setformat(rdch, (*arg_i) | (rdch->format & AFMT_STEREO)); > if (tmp == 0) > tmp = rdch->format & ~AFMT_STEREO; > - CHN_UNLOCK(rdch); > } > *arg_i = tmp; > } else > @@ -800,18 +757,14 @@ > > DEB(printf("SNDCTL_DSP_SETFRAGMENT %d frags, %d sz\n", maxfrags, fragsz)); > if (rdch) { > - CHN_LOCK(rdch); > ret = chn_setblocksize(rdch, maxfrags, fragsz); > maxfrags = sndbuf_getblkcnt(rdch->bufsoft); > fragsz = sndbuf_getblksz(rdch->bufsoft); > - CHN_UNLOCK(rdch); > } > if (wrch && ret == 0) { > - CHN_LOCK(wrch); > ret = chn_setblocksize(wrch, maxfrags, fragsz); > maxfrags = sndbuf_getblkcnt(wrch->bufsoft); > fragsz = sndbuf_getblksz(wrch->bufsoft); > - CHN_UNLOCK(wrch); > } > > fragln = 0; > @@ -830,12 +783,10 @@ > if (rdch) { > struct snd_dbuf *bs = rdch->bufsoft; > > - CHN_LOCK(rdch); > a->bytes = sndbuf_getready(bs); > a->fragments = a->bytes / sndbuf_getblksz(bs); > a->fragstotal = sndbuf_getblkcnt(bs); > a->fragsize = sndbuf_getblksz(bs); > - CHN_UNLOCK(rdch); > } > } > break; > @@ -847,13 +798,11 @@ > if (wrch) { > struct snd_dbuf *bs = wrch->bufsoft; > > - CHN_LOCK(wrch); > chn_wrupdate(wrch); > a->bytes = sndbuf_getfree(bs); > a->fragments = a->bytes / sndbuf_getblksz(bs); > a->fragstotal = sndbuf_getblkcnt(bs); > a->fragsize = sndbuf_getblksz(bs); > - CHN_UNLOCK(wrch); > } > } > break; > @@ -864,13 +813,11 @@ > if (rdch) { > struct snd_dbuf *bs = rdch->bufsoft; > > - CHN_LOCK(rdch); > chn_rdupdate(rdch); > a->bytes = sndbuf_gettotal(bs); > a->blocks = sndbuf_getblocks(bs) - rdch->blocks; > a->ptr = sndbuf_getreadyptr(bs); > rdch->blocks = sndbuf_getblocks(bs); > - CHN_UNLOCK(rdch); > } else > ret = EINVAL; > } > @@ -882,13 +829,11 @@ > if (wrch) { > struct snd_dbuf *bs = wrch->bufsoft; > > - CHN_LOCK(wrch); > chn_wrupdate(wrch); > a->bytes = sndbuf_gettotal(bs); > a->blocks = sndbuf_getblocks(bs) - wrch->blocks; > a->ptr = sndbuf_getreadyptr(bs); > wrch->blocks = sndbuf_getblocks(bs); > - CHN_UNLOCK(wrch); > } else > ret = EINVAL; > } > @@ -906,22 +851,18 @@ > > case SNDCTL_DSP_SETTRIGGER: > if (rdch) { > - CHN_LOCK(rdch); > rdch->flags &= ~(CHN_F_TRIGGERED | CHN_F_NOTRIGGER); > if (*arg_i & PCM_ENABLE_INPUT) > chn_start(rdch, 1); > else > rdch->flags |= CHN_F_NOTRIGGER; > - CHN_UNLOCK(rdch); > } > if (wrch) { > - CHN_LOCK(wrch); > wrch->flags &= ~(CHN_F_TRIGGERED | CHN_F_NOTRIGGER); > if (*arg_i & PCM_ENABLE_OUTPUT) > chn_start(wrch, 1); > else > wrch->flags |= CHN_F_NOTRIGGER; > - CHN_UNLOCK(wrch); > } > break; > > @@ -938,20 +879,16 @@ > struct snd_dbuf *b = wrch->bufhard; > struct snd_dbuf *bs = wrch->bufsoft; > > - CHN_LOCK(wrch); > chn_wrupdate(wrch); > *arg_i = sndbuf_getready(b) + sndbuf_getready(bs); > - CHN_UNLOCK(wrch); > } else > ret = EINVAL; > break; > > case SNDCTL_DSP_POST: > if (wrch) { > - CHN_LOCK(wrch); > wrch->flags &= ~CHN_F_NOTRIGGER; > chn_start(wrch, 1); > - CHN_UNLOCK(wrch); > } > break; > > @@ -969,6 +906,10 @@ > ret = EINVAL; > break; > } > + if (rdch != NULL) > + CHN_UNLOCK(rdch); > + if (wrch != NULL) > + CHN_UNLOCK(wrch); > relchns(i_dev, rdch, wrch, 0); > splx(s); > return ret; > Index: sys/dev/sound/pcm/sound.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/sound.c,v > retrieving revision 1.88 > diff -u -r1.88 sound.c > --- sys/dev/sound/pcm/sound.c 20 Jan 2004 03:58:57 -0000 1.88 > +++ sys/dev/sound/pcm/sound.c 20 Jan 2004 10:34:46 -0000 > @@ -75,7 +75,23 @@ > m = malloc(sizeof(*m), M_DEVBUF, M_WAITOK | M_ZERO); > if (m == NULL) > return NULL; > - mtx_init(m, desc, type, MTX_DEF | MTX_RECURSE); > + mtx_init(m, desc, type, MTX_DEF); > + return m; > +#else > + return (void *)0xcafebabe; > +#endif > +} > + > +void * > +snd_chnmtxcreate(const char *desc, const char *type) > +{ > +#ifdef USING_MUTEX > + struct mtx *m; > + > + m = malloc(sizeof(*m), M_DEVBUF, M_WAITOK | M_ZERO); > + if (m == NULL) > + return NULL; > + mtx_init(m, desc, type, MTX_DEF | MTX_DUPOK); > return m; > #else > return (void *)0xcafebabe; > @@ -188,13 +204,16 @@ > /* try to create a vchan */ > SLIST_FOREACH(sce, &d->channels, link) { > c = sce->channel; > + CHN_LOCK(c); > if (!SLIST_EMPTY(&c->children)) { > err = vchan_create(c); > + CHN_UNLOCK(c); > if (!err) > return pcm_chnalloc(d, direction, pid, -1); > else > device_printf(d->dev, "vchan_create(%s) == %d\n", c->name, err); > - } > + } else > + CHN_UNLOCK(c); > } > } > } > @@ -250,15 +269,19 @@ > if (num > 0 && d->vchancount == 0) { > SLIST_FOREACH(sce, &d->channels, link) { > c = sce->channel; > + CHN_LOCK(c); > if ((c->direction == PCMDIR_PLAY) && !(c->flags & CHN_F_BUSY)) { > c->flags |= CHN_F_BUSY; > err = vchan_create(c); > if (err) { > - device_printf(d->dev, "vchan_create(%s) == %d\n", c->name, err); > c->flags &= ~CHN_F_BUSY; > - } > + CHN_UNLOCK(c); > + device_printf(d->dev, "vchan_create(%s) == %d\n", c->name, err); > + } else > + CHN_UNLOCK(c); > return; > } > + CHN_UNLOCK(c); > } > } > if (num == 0 && d->vchancount > 0) { > @@ -313,7 +336,7 @@ > v = snd_maxautovchans; > error = sysctl_handle_int(oidp, &v, sizeof(v), req); > if (error == 0 && req->newptr != NULL) { > - if (v < 0 || v >= SND_MAXVCHANS) > + if (v < 0 || v >= SND_MAXVCHANS || pcm_devclass == NULL) > return EINVAL; > if (v != snd_maxautovchans) { > for (i = 0; i < devclass_get_maxunit(pcm_devclass); i++) { > @@ -529,20 +552,23 @@ > err = pcm_chn_add(d, ch); > if (err) { > device_printf(d->dev, "pcm_chn_add(%s) failed, err=%d\n", ch->name, err); > - snd_mtxunlock(d->lock); > pcm_chn_destroy(ch); > return err; > } > > + CHN_LOCK(ch); > if (snd_maxautovchans > 0 && (d->flags & SD_F_AUTOVCHAN) && > ch->direction == PCMDIR_PLAY && d->vchancount == 0) { > ch->flags |= CHN_F_BUSY; > err = vchan_create(ch); > if (err) { > - device_printf(d->dev, "vchan_create(%s) == %d\n", ch->name, err); > ch->flags &= ~CHN_F_BUSY; > + CHN_UNLOCK(ch); > + device_printf(d->dev, "vchan_create(%s) == %d\n", ch->name, err); > + return err; > } > } > + CHN_UNLOCK(ch); > > return err; > } > @@ -866,11 +892,13 @@ > cnt = 0; > SLIST_FOREACH(sce, &d->channels, link) { > c = sce->channel; > + CHN_LOCK(c); > if ((c->direction == PCMDIR_PLAY) && (c->flags & CHN_F_VIRTUAL)) { > cnt++; > if (c->flags & CHN_F_BUSY) > busy++; > } > + CHN_UNLOCK(c); > } > > newcnt = cnt; > @@ -888,23 +916,28 @@ > /* add new vchans - find a parent channel first */ > SLIST_FOREACH(sce, &d->channels, link) { > c = sce->channel; > + CHN_LOCK(c); > /* not a candidate if not a play channel */ > if (c->direction != PCMDIR_PLAY) > - continue; > + goto next; > /* not a candidate if a virtual channel */ > if (c->flags & CHN_F_VIRTUAL) > - continue; > + goto next; > /* not a candidate if it's in use */ > - if ((c->flags & CHN_F_BUSY) && (SLIST_EMPTY(&c->children))) > - continue; > - /* > - * if we get here we're a nonvirtual play channel, and either > - * 1) not busy > - * 2) busy with children, not directly open > - * > - * thus we can add children > - */ > - goto addok; > + if (!(c->flags & CHN_F_BUSY) || > + !(SLIST_EMPTY(&c->children))) > + /* > + * if we get here we're a nonvirtual > + * play channel, and either > + * 1) not busy > + * 2) busy with children, not directly > + * open > + * > + * thus we can add children > + */ > + goto addok; > +next: > + CHN_UNLOCK(c); > } > pcm_inprog(d, -1); > return EBUSY; > @@ -917,6 +950,7 @@ > } > if (SLIST_EMPTY(&c->children)) > c->flags &= ~CHN_F_BUSY; > + CHN_UNLOCK(c); > } else if (newcnt < cnt) { > if (busy > newcnt) { > printf("cnt %d, newcnt %d, busy %d\n", cnt, newcnt, busy); > @@ -928,13 +962,17 @@ > while (err == 0 && newcnt < cnt) { > SLIST_FOREACH(sce, &d->channels, link) { > c = sce->channel; > + CHN_LOCK(c); > if ((c->flags & (CHN_F_BUSY | CHN_F_VIRTUAL)) == CHN_F_VIRTUAL) > goto remok; > + > + CHN_UNLOCK(c); > } > snd_mtxunlock(d->lock); > pcm_inprog(d, -1); > return EINVAL; > remok: > + CHN_UNLOCK(c); > err = vchan_destroy(c); > if (err == 0) > cnt--; > Index: sys/dev/sound/pcm/sound.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/sound.h,v > retrieving revision 1.54 > diff -u -r1.54 sound.h > --- sys/dev/sound/pcm/sound.h 20 Jan 2004 03:58:57 -0000 1.54 > +++ sys/dev/sound/pcm/sound.h 20 Jan 2004 10:34:46 -0000 > @@ -238,6 +238,7 @@ > driver_intr_t hand, void *param, void **cookiep); > > void *snd_mtxcreate(const char *desc, const char *type); > +void *snd_chnmtxcreate(const char *desc, const char *type); > void snd_mtxfree(void *m); > void snd_mtxassert(void *m); > #define snd_mtxlock(m) mtx_lock(m) > Index: sys/dev/sound/pcm/vchan.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sound/pcm/vchan.c,v > retrieving revision 1.15 > diff -u -r1.15 vchan.c > --- sys/dev/sound/pcm/vchan.c 20 Jan 2004 03:58:57 -0000 1.15 > +++ sys/dev/sound/pcm/vchan.c 25 Jan 2004 01:54:21 -0000 > @@ -77,7 +77,9 @@ > int16_t *tmp, *dst; > unsigned int cnt; > > - KASSERT(sndbuf_getsize(src) >= count, ("bad bufsize")); > + if (sndbuf_getsize(src) < count) > + panic("feed_vchan_s16(%s): tmp buffer size %d < count %d, flags = 0x%x", > + c->name, sndbuf_getsize(src), count, c->flags); > count &= ~1; > bzero(b, count); > > @@ -92,12 +94,14 @@ > bzero(tmp, count); > SLIST_FOREACH(cce, &c->children, link) { > ch = cce->channel; > + CHN_LOCK(ch); > if (ch->flags & CHN_F_TRIGGERED) { > if (ch->flags & CHN_F_MAPPED) > sndbuf_acquire(ch->bufsoft, NULL, sndbuf_getfree(ch->bufsoft)); > cnt = FEEDER_FEED(ch->feeder, ch, (u_int8_t *)tmp, count, ch->bufsoft); > vchan_mix_s16(dst, tmp, cnt / 2); > } > + CHN_UNLOCK(ch); > } > > return count; > @@ -145,13 +149,16 @@ > { > struct vchinfo *ch = data; > struct pcm_channel *parent = ch->parent; > + struct pcm_channel *channel = ch->channel; > > ch->fmt = format; > ch->bps = 1; > ch->bps <<= (ch->fmt & AFMT_STEREO)? 1 : 0; > ch->bps <<= (ch->fmt & AFMT_16BIT)? 1 : 0; > ch->bps <<= (ch->fmt & AFMT_32BIT)? 2 : 0; > + CHN_UNLOCK(channel); > chn_notify(parent, CHN_N_FORMAT); > + CHN_LOCK(channel); > return 0; > } > > @@ -160,9 +167,12 @@ > { > struct vchinfo *ch = data; > struct pcm_channel *parent = ch->parent; > + struct pcm_channel *channel = ch->channel; > > ch->spd = speed; > + CHN_UNLOCK(channel); > chn_notify(parent, CHN_N_RATE); > + CHN_LOCK(channel); > return speed; > } > > @@ -171,14 +181,19 @@ > { > struct vchinfo *ch = data; > struct pcm_channel *parent = ch->parent; > + struct pcm_channel *channel = ch->channel; > int prate, crate; > > ch->blksz = blocksize; > + CHN_UNLOCK(channel); > chn_notify(parent, CHN_N_BLOCKSIZE); > + CHN_LOCK(parent); > + CHN_LOCK(channel); > > crate = ch->spd * ch->bps; > prate = sndbuf_getspd(parent->bufhard) * sndbuf_getbps(parent->bufhard); > blocksize = sndbuf_getblksz(parent->bufhard); > + CHN_UNLOCK(parent); > blocksize *= prate; > blocksize /= crate; > > @@ -190,12 +205,15 @@ > { > struct vchinfo *ch = data; > struct pcm_channel *parent = ch->parent; > + struct pcm_channel *channel = ch->channel; > > if (go == PCMTRIG_EMLDMAWR || go == PCMTRIG_EMLDMARD) > return 0; > > ch->run = (go == PCMTRIG_START)? 1 : 0; > + CHN_UNLOCK(channel); > chn_notify(parent, CHN_N_TRIGGER); > + CHN_LOCK(channel); > > return 0; > } > @@ -235,8 +253,11 @@ > struct pcm_channel *child; > int err, first; > > + CHN_UNLOCK(parent); > + > pce = malloc(sizeof(*pce), M_DEVBUF, M_WAITOK | M_ZERO); > if (!pce) { > + CHN_LOCK(parent); > return ENOMEM; > } > > @@ -244,14 +265,13 @@ > child = pcm_chn_create(d, parent, &vchan_class, PCMDIR_VIRTUAL, parent); > if (!child) { > free(pce, M_DEVBUF); > + CHN_LOCK(parent); > return ENODEV; > } > > CHN_LOCK(parent); > - if (!(parent->flags & CHN_F_BUSY)) { > - CHN_UNLOCK(parent); > + if (!(parent->flags & CHN_F_BUSY)) > return EBUSY; > - } > > first = SLIST_EMPTY(&parent->children); > /* add us to our parent channel's children */ > @@ -269,6 +289,7 @@ > free(pce, M_DEVBUF); > } > > + CHN_LOCK(parent); > /* XXX gross ugly hack, murder death kill */ > if (first && !err) { > err = chn_reset(parent, AFMT_STEREO | AFMT_S16_LE); > > _______________________________________________ > 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" -- If you optimize everything, you will always be unhappy. - Don Knuth From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 10:30: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 15A8316A4CE for ; Sun, 25 Jan 2004 10:30:52 -0800 (PST) Received: from smtp2.sea.theriver.com (smtp2.sea.theriver.com [216.39.128.17]) by mx1.FreeBSD.org (Postfix) with SMTP id B599E43D45 for ; Sun, 25 Jan 2004 10:30:48 -0800 (PST) (envelope-from tponsford@theriver.com) Received: (qmail 27181 invoked from network); 25 Jan 2004 18:30:47 -0000 Received: from a48.tc43.theriver.com (HELO theriver.com) (tponsford@206.26.123.240) by smtp2.sea.theriver.com with SMTP; 25 Jan 2004 18:30:47 -0000 Message-ID: <4012B9A0.7020302@theriver.com> Date: Sat, 24 Jan 2004 11:29:52 -0700 From: Tom Ponsford User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030808 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <4011B6F6.5040306@theriver.com> <20040125115111.GN77998@cicely12.cicely.de> <20040125115741.GA86058@freebie.xs4all.nl> <20040125121318.GO77998@cicely12.cicely.de> In-Reply-To: <20040125121318.GO77998@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Same problem, new year 2100A machine check 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, 25 Jan 2004 18:30:52 -0000 Hi All, I did think of trying to dig up a EISA configuration utility to see if that may be the problem. It did however boot and run quite well under 4.xx on a uniprocessor kernel, without any reconfiguration of the EISA bus. Under 4.xx it also did a machine check under a SMP kernel. Apparently, the 2100A is quite an evil machine with it's split PCI bus, I did remove all PCI cards from the machine, as there were reports a machine checks with certain cards. Removing the all the cards had no effect, however. Bernd Walter wrote: > On Sun, Jan 25, 2004 at 12:57:41PM +0100, Wilko Bulte wrote: > >>On Sun, Jan 25, 2004 at 12:51:12PM +0100, Bernd Walter wrote: >> >>>On Fri, Jan 23, 2004 at 05:06:14PM -0700, Tom Ponsford wrote: >>> >>>>I decided to replace a disk on the ol' 2100A. I had been running VMS on it >>>>without any troubles, until a disk started giving me errors. After >>>>replacing the disk, I decided to give 5.2 a go, thinking maybe some of the >>>>problems of last year may have been resolved. >>>> >>>>No such luck. >> >>... >> >> >>>>unexpected machine check: >>>> >>>> mces = 0x1 >>>> vector = 0x670 >>>> param = 0xfffffc0000006000 >>>> pc = 0xfffffc00003b48d4 >>>> ra = 0xfffffc00003b4908 >>>> curproc = 0xfffffc0000810ee0 >>>> pid = 0, comm = swapper >>>> >>>>panic: machine check >>>>cpuid = 0; >>>>Uptime: 1s >>>>Automatic reboot in 15 seconds - press a key on the console to abort >>> >>>Maybe there is something wrong with the EISA configuration on your >>>machine. >> >>Hmm, could be. But 2100[a] are not really well supported/tested.. > > > It's mostly guessing, because it's probing the bridge and EISA support > is a difference between 4.x, which works acording to the originator. > From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 10:45: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 CB53016A4CE for ; Sun, 25 Jan 2004 10:45:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D85343D3F for ; Sun, 25 Jan 2004 10:45:36 -0800 (PST) (envelope-from sebastian.ssmoller@gmx.net) Received: (qmail 17543 invoked by uid 65534); 25 Jan 2004 18:45:34 -0000 Received: from pD9E81F62.dip.t-dialin.net (EHLO [217.232.31.98]) (217.232.31.98) by mail.gmx.net (mp026) with SMTP; 25 Jan 2004 19:45:34 +0100 X-Authenticated: #15005775 From: sebastian ssmoller To: Freebsd Current Content-Type: text/plain Message-Id: <1075056397.45058.55.camel@tyrael.linnet> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jan 2004 19:46:38 +0100 Content-Transfer-Encoding: 7bit Subject: panic: fatal trap 12 - inet6 ? 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, 25 Jan 2004 18:45:38 -0000 hi, recently i catched the following panic on my system : fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc05b4886 stack pointer = 0x10:0xd741ec94 frame pointer = 0x10:0xd741ecb0 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 = 28 (swi8: tty:sio clock) kernel: type 12 trap, code = 0 stopped at nd6_slowtimo+0x46: movl 0x8(%eax),%ebx db> where nd6_slowtimo(0,0,c06ad7e6,d9,1) at nd6_slowtimo+0x46 softclock ... ithread_loop ... fork_exit ... fork_trampoline ... $ uname -a FreeBSD tyrael.linnet 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Sun Jan 18 21:44:24 CET 2004 seb@tyrael.linnet:/usr/obj/usr/src-current/sys/DEBUG i386 $ nm /boot/kernel/kernel | grep c05b48 c05b48f0 T nd6_output c05b4840 t nd6_slowtimo this panic occured several times a day. it does not seem to make any difference whether there is high load on the system or not. i get the same error with and without acpi. first, i thought this was a hardware problem, so i changed some of my hw-components (vga, mem) and still got this error. then i found out that nd6_slowtimo has something to do with inet6. so i disabled "option INET6" in my kernel config - et voila my system runs stable (for several days) now. anyone similar problems - or is this a PR ? regards, seb From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:03: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 64B7916A4CF for ; Sun, 25 Jan 2004 11:03:11 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C9743D1F for ; Sun, 25 Jan 2004 11:03:10 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6E10972DBF; Sun, 25 Jan 2004 11:03:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6964872DB5; Sun, 25 Jan 2004 11:03:10 -0800 (PST) Date: Sun, 25 Jan 2004 11:03:10 -0800 (PST) From: Doug White To: alexis georges In-Reply-To: Message-ID: <20040125110103.T81485@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: kris@obsecurity.org Subject: Re: Timecounters and 5.2 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, 25 Jan 2004 19:03:11 -0000 On Tue, 20 Jan 2004, alexis georges wrote: > well, i could not read the stuff when doing boot -v, but i did it with no > acpi, and i attached the dmesg..also, when i do do the boot with acpi and > -v, the last line i get is : > > lo0: bpf attached > > there is no error i can see..just that the boot freezes (with the > Timecounters stuff as the last 2 lines).. Taking a look at my system, this is where the ATA and firewire probe happens. I've had hangs here if interrupts are broken. Its likely that ACPI on your system has bogus routing information and this causes ATA to hang. I didn't see if your system boots when ACPI is disabled. If it does, then, well, join the club :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:06: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 1FAB916A4CE for ; Sun, 25 Jan 2004 11:06:33 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06B4A43D1D for ; Sun, 25 Jan 2004 11:06:31 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i0PJ6HN1096873 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 25 Jan 2004 20:06:26 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i0PJ5uFq079174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2004 20:05:57 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i0PJ5uPw097807; Sun, 25 Jan 2004 20:05:56 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i0PJ5t8N097806; Sun, 25 Jan 2004 20:05:55 +0100 (CET) (envelope-from ticso) Date: Sun, 25 Jan 2004 20:05:54 +0100 From: Bernd Walter To: Tom Ponsford Message-ID: <20040125190553.GT77998@cicely12.cicely.de> References: <4011B6F6.5040306@theriver.com> <20040125115111.GN77998@cicely12.cicely.de> <20040125115741.GA86058@freebie.xs4all.nl> <20040125121318.GO77998@cicely12.cicely.de> <4012B9A0.7020302@theriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4012B9A0.7020302@theriver.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de Subject: Re: Same problem, new year 2100A machine check X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:06:33 -0000 On Sat, Jan 24, 2004 at 11:29:52AM -0700, Tom Ponsford wrote: > Hi All, > > I did think of trying to dig up a EISA configuration utility to see if that > may be the problem. It did however boot and run quite well under 4.xx on a > uniprocessor kernel, without any reconfiguration of the EISA bus. Under > 4.xx it also did a machine check under a SMP kernel. Apparently, the 2100A > is quite an evil machine with it's split PCI bus, I did remove all PCI > cards from the machine, as there were reports a machine checks with certain > cards. Removing the all the cards had no effect, however. GENERIC on 4.x is without EISA support. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:12: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 CD00616A4CE for ; Sun, 25 Jan 2004 11:12:23 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 853D043D49 for ; Sun, 25 Jan 2004 11:12:21 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6DB7172DC7; Sun, 25 Jan 2004 11:12:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6AC8272DBF; Sun, 25 Jan 2004 11:12:21 -0800 (PST) Date: Sun, 25 Jan 2004 11:12:21 -0800 (PST) From: Doug White To: Ken Smith In-Reply-To: <20040121141952.GA17839@electra.cse.Buffalo.EDU> Message-ID: <20040125110630.F81485@carver.gumbysoft.com> References: <1074659659.28370.10.camel@athena> <20040121141952.GA17839@electra.cse.Buffalo.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Mark Magnusson cc: freebsd-current@freebsd.org Subject: Re: Updating from 4.9-RELEASE 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, 25 Jan 2004 19:12:23 -0000 On Wed, 21 Jan 2004, Ken Smith wrote: > If I am remembering that right don't the statfs issues break that, > or at least make it something not to be attempted by mere mortals > and perhaps worth a mention in UPDATING? Its in UPDATING on -CURRENT. I guess we need to explicitly warn people to read the -CURRENT UPDATING and not the -STABLE one when planning their upgrade. This is in -CURRENT UPDATING: ****************************DANGER******************************* DO NOT make installworld after the buildworld w/o building and installing a new kernel FIRST. You will be unable to build a new kernel otherwise on a system with new binaries and an old kernel. Also see the section "To upgrade in-place from 4.x-stable to current" near the bottom of the file. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:19: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 D8B1816A4CE for ; Sun, 25 Jan 2004 11:19:34 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4DCB43D39 for ; Sun, 25 Jan 2004 11:19:31 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9DC6372DBF; Sun, 25 Jan 2004 11:19:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 929A472DB5; Sun, 25 Jan 2004 11:19:31 -0800 (PST) Date: Sun, 25 Jan 2004 11:19:31 -0800 (PST) From: Doug White To: Scott DF In-Reply-To: <400E8FBE.4070205@expertune.com> Message-ID: <20040125111641.B81485@carver.gumbysoft.com> References: <400E8FBE.4070205@expertune.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 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: Sun, 25 Jan 2004 19:19:35 -0000 On Wed, 21 Jan 2004, Scott DF wrote: > It was suggested I post to this list from Usenet CUBFM. Here is my post > to that list. > > --- original post --- > After upgrading from 5.1 to 5.2, I get a panic when I try to boot. I > can boot into single user mode, but a normal boot produces this: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x5d > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc059c4de > stack pointer = 0x10:02cbe61bbc > frame pointer = 0x10:0xcbe61bd4 > 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 = 508 (lkdload) The obvious thing that comes to mind here is a mismatched kernel module. Try inhibiting as many modules from loading as possible (boot single user if you have to), booting, then moving /boot/kernel out of the way (its a directory), then rebuild & reinstall the kernel again. Also move /modules out of the way since those aren't usable anymore. Is the NVidia module being used? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:24: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 7A5DE16A4CE for ; Sun, 25 Jan 2004 11:24:34 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8BF43D4C for ; Sun, 25 Jan 2004 11:24:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0PJOR82043730; Sun, 25 Jan 2004 11:24:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0PJOQva043727; Sun, 25 Jan 2004 11:24:26 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Jan 2004 11:24:26 -0800 (PST) From: Matthew Dillon Message-Id: <200401251924.i0PJOQva043727@apollo.backplane.com> To: Maxim Sobolev References: <4012806B.7090102@potentialtech.com> <4012AC47.4020409@portaone.com> cc: Bill Moran cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock 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: Sun, 25 Jan 2004 19:24:34 -0000 :I've ported PLL part (sys/i386/isa/clock.c change) and now I'm testing :it. I'll post the patch to this list once I will have finished. Right :now it works like a charm, but I need to get rid of the constant skew :introduced in tvtohz(). : :-Maxim Uh. It really wasn't meant to be ported. It was just some stopgap fun. The real 'solution' to the inconsistent sleep() delays is to not use 'tick' granularity for nanosleep() for small timing intervals or tail-end timing intervals. What you really want to do is bring in the variable-delay hardware timer interrupt abstraction that's going to go into DFly in the next week or so, but that will be a lot harder without the IPI messaging infrastructure. You'll have to wait, but I'll probably start posting test patches (for DFly) in one or two days once I get it working for SMP. Basically that abstraction will allow the kernel to 'register' multiple one-shot or periodic clock interrupt callbacks (with interrupt frame) on a per-cpu basis, which then in turn drives a variable load interrupt timer. At the moment I am using Timer0 for that and getting the time base from Timer2 (disabling the speaker). DFly is going to use this to 'register' periodic hardclock, statclock, and schedclock interrupts on a per-cpu basis. The idea will eventually to be to use the LAPIC in SMP systems to provide per-cpu clock interrupts but that's at least a few months away for us. Then, with that in hand, it would be possible to 'fix' nanosleep() to actually do a fine-grained sleep for the requested time period. A fine-grained nanosleep would be far more useful then a phase-synchronized tick timer. In anycase, watch for the patch sets. I think the abstraction will be portable to 5.x but you you will need to also port the IPI messaging code (which is itself an extremely useful abstraction and well worth the porting effort, IMHO). -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:28: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 8152316A4CE for ; Sun, 25 Jan 2004 11:28:41 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A2C143D5F for ; Sun, 25 Jan 2004 11:28:35 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5AE2C72DBF; Sun, 25 Jan 2004 11:28:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5911372DB5; Sun, 25 Jan 2004 11:28:35 -0800 (PST) Date: Sun, 25 Jan 2004 11:28:35 -0800 (PST) From: Doug White To: John In-Reply-To: <20040121200331.GA2006@mail.unixjunkie.com> Message-ID: <20040125112503.O81485@carver.gumbysoft.com> References: <20040121200331.GA2006@mail.unixjunkie.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.2R + ULE crash 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, 25 Jan 2004 19:28:41 -0000 On Wed, 21 Jan 2004, John wrote: > Well i'm kinda fly blind on the crash dump so if anyone else wants me to > show something else just let me know. > This happened on Day 4.5 of compiling Open Office 1.1. > I haven't touched much of anything else on the system after the > crash but i did have a power failure a day after the crash. > Oh btw /usr is also nfs exported on this box and i did have a client > using /usr at the time of the crash. (mounted via mount_nfs with no options) Does the machine have ECC memory? The panic location doesn't make a whole lot of sense -- its in the local apic management code. Looks like it got passed bogus data, two 0 arguments. Frame 11 is where the original trap occured, the rest is extra garbage. You might contact jhb@freebsd.org about this and see what you can extract. Considering the machine was running OK under load for several days, I'm thinking it may have been a memory error or possible overheat-type fluke. How well ventilated is the system? :) Make sure you forward your original message since I'm going to chop out a huge amound of your post for space savings. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:32: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 ED87516A4CE for ; Sun, 25 Jan 2004 11:32:46 -0800 (PST) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 988BC43D45 for ; Sun, 25 Jan 2004 11:32:35 -0800 (PST) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i0PJWYTr024739; Sun, 25 Jan 2004 14:32:34 -0500 (EST) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i0PJWYBo024738; Sun, 25 Jan 2004 14:32:34 -0500 (EST) Date: Sun, 25 Jan 2004 14:32:34 -0500 From: Ken Smith To: Doug White Message-ID: <20040125193234.GA24573@electra.cse.Buffalo.EDU> References: <1074659659.28370.10.camel@athena> <20040121141952.GA17839@electra.cse.Buffalo.EDU> <20040125110630.F81485@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125110630.F81485@carver.gumbysoft.com> User-Agent: Mutt/1.4.1i cc: Mark Magnusson cc: Ken Smith cc: freebsd-current@freebsd.org Subject: Re: Updating from 4.9-RELEASE 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, 25 Jan 2004 19:32:47 -0000 On Sun, Jan 25, 2004 at 11:12:21AM -0800, Doug White wrote: > Its in UPDATING on -CURRENT. I guess we need to explicitly warn people to > read the -CURRENT UPDATING and not the -STABLE one when planning their > upgrade. For what it's worth I was reading the right file. If you want to warn people about something warn them not to be afraid of doing something before they actually try it. :-( Booting a 5.X kernel in a 4.X world sounded scary but seems to have worked just fine. > Also see the section "To upgrade in-place from 4.x-stable to current" near > the bottom of the file. Missed that part completely. :-( Thanks. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:34: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 E75B016A4CE for ; Sun, 25 Jan 2004 11:34:07 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3459443D53 for ; Sun, 25 Jan 2004 11:34:06 -0800 (PST) (envelope-from sebastian.ssmoller@gmx.net) Received: (qmail 27960 invoked by uid 65534); 25 Jan 2004 19:34:04 -0000 Received: from pD9E837CF.dip.t-dialin.net (HELO hadriel.linnet) (217.232.55.207) by mail.gmx.net (mp025) with SMTP; 25 Jan 2004 20:34:04 +0100 X-Authenticated: #15005775 Date: Sun, 25 Jan 2004 20:34:56 +0100 From: sebastian ssmoller To: current@freebsd.org Message-Id: <20040125203456.7bfaa67b.sebastian.ssmoller@gmx.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: panic: m_copm, length > size of mbuf chain 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, 25 Jan 2004 19:34:08 -0000 hi, my system ran stable for several days now but suddenly this error occured. At this moment i did nothing special - just surfing the net ... cause i have no serial line attached i could only get the following infos: Debugger(...) at Debugger+0x54 panic(...) at panic+0xd5 m_copym(...) ip_fragment(...) ip_output(...) ip_forward(...) i didnt want to write down all these numbers(addresses) by hand, should i ? it seems to have to do something with inet/ip so i possibly should mention that i disabled "option inet6" in kernel and that i use "pf" as packet filter. $ uname -a FreeBSD tyrael.linnet 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Mon Jan 19 22:26:43 CET 2004 root@tyrael.linnet:/usr/obj/usr/src-current/sys/DEBUG i386 i can provide more info if needed... regards, seb From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:37: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 DD03916A4CE for ; Sun, 25 Jan 2004 11:37:22 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7189B43D2F for ; Sun, 25 Jan 2004 11:37:21 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6490472DC7; Sun, 25 Jan 2004 11:37:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6241572DBF; Sun, 25 Jan 2004 11:37:21 -0800 (PST) Date: Sun, 25 Jan 2004 11:37:21 -0800 (PST) From: Doug White To: "Paul R. Yaskowski" In-Reply-To: <20040122205958.AEDD243D1D@mx1.FreeBSD.org> Message-ID: <20040125113645.H81485@carver.gumbysoft.com> References: <20040122205958.AEDD243D1D@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.2-R Installation Issue 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, 25 Jan 2004 19:37:23 -0000 On Thu, 22 Jan 2004, Paul R. Yaskowski wrote: > My apologies if this is the wrong list. > > I've been having a long-standing issue installing 5.x onto a Dell PowerEdge > 600SC. As far as I can tell, my issue specifically relates to PR 54549, > http://www.freebsd.org/cgi/query-pr.cgi?pr=54549. > > 5.0-R and 5.1-R always paniced booting the first time off of the CD-ROM. > 5.2-R gets much further, but I still have some issues. The problem seems to > originate with the ATA controller, a ServerWorks CSB6 controller. I'm > getting the following kernel messages while booting the first time before > installation. Unfortunately the system doesn't respond to keystrokes > quickly, so these have been written down: > > -- > ata2-master: timeout sending command=ef > error issueing PIO command > error issuing ATA PACKET command > ata2-master: timeout sending command=a0 What happens if you boot without ACPI? I was about to suggest removing the cdrom drive, but you kinda need that. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:43: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 3986916A4CE for ; Sun, 25 Jan 2004 11:43:04 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E07143D39 for ; Sun, 25 Jan 2004 11:43:03 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5D72172DBF; Sun, 25 Jan 2004 11:43:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 593D672DB5; Sun, 25 Jan 2004 11:43:03 -0800 (PST) Date: Sun, 25 Jan 2004 11:43:03 -0800 (PST) From: Doug White To: Vanh Phom In-Reply-To: <1074858990.1399.17.camel@Supra> Message-ID: <20040125114141.I81485@carver.gumbysoft.com> References: <1074858990.1399.17.camel@Supra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Installing FreeBsd with X prob 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, 25 Jan 2004 19:43:04 -0000 On Fri, 23 Jan 2004, Vanh Phom wrote: > After spending the last couple days installing Freebsd. I managed to get > X up bare. Apparently the X server is up with a blank screen and no way > to shut it down. I'm trying to run kdm,sometime it would work if I cd to > /usr/local/bin and type kdm. Otherwise I got a blank screen. > Any help would be appreciated. By blank screen, you mean the crosshatch pattern with the X cursor? The normal way to start X up is using 'startx'. This arranges for a ~/.xinitrc script to run to start your window manager, or will start up a basic twm session if that file is not present. Also, if you need it, the X server kill key is Ctrl-Alt-Backspace. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:45: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 3E47616A4CF for ; Sun, 25 Jan 2004 11:45:20 -0800 (PST) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4417943D64 for ; Sun, 25 Jan 2004 11:45:05 -0800 (PST) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i0PJj4Tr024950; Sun, 25 Jan 2004 14:45:04 -0500 (EST) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i0PJj4oK024949; Sun, 25 Jan 2004 14:45:04 -0500 (EST) Date: Sun, 25 Jan 2004 14:45:04 -0500 From: Ken Smith To: Doug White Message-ID: <20040125194504.GA24783@electra.cse.Buffalo.EDU> References: <20040125110103.T81485@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125110103.T81485@carver.gumbysoft.com> User-Agent: Mutt/1.4.1i cc: alexis georges cc: freebsd-current@freebsd.org cc: kris@obsecurity.org Subject: Re: Timecounters and 5.2 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, 25 Jan 2004 19:45:20 -0000 On Sun, Jan 25, 2004 at 11:03:10AM -0800, Doug White wrote: > Taking a look at my system, this is where the ATA and firewire probe > happens. I've had hangs here if interrupts are broken. Its likely that > ACPI on your system has bogus routing information and this causes ATA to > hang. In case it helps at all, pluto2 (ia64 reference machine on the cluster) might be doing the same thing. For a kernel built Jan 22nd it wedges right after the timecounter messages. For a kernel built Jan 20th it seems to boot fine. The messages immediately after the timecounter messages for a successful boot are the ATA-attached DVD drive. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:47: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 AB4C716A4CE for ; Sun, 25 Jan 2004 11:47:33 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C45F43D2D for ; Sun, 25 Jan 2004 11:47:32 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5E37672DBF; Sun, 25 Jan 2004 11:47:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5956D72DB5; Sun, 25 Jan 2004 11:47:32 -0800 (PST) Date: Sun, 25 Jan 2004 11:47:32 -0800 (PST) From: Doug White To: Roberto Nunnari In-Reply-To: <40128AD4.9020401@supsi.ch> Message-ID: <20040125114516.Y81485@carver.gumbysoft.com> References: <400EC37A.6000505@supsi.ch> <20040123120622.C61090@carver.gumbysoft.com> <40128AD4.9020401@supsi.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: problem with scsi device 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, 25 Jan 2004 19:47:33 -0000 On Sat, 24 Jan 2004, Roberto Nunnari wrote: > Thanks for your reply. I was convinced that it was a hardware problem, too.. > ..so I installed another OS on that same machine.. just to > make sure it was a hardware problem.. big surprise! it worked > without a problem.. ..went back to FreeBSD and the problem > is again there.. > > Do you believe that even after that it could still be a hardware > problem? or a mix of hardware bug and software bug? May it be that > FreeBSD software uses some buggy hardware features that the other > OS just don't use? Thats entirely possible, or some other SCSI command triggers a firmware bug that makes the drive spaz out. We went around for 6+ months with SpetraLogic and Sony on a firmware problem on the AIT-2 drives that ADSM triggered. It pretty much came down to getting a SCSI recorder to see what the offending transactions were, getting that sent off to Sony, and Sony issuing a fix. By the time it got fixed, the company was in the process of being acquired, and that whole backup setup got repurposed. :) You might check if there is a firmware update for your drive. > > Doug White wrote: > > On Wed, 21 Jan 2004, Roberto Nunnari wrote: > > > > > >> Removable Sequential Access SCSI-3 device > > > > > >>it seams that if I use a new tape, then I can dump on it.. > >>but if I try to overwrite the tape, it starts behaving funny. > >>also.. anytime I try to write to a non new tape, it will > >>make errors and turn on the dirt led. > >>The result is that it's not possible to make any reliable > >>dump/restore on it. > >> > >>the tape drive is less than 1 year old and the tapes are > >>of good quality. > > > > > > My experience with this on DLT tapes is that this is caused by a damaged > > head assembly or something is seriously out of alignment. In other words, > > its not something you can fix. If it is less than a year old, then it > > should still be under warranty. I suggest you take advantage of that. > > > > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 11:52: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 7F31416A4F4 for ; Sun, 25 Jan 2004 11:52:32 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD28743D1F for ; Sun, 25 Jan 2004 11:52:30 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i0PJqOPf045945; Mon, 26 Jan 2004 06:52:24 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i0PJqOck045944; Mon, 26 Jan 2004 06:52:24 +1100 (EST) (envelope-from peter) Date: Mon, 26 Jan 2004 06:52:24 +1100 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20040125195224.GA45925@server.vk2pj.dyndns.org> References: <20040124074052.GA12597@cirb503493.alcatel.com.au> <20040125143203.G29442@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125143203.G29442@gamplex.bde.org> User-Agent: Mutt/1.4.1i Subject: Re: 80386 support in -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: Sun, 25 Jan 2004 19:52:32 -0000 On Sun, Jan 25, 2004 at 05:28:31PM +1100, Bruce Evans wrote: >SMP is now in GENERIC, so support for it is more important than when >I386_CPU was removed from GENERIC. > >The ifdef tangle for this stuff combined with lack of testing seems to >have broken the 386 support in practice. Interesting. Does anyone on this list actually use -CURRENT on a 386? Unfortunately(?) my 386 laptop died terminally some years ago (the HDD died and the BIOS only supports 80MB and 120MB HDDs) and my 386 motherboard collection got trashed last year as part of a move. > Libraries are now chummy with >the kernel implementation of atomic operations, but not chummy enough to >know when it actually works in userland. libthr uses the kernel >atomic_cmpset_*(), but this never works on plain i386's in userland >(the I386_CPU version doesn't work unless the application gains i/o >privilege since it uses cli/sti, and the !I386_CPU version doesn't >work because it uses cmpxchg). Is it time to bite the bullet and fully desupport the 80386? It looks like threads don't work and it's likely that other bitrot will set in in the absence of active testing. Peter From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 12:12:00 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 9DCD216A4CE; Sun, 25 Jan 2004 12:12:00 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD34B43D1F; Sun, 25 Jan 2004 12:11:59 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id AA71072DBF; Sun, 25 Jan 2004 12:11:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A586172DB5; Sun, 25 Jan 2004 12:11:59 -0800 (PST) Date: Sun, 25 Jan 2004 12:11:59 -0800 (PST) From: Doug White To: Sten Spans In-Reply-To: Message-ID: <20040125121101.Y81485@carver.gumbysoft.com> References: <20040125012602.XMOS163351.fep03-mail.bloor.is.net.cable.rogers.com@win2000> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Mike Jakubik cc: hardware@freebsd.org cc: current@freebsd.org Subject: Re: LSI MegaRAID SCSI 320-0 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, 25 Jan 2004 20:12:00 -0000 On Sun, 25 Jan 2004, Sten Spans wrote: > On Sat, 24 Jan 2004, Mike Jakubik wrote: > > > Does anyone know if the LSI Logic MegaRAID SCSI 320-0 Zero-channel > > (ZCR) Ultra320 SCSI RAID card is supported? I know the amr man page doesn't > > list the ZCR card specifically, but im hoping someone forgot to list it :) > > The serial ata raid cards ( Megaraid 150-x ) aint listed either but do > work with the amr driver. Well thats curious. The IBM X335 I've been playing with came with a SiI0680-based (parallel IDE) MegaRAID card. I figured ataraid would pick it up, but if it emulates a SCSI amr card, thats rather interesting. I'll have to experiment with that. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 12:14: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 E1E8C16A4CE for ; Sun, 25 Jan 2004 12:14:01 -0800 (PST) Received: from bim01.bimmer-edv.at (s1ip3.bimmer-edv.at [213.133.101.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8357C43D2F for ; Sun, 25 Jan 2004 12:13:59 -0800 (PST) (envelope-from freebsd.org@bimmer.at) Received: from localhost (bim01 [127.0.0.1]) by bim01.bimmer-edv.at (Postfix) with ESMTP id 477325F8076 for ; Sun, 25 Jan 2004 21:13:58 +0100 (CET) Received: from bim01.bimmer-edv.at ([127.0.0.1]) by localhost (bim01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29302-04 for ; Sun, 25 Jan 2004 21:13:27 +0100 (CET) Received: from chris (chello080110217205.114.11.wu-wien.teleweb.at [80.110.217.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by bim01.bimmer-edv.at (Postfix) with ESMTP id 775A35F8079 for ; Sun, 25 Jan 2004 21:13:20 +0100 (CET) From: "Christian B." To: Date: Sun, 25 Jan 2004 21:13:31 +0100 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.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPjfClYOR8IzwIITumVVvcuk8iplw== X-Virus-Scanned: by amavisd-new at bimmer-edv.at Subject: FreeBSD 5.2: malloc(): error: allocation failed 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, 25 Jan 2004 20:14:02 -0000 Hello, First, I have FreeBSD 5.1 installed on my dual-Xeon machine with 2GB RAM. Now, I delete the disk and installed FreeBSD 5.2 with the same ports and configuration. For the MySQL 4.0.17, I use following configuration (the same as under FreeBSD 5.1): ---------------------------------- key_buffer = 256M max_allowed_packet = 1M table_cache = 256 sort_buffer_size = 1M read_buffer_size = 1M myisam_sort_buffer_size = 64M thread_cache = 8 query_cache_size= 16M thread_concurrency = 4 max_connections = 2000 ---------------------------------- But after I start the mysql-server, I get following error: ---------------------------------- mysqld in malloc(): error: allocation failed mysqld got signal 6; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=1044480 max_used_connections=0 max_connections=2000 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 155824 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. ---------------------------------- If I reduce the key_buffer to 128M, mysql starts normal. So, I installed the Port "Memtest". But if I run it with more than 511MB ("memtest 512M 1"), I get the following error: ---------------------------------- Current limits: RLIMIT_RSS 0xffffffff RLIMIT_VMEM 0xffffffff Raising limits... memtest in malloc(): error: allocation failed Abort (core dumped) ---------------------------------- The output from top: ---------------------------------- 61 processes: 3 running, 48 sleeping, 10 waiting Mem: 76M Active, 12M Inact, 47M Wired, 16K Cache, 21M Buf, 1872M Free Swap: 5120M Total, 5120M Free ---------------------------------- I read the whole documentation about FreeBSD 5.2-update, but I cannot find any changes about the memory-functions. Can anyone say me, why I have problems with memory-allocation? Thanks for your help! Best regards, Christian From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 12:24: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 E9DBB16A4CE for ; Sun, 25 Jan 2004 12:24:28 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A64043D49 for ; Sun, 25 Jan 2004 12:24:27 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5BFCF72DBF; Sun, 25 Jan 2004 12:24:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5721F72DB5; Sun, 25 Jan 2004 12:24:27 -0800 (PST) Date: Sun, 25 Jan 2004 12:24:27 -0800 (PST) From: Doug White To: "Christian B." In-Reply-To: Message-ID: <20040125122226.J81485@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.2: malloc(): error: allocation failed 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, 25 Jan 2004 20:24:29 -0000 On Sun, 25 Jan 2004, Christian B. wrote: > First, I have FreeBSD 5.1 installed on my dual-Xeon machine with 2GB RAM. > Now, I delete the disk and installed FreeBSD 5.2 with the same ports and > configuration. Hm, you haven't been adjusting MAXDSIZ, have you? I've been getting this exact same error sequence when I set MAXDSIZ so big there was no space left for mmap() to work. In that case I was setting it to near 3GB. Are you setting any tuning option in loader.conf or with a custom kernel configuration? > > For the MySQL 4.0.17, I use following configuration (the same as under > FreeBSD 5.1): > ---------------------------------- > key_buffer = 256M > max_allowed_packet = 1M > table_cache = 256 > sort_buffer_size = 1M > read_buffer_size = 1M > myisam_sort_buffer_size = 64M > thread_cache = 8 > query_cache_size= 16M > thread_concurrency = 4 > max_connections = 2000 > ---------------------------------- > > But after I start the mysql-server, I get following error: > ---------------------------------- > mysqld in malloc(): error: allocation failed > mysqld got signal 6; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly built, > or misconfigured. This error can also be caused by malfunctioning hardware. > We will try our best to scrape up some info that will hopefully help > diagnose > the problem, but since we have already crashed, something is definitely > wrong > and this may fail. > > key_buffer_size=268435456 > read_buffer_size=1044480 > max_used_connections=0 > max_connections=2000 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 155824 > K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > ---------------------------------- > > If I reduce the key_buffer to 128M, mysql starts normal. > > > So, I installed the Port "Memtest". But if I run it with more than 511MB > ("memtest 512M 1"), I get the following error: > ---------------------------------- > Current limits: > RLIMIT_RSS 0xffffffff > RLIMIT_VMEM 0xffffffff > Raising limits... > memtest in malloc(): error: allocation failed > Abort (core dumped) > ---------------------------------- > > The output from top: > ---------------------------------- > 61 processes: 3 running, 48 sleeping, 10 waiting > Mem: 76M Active, 12M Inact, 47M Wired, 16K Cache, 21M Buf, 1872M Free > Swap: 5120M Total, 5120M Free > ---------------------------------- > > > I read the whole documentation about FreeBSD 5.2-update, but I cannot find > any changes about the memory-functions. > > Can anyone say me, why I have problems with memory-allocation? > > Thanks for your help! > > Best regards, > Christian > > _______________________________________________ > 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" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 12:52: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 AE86916A4CF for ; Sun, 25 Jan 2004 12:52:20 -0800 (PST) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E86E43D5D for ; Sun, 25 Jan 2004 12:51:30 -0800 (PST) (envelope-from conardcox@earthlink.net) Received: from rocket.leaguetrax.com. ([66.56.143.0])i0PKpRTe001212 for ; Sun, 25 Jan 2004 15:51:28 -0500 (EST) From: Richard Cox To: freebsd-current@freebsd.org Date: Sun, 25 Jan 2004 15:19:19 -0500 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401251519.19925.conardcox@earthlink.net> X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: devfs kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conardcox@earthlink.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 20:52:20 -0000 I was trying to get xine going on 5.2 Current and ran into a kernel panic. After a bit of investigating, I discovered I could reproduce the panic consistently just by trying to stat /dev/dsp1 (i.e., just an 'ls /dev/dsp1' will cause the kernel to panic). Here are the particulars, please let me know if there is any more information you would need to track this down: rocket:/usr/src/sys/fs/devfs]# kldstat Id Refs Address Size Name 1 11 0xc0400000 3a3d08 kernel 2 1 0xc07a4000 1ceac linux.ko 3 1 0xc07c1000 8744 snd_emu10k1.ko 4 2 0xc07ca000 1d5d8 snd_pcm.ko 5 1 0xc07e8000 1af00 radeon.ko 6 1 0xc0803000 4da2c acpi.ko gdb traceback: (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04ff58c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc04ff8ff in poweroff_wait (junk=0xc06b5e99, howto=821) at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0668d4d in trap_fatal (frame=0xc06ae406, eva=0) at /usr/src/sys/i386/i386/trap.c:821 #4 0xc0668a5c in trap_pfault (frame=0xe54769d8, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:735 #5 0xc066863c in trap (frame= {tf_fs = -448331752, tf_es = -1067253744, tf_ds = 16, tf_edi = 3, tf_esi = -448304353, tf_ebp = -448304552, tf_isp = -448304636, tf_ebx = 1, tf_edx = 0, tf_ecx = 1, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -969554095, tf_cs = 8, tf_eflags = 66118, tf_esp = -971754816, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:420 #6 0xc065b408 in calltrap () at {standard input}:94 #7 0xc04b2f94 in devfs_lookupx (ap=0x0) at /usr/src/sys/fs/devfs/devfs_vnops.c:386 #8 0xc04b32f3 in devfs_lookup (ap=0xe5476b88) at /usr/src/sys/fs/devfs/devfs_vnops.c:455 #9 0xc0551dac in lookup (ndp=0xe5476c28) at vnode_if.h:52 #10 0xc05517d4 in namei (ndp=0xe5476c28) at /usr/src/sys/kern/vfs_lookup.c:183 #11 0xc055f9a7 in lstat (td=0xc60febd0, uap=0xe5476d14) at /usr/src/sys/kern/vfs_syscalls.c:2036 #12 0xc06690c2 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134542080, tf_esi = 134542152, tf_ebp = -1077942680, tf_isp = -448303756, tf_ebx = 672751904, tf_edx = 134557824, tf_ecx = 0, tf_eax = 190, tf_trapno = 12, tf_err = 2, tf_eip = 672244687, tf_cs = 31, tf_eflags = 582, tf_esp = -1077942836, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1010 #13 0xc065b45d in Xint0x80_syscall () at {standard input}:136 dmesg output: 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.2-CURRENT #1: Sat Jan 24 13:06:57 EST 2004 root@rocket.leaguetrax.com:/usr/obj/usr/src/sys/ROCKET Preloaded elf kernel "/boot/kernel/kernel" at 0xc0852000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc0852294. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc0852340. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc08523f0. Preloaded elf module "/boot/kernel/radeon.ko" at 0xc085249c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0852548. module_register: module pci/DRIVER_NAME already exists! Module pci/DRIVER_NAME failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.20GHz (2193.35-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 1073479680 (1023 MB) avail memory = 1040945152 (992 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 13 entries at 0xc00f2aa0 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc224a180), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc224a280), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc224a280), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.PCI0 - AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc224a180), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc226d400), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc226d400), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.MEM_ - AE_AML_REGION_LIMIT acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib0: slot 31 INTD is routed to irq 5 pcib0: slot 31 INTB is routed to irq 10 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 drm0: port 0xc800-0xc8ff mem 0xff8f0000-0xff8fffff,0xe0000000-0xe7ffffff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized radeon 1.10.0 20020828 on minor 0 pcib2: at device 30.0 on pci0 pci2: on pcib2 pcib2: slot 1 INTA is routed to irq 5 pcib2: slot 1 INTB is routed to irq 3 pcib2: slot 1 INTC is routed to irq 9 pcib2: slot 8 INTA is routed to irq 11 pcib2: slot 10 INTA is routed to irq 11 pcib2: slot 11 INTA is routed to irq 9 pcib2: slot 12 INTA is routed to irq 10 pcib2: slot 13 INTA is routed to irq 11 ohci0: mem 0xff9fd000-0xff9fdfff irq 5 at device 1.0 on pci2 usb0: OHCI version 1.0 usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB Optical Mouse, rev 1.10/21.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ohci1: mem 0xff9fe000-0xff9fefff irq 3 at device 1.1 on pci2 usb1: OHCI version 1.0 usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci2: at device 1.2 (no driver attached) fxp0: port 0xdf00-0xdf3f mem 0xff9fc000-0xff9fcfff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:03:47:d3:fb:ac miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 10.0 (no driver attached) fwohci0: mem 0xff9f8000-0xff9fbfff,0xff9ff000-0xff9ff7ff irq 9 at device 11.0 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:05:3f:52:00:00:16:14 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:05:3f:00:16:14 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcm0: port 0xdf80-0xdf9f irq 10 at device 12.0 on pci2 pcm0: pci2: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xef80-0xef9f irq 5 at device 31.2 on pci0 usb2: on uhci0 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 acpi_cpu1: on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 pmtimer0 on isa0 orm0: