From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 01:43:42 2003 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 3831616A4CE; Sun, 9 Nov 2003 01:43:42 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C61FA43FD7; Sun, 9 Nov 2003 01:43:38 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id UAA29505; Sun, 9 Nov 2003 20:43:34 +1100 Date: Sun, 9 Nov 2003 20:43:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Don Lewis In-Reply-To: <200311090735.hA97ZLeF063127@gw.catspoiler.org> Message-ID: <20031109192046.L2537@gamplex.bde.org> References: <200311090735.hA97ZLeF063127@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: serial console oddity 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, 09 Nov 2003 09:43:42 -0000 On Sat, 8 Nov 2003, Don Lewis wrote: > I've been seeing some wierd things for many months when using a serial > console on my -CURRENT box. I finally had a chance to take a closer > look today. > > It looks like the problem is some sort of interference between kernel > output to the console and userland writes to /dev/console. I typically > see syslogd output to the console get corrupted. Each message that > syslogd writes seems to get truncated or otherwise corrupted. The most > common thing I see is that each syslog message is reduced to a space and > the first character of the month, or sometimes just a space, or > sometimes nothing at all. This is (at least primarily) a longstanding bug in ttymsg(). It uses nonblocking mode so that it doesn't block in write() or close(). For the same reason, it doesn't wait for output to drain before close(). If the close happens to be the last one on the device, this causes any data buffered in the tty and lower software layers to be discarded cleanly and any data in lower hardware layers to by discarded in a driver plus hardware-dependent way (usually not so cleanly, especially for the character being transmitted). > This is totally consistent until I "kill > -HUP" syslogd, which I believe causes syslogd to close and open > /dev/console, after which the syslog output appears correct on the > console. When the syslogd output is being corrupted, I can cat a file to > /dev/console and the output appears to be correct. When I debugged this, syslogd didn't seem to keep the console open, so the open()/close() in ttymsg() always caused the problem. I didn't notice killing syslogd makes a difference. Perhaps it helps due to a missing close. Holding the console open may be a workaround or even the correct fix. It's not clear where this should be done (should all clients of ttymsg() do it?). Running getty on the console or on the underlying tty device should do it accidentally. > I truss'ed syslogd, and it appears to be working normally, the writev() > call that writes the data to the console appears to be writing the > correct character count, so it would appear that the fault is in the > kernel. If there are any kernel bugs in this area, then they would be that last close of the console affects the underlying tty. The multiple console changes are quite likely to have broken this if getty is run on the underlying tty (they silently discarded the half-close of the underlying tty which was needed to avoided trashing some of its state when only the console is closed). > The problem doesn't appear to be specific to syslogd, because I have > seen the output from the shutdown scripts that goes to the console get > truncated as well. Yes, in theory it should affect anything that uses ttymsg() or does direct non-blocking writes without waiting for the output to drain. > I have my serial console running at the default 9600 bps. I always use 115200 bps and the symptoms are similar right down to normally getting only the first character of the month name followed by 0-1 bytes of garbage. The first character of the month name is just the first character of the message. Apparently my systems are fast enough for close() to be called before transmission of the second character has completed (2 * 87+ usec at 115200 bps). Here are some half-baked fixes. The part that clears O_NONBLOCK is wrong, and the usleep() part is obviously a hack. ttymsg() shouldn't block even in close(), since if the close is in the parent ttymsg() might block forever and if the close() is in a forked child then blocking could create zillions of blocked children. Another part of the patch is concerned with limiting forked children. If I were happy with that part then blocking would not be so bad. In practice, I don't have enough system activity for blocked children to be a problem. To see the problem with blocked children, do something like the following: - turn off clocal on the console so that the console can block better. For sio consoles this often requires turning it off in the lock-state device, since the driver defends against this foot shooting by locking it on. - hold the console open or otherwise avoid the original bug in this thread, else messages will just be discarded in close() faster than they can pile up. - turn off your external console device or otherwise drop carrier. - send lots of messages. %%% Index: ttymsg.c =================================================================== RCS file: /home/ncvs/src/usr.bin/wall/ttymsg.c,v retrieving revision 1.11 diff -u -2 -r1.11 ttymsg.c --- ttymsg.c 11 Oct 2002 14:58:34 -0000 1.11 +++ ttymsg.c 11 Oct 2002 18:13:51 -0000 @@ -32,14 +32,16 @@ */ -#include - -__FBSDID("$FreeBSD: src/usr.bin/wall/ttymsg.c,v 1.11 2002/10/11 14:58:34 mike Exp $"); - +#if 0 #ifndef lint -static const char sccsid[] = "@(#)ttymsg.c 8.2 (Berkeley) 11/16/93"; +static char sccsid[] = "@(#)ttymsg.c 8.2 (Berkeley) 11/16/93"; +#endif /* not lint */ #endif +#include +__FBSDID("$FreeBSD: src/usr.bin/wall/ttymsg.c,v 1.11 2002/10/11 14:58:34 mike Exp $"); + #include #include +#include #include #include @@ -66,8 +68,24 @@ struct iovec localiov[7]; ssize_t left, wret; - int cnt, fd; + static pid_t cpid; + pid_t pid; + int cnt, fd, forked, status; static char device[MAXNAMLEN] = _PATH_DEV; static char errbuf[1024]; - int forked; + + /* + * Don't do anything if a child is still alive. Interleaved + * output would not be good, and filling the process table with + * as many children as we can fork before the timeout kills them + * would be worse. Waiting here also reduces the need to handle + * SIGCHLD in callers. + */ + if (cpid) { + pid = waitpid(cpid, &status, WNOHANG); + if (pid == cpid || (pid == -1 || errno == ECHILD)) + cpid = 0; + else + return (NULL); + } forked = 0; @@ -121,6 +139,4 @@ } if (errno == EWOULDBLOCK) { - int cpid; - if (forked) { (void) close(fd); @@ -161,4 +177,8 @@ } + (void) fcntl(fd, F_SETFL, 0); /* Clear O_NONBLOCK. */ +#if 1 + usleep(100000); +#endif (void) close(fd); if (forked) %%% For a non-half-baked fix, do somethng like: - never block in ttymsg(), but always wait for output to drain using tcdrain() in a single child process. It's probably acceptable for this to not report errors to ttymsg()'s caller. - limit children better. I think we now fork children iff writev() returns EWOULDBLOCK and this happens mainly when the tty buffers fill up due to clocal being off and the external console not listening. Handling this right seems to require handing off the messages to a single child process that can buffer the messages in userland and can block writing and draining them. Blocked write()s and tcdrain()s are easy enough to handle in a specialized process by sending signals to abort them. Bruce From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 02:12:28 2003 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 69C2E16A4CE for ; Sun, 9 Nov 2003 02:12:28 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1938143F3F for ; Sun, 9 Nov 2003 02:12:27 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id hA9ACZwv080171; Sun, 9 Nov 2003 11:12:35 +0100 (CET) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.10/8.12.10/Submit) id hA9ACYO6080170; Sun, 9 Nov 2003 11:12:34 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200311091012.hA9ACYO6080170@spider.deepcore.dk> In-Reply-To: <20031108213139.8791C43FAF@mx1.FreeBSD.org> To: Peter Edwards Date: Sun, 9 Nov 2003 11:12:34 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: current@FreeBSD.ORG Subject: Re: ATAPI-CD corruption since GEOMification (& possible fix) 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, 09 Nov 2003 10:12:28 -0000 It seems Peter Edwards wrote: > With a -current built after atapi-cd was changed over to GEOM, reads > from a filesystem mounted on a CD device are being corrupted, with > junk being inserted into the file from offset 63489 onwards. > > I had a quick look around atapi-cd.c, and I think I spotted the > problem: applying this patch certainly stopped the corruption > I was seeing. Anyone else seeing this? Can someone verify that > this is indeed the correct fix? Yeps looks like what I intended, but apprarently didn't type :( Fix committed, thanks! -Søren From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 02:30:25 2003 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 A433E16A4CE for ; Sun, 9 Nov 2003 02:30:25 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADCF543FAF for ; Sun, 9 Nov 2003 02:30:24 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hA9AUGeF063359; Sun, 9 Nov 2003 02:30:21 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200311091030.hA9AUGeF063359@gw.catspoiler.org> Date: Sun, 9 Nov 2003 02:30:16 -0800 (PST) From: Don Lewis To: bde@zeta.org.au In-Reply-To: <20031109192046.L2537@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: serial console oddity 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, 09 Nov 2003 10:30:25 -0000 On 9 Nov, Bruce Evans wrote: > On Sat, 8 Nov 2003, Don Lewis wrote: > >> I've been seeing some wierd things for many months when using a serial >> console on my -CURRENT box. I finally had a chance to take a closer >> look today. >> >> It looks like the problem is some sort of interference between kernel >> output to the console and userland writes to /dev/console. I typically >> see syslogd output to the console get corrupted. Each message that >> syslogd writes seems to get truncated or otherwise corrupted. The most >> common thing I see is that each syslog message is reduced to a space and >> the first character of the month, or sometimes just a space, or >> sometimes nothing at all. > > This is (at least primarily) a longstanding bug in ttymsg(). It uses > nonblocking mode so that it doesn't block in write() or close(). For > the same reason, it doesn't wait for output to drain before close(). > If the close happens to be the last one on the device, this causes any > data buffered in the tty and lower software layers to be discarded > cleanly and any data in lower hardware layers to by discarded in a > driver plus hardware-dependent way (usually not so cleanly, especially > for the character being transmitted). I didn't think of a flush on close problem because I thought syslogd always kept the console open. >> This is totally consistent until I "kill >> -HUP" syslogd, which I believe causes syslogd to close and open >> /dev/console, after which the syslog output appears correct on the >> console. When the syslogd output is being corrupted, I can cat a file to >> /dev/console and the output appears to be correct. > > When I debugged this, syslogd didn't seem to keep the console open, > so the open()/close() in ttymsg() always caused the problem. I didn't > notice killing syslogd makes a difference. Perhaps it helps due to a > missing close. Holding the console open may be a workaround or even > the correct fix. It's not clear where this should be done (should all > clients of ttymsg() do it?). Running getty on the console or on the > underlying tty device should do it accidentally. It looks to me like syslogd keeps the console open in addition to the open()/close() in ttymsg(). cfline() calls open() on anything that begins with '/' and calls isatty() to figure out whether it should set the type to F_CONSOLE, F_TTY, or F_FILE, and init() closes the file descriptor for all of these when syslogd is HUPed. I wonder if the console descriptor is getting revoked ... >> I truss'ed syslogd, and it appears to be working normally, the writev() >> call that writes the data to the console appears to be writing the >> correct character count, so it would appear that the fault is in the >> kernel. > > If there are any kernel bugs in this area, then they would be that > last close of the console affects the underlying tty. The multiple > console changes are quite likely to have broken this if getty is run > on the underlying tty (they silently discarded the half-close of the > underlying tty which was needed to avoided trashing some of its state > when only the console is closed). I'm not running getty on my serial console. It is running on ttyv*. I'm only using the serial console to capture kernel stack traces, etc. >> The problem doesn't appear to be specific to syslogd, because I have >> seen the output from the shutdown scripts that goes to the console get >> truncated as well. > > Yes, in theory it should affect anything that uses ttymsg() or does > direct non-blocking writes without waiting for the output to drain. > Here are some half-baked fixes. The part that clears O_NONBLOCK is > wrong, and the usleep() part is obviously a hack. ttymsg() shouldn't > block even in close(), since if the close is in the parent ttymsg() > might block forever and if the close() is in a forked child then > blocking could create zillions of blocked children. > > Another part of the patch is concerned with limiting forked children. > If I were happy with that part then blocking would not be so bad. In > practice, I don't have enough system activity for blocked children to > be a problem. To see the problem with blocked children, do something > like the following: > - turn off clocal on the console so that the console can block better. > For sio consoles this often requires turning it off in the lock-state > device, since the driver defends against this foot shooting by locking > it on. > - hold the console open or otherwise avoid the original bug in this > thread, else messages will just be discarded in close() faster than > they can pile up. > - turn off your external console device or otherwise drop carrier. > - send lots of messages. I ran into this years ago when I was using actual terminals for console devices and someone typed a ^S and went away. The failure mode wasn't pretty. It was probably in the days when I was managing Masscomp boxes, but it might have been the first batch of Sun servers. > > For a non-half-baked fix, do somethng like: > - never block in ttymsg(), but always wait for output to drain using > tcdrain() in a single child process. It's probably acceptable for > this to not report errors to ttymsg()'s caller. > - limit children better. I think we now fork children iff writev() > returns EWOULDBLOCK and this happens mainly when the tty buffers > fill up due to clocal being off and the external console not > listening. Handling this right seems to require handing off the > messages to a single child process that can buffer the messages > in userland and can block writing and draining them. Blocked write()s > and tcdrain()s are easy enough to handle in a specialized process by > sending signals to abort them. I like this idea better. The userland process could be smart to drop entire lines of output if things started getting too backlogged. From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 04:52:13 2003 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 9CE2116A4CE for ; Sun, 9 Nov 2003 04:52:13 -0800 (PST) Received: from kundenserver16.yws-admin.de (kundenserver16.yws-admin.de [217.115.154.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ECFC4400D for ; Sun, 9 Nov 2003 04:52:12 -0800 (PST) (envelope-from flo@kasimir.com) Received: from kasimir.com (pD9FF4AF0.dip.t-dialin.net [217.255.74.240]) by kundenserver16.yws-admin.de (Postfix) with ESMTP id 43114352587; Sun, 9 Nov 2003 13:51:56 +0100 (CET) Message-ID: <3FAE3861.2030107@kasimir.com> Date: Sun, 09 Nov 2003 13:51:45 +0100 From: "Florian C. Smeets" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031021 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff References: <3FAD4885.4020404@kasimir.com> <20031108203717.GA2539@pit.databus.com> In-Reply-To: <20031108203717.GA2539@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: hard lockup with new interrupt code, possible cause irq14: ata0 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, 09 Nov 2003 12:52:13 -0000 Barney Wolff wrote: Hey Barney, > Try adding > options NO_MIXED_MODE > to your conf. That fixed boot-time hangs on my Asus A7M266-D. > Thanks for the reply but this didn't work for me. I'm goning to investigate further. Regards, flo From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 08:19:55 2003 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 E993616A4D0 for ; Sun, 9 Nov 2003 08:19:55 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3095D43FE0 for ; Sun, 9 Nov 2003 08:19:52 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 81579 invoked from network); 9 Nov 2003 16:22:38 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.148.7]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2003 16:22:38 -0000 Message-ID: <3FAE68FB.64D262FF@pipeline.ch> Date: Sun, 09 Nov 2003 17:19:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@errno.com cc: mb@imp.ch cc: ume@freebsd.org Subject: tcp hostcache and ip fastforward for review 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, 09 Nov 2003 16:19:56 -0000 Hello all, this patch contains three things (to be separated for committing): tcp_hostcache - removes protocol cloning from routing table (IPv4+6) - removes rtentry pointer from inpcb and in6pcb - removes ip route cache in ip_input.c (locking much easier) - removes most (tcp specific) metrics from rtentry metrics - adds a hostcache table which carries the metrics for tcp - works transparently for IPv4 and IPv6 - is designed for concurrent access in SMP environments - significant reduction of routing table size (no cloning anymore) - eases many routing table locking situations in ip/tcp code ip_fastforward - removes ip_flow forwarding code - adds full direct process-to-completion IPv4 forwarding code - handles ip fragmentation incl. hw support (ip_flow did not) - supports ipfw and ipfilter (ip_flow did not) - supports divert and ipfw fwd (ip_flow did not) - drops anything it can't handle back to normal ip_input tcp bug fixes and MSS DoS attack prevention - fixes wrong goto in tcp_input.c which sends two RST packets instead of one - adds tcp_minmss sysctl which limits the lowest MSS we accept during TCP setup and path MTU discovery - adds tcp_minmssoverload which disconnects a TCP session if it receives too many (1000) packets per second whose average segement size is lower than tcp_minmss - DoS attack 1: send very low MSS in syn to remote host, request large data stream (file) and let other host produce maaaany small packets which consumes a lot of CPU - DoS attack 2: make MSS very low on local side of connection and send maaaany small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. I'm looking for any comments, testing and bug reports (if any ;-). Hajimu-san, I'm looking especially for comments on whether my changes to IPv6 are correct wrt IPv6 concepts. (I hope they are). Hopefully these things can make it into -CURRENT before 5.2 release. Sam Leffler has indicated he is willing to commit it when there are no objections to the implementation and the code. I am fully committed to fix any bugs that might come up after it's in the tree. I am running my machines with these changes for a couple of weeks now without any problems. The attached patch obviously doesn't have that much exposure because I've had to update it all the time to track Sam's locking changes and UME's IPv6 updates. The patch is here (relative to -CURRENT as of 2003-11-09): http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch I'm grateful for everyone who tries out the patch and reports their success and/or other findings. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 09:05:27 2003 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 9971616A4CE for ; Sun, 9 Nov 2003 09:05:27 -0800 (PST) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5043B43FBF for ; Sun, 9 Nov 2003 09:05:26 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.10/8.12.10) with ESMTP id hA9H5FqT118454 for ; Sun, 9 Nov 2003 18:05:17 +0100 Date: Sun, 9 Nov 2003 18:05:06 +0100 (CET) From: Lukas Ertl To: current@freebsd.org Message-ID: <20031109175416.Y58774@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: mailbox 4246; Body=0 Fuz1=0 Fuz2=0 Subject: panic: Most recently used by mount 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, 09 Nov 2003 17:05:27 -0000 Hi, I get the following repeatable panic by just doing: # mount /cdrom when there's no disk in the drive. The panic doesn't happen immediately, the mount call returns and gives the error 'device not configured' (as it should), but if I wait some time, it panics. The system is: FreeBSD 5.1-CURRENT #4: Sat Nov 8 01:15:35 CET 2003 I somehow suspect the GEOMified SCSI CD driver, since I can do the same on my laptop (which has an IDE DVD-ROM) just fine. Attached is the backtrace and the dmesg. ---8<--- GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: Most recently used by mount panic messages: --- panic: Most recently used by mount Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug Reading symbols from /boot/kernel/daemon_saver.ko...done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/linux/linux.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04731cd in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xd3085778 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0472f6a in db_command (last_cmdp=0xc07891a0, cmd_table=0x0, aux_cmd_tablep=0xc0739b18, aux_cmd_tablep_end=0xc0739b1c) at /usr/src/sys/ddb/db_command.c:346 #3 0xc0473078 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472 #4 0xc0475db9 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73 #5 0xc06be632 in kdb_trap (type=3, code=0, regs=0xd30858b8) at /usr/src/sys/i386/i386/db_interface.c:171 #6 0xc06d0f2b in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1066205972, tf_ebp = -754427644, tf_isp = -754427676, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066669875, tf_cs = 8, tf_eflags = 642, tf_esp = -1066196186, tf_ss = -1066285008}) at /usr/src/sys/i386/i386/trap.c:580 #7 0xc06bff08 in calltrap () at {standard input}:94 #8 0xc057a37c in panic (fmt=0xc072fcec "Most recently used by %s\n") at /usr/src/sys/kern/kern_shutdown.c:534 #9 0xc069b377 in mtrash_ctor (mem=0xc2fe1800, size=0, arg=0x0) at /usr/src/sys/vm/uma_dbg.c:137 #10 0xc0699ca4 in uma_zalloc_arg (zone=0xc103acc0, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1413 #11 0xc056ef16 in malloc (size=3238243520, type=0xc0769c20, flags=2) at /usr/src/sys/vm/uma.h:234 #12 0xc0552881 in elf32_load_file (p=0xc2e9b3c8, file=0x0, addr=0xd3085a9c, entry=0x0, pagesize=4096) at /usr/src/sys/kern/imgact_elf.c:519 #13 0xc0553066 in exec_elf32_imgact (imgp=0xd3085b8c) at /usr/src/sys/kern/imgact_elf.c:825 #14 0xc05613cc in kern_execve (td=0xc2e9d140, fname=---Can't read userspace from dump, or kernel process---) at /usr/src/sys/kern/kern_exec.c:311 #15 0xc0561de0 in execve (td=0x0, uap=0x0) at /usr/src/sys/kern/kern_exec.c:695 #16 0xc06d17f2 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135278700, tf_esi = 135278752, tf_ebp = -1077941128, tf_isp = -754426508, tf_ebx = 0, tf_edx = -1077940370, tf_ecx = 135278639, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134716943,---Type to continue, or q to quit--- tf_cs = 31, tf_eflags = 646, tf_esp = -1077941156, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1010 #17 0xc06bff5d in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- ---8<--- ---8<--- Copyright (c) 1992-2003 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.1-CURRENT #4: Sat Nov 8 01:15:35 CET 2003 le@leelou:/usr/obj/usr/src/sys/LEELOU Preloaded elf kernel "/boot/kernel/kernel" at 0xc089f000. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Duron(tm) Processor (700.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183f9ff AMD Features=0xc0440000 real memory = 268369920 (255 MB) avail memory = 251052032 (239 MB) Pentium Pro MTRR support enabled acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fddd0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 8 INTA is routed to irq 10 pcib0: slot 9 INTA is routed to irq 9 pcib0: slot 13 INTA is routed to irq 11 pcib0: slot 15 INTA is routed to irq 11 agp0: mem 0xd0000000-0xd3ffffff 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 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xd400-0xd41f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: port 0xd800-0xd81f irq 10 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 rl0: port 0xdc00-0xdcff mem 0xdb000000-0xdb0000ff irq 10 at device 8.0 on pci0 rl0: Ethernet address: 00:30:4f:14:d1:cd miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vx0: <3COM 3C595 Etherlink III PCI> port 0xe000-0xe01f irq 9 at device 9.0 on pci0 utp/tx[*utp*] address 00:a0:24:9d:20:b7 pcm0: port 0xe400-0xe43f irq 11 at device 13.0 on pci0 ahc0: port 0xe800-0xe8ff mem 0xdb001000-0xdb001fff irq 11 at device 15.0 on pci0 aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs fdc0: port 0x3f7,0x3f0-0x3f5 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 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: &Y*8\)S0HFBHS=85&]^ED(#2@ MS5.Z_ZW>C'85B!>U"OY+$'GQEX&T7C-:!BAB8/T>[C"FHP$L77H=L'&9'CF-[`I?_HNV&+-9K^'"/UOS>;9A^'1%JLX?7'N8FKG M-7+[SSJH#\T^][D@HQY@%/]IPN;%*!^G<#:G_\"'PEP_JQ:/T<9NW'Z^F8[J M]Y[K_]E,=?,99W0="0>$]A?$`Z8!RE=F^84J\L$LL60)'=QE@4=[$SK`B&0+:4UI@C M&Y*]-OOUNR,I64EDUT&1;X6!(+3YG.Y(ZNYX=R2&*XKE>JT<+6,*+.(18'A5 MJH+==PK%3^2[XUH'+1Z?TC$;EJG>H%2'@N?_F2#G.H&-T2$]TV6>@6XM\+H? MI@Y+ET_V.,D,^,SVT#?]1CE>8I$=@&U[8AUKCH;;>S<^1E%XW2W#YAR/2#RAW^1>-0?Q$`HOI1.(Z(=)_D& M=CE8ZH01(E4"A*5TL'PPA86!K6UG+$A1C*MY52D>U,HP,[-"IYAL3E42E+AN M&ZR*$YE*(1TCEX&*!&#G4^,"``'/FS2^A\L4ZZ31P=SPL3W61%;5FC7?14;,)4VIIE>SM..:3K; MZ;CX#5$J2:3.9RA1S;.:\1W]32,,AQQC&&Y;QP6VY3XIM9&O;[S*E^ITOXJ/ M/*DJ6,V7F,Z>D:_I0X+UP)QL]'^V#4,(C_G-H[#)ZJ@WH#HP;0IK@-5FN0T& M:3H?!J,8'$O8.`!7H!!AWE-*TA50G`G;D]REFM:O%\-)&%T,[_J_=IGL M43I@(1WP,P(CV94&OB8-CC66V385\3DYXK[M>XQQK,S#5"TH&.YSQR:1A?O_ M"XLX@HPM(J'+N<$ZV+GLJ;`A`TV\6G\!;9EMX"W68XO@.B+P+F>MRU/:]S*QJTZ%8B M^%0T=`/\4L!1,RQ5^BG#<2F9I94G$1SX(XLL_XR)=@\FQK$I3$26I[KI.X+Y MK31X1:/J!_K'$,([O(3M4I)(.)Y+?=;.$)]69&@[O&K)=OCL!?S9@-3- M'<]/ZQ$Q?/)V/CPJ!86UMF,TLHI,U<^KR0B;4INZU#Z$'_%2H&<34S?;1T2D MKR!PI#PP&JB"B6XY?]!%$_08XX-_W`RO/YV0J'\>8(J!J@\'QY#LPT5AC*GU M]0:VM^-H/#0-,BB*9;$/V.@,5/!:+Y0LG:/VWX>[N1I.0!M.!E?J/L.DG`7< MM^@^B+ZD99E;NJ;)0F\#ZY%-BD07.BUGRA%+]Q%Z@_%[_`OGYLL8+-S!'_:I,QPK1)GY^\W>8'CH-C1ZQJ%/D#`-/DQ\12^33CU M0PC^_L-*G18`:ZU*Y!5,U6OK6%%`KD83G]V>P2/+U3HD1 M`:_VQS`:3JHUS:59T\W/3@K?T0L[4/N5P@Y0+:)Z>T1B[9[I5PS!VPW-C_'; M7(S9WL%\_;(>K;(<3TU4[W7W;`_\YQKYN4:J-1)C+`7MA*I'O2^6#V1S7P8] MT$@][3UVE)-RAZ$"V,!IH](KI_.\AU]U+N?YYAL97+XGV;=L1KZ`K<'BCGD. ML`6&TA?S_&7L!X]6E%\",G](/F?FL$]AKE$ETT62_W-7)O_"'NE_OGXLX;%: "```` ` end ----Next_Part(Mon_Nov_10_21:39:37_2003_819)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=NEWJKPC11 # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.365 2002/09/27 19:09:21 sos Exp $ machine i386 #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident NEWCARD #To statically compile in device wiring instead of /boot/device.hints #hints "NEWCARD.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_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 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 # 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 acpi device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # 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) # 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 # Audio support #device pcm # 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 # 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 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 rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) 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 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. # 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 # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet # # ACPI support using the Intel ACPI Component Architecture reference # implementation. # # ACPI_DEBUG enables the use of the debug.acpi.level and debug.acpi.layer # kernel environment variables to select initial debugging levels for the # Intel ACPICA code. (Note that the Intel code must also have USE_DEBUGGER # defined when it is built). # #device acpica #options ACPI_DEBUG #options NETGRAPH #options NETGRAPH_BRIDGE #options NETGRAPH_ETHER #options NETGRAPH_SOCKET # # spic: Sony Programmable I/O controller (VAIO notebooks) #device spic # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) ----Next_Part(Mon_Nov_10_21:39:37_2003_819)---- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 04:50:18 2003 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 A754416A4CE for ; Mon, 10 Nov 2003 04:50:18 -0800 (PST) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A3C843F3F for ; Mon, 10 Nov 2003 04:50:17 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd08.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1AJBUd-0003zu-02; Mon, 10 Nov 2003 13:50:07 +0100 Received: from Andro-Beta.Leidinger.net (STUnD+ZpoesZjepa-zfxUs17S16MGf2bLDTwDohu4Ca0yRVv2adMcc@[80.131.123.151]) by fmrl08.sul.t-online.com with esmtp id 1AJBUJ-1CbCca0; Mon, 10 Nov 2003 13:49:47 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAACnhsm021462; Mon, 10 Nov 2003 13:49:44 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAACo2qu035833; Mon, 10 Nov 2003 13:50:02 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 13:50:02 +0100 From: Alexander Leidinger To: ticso@cicely.de Message-Id: <20031110135002.66055c17.Alexander@Leidinger.net> In-Reply-To: <20031110121911.GL16726@cicely12.cicely.de> References: <200311091924.hA9JOP7G073292@Andro-Beta.Leidinger.net> <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: STUnD+ZpoesZjepa-zfxUs17S16MGf2bLDTwDohu4Ca0yRVv2adMcc@t-dialin.net cc: ticso@cicely12.cicely.de cc: current@freebsd.org cc: Pav Lucistnik Subject: Re: New EHCI device ID X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 12:50:18 -0000 On Mon, 10 Nov 2003 13:19:12 +0100 Bernd Walter wrote: > I really doubt that you have a high speed mouse. > EHCI only supports high speed devices itself. But it shouldn't stop the entire system if I attach an USB 1.1 mouse to an ehci controlled port. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 04:55:49 2003 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 C0BD416A4CE for ; Mon, 10 Nov 2003 04:55:49 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A37B43F75 for ; Mon, 10 Nov 2003 04:55:46 -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) hAACtft2072270 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 10 Nov 2003 13:55:43 +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 hAACte2q033862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 13:55:40 +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 hAACtd2u021203; Mon, 10 Nov 2003 13:55:39 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id hAACtduh021202; Mon, 10 Nov 2003 13:55:39 +0100 (CET) (envelope-from ticso) Date: Mon, 10 Nov 2003 13:55:39 +0100 From: Bernd Walter To: Alexander Leidinger Message-ID: <20031110125538.GP16726@cicely12.cicely.de> References: <200311091924.hA9JOP7G073292@Andro-Beta.Leidinger.net> <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> <20031110135002.66055c17.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110135002.66055c17.Alexander@Leidinger.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: ticso@cicely12.cicely.de cc: current@freebsd.org cc: ticso@cicely.de cc: Pav Lucistnik Subject: Re: New EHCI device ID 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: Mon, 10 Nov 2003 12:55:49 -0000 On Mon, Nov 10, 2003 at 01:50:02PM +0100, Alexander Leidinger wrote: > On Mon, 10 Nov 2003 13:19:12 +0100 > Bernd Walter wrote: > > > I really doubt that you have a high speed mouse. > > EHCI only supports high speed devices itself. > > But it shouldn't stop the entire system if I attach an USB 1.1 mouse to > an ehci controlled port. But ehci doesn't control low/full speed ports. The physical ports are multiplexed between ehci and ohci/uhci ports. The switching is done without driver interaction. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 05:58:59 2003 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 7D64216A4CE; Mon, 10 Nov 2003 05:58:59 -0800 (PST) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83EF043FE1; Mon, 10 Nov 2003 05:58:57 -0800 (PST) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 92CF922827; Mon, 10 Nov 2003 14:58:55 +0100 (CET) Date: Mon, 10 Nov 2003 14:57:43 +0100 From: Dimitry Andric X-Mailer: The Bat! (v2.01.26) Business X-Priority: 3 (Normal) Message-ID: <18123090602.20031110145743@andric.com> To: Harti Brandt MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------12B10F2482AA0419D" cc: FreeBSD Current List Subject: Buildworld errors out on libbsnmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 13:58:59 -0000 ------------12B10F2482AA0419D Content-Type: multipart/mixed; boundary="----------701CF1A61C7D169B" ------------701CF1A61C7D169B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I was just building world after your recent commits of the libbsnmp stuff. This results in the following errors: --------------------------------------------------------------------- =3D=3D=3D> lib/libbsnmp/modules/snmp_mibII rm -f .depend mkdep -f .depend -a -I/usr/include/bsnmp -I/usr/src/lib/libbsnmp/modules= /snmp_mibII /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c /usr/src= /lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII= .c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_= mibII/mibII_ifmib.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../co= ntrib/bsnmp/snmp_mibII/mibII_ip.c /usr/src/lib/libbsnmp/modules/snmp_mibII/= ../../../../contrib/bsnmp/snmp_mibII/mibII_interfaces.c /usr/src/lib/libbsn= mp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_ipaddr.c /= usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibI= I/mibII_ifstack.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../cont= rib/bsnmp/snmp_mibII/mibII_rcvaddr.c /usr/src/lib/libbsnmp/modules/snmp_mib= II/../../../../contrib/bsnmp/snmp_mibII/mibII_nettomedia.c /usr/src/lib/lib= bsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_tcp.c /= usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibI= I/mibII_udp.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/= bsnmp/snmp_mibII/mibII_route.c /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:5:18: asn1.h: No such= file or directory /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:6:18: snmp.h: No such= file or directory /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:7:23: snmpagent.h: No= such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ifmib.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ip.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_interfaces.c:= 37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ipaddr.c:40: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ifstack.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_rcvaddr.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_nettomedia.c:= 42: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_tcp.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_udp.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_route.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or di= rectory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or= directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libbsnmp/modules/snmp_mibII. *** Error code 1 Stop in /usr/src/lib/libbsnmp/modules. *** Error code 1 Stop in /usr/src/lib/libbsnmp. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --------------------------------------------------------------------- It seems that the depend stage assumes that the bsnmp include files are already in /usr/include, but since I don't have these yet, it fails. Of course I could first make install them, but I hope that the attached patch is a better fix: it uses include paths directly in the src/contrib/bsnmp tree. This should also prevent usage of outdated headers when building. If you have any questions about how I got the above errors, please let me know. You might be able to reproduce them by simply removing your /usr/include/bsnmp dir before building world. ------------701CF1A61C7D169B Content-Type: application/octet-stream; name="libbsnmp.diff" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="libbsnmp.diff" ZGlmZiAtdWQgbGliL2xpYmJzbm1wL21vZHVsZXMvc25tcF9taWJJSS9NYWtlZmlsZS5vcmcg bGliL2xpYmJzbm1wL21vZHVsZXMvc25tcF9taWJJSS9NYWtlZmlsZQotLS0gbGliL2xpYmJz bm1wL21vZHVsZXMvc25tcF9taWJJSS9NYWtlZmlsZS5vcmcJTW9uIE5vdiAxMCAxMDoxNzoz MyAyMDAzCisrKyBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX21pYklJL01ha2VmaWxlCU1v biBOb3YgMTAgMTQ6Mjk6MzEgMjAwMwpAQCAtNCw2ICs0LDggQEAKIAogQ09OVFJJQj0key5D VVJESVJ9Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYnNubXAvc25tcF9taWJJSQogLlBBVEg6ICR7 Q09OVFJJQn0KK1NOTVBMSUI9JHsuQ1VSRElSfS8uLi8uLi8uLi8uLi9jb250cmliL2Jzbm1w L2xpYgorU05NUE1PRD0key5DVVJESVJ9Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYnNubXAvc25t cGQKIAogTU9EPQltaWJJSQogU1JDUz0JbWliSUkuYyBtaWJJSV9pZm1pYi5jIG1pYklJX2lw LmMgbWliSUlfaW50ZXJmYWNlcy5jCQlcCkBAIC0xNCw2ICsxNiw2IEBACiBERUZTPQkke01P RH1fdHJlZS5kZWYKIElOQ1M9CXNubXBfJHtNT0R9LmgKIAotQ0ZMQUdTKz0gLUkke0lOQ0xV REVESVJ9L2Jzbm1wIC1JJHsuQ1VSRElSfQorQ0ZMQUdTKz0gLUkke1NOTVBMSUJ9IC1JJHtT Tk1QTU9EfSAtSSR7Q09OVFJJQn0gLUkkey5DVVJESVJ9CiAKIC5pbmNsdWRlIDxic2QubGli Lm1rPgpkaWZmIC11ZCBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX25ldGdyYXBoL01ha2Vm aWxlLm9yZyBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX25ldGdyYXBoL01ha2VmaWxlCi0t LSBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX25ldGdyYXBoL01ha2VmaWxlLm9yZwlNb24g Tm92IDEwIDEwOjE3OjM0IDIwMDMKKysrIGxpYi9saWJic25tcC9tb2R1bGVzL3NubXBfbmV0 Z3JhcGgvTWFrZWZpbGUJTW9uIE5vdiAxMCAxNDozMzowOSAyMDAzCkBAIC0yLDYgKzIsMTAg QEAKICMKICMgQXV0aG9yOiBIYXJ0aSBCcmFuZHQgPGhhcnRpQGZyZWVic2Qub3JnPgogCitT Tk1QTElCPSR7LkNVUkRJUn0vLi4vLi4vLi4vLi4vY29udHJpYi9ic25tcC9saWIKK1NOTVBN SUI9JHsuQ1VSRElSfS8uLi8uLi8uLi8uLi9jb250cmliL2Jzbm1wL3NubXBfbWliSUkKK1NO TVBNT0Q9JHsuQ1VSRElSfS8uLi8uLi8uLi8uLi9jb250cmliL2Jzbm1wL3NubXBkCisKIE1P RD0JbmV0Z3JhcGgKIFNSQ1M9CXNubXBfbmV0Z3JhcGguYwogTUFOPQlzbm1wX25ldGdyYXBo LjMKQEAgLTEwLDYgKzE0LDYgQEAKIERFRlM9CSR7TU9EfV90cmVlLmRlZgogSU5DUz0Jc25t cF8ke01PRH0uaAogCi1DRkxBR1MrPSAtSSR7SU5DTFVERURJUn0vYnNubXAgLUkkey5DVVJE SVJ9CitDRkxBR1MrPSAtSSR7U05NUExJQn0gLUkke1NOTVBNSUJ9IC1JJHtTTk1QTU9EfSAt SSR7LkNVUkRJUn0KIAogLmluY2x1ZGUgPGJzZC5saWIubWs+Cg== ------------701CF1A61C7D169B-- ------------12B10F2482AA0419D Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQE/r5lWsF6jCi4glqMRAr6wAKCfQvFI1aH74/1tR9sJ3oRcgodhYgCfV5Xl 3whv4ger0IIxH0E4arMAX88= =6jb4 -----END PGP MESSAGE----- ------------12B10F2482AA0419D-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 06:02:09 2003 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 5946616A4CE for ; Mon, 10 Nov 2003 06:02:09 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DA2343F85 for ; Mon, 10 Nov 2003 06:02:07 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hAAE26U24197; Mon, 10 Nov 2003 15:02:06 +0100 (MET) Date: Mon, 10 Nov 2003 15:02:06 +0100 (CET) From: Harti Brandt To: Dimitry Andric In-Reply-To: <18123090602.20031110145743@andric.com> Message-ID: <20031110150043.T29745@beagle.fokus.fraunhofer.de> References: <18123090602.20031110145743@andric.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Current List Subject: Re: Buildworld errors out on libbsnmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 14:02:09 -0000 On Mon, 10 Nov 2003, Dimitry Andric wrote: DA>Hi, DA> DA>I was just building world after your recent commits of the libbsnmp DA>stuff. This results in the following errors: Sorry, that was my error. I have committed a fix for the library, one for the daemon follows in a couple of minutes as soon as I have verified that it builds the universe. harti From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 06:21:09 2003 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 B9FB916A4D4; Mon, 10 Nov 2003 06:21:09 -0800 (PST) Received: from home2.morten-johansen.net (213.234.112.58.adsl.o-d.tiscali.no [213.234.112.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC51043F85; Mon, 10 Nov 2003 06:21:07 -0800 (PST) (envelope-from mail@morten-johansen.net) Received: from morten-johansen.net (localhost [127.0.0.1]) hAAEL3xX000654; Mon, 10 Nov 2003 15:21:05 +0100 (CET) (envelope-from mail@morten-johansen.net) Message-ID: <3FAF9ECF.6020204@morten-johansen.net> Date: Mon, 10 Nov 2003 15:21:03 +0100 From: Morten Johansen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030817 X-Accept-Language: no, nb, en-us, en MIME-Version: 1.0 To: Bruce Evans References: <3FA966B2.9040704@morten-johansen.net> <20031105202947.A43448@pooker.samsco.home> <3FAAF50B.9030105@morten-johansen.net> <20031107230107.O3769@gamplex.bde.org> <3FACB0DC.7020802@freebsd.org> <3FACEC1B.2040903@morten-johansen.net> <20031110205212.V2817@gamplex.bde.org> In-Reply-To: <20031110205212.V2817@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: the PS/2 mouse problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 14:21:09 -0000 Bruce Evans wrote: > On Sat, 8 Nov 2003, Morten Johansen wrote: > > >>Scott Long wrote: >> >>>Bruce Evans wrote: >>> >>>>[... possibly too much trimmed] >>> >>>The problem here is that the keyboard controller driver tries to be too >>>smart. If it detects that the hardware FIFO is full, it'll drain it into >>>a per-softc, per-function ring buffer. So having psm(4) just directly >>>read the hardware is insufficient in this scheme. > > > What is the per-function part? (I'm not very familar with psm, but once > understood simpler versions of the keyboard driver.) Several layers of > buffering might not be too bad for slow devices. The i/o times tend to > dominate unless you do silly things like a context switch to move each > character from one buffer to other, and even that can be fast enough > (I believe it is normal for interactive input on ptys; then there's often > a remote IPC or two per character as well). > > >>>>- it sometimes calls the DELAY() function, which is not permitted in fast >>>> interrupt handlers since apart from locking issues, fast interrupt >>>>handlers >>>> are not permitted to busy-wait. >>> >>>Again, the keyboard controller driver is too smart for its own good. To >>>summarize: >>> >>>read_aux_data_no_wait() >>>{ >>> Does softc->aux ring buffer contain data? >>> return ring buffer data >>> >>> Check the status register >>> Is the keyboard fifo full? >>> DELAY(7us) >>> read keyboard fifo into softc->kbd ring buffer >>> Check the status register >>> >>> Is the aux fifo full? >>> DELAY(7us) >>> return aux fifo data >>>} >>> >>>So you can wind up stalling for 14us in there, presumably because you >>>cannot read the status and data registers back-to-back without a delay. >>>I don't have the atkbd spec handy so I'm not sure how to optimize this. >>>Do you really need to check the status register before reading the data >>>register? > > > At least it's a bounded delay. I believe such delays are required for > some layers of the keyboard. Perhaps only for the keyboard (old hardware > only?) and not for the keyboard controller or the mouse. > > >>>>Many of the complications for fast interrupt handlers shouldn't be needed >>>>in psm. Just make psmintr() INTR_MPSAFE. >>> >>>I believe that the previous poster actually tried making it INTR_MPSAFE, >>>but didn't see a measurable benefit because the latency of scheduling >>>the ithread is still unacceptable. >> >>That is 100% correct. >>In the meantime I have taken your's and Bruce's advice and rearranged >>the interrupt handler to look like this: >> >>mtx_lock(&sc->input_mtx); > > > Er, this is reasonable for INTR_MPSAFE but not for INTR_FAST. > mtx_lock() is a "sleep" lock so it cannot be used in fast interrupt > handlers. mtx_lock_spin() must be used. (My version doesn't permit > use of mtx_lock_spin() either; more primitive locking must be used.) > > >>while((c = read_aux_data_no_wait(sc->kbdc)) != -1) { > > > This is probably INTR_FAST-safe enough in practice. > > >> sc->input_queue.buf[sc->input_queue.tail] = c; >> if ((++ sc->input_queue.tail) >= PSM_BUFSIZE) >> sc->input_queue.tail = 0; >> count = (++ sc->input_queue.count); >>} >>mtx_unlock(&sc->input_mtx); > > > The locking for the queue seems to be correct except this should operate > on a spinlock too. > > >>if (count >= sc->mode.packetsize) >> taskqueue_enqueue(taskqueue_swi_giant, &sc->psm_task); > > > taskqueue_enqueue() can only be used in non-fast interrupt handlers. > taskqueue_enqueue_fast() must be used in fast interrupt handlers (except > in my version, it is not permitted so it shouldn't exist). Note that > the spinlock/fast versions can be used for normal interrupt handlers > too, so not much more code is needed to support handlers whose fastness > is dynamically configured. > Yes, I have submitted a PR (kern/59067), with an INTR_FAST version that uses spinlocks and taskqueue_fast. You can find it here if you have time to look at it: http://dsm.oslonett.no/patch-psm-fast I would appreciate comments on it's correctness. > >>And it works, but having it INTR_MPSAFE still does NOT help my problem. >>It looks to me like data is getting lost because the interrupt handler >>is unable to read it before it's gone, and the driver gets out of sync, >>and has to reset itself. >>However it now takes a few more tries to provoke the problem, so >>something seems to have improved somewhere. > > > This is a bit surprising. There are still so few INTR_MPSAFE handlers > that there aren't many system activities that get in the way of running > the INTR_MPSAFE ones. Shared interrupts prevent running of a handler > while other handlers on the same interrupt are running, and the mouse > interrupt is often shared, but if it is shared then it couldn't be fast > until recently and still can't be fast unless all the other handlers on > it are fast. > > Bruce It seems odd that it should be necessary to have it INTR_FAST. But somehow it is, on my system. Morten From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 06:42:05 2003 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 31E0216A4CE for ; Mon, 10 Nov 2003 06:42:05 -0800 (PST) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121EE43FDF for ; Mon, 10 Nov 2003 06:42:04 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by mailbox.univie.ac.at (8.12.10/8.12.10) with ESMTP id hAAEfwPj239654 for ; Mon, 10 Nov 2003 15:42:00 +0100 Date: Mon, 10 Nov 2003 15:41:57 +0100 (CET) From: Lukas Ertl To: current@freebsd.org Message-ID: <20031110153808.A22613@pcle2.cc.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: mx1 4261; Body=0 Fuz1=0 Fuz2=0 Subject: named pipes memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 14:42:05 -0000 Hi, is there a known problem with named pipes in -CURRENT? The following shell script freezes a machine in several minutes and needs a power cycle. You can see the increasing memory in vmstat -z (unpcb) and netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003. ---8<--- #/bin/sh FIFO=/tmp/foo for i in `jot 50000 1`; do mkfifo ${FIFO} echo blubb > ${FIFO} & kill $! rm ${FIFO} done ---8<--- regards, le -- Lukas Ertl eMail: l.ertl@univie.ac.at UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 06:50:15 2003 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 8A28716A4CE; Mon, 10 Nov 2003 06:50:15 -0800 (PST) Received: from womble.xtaz.co.uk (82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27DF243FB1; Mon, 10 Nov 2003 06:50:14 -0800 (PST) (envelope-from matt@xtaz.co.uk) Received: from xtaz.co.uk (localhost [127.0.0.1]) by womble.xtaz.co.uk (Postfix) with ESMTP id A41A7902D9; Mon, 10 Nov 2003 14:50:11 +0000 (GMT) Message-ID: <3FAFA5A3.3000704@xtaz.co.uk> Date: Mon, 10 Nov 2003 14:50:11 +0000 From: Matt Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson , Soren Schmidt References: <3FA22395.3000907@xtaz.co.uk> In-Reply-To: <3FA22395.3000907@xtaz.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 14:50:15 -0000 With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I just got the lockup again now whilst it downloaded p5-Net-DNS to portupgrade into /usr/ports/distfiles. This is a very small file but it was enough to trigger it off. So it doesn't look like a size related issue either as I can download around 4% of mysql before it locks up. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. As a start here is the relevent parts of my dmesg to show the NIC's I'm using. I wonder if this corresponds to sorens? NFS CLIENT (xl1 would be the card it's using to talk to the server): xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem 0xea000000-0xea00007f irq 12 at device 15.0 on pci0 xl0: Ethernet address: 00:a0:24:ac:e1:b4 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: <3Com 3c905-TX Fast Etherlink XL> port 0xe800-0xe83f irq 11 at device 17.0 on pci0 xl1: Ethernet address: 00:60:08:6d:1e:3b miibus1: on xl1 nsphy0: on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto NFS SERVER: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Both connected to a 100meg full duplex switch. Any ideas? As I have said I'm happy to enable some major debugging etc. But I just need somebody to give me a step by step guide for what to do and look for. In case this thread is too old now and nobody remembers anything about it the previous email regarding it is at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1183410+0+archive/2003/freebsd-current/20031102.freebsd-current Regards, Matt. From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 06:54:44 2003 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 780AC16A4CE for ; Mon, 10 Nov 2003 06:54:44 -0800 (PST) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1368B43FAF for ; Mon, 10 Nov 2003 06:54:42 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd08.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AJDQv-0005gN-04; Mon, 10 Nov 2003 15:54:25 +0100 Received: from Andro-Beta.Leidinger.net (XjjfzTZ6ge6ADG9Wn4ZAETTi6wuVYCiEBHWsNH1d3+z9Pm5rRBqTY9@[80.131.123.151]) by fmrl08.sul.t-online.com with esmtp id 1AJDQZ-2E6wyW0; Mon, 10 Nov 2003 15:54:03 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAAEs3sm038991; Mon, 10 Nov 2003 15:54:03 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAAEsNbV001704; Mon, 10 Nov 2003 15:54:23 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 15:54:23 +0100 From: Alexander Leidinger To: ticso@cicely.de Message-Id: <20031110155423.1bb0b145.Alexander@Leidinger.net> In-Reply-To: <20031110125538.GP16726@cicely12.cicely.de> References: <200311091924.hA9JOP7G073292@Andro-Beta.Leidinger.net> <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> <20031110135002.66055c17.Alexander@Leidinger.net> <20031110125538.GP16726@cicely12.cicely.de> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: XjjfzTZ6ge6ADG9Wn4ZAETTi6wuVYCiEBHWsNH1d3+z9Pm5rRBqTY9@t-dialin.net cc: current@freebsd.org Subject: Re: New EHCI device ID X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 14:54:44 -0000 On Mon, 10 Nov 2003 13:55:39 +0100 Bernd Walter wrote: > But ehci doesn't control low/full speed ports. > The physical ports are multiplexed between ehci and ohci/uhci ports. > The switching is done without driver interaction. Attached to the port is a uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered on this hub is a ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. This is from the dmesg of my desktop system (USB 1.1 only). If I attach this combo to the other system ehci tells me: ---snip--- usb4: unrevoerable error, controller halted usb4: blocking intrs 0x10 ---snip-- and stopps booting further. The usb part of the dmesg without anything attached: ---snip--- # dmesg |grep -E '(usb|hci|uhub)' uhci0: port 0xbc00-0xbc1f irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb400-0xb41f irq 18 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xb800-0xb81f irq 16 at device 29.3 on pci0 usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfc000000-0xfc0003ff irq 23 at device 29.7 on pci0 ehci0: (New EHCI DeviceId=0x24dd8086) ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ---snip--- Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:03:11 2003 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 8D2B816A4D5; Mon, 10 Nov 2003 07:03:11 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2870143F75; Mon, 10 Nov 2003 07:03:10 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id hAAF3mEQ005453; Mon, 10 Nov 2003 16:03:48 +0100 (CET) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.10/8.12.10/Submit) id hAAF3lbV005452; Mon, 10 Nov 2003 16:03:48 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200311101503.hAAF3lbV005452@spider.deepcore.dk> In-Reply-To: <3FAFA5A3.3000704@xtaz.co.uk> To: Matt Smith Date: Mon, 10 Nov 2003 16:03:47 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: Robert Watson cc: current@FreeBSD.ORG Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 15:03:11 -0000 It seems Matt Smith wrote: > With a current build from november the 9th I am still getting exactly > the same NFS lockups. I assume soren is as well. NFS has basically been > pretty unusable now for over a month. Yes I do, NFS is virtually useless... > As only a couple of people have complained about this from what I can > see I assume it is something related to something specific such as a > network card? Could be, but its more than one type of card which suggests to me its more "generic" in origin.. > From my testing I only get this lockup when writing to the server. > Reading from the server works perfectly all the time. So luckily I can > still manage an NFS mounted installworld/kernel. I can also lock it up with just reading, but it takes longer. > Obviously we should really try and find the cause of this before 5.2. I > am willing to try any patches/debug on my systems. But I just have zero > clue about what to look for myself. I think its a definite showstopper for 5.2 actually.. > NFS SERVER: > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem > 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 > xl0: Ethernet address: 00:04:76:8d:c5:fd > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto OK the worst server I've got has: re0: port 0xdc00-0xdcff mem 0xe4000000-0xe40000ff irq 12 at device 9.0 on pci0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re1: port 0xe000-0xe0ff mem 0xe4001000-0xe40010ff irq 10 at device 10.0 on pci0 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2: port 0xe400-0xe4ff mem 0xe4002000-0xe40020ff irq 11 at device 11.0 on pci0 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto The clients use fxp/xl/sis cards and can all make this server hang in seconds.. -Søren From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:11:41 2003 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 43F5716A4CE for ; Mon, 10 Nov 2003 07:11:41 -0800 (PST) Received: from mx.upsys.se (mx.upsys.se [194.52.52.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id C090244056 for ; Mon, 10 Nov 2003 07:11:01 -0800 (PST) (envelope-from seger@upsys.se) Received: from postis.upsys.se ([194.52.52.68]) by mx.upsys.se with esmtp (Exim 4.22) id 1AJDgw-000Bju-65 for freebsd-current@freebsd.org; Mon, 10 Nov 2003 16:10:58 +0100 Received: from laptoya.upsys.se (vampyr12.upsys.se [192.168.2.139]) by postis.upsys.se (8.11.6/8.11.6) with ESMTP id hAAFAuT45660 for ; Mon, 10 Nov 2003 16:10:57 +0100 (CET) (envelope-from seger@upsys.se) From: Nils Segerdahl To: freebsd-current@freebsd.org Date: Mon, 10 Nov 2003 16:10:53 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311101610.53858.seger@upsys.se> Subject: Kernel halt when connecting re0 to the lan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 15:11:41 -0000 Problem: when connecting my laptop (Compaq evo N1020v) to the network, the kernel ha= lts=20 right after execution of re_diag() in the re-device driver. The loopback test fails. The interface works ok if I remove the test from the driver, or if I use=20 another operating system. It used to work perfect with 4.8-STABLE. Any suggestions? =46rom dmesg: re0: port 0x9000-0x90ff mem=20 0xf0019800-0xf00198ff=20 irq 11 at device 11.0 on pci0 re0: Ethernet address: 00:08:02:d6:bf:cd miibus0: on re0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Best reg. Nils S. =20 Nils Segerdahl From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:19:36 2003 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 B260916A4CE for ; Mon, 10 Nov 2003 07:19:36 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB4F643FBF for ; Mon, 10 Nov 2003 07:19:34 -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) hAAFJUt2073807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 10 Nov 2003 16:19:32 +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 hAAFJS2q034611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 16:19:28 +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 hAAFJS2u021734; Mon, 10 Nov 2003 16:19:28 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id hAAFJS1H021733; Mon, 10 Nov 2003 16:19:28 +0100 (CET) (envelope-from ticso) Date: Mon, 10 Nov 2003 16:19:27 +0100 From: Bernd Walter To: Alexander Leidinger Message-ID: <20031110151927.GT16726@cicely12.cicely.de> References: <200311091924.hA9JOP7G073292@Andro-Beta.Leidinger.net> <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> <20031110135002.66055c17.Alexander@Leidinger.net> <20031110125538.GP16726@cicely12.cicely.de> <20031110155423.1bb0b145.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110155423.1bb0b145.Alexander@Leidinger.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: ticso@cicely.de cc: current@freebsd.org Subject: Re: New EHCI device ID 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: Mon, 10 Nov 2003 15:19:36 -0000 On Mon, Nov 10, 2003 at 03:54:23PM +0100, Alexander Leidinger wrote: > On Mon, 10 Nov 2003 13:55:39 +0100 > Bernd Walter wrote: > > > But ehci doesn't control low/full speed ports. > > The physical ports are multiplexed between ehci and ohci/uhci ports. > > The switching is done without driver interaction. > > Attached to the port is a > > uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 > uhub1: 4 ports with 4 removable, self powered USB2 hubs are currently not supported with high speed uplinks. That's the reason why there is no EHCI support in GENERIC. EHCI needs interrupt transfers first to support usb2.0 hubs at high speed uplinks with high speed devices. For low and full speed downlink we additionaly need speed conversion support in uhub code. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:32:58 2003 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 6727316A4CE for ; Mon, 10 Nov 2003 07:32:58 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E01F43FBF for ; Mon, 10 Nov 2003 07:32:56 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd00.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1AJE2B-000392-02; Mon, 10 Nov 2003 16:32:55 +0100 Received: from Andro-Beta.Leidinger.net (VTn0XTZQ8e8R9z2VhwEIkZ8guIVcw-AgFkqgOF5Zn0JBKOnJZiHXrW@[80.131.123.151]) by fmrl00.sul.t-online.com with esmtp id 1AJE1r-1Ohd5c0; Mon, 10 Nov 2003 16:32:35 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAAFWXsm044453 for ; Mon, 10 Nov 2003 16:32:34 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAAFWsbV006600 for ; Mon, 10 Nov 2003 16:32:54 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 16:32:54 +0100 From: Alexander Leidinger To: freebsd-current@freebsd.org Message-Id: <20031110163254.046a5a44.Alexander@Leidinger.net> In-Reply-To: <20031110121242.GA6807@lara.unibe.ch> References: <000501c3a743$3f4c7a90$ca00a8c0@michael> <000d01c3a74f$5e1252e0$ca00a8c0@michael> <20031110113541.1ad899ff.Alexander@Leidinger.net> <20031110104900.GO810@starjuice.net> <20031110121242.GA6807@lara.unibe.ch> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: VTn0XTZQ8e8R9z2VhwEIkZ8guIVcw-AgFkqgOF5Zn0JBKOnJZiHXrW@t-dialin.net Subject: Re: ALTQ 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: Mon, 10 Nov 2003 15:32:58 -0000 On Mon, 10 Nov 2003 13:12:42 +0100 Tobias Roth wrote: > the author of altq itself or the author of the freebsd port? I don't know the who's who, but I think it was the author of altq itself. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:35:31 2003 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 C537A16A4D0 for ; Mon, 10 Nov 2003 07:35:31 -0800 (PST) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9414243FA3 for ; Mon, 10 Nov 2003 07:35:30 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd06.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1AJE4d-0004WD-08; Mon, 10 Nov 2003 16:35:27 +0100 Received: from Andro-Beta.Leidinger.net (rfv6DgZroeRupCeertz7ejejP5lShi2VZZP39gbT85swhGMjYn5zs1@[80.131.123.151]) by fmrl06.sul.t-online.com with esmtp id 1AJE4O-1Et5rE0; Mon, 10 Nov 2003 16:35:12 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAAFZAsm044809; Mon, 10 Nov 2003 16:35:10 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAAFZVbV006935; Mon, 10 Nov 2003 16:35:31 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 16:35:31 +0100 From: Alexander Leidinger To: ticso@cicely.de Message-Id: <20031110163531.4441f094.Alexander@Leidinger.net> In-Reply-To: <20031110151927.GT16726@cicely12.cicely.de> References: <200311091924.hA9JOP7G073292@Andro-Beta.Leidinger.net> <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> <20031110135002.66055c17.Alexander@Leidinger.net> <20031110125538.GP16726@cicely12.cicely.de> <20031110155423.1bb0b145.Alexander@Leidinger.net> <20031110151927.GT16726@cicely12.cicely.de> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: rfv6DgZroeRupCeertz7ejejP5lShi2VZZP39gbT85swhGMjYn5zs1@t-dialin.net cc: current@freebsd.org Subject: Re: New EHCI device ID X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 15:35:31 -0000 On Mon, 10 Nov 2003 16:19:27 +0100 Bernd Walter wrote: > USB2 hubs are currently not supported with high speed uplinks. > That's the reason why there is no EHCI support in GENERIC. > EHCI needs interrupt transfers first to support usb2.0 hubs at high > speed uplinks with high speed devices. > For low and full speed downlink we additionaly need speed conversion > support in uhub code. Is there an easy way of printing something like this instead of halting the system? Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:48:47 2003 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 7EC1D16A4CF for ; Mon, 10 Nov 2003 07:48:47 -0800 (PST) Received: from ns2.wananchi.com (ns2.wananchi.com [62.8.64.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC1343FE3 for ; Mon, 10 Nov 2003 07:48:43 -0800 (PST) (envelope-from wash@wananchi.com) Received: from wash by ns2.wananchi.com with local (Exim 4.24 #1 (FreeBSD 4.9)) id 1AJEHR-0006T4-0j by authid for ; Mon, 10 Nov 2003 18:48:41 +0300 Date: Mon, 10 Nov 2003 18:48:40 +0300 From: Odhiambo Washington To: current@freebsd.org Message-ID: <20031110154840.GL12559@ns2.wananchi.com> Mail-Followup-To: Odhiambo Washington , current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Disclaimer: Any views expressed in this message,where not explicitly attributed otherwise, are mine alone!. X-Mailer: Mutt 1.5.4i (2003-03-19) X-Designation: Systems Administrator, Wananchi Online Ltd. X-Location: Nairobi, KE, East Africa. X-Uptime: 6:46PM up 2 days, 9:23, 2 users, load averages: 0.92, 2.84, 2.91 User-Agent: Mutt/1.5.4i Subject: buildworld error on 5.1-REL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 15:48:47 -0000 I am seeing the following error and no amount of cvsup will help it. http://ns2.wananchi.com/~wash/5.1-REL/WORLD.txt Advise appreciated. -Wash -- |\ _,,,---,,_ | Odhiambo Washington Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 + If time heals all wounds, how come the belly button stays the same? From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 07:57:27 2003 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 9B91416A4CF; Mon, 10 Nov 2003 07:57:27 -0800 (PST) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E6943FBD; Mon, 10 Nov 2003 07:57:25 -0800 (PST) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id MUA74016; Mon, 10 Nov 2003 07:57:24 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 48EE85D07; Mon, 10 Nov 2003 07:57:24 -0800 (PST) To: Scott Long In-Reply-To: Message from Scott Long of "Sun, 09 Nov 2003 22:43:47 MST." <3FAF2593.8020903@freebsd.org> Date: Mon, 10 Nov 2003 07:57:24 -0800 From: "Kevin Oberman" Message-Id: <20031110155724.48EE85D07@ptavv.es.net> cc: Robert Watson cc: current@freebsd.org Subject: Re: Kernel memory leak in ATAPI/CAM or ATAng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 15:57:27 -0000 > Date: Sun, 09 Nov 2003 22:43:47 -0700 > From: Scott Long > > Kevin Oberman wrote: > > Tested. It's much better, although ATA request keeps adding more > > memory all the time when mplayer is playing, but it's now increasing > > at about 20K/minute which is a huge improvement. Still, I don't > > understand why it should just continue to grow all of the time. The > > data rate is about constant. I would expect that it should grow to a > > size where the data being processed can be accommodated and then stop > > growing. I don't see it stopping. > > > > Thanks for the quick fix. > > Well, it sounds like there is still a memory leak somewhere. Make sure > that you have rev 1.27 of atapi-cam.c to be sure. If so, please let me > know which malloc type in vmstat -m is growing. Oh, crap! I guess I pulled the new version too quickly yesterday when your message arrived. I had 1.26. And I don't have a DVD with me, so I was seeing a much slower leak because the CD transfers data so much more slowly. After a kernel rebuild I see: ATA request 0 0K 1K 7285 128 after reading some bulk data off of a CD. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:00:46 2003 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 7D03416A4CE for ; Mon, 10 Nov 2003 08:00:46 -0800 (PST) Received: from swank.verbotenplanet.net (mail.verbotenplanet.net [207.99.115.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BC4143FE5 for ; Mon, 10 Nov 2003 08:00:45 -0800 (PST) (envelope-from schnozzy@verbotenplanet.net) Received: from www by swank.verbotenplanet.net with local (Exim 4.24; FreeBSD 4.9) id 1AJET2-000E9u-Sj for current@FreeBSD.ORG; Mon, 10 Nov 2003 11:00:40 -0500 From: "Kelley Reynolds" Date: Mon, 10 Nov 2003 11:00:40 -0500 To: current@FreeBSD.ORG In-Reply-To: <200311101503.hAAF3lbV005452@spider.deepcore.dk> Message-ID: <0.87229300.1068480040@verbotenplanet.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Content-Description: messagebody References: <200311101503.hAAF3lbV005452@spider.deepcore.dk> X-Mailer: ISMail (http://www.insidesystems.net/projects/project.php?projectid=4) X-Mailer-Version: v1.7.1 Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: schnozzy@verbotenplanet.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:00:46 -0000 --- Original Message --- From: Soren Schmidt Sent: Mon, 10 Nov 2003 16:03:47 +0100 (CET) To: Matt Smith Subject: Re: Still getting NFS client locking up > It seems Matt Smith wrote: > > With a current build from november the 9th I am still getting exactly > > the same NFS lockups. I assume soren is as well. NFS has basically been > > pretty unusable now for over a month. > > Yes I do, NFS is virtually useless... > > > As only a couple of people have complained about this from what I can > > see I assume it is something related to something specific such as a > > network card? > > Could be, but its more than one type of card which suggests to me > its more "generic" in origin.. > > > From my testing I only get this lockup when writing to the server. > > Reading from the server works perfectly all the time. So luckily I can > > still manage an NFS mounted installworld/kernel. > > I can also lock it up with just reading, but it takes longer. > > > Obviously we should really try and find the cause of this before 5.2. I > > am willing to try any patches/debug on my systems. But I just have zero > > clue about what to look for myself. > > I think its a definite showstopper for 5.2 actually.. > Just to add some more evidence to the mix, I have two 5.1 current boxes using bfe, vr, and both have ath, and I am experience all of the lockups on the server end... client has yet to lock up. Kelley From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:20:36 2003 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 6997816A4CE for ; Mon, 10 Nov 2003 08:20:36 -0800 (PST) Received: from mx7.mail.ru (mx7.mail.ru [194.67.23.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B123343F3F for ; Mon, 10 Nov 2003 08:20:35 -0800 (PST) (envelope-from xtremeinc@mail.ru) Received: from [213.252.64.162] (port=54675 helo=PC004.amvit.ru) by mx7.mail.ru with esmtp id 1AJEmF-0003Xj-00 for freebsd-current@FreeBSD.org; Mon, 10 Nov 2003 19:20:31 +0300 Date: Mon, 10 Nov 2003 19:20:22 +0300 From: Serj Kotsuba X-Mailer: The Bat! (v2.01) CD5BF9353B3B7091 Organization: XTreme Inc. X-Priority: 3 (Normal) Message-ID: <8719542125.20031110192022@mail.ru> To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Serj Kotsuba List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:20:36 -0000 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:25:48 2003 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 706B616A4CE; Mon, 10 Nov 2003 08:25:48 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFF6043F85; Mon, 10 Nov 2003 08:25:46 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) hAAGPjfw055996; Mon, 10 Nov 2003 17:25:45 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id hAAGPenF055995; Mon, 10 Nov 2003 17:25:40 +0100 (CET) (envelope-from marius) Date: Mon, 10 Nov 2003 17:25:40 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20031110172540.A29948@newtrinity.zeist.de> References: <20031106152721.J95465@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@freebsd.org on Thu, Nov 06, 2003 at 12:22:45PM -0500 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.22.0.1; VDF 6.22.0.32 cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:25:48 -0000 On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: > > On 06-Nov-2003 Harti Brandt wrote: > > JB>I figured out what is happenning I think. You are getting a spurious > > JB>interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register > > JB>lists pending interrupts still waiting to be serviced. Try using > > JB>'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if > > JB>the spurious IRQ 7 interrupts go away. > > > > Ok, that seems to help. Interesting although why do these interrupts > > happen only with a larger HZ and when the kernel is doing printfs (this > > machine has a serial console). I have also not tried to disable SIO2 and > > the parallel port. > > Can you also try turning mixed mode back on and using > http://www.FreeBSD.org/~jhb/patches/spurious.patch > > You should get some stray IRQ 7's in the vmstat -i output as well as a few > printf's to the kernel console. > I think I'm seeing something related here, with the old interrupt code I got: <...> Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... ACPI autoload failed - no such file or directory stray irq 7 ^^^^^^^^^^^ Copyright (c) 1992-2003 The FreeBSD Project. <...> With the new interrupt code I get: <...> OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db> tr (null)(0,0,0,0,0) at 0xa00 <...> However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: <...> db> continue SMAP type=01 base=0000000000000000 len=000000000009f400 SMAP type=02 base=000000000009f400 len=0000000000000c00 SMAP type=02 base=00000000000d0000 len=0000000000030000 SMAP type=01 base=0000000000100000 len=000000001fdf0000 SMAP type=03 base=000000001fef0000 len=000000000000f000 SMAP type=04 base=000000001feff000 len=0000000000001000 SMAP type=01 base=000000001ff00000 len=0000000000080000 SMAP type=02 base=000000001ff80000 len=0000000000080000 SMAP type=02 base=00000000fec00000 len=0000000000004000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff80000 len=0000000000080000 Copyright (c) 1992-2003 The FreeBSD Project. <...> Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full verbose boot log is at: http://quad.zeist.de/newintr.log From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:29:48 2003 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 1C04416A4CE for ; Mon, 10 Nov 2003 08:29:48 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5B343FDD for ; Mon, 10 Nov 2003 08:29:45 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAAGTdNJ043928 for ; Mon, 10 Nov 2003 18:29:39 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAAGTdsr043927 for current@freebsd.org; Mon, 10 Nov 2003 18:29:39 +0200 (SAST) (envelope-from jhay) Date: Mon, 10 Nov 2003 18:29:38 +0200 From: John Hay To: current@freebsd.org Message-ID: <20031110162937.GA43708@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: diskless panic with new interrupt code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:29:48 -0000 Hi, My old diskless dual Pentium I 100MHz system does not like the latest code. I use etherboot to boot it. I have tried both an UP and SMP kernel but it panic in the same way. Looking at the low address values, it looks as if it happens very early. Maybe something depends on the loader initializing things nowadays? A kernel of about 2 weeks ago did boot without a problem, even an SMP one. On bootup this is what I see: ######################################### WARNING: loader(8) metadata is missing! instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db> ######################################### John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:30:26 2003 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 66E0C16A4D2 for ; Mon, 10 Nov 2003 08:30:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D7843FAF for ; Mon, 10 Nov 2003 08:30:25 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAAGSeMg057960; Mon, 10 Nov 2003 11:28:40 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAAGSeSp057957; Mon, 10 Nov 2003 11:28:40 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Nov 2003 11:28:40 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Smith In-Reply-To: <3FAFA5A3.3000704@xtaz.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Soren Schmidt cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:30:26 -0000 On Mon, 10 Nov 2003, Matt Smith wrote: > With a current build from november the 9th I am still getting exactly > the same NFS lockups. I assume soren is as well. NFS has basically been > pretty unusable now for over a month. > > As only a couple of people have complained about this from what I can > see I assume it is something related to something specific such as a > network card? I'm fairly baffled. I tried for many hours to reproduce the problem in two seperate sets of systems here, and completely failed. I left buildworlds, cvs updates, blah blah blah, running for 96 hours across pools of clients and servers and no hint of the problem. I also use NFS daily on my primary workstation at work, as well as in my normal development setup with diskless crashboxes. So indeed, there must be some very specific piece of the picture that I'm not reproducing, such as a specific network card, or there's a race condition that requires very specific timing, etc. How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations... > From my testing I only get this lockup when writing to the server. > Reading from the server works perfectly all the time. So luckily I can > still manage an NFS mounted installworld/kernel. > > I just got the lockup again now whilst it downloaded p5-Net-DNS to > portupgrade into /usr/ports/distfiles. This is a very small file but it > was enough to trigger it off. So it doesn't look like a size related > issue either as I can download around 4% of mysql before it locks up. > > Obviously we should really try and find the cause of this before 5.2. I > am willing to try any patches/debug on my systems. But I just have zero > clue about what to look for myself. > > As a start here is the relevent parts of my dmesg to show the NIC's I'm > using. I wonder if this corresponds to sorens? > > NFS CLIENT (xl1 would be the card it's using to talk to the server): > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem > 0xea000000-0xea00007f irq 12 at device 15.0 on pci0 > xl0: Ethernet address: 00:a0:24:ac:e1:b4 > miibus0: on xl0 > xlphy0: <3Com internal media interface> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl1: <3Com 3c905-TX Fast Etherlink XL> port 0xe800-0xe83f irq 11 at > device 17.0 on pci0 > xl1: Ethernet address: 00:60:08:6d:1e:3b > miibus1: on xl1 > nsphy0: on miibus1 > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > NFS SERVER: > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem > 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 > xl0: Ethernet address: 00:04:76:8d:c5:fd > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My server: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd880-0xd8ff mem 0xff202000-0xff20207f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:b0:d0:29:ec:ce miibus2: on xl0 xlphy0: <3Com internal media interface> on miibus2 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My client1: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xff000000-0xff00007f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:c0:4f:0d:6b:bc miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My client2: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd880-0xd8ff mem 0xff202000-0xff20207f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:b0:d0:2b:76:d5 miibus2: on xl0 xlphy0: <3Com internal media interface> on miibus2 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > Both connected to a 100meg full duplex switch. Ditto. > Any ideas? As I have said I'm happy to enable some major debugging etc. > But I just need somebody to give me a step by step guide for what to do > and look for. > In case this thread is too old now and nobody remembers anything about > it the previous email regarding it is at > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1183410+0+archive/2003/freebsd-current/20031102.freebsd-current Ok, here's the strategy I was planning to take once I could reproduce it: (1) Attempt to further narrow down responsibility to client/server. In particular, see if an apparent hang on one client affects the other clients. (2) Investigate Soren's report that killing and restarting nfsd on the server would clear the hang. (3) Look at stack traces of involved processes on both the client and server: in particular, look at traces for any client blocked in NFS, any nfsiod processes on the client, and the nfsd processes on the server. Also look at the wait channels on clients and servers for these processes. Particularly interested in whether nfsd processes are blocked trying to grab locks. (4) Look at netstat information for NFS sockets, in particular, if the buffers are full, or not being drained. In particular, on the server, is the input queue not being drained by nfsd worker threads? (5) Try backing out src/sys/nfsserver/nfs_serv.c:1.137, which removed another deadlock problem, but did change locking behavior in the NFS server. (6) Look at packet traces between the client and server with ethereal, which has pretty good NFS decoding. Is the client retransmitting an RPC to the server and the server just isn't responding, or is the client failing to transmit? At the point of the hang, what sorts of RPCs are outstanding to the server? In the past, we've seen "apparent hangs" when some or another more obscure unusual error case on the NFS server fails to respond to an RPC, which causes the client to "wait forever". To do all this, you'll want to compile DDB into your kernel, and make sure you have a copy of the kernel on-disk with debugging symbols. Do this on both the client and the server. To generate stack traces, you can break to the debugger on the console of each system, use the debugger "ps" command to identify victims, then "trace pid" replacing "pid" with the pid number of interest. Ideally, you'll use a serial console and use serial break (requires BREAK_TO_DEBUGGER) to do this so you can copy and paste traces rather than having to hand-transcribe. Things to look for: normally, idle nfsd and nfsiod processes have a WCHAN of "-" (ps -lax), which indicates they're blocked waiting for some event to kick them off. If you see nfsd processes "hung" in another state, it's a good sign we've identified a server problem. In the nfs client processes, "nfsrcvlk" typically indicates a process has sent out an RPC and is now waiting on a response. If you need any help getting debugging stuff up and running, let me know. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:45:04 2003 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 605C016A4CE; Mon, 10 Nov 2003 08:45:04 -0800 (PST) Received: from womble.xtaz.co.uk (82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 780EC43FAF; Mon, 10 Nov 2003 08:45:03 -0800 (PST) (envelope-from matt@xtaz.co.uk) Received: from xtaz.co.uk (localhost [127.0.0.1]) by womble.xtaz.co.uk (Postfix) with ESMTP id 6406E902D7; Mon, 10 Nov 2003 16:45:02 +0000 (GMT) Message-ID: <3FAFC08D.30301@xtaz.co.uk> Date: Mon, 10 Nov 2003 16:45:01 +0000 From: Matt Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Soren Schmidt cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:45:04 -0000 X-List-Received-Date: Mon, 10 Nov 2003 16:45:04 -0000 X-List-Received-Date: Mon, 10 Nov 2003 16:45:04 -0000 Robert Watson wrote: > I'm fairly baffled. I tried for many hours to reproduce the problem in > two seperate sets of systems here, and completely failed. I left > buildworlds, cvs updates, blah blah blah, running for 96 hours across > pools of clients and servers and no hint of the problem. I also use NFS > daily on my primary workstation at work, as well as in my normal > development setup with diskless crashboxes. So indeed, there must be some > very specific piece of the picture that I'm not reproducing, such as a > specific network card, or there's a race condition that requires very > specific timing, etc. > > How fast are your systems, speaking of which? I live in the world of > 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're > using multi-ghz boxes, that could well be the distinguishing factor > between our configurations... > client is an intel pentium II 300mhz with 256meg ram and 1gig of swap. server is an athlon XP 2200 with 512meg ram and 1gig of swap. I can certainly spend some time trying to get some proper debug based on what you have said in your email. I shall look into setting up a serial console etc. In the meantime another piece of information which might be helpful is this. Looking at the wtmp to see when I rebuilt my world/kernel I can see this: reboot ~ Tue Oct 21 20:44 reboot ~ Wed Oct 15 19:36 (These times are in BST which is +5 hours from east coast US). On the Oct 15th kernel NFS was working perfectly (and before that). From the Oct 21st kernel it has always locked up in this way. So something between those two dates was commited which broke this for us. Another way of me debugging this I guess is to backtrack my world to each date in between systematically and find the exact date it breaks and look at the commits. Matt. From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:45:17 2003 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 ADF7016A4CF for ; Mon, 10 Nov 2003 08:45:17 -0800 (PST) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B394843FBD for ; Mon, 10 Nov 2003 08:45:15 -0800 (PST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1])hAAGjDlY001295 for ; Mon, 10 Nov 2003 11:45:13 -0500 (EST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost)hAAGjD7R001294 for current@freebsd.org; Mon, 10 Nov 2003 11:45:13 -0500 (EST) (envelope-from mwlucas) Date: Mon, 10 Nov 2003 11:45:13 -0500 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20031110164513.GA828@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-2.5 required=4.0 tests=USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: erroneous message from locked-up machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:45:17 -0000 I came in to work today to find one of my -current machines unable to open a pipe. (This probably had a lot to do with the spamd that went stark raving nutters overnight, but that's a separate problem.) A power cycle fixed the problem, but /var/log/messages was filled with: Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7). Interesting. bewilderbeast~;sysctl kern.maxpipekva sysctl: unknown oid 'kern.maxpipekva' bewilderbeast~; And tuning(7) doesn't mention this, either. Is this just work-in-progress, or did someone forget to commit something? ==ml PS: Lesson of the day: no pipe KVA, no su. Great fun on remote machines! :-) -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org Today's chance of throwing it all away to start a goat farm: 41.8% http://www.BlackHelicopters.org/~mwlucas/ Absolute OpenBSD: http://www.AbsoluteOpenBSD.com/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:45:35 2003 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 5A24716A4CE; Mon, 10 Nov 2003 08:45:35 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80A5B43F75; Mon, 10 Nov 2003 08:45:28 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:l6ynzkgnYr+W7R/c9IsOn8PKn0xkVeda5ewI3ogt1HOR4DqngT5BWy1ULjsmybb7@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hAAGiREU067618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2003 01:44:30 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 11 Nov 2003 01:44:27 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:45:35 -0000 Hi, >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 >>>>> Andre Oppermann said: oppermann> Hajimu-san, I'm looking especially for comments on whether my changes oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). I don't see the patch in detail, yet, it seems your change will affect KAME's development. You should ask core@kame.net for review your patch in detail before committing into FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:47:23 2003 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 683F016A4CE for ; Mon, 10 Nov 2003 08:47:23 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1997143FE5 for ; Mon, 10 Nov 2003 08:47:20 -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) hAAGl8t2075013 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 10 Nov 2003 17:47:15 +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 hAAGl52q035160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 17:47:05 +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 hAAGl52u022068; Mon, 10 Nov 2003 17:47:05 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id hAAGl3o1022067; Mon, 10 Nov 2003 17:47:03 +0100 (CET) (envelope-from ticso) Date: Mon, 10 Nov 2003 17:47:02 +0100 From: Bernd Walter To: Alexander Leidinger Message-ID: <20031110164701.GX16726@cicely12.cicely.de> References: <20031109212217.GF16726@cicely12.cicely.de> <1068418579.1822.13.camel@hood.oook.cz> <20031109231136.GI16726@cicely12.cicely.de> <20031110100320.1189515c.Alexander@Leidinger.net> <20031110121911.GL16726@cicely12.cicely.de> <20031110135002.66055c17.Alexander@Leidinger.net> <20031110125538.GP16726@cicely12.cicely.de> <20031110155423.1bb0b145.Alexander@Leidinger.net> <20031110151927.GT16726@cicely12.cicely.de> <20031110163531.4441f094.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110163531.4441f094.Alexander@Leidinger.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: ticso@cicely.de cc: current@freebsd.org Subject: Re: New EHCI device ID 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: Mon, 10 Nov 2003 16:47:23 -0000 On Mon, Nov 10, 2003 at 04:35:31PM +0100, Alexander Leidinger wrote: > On Mon, 10 Nov 2003 16:19:27 +0100 > Bernd Walter wrote: > > > USB2 hubs are currently not supported with high speed uplinks. > > That's the reason why there is no EHCI support in GENERIC. > > EHCI needs interrupt transfers first to support usb2.0 hubs at high > > speed uplinks with high speed devices. > > For low and full speed downlink we additionaly need speed conversion > > support in uhub code. > > Is there an easy way of printing something like this instead of halting > the system? Don't know, but if I ever put time in that issue then by implementing the missing points and not by changing symptoms. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 08:49:50 2003 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 8680A16A4CE for ; Mon, 10 Nov 2003 08:49:50 -0800 (PST) Received: from queue.unet.com.mk (queue.unet.com.mk [212.13.64.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ADAE43FAF for ; Mon, 10 Nov 2003 08:49:45 -0800 (PST) (envelope-from aleksandar@unet.com.mk) Received: from b166-er.unet.com.mk (unet-gw.unet.com.mk [212.13.80.1]) by queue.unet.com.mk (8.11.6/8.11.6) with SMTP id hAAGZRR02967 for ; Mon, 10 Nov 2003 17:35:27 +0100 Date: Mon, 10 Nov 2003 18:52:29 +0100 From: Aleksandar Simonovski To: freebsd-current@freebsd.org Message-Id: <20031110185229.075ea3ef.aleksandar@unet.com.mk> Organization: Unet X-Mailer: Sylpheed version 0.9.4-gtk2-20030802 (GTK+ 2.2.4; i686-pc-linux-gnu) X-Operating-System: Slackware 9.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 16:49:50 -0000 after making make buildworld,installworld mergemaster and everything that i suposed to do ( reading UPDATING) i get this error: init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or directory init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or directory .......and so on any help thanx Aleksandar From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:04:29 2003 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 6EA7416A4CF for ; Mon, 10 Nov 2003 09:04:29 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E622143F85 for ; Mon, 10 Nov 2003 09:04:28 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D6DA472DB5; Mon, 10 Nov 2003 09:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D216572DAD; Mon, 10 Nov 2003 09:04:28 -0800 (PST) Date: Mon, 10 Nov 2003 09:04:28 -0800 (PST) From: Doug White To: Jason In-Reply-To: <3FADD279.2040206@ec.rr.com> Message-ID: <20031110090348.C53095@carver.gumbysoft.com> References: <3FADD279.2040206@ec.rr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: build problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:04:29 -0000 On Sun, 9 Nov 2003, Jason wrote: > I have had problems finishing buildworld and the problem is the same > each time the build fails. It has failed 4 times at > file:///usr/src/gnu/usr.bin/cvs/doc/. I have cvsuped 3 times in 2 > days. I am running 5.1. Any info you might have would be helpful. This is usually where rescue falls over. Try building with out -j and see where it des then. You may want to clear out /usr/obj. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:06:05 2003 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 1A1E316A4D0; Mon, 10 Nov 2003 09:06:05 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5340B43FCB; Mon, 10 Nov 2003 09:06:02 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAAH5dNJ045132; Mon, 10 Nov 2003 19:05:39 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAAH5cVM045131; Mon, 10 Nov 2003 19:05:38 +0200 (SAST) (envelope-from jhay) Date: Mon, 10 Nov 2003 19:05:38 +0200 From: John Hay To: Marius Strobl Message-ID: <20031110170538.GA44941@zibbi.icomtek.csir.co.za> References: <20031106152721.J95465@beagle.fokus.fraunhofer.de> <20031110172540.A29948@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110172540.A29948@newtrinity.zeist.de> User-Agent: Mutt/1.4i cc: current@freebsd.org Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:06:05 -0000 > > With the new interrupt code I get: > <...> > OK boot > cpuid = 0; apic id = 00 > instruction pointer = 0x0:0xa00 > stack pointer = 0x0:0xffe > frame pointer = 0x0:0x0 > code segment = base 0x0, limit 0x0, type 0x0 > = DPL 0, pres 0, def32 0, gran 0 > processor eflags = interrupt enabled, vm86, IOPL = 0 > current process = 0 () > kernel: type 30 trap, code=0 > Stopped at 0xa00: cli > db> tr > (null)(0,0,0,0,0) at 0xa00 > <...> > > However, if I enter 'continue' at the DDB prompt it continues to boot > and the system seems to runs fine: > > <...> > db> continue ... > Copyright (c) 1992-2003 The FreeBSD Project. > <...> > Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:08:19 2003 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 A740916A4CE for ; Mon, 10 Nov 2003 09:08:19 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492EC43FD7 for ; Mon, 10 Nov 2003 09:08:18 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd00.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1AJFVm-0005KY-0B; Mon, 10 Nov 2003 18:07:34 +0100 Received: from Andro-Beta.Leidinger.net (S97Ub+ZYgeQDjxh4FB1l1LtsIjCfnlWrpu7BrqTXHHtBZIEgM18XUL@[80.131.123.151]) by fmrl00.sul.t-online.com with esmtp id 1AJFVa-1EEffU0; Mon, 10 Nov 2003 18:07:22 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAAH7Jsm057236; Mon, 10 Nov 2003 18:07:20 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAAH7ebV019446; Mon, 10 Nov 2003 18:07:40 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 18:07:40 +0100 From: Alexander Leidinger To: "Michael W. Lucas" Message-Id: <20031110180740.5b8bfd68.Alexander@Leidinger.net> In-Reply-To: <20031110164513.GA828@bewilderbeast.blackhelicopters.org> References: <20031110164513.GA828@bewilderbeast.blackhelicopters.org> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: S97Ub+ZYgeQDjxh4FB1l1LtsIjCfnlWrpu7BrqTXHHtBZIEgM18XUL@t-dialin.net cc: current@freebsd.org Subject: Re: erroneous message from locked-up machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:08:19 -0000 On Mon, 10 Nov 2003 11:45:13 -0500 "Michael W. Lucas" wrote: > Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7). > > Interesting. > > bewilderbeast~;sysctl kern.maxpipekva > sysctl: unknown oid 'kern.maxpipekva' > bewilderbeast~; sysctl kern.maxpipe and "kva exceeded, please see tuning(7)." Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:17:12 2003 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 4281616A4CF for ; Mon, 10 Nov 2003 09:17:12 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A79EB43FCB for ; Mon, 10 Nov 2003 09:17:07 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 99F6372DB8; Mon, 10 Nov 2003 09:17:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 955D972DB5; Mon, 10 Nov 2003 09:17:07 -0800 (PST) Date: Mon, 10 Nov 2003 09:17:07 -0800 (PST) From: Doug White To: Yannick FAHAM In-Reply-To: <1068412105.17013.5.camel@ufretin.no-ip.org> Message-ID: <20031110091547.M53095@carver.gumbysoft.com> References: <1068412105.17013.5.camel@ufretin.no-ip.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Problem on a laptop with 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: Mon, 10 Nov 2003 17:17:12 -0000 On Sun, 9 Nov 2003, Yannick FAHAM wrote: > I have recently bought a centrino laptop and tried to install current on > it. the fact is my network card is only supported in this branche > (broadcom 4401). Broadcom wireless cards are not supported in -CURRENT. > after compiling the kernel, the boot process freeze on the hardware > enumeration. I have disabled acpi and boot in verbose mode and I have > many errors message like > (probe0)... Error 22. > Sorry for my english, i'm french. Could you post the dmesg you're getting? This isn't enough to tell... > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:24:14 2003 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 7E6CE16A4CE for ; Mon, 10 Nov 2003 09:24:14 -0800 (PST) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69D343FDF for ; Mon, 10 Nov 2003 09:24:13 -0800 (PST) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id D892E21686; Mon, 10 Nov 2003 09:24:13 -0800 (PST) Date: Mon, 10 Nov 2003 09:24:13 -0800 From: Will Andrews To: Doug White Message-ID: <20031110172413.GE93583@procyon.firepipe.net> Mail-Followup-To: Doug White , Yannick FAHAM , freebsd-current@freebsd.org References: <1068412105.17013.5.camel@ufretin.no-ip.org> <20031110091547.M53095@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110091547.M53095@carver.gumbysoft.com> User-Agent: Mutt/1.4.1i cc: Yannick FAHAM cc: freebsd-current@freebsd.org Subject: Re: Problem on a laptop with 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: Mon, 10 Nov 2003 17:24:14 -0000 On Mon, Nov 10, 2003 at 09:17:07AM -0800, Doug White wrote: > > (broadcom 4401). > > Broadcom wireless cards are not supported in -CURRENT. That's not a wireless card. It's an el cheapo 10/100 chipset. Linux supports it now, and it's found in some Athlon motherboards (such as the one powering cvsup12.freebsd.org) as well as some newer laptops. Regards, -- wca From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:38:51 2003 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 77BF116A4CE for ; Mon, 10 Nov 2003 09:38:51 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8DAC43FCB for ; Mon, 10 Nov 2003 09:38:50 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id DDB7872DAD; Mon, 10 Nov 2003 09:38:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id DB3DA72DA8; Mon, 10 Nov 2003 09:38:50 -0800 (PST) Date: Mon, 10 Nov 2003 09:38:50 -0800 (PST) From: Doug White To: Aleksandar Simonovski In-Reply-To: <20031110185229.075ea3ef.aleksandar@unet.com.mk> Message-ID: <20031110093832.C53095@carver.gumbysoft.com> References: <20031110185229.075ea3ef.aleksandar@unet.com.mk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:38:51 -0000 On Mon, 10 Nov 2003, Aleksandar Simonovski wrote: > after making make buildworld,installworld mergemaster and everything > that i suposed to do ( reading UPDATING) i get this error: > > init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or directory > init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or directory Hm, no devfs mounted? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:44:01 2003 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 39A7316A4CE; Mon, 10 Nov 2003 09:44:01 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 066CF43FCB; Mon, 10 Nov 2003 09:44:00 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id hAAHieEQ008463; Mon, 10 Nov 2003 18:44:40 +0100 (CET) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.10/8.12.10/Submit) id hAAHiefC008462; Mon, 10 Nov 2003 18:44:40 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200311101744.hAAHiefC008462@spider.deepcore.dk> In-Reply-To: To: Robert Watson Date: Mon, 10 Nov 2003 18:44:40 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:44:01 -0000 It seems Robert Watson wrote: > How fast are your systems, speaking of which? I live in the world of > 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're > using multi-ghz boxes, that could well be the distinguishing factor > between our configurations... Server is 533MhzVIA C3, clients everything from 300Mhz PII to 2.6G P4. > Ok, here's the strategy I was planning to take once I could reproduce it: > > (1) Attempt to further narrow down responsibility to client/server. In > particular, see if an apparent hang on one client affects the other > clients. For me its just the server end that fails, I've not seen the client hang. > (2) Investigate Soren's report that killing and restarting nfsd on the > server would clear the hang. Yups, that works, in fact I have that in my crontab now every minute to keep NFS from hosing my setup here. NOTE: I also still need to ifconfig done/up my interfaces on some boxes or the netstack will freeze (again done every minute in crontab). However when NFS locks up it seems totatlly unrelated, ie all other network traffic works... > (3) Look at stack traces of involved processes on both the client and > server: in particular, look at traces for any client blocked in NFS, > any nfsiod processes on the client, and the nfsd processes on the > server. Also look at the wait channels on clients and servers for > these processes. Particularly interested in whether nfsd processes > are blocked trying to grab locks. Ok, will do.. > (4) Look at netstat information for NFS sockets, in particular, if the > buffers are full, or not being drained. In particular, on the server, > is the input queue not being drained by nfsd worker threads? Netstat doesn't seem to give any hints or even usefull info here, any special cmdøs you want the output from ? > (5) Try backing out src/sys/nfsserver/nfs_serv.c:1.137, which removed > another deadlock problem, but did change locking behavior in the NFS > server. No change already tried. > (6) Look at packet traces between the client and server with ethereal, > which has pretty good NFS decoding. Is the client retransmitting an > RPC to the server and the server just isn't responding, or is the > client failing to transmit? At the point of the hang, what sorts of > RPCs are outstanding to the server? In the past, we've seen "apparent > hangs" when some or another more obscure unusual error case on the NFS > server fails to respond to an RPC, which causes the client to "wait > forever". I can try that easily, I'll get a trace to you later tonight... > Things to look for: normally, idle nfsd and nfsiod processes have a WCHAN > of "-" (ps -lax), which indicates they're blocked waiting for some event > to kick them off. If you see nfsd processes "hung" in another state, it's > a good sign we've identified a server problem. In the nfs client > processes, "nfsrcvlk" typically indicates a process has sent out an RPC > and is now waiting on a response. I see the idle '-' wchan here when things go bad IIRC... -Søren From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:47:34 2003 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 B2E7416A4CE for ; Mon, 10 Nov 2003 09:47:34 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3570943F3F for ; Mon, 10 Nov 2003 09:47:33 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id EAA15695; Tue, 11 Nov 2003 04:46:48 +1100 Date: Tue, 11 Nov 2003 04:46:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Michael W. Lucas" In-Reply-To: <20031110164513.GA828@bewilderbeast.blackhelicopters.org> Message-ID: <20031111042518.I857@gamplex.bde.org> References: <20031110164513.GA828@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: erroneous message from locked-up machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:47:34 -0000 On Mon, 10 Nov 2003, Michael W. Lucas wrote: > I came in to work today to find one of my -current machines unable to > open a pipe. (This probably had a lot to do with the spamd that went > stark raving nutters overnight, but that's a separate problem.) A > power cycle fixed the problem, but /var/log/messages was filled with: > > Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7). > > Interesting. > > bewilderbeast~;sysctl kern.maxpipekva > sysctl: unknown oid 'kern.maxpipekva' > bewilderbeast~; The following patch fixes this and some nearby style bugs: - source style bug: line too line - output style bugs: comma splice, verboseness (helps make the source line too long), and kernel message terminated with a ".". %%% Index: sys_pipe.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v retrieving revision 1.158 diff -u -2 -r1.158 sys_pipe.c --- sys_pipe.c 9 Nov 2003 09:17:24 -0000 1.158 +++ sys_pipe.c 10 Nov 2003 17:21:47 -0000 @@ -331,5 +331,5 @@ if (error != KERN_SUCCESS) { if (ppsratecheck(&lastfail, &curfail, 1)) - printf("kern.maxpipekva exceeded, please see tuning(7).\n"); + printf("kern.ipc.maxpipekva exceeded; see tuning(7)\n"); return (ENOMEM); } %%% > And tuning(7) doesn't mention this, either. > > Is this just work-in-progress, or did someone forget to commit something? Seems like tuning pipe kva is completely absent in tuning(7) (so the above message can be shortened further). You can tune kva generally as documented there, but the pipe limit is separate. > PS: Lesson of the day: no pipe KVA, no su. Great fun on remote > machines! :-) It's interesting that su was the point of failure. It uses a pipe hack for IPC. Otherwise it doesn't use pipes, at least direectly. It shouldn't need to use the pipe hack. My version uses signals instead. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 09:49:12 2003 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 BEC5E16A4CE for ; Mon, 10 Nov 2003 09:49:12 -0800 (PST) Received: from wolfram.com (wri-dns0.wolfram.com [140.177.205.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F39E743FE5 for ; Mon, 10 Nov 2003 09:49:10 -0800 (PST) (envelope-from hemi@just.puresimplicity.net) Received: from just.puresimplicity.net ([140.177.207.10]) by wolfram.com (8.11.2/8.11.2) with ESMTP id hAAHn8B29394; Mon, 10 Nov 2003 11:49:08 -0600 Received: (from hemi@localhost) by just.puresimplicity.net (8.12.8p2/8.12.8/Submit) id hAAHn804094172; Mon, 10 Nov 2003 11:49:08 -0600 (CST) (envelope-from hemi) Date: Mon, 10 Nov 2003 11:49:08 -0600 From: Josh Tolbert To: "Scott R. Sewall" Message-ID: <20031110174908.GA93972@just.puresimplicity.net> References: <3FAA8AB6.90904@ix.netcom.com> <20031106175845.GE71078@just.puresimplicity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031106175845.GE71078@just.puresimplicity.net> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: Trouble booting a SMP kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:49:12 -0000 On Thu, Nov 06, 2003 at 11:58:46AM -0600, Josh Tolbert wrote: > On Thu, Nov 06, 2003 at 09:53:58AM -0800, Scott R. Sewall wrote: > > > > I need a little help diagnosing a problem booting a 5.1-RELEASE SMP kernel. > > > > The GENERIC kernel boots just fine. When I boot a GENERIC kernel with SMP > > enabled the boot fails early in the boot process. The text from the > > console is below: > > > > Programming 16 pins in IOAPIC #0 > > IOAPIC #0 intpin 2 -> irq 0 > > Programming 16 pins in IOAPIC #1 > > AP #1 (PHY #1) failed! > > panic y/n? [y] n > > > > APIC_IO: Testing 8254 interrupt delivery > > [system is locks up at this point, no more messages] > > > > Also fails to boot a FreeBSD 4.4 SMP kernel, which leads me to beleive > > it's a hardware > > problem. > > > > Is this indicative of a failed processor or is it the motherboard? > > > > Hardware is a Tyan Thunder LE-T, BIOS v1.06, Dual Pentium III 1133 MHz, > > 2GB RAM. > > > > Any advise on diagnosing the problem is greatly appreciated. > > > > -- Scott > > No advice, but I experienced this exact problem last night. I'm running a Tyan > Tiger LE motherboard, 2x PIII 733, 512M RAM and various other bits. It hangs > in the exact same spot as yours does, which isn't surprising considering both > motherboards use essentially the same chipset. > > This machine has ran with 4.x in the past, as well as an older 5-CURRENT, but > I don't have timeframes for either. > > I'm fairly certain it's not a hardware problem. Google turns up a few other > people with the same problem, so I don't think we're alone. I was going to > fire off an e-mail to the lists today, but figured it would be best just to > chime in with a "me too" since you've already got one in. > > Thanks, > Josh To follow up, I tried the latest -CURRENT build from current.freebsd.org. The new SMP arrangement works great and the kernel boots fine on the machine, but I couldn't continue the install once I got past drive partitioning due to some missing devices related to the Promise IDE RAID array. So, as it stands, -RELEASE won't run in SMP and -CURRENT will, but -CURRENT won't install on my machine. Of course, I put all of about five minutes' worth of effort in to it... Any other ideas? Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 10:05:49 2003 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 A161616A4CE for ; Mon, 10 Nov 2003 10:05:49 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 799ED43FDD for ; Mon, 10 Nov 2003 10:05:47 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAAI5gNJ047271 for ; Mon, 10 Nov 2003 20:05:42 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAAI5g4H047270 for current@freebsd.org; Mon, 10 Nov 2003 20:05:42 +0200 (SAST) (envelope-from jhay) Date: Mon, 10 Nov 2003 20:05:41 +0200 From: John Hay To: current@freebsd.org Message-ID: <20031110180541.GA47135@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: panic: probing for non-PCI bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 18:05:49 -0000 Hi, Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: ############################ Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 640kB/130036kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (jhay@beast.icomtek.csir.co.za, Sun Nov 2 14:16:55 SAST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 syms=[0x4+0x31690+0x4+0x3de08] /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb] loading required module 'miibus' /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 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.1-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003 jhay@beast.icomtek.csir.co.za:/b/src/sys/i386/compile/BEAST Preloaded elf kernel "/boot/kernel/kernel" at 0xc0768000. Preloaded elf module "/boot/kernel/if_vlan.ko" at 0xc076821c. Preloaded elf module "/boot/kernel/if_fxp.ko" at 0xc07682c8. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc0768374. Preloaded elf module "/boot/kernel/usb.ko" at 0xc0768420. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80fbff real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ############################ John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 10:32:47 2003 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 DFFA216A4CE for ; Mon, 10 Nov 2003 10:32:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B357443F3F for ; Mon, 10 Nov 2003 10:32:46 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAAIV2Mg059603; Mon, 10 Nov 2003 13:31:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAAIV1vu059600; Mon, 10 Nov 2003 13:31:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Nov 2003 13:31:01 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Smith In-Reply-To: <3FAFC08D.30301@xtaz.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Soren Schmidt cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 18:32:48 -0000 On Mon, 10 Nov 2003, Matt Smith wrote: > I can certainly spend some time trying to get some proper debug based on > what you have said in your email. I shall look into setting up a serial > console etc. > > In the meantime another piece of information which might be helpful is > this. Looking at the wtmp to see when I rebuilt my world/kernel I can > see this: > > reboot ~ Tue Oct 21 20:44 > reboot ~ Wed Oct 15 19:36 > > (These times are in BST which is +5 hours from east coast US). > > On the Oct 15th kernel NFS was working perfectly (and before that). From > the Oct 21st kernel it has always locked up in this way. So something > between those two dates was commited which broke this for us. Another > way of me debugging this I guess is to backtrack my world to each date > in between systematically and find the exact date it breaks and look at > the commits. Hmm. The one other thing that might be worth trying, and this is pretty time-consuming, is attempting to narrow down the threshold kernel change that caused the failures to start. Typically, this is done using a binary search (i.e., find two dates -- one that the kernel works, the other that it doesn't -- split the difference, repeat until narrowed down to a range of commits that can be individually inspected). This way we could try to identify some suspect changes that could be backed out locally individually to narrow it down. The likely categories of commits that might be worth looking at probably include: (1) Changes specifically to the network drivers that you're using. (2) Changes to the network stack, especially relating to locking and timeouts. (3) Changes to the NFS client and server code. (4) Changes in general to VFS and buffer cache locking. We've had a lot of commits in all of these categories, so narrowing it down would be a useful way to help figure it out... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 10:40:50 2003 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 C2B4416A4CE for ; Mon, 10 Nov 2003 10:40:50 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A797E43F93 for ; Mon, 10 Nov 2003 10:40:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 17571 invoked from network); 10 Nov 2003 18:40:46 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Nov 2003 18:40:46 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hAAIeMce014341; Mon, 10 Nov 2003 13:40:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031110172540.A29948@newtrinity.zeist.de> Date: Mon, 10 Nov 2003 13:40:19 -0500 (EST) From: John Baldwin To: Marius Strobl X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 18:40:51 -0000 On 10-Nov-2003 Marius Strobl wrote: > On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: >> >> On 06-Nov-2003 Harti Brandt wrote: >> > JB>I figured out what is happenning I think. You are getting a spurious >> > JB>interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register >> > JB>lists pending interrupts still waiting to be serviced. Try using >> > JB>'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if >> > JB>the spurious IRQ 7 interrupts go away. >> > >> > Ok, that seems to help. Interesting although why do these interrupts >> > happen only with a larger HZ and when the kernel is doing printfs (this >> > machine has a serial console). I have also not tried to disable SIO2 and >> > the parallel port. >> >> Can you also try turning mixed mode back on and using >> http://www.FreeBSD.org/~jhb/patches/spurious.patch >> >> You should get some stray IRQ 7's in the vmstat -i output as well as a few >> printf's to the kernel console. >> > > I think I'm seeing something related here, with the old interrupt code I > got: > <...> > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > ACPI autoload failed - no such file or directory > stray irq 7 > ^^^^^^^^^^^ > Copyright (c) 1992-2003 The FreeBSD Project. Peter has seen this on an amd64 machine. It seems we can get an interrupt from the AT PIC before we get a chance to program the PICs to mask all their inputs. > <...> > > With the new interrupt code I get: > <...> > OK boot > cpuid = 0; apic id = 00 > instruction pointer = 0x0:0xa00 > stack pointer = 0x0:0xffe > frame pointer = 0x0:0x0 > code segment = base 0x0, limit 0x0, type 0x0 > = DPL 0, pres 0, def32 0, gran 0 > processor eflags = interrupt enabled, vm86, IOPL = 0 > current process = 0 () > kernel: type 30 trap, code=0 > Stopped at 0xa00: cli > db> tr > (null)(0,0,0,0,0) at 0xa00 > <...> > > However, if I enter 'continue' at the DDB prompt it continues to boot > and the system seems to runs fine: > > <...> > db> continue > SMAP type=01 base=0000000000000000 len=000000000009f400 > SMAP type=02 base=000000000009f400 len=0000000000000c00 > SMAP type=02 base=00000000000d0000 len=0000000000030000 > SMAP type=01 base=0000000000100000 len=000000001fdf0000 > SMAP type=03 base=000000001fef0000 len=000000000000f000 > SMAP type=04 base=000000001feff000 len=0000000000001000 > SMAP type=01 base=000000001ff00000 len=0000000000080000 > SMAP type=02 base=000000001ff80000 len=0000000000080000 > SMAP type=02 base=00000000fec00000 len=0000000000004000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000fff80000 len=0000000000080000 > Copyright (c) 1992-2003 The FreeBSD Project. > <...> > > Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' > makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full > verbose boot log is at: http://quad.zeist.de/newintr.log > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 10:47:05 2003 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 EE33B16A4CE for ; Mon, 10 Nov 2003 10:47:05 -0800 (PST) Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F07AA43FCB for ; Mon, 10 Nov 2003 10:47:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 1617 invoked from network); 10 Nov 2003 18:41:22 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Nov 2003 18:41:22 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hAAIewce014352; Mon, 10 Nov 2003 13:40:58 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031110162937.GA43708@zibbi.icomtek.csir.co.za> Date: Mon, 10 Nov 2003 13:40:55 -0500 (EST) From: John Baldwin To: John Hay X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org Subject: RE: diskless panic with new interrupt code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 18:47:06 -0000 On 10-Nov-2003 John Hay wrote: > Hi, > > My old diskless dual Pentium I 100MHz system does not like the latest > code. I use etherboot to boot it. I have tried both an UP and SMP kernel > but it panic in the same way. Looking at the low address values, it > looks as if it happens very early. Maybe something depends on the > loader initializing things nowadays? A kernel of about 2 weeks ago > did boot without a problem, even an SMP one. > > On bootup this is what I see: > >######################################### > WARNING: loader(8) metadata is missing! > instruction pointer = 0x0:0xa00 > stack pointer = 0x0:0xffe > frame pointer = 0x0:0x0 > code segment = base 0x0, limit 0x0, type 0x0 > = DPL 0, pres 0, def32 0, gran 0 > processor eflags = interrupt enabled, vm86, IOPL = 0 > current process = 0 () > kernel: type 30 trap, code=0 > Stopped at 0xa00: cli > db> >######################################### Just do a continue for now until I get a workaround for this done. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:03:42 2003 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 8770E16A4CE for ; Mon, 10 Nov 2003 11:03:42 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D8143FEC for ; Mon, 10 Nov 2003 11:03:33 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 60626 invoked from network); 10 Nov 2003 19:06:22 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 19:06:22 -0000 Message-ID: <3FAFE0E5.743F815A@pipeline.ch> Date: Mon, 10 Nov 2003 20:03:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:03:42 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 > >>>>> Andre Oppermann said: > > oppermann> Hajimu-san, I'm looking especially for comments on whether my changes > oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). > > I don't see the patch in detail, yet, it seems your change will affect > KAME's development. You should ask core@kame.net for review your > patch in detail before committing into FreeBSD. Ok, I've written an email core@kame.net. However there is not very much time for them to respond before 5.2 code freeze. I've taken care in my changes not to break IPv6 and to be only minimal intrusive. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:13:33 2003 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 2450016A4CE for ; Mon, 10 Nov 2003 11:13:33 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A41543FB1 for ; Mon, 10 Nov 2003 11:13:32 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 2867 invoked from network); 10 Nov 2003 19:13:27 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Nov 2003 19:13:27 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hAAJCxce014583; Mon, 10 Nov 2003 14:12:59 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031110170538.GA44941@zibbi.icomtek.csir.co.za> Date: Mon, 10 Nov 2003 14:12:56 -0500 (EST) From: John Baldwin To: John Hay X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org cc: Marius Strobl Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:13:33 -0000 On 10-Nov-2003 John Hay wrote: >> >> With the new interrupt code I get: >> <...> >> OK boot >> cpuid = 0; apic id = 00 >> instruction pointer = 0x0:0xa00 >> stack pointer = 0x0:0xffe >> frame pointer = 0x0:0x0 >> code segment = base 0x0, limit 0x0, type 0x0 >> = DPL 0, pres 0, def32 0, gran 0 >> processor eflags = interrupt enabled, vm86, IOPL = 0 >> current process = 0 () >> kernel: type 30 trap, code=0 >> Stopped at 0xa00: cli >> db> tr >> (null)(0,0,0,0,0) at 0xa00 >> <...> >> >> However, if I enter 'continue' at the DDB prompt it continues to boot >> and the system seems to runs fine: >> >> <...> >> db> continue > ... >> Copyright (c) 1992-2003 The FreeBSD Project. >> <...> >> > > Now why didn't I think of trying 'continue'? Hey there my old dual > Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:13:57 2003 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 7618F16A4EF for ; Mon, 10 Nov 2003 11:13:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id A134843F85 for ; Mon, 10 Nov 2003 11:13:55 -0800 (PST) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AJHTr-0004k1-00; Mon, 10 Nov 2003 20:13:43 +0100 Received: from [80.131.145.25] (helo=max2400) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AJHTq-0008QM-00; Mon, 10 Nov 2003 20:13:43 +0100 Date: Mon, 10 Nov 2003 20:13:49 +0100 From: Max Laier X-Mailer: The Bat! (v2.00) UNREG / CD5BF9353B3B7091 Organization: n/a X-Priority: 3 (Normal) Message-ID: <13127169546.20031110201349@love2party.net> To: Alexander Leidinger In-Reply-To: <20031110163254.046a5a44.Alexander@Leidinger.net> References: <000501c3a743$3f4c7a90$ca00a8c0@michael> <000d01c3a74f$5e1252e0$ca00a8c0@michael> <20031110113541.1ad899ff.Alexander@Leidinger.net> <20031110104900.GO810@starjuice.net> <20031110121242.GA6807@lara.unibe.ch> <20031110163254.046a5a44.Alexander@Leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re[2]: ALTQ support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Max Laier List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:13:57 -0000 Monday, November 10, 2003, 4:32:54 PM, you wrote: AL> On Mon, 10 Nov 2003 13:12:42 +0100 AL> Tobias Roth wrote: >> the author of altq itself or the author of the freebsd port? AL> I don't know the who's who, but I think it was the author of altq AL> itself. I certainly doubt that! On his homepage he has own patchsets for early 4.x releases and gives KAME as a resource for 5.x patchsets. So prove me wrong (by finally finding that mysterious thread) or stop spreading that kind of evil half-knowledge, please! FYI: The author of altq would be Kenjiro Cho, as google tells you. -- Best regards, Max mailto:max@love2party.net From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:24:25 2003 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 2D24C16A4CE for ; Mon, 10 Nov 2003 11:24:25 -0800 (PST) Received: from www.kukulies.org (www.kukulies.org [213.146.112.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7872543FA3 for ; Mon, 10 Nov 2003 11:24:23 -0800 (PST) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (localhost [127.0.0.1]) by www.kukulies.org (8.12.10/8.12.6) with ESMTP id hAAJOEoR096768; Mon, 10 Nov 2003 20:24:20 +0100 (CET) (envelope-from kuku@www.kukulies.org) Received: (from kuku@localhost) by www.kukulies.org (8.12.10/8.12.6/Submit) id hAAJODdt096767; Mon, 10 Nov 2003 20:24:13 +0100 (CET) Date: Mon, 10 Nov 2003 20:24:13 +0100 From: "Christoph P. Kukulies" To: Seth Chandler Message-ID: <20031110192413.GA96726@gilberto.physik.rwth-aachen.de> References: <200311100747.hAA7l8SL091492@www.kukulies.org> <3FAF615B.3090306@sethbc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAF615B.3090306@sethbc.org> User-Agent: Mutt/1.4.1i cc: "C. Kukulies" cc: freebsd-current@freebsd.org Subject: Re: -0166: *** Error: UtAllocate: Attempt to alloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:24:25 -0000 On Mon, Nov 10, 2003 at 04:58:51AM -0500, Seth Chandler wrote: > You using a dell laptop? They got the broken acpi aml code. There is a > patch out to fix it, its located here: > > http://sandcat.nl/~stijn/freebsd/dell.php Thanks. Applied it and it seems to cure the problem. Also xbatt shows the battery status now correctly. Nov 10 20:05:24 mybook kernel: acpi0: on motherboard Nov 10 20:05:24 mybook kernel: pcibios: BIOS version 2.10 Nov 10 20:05:24 mybook kernel: Using $PIR table, 10 entries at 0xc00fbc20 Nov 10 20:05:24 mybook kernel: Timecounter "ACPI-fast" frequency 3579545 Hz q uality 1000 Nov 10 20:05:24 mybook kernel: acpi_timer0: <24-bit timer at 3.579545MHz> por t 0x808-0x80b on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cpu0: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_tz0: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_acad0: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cmbat0: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cmbat1: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_lid0: on acpi 0 Nov 10 20:05:24 mybook kernel: acpi_button0: on acpi0 Nov 10 20:05:24 mybook kernel: acpi_button1: on acpi0 Nov 10 20:05:24 mybook kernel: pcib0: port 0xcf8-0xcff on acpi0 Nov 10 20:05:24 mybook kernel: pci0: on pcib0 Nov 10 20:05:24 mybook kernel: pcib0: slot 31 INTD is routed to irq 10 Nov 10 20:05:24 mybook kernel: agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 Nov 10 20:05:24 mybook kernel: pcib1: at device 1.0 on > > seth > > > C. Kukulies wrote: > > >...ate zero bytes > > > >The kernel message > > > >-0166: *** Error: UtAllocate: Attempt to allocate zero bytes > >-0166: *** Error: UtAllocate: Attempt to allocate zero bytes > >-0166: *** Error: UtAllocate: Attempt to allocate zero bytes > >-0166: *** Error: UtAllocate: Attempt to allocate zero bytes > > > >clobbers the screen in bursts during startup for quite some time now. > >I would like to ask if there is something I can do about it. > >Upgrading (cvsup)? Edit some config files with senseful info? > > > >AFAIK it has to do something with acpi, doesn't it? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:31:52 2003 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 1833216A4CE; Mon, 10 Nov 2003 11:31:52 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA00643F75; Mon, 10 Nov 2003 11:31:50 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) hAAJVnfw073335; Mon, 10 Nov 2003 20:31:49 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id hAAJVhkj073334; Mon, 10 Nov 2003 20:31:43 +0100 (CET) (envelope-from marius) Date: Mon, 10 Nov 2003 20:31:43 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20031110203143.A30188@newtrinity.zeist.de> References: <20031110170538.GA44941@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Nov 10, 2003 at 02:12:56PM -0500 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.22.0.1; VDF 6.22.0.32 cc: current@FreeBSD.org Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:31:52 -0000 On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: > > On 10-Nov-2003 John Hay wrote: > >> > >> With the new interrupt code I get: > >> <...> > >> OK boot > >> cpuid = 0; apic id = 00 > >> instruction pointer = 0x0:0xa00 > >> stack pointer = 0x0:0xffe > >> frame pointer = 0x0:0x0 > >> code segment = base 0x0, limit 0x0, type 0x0 > >> = DPL 0, pres 0, def32 0, gran 0 > >> processor eflags = interrupt enabled, vm86, IOPL = 0 > >> current process = 0 () > >> kernel: type 30 trap, code=0 > >> Stopped at 0xa00: cli > >> db> tr > >> (null)(0,0,0,0,0) at 0xa00 > >> <...> > >> > >> However, if I enter 'continue' at the DDB prompt it continues to boot > >> and the system seems to runs fine: > >> > >> <...> > >> db> continue > > ... > >> Copyright (c) 1992-2003 The FreeBSD Project. > >> <...> > >> > > > > Now why didn't I think of trying 'continue'? Hey there my old dual > > Pentium I diskless machine is running in SMP mode. > > Can you try this patch: > > http://www.FreeBSD.org/~jhb/patches/atpic.patch > Works here, thanks! Btw., I also get such a stray interrupt on my Sun U60, IIRC also from the printer port :) From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:37:32 2003 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 89D2216A4CE for ; Mon, 10 Nov 2003 11:37:32 -0800 (PST) Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C269C43FCB for ; Mon, 10 Nov 2003 11:37:30 -0800 (PST) (envelope-from ler@lerctr.org) Received: from lerlaptop-red.iadfw.net (lerlaptop-red.iadfw.net [207.136.3.72]) (authenticated bits=0)hAAJbRKx024133 for ; Mon, 10 Nov 2003 13:37:28 -0600 (CST) Date: Mon, 10 Nov 2003 13:37:23 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Message-ID: <22330000.1068493043@lerlaptop-red.iadfw.net> X-Mailer: Mulberry/3.1.0 (Linux/x86) X-PGP-Info: All other keys are old/dead. X-PGP-Key: 0x3c49bdd6 X-PGP-Fingerprint: D0D1 3C11 F42F 6B29 FA67 6BF3 AD13 4685 3C49 BDD6 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========6923D2E2333A68131102==========" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: INPCB panic.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:37:32 -0000 --==========6923D2E2333A68131102========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I removed my wi0 card (with DHCLIENT running), and got the following panic=20 on a -CURRENT from yesterday: Script started on Mon Nov 10 13:23:10 2003 lerlaptop-red# k??[K?? lerlaptop-red# gdb -k kernel.0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain=20 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xc5157040 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc06165ba stack pointer =3D 0x10:0xe1831af4 frame pointer =3D 0x10:0xe1831b38 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1278 (dhclient) panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer =3D 0x8:0xc06e4d34 stack pointer =3D 0x10:0xe1831874 frame pointer =3D 0x10:0xe1831880 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D IOPL =3D 0 current process =3D 1278 (dhclient) panic: from debugger Uptime: 4h10m1s Dumping 503 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320=20 336 352 368 384 400 416 432 448 464 480 496 --- Reading symbols from=20 /usr/obj/usr/src/sys/LERLAPTOP/modules/usr/src/sys/modules/linux/linux.ko.d ebug...done. Loaded symbols for=20 /usr/obj/usr/src/sys/LERLAPTOP/modules/usr/src/sys/modules/linux/linux.ko.d ebug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0588f02 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0589237 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc04720a2 in db_panic () at /usr/src/sys/ddb/db_command.c:450 #4 0xc0472002 in db_command (last_cmdp=3D0xc07ae580, cmd_table=3D0x0, aux_cmd_tablep=3D0xc075e58c, aux_cmd_tablep_end=3D0xc075e590) at /usr/src/sys/ddb/db_command.c:346 #5 0xc0472145 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472 #6 0xc0475145 in db_trap (type=3D12, code=3D0) at = /usr/src/sys/ddb/db_trap.c:73 #7 0xc06e4a7c in kdb_trap (type=3D12, code=3D0, regs=3D0xe1831ab4) at /usr/src/sys/i386/i386/db_interface.c:171 #8 0xc06f7b86 in trap_fatal (frame=3D0xe1831ab4, eva=3D0) at /usr/src/sys/i386/i386/trap.c:816 #9 0xc06f7852 in trap_pfault (frame=3D0xe1831ab4, usermode=3D0, = eva=3D3306516544) at /usr/src/sys/i386/i386/trap.c:735 #10 0xc06f7435 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 0, tf_esi =3D = -33322801,=20 tf_ebp =3D -511501512, tf_isp =3D -511501600, tf_ebx =3D -996562916, tf_edx = =3D=20 -988424704, tf_ecx =3D -996562976, tf_eax =3D -988450816, tf_trapno =3D 12, = tf_err =3D 0, tf_eip =3D -1067358790, tf_cs =3D 8, tf_eflags =3D 66182, = tf_esp =3D=20 -1043464832, tf_ss =3D -1067974221}) at /usr/src/sys/i386/i386/trap.c:420 #11 0xc06e6478 in calltrap () at {standard input}:94 #12 0xc062c102 in udp_output (inp=3D0xc499a7e0, m=3D0xc1cf4800,=20 addr=3D0xc47d1380, ---Type to continue, or q to quit--- control=3D0xfe0388cf, td=3D0xc4d5ab40) at=20 /usr/src/sys/netinet/udp_usrreq.c:779 #13 0xc062cad7 in udp_send (so=3D0x0, flags=3D0, m=3D0xc1cf4800, = addr=3D0x0, control=3D0x0, td=3D0x0) at /usr/src/sys/netinet/udp_usrreq.c:1044 #14 0xc05c177d in sosend (so=3D0xc4998dd0, addr=3D0xc47d1380, = uio=3D0xe1831c48, top=3D0xc1cf4800, control=3D0x0, flags=3D0, td=3D0xc4d5ab40) at /usr/src/sys/kern/uipc_socket.c:715 #15 0xc05c5c6c in kern_sendit (td=3D0xc4d5ab40, s=3D5, mp=3D0xe1831cc0, = flags=3D0, control=3D0x0) at /usr/src/sys/kern/uipc_syscalls.c:722 #16 0xc05c5abe in sendit (td=3D0x0, s=3D0, mp=3D0xe1831cc0, flags=3D0) at /usr/src/sys/kern/uipc_syscalls.c:662 #17 0xc05c5dfb in sendto (td=3D0x0, uap=3D0x0) at /usr/src/sys/kern/uipc_syscalls.c:783 #18 0xc06f7ed0 in syscall (frame=3D {tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 135203427, = tf_esi =3D=20 135390029, tf_ebp =3D -1077946280, tf_isp =3D -511500940, tf_ebx =3D = -1077945840,=20 tf_edx =3D 135581776, tf_ecx =3D 0, tf_eax =3D 133, tf_trapno =3D 0, tf_err = =3D 2,=20 tf_eip =3D 134802611, tf_cs =3D 31, tf_eflags =3D 646, tf_esp =3D = -1077946324,=20 tf_ss =3D 47}) at /usr/src/sys/i386/i386/trap.c:1010 #19 0xc06e64cd in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- (kgdb) quit lerlaptop-red# ^D??exit Script done on Mon Nov 10 13:23:44 2003 I have the core and kernel available if some kind soul wants it... LER --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 --==========6923D2E2333A68131102========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/r+j2rRNGhTxJvdYRAngzAJ0czm6utF3aAp7VZBGFoVD97aQFUACdEZfF h5cdC3gkCMIbVAi7k+AA6AI= =RuMW -----END PGP SIGNATURE----- --==========6923D2E2333A68131102==========-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:44:28 2003 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 1853716A4CE; Mon, 10 Nov 2003 11:44:28 -0800 (PST) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78AB43FD7; Mon, 10 Nov 2003 11:44:26 -0800 (PST) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 4B1A322827; Mon, 10 Nov 2003 20:44:25 +0100 (CET) Date: Mon, 10 Nov 2003 20:43:57 +0100 From: Dimitry Andric X-Mailer: The Bat! (v2.01.26) Business X-Priority: 3 (Normal) Message-ID: <17843865455.20031110204357@andric.com> To: Harti Brandt In-Reply-To: <20031110150043.T29745@beagle.fokus.fraunhofer.de> References: <18123090602.20031110145743@andric.com> <20031110150043.T29745@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------D51223631FCA96E" cc: FreeBSD Current List Subject: Re: Buildworld errors out on libbsnmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:44:28 -0000 X-List-Received-Date: Mon, 10 Nov 2003 19:44:28 -0000 ------------D51223631FCA96E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2003-11-10 at 15:02:06 Harti Brandt wrote: > Sorry, that was my error. I have committed a fix for the library, > one for the daemon follows in a couple of minutes as soon as I have > verified that it builds the universe. Builds fine here now, too. Thanks for the quick fix! ------------D51223631FCA96E Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQE/r+p9sF6jCi4glqMRAk7lAJwNr7jjhmCPZEBEl72fc2dB90gOBACdGCLR MS7dXhpquoXPWnzx2+1J6a0= =O9to -----END PGP MESSAGE----- ------------D51223631FCA96E-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:44:30 2003 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 E465A16A4CE; Mon, 10 Nov 2003 11:44:30 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A8C43FB1; Mon, 10 Nov 2003 11:44:28 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAAJiQNJ050590; Mon, 10 Nov 2003 21:44:26 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAAJiQnH050589; Mon, 10 Nov 2003 21:44:26 +0200 (SAST) (envelope-from jhay) Date: Mon, 10 Nov 2003 21:44:26 +0200 From: John Hay To: John Baldwin Message-ID: <20031110194426.GA50381@zibbi.icomtek.csir.co.za> References: <20031110170538.GA44941@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: current@FreeBSD.org Subject: Re: New interrupt stuff breaks ASUS 2 CPU system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:44:31 -0000 On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: > > On 10-Nov-2003 John Hay wrote: > >> > >> With the new interrupt code I get: > >> <...> > >> OK boot > >> cpuid = 0; apic id = 00 > >> instruction pointer = 0x0:0xa00 > >> stack pointer = 0x0:0xffe > >> frame pointer = 0x0:0x0 > >> code segment = base 0x0, limit 0x0, type 0x0 > >> = DPL 0, pres 0, def32 0, gran 0 > >> processor eflags = interrupt enabled, vm86, IOPL = 0 > >> current process = 0 () > >> kernel: type 30 trap, code=0 > >> Stopped at 0xa00: cli > >> db> tr > >> (null)(0,0,0,0,0) at 0xa00 > >> <...> > >> > >> However, if I enter 'continue' at the DDB prompt it continues to boot > >> and the system seems to runs fine: > >> > >> <...> > >> db> continue > > ... > >> Copyright (c) 1992-2003 The FreeBSD Project. > >> <...> > >> > > > > Now why didn't I think of trying 'continue'? Hey there my old dual > > Pentium I diskless machine is running in SMP mode. > > Can you try this patch: > > http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a "panic: probing for non-PCI bus" when booting. :-) John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:45:55 2003 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 8039E16A4CE for ; Mon, 10 Nov 2003 11:45:55 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id ECD8443FD7 for ; Mon, 10 Nov 2003 11:45:51 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 30559 invoked from network); 10 Nov 2003 19:45:50 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Nov 2003 19:45:50 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Nov 2003 13:45:48 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <3FAF62BE.BEA1B3EE@pipeline.ch> Message-ID: <20031110133307.R1101@odysseus.silby.com> References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:45:55 -0000 On Mon, 10 Nov 2003, Andre Oppermann wrote: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > > > This should help make synfloods with random source addresses less > > damaging. > > The cache will only be updated if the tcp connection is being closed. > All updates are done in tcp_drop. The T/TCP updates have to be done > inline during connection setup. I've converted all places which > updated the T/TCP rtmetrics in routing table with updates to the > hostcache. Good, that's exactly how it should work. > > Would it be possible to provide a way for netstat to view the host cache > > table? I think that it would be useful. > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > Syncache ain't visible via netstat either. So far you had to use > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > sure whether netstat is the right place for it. But I can do that > in a second step. Ok, that should be good enough for now. > The actually solves the problem. Let me explain in more detail. When > we get so many small packets per second the CPU will become pretty > saturated. Depending on how much data is sent it can go on for minutes > or hours. This code jumps in there and disconnects the within a second. > Of course someone can immediatly reconnect and do it again. But that > needs the 3WHS again and gives some delay. In the end this code is > like the ICMP rate limiter code. It there to migitate a problem to > manageable level, not to make it go away. Ok, so the problem is that the sockbuf chain keeps getting longer, causing the delay to grow as more fragments pile in... I see now. I drop my objection to it. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:57:37 2003 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 6D89C16A4CE for ; Mon, 10 Nov 2003 11:57:37 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536AE43F93 for ; Mon, 10 Nov 2003 11:57:36 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hAAJvQeF067350; Mon, 10 Nov 2003 11:57:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200311101957.hAAJvQeF067350@gw.catspoiler.org> Date: Mon, 10 Nov 2003 11:57:26 -0800 (PST) From: Don Lewis To: l.ertl@univie.ac.at In-Reply-To: <20031110153808.A22613@pcle2.cc.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: named pipes memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:57:37 -0000 X-List-Received-Date: Mon, 10 Nov 2003 19:57:37 -0000 On 10 Nov, Lukas Ertl wrote: > Hi, > > is there a known problem with named pipes in -CURRENT? > > The following shell script freezes a machine in several minutes and needs > a power cycle. You can see the increasing memory in vmstat -z (unpcb) and > netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003. > > ---8<--- > #/bin/sh > > FIFO=/tmp/foo > > for i in `jot 50000 1`; do > mkfifo ${FIFO} > echo blubb > ${FIFO} & > kill $! > rm ${FIFO} > done > ---8<--- If fifo_open() is interrupted, fifo_close() never gets called, and the resources are not recovered. I wish doing the resource recovery in fifo_inactive() would have worked ... Try this patch: Index: sys/fs/fifofs/fifo_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.89 diff -u -r1.89 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 17:17:09 -0000 1.89 +++ sys/fs/fifofs/fifo_vnops.c 10 Nov 2003 19:11:00 -0000 @@ -154,6 +154,26 @@ } /* + * Dispose of fifo resources. + * Should be called with vnode locked + */ +static void +fifo_cleanup(struct vnode *vp) +{ + struct fifoinfo *fip = vp->v_fifoinfo; + + VI_LOCK(vp); + if (vp->v_usecount == 1) { + vp->v_fifoinfo = NULL; + VI_UNLOCK(vp); + (void)soclose(fip->fi_readsock); + (void)soclose(fip->fi_writesock); + FREE(fip, M_VNODE); + } else + VI_UNLOCK(vp); +} + +/* * Open called to set up a new instance of a fifo or * to find an active instance of a fifo. */ @@ -249,6 +269,7 @@ fip->fi_readers--; if (fip->fi_readers == 0) socantsendmore(fip->fi_writesock); + fifo_cleanup(vp); return (error); } VI_LOCK(vp); @@ -268,6 +289,7 @@ fip->fi_writers--; if (fip->fi_writers == 0) socantrcvmore(fip->fi_readsock); + fifo_cleanup(vp); return (error); } /* @@ -554,15 +576,7 @@ if (fip->fi_writers == 0) socantrcvmore(fip->fi_readsock); } - VI_LOCK(vp); - if (vp->v_usecount == 1) { - vp->v_fifoinfo = NULL; - VI_UNLOCK(vp); - (void)soclose(fip->fi_readsock); - (void)soclose(fip->fi_writesock); - FREE(fip, M_VNODE); - } else - VI_UNLOCK(vp); + fifo_cleanup(vp); VOP_UNLOCK(vp, 0, td); return (0); } From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 11:57:42 2003 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 7255116A4CE for ; Mon, 10 Nov 2003 11:57:42 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6482043FBD for ; Mon, 10 Nov 2003 11:57:41 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hAAJvd0x016111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 Nov 2003 11:57:40 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Larry Rosenman , freebsd-current@freebsd.org Date: Mon, 10 Nov 2003 11:59:44 -0800 User-Agent: KMail/1.5.3 References: <22330000.1068493043@lerlaptop-red.iadfw.net> In-Reply-To: <22330000.1068493043@lerlaptop-red.iadfw.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311101159.44366.sam@errno.com> Subject: Re: INPCB panic.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:57:42 -0000 On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: > I removed my wi0 card (with DHCLIENT running), and got the following panic > on a -CURRENT from yesterday: Thanks. Working on it... Sam From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:15:57 2003 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 DBB5116A4CE; Mon, 10 Nov 2003 12:15:57 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1472143F93; Mon, 10 Nov 2003 12:15:56 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hAAKFt8i003701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 15:15:55 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hAAKFqH7003700; Mon, 10 Nov 2003 15:15:52 -0500 (EST) Date: Mon, 10 Nov 2003 15:15:52 -0500 From: Leo Bicknell To: Mike Silbersack Message-ID: <20031110201552.GA3148@ussenterprise.ufp.org> Mail-Followup-To: Mike Silbersack , Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org, mb@imp.ch, ume@freebsd.org, sam@errno.com References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> <20031110133307.R1101@odysseus.silby.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20031110133307.R1101@odysseus.silby.com> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 20:15:58 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbers= ack wrote: > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > Syncache ain't visible via netstat either. So far you had to use > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > sure whether netstat is the right place for it. But I can do that > > in a second step. >=20 > Ok, that should be good enough for now. I'm not going to say it's not good enough, but more than once the whole "route get" thing has been quite inconveniant, so I'll put in a big vote that both be available in easy to get table form from some command line utility (netstat seems like a good place). --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/r/H4Nh6mMG5yMTYRAjMXAJwNWp3urXL4WURTIk8Yrps++yIkvACfb6yS 1XlKdJtg5pBFczc59On+4TY= =Bgwr -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:29:59 2003 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 730B916A4CF for ; Mon, 10 Nov 2003 12:29:59 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A937343F75 for ; Mon, 10 Nov 2003 12:29:55 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 67716 invoked from network); 10 Nov 2003 20:32:44 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 20:32:44 -0000 Message-ID: <3FAFF523.C3FF55F3@pipeline.ch> Date: Mon, 10 Nov 2003 21:29:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Leo Bicknell References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> <20031110133307.R1101@odysseus.silby.com> <20031110201552.GA3148@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org cc: Mike Silbersack Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 20:29:59 -0000 Leo Bicknell wrote: > > In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > > Syncache ain't visible via netstat either. So far you had to use > > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > > sure whether netstat is the right place for it. But I can do that > > > in a second step. > > > > Ok, that should be good enough for now. > > I'm not going to say it's not good enough, but more than once the whole > "route get" thing has been quite inconveniant, so I'll put in a big vote > that both be available in easy to get table form from some command line > utility (netstat seems like a good place). I'll look into that when 5.2 is in code freeze. Can then put it in afterwards. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 12:49:08 2003 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 4B32816A4CE for ; Mon, 10 Nov 2003 12:49:08 -0800 (PST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [193.162.153.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D877043F3F for ; Mon, 10 Nov 2003 12:49:06 -0800 (PST) (envelope-from esbjerg@xbsd.net) Received: from xbsd.net (0x50a16596.boanxx13.adsl-dhcp.tele.dk [80.161.101.150]) by pfepb.post.tele.dk (Postfix) with ESMTP id F05C95EE346 for ; Mon, 10 Nov 2003 21:49:01 +0100 (CET) Received: by xbsd.net (Postfix, from userid 1000) id 77C353DF2D; Mon, 10 Nov 2003 21:49:01 +0100 (CET) Date: Mon, 10 Nov 2003 21:49:01 +0100 From: Sven Esbjerg To: current@freebsd.org Message-ID: <20031110204901.GA31933@gosling.home.xbsd.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: ddb and usb keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 20:49:08 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I primarily use a usb keyboard on my PC. After an upgrade this weekend the kernel paniced and went into ddb. Unfortunately the usb keyboard does not work in ddb mode. Thus I can only pull the plug :( MB is a Supermicro P3TDDE with two PIII 800MHz CPU's. Chipset is: # dmesg |grep VIA acpi0: on motherboard agp0: mem 0xf0000000-0xf3ffffff at device 0.0 on pci0 uhci0: port 0xb800-0xb81f irq 11 at device 17.2 on pci0 usb0: on uhci0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhci1: port 0xbc00-0xbc1f irq 11 at device 17.3 on pci0 usb1: on uhci1 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhci2: port 0xc000-0xc01f irq 11 at device 17.4 on pci0 usb2: on uhci2 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 keyboard is a Sun Type 6 keyboard. dmesg is attached. Sven Esbjerg --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="enzo.dmesg" Copyright (c) 1992-2003 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.1-CURRENT #0: Tue Oct 28 21:33:03 CET 2003 root@enzo.home.xbsd.net:/usr/src/sys/i386/compile/ENZO.DBG Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc08e1000. Preloaded elf module "/boot/kernel.old/acpi.ko" at 0xc08e11f8. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (801.82-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 1073676288 (1023 MB) avail memory = 1033502720 (985 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec00000 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdef0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_cpu1: port 0x530-0x537 on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 11 -> irq 2 IOAPIC #0 intpin 10 -> irq 5 IOAPIC #0 intpin 5 -> irq 10 IOAPIC #0 intpin 12 -> irq 11 agp0: mem 0xf0000000-0xf3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) adv0: port 0x9000-0x90ff mem 0xfa221000-0xfa2210ff irq 2 at device 7.0 on pci0 adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 pcm0: port 0x9400-0x941f irq 5 at device 8.0 on pci0 pcm0: pci0: at device 10.0 (no driver attached) atapci0: port 0xac00-0xac3f,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c07 mem 0xfa200000-0xfa21ffff irq 5 at device 12.0 on pci0 atapci0: [MPSAFE] ata2: at 0x9c00 on atapci0 ata2: [MPSAFE] ata3: at 0xa400 on atapci0 ata3: [MPSAFE] fxp0: port 0xb000-0xb03f mem 0xfa100000-0xfa1fffff,0xfa220000-0xfa220fff irq 11 at device 13.0 on pci0 fxp0: Ethernet address 00:30:48:41:b9:ba miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0xb400-0xb40f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] uhci0: port 0xb800-0xb81f irq 11 at device 17.2 on pci0 uhci0: LegSup = 0x2010 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub1: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 uhub1: 4 ports with 4 removable, self powered ugen0: OmniVision OV511+ Camera, rev 1.00/1.00, addr 3 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 ums0: Logitech USB Mouse, rev 1.10/6.10, addr 4, iclass 3/1 ums0: 4 buttons and Z dir. uhci1: port 0xbc00-0xbc1f irq 11 at device 17.3 on pci0 uhci1: LegSup = 0x2010 usb1: on uhci1 usb1: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhub2: port error, restarting port 1 uhub2: port error, giving up port 1 uhub2: port error, restarting port 2 uhub2: port error, giving up port 2 uhci2: port 0xc000-0xc01f irq 11 at device 17.4 on pci0 uhci2: LegSup = 0x2010 usb2: on uhci2 usb2: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhub3: port error, restarting port 1 uhub3: port error, giving up port 1 uhub3: port error, restarting port 2 uhub3: port error, giving up port 2 fdc0: port 0x3f7,0x3f0-0x3f5 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 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] Option "ForcePCIMode" "true" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] Option "AGPSize" "64" # #Option "RingSize" # #Option "BufferSize" "4" #vertex # #Option "EnableDepthMoves" # [] #Option "EnablePageFlip" # [] #Option "NoBackBuffer" # [] #Option "PanelOff" # [] #Option "DDCMode" # [] #Option "CloneDisplay" # #Option "CloneMode" # [] #Option "CloneHSync" # [] #Option "CloneVRefresh" # [] #Option "UseFBDev" # [] #Option "VideoKey" # Identifier "Card0" Driver "radeon" #"ati" VendorName "ATI Technologies Inc" BoardName "Radeon R200 QL [Radeon 8500 LE]" BusID "PCI:2:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Depth 16 EndSubSection SubSection "Display" Depth 24 Modes "1280x960"#"1120x840" EndSubSection EndSection Section "DRI" Mode 0666 EndSection --------------010702090408040503040004-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 19:46:13 2003 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 467C516A4CE for ; Tue, 11 Nov 2003 19:46:13 -0800 (PST) Received: from smtp1.btinet.net (mail.gnda.com [216.235.160.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F4343F75 for ; Tue, 11 Nov 2003 19:46:12 -0800 (PST) (envelope-from pmes@btinet.net) Received: from exim by smtp1.btinet.net with spam-scanned (Exim 4.24) id 1AJlxL-0005yq-G2 for current@freebsd.org; Tue, 11 Nov 2003 21:46:11 -0600 Received: from ar11-bsmrnd.l1.btigate.com ([209.62.224.243] helo=btinet.net) by smtp1.btinet.net with esmtp (Exim 4.24) id 1AJlxL-0005yZ-2M for current@freebsd.org; Tue, 11 Nov 2003 21:46:11 -0600 Message-ID: <3FB1AD01.6000403@btinet.net> Date: Tue, 11 Nov 2003 21:46:09 -0600 From: Peter Schultz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6a) Gecko/20031104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on smtp1.btinet.net X-Spam-Status: No, hits=0.0 required=10.0 tests=none autolearn=no version=2.60 Subject: floppy install troubles X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 03:46:13 -0000 I'm having trouble installing with the 5.1-CURRENT-20031110-JPSNAP floppies I got off snapshots.jp.freebsd.org. First off, I tried to create a new slice and it wants to use /dev/ad0p1. I don't believe the p is correct. I tried again without changing the slices at all, and when newfs ran the install stopped with this error: "newfs: Cannot retrieve operator gid". Thanks, Pete... From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:23:13 2003 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 D3F8A16A4DB for ; Tue, 11 Nov 2003 20:23:13 -0800 (PST) Received: from marge.icomtek.csir.co.za (marge.icomtek.csir.co.za [146.64.28.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 839EF43F93 for ; Tue, 11 Nov 2003 20:23:11 -0800 (PST) (envelope-from jhugo@icomtek.csir.co.za) Received: from jeep.icomtek.csir.co.za (jeep.icomtek.csir.co.za [146.64.28.29])hAC4N92v050024 for ; Wed, 12 Nov 2003 06:23:09 +0200 (SAST) (envelope-from jhugo@icomtek.csir.co.za) Content-Type: text/plain; charset="iso-8859-1" From: Johann Hugo Date: Wed, 12 Nov 2003 06:23:09 +0200 X-Mailer: KMail [version 1.4] To: current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311120623.09159.jhugo@icomtek.csir.co.za> Subject: Re: atheros (ath) driver - media option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 04:23:14 -0000 On Wednesday 12 November 2003 00:54, Sam Leffler wrote: > Not sure what you're trying to accomplish by setting the media when > operating in hostap mode. It should be ignored, but I'm not sure exactly > what will happen. Locking the tx rate on the client side makes more sense > and should be honored correctly. Maybe I should give you some more info here. We currently have a 30km wireless link to a remote site: Lucent/orinoco AP -----30km ----- FreeBSD client with Lucent adapter. The problem is that over that distance the SIFS counter expires on most of the packets before we receive a ACK on the other side. So the throughput is way down. I've decided to installed a parallel/experimental link on another frq. so that I can play around with the atheros driver/cards and also 11g. The second link looks something like this: FreeBSD/HostAP/Atheros ----- 30km ------ FreeBSD/Soekris/Client/Atheros The problem is: (mode 11b media DS/1Mbps) HostAP TX = 11Mbps --------- 30km -----Client RX at 11Mbps not OK HostAP RX at 1Mbps = OK ----- 30km ----- Client TX at 1Mbps (mode 11g media OFDM/6Mbps) HostAP TX = 54Mbps --------- 30km -----Client RX at 54 Mbps not OK HostAP RX at 1Mbps = OK ----- 30km ----- Client RX at 54 Mbps not OK So I am trying to force the max TX rate on both ends to a lower speed. Another question: Do you have control over the SIFS counter. Is there a way to adjust the counter so that it will be more tolerant to longer links, or is it possible to disable the ACK's for unicast packets ? http://lists.nocat.net/pipermail/nocat/2002-April/001223.html Johann From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:36:04 2003 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 B702516A4CE for ; Tue, 11 Nov 2003 20:36:04 -0800 (PST) Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB5A943F93 for ; Tue, 11 Nov 2003 20:36:03 -0800 (PST) (envelope-from ciscogeek@bgp4.net) Received: from bgp4.net ([68.99.195.198]) by fed1mtao04.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031112043603.JLU3905.fed1mtao04.cox.net@bgp4.net> for ; Tue, 11 Nov 2003 23:36:03 -0500 Message-ID: <3FB1B8B3.8090403@bgp4.net> Date: Tue, 11 Nov 2003 21:36:03 -0700 From: Janet Sullivan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200311112149.hABLnZeF070361@gw.catspoiler.org> In-Reply-To: <200311112149.hABLnZeF070361@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 04:36:04 -0000 > I'm not having any problems with my -CURRENT client. My server is > running 4.9-STABLE, so I can't comment on the state of the NFS server > code in -CURRENT. For what it's worth, my NFS usage is not very heavy, > and is mostly reading, with very little writing. So far I only have problems in a mixed -STABLE/-CURRENT environment. When the client & server are both -CURRENT I haven't had any problems. If the client is -CURRENT and the server is -STABLE, I occasionally get very, very slow response times (like 40 seconds to get an ls response). I can't blame the response times on my LAN, because everything else continues to function properly. In fact, I just had to reboot my laptop (running -CURRENT from 2003.10.30.07.10.00) to get my -STABLE nfs mounts back to normal. Are the folks seeing hangs getting any kind of console error messages? I don't see anything - performance just tanks to the point of being unusable. From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 21:39:44 2003 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 6EC8B16A4CE for ; Tue, 11 Nov 2003 21:39:44 -0800 (PST) Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [211.29.132.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE87B43F85 for ; Tue, 11 Nov 2003 21:39:41 -0800 (PST) (envelope-from current1@buggerit.com.au) Received: from ratpak.buggerit.com.au ([198.142.100.160])hAC5ddb14751 for ; Wed, 12 Nov 2003 16:39:39 +1100 Date: Wed, 12 Nov 2003 16:40:01 +1100 From: Taras To: freebsd-current@freebsd.org Message-Id: <20031112164001.726377b4.current1@buggerit.com.au> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: fw_xferq_drain (was data corruption when reading from a mount_cd9660 filesystem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 05:39:44 -0000 Thanks to all that replied. I did have rev 1.153 of atapi-cd.c but was unable to rebuild because of the RB_BOOTINFO thingy. Have re-cvsup'd and all is well reading the CD, many thanks. However what now isn't so well is upon every "reboot" and "shutdown" just after the syncing disks and Uptime is displayed, it drops into the debugger with: instruction pointer = 0x8:0xc0496dae stack pointer = 0x10:0xd89f9adc frame pointer = 0x10:0xd89f9ae8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 763 (reboot) # for reboot current process = 1 (init) # for shutdown -h now kernel: type 30 trap, code=0 Stopped at fw_xferq_drain+0xe: testl %edx,%edx Since this happens after the disks are sync'd the system boots OK. > G'day, > It appears that files with size greater than 65536 bytes when read from > a cd9660 mounted filesystem appear corrupted. > Happens on any cd-rom I try regardless of where it was burnt, > even the original 5.1-RELEASE-i386-miniinst.iso now appears corrupt. > > [...snip...] > regards, Taras From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 22:04:12 2003 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 2EB3516A4CE; Tue, 11 Nov 2003 22:04:12 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B1EC43FA3; Tue, 11 Nov 2003 22:04:10 -0800 (PST) (envelope-from delphij@frontfree.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id 04B3052D3; Wed, 12 Nov 2003 14:04:08 +0800 (CST) Received: from srv (unknown [202.112.73.151]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id 931085299; Wed, 12 Nov 2003 14:04:07 +0800 (CST) From: "=?utf-8?B?WGluIExJL+adjumRqw==?=" To: Date: Wed, 12 Nov 2003 14:04:07 +0800 Organization: Frontfree Technology Network MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcOo4siCf3D+sRCtTy+nOmwNB16drA== Message-Id: <20031112060407.931085299@ftp.bjpu.edu.cn> cc: jhb@FreeBSD.org Subject: Recent -CURRENT panic (New interrupt code related?); backtrace included X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 06:04:12 -0000 Hello, On recently compiled kernels, I often get panics which seemed to be = interrupt related. Among other things, almost all of them claims that = "Kernel trap 30", which seemd to be strange.=20 The kernel I am currently running, namely, FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat = Oct 25 22:27:05 CST 2003 = delphij@servers.frontfree.net:/usr/obj/usr/src/sys/SERVERS i386 seemed to be ok, however, when I am trying the new kernels (you see, 14 = compile and run attempts:), it exhibits incredible instablity. FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003 delphij@servers.frontfree.net:/usr/obj/usr/src/sys/SERVERS Here is one of the crashdumps I caught. The machine was configured with = a UP kernel, with DEVICE_POLLING enabled. There are two networking = adapters attached to it, a fxp and a dc, and the machine itself act as a = NAT gateway. The network load is not very heavy. If you think the = backtrace helpful, or need any more information, please write me and I = will try everything I can to help. servers# gdb -k /usr/obj/usr/src/sys/SERVERS/kernel.debug vmcore.0=20 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "i386-undermydesk-freebsd"... panic: from debugger panic messages: --- panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer =3D 0x8:0xc0639654 stack pointer =3D 0x10:0xc6305a98 frame pointer =3D 0x10:0xc6305aa4 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D IOPL =3D 0 current process =3D 11 (idle) panic: from debugger Uptime: 23m22s Dumping 63 MB 16 32 48 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04e8b41 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450 #4 0xc04641b2 in db_command (last_cmdp=3D0xc06cc440, cmd_table=3D0x0, = aux_cmd_tablep=3D0xc069d338,=20 aux_cmd_tablep_end=3D0xc069d33c) at = /usr/src/sys/ddb/db_command.c:346 #5 0xc04642f5 in db_command_loop () at = /usr/src/sys/ddb/db_command.c:472 #6 0xc04672e5 in db_trap (type=3D30, code=3D0) at = /usr/src/sys/ddb/db_trap.c:73 #7 0xc063939c in kdb_trap (type=3D30, code=3D0, regs=3D0xc6305ca0) at = /usr/src/sys/i386/i386/db_interface.c:171 #8 0xc064cda6 in trap_fatal (frame=3D0xc6305ca0, eva=3D0) at = /usr/src/sys/i386/i386/trap.c:816 #9 0xc064c822 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 1075970064, tf_ds =3D -1636237296, tf_edi = =3D 0, tf_esi =3D -1059059840, tf_ebp =3D -969909024, tf_isp =3D = -969909044, tf_ebx =3D -1059063048, tf_edx =3D 0, tf_ecx =3D 2, tf_eax = =3D 0, tf_trapno =3D 30, tf_err =3D 0, tf_eip =3D -1067175531, tf_cs =3D = 8, tf_eflags =3D 582, tf_esp =3D -969909016, tf_ss =3D -1067175489}) at /usr/src/sys/i386/i386/trap.c:618 #10 0xc063ad58 in calltrap () at {standard input}:94 #11 0xc06431bf in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1071 #12 0xc04d449c in idle_proc (dummy=3D0x0) at = /usr/src/sys/kern/kern_idle.c:86 #13 0xc04d41d4 in fork_exit (callout=3D0xc04d4460 , = arg=3D0x0, frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:793 (kgdb) bt full #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 No locals. #1 0xc04e8b41 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:372 No locals. #2 0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 td =3D (struct thread *) 0xc0e00780 bootopt =3D 260 newpanic =3D 0 ap =3D 0xc6305ae0 "\230[0=E6=92=87AF=E7=B9=BA2251d? buf =3D "from debugger", '\0' #3 0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450 No locals. #4 0xc04641b2 in db_command (last_cmdp=3D0xc06cc440, cmd_table=3D0x0, = aux_cmd_tablep=3D0xc069d338,=20 aux_cmd_tablep_end=3D0xc069d33c) at = /usr/src/sys/ddb/db_command.c:346 cmd =3D (struct command *) 0xc06658c0 t =3D 0 modif =3D = "\0=E8=9A=BB=E7=BA=87\231r?[0=E8=8A=A2r\0\0\0=E7=89=93q=E7=B9=BAr\0\0\0\0= 01\0\0\0H[0=E8=8A=95=E9=8F=B1=E7=B9=BA200\214q=E7=B9=BAaK\0 = $=EE=9B=97=E7=B1=BBrp=E7=BD=93=E8=9A=BB=E7=BA=97\0\0\0=E7=8A=95l=E7=BA=87= \231r=E7=BA=8B[0=E8=92=B2`F=E7=BA=9E\234h=E7=B9=BA200^F=E7=B9=BA0\0\0\0\0= 20\0\0\0h\231r=E7=BD=93=E8=9A=BB=E6=A2=A8WF=E7=BD=93=E8=9A=BB=E7=B9=BA200= =E8=94=BF=E7=BA=97\0\0\0\020\0\0" addr =3D -1067175531 count =3D -1 have_addr =3D 0 result =3D 0 #5 0xc04642f5 in db_command_loop () at = /usr/src/sys/ddb/db_command.c:472 No locals. #6 0xc04672e5 in db_trap (type=3D30, code=3D0) at = /usr/src/sys/ddb/db_trap.c:73 bkpt =3D 0 #7 0xc063939c in kdb_trap (type=3D30, code=3D0, regs=3D0xc6305ca0) at = /usr/src/sys/i386/i386/db_interface.c:171 ef =3D 582 ddb_mode =3D 1 #8 0xc064cda6 in trap_fatal (frame=3D0xc6305ca0, eva=3D0) at = /usr/src/sys/i386/i386/trap.c:816 code =3D 16 type =3D 30 ss =3D 16 esp =3D 0 softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D = 27, ssd_dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 3,=20 ---Type to continue, or q to quit--- ssd_xx1 =3D 2, ssd_def32 =3D 1, ssd_gran =3D 1} #9 0xc064c822 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 1075970064, tf_ds =3D -1636237296, tf_edi = =3D 0, tf_esi =3D -1059059840, tf_ebp =3D -969909024, tf_isp =3D = -969909044, tf_ebx =3D -1059063048, tf_edx =3D 0, tf_ecx =3D 2, tf_eax = =3D 0, tf_trapno =3D 30, tf_err =3D 0, tf_eip =3D -1067175531, tf_cs =3D = 8, tf_eflags =3D 582, tf_esp =3D -969909016, tf_ss =3D -1067175489}) at /usr/src/sys/i386/i386/trap.c:618 td =3D (struct thread *) 0xc0e00780 p =3D (struct proc *) 0xc0dffaf8 sticks =3D 3235907456 i =3D 0 ucode =3D 0 type =3D 30 code =3D 0 eva =3D 0 #10 0xc063ad58 in calltrap () at {standard input}:94 No locals. #11 0xc06431bf in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1071 No locals. #12 0xc04d449c in idle_proc (dummy=3D0x0) at = /usr/src/sys/kern/kern_idle.c:86 p =3D (struct proc *) 0xc0dffaf8 td =3D (struct thread *) 0xc0e00780 #13 0xc04d41d4 in fork_exit (callout=3D0xc04d4460 , = arg=3D0x0, frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:793 p =3D (struct proc *) 0xc0dffaf8 td =3D (struct thread *) 0x0 From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 22:29:50 2003 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 E4F8B16A4CE; Tue, 11 Nov 2003 22:29:50 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id F206343FB1; Tue, 11 Nov 2003 22:29:47 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hAC6Tlv9079744; Wed, 12 Nov 2003 01:29:47 -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 hAC6Tk2u079743; Wed, 12 Nov 2003 01:29:46 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 01:29:46 -0500 (EST) Message-Id: <200311120629.hAC6Tk2u079743@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, alpha@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 06:29:51 -0000 TB --- 2003-11-12 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-12 05:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 05:02:05 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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 --- 2003-11-12 06:06:25 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 06:06:26 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 06:18:21 GMT 2003 TB --- 2003-11-12 06:18:21 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 06:18:21 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 06:18:21 GMT 2003 [...] xform.o: In function `rijndael128_decrypt': xform.o(.text+0x9b8): undefined reference to `rijndael_decrypt' xform.o(.text+0x9bc): undefined reference to `rijndael_decrypt' xform.o: In function `rijndael128_setkey': xform.o(.text+0xa44): undefined reference to `rijndael_set_key' xform.o(.text+0xa48): undefined reference to `rijndael_set_key' xform.o(.text+0xa68): undefined reference to `rijndael_set_key' xform.o(.text+0xa6c): undefined reference to `rijndael_set_key' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-12 06:29:46 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 06:29:46 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-12 06:29:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 22:51:49 2003 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 A3AF916A4CE for ; Tue, 11 Nov 2003 22:51:49 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8580E43F93 for ; Tue, 11 Nov 2003 22:51:46 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAC6phNJ016382; Wed, 12 Nov 2003 08:51:43 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAC6pgxc016381; Wed, 12 Nov 2003 08:51:42 +0200 (SAST) (envelope-from jhay) Date: Wed, 12 Nov 2003 08:51:42 +0200 From: John Hay To: Doug White Message-ID: <20031112065142.GA16030@zibbi.icomtek.csir.co.za> References: <20031111183603.GA92144@zibbi.icomtek.csir.co.za> <20031111203859.GA97150@zibbi.icomtek.csir.co.za> <20031111175046.J66327@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031111175046.J66327@carver.gumbysoft.com> User-Agent: Mutt/1.4i cc: current@FreeBSD.org Subject: Re: panic: probing for non-PCI bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 06:51:49 -0000 > > > > >> >> > acpi0: on motherboard > > Here's the mobo model. > > you might check for a BIOS update... Nope, I'm running the latest - 1008. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 23:01:30 2003 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 DAD1E16A4CE; Tue, 11 Nov 2003 23:01:30 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A07443FDD; Tue, 11 Nov 2003 23:01:28 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAC71PNJ016724; Wed, 12 Nov 2003 09:01:26 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAC71P9L016723; Wed, 12 Nov 2003 09:01:25 +0200 (SAST) (envelope-from jhay) Date: Wed, 12 Nov 2003 09:01:25 +0200 From: John Hay To: John Baldwin Message-ID: <20031112070125.GB16030@zibbi.icomtek.csir.co.za> References: <20031111203859.GA97150@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: current@FreeBSD.org Subject: Re: panic: probing for non-PCI bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 07:01:31 -0000 > > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in > > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. > > > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. > I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps > there is a BIOS option to set the interrupt model to APIC rather than PIC that > might fix the ACPI case. Ok, I opened the machine this morning and it does have an AGP slot. I also had a look in the BIOS setup, but didn't see anything to change the interrupt model. The closest I saw was: MPS 1.4 Support - Enabled/Disabled (Enabled) PCI 2.1 Support - Enabled/disabled (Enabled) PNP OS Installed - No/Yes (No) I built a new kernel with your mptable changes included and with acpi enabled, it would panic, but the onboard scsi interrupt doesn't work, so you don't get very far. With acpi disabled, it seems to work fine, although I haven't done much yet. So it looks like I'm up and running again, thanks. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 23:21:11 2003 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 6836316A4CE; Tue, 11 Nov 2003 23:21:11 -0800 (PST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 046AF43F75; Tue, 11 Nov 2003 23:21:09 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) hAC7L6NJ017438; Wed, 12 Nov 2003 09:21:06 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id hAC7L6J7017435; Wed, 12 Nov 2003 09:21:06 +0200 (SAST) (envelope-from jhay) Date: Wed, 12 Nov 2003 09:21:06 +0200 From: John Hay To: jhb@freebsd.org Message-ID: <20031112072105.GA17303@zibbi.icomtek.csir.co.za> References: <20031111203859.GA97150@zibbi.icomtek.csir.co.za> <20031112070125.GB16030@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031112070125.GB16030@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.4i cc: current@freebsd.org Subject: Re: panic: probing for non-PCI bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 07:21:11 -0000 Oops, I missed a not. On Wed, Nov 12, 2003 at 09:01:25AM +0200, John Hay wrote: > > > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in > > > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. > > > > > > pcib1: at device 1.0 on pci0 > > > pci1: on pcib1 > > > > Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. > > I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps > > there is a BIOS option to set the interrupt model to APIC rather than PIC that > > might fix the ACPI case. > > Ok, I opened the machine this morning and it does have an AGP slot. > > I also had a look in the BIOS setup, but didn't see anything to change > the interrupt model. The closest I saw was: > > MPS 1.4 Support - Enabled/Disabled (Enabled) > PCI 2.1 Support - Enabled/disabled (Enabled) > PNP OS Installed - No/Yes (No) > > I built a new kernel with your mptable changes included and with acpi > enabled, it would panic, but the onboard scsi interrupt doesn't work, ^^^ not > so you don't get very far. With acpi disabled, it seems to work fine, > although I haven't done much yet. So it looks like I'm up and running > again, thanks. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 23:28:35 2003 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 BC7AC16A4CE for ; Tue, 11 Nov 2003 23:28:35 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD9243F93 for ; Tue, 11 Nov 2003 23:28:34 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id hAC7SYbg040245 for current@freebsd.org; Wed, 12 Nov 2003 01:28:34 -0600 (CST) (envelope-from dan) Date: Wed, 12 Nov 2003 01:28:33 -0600 From: Dan Nelson To: current@freebsd.org Message-ID: <20031112072833.GA19301@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.5.1i Subject: panic: mutex inp not owned at in_pcb.c:685 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 07:28:35 -0000 I'm getting one of these panics every time I cd into an amd mountpoint on one of my machines with today's -current: (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc04fd20f in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc04fd4c7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc04f6248 in _mtx_assert (m=0xc1a238cc, what=0, file=0xc0662af6 "../../../netinet/in_pcb.c", line=685) at ../../../kern/kern_mutex.c:667 #4 0xc05659c7 in in_pcbdetach (inp=0xc1a23820) at ../../../netinet/in_pcb.c:685 #5 0xc057827b in tcp_twclose (tw=0xc1d79000, reuse=0) at ../../../netinet/tcp_subr.c:1725 #6 0xc05660a5 in in_pcblookup_local (pcbinfo=0xc06c36c0, laddr={s_addr = 0}, lport_arg=3248633888, wild_okay=1) at ../../../netinet/in_pcb.c:1002 #7 0xc0565350 in in_pcbbind_setup (inp=0xc1a23680, nam=0xc19254a0, laddrp=0xc1a236b8, lportp=0xc1a2369a, td=0xc1cee640) at ../../../netinet/in_pcb.c:353 #8 0xc0565036 in in_pcbbind (inp=0xc1a23680, nam=0xc19254a0, td=0xc1cee640) at ../../../netinet/in_pcb.c:218 #9 0xc057a7c6 in tcp_usr_bind (so=0x0, nam=0xc19254a0, td=0xc1cee640) at ../../../netinet/tcp_usrreq.c:252 #10 0xc052c59e in sobind (so=0x0, nam=0xc19254a0, td=0xc1cee640) at ../../../kern/uipc_socket.c:230 #11 0xc052fb47 in kern_bind (td=0xc1cee640, fd=8, sa=0xc19254a0) at ../../../kern/uipc_syscalls.c:183 #12 0xc052faf3 in bind (td=0xc1cee640, uap=0xdce90d14) at ../../../kern/uipc_syscalls.c:163 #13 0xc06186cb in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 8, tf_esi = -1077943876, tf_ebp = -1077943860, tf_isp = -588706444, tf_ebx = 1019, tf_edx = -1, tf_ecx = 48, tf_eax = 104, tf_trapno = 12, tf_err = 2, tf_eip = 671989471, tf_cs = 31, tf_eflags = 663, tf_esp = -1077943920, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 #14 0xc06096fd in Xint0x80_syscall () at {standard input}:136 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 00:10:08 2003 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 7A03516A4CE for ; Wed, 12 Nov 2003 00:10:08 -0800 (PST) Received: from ib.com.ua (ib.com.ua [217.144.67.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DCA443FEA for ; Wed, 12 Nov 2003 00:10:06 -0800 (PST) (envelope-from toha@toha.org.ua) Received: from ib.com.ua (localhost.ib.com.ua [127.0.0.1]) by ib.com.ua (8.12.10/8.12.10) with ESMTP id hAC89wLI011123 for ; Wed, 12 Nov 2003 10:09:58 +0200 (EET) (envelope-from toha@toha.org.ua) Received: (from root@localhost) by ib.com.ua (8.12.10/8.12.10/Submit) id hAC89wGT011122 for freebsd-current@freebsd.org; Wed, 12 Nov 2003 10:09:58 +0200 (EET) (envelope-from toha@toha.org.ua) Date: Wed, 12 Nov 2003 10:09:58 +0200 (EET) From: toha@toha.org.ua Message-Id: <200311120809.hAC89wGT011122@ib.com.ua> To: freebsd-current@freebsd.org Subject: release build problems, drivers.flp: file system is full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 08:10:08 -0000 Hi. Release build fails: drivers.flp: file system if full. Can somebody remove some driver from drivers.conf? thanks. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 00:59:41 2003 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 1F38616A4CF for ; Wed, 12 Nov 2003 00:59:41 -0800 (PST) Received: from ib.com.ua (ib.com.ua [217.144.67.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF79043F85 for ; Wed, 12 Nov 2003 00:59:38 -0800 (PST) (envelope-from toha@toha.org.ua) Received: from ib.com.ua (localhost.ib.com.ua [127.0.0.1]) by ib.com.ua (8.12.10/8.12.10) with ESMTP id hAC8xULI012355 for ; Wed, 12 Nov 2003 10:59:30 +0200 (EET) (envelope-from toha@toha.org.ua) Received: (from toha@localhost) by ib.com.ua (8.12.10/8.12.10/Submit) id hAC8xU9I012354 for freebsd-current@freebsd.org; Wed, 12 Nov 2003 10:59:30 +0200 (EET) (envelope-from toha@toha.org.ua) Date: Wed, 12 Nov 2003 10:59:30 +0200 (EET) From: toha@toha.org.ua Message-Id: <200311120859.hAC8xU9I012354@ib.com.ua> X-Authentication-Warning: ib.com.ua: toha set sender to toha@toha.org.ua using -f To: freebsd-current@freebsd.org Subject: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 08:59:41 -0000 Sysinstall fails then attempt to create new file system. error message: cannot get operator gid. how to dial with it? P.S. please, CC me From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:00:30 2003 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 B360B16A4D0; Wed, 12 Nov 2003 01:00:30 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC77443FEC; Wed, 12 Nov 2003 01:00:29 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hAC90Tv9040179; Wed, 12 Nov 2003 04:00:29 -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 hAC90TOR040178; Wed, 12 Nov 2003 04:00:29 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 04:00:29 -0500 (EST) Message-Id: <200311120900.hAC90TOR040178@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, i386@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:00:30 -0000 TB --- 2003-11-12 07:36:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 07:36:59 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-12 07:36:59 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 07:39:12 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/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 --- 2003-11-12 08:41:22 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 08:41:22 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 08:56:09 GMT 2003 TB --- 2003-11-12 08:56:09 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 08:56:09 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 08:56:09 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpi_timer.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdDebug.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdHardware.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdInterrupt.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdInterrupt.c: In function `acpi_OverrideInterruptLevel': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdInterrupt.c:139: error: `_Dbg' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdInterrupt.c:139: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/Osd/OsdInterrupt.c:139: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-11-12 09:00:28 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 09:00:28 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-12 09:00:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:01:29 2003 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 0B74F16A4CF for ; Wed, 12 Nov 2003 01:01:29 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9605943F93 for ; Wed, 12 Nov 2003 01:01:27 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hAC91PU12900 for ; Wed, 12 Nov 2003 10:01:25 +0100 (MET) Date: Wed, 12 Nov 2003 10:01:25 +0100 (CET) From: Harti Brandt To: current@freebsd.org Message-ID: <20031112095711.A33680@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: HEADSUP: netgraph constants changing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:01:29 -0000 Hi all, as I've written a couple of days ago I'm going to bump some constants in the netgraph code that defined various name lengths in the next minutes. I've not received any negative feedback and have the ok from re. If you use netgraph make sure that the kernel, any externally maintained netgraph modules and any user space netgraph stuff (mainly ngctl and nghook) are in sync otherwise they'll not be able to communicate. This is especially important if you use netgraph for booting purposes. No correctly written code should break by this change :-) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:10:38 2003 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 D9C9C16A4CF for ; Wed, 12 Nov 2003 01:10:38 -0800 (PST) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B075443F85 for ; Wed, 12 Nov 2003 01:10:37 -0800 (PST) (envelope-from jqdkf@army.com) Received: from cactus (qmailr@167-94.priv19.nus.edu.sg [172.19.167.94]) by leonis.nus.edu.sg (8.12.9/8.12.9) with SMTP id hAC9AZo5000824 for ; Wed, 12 Nov 2003 17:10:36 +0800 (SGT) Received: (qmail 4463 invoked by uid 1000); 12 Nov 2003 09:10:32 -0000 From: jqdkf@army.com Date: Wed, 12 Nov 2003 17:10:32 +0800 To: current@freebsd.org Message-ID: <20031112091032.GA4425@cactus> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: xscreensaver bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:10:39 -0000 Hi, I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? Regards, -- Zeng Nan Simple is Beautiful. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:37:19 2003 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 7703B16A4CE for ; Wed, 12 Nov 2003 01:37:19 -0800 (PST) Received: from ib.com.ua (ib.com.ua [217.144.67.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B13B43FB1 for ; Wed, 12 Nov 2003 01:37:16 -0800 (PST) (envelope-from toha@toha.org.ua) Received: from ib.com.ua (localhost.ib.com.ua [127.0.0.1]) by ib.com.ua (8.12.10/8.12.10) with ESMTP id hAC9b3LI013393 for ; Wed, 12 Nov 2003 11:37:03 +0200 (EET) (envelope-from toha@toha.org.ua) Received: (from toha@localhost) by ib.com.ua (8.12.10/8.12.10/Submit) id hAC9b3pA013392 for freebsd-current@freebsd.org; Wed, 12 Nov 2003 11:37:03 +0200 (EET) (envelope-from toha@toha.org.ua) Date: Wed, 12 Nov 2003 11:37:03 +0200 (EET) From: toha@toha.org.ua Message-Id: <200311120937.hAC9b3pA013392@ib.com.ua> X-Authentication-Warning: ib.com.ua: toha set sender to toha@toha.org.ua using -f To: freebsd-current@freebsd.org Subject: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:37:19 -0000 Okey. I've made fresh (20031111) release from HEAD. During installation, sysinstall has troubles creating filesystems. 1). fdisk creates slice with name "ad0p1". and newfs can't find /dev/ad0p1*. 2). if i create slice, then do "rescan devices" or rerun sysinstall, slice has name "ad0s1". but newfs says: "cannot retrive operator gid" 3). I've run "Fixed Shell" and created file "/etc/group" with one line "operator:*:5:root" and newfs created file systems successfuly. is this known issues? P.S. Sorry my bad english. P.P.S. Please, CC' me. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:42:11 2003 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 6C62816A4CF for ; Wed, 12 Nov 2003 01:42:11 -0800 (PST) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 057ED43FCB for ; Wed, 12 Nov 2003 01:42:10 -0800 (PST) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 3.36 #1) id 1AJrVo-000IGx-00; Wed, 12 Nov 2003 10:42:08 +0100 Date: Wed, 12 Nov 2003 10:42:08 +0100 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20031112094208.GA6957@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org, toha@toha.org.ua References: <200311120937.hAC9b3pA013392@ib.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311120937.hAC9b3pA013392@ib.com.ua> User-Agent: Mutt/1.5.4i Sender: Oliver Brandmueller cc: toha@toha.org.ua Subject: Re: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:42:11 -0000 Hi. On Wed, Nov 12, 2003 at 11:37:03AM +0200, toha@toha.org.ua wrote: > I've made fresh (20031111) release from HEAD. > During installation, sysinstall has troubles creating > filesystems. > > 1). fdisk creates slice with name "ad0p1". and newfs > can't find /dev/ad0p1*. > 2). if i create slice, then do "rescan devices" or > rerun sysinstall, slice has name "ad0s1". but > newfs says: "cannot retrive operator gid" > 3). I've run "Fixed Shell" and created file "/etc/group" > with one line "operator:*:5:root" and newfs > created file systems successfuly. > > is this known issues? I can at least say I found the same problem in a snapshot from a few days ago (I think 08 Nov 03) for an install with a Mylex controller, as where the devices were incorrectly referenced as mlx0p1a instead of mlx0s1a and so on. I finally installed an 5.1-REL and updated in that situation, because I just had it around. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:48:37 2003 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 6574D16A4CE for ; Wed, 12 Nov 2003 01:48:37 -0800 (PST) Received: from ray.idi.ntnu.no (ray.idi.ntnu.no [129.241.107.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABBAA43FE3 for ; Wed, 12 Nov 2003 01:48:35 -0800 (PST) (envelope-from morten@rodal.no) Received: from hauk10.idi.ntnu.no (hauk10.idi.ntnu.no [129.241.102.222]) by ray.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id hAC9mTDG007533; Wed, 12 Nov 2003 10:48:30 +0100 (MET) Received: from rodal.no (localhost [127.0.0.1]) by hauk10.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id hAC9mTkX062517; Wed, 12 Nov 2003 10:48:29 +0100 (CET) (envelope-from morten@rodal.no) Message-ID: <3FB201E4.3090505@rodal.no> Date: Wed, 12 Nov 2003 10:48:20 +0100 From: Morten Rodal User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031026 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jqdkf@army.com References: <20031112091032.GA4425@cactus> In-Reply-To: <20031112091032.GA4425@cactus> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB985A33F13471FF216F2A5D8" X-Spam-Status: No, hits=-8.7 required=4 X-Virus-Scanned: by amavisd-new-IDI cc: current@freebsd.org Subject: Re: xscreensaver bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:48:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB985A33F13471FF216F2A5D8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit jqdkf@army.com wrote: > Hi, > > I'm new in FreeBSD. I found that after I lock screen with xscreensaver, > I can unlock it with the root's password as well as my normal user's > password. I don't think it is a good thing. Is it a bug? > It is not a bug, but rather a feature of xscreensaver. It has (to the best of my knowledge) nothing to do with FreeBSD. If you install xscreensaver on Linux, or some other platform, it will probably allow you to unlock the screen with the root password there too. -- Morten Rodal --------------enigB985A33F13471FF216F2A5D8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/sgHtbWe1Cy11WVsRAiZYAKCs1R1xrtOxoz9dIcn5tSDQRinrXwCfVxz2 ABKR5CfGE9RsQ7Gfz7SHIo8= =HJX4 -----END PGP SIGNATURE----- --------------enigB985A33F13471FF216F2A5D8-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 01:52:46 2003 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 0436916A4E9 for ; Wed, 12 Nov 2003 01:52:44 -0800 (PST) Received: from freebsd.petanna.net (host81-136-58-113.in-addr.btopenworld.com [81.136.58.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAE5443FDF for ; Wed, 12 Nov 2003 01:52:42 -0800 (PST) (envelope-from peter@circlesquared.com) Received: from circlesquared.com (localhost.petanna.net [127.0.0.1]) by freebsd.petanna.net (8.12.10/8.12.6) with ESMTP id hAC9suIe045037 for ; Wed, 12 Nov 2003 09:54:58 GMT (envelope-from peter@circlesquared.com) Message-ID: <3FB20370.7060807@circlesquared.com> Date: Wed, 12 Nov 2003 09:54:56 +0000 From: Peter Risdon User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20031102 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Intel 865 probs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:52:46 -0000 Hi, Having lots of probs with a machine based on an Intel 865 motherboard. Any pointers? Please let me know if you need more info. It seems to run OK unless userland ppp is invoked, after which it falls over within about 30 minutes. External ISDN TA connected to cuaa0 stopped functioning after a couple of days' operation. New TA installed, sources updated, world and kernel built and installed. Thanks in advance, Peter Risdon. server.mydomain.com kernel log messages: >> a0000-0xbffff on isa0 >> Timecounter "TSC" frequency 2394011744 Hz quality 800 >> Timecounters tick every 10.000 msec >> GEOM: create disk ad0 dp=0xc6b02370 >> GEOM: create disk ad2 dp=0xc6b02070 >> sa0 at ahc0 bus 0 target 3 lun 0 >> WARNING: / was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /usr/home was not properly dismounted >> WARNING: /var was not properly dismounted >> /var: superblock summary recomputed >> lock order reversal >> 1st 0xc70c8afc vm object (vm object) @ vm/swap_pager.c:1323 >> 2nd 0xc097fc80 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1838 >> 3rd 0xc1034378 vm object (vm object) @ vm/uma_core.c:876 >> Stack backtrace: >> lock order reversal >> 1st 0xc71d7090 rtentry (rtentry) @ net/rtsock.c:388 >> 2nd 0xc693b87c radix node head (radix node head) @ net/route.c:1114 >> Stack backtrace: >> 1st 0xc0974ab4 route cache (route cache) @ netinet/ip_input.c:781 >> 2nd 0xc7d4ed90 rtentry (rtentry) @ netinet/ip_input.c:781 >> panic: mutex inp not owned at ../../../netinet/ip_output.c:210 >> syncing disks, buffers remaining... 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 6901 >> giving up on 2420 buffers >> Uptime: 6h55m14s >> panic: sleeping thread (pid 27) owns a mutex >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> >> Fatal double fault: >> eip = 0xc07ec9f5 >> esp = 0xe1c4e000 >> ebp = 0xe1c4e008 >> panic: double fault >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> Uptime: 6h55m14s >> panic: msleep >> FreeBSD 5.1-CURRENT #0: Mon Nov 10 11:44:45 GMT 2003 >> root@server.mydomain.com:/usr/src/sys/i386/compile/GENplusSERIAL >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a70000. >> avail memory = 1016430592 (969 MB) >> pcib1: slot 1 INTA is routed to irq 11 >> pcib1: slot 8 INTA is routed to irq 11 >> puc0: port 0xbc00-0xbc1f irq 11 at device 1.0 on pci1 >> sio4: on puc0 >> sio4: type 16550A >> sio4: unable to activate interrupt in fast mode - using normal mode >> sio5: on puc0 >> sio5: type 16550A >> sio5: unable to activate interrupt in fast mode - using normal mode >> ahc0: port 0xb800-0xb8ff mem 0xff8ff000-0xff8fffff irq 3 at device 2.0 on pci1 >> ahc0: Host Adapter Bios disabled. Using default SCSI device parameters >> aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs >> fxp0: port 0xb400-0xb43f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1 >> npx0: [FAST] >> npx0: on motherboard >> npx0: INT 16 interface >> Timecounter "TSC" frequency 2394013308 Hz quality 800 >> GEOM: create disk ad0 dp=0xc6b02370 >> GEOM: create disk ad2 dp=0xc6b02070 >> sa0 at ahc0 bus 0 target 3 lun 0 >> WARNING: / was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /usr/home was not properly dismounted >> WARNING: /var was not properly dismounted >> /var: mount pending error: blocks 4 files 1 >> /var: superblock summary recomputed >> FreeBSD 5.1-CURRENT #0: Mon Nov 10 11:44:45 GMT 2003 >> root@server.mydomain.com:/usr/src/sys/i386/compile/GENplusSERIAL >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a70000. >> avail memory = 1016430592 (969 MB) >> pcib1: slot 1 INTA is routed to irq 11 >> pcib1: slot 8 INTA is routed to irq 11 >> puc0: port 0xbc00-0xbc1f irq 11 at device 1.0 on pci1 >> sio4: on puc0 >> sio4: type 16550A >> sio4: unable to activate interrupt in fast mode - using normal mode >> sio5: on puc0 >> sio5: type 16550A >> sio5: unable to activate interrupt in fast mode - using normal mode >> ahc0: port 0xb800-0xb8ff mem 0xff8ff000-0xff8fffff irq 3 at device 2.0 on pci1 >> ahc0: Host Adapter Bios disabled. Using default SCSI device parameters >> aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs >> fxp0: port 0xb400-0xb43f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1 >> npx0: [FAST] >> npx0: on motherboard >> npx0: INT 16 interface >> Timecounter "TSC" frequency 2394014016 Hz quality 800 >> GEOM: create disk ad0 dp=0xc6b02370 >> GEOM: create disk ad2 dp=0xc6b02070 >> sa0 at ahc0 bus 0 target 3 lun 0 >> WARNING: / was not properly dismounted >> WARNING: /usr was not properly dismounted >> /usr: mount pending error: blocks 4 files 1 >> WARNING: /usr/home was not properly dismounted >> WARNING: /var was not properly dismounted >> lock order reversal >> 1st 0xc6f8b190 rtentry (rtentry) @ net/rtsock.c:388 >> 2nd 0xc693b87c radix node head (radix node head) @ net/route.c:1114 >> Stack backtrace: >> 1st 0xc0974ab4 route cache (route cache) @ netinet/ip_input.c:781 >> 2nd 0xc6bf2690 rtentry (rtentry) @ netinet/ip_input.c:781 >> panic: mutex inp not owned at ../../../netinet/ip_output.c:210 >> syncing disks, buffers remaining... 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 2657 >> giving up on 1812 buffers >> Uptime: 2h30m47s >> Automatic reboot in 15 seconds - press a key on the console to abort >> FreeBSD 5.1-CURRENT #0: Mon Nov 10 11:44:45 GMT 2003 >> root@server.mydomain.com:/usr/src/sys/i386/compile/GENplusSERIAL >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a70000. >> avail memory = 1016430592 (969 MB) >> pcib1: slot 1 INTA is routed to irq 11 >> pcib1: slot 8 INTA is routed to irq 11 >> puc0: port 0xbc00-0xbc1f irq 11 at device 1.0 on pci1 >> sio4: on puc0 >> sio4: type 16550A >> sio4: unable to activate interrupt in fast mode - using normal mode >> sio5: on puc0 >> sio5: type 16550A >> sio5: unable to activate interrupt in fast mode - using normal mode >> ahc0: port 0xb800-0xb8ff mem 0xff8ff000-0xff8fffff irq 3 at device 2.0 on pci1 >> ahc0: Host Adapter Bios disabled. Using default SCSI device parameters >> aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs >> fxp0: port 0xb400-0xb43f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1 >> npx0: [FAST] >> npx0: on motherboard >> npx0: INT 16 interface >> Timecounter "TSC" frequency 2394013644 Hz quality 800 >> GEOM: create disk ad0 dp=0xc6b02370 >> GEOM: create disk ad2 dp=0xc6b02070 >> sa0 at ahc0 bus 0 target 3 lun 0 >> WARNING: / was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /usr/home was not properly dismounted >> WARNING: /var was not properly dismounted >> /var: mount pending error: blocks 4 files 1 >> /var: superblock summary recomputed > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 02:22:43 2003 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 C1FD416A4CE; Wed, 12 Nov 2003 02:22:43 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C73343F75; Wed, 12 Nov 2003 02:22:42 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACAMfv9095198; Wed, 12 Nov 2003 05:22:41 -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 hACAMfci095197; Wed, 12 Nov 2003 05:22:41 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 05:22:41 -0500 (EST) Message-Id: <200311121022.hACAMfci095197@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, i386@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 10:22:44 -0000 TB --- 2003-11-12 09:00:29 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 09:00:29 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-12 09:00:29 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 09:02:53 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/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 --- 2003-11-12 10:01:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 10:01:12 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 10:13:25 GMT 2003 TB --- 2003-11-12 10:13:25 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 10:13:25 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 10:13:25 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_label.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_net.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_pipe.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_process.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_system.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac/mac_vfs.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_biba/mac_biba.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_biba/mac_biba.c:2652: warning: initialization from incompatible pointer type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-11-12 10:22:41 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 10:22:41 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-12 10:22:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 03:06:37 2003 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 607EA16A4CE; Wed, 12 Nov 2003 03:06:37 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 436E143FE9; Wed, 12 Nov 2003 03:06:36 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACB6Zv9066964; Wed, 12 Nov 2003 06:06:35 -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 hACB6Zsw066963; Wed, 12 Nov 2003 06:06:35 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 06:06:35 -0500 (EST) Message-Id: <200311121106.hACB6Zsw066963@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, ia64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 11:06:37 -0000 TB --- 2003-11-12 10:22:41 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 10:22:41 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-12 10:22:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 10:24:58 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/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.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-11-12 11:06:35 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 11:06:35 - TB --- ERROR: failed to build world TB --- 2003-11-12 11:06:35 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 03:46:02 2003 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 9B67616A4CE; Wed, 12 Nov 2003 03:46:02 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD35F43F85; Wed, 12 Nov 2003 03:46:00 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACBk0v9039944; Wed, 12 Nov 2003 06:46:00 -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 hACBk0SB039943; Wed, 12 Nov 2003 06:46:00 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 06:46:00 -0500 (EST) Message-Id: <200311121146.hACBk0SB039943@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 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: Wed, 12 Nov 2003 11:46:02 -0000 TB --- 2003-11-12 11:06:35 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 11:06:35 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-12 11:06:35 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 11:08:36 - 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.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-12 11:45:59 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 11:45:59 - TB --- ERROR: failed to build world TB --- 2003-11-12 11:45:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 05:48:38 2003 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 9242D16A4CE for ; Wed, 12 Nov 2003 05:48:38 -0800 (PST) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D6643F3F for ; Wed, 12 Nov 2003 05:48:37 -0800 (PST) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1])hACDlrM99007; Wed, 12 Nov 2003 22:47:56 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <200311120809.hAC89wGT011122@ib.com.ua> References: <200311120809.hAC89wGT011122@ib.com.ua> X-User-Agent: Mew/1.94.2 Emacs/21.3 X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20030322(IM144) Lines: 17 From: Makoto Matsushita To: toha@toha.org.ua Date: Wed, 12 Nov 2003 22:47:50 +0900 Message-Id: <20031112224750C.matusita@jp.FreeBSD.org> cc: current@FreeBSD.org Subject: Re: release build problems, drivers.flp: file system is full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 13:48:38 -0000 toha> Release build fails: toha> drivers.flp: file system if full. Since yesterday. toha> Can somebody remove some driver from drivers.conf? No, don't do that. Since we have only 3 floppies, simply removing some modules may mean "it cannot use it while installing FreeBSD." Fortunately we have some rooms in mfsroot.flp, we can move some drivers (back?) to there. I'm just trying which module(s) can be moved or not. -- - Makoto `MAR' Matsushita From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 06:04:09 2003 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 A440716A4D0 for ; Wed, 12 Nov 2003 06:04:09 -0800 (PST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B3B443FB1 for ; Wed, 12 Nov 2003 06:04:06 -0800 (PST) (envelope-from atrens@nortelnetworks.com) Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) id hACE44W26988 for ; Wed, 12 Nov 2003 09:04:04 -0500 (EST) Received: from zcard031.ca.nortel.com ([47.129.242.121]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WTC1CZ9L; Wed, 12 Nov 2003 09:04:04 -0500 Received: from nortelnetworks.com (artpt4ws.us.nortel.com [47.140.42.14]) by zcard031.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3KAFBCN; Wed, 12 Nov 2003 09:04:03 -0500 Message-ID: <3FB230A8.5000706@nortelnetworks.com> Date: Wed, 12 Nov 2003 08:07:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Andrew Atrens User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030807 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 14:04:09 -0000 Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? Cheers, Andrew. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 06:43:42 2003 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 DA91716A4CE for ; Wed, 12 Nov 2003 06:43:42 -0800 (PST) Received: from mail-in.m-online.net (svr8.m-online.net [62.245.150.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36A6C43F85 for ; Wed, 12 Nov 2003 06:43:39 -0800 (PST) (envelope-from h@schmalzbauer.de) Received: from mail.m-online.net (svr14.m-onlne.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id C917B476; Wed, 12 Nov 2003 15:43:37 +0100 (CET) Received: from cale.flintsbach.schmalzbauer.de (ppp-62-245-232-127.mnet-online.de [62.245.232.127]) by mail.m-online.net (Postfix) with ESMTP id 95CF617070; Wed, 12 Nov 2003 15:43:32 +0100 (CET) From: Harald Schmalzbauer To: Andrew Atrens , current@freebsd.org Date: Wed, 12 Nov 2003 15:43:27 +0100 User-Agent: KMail/1.5.4 References: <3FB230A8.5000706@nortelnetworks.com> In-Reply-To: <3FB230A8.5000706@nortelnetworks.com> X-Birthday: 06 Oktober 1972 X-Name: Harald Schmalzbauer X-Phone1: +49 (0) 163 555 3237 X-Phone2: +49 (0) 89 18947781 X-Address: Munich, 80686 X-Country: Germany MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Wcks/gaLlaCAdYZ"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200311121543.35074@harrymail> Subject: Re: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 14:43:43 -0000 --Boundary-02=_Wcks/gaLlaCAdYZ Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? I recommended that a friend of mine. It's running without an Problem under= =20 4.7. I Don't know about newer versions but it should work well. =2DHarry > > > Cheers, > > Andrew. > > > > _______________________________________________ > 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" --Boundary-02=_Wcks/gaLlaCAdYZ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/skcWBylq0S4AzzwRApZ2AJ9B8/jg6g49LPcGGl5vCKSlw1i4KwCfZsQu EnyUxM7ApwaO7rsxtqHykag= =3T38 -----END PGP SIGNATURE----- --Boundary-02=_Wcks/gaLlaCAdYZ-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 06:56:12 2003 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 0E34316A4CF for ; Wed, 12 Nov 2003 06:56:12 -0800 (PST) Received: from sccimhc02.asp.att.net (sccimhc02.asp.att.net [63.240.76.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BDD243F75 for ; Wed, 12 Nov 2003 06:56:11 -0800 (PST) (envelope-from steve@energistic.com) Received: from energistic.com (12-223-237-12.client.insightbb.com[12.223.237.12]) by sccimhc02.asp.att.net (sccimhc02) with ESMTP id <20031112145609im200gbef2e>; Wed, 12 Nov 2003 14:56:10 +0000 Received: from energistic.com (steve@localhost [127.0.0.1]) by energistic.com (8.12.10/8.12.10) with ESMTP id hACEu3tX055883; Wed, 12 Nov 2003 09:56:04 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.12.10/8.12.10/Submit) id hACEtubq052855; Wed, 12 Nov 2003 09:55:56 -0500 (EST) (envelope-from steve) Date: Wed, 12 Nov 2003 09:55:56 -0500 From: Steve Ames To: Steve Ames Message-ID: <20031112145556.GA93082@energistic.com> References: <200311111640.hABGe3VV030454@energistic.com> <200311110858.35921.sam@errno.com> <027101c3a899$a1975ce0$fc00030a@officescape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027101c3a899$a1975ce0$fc00030a@officescape.net> User-Agent: Mutt/1.5.4i cc: Sam Leffler cc: freebsd-current@freebsd.org Subject: Re: panic related to in_output.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 14:56:12 -0000 Bah. Certainly better. The machine was locking every 15-20 minutes. Now it reboots itself every couple of hours with the following: panic: lock (sleep mutex) tcp not locked @ /usr/src/sys/netinet/tcp_syncache.c 378 -Steve On Tue, Nov 11, 2003 at 04:20:20PM -0500, Steve Ames wrote: > That seems to have done the job (v 1.48 of tcp_syncache.c). At least its > been up for nearly an hour which is a definate positive! > > Thanks. > > -Steve > > ----- Original Message ----- > From: "Sam Leffler" > To: "Steve Ames" ; > Sent: Tuesday, November 11, 2003 11:58 AM > Subject: Re: panic related to in_output.c > > > > On Tuesday 11 November 2003 08:40 am, Steve Ames wrote: > > > Code from yesterday evening (11/10 around 5PM EST). Just updated this > > > morning. I saw no updates to ip_output.c but there were changes to a > couple > > > of other files in sys/netinet so figured I'd give it a whirl... > > > > > > panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218 > > > cpuid= -; > > > Debugger("panic") > > > Stopped at Debugger+0x55: xchgl %ebx,in_Deubbger,0 > > > db> > > > > I'll commit the fix today. I was waiting for testing feedback from the > 1st > > person that tripped the assertion... > > > > Sam > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 07:13:35 2003 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 ED68516A4CE for ; Wed, 12 Nov 2003 07:13:35 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 088ED43F3F for ; Wed, 12 Nov 2003 07:13:35 -0800 (PST) (envelope-from sweetleaf@fastmail.fm) Received: from server1.messagingengine.com (server1.internal [10.202.2.132]) by mail.messagingengine.com (Postfix) with ESMTP id B06FB3EDB72 for ; Wed, 12 Nov 2003 10:13:01 -0500 (EST) Received: by server1.messagingengine.com (Postfix, from userid 99) id 2547A3DDBE; Wed, 12 Nov 2003 10:13:01 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Sweetleaf" To: freebsd-current@freebsd.org Date: Wed, 12 Nov 2003 07:13:01 -0800 X-Sasl-Enc: pjIp4/izGKHhrGb274Z4jg 1068649981 Message-Id: <20031112151301.2547A3DDBE@server1.messagingengine.com> Subject: cdparanoia in the ports fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 15:13:36 -0000 I am trying to get cdparanoia from the port to compile but am running into the following: ===> Building for cdparanoia-3.9.8_5 cd interface && gmake all gmake[1]: Entering directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake libcdda_interface.a CFLAGS="-O -O -mcpu=pentiumpro" gmake[2]: Entering directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' cc -O -O -mcpu=pentiumpro -c scan_devices.c cc -O -O -mcpu=pentiumpro -c common_interface.c cc -O -O -mcpu=pentiumpro -c cooked_interface.c cooked_interface.c: In function `cooked_read': cooked_interface.c:204: error: storage size of `arg' isn't known cooked_interface.c:215: error: `CDIOCREADAUDIO' undeclared (first use in this function) cooked_interface.c:215: error: (Each undeclared identifier is reported only once cooked_interface.c:215: error: for each function it appears in.) gmake[2]: *** [cooked_interface.o] Error 1 gmake[2]: Leaving directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake[1]: *** [lib] Error 2 gmake[1]: Leaving directory `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/audio/cdparanoia. system: freebsd 5-current ports 5-current -- Sweetleaf sweetleaf@fastmail.fm -- http://www.fastmail.fm - Access your email from home and the web From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 07:22:42 2003 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 0164016A4CE for ; Wed, 12 Nov 2003 07:22:42 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E27643FA3 for ; Wed, 12 Nov 2003 07:22:39 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 91642 invoked from network); 12 Nov 2003 15:25:31 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 15:25:31 -0000 Message-ID: <3FB2503E.53B21470@pipeline.ch> Date: Wed, 12 Nov 2003 16:22:38 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 15:22:42 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Tue, 11 Nov 2003 19:26:41 +0100 > >>>>> Andre Oppermann said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031111.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Ok, I found the bug. It was in the ipv6 hash function where I made a mistake with the hashmask. The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch Could you try again please? I have organized a second IPv6 capable machine (OpenBSD) for testing and I was able to ssh from my development machine to the OpenBSD via IPv6 tcp connection. I hope the last update has ironed out all ip6 bugs now. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 07:24:03 2003 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 4EDA316A4CE for ; Wed, 12 Nov 2003 07:24:03 -0800 (PST) Received: from be-well.no-ip.com (lowellg.ne.client2.attbi.com [66.30.200.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id A692B43FBF for ; Wed, 12 Nov 2003 07:24:02 -0800 (PST) (envelope-from freebsd-current-local@be-well.ilk.org) Received: by be-well.no-ip.com (Postfix, from userid 1147) id 138215D; Wed, 12 Nov 2003 10:24:01 -0500 (EST) Sender: lowell@be-well.ilk.org To: freebsd-current@freebsd.org References: <20031112151301.2547A3DDBE@server1.messagingengine.com> From: Lowell Gilbert Date: 12 Nov 2003 10:24:01 -0500 In-Reply-To: <20031112151301.2547A3DDBE@server1.messagingengine.com> Message-ID: <444qx9fw4u.fsf@be-well.ilk.org> Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: cdparanoia in the ports fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 15:24:03 -0000 "Sweetleaf" writes: > I am trying to get cdparanoia from the port to compile but am running > into the following: > > ===> Building for cdparanoia-3.9.8_5 > cd interface && gmake all > gmake[1]: Entering directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake libcdda_interface.a CFLAGS="-O -O -mcpu=pentiumpro" > gmake[2]: Entering directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > cc -O -O -mcpu=pentiumpro -c scan_devices.c > cc -O -O -mcpu=pentiumpro -c common_interface.c > cc -O -O -mcpu=pentiumpro -c cooked_interface.c > cooked_interface.c: In function `cooked_read': > cooked_interface.c:204: error: storage size of `arg' isn't known > cooked_interface.c:215: error: `CDIOCREADAUDIO' undeclared (first use in > this function) > cooked_interface.c:215: error: (Each undeclared identifier is reported > only once > cooked_interface.c:215: error: for each function it appears in.) > gmake[2]: *** [cooked_interface.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake[1]: *** [lib] Error 2 > gmake[1]: Leaving directory > `/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface' > gmake: *** [all] Error 2 > *** Error code 2 > > Stop in /usr/ports/audio/cdparanoia. > > > system: > > freebsd 5-current > > ports 5-current Well, no, the latest cdparanoia port is cdparanoia-3.9.8_6. That fixed the problem you're seeing. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:11:37 2003 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 2B6EF16A4CE; Wed, 12 Nov 2003 08:11:37 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A67B43FE1; Wed, 12 Nov 2003 08:11:36 -0800 (PST) (envelope-from sweetleaf@fastmail.fm) Received: from server1.messagingengine.com (server1.internal [10.202.2.132]) by mail.messagingengine.com (Postfix) with ESMTP id 211C83FC946; Wed, 12 Nov 2003 11:07:12 -0500 (EST) Received: by server1.messagingengine.com (Postfix, from userid 99) id 784E03FADE; Wed, 12 Nov 2003 11:07:11 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Sweetleaf" To: freebsd-current@freebsd.org Date: Wed, 12 Nov 2003 08:07:11 -0800 X-Sasl-Enc: RMFIL2cYICyxbszoHMvkdg 1068653231 Message-Id: <20031112160711.784E03FADE@server1.messagingengine.com> cc: freebsd-ports@freebsd.org Subject: open office X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:11:37 -0000 Does openoffice seem slow to respond to others? Clicking on a menu option such as "file" as to open a file takes about 30sec to give me the drop down menu. Also i have noticed there might be a problem with the way the port built or installed gtk, go to the business card creator and you should see just gibberesh instead of the wizzard layout. I am using the openoffice in the 5-current ports which is 1.1.0. System: amd athlon-xp 1800 w/256 ddr 2700 ram freebsd-5-current with 5-current ports. -- Sweetleaf sweetleaf@fastmail.fm -- http://www.fastmail.fm - Does exactly what it says on the tin From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:18:49 2003 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 5207616A4CE; Wed, 12 Nov 2003 08:18:49 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EA8B43FB1; Wed, 12 Nov 2003 08:18:48 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hACGGvMg090504; Wed, 12 Nov 2003 11:16:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hACGGvNs090501; Wed, 12 Nov 2003 11:16:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 12 Nov 2003 11:16:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Sweetleaf In-Reply-To: <20031112160711.784E03FADE@server1.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-ports@freebsd.org Subject: Re: open office X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:18:49 -0000 On Wed, 12 Nov 2003, Sweetleaf wrote: > Does openoffice seem slow to respond to others? Clicking on a menu option > such as "file" as to open a file takes about 30sec to give me the drop > down menu. Also i have noticed there might be a problem with the way the > port built or installed gtk, go to the business card creator and you > should see just gibberesh instead of the wizzard layout. I am using the > openoffice in the 5-current ports which is 1.1.0. > > System: amd athlon-xp 1800 w/256 ddr 2700 ram > > freebsd-5-current with 5-current ports. Are you using libc_r, or another of the threading libraries? Interactivity problems in applications can sometimes be attributed to thread-level scheduling or locking problems, either in the application, or due to the threading model. I've found that switching to libkse makes threaded GUI applications a lot more responsive, as the GUI can continue to update while another thread performs slow disk I/O or the like. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:23:10 2003 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 4FBD616A4CE for ; Wed, 12 Nov 2003 08:23:10 -0800 (PST) Received: from www.premsoft.co.za (www.rune.za.net [196.37.142.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id E362843FD7 for ; Wed, 12 Nov 2003 08:22:57 -0800 (PST) (envelope-from freebsd-questions@premsoft.co.za) Received: from jaco[196.33.247.85] by www.premsoft.co.za; Wed, 12 Nov 2003 18:44:45 +0200 Message-ID: <099401c3a939$322ac680$3635a8c0@jaco> From: "Jaco H. van Tonder" To: "Peter Risdon" , References: <3FB20370.7060807@circlesquared.com> Date: Wed, 12 Nov 2003 18:22:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Intel 865 probs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:23:10 -0000 Peter, >Hi, > >Having lots of probs with a machine based on an Intel 865 motherboard. >Any pointers? Please let me know if you need more info. It seems to run >OK unless userland ppp is invoked, after which it falls over within >about 30 minutes. External ISDN TA connected to cuaa0 stopped >functioning after a couple of days' operation. New TA installed, sources >updated, world and kernel built and installed. For what its worth, I had a lot of problems on the I865P board, and It boiled down to memory corruption. The machine had lots of "random" crashes, meanng that they were not occuring when I do something specific. The machine startted to panic as soon as the load got high. I took out the memory, and placed it into another slot and the machine is cruising along happily now. The other questions is what is the date of the -CURRENT tree that is giving this problems? I can recall quite a few problems, which were fixed, that could cause this problem. Jaco van Tonder Magic Developer :: Premsoft Development (Pty) Ltd Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 Email: jaco@premsoft.co.za :: Web: http://www.premsoft.co.za/ Disclaimer: http://www.premsoft.co.za/email_disclaimer.html From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:24:20 2003 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 AABD616A4CF for ; Wed, 12 Nov 2003 08:24:20 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E056443F3F for ; Wed, 12 Nov 2003 08:24:19 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id hACGOIfY081983; Wed, 12 Nov 2003 08:24:18 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.9/Submit) id hACGODx8081982; Wed, 12 Nov 2003 08:24:13 -0800 (PST) (envelope-from obrien) Date: Wed, 12 Nov 2003 08:24:13 -0800 From: "David O'Brien" To: toha@toha.org.ua Message-ID: <20031112162413.GA9744@dragon.nuxi.com> References: <200311120937.hAC9b3pA013392@ib.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311120937.hAC9b3pA013392@ib.com.ua> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:24:20 -0000 On Wed, Nov 12, 2003 at 11:37:03AM +0200, toha@toha.org.ua wrote: > I've made fresh (20031111) release from HEAD. > During installation, sysinstall has troubles creating > filesystems. > > 1). fdisk creates slice with name "ad0p1". and newfs > can't find /dev/ad0p1*. > 2). if i create slice, then do "rescan devices" or > rerun sysinstall, slice has name "ad0s1". but > newfs says: "cannot retrive operator gid" Yes. I ran into this just yesterday. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:26:07 2003 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 4356516A4CE for ; Wed, 12 Nov 2003 08:26:07 -0800 (PST) Received: from wolfram.com (wri-dns0.wolfram.com [140.177.205.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA6743F93 for ; Wed, 12 Nov 2003 08:25:56 -0800 (PST) (envelope-from hemi@just.puresimplicity.net) Received: from just.puresimplicity.net ([140.177.207.10]) by wolfram.com (8.11.2/8.11.2) with ESMTP id hACGPiB31798; Wed, 12 Nov 2003 10:25:49 -0600 Received: (from hemi@localhost) by just.puresimplicity.net (8.12.8p2/8.12.8/Submit) id hACGPhRS006001; Wed, 12 Nov 2003 10:25:43 -0600 (CST) (envelope-from hemi) Date: Wed, 12 Nov 2003 10:25:43 -0600 From: Josh Tolbert To: Harald Schmalzbauer Message-ID: <20031112162543.GA5939@just.puresimplicity.net> References: <3FB230A8.5000706@nortelnetworks.com> <200311121543.35074@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311121543.35074@harrymail> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:26:07 -0000 On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: Content-Description: signed data > On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > > Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > > I recommended that a friend of mine. It's running without an Problem under > 4.7. I Don't know about newer versions but it should work well. > > -Harry I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under 5.1-RELEASE, so it'll probably work fine under -CURRENT. However, 3dm from the ports tree does not work. Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:29:37 2003 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 781AB16A4CE for ; Wed, 12 Nov 2003 08:29:37 -0800 (PST) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66CD443F93 for ; Wed, 12 Nov 2003 08:29:36 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 14066 invoked from network); 12 Nov 2003 16:29:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Nov 2003 16:29:35 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hACGTBce025960; Wed, 12 Nov 2003 11:29:12 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031112060407.931085299@ftp.bjpu.edu.cn> Date: Wed, 12 Nov 2003 11:29:10 -0500 (EST) From: John Baldwin To: =?utf-8?B?WGluIExJL+adjumRqw==?= X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org Subject: RE: Recent -CURRENT panic (New interrupt code related?); backtrace included X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:29:37 -0000 On 12-Nov-2003 Xin LI/李鑫 wrote: > Hello, > > On recently compiled kernels, I often get panics which seemed to be interrupt related. Among > other things, almost all of them claims that "Kernel trap 30", which seemd to be strange. > > The kernel I am currently running, namely, > > FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 22:27:05 CST 2003 > delphij@servers.frontfree.net:/usr/obj/usr/src/sys/SERVERS i386 > > seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and run > attempts:), it exhibits incredible instablity. > > FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003 > delphij@servers.frontfree.net:/usr/obj/usr/src/sys/SERVERS > > Here is one of the crashdumps I caught. The machine was configured with a UP kernel, with > DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp and a dc, and the > machine itself act as a NAT gateway. The network load is not very heavy. If you think the > backtrace helpful, or need any more information, please write me and I will try everything I can > to help. Do you have 'device apic' enabled? If so, can you try using 'options NO_MIXED_MODE'. Barring that, can you try http://www.FreeBSD.org/~jhb/patches/spurious.patch and if that doesn't work http://www.FreeBSD.org/~jhb/patches/atpic.patch? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:30:55 2003 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 3FA9316A4CE for ; Wed, 12 Nov 2003 08:30:55 -0800 (PST) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E53843FAF for ; Wed, 12 Nov 2003 08:30:54 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 5150 invoked from network); 12 Nov 2003 16:30:53 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Nov 2003 16:30:53 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hACGUUce025981; Wed, 12 Nov 2003 11:30:30 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031112070125.GB16030@zibbi.icomtek.csir.co.za> Date: Wed, 12 Nov 2003 11:30:28 -0500 (EST) From: John Baldwin To: John Hay X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@FreeBSD.org Subject: Re: panic: probing for non-PCI bus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:30:55 -0000 On 12-Nov-2003 John Hay wrote: >> > Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in >> > the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. >> > >> > pcib1: at device 1.0 on pci0 >> > pci1: on pcib1 >> >> Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. >> I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps >> there is a BIOS option to set the interrupt model to APIC rather than PIC that >> might fix the ACPI case. > > Ok, I opened the machine this morning and it does have an AGP slot. > > I also had a look in the BIOS setup, but didn't see anything to change > the interrupt model. The closest I saw was: > > MPS 1.4 Support - Enabled/Disabled (Enabled) > PCI 2.1 Support - Enabled/disabled (Enabled) > PNP OS Installed - No/Yes (No) > > I built a new kernel with your mptable changes included and with acpi > enabled, it would panic, but the onboard scsi interrupt doesn't work, > so you don't get very far. With acpi disabled, it seems to work fine, > although I haven't done much yet. So it looks like I'm up and running > again, thanks. Yes, your BIOS doesn't include any interrupt routing information in ACPI for using APICs, so your machine isn't going to work with ACPI and 'device apic'. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 08:54:38 2003 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 9708C16A4CF for ; Wed, 12 Nov 2003 08:54:38 -0800 (PST) Received: from blake.polstra.com (dsl081-189-066.sea1.dsl.speakeasy.net [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC7943F85 for ; Wed, 12 Nov 2003 08:54:36 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id hACGsS8b033428; Wed, 12 Nov 2003 08:54:29 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031112095711.A33680@beagle.fokus.fraunhofer.de> Date: Wed, 12 Nov 2003 08:54:28 -0800 (PST) From: John Polstra To: Harti Brandt X-Bogosity: No, tests=bogofilter, spamicity=0.454416, version=0.14.5 cc: current@freebsd.org Subject: RE: HEADSUP: netgraph constants changing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 16:54:38 -0000 On 12-Nov-2003 Harti Brandt wrote: > > as I've written a couple of days ago I'm going to bump some constants in > the netgraph code that defined various name lengths in the next minutes. > I've not received any negative feedback and have the ok from re. If you > use netgraph make sure that the kernel, any externally maintained netgraph > modules and any user space netgraph stuff (mainly ngctl and nghook) are in > sync otherwise they'll not be able to communicate. This is especially > important if you use netgraph for booting purposes. No correctly written > code should break by this change :-) Please be sure to increment NG_VERSION in ng_message.h. John From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:17:04 2003 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 A2EFC16A4CE for ; Wed, 12 Nov 2003 09:17:04 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28CF543FA3 for ; Wed, 12 Nov 2003 09:17:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 1690 invoked from network); 12 Nov 2003 17:17:01 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Nov 2003 17:17:01 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hACHGcce026215; Wed, 12 Nov 2003 12:16:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031112162413.GA9744@dragon.nuxi.com> Date: Wed, 12 Nov 2003 12:16:36 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: toha@toha.org.ua cc: marcel@FreeBSD.org Subject: Re: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:17:04 -0000 On 12-Nov-2003 David O'Brien wrote: > On Wed, Nov 12, 2003 at 11:37:03AM +0200, toha@toha.org.ua wrote: >> I've made fresh (20031111) release from HEAD. >> During installation, sysinstall has troubles creating >> filesystems. >> >> 1). fdisk creates slice with name "ad0p1". and newfs >> can't find /dev/ad0p1*. >> 2). if i create slice, then do "rescan devices" or >> rerun sysinstall, slice has name "ad0s1". but >> newfs says: "cannot retrive operator gid" > > Yes. I ran into this just yesterday. The fdisk slice name problem might be related to Marcel's GPT changes to sysinstall. GPT partitions use /dev/ad0pX while MBR slices use /dev/ad0sX. Both are created in the fdisk part of sysinstall. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:17:48 2003 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 20B2616A4CE for ; Wed, 12 Nov 2003 09:17:47 -0800 (PST) Received: from valenti.ingenium.at (cm57-70.liwest.at [212.33.57.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B7AC43F85 for ; Wed, 12 Nov 2003 09:17:46 -0800 (PST) (envelope-from bernhard.valenti@gmx.net) Received: from gmx.net (decipher.home [10.0.0.4]) (authenticated bits=0)hACHHhSo034358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Nov 2003 18:17:44 +0100 (CET) (envelope-from bernhard.valenti@gmx.net) Message-ID: <3FB26B36.4020102@gmx.net> Date: Wed, 12 Nov 2003 18:17:42 +0100 From: Bernhard Valenti User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20031009 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: atheron driver and netgear WG511T X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:17:48 -0000 hi, i get this when inserting my Netgear WG511T card into my laptop: ath0: mem 0x88010000-0x8801ffff irq 11 at device 0.0 on cardbus0 ath0: unable to attach hardware; HAL status 13 device_probe_and_attach: ath0 attach returned 6 the ath manpage says that this chip should be supported... any ideas? regards, bernhard From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:42:37 2003 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 16DD416A4CE; Wed, 12 Nov 2003 09:42:37 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0686943FDD; Wed, 12 Nov 2003 09:42:36 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hACHgZbe009462; Wed, 12 Nov 2003 09:42:35 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hACHgYbH002817; Wed, 12 Nov 2003 09:42:34 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hACHgY71002816; Wed, 12 Nov 2003 09:42:34 -0800 (PST) (envelope-from marcel) Date: Wed, 12 Nov 2003 09:42:34 -0800 From: Marcel Moolenaar To: John Baldwin Message-ID: <20031112174234.GA2734@dhcp01.pn.xcllnt.net> References: <20031112162413.GA9744@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: toha@toha.org.ua cc: freebsd-current@FreeBSD.org Subject: Re: sysinstall fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:42:37 -0000 On Wed, Nov 12, 2003 at 12:16:36PM -0500, John Baldwin wrote: > > On 12-Nov-2003 David O'Brien wrote: > > On Wed, Nov 12, 2003 at 11:37:03AM +0200, toha@toha.org.ua wrote: > >> I've made fresh (20031111) release from HEAD. > >> During installation, sysinstall has troubles creating > >> filesystems. > >> > >> 1). fdisk creates slice with name "ad0p1". and newfs > >> can't find /dev/ad0p1*. > >> 2). if i create slice, then do "rescan devices" or > >> rerun sysinstall, slice has name "ad0s1". but > >> newfs says: "cannot retrive operator gid" > > > > Yes. I ran into this just yesterday. > > The fdisk slice name problem might be related to Marcel's GPT > changes to sysinstall. GPT partitions use /dev/ad0pX while > MBR slices use /dev/ad0sX. Both are created in the fdisk > part of sysinstall. Yup, my bad. I'll make the code ia64 specific. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:47:10 2003 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 362A816A4CE; Wed, 12 Nov 2003 09:47:10 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 283E143FCB; Wed, 12 Nov 2003 09:47:09 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACHl8v9023444; Wed, 12 Nov 2003 12:47:08 -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 hACHl73O023443; Wed, 12 Nov 2003 12:47:07 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 12:47:07 -0500 (EST) Message-Id: <200311121747.hACHl73O023443@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, alpha@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:47:10 -0000 TB --- 2003-11-12 17:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 17:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-12 17:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 17:04:33 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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.. [...] ===> bin/df cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-12 17:47:07 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 17:47:07 - TB --- ERROR: failed to build world TB --- 2003-11-12 17:47:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:55:57 2003 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 3EDB216A4CF for ; Wed, 12 Nov 2003 09:55:57 -0800 (PST) Received: from eden.barryp.org (host-150-32-220-24.midco.net [24.220.32.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93CAB43FB1 for ; Wed, 12 Nov 2003 09:55:55 -0800 (PST) (envelope-from bp@barryp.org) Received: from geo.med.und.nodak.edu ([134.129.166.11] helo=barryp.org) by eden.barryp.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.20) id 1AJzDR-000PNu-1N; Wed, 12 Nov 2003 11:55:41 -0600 Message-ID: <3FB27416.5060209@barryp.org> Date: Wed, 12 Nov 2003 11:55:34 -0600 From: Barry Pederson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Tolbert References: <3FB230A8.5000706@nortelnetworks.com> <200311121543.35074@harrymail> <20031112162543.GA5939@just.puresimplicity.net> In-Reply-To: <20031112162543.GA5939@just.puresimplicity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.9 required=4.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org cc: Harald Schmalzbauer Subject: Re: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:55:57 -0000 Josh Tolbert wrote: > On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: > Content-Description: signed data > >>On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: >> >>>Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? >> >>I recommended that a friend of mine. It's running without an Problem under >>4.7. I Don't know about newer versions but it should work well. >> >>-Harry > > > I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under > 5.1-RELEASE, so it'll probably work fine under -CURRENT. However, > 3dm from the ports tree does not work. There was a list message about this back in May from Tor.Egge@... with the subject "Re: 3dmd broken" http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1035474+0+archive/2003/freebsd-current/20030601.freebsd-current which included a tiny binary patch. I tried this with the port version of 3dmd on a 5.1-Release box, and it seems to work OK. Barry From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 09:56:36 2003 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 AE16C16A4CE; Wed, 12 Nov 2003 09:56:36 -0800 (PST) Received: from regina.plastikos.com (216-107-106-250.wan.networktel.net [216.107.106.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD3643F75; Wed, 12 Nov 2003 09:56:35 -0800 (PST) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-212-172-144.jan.bellsouth.net [68.212.172.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by regina.plastikos.com (Postfix) with ESMTP id 15E0C6EECD; Wed, 12 Nov 2003 12:56:34 -0500 (EST) Received: by mortis.over-yonder.net (Postfix, from userid 100) id B9B4320F26; Wed, 12 Nov 2003 11:56:31 -0600 (CST) Date: Wed, 12 Nov 2003 11:56:31 -0600 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20031112175631.GQ12248@over-yonder.net> References: <200311110220.10204@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i-fullermd.1 X-Editor: vi X-OS: FreeBSD cc: current@FreeBSD.org Subject: Re: APIC-UP related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 17:56:36 -0000 I, for one, am always pleased to see these sort of in-depth explanations of these sort of shims. On Tue, Nov 11, 2003 at 11:35:26AM -0500 I heard the voice of John Baldwin, and lo! it spake thus: > > It's documented in /sys/i386/conf/NOTES now along with 'device apic'. For > a longer explanation of what is happening: > [...] > > So, by default, to work around motherboards that don't hook IRQ 0 > up to the I/O APIC, we route IRQ 0 through the the 8259A PICs. > [...] > > However, if NO_MIXED_MODE works, that is actually the more desirable > way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? -- 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 Wed Nov 12 10:04:08 2003 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 BE10216A4CF; Wed, 12 Nov 2003 10:04:08 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4009343FA3; Wed, 12 Nov 2003 10:04:07 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 872E35309; Wed, 12 Nov 2003 19:04:05 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id CBDD35308; Wed, 12 Nov 2003 19:03:57 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 489AEB828; Wed, 12 Nov 2003 19:03:57 +0100 (CET) To: "Matthew D. Fuller" References: <200311110220.10204@harrymail> <20031112175631.GQ12248@over-yonder.net> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 12 Nov 2003 19:03:57 +0100 In-Reply-To: <20031112175631.GQ12248@over-yonder.net> (Matthew D. Fuller's message of "Wed, 12 Nov 2003 11:56:31 -0600") 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.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.5 required=5.0 tests=RCVD_IN_DYNABLOCK autolearn=no version=2.60 cc: current@FreeBSD.org cc: John Baldwin Subject: Re: APIC-UP related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:04:08 -0000 "Matthew D. Fuller" writes: > > However, if NO_MIXED_MODE works, that is actually the more desirable > > way to run your system. > How common is the need for this? Does turning of mixed mode when it's > not needed give any real advantages higher up? NO_MIXED_MODE disables a hack which allow FreeBSD to work with mother- boards that lie about how APIC pins are wired. In general, you always want to use NO_MIXED_MODE *except* on hardware that has the bug that makes the mixed-mode hack necessary. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 10:29:47 2003 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 E64DE16A4CE; Wed, 12 Nov 2003 10:29:47 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C88AA43F75; Wed, 12 Nov 2003 10:29:44 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACIThv9096552; Wed, 12 Nov 2003 13:29:44 -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 hACIThc8096551; Wed, 12 Nov 2003 13:29:43 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 13:29:43 -0500 (EST) Message-Id: <200311121829.hACIThc8096551@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, amd64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:29:48 -0000 TB --- 2003-11-12 17:47:08 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 17:47:08 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-11-12 17:47:08 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 17:49:08 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/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.. [...] ===> bin/df cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c: In function `prtstat': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 5) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:454: warning: long long int format, long int arg (arg 7) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 3) /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df/df.c:464: warning: long long int format, int64_t arg (arg 5) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin/df. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-11-12 18:29:43 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 18:29:43 - TB --- ERROR: failed to build world TB --- 2003-11-12 18:29:43 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 10:38:53 2003 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 4B21E16A4CE for ; Wed, 12 Nov 2003 10:38:53 -0800 (PST) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id D97C743FD7 for ; Wed, 12 Nov 2003 10:38:51 -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 hACIaVk4039564; Wed, 12 Nov 2003 13:36:31 -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 hACIaVmH039563; Wed, 12 Nov 2003 13:36:31 -0500 (EST) Date: Wed, 12 Nov 2003 13:36:31 -0500 From: Mathew Kanner To: freebsd-current@freebsd.org Message-ID: <20031112183631.GD35191@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline 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.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hak.cnd.mcgill.ca cc: Cameron Grant Subject: sound patch for pop & crackles X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:38:53 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello All, Could people experiencing pops and crackles try the attached patch and set hw.snd.fragps=128. This patch also fixes select on vchans. more details in http://www.freebsd.org/cgi/query-pr.cgi?pr=59208 Thanks, --Mat -- I don't even know what street Canada is on. - Al Capone --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="channel_frag.patch" --- channel.c.old Wed Nov 12 02:42:43 2003 +++ channel.c Wed Nov 12 03:59:31 2003 @@ -41,6 +41,10 @@ #define DEB(x) x */ +static int chn_fragsps = 0; +SYSCTL_INT(_hw_snd, OID_AUTO, fragsps, CTLFLAG_RW, + &chn_fragsps, 1, "max fragments per second, 0 to disable"); + static int chn_targetirqrate = 32; TUNABLE_INT("hw.snd.targetirqrate", &chn_targetirqrate); @@ -59,7 +63,7 @@ return err; } SYSCTL_PROC(_hw_snd, OID_AUTO, targetirqrate, CTLTYPE_INT | CTLFLAG_RW, - 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", ""); + 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", "default fragment targets this IRQ rate"); static int report_soft_formats = 1; SYSCTL_INT(_hw_snd, OID_AUTO, report_soft_formats, CTLFLAG_RW, &report_soft_formats, 1, "report software-emulated formats"); @@ -113,10 +117,17 @@ chn_wakeup(struct pcm_channel *c) { struct snd_dbuf *bs = c->bufsoft; + struct pcmchan_children *pce; - CHN_LOCKASSERT(c); - if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c)) - selwakeup(sndbuf_getsel(bs)); +// CHN_LOCKASSERT(c); + if (SLIST_EMPTY(&c->children)) { + if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c)) + selwakeup(sndbuf_getsel(bs)); + } else { + SLIST_FOREACH(pce, &c->children, link) { + chn_wakeup(pce->channel); + } + } wakeup(bs); } @@ -931,7 +942,7 @@ { struct snd_dbuf *b = c->bufhard; struct snd_dbuf *bs = c->bufsoft; - int bufsz, irqhz, tmp, ret; + int irqhz, tmp, ret; CHN_LOCKASSERT(c); if (!CANCHANGE(c) || (c->flags & CHN_F_MAPPED)) @@ -960,14 +971,23 @@ DEB(printf("%s: updating (%d, %d)\n", __func__, blkcnt, blksz)); } } else { + if ( chn_fragsps != 0 && + sndbuf_getbps(bs) * sndbuf_getspd(bs) / blksz > chn_fragsps) + { + blksz = sndbuf_getbps(bs) * sndbuf_getspd(bs) / chn_fragsps; + tmp = 32; + while (tmp < blksz) + tmp <<= 1; + blksz = tmp; + if (blksz * blkcnt > CHN_2NDBUFMAXSIZE) + blkcnt = CHN_2NDBUFMAXSIZE / blksz; + } ret = EINVAL; if ((blksz < 16) || (blkcnt < 2) || (blkcnt * blksz > CHN_2NDBUFMAXSIZE)) goto out; ret = 0; c->flags |= CHN_F_HAS_SIZE; } - - bufsz = blkcnt * blksz; ret = sndbuf_remalloc(bs, blkcnt, blksz); if (ret) --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 10:45:28 2003 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 A857916A4CE for ; Wed, 12 Nov 2003 10:45:28 -0800 (PST) Received: from wolfram.com (wri-dns0.wolfram.com [140.177.205.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 896CC43FF2 for ; Wed, 12 Nov 2003 10:45:17 -0800 (PST) (envelope-from hemi@just.puresimplicity.net) Received: from just.puresimplicity.net ([140.177.207.10]) by wolfram.com (8.11.2/8.11.2) with ESMTP id hACIj9B07763; Wed, 12 Nov 2003 12:45:15 -0600 Received: (from hemi@localhost) by just.puresimplicity.net (8.12.8p2/8.12.8/Submit) id hACIj9Cf006690; Wed, 12 Nov 2003 12:45:09 -0600 (CST) (envelope-from hemi) Date: Wed, 12 Nov 2003 12:45:09 -0600 From: Josh Tolbert To: Barry Pederson Message-ID: <20031112184509.GA6540@just.puresimplicity.net> References: <3FB230A8.5000706@nortelnetworks.com> <200311121543.35074@harrymail> <20031112162543.GA5939@just.puresimplicity.net> <3FB27416.5060209@barryp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB27416.5060209@barryp.org> User-Agent: Mutt/1.4.1i cc: current@freebsd.org cc: Harald Schmalzbauer Subject: Re: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:45:28 -0000 On Wed, Nov 12, 2003 at 11:55:34AM -0600, Barry Pederson wrote: > Josh Tolbert wrote: > > >On Wed, Nov 12, 2003 at 03:43:27PM +0100, Harald Schmalzbauer wrote: > >Content-Description: signed data > > > >>On Wednesday 12 November 2003 14:07, Andrew Atrens wrote: > >> > >>>Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > >> > >>I recommended that a friend of mine. It's running without an Problem > >>under 4.7. I Don't know about newer versions but it should work well. > >> > >>-Harry > > > > > >I have a 3Ware 7000-2 (two-channel, 32-bit) running fine under > >5.1-RELEASE, so it'll probably work fine under -CURRENT. However, > >3dm from the ports tree does not work. > > There was a list message about this back in May from Tor.Egge@... with the > subject "Re: 3dmd broken" > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1035474+0+archive/2003/freebsd-current/20030601.freebsd-current > > which included a tiny binary patch. I tried this with the port version of > 3dmd on a 5.1-Release box, and it seems to work OK. > > Barry Hi Barry, Interesting. I should have searched. I wasn't running 5.1 back then. :) Either way, thank you. I'll give the patch a shot. Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 10:55:11 2003 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 9FEEF16A4CE; Wed, 12 Nov 2003 10:55:11 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D4D43F93; Wed, 12 Nov 2003 10:55:11 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id hACItAaG006605; Wed, 12 Nov 2003 10:55:10 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200311121855.hACItAaG006605@beastie.mckusick.com> To: freebsd-current@freebsd.org X-URL: http://WWW.McKusick.COM/ Date: Wed, 12 Nov 2003 10:55:10 -0800 From: Kirk McKusick Subject: HEADS-UP new statfs structure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kirk McKusick List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:55:11 -0000 The statfs structure was updated on Nov 11th with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build and boot a new kernel BEFORE doing a `make world' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Kirk McKusick From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 11:18:21 2003 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 041D416A4CF for ; Wed, 12 Nov 2003 11:18:21 -0800 (PST) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A49D843F3F for ; Wed, 12 Nov 2003 11:18:19 -0800 (PST) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 5A57B22845; Wed, 12 Nov 2003 20:18:17 +0100 (CET) Date: Wed, 12 Nov 2003 20:18:05 +0100 From: Dimitry Andric X-Mailer: The Bat! (v2.01.26) Business X-Priority: 3 (Normal) Message-ID: <5342692438.20031112201805@andric.com> To: Wiktor Niesiobedzki In-Reply-To: <20031111143115.GB231@mail.evip.pl> References: <20031111143115.GB231@mail.evip.pl> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------A31B53A2E7CC484" cc: current@freebsd.org Subject: Re: munmap & cp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 19:18:21 -0000 ------------A31B53A2E7CC484 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2003-11-11 at 15:31:15 Wiktor Niesiobedzki wrote: > $ mkdir foo > $ cd foo > $ touch foo > $ cp foo foo2 > cp: foo: Invalid argument Yes, I've just run into this problem too, because a large number of ports failed to install because of it. This is because they cp -r a number of directories to be installed, and these obviously contain 0 byte files... :( Since the cp source doesn't seem to have been touched for 4 months, it turns out that the semantics of the munmap call changed suddenly, due to "Open Group Base Specifications Issue 6", see: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c I wonder why mmap of 0 bytes is allowed to succeed, and munmap of the same amount is not, but then again, it's obviously following a standard, which doesn't have to abide to any rules of logic. ;) Anyway, cp (and possibly other tools which use munmap) will need to be fixed. For now, I simply disabled the VM_AND_BUFFER_CACHE_SYNCHRONIZED flag in the Makefile for cp, which simply disables the whole mmap'ing stuff. I don't notice any difference without it... ------------A31B53A2E7CC484 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQE/sodtsF6jCi4glqMRAm46AJsEAspVUxjvTx2/v1WdbWyDYF0WAgCdGmeF 7IkmYMLHkZe3ihaqUcw4Zps= =5mbV -----END PGP MESSAGE----- ------------A31B53A2E7CC484-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 11:23:43 2003 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 D092A16A4CE for ; Wed, 12 Nov 2003 11:23:43 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C4A543FCB for ; Wed, 12 Nov 2003 11:23:42 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 730B11FF90C; Wed, 12 Nov 2003 20:23:38 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id E4F6F1FF90A; Wed, 12 Nov 2003 20:23:36 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id A6C32154E2; Wed, 12 Nov 2003 19:23:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9C763153FA; Wed, 12 Nov 2003 19:23:26 +0000 (UTC) Date: Wed, 12 Nov 2003 19:23:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Kirk McKusick In-Reply-To: <200311121855.hACItAaG006605@beastie.mckusick.com> Message-ID: References: <200311121855.hACItAaG006605@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020300 cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP new statfs structure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 19:23:43 -0000 On Wed, 12 Nov 2003, Kirk McKusick wrote: > The statfs structure was updated on Nov 11th with 64-bit fields > to allow accurate reporting of multi-terabyte filesystem sizes. > > You should build and boot a new kernel BEFORE doing a `make world' > as the new kernel will know about binaries using the old statfs > structure, but an old kernel will not know about the new system > calls that support the new statfs structure. Running an old kernel > after a `make world' will cause programs such as `df' that do a > statfs system call to fail with a bad system call. shouldn't in addition to this mail requested by Scott UPDATING also be updated ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 11:56:01 2003 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 D792B16A4CE for ; Wed, 12 Nov 2003 11:56:01 -0800 (PST) Received: from mandarin.fruitsalad.org (pc117.net160.koping.net [81.16.160.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0560643FD7 for ; Wed, 12 Nov 2003 11:56:00 -0800 (PST) (envelope-from matt@hasta.se) Received: from [192.168.15.46] (helo=klementin) by mandarin.fruitsalad.org with smtp (Exim 4.14) id 1AK15g-000AC4-K6; Wed, 12 Nov 2003 20:55:48 +0100 From: "Matt Douhan" To: "Josh Tolbert" , "Barry Pederson" Date: Wed, 12 Nov 2003 20:56:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20031112184509.GA6540@just.puresimplicity.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: current@freebsd.org cc: Harald Schmalzbauer Subject: SV: which 3ware controllers are supported ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 19:56:02 -0000 -----Ursprungligt meddelande----- Fran: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org]For Josh Tolbert >> > >>>Anyone using a "3WARE ESCALADE 7500-4LP ATA RAID CARD" ? > >> we use the 7500-8 ATA card on STABLE and CURRENT with 8x160GB drives in RAID 5 mode, we have no problems what soever, and we have replaced drives and successfully rebuilt arrays with no data loss at all. so I guess a works for me (tm) is in order Rgds Matt www.fruitsalad.org From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 11:57:00 2003 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 C7CB816A4CE; Wed, 12 Nov 2003 11:57:00 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB7A4403B; Wed, 12 Nov 2003 11:56:58 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACJuvv9056185; Wed, 12 Nov 2003 14:56:57 -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 hACJuvG7056184; Wed, 12 Nov 2003 14:56:57 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 14:56:57 -0500 (EST) Message-Id: <200311121956.hACJuvG7056184@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, i386@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 19:57:01 -0000 TB --- 2003-11-12 18:29:44 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 18:29:44 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-12 18:29:44 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 18:32:52 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/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 --- 2003-11-12 19:31:11 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 19:31:11 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 19:46:03 GMT 2003 TB --- 2003-11-12 19:46:03 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 19:46:03 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 19:46:03 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_partition/mac_partition! .c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_portacl/mac_portacl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_seeotheruids/mac_seeoth! eruids.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_stub/mac_stub.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_test/mac_test.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_test/mac_test.c: In function `mac_test_check_kenv_dump': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_test/mac_test.c:1068: error: request for member `l_perpolicy' in something not a structure or union /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_test/mac_test.c:1068: error: request for member `l_perpolicy' in something not a structure or union *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-11-12 19:56:57 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 19:56:57 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-12 19:56:57 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 12:31:20 2003 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 EF1CE16A4CE; Wed, 12 Nov 2003 12:31:20 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C9C943FE3; Wed, 12 Nov 2003 12:31:12 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:6jncerZMCbYEeC1esOkVvRKkyXsVywPWWJeKNNqlj/i/0p/yLbuJyBjHKCCIGuBR@mille.mahoroba.org [IPv6:3ffe:501:185b:8010:202:2dff:fe41:8630]) (user=ume mech=CRAM-MD5 bits=0)hACKU4EU007926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2003 05:30:05 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 13 Nov 2003 05:30:04 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FB2503E.53B21470@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> <3FB2503E.53B21470@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.9-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.6 required=5.0 tests=DOMAIN_4U2 autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 20:31:21 -0000 Hi, >>>>> On Wed, 12 Nov 2003 16:22:38 +0100 >>>>> Andre Oppermann said: oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made oppermann> a mistake with the hashmask. oppermann> The updated patch is here: oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch oppermann> Could you try again please? It does repeatable panic. Unfortunately, my laptop hanguped during dumping core, and I couldn't get core. So, I copied the output from ddb by hand. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc05b68c5 stack pointer = 0x10:0xd208ea28 frame pointer = 0x10:0xd208ea64 code segment = base 0x0, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27 (swi1: net) kernel: type 12 trap, code=0 Stopped at in6_selecthlim+0x35: cmpl $0,0x1c(%esi) db> trace in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c syncache_add(d208eb80,d208ebf4,c1fc4836,d208eb4c,c19a0600) at syncache_add+0x4f4 tcp_input(c19a0600,28,0,d208ec40,6) at tcp_input+0xdae tcp6_input(d208ec84,d208ec60,6,d208ec84,28) at tcp6_input+0xf5 ip6_input(c19a0600,d018930f,39d40a1e,c0724474,0) at ip6_input+0xc18 netisr_processqueue(c06f0484,aa,7b1c1ccb,351110b4,c050250d) at netisr_processqueue+0xd9 swi_net(0,0,0,0,c199254c) at swi_net+0xd9 ithread_loop(c1988580,d208ed48,4d,55ff44fd,0) at ithread_loop+0x1d8 fork_exit(c04e4d90,c1988580,d208ed48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd208ed7c, ebp = 0 --- db> Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 12:45:15 2003 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 D322A16A4CE for ; Wed, 12 Nov 2003 12:45:15 -0800 (PST) Received: from freebsd.petanna.net (host81-136-58-113.in-addr.btopenworld.com [81.136.58.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7184F43FE1 for ; Wed, 12 Nov 2003 12:45:09 -0800 (PST) (envelope-from peter@circlesquared.com) Received: from circlesquared.com (localhost.petanna.net [127.0.0.1]) by freebsd.petanna.net (8.12.10/8.12.6) with ESMTP id hACKlOIe046472; Wed, 12 Nov 2003 20:47:27 GMT (envelope-from peter@circlesquared.com) Message-ID: <3FB29C5C.6090803@circlesquared.com> Date: Wed, 12 Nov 2003 20:47:24 +0000 From: Peter Risdon User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20031102 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jaco H. van Tonder" References: <3FB20370.7060807@circlesquared.com> <099401c3a939$322ac680$3635a8c0@jaco> In-Reply-To: <099401c3a939$322ac680$3635a8c0@jaco> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Intel 865 probs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 20:45:16 -0000 Jaco, Thanks for this. Jaco H. van Tonder wrote: >For what its worth, I had a lot of problems on the I865P board, and It >boiled down to memory corruption. >The machine had lots of "random" crashes, meanng that they were not occuring >when I do something specific. >The machine startted to panic as soon as the load got high. >I took out the memory, and placed it into another slot and the machine is >cruising along happily now. > > I played with the memory slots as soon as the problems started, and found memtest would sometimes throw up huge numbers of errors, and sometimes none at all. FWIW slot 1 was the worst. But I suspect, no more than that, some other problem as well. >The other questions is what is the date of the -CURRENT tree that is giving >this problems? I can recall quite a few problems, which were fixed, that >could cause this problem. > > Nov 10. I ran cvsup at about 9:00am GMT. Peter Risdon. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 12:49:50 2003 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 DE2D116A4CF for ; Wed, 12 Nov 2003 12:49:50 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E63CD43FE3 for ; Wed, 12 Nov 2003 12:49:47 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 24248 invoked from network); 12 Nov 2003 20:52:39 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 20:52:39 -0000 Message-ID: <3FB29CEA.1F5B9149@pipeline.ch> Date: Wed, 12 Nov 2003 21:49:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> <3FB2503E.53B21470@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 20:49:51 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Wed, 12 Nov 2003 16:22:38 +0100 > >>>>> Andre Oppermann said: > > oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made > oppermann> a mistake with the hashmask. > oppermann> The updated patch is here: > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch > oppermann> Could you try again please? > > It does repeatable panic. Unfortunately, my laptop hanguped during > dumping core, and I couldn't get core. So, I copied the output from > ddb by hand. -snip- > Stopped at in6_selecthlim+0x35: cmpl $0,0x1c(%esi) > db> trace > in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 > syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c Grmpf... That is a logic error by me. Please add the following check on line 707 in the patched netinet6/in6_src.c: else if (in6p && !IN6_IS_ADDR_UNSPECIFIED(&in6p->in6p_faddr)) { ^^^^ ^^ Thank you for your effort in testing my changes! -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 13:19:09 2003 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 0DF2316A4CE; Wed, 12 Nov 2003 13:19:09 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316DF43FA3; Wed, 12 Nov 2003 13:19:07 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACLJ6v9011356; Wed, 12 Nov 2003 16:19:06 -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 hACLJ6Ug011355; Wed, 12 Nov 2003 16:19:06 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 16:19:06 -0500 (EST) Message-Id: <200311122119.hACLJ6Ug011355@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, i386@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 21:19:09 -0000 TB --- 2003-11-12 19:56:57 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 19:56:57 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-12 19:56:57 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 19:59:09 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/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 --- 2003-11-12 20:57:31 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 12 20:57:31 GMT 2003 >>> Kernel build for GENERIC completed on Wed Nov 12 21:09:45 GMT 2003 TB --- 2003-11-12 21:09:45 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-12 21:09:45 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 12 21:09:45 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_partition/mac_partition! .c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_portacl/mac_portacl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_seeotheruids/mac_seeoth! eruids.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_stub/mac_stub.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_test/mac_test.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_test/mac_test.c: In function `mac_test_check_kenv_dump': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_test/mac_test.c:1068: error: request for member `l_perpolicy' in something not a structure or union /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_test/mac_test.c:1068: error: request for member `l_perpolicy' in something not a structure or union *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-11-12 21:19:06 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 21:19:06 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-12 21:19:06 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 13:49:26 2003 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 449CA16A4CF; Wed, 12 Nov 2003 13:49:26 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 299CA43FB1; Wed, 12 Nov 2003 13:49:25 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) hACLnOv9061048; Wed, 12 Nov 2003 16:49:24 -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 hACLnO8E061047; Wed, 12 Nov 2003 16:49:24 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Wed, 12 Nov 2003 16:49:24 -0500 (EST) Message-Id: <200311122149.hACLnO8E061047@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 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: Wed, 12 Nov 2003 21:49:26 -0000 TB --- 2003-11-12 21:34:58 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-12 21:34:58 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-12 21:34:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-12 21:36:59 - 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 [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `build_access_request': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c:114: warning: cast increases required alignment of target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-12 21:49:24 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-12 21:49:24 - TB --- ERROR: failed to build world TB --- 2003-11-12 21:49:24 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 13:49:30 2003 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 73B3016A4CF; Wed, 12 Nov 2003 13:49:30 -0800 (PST) Received: from hexagon.stack.nl (hexagon.stack.nl [131.155.140.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6017143FB1; Wed, 12 Nov 2003 13:49:29 -0800 (PST) (envelope-from marcolz@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010:2e0:81ff:fe22:51d8]) by hexagon.stack.nl (Postfix) with ESMTP id E3FD85148; Wed, 12 Nov 2003 22:49:27 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 333) id C5DF11CC71; Wed, 12 Nov 2003 22:49:27 +0100 (CET) Date: Wed, 12 Nov 2003 22:49:27 +0100 From: Marc Olzheim To: Robert Watson Message-ID: <20031112214927.GA43616@stack.nl> References: <3FAFA5A3.3000704@xtaz.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD turtle.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.5.1i cc: Soren Schmidt cc: current@freebsd.org Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 21:49:30 -0000 On Mon, Nov 10, 2003 at 11:28:40AM -0500, Robert Watson wrote: > How fast are your systems, speaking of which? I live in the world of > 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're > using multi-ghz boxes, that could well be the distinguishing factor > between our configurations... I collected some information from my client and server, just before my server crashed (probably because of this), including a tcpdump of the last seconds before it stops... http://www.stack.nl/~marcolz/FreeBSD/NFS/ Zlo From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 14:25:25 2003 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 0B40E16A4CF for ; Wed, 12 Nov 2003 14:25:25 -0800 (PST) Received: from mail.evip.pl (mail.evip.com.pl [212.244.157.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6D6F43FAF for ; Wed, 12 Nov 2003 14:25:23 -0800 (PST) (envelope-from w@evip.pl) Received: from drwebc by mail.evip.pl with drweb-scanned (Exim 4.22) id 1AK3QL-000GvB-Cj; Wed, 12 Nov 2003 23:25:17 +0100 Received: from w by mail.evip.pl with local (Exim 4.22) id 1AK3QL-000Gv2-9l; Wed, 12 Nov 2003 23:25:17 +0100 Date: Wed, 12 Nov 2003 23:25:17 +0100 From: Wiktor Niesiobedzki To: Dimitry Andric Message-ID: <20031112222517.GJ231@mail.evip.pl> References: <20031111143115.GB231@mail.evip.pl> <5342692438.20031112201805@andric.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline In-Reply-To: <5342692438.20031112201805@andric.com> User-Agent: Mutt/1.4i Sender: Wiktor Niesiobedzki cc: current@freebsd.org Subject: Re: munmap & cp [patch enclosed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 22:25:25 -0000 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 12, 2003 at 08:18:05PM +0100, Dimitry Andric wrote: > On 2003-11-11 at 15:31:15 Wiktor Niesiobedzki wrote: > > > $ mkdir foo > > $ cd foo > > $ touch foo > > $ cp foo foo2 > > cp: foo: Invalid argument > Anyway, cp (and possibly other tools which use munmap) will need to be > fixed. For now, I simply disabled the VM_AND_BUFFER_CACHE_SYNCHRONIZED > flag in the Makefile for cp, which simply disables the whole mmap'ing > stuff. I don't notice any difference without it... I would still propose my one-line solution, to use mmap only when the file size is greater than 0. As far as I looked into source tree, most usages of munmap are in unsafe way - i.e. without checking the return value. Is there someone willing to commit this trival change? For now, some number of ports will refuse tu build/install. Cheers, Wiktor Niesiobedzki PS. The acctual patch attached. --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch --- utils.c 2003/06/22 07:02:17 1.41 +++ utils.c 2003/11/11 14:32:17 @@ -133,7 +133,7 @@ * wins some CPU back. */ #ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED + if (S_ISREG(fs->st_mode) && fs->st_size <= 8 * 1048576 && fs->st_size > 0) { - if (S_ISREG(fs->st_mode) && fs->st_size <= 8 * 1048576) { if ((p = mmap(NULL, (size_t)fs->st_size, PROT_READ, MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) { warn("%s", entp->fts_path); --ylS2wUBXLOxYXZFQ-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 14:37:22 2003 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 238A716A4CE for ; Wed, 12 Nov 2003 14:37:22 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ECCC43F93 for ; Wed, 12 Nov 2003 14:37:20 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id hACMbI7o009611 for ; Wed, 12 Nov 2003 23:37:19 +0100 (CET) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9p2/8.12.9) with ESMTP id hACMbI0P072425 for ; Wed, 12 Nov 2003 23:37:18 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9p2/8.12.9/Submit) id hACMbIOM072424 for freebsd-current@freebsd.org; Wed, 12 Nov 2003 23:37:18 +0100 (CET) (envelope-from wkb) Date: Wed, 12 Nov 2003 23:37:18 +0100 From: Wilko Bulte To: freebsd-current@freebsd.org Message-ID: <20031112223718.GA72413@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-STABLE X-PGP: finger wilko@freebsd.org Subject: buildworld failure on sparc64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 22:37:22 -0000 ===> lib/libpam/modules/pam_radius cc -O -pipe -I/usr/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_radius/pam_radius.c /usr/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `build_access_request': /usr/src/lib/libpam/modules/pam_radius/pam_radius.c:114: warning: cast increases required alignment of target type *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 ? -- | / o / /_ _ |/|/ / / /( (_) Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 14:38:25 2003 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 548AD16A4CE for ; Wed, 12 Nov 2003 14:38:25 -0800 (PST) Received: from smaug.vex.net (H211.C136.B246.tor.eicat.ca [66.246.136.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3830F43FE3 for ; Wed, 12 Nov 2003 14:38:24 -0800 (PST) (envelope-from x@Vex.Net) Received: from bee.vii.net (unknown [209.135.116.67]) by smaug.vex.net (Postfix) with ESMTP id BB28648599 for ; Wed, 12 Nov 2003 17:38:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bee.vii.net (Postfix) with ESMTP id A05B85C7A for ; Wed, 12 Nov 2003 17:38:14 -0500 (EST) From: Tim Middleton Organization: xxvii.net To: freebsd-current@freebsd.org Date: Wed, 12 Nov 2003 17:38:13 -0500 User-Agent: KMail/1.5.4 References: <200311112149.hABLnZeF070361@gw.catspoiler.org> <3FB1B8B3.8090403@bgp4.net> In-Reply-To: <3FB1B8B3.8090403@bgp4.net> X-Whee: Yes, Please. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311121738.13783.x@Vex.Net> Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 22:38:25 -0000 On November 11, 2003 11:36 pm, Janet Sullivan wrote: > So far I only have problems in a mixed -STABLE/-CURRENT environment. > When the client & server are both -CURRENT I haven't had any problems. I just installed another -STABLE box to see if keeping them both -STABLE helps. I haven't really tested the NFS yet as I didn't want to risk locking the box up in the middle of a buildworld. So i just mounted the NFS drive on the new test box and left it.... Within an hour the NFS server box doing the build world was locked up solid. I can't say if it was NFS mount related or not; nfsd wasn't really doing anything. Doesn't seem like it would have been. Beginning to wonder if it is some strange hardware problem on this box; which coincidentally only shows up when there's an nfs mount! But that doesn't explain why my normally rock solid desktop system tanked when being tested as an NFS client to that STABLE box. Hmmm... Back to testing. I'm doing heavy disk I/O tests without any NFS mounts now. If they go okay, back to the NFS mounting and testing... It seems to me there is something desperately wrong with NFS is mixing -CURRENT and -STABLE NFS server/clients causes either side (in my case both sides) to lock up solid. I mean, problems are problems... but solid lockups with no crash messages or anything is ... nasty. > Are the folks seeing hangs getting any kind of console error messages? I see nothing. My server is completely locks up. Nothing responds. The drive light (the times i've noticed) is frozen "on". On my desktop box the mouse is dead as well. > I don't see anything - performance just tanks to the point of being > unusable. When testing with my desktop box as client, i noticed just before or just when the NFS locked up the mouse and keyboard response would be very erratic ... slow and jerky. -- Tim Middleton | Cain Gang Ltd | "Who is Ungit?" said he, still holding x@veX.net | www.Vex.Net | my hands. --C.S.Lewis (TWHF) From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 14:53:30 2003 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 635A116A4CE; Wed, 12 Nov 2003 14:53:30 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B4CC43FB1; Wed, 12 Nov 2003 14:53:28 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 91134384E7; Wed, 12 Nov 2003 23:53:26 +0100 (CET) Date: Wed, 12 Nov 2003 23:53:26 +0100 From: Jesper Skriver To: Andre Oppermann Message-ID: <20031112225326.GI41949@FreeBSD.org> Mail-Followup-To: Jesper Skriver , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org, sam@errno.com, mb@imp.ch, ume@freebsd.org References: <3FAE68FB.64D262FF@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 22:53:30 -0000 On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > Hello all, > > this patch contains three things (to be separated for committing): > > tcp_hostcache > > - removes protocol cloning from routing table (IPv4+6) > - removes rtentry pointer from inpcb and in6pcb > - removes ip route cache in ip_input.c (locking much easier) > - removes most (tcp specific) metrics from rtentry metrics > - adds a hostcache table which carries the metrics for tcp > - works transparently for IPv4 and IPv6 > - is designed for concurrent access in SMP environments > - significant reduction of routing table size (no cloning anymore) > - eases many routing table locking situations in ip/tcp code > > ip_fastforward > > - removes ip_flow forwarding code > - adds full direct process-to-completion IPv4 forwarding code > - handles ip fragmentation incl. hw support (ip_flow did not) > - supports ipfw and ipfilter (ip_flow did not) > - supports divert and ipfw fwd (ip_flow did not) > - drops anything it can't handle back to normal ip_input I have a few comments to this code, see inline, look for #jesper Apart from that it looks good. /Jesper > +int > +ip_fastforward(struct mbuf *m) > +{ > + struct ip *ip; > + struct mbuf *m0 = NULL; > +#ifdef IPDIVERT > + struct ip *tip; > + struct mbuf *teem = NULL; > +#endif > + struct mbuf *tag = NULL; > + struct route ro; > + struct sockaddr_in *dst = NULL; > + struct in_ifaddr *ia = NULL; > + struct ifaddr *ifa = NULL; > + struct ifnet *ifp = NULL; > + struct ip_fw_args args; > + in_addr_t odest, dest; > + u_short sum; > + int hlen; > + int error = 0; > + int ipfw; > + > + /* > + * Are we active and forwarding packets? > + */ > + if (!ipfastforward_active || !ipforwarding) > + return 0; > + > + /* > + * If there is any MT_TAG we fall back to ip_input because we can't > + * handle TAGs here. > + */ > + if (m && m->m_type == MT_TAG) > + return 0; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + [...] > + > + /* > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > + * no multicast, no INADDR_ANY > + */ > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || #jesper You will never see packets with a multicast source address. > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) || > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) || > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) || > + (ip->ip_dst.s_addr == INADDR_ANY) ) > + goto fallback; > + > + /* > + * Is it for a local address on this host? > + */ > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > + goto fallback; > + } > + } > + > + /* > + * Or is it for a local IP broadcast address on this host? > + */ > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) { > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) { > + if (ifa->ifa_addr->sa_family != AF_INET) > + continue; > + ia = ifatoia(ifa); > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr) > + goto fallback; > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == > + ip->ip_dst.s_addr) > + goto fallback; > + continue; > +fallback: > + /* drop the packet back to netisr */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + return 0; > + } > + } > + ipstat.ips_total++; #jesper If we stored special "for us" /32 routes in the routing table for addresses configured on this host, we could avoid the above 2 loops, which can quite expensive. These special routes will simply mean that the packet is for us, and needs to given to ip_input > + /** > + ** Third: incoming packet firewall processing > + **/ > + > + odest = dest = ip->ip_dst.s_addr; #jesper You could save a few cycles by doing #ifdef PFIL_HOOKS odest = ip->ip_dst.s_addr; /* * Run through list of ipfilter hooks for input packets */ if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || m == NULL) return 1; M_ASSERTVALID(m); M_ASSERTPKTHDR(m); ip = mtod(m, struct ip *); /* if m changed during fw processing */ dest = ip->ip_dst.s_addr; #else odest = dest = ip->ip_dst.s_addr; #endif Thus avoiding writing to dest twice. > +#ifdef PFIL_HOOKS > + /* > + * Run through list of ipfilter hooks for input packets > + */ > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > + m == NULL) > + return 1; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > + dest = ip->ip_dst.s_addr; > +#endif > + > + /* > + * Run through ipfw for input packets > + */ > + if (fw_enable && IPFW_LOADED) { > + bzero(&args, sizeof(args)); > + args.m = m; > + ipfw = 0; > + > + ipfw = ip_fw_chk_ptr(&args); > + m = args.m; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /* > + * Packet denied, drop it > + */ > + if ( (ipfw & IP_FW_PORT_DENY_FLAG) || m == NULL) { > + if (m) > + m_freem(m); > + return 1; > + } > + /* > + * Send packet to the appropriate pipe > + */ > + if (DUMMYNET_LOADED && (ipfw & IP_FW_PORT_DYNT_FLAG) != 0) { #jesper Whitespace bug, spaces instead of tabs > + ip_dn_io_ptr(m, ipfw & 0xffff, DN_TO_IP_IN, &args); > + return 1; > + } > +#ifdef IPDIVERT > + /* > + * Divert packet > + */ > + if (ipfw != 0 && (ipfw & IP_FW_PORT_DYNT_FLAG) == 0) { > + /* > + * See if this is a fragment > + */ > + if (ip->ip_off & (IP_MF | IP_OFFMASK)) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + return 1; > + } > + tag->m_flags = PACKET_TAG_DIVERT; > + tag->m_data = (caddr_t)(u_long)args.divert_rule; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + > + goto droptoours; #jesper Whitespace bug, spaces instead of tabs > + } > + /* > + * Tee packet > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) > + teem = m_dup(m, M_DONTWAIT); > + else > + teem = m; > + if (teem == NULL) > + goto passin; > + > + M_ASSERTVALID(teem); > + M_ASSERTPKTHDR(teem); > + > + /* > + * Delayed checksums are not compatible > + */ > + if (teem->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + in_delayed_cksum(teem); > + teem->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > + } > + /* > + * Restore packet header fields to original values > + */ > + tip = mtod(teem, struct ip *); > + tip->ip_len = htons(tip->ip_len); > + tip->ip_off = htons(tip->ip_off); > + /* > + * Deliver packet to divert input routine > + */ > + divert_packet(teem, 0, ipfw & 0xffff, args.divert_rule); > + /* > + * If this was not tee, we are done > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) > + return 1; > + /* Continue if it was tee */ > + goto passin; > + } > +#endif > + if (ipfw == 0 && args.next_hop != NULL) { > + dest = args.next_hop->sin_addr.s_addr; > + goto passin; > + } > + /* > + * Let through or not? > + */ > + if (ipfw != 0) { > + m_freem(m); > + return 1; > + } > + } > +passin: > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > + > + /* > + * Destination address changed? > + */ > + if (odest != dest) { > + /* > + * Is it now for a local address on this host? > + */ > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) > + goto forwardlocal; > + } #jesper Same comment as above - and do we really want to see if the original destination address was ours if we're doing NAT ? > + /* > + * Go on with new destination address > + */ > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /** > + ** Forth: decrement TTL and look up route > + **/ > + > + /* > + * Check TTL > + */ > +#ifdef IPSTEALTH > + if (!ipstealth) { > +#endif > + if (ip->ip_ttl <= IPTTLDEC) { > + icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, NULL, NULL); > + return 1; > + } > + > + /* > + * Decrement the TTL and incrementally change the checksum. > + * Don't bother doing this with hw checksum offloading. > + */ > + ip->ip_ttl -= IPTTLDEC; > + if (ip->ip_sum >= (u_int16_t) ~htons(IPTTLDEC << 8)) > + ip->ip_sum -= ~htons(IPTTLDEC << 8); > + else > + ip->ip_sum += htons(IPTTLDEC << 8); > +#ifdef IPSTEALTH > + } > +#endif > + > + /* > + * Find route to destination. > + */ > + bzero(&ro, sizeof(ro)); > + dst = (struct sockaddr_in *)&ro.ro_dst; > + dst->sin_family = AF_INET; > + dst->sin_len = sizeof(*dst); > + dst->sin_addr.s_addr = dest; > + rtalloc(&ro); > + > + /* > + * Route there and interface still up? > + */ > + if ((ro.ro_rt) && > + (ro.ro_rt->rt_flags & RTF_UP) && > + (ro.ro_rt->rt_ifp->if_flags & IFF_UP)) { > + ia = ifatoia(ro.ro_rt->rt_ifa); > + ifp = ro.ro_rt->rt_ifp; > + if (ro.ro_rt->rt_flags & RTF_GATEWAY) > + dst = (struct sockaddr_in *)ro.ro_rt->rt_gateway; > + } else { > + ipstat.ips_noroute++; > + ipstat.ips_cantforward++; > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, NULL, NULL); > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + > + > + /** > + ** Fifth: outgoing firewall packet processing > + **/ > + > +#ifdef PFIL_HOOKS > + /* > + * Run through list of hooks for output packets. > + */ > + if (pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT) || > + m == NULL) { > + RTFREE(ro.ro_rt); > + return 1; > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + ip = mtod(m, struct ip *); > + dest = ip->ip_dst.s_addr; > +#endif > + if (fw_enable && IPFW_LOADED && !args.next_hop) { > + bzero(&args, sizeof(args)); > + args.m = m; > + args.oif = ifp; > + ipfw = 0; > + > + ipfw = ip_fw_chk_ptr(&args); > + m = args.m; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + if ( (ipfw & IP_FW_PORT_DENY_FLAG) || m == NULL) { > + if (m) > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + if (DUMMYNET_LOADED && (ipfw & IP_FW_PORT_DYNT_FLAG) != 0) { #jesper Whitespace bug, spaces instead of tabs > + /* > + * XXX note: if the ifp or rt entry are deleted > + * while a pkt is in dummynet, we are in trouble! > + */ > + args.ro = &ro; /* dummynet does not save it */ > + args.dst = dst; > + > + ip_dn_io_ptr(m, ipfw & 0xffff, DN_TO_IP_OUT, &args); > + RTFREE(ro.ro_rt); > + return 1; > + } > +#ifdef IPDIVERT > + if (ipfw != 0 && (ipfw & IP_FW_PORT_DYNT_FLAG) == 0) { > + /* > + * See if this is a fragment > + */ > + if (ip->ip_off & (IP_MF | IP_OFFMASK)) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_DIVERT; > + tag->m_data = (caddr_t)(u_int32_t)args.divert_rule; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + > + goto droptoours; > + } > + /* > + * Tee packet > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) > + teem = m_dup(m, M_DONTWAIT); > + else > + teem = m; > + if (teem == NULL) > + goto passout; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /* > + * delayed checksums are not compatible with divert > + */ > + if (teem->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + in_delayed_cksum(teem); > + teem->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > + } > + /* > + * Restore packet header fields to original values > + */ > + tip = mtod(teem, struct ip *); > + tip->ip_len = htons(tip->ip_len); > + tip->ip_off = htons(tip->ip_off); > + /* > + * Deliver packet to divert input routine > + */ > + divert_packet(teem, 0, ipfw & 0xffff, args.divert_rule); > + /* > + * If this was not tee, we are done > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) { > + RTFREE(ro.ro_rt); > + return 1; > + } > + /* Continue if it was tee */ > + goto passout; > + } > +#endif > + if (ipfw == 0 && args.next_hop != NULL) { > + dest = args.next_hop->sin_addr.s_addr; > + goto passout; > + } > + /* > + * Let through or not? > + */ > + if (ipfw != 0) { > + m_freem(m); > + return 1; > + } > + } > +passout: > + ip = mtod(m, struct ip *); > + > + /* > + * Destination address changed? > + */ > + if (odest != dest) { > + /* > + * Is it now for a local address on this host? > + */ #jesper Again, do we really want to look for packets destined for us after being translated ? > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > +forwardlocal: > + if(args.next_hop) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + if(ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_IPFORWARD; > + tag->m_data = (caddr_t)args.next_hop; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + } > +#ifdef IPDIVERT > +droptoours: /* Used for DIVERT */ > +#endif > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + if(ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_IPFASTFWD_OURS; > + tag->m_data = NULL; > + tag->m_next = m; #jesper Whitespace bug, spaces instead of tabs > + m = tag; > + tag = NULL; > + > +#if 0 > + /* > + * Do some checks, we never know what fw has > + * done to it. > + */ > + if (m->m_pkthdr.rcvif == NULL) > + m->m_pkthdr.rcvif = ifunit("lo0"); > + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + m->m_pkthdr.csum_flags |= > + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; > + m->m_pkthdr.csum_data = 0xffff; > + } > + m->m_pkthdr.csum_flags |= > + CSUM_IP_CHECKED | CSUM_IP_VALID; > +#endif > + > + /* ip still points to the real packet */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + > + M_ASSERTVALID(m); > + > + /* > + * Drop packet to ip_input > + */ > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 0; > + } > + } > + /* > + * Redo route lookup with new destination address > + */ > + RTFREE(ro.ro_rt); > + bzero(&ro, sizeof(ro)); > + dst = (struct sockaddr_in *)&ro.ro_dst; > + dst->sin_family = AF_INET; > + dst->sin_len = sizeof(*dst); > + dst->sin_addr.s_addr = dest; > + rtalloc(&ro); > + > + /* > + * Route there and interface still up? > + */ > + if ((ro.ro_rt) && > + (ro.ro_rt->rt_flags & RTF_UP) && > + (ro.ro_rt->rt_ifp->if_flags & IFF_UP)) { > + ia = ifatoia(ro.ro_rt->rt_ifa); > + ifp = ro.ro_rt->rt_ifp; > + if (ro.ro_rt->rt_flags & RTF_GATEWAY) > + dst = (struct sockaddr_in *)ro.ro_rt->rt_gateway; > + } else { > + ipstat.ips_noroute++; > + ipstat.ips_cantforward++; > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, NULL, NULL); > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /** > + ** Sixth: send off the packet > + **/ > + > + /* > + * Check if packet fits MTU or if hardware will fragement for us > + */ > + if (ip->ip_len <= ifp->if_mtu || (ifp->if_hwassist & CSUM_FRAGMENT && > + ((ip->ip_off & IP_DF) == 0))) { > + /* > + * Restore packet header fields to original values > + */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + /* > + * Send off the packet via outgoing interface > + */ > + error = (ifp->if_output)(ifp, m, (struct sockaddr *)dst, ro.ro_rt); > + if (ia) { > + ia->ia_ifa.if_opackets++; > + ia->ia_ifa.if_obytes += m->m_pkthdr.len; > + } > + } else { > + /* > + * Handle EMSGSIZE with icmp reply needfrag for TCP MTU discovery > + */ > + if (ip->ip_off & IP_DF) { > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_NEEDFRAG, NULL, ifp); > + ipstat.ips_cantfrag++; > + RTFREE(ro.ro_rt); > + return 1; > + } else { > + /* > + * We have to fragement the packet > + */ > + m->m_pkthdr.csum_flags |= CSUM_IP; > + if (ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist, > + (~ifp->if_hwassist & CSUM_DELAY_IP))) { > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + /* > + * Send off the fragments via outgoing interface > + */ > + for (; m; m = m0) { > + m0 = m->m_nextpkt; > + m->m_nextpkt = 0; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + if (error == 0) { > + error = (*ifp->if_output)(ifp, m, > + (struct sockaddr *)dst, ro.ro_rt); > + if (ia) { > + ia->ia_ifa.if_opackets++; > + ia->ia_ifa.if_obytes += m->m_pkthdr.len; > + } > + } else { > + m_freem(m); > + } > + } > + if (error == 0) > + ipstat.ips_fragmented++; > + } > + } > + > + if (error == ENOBUFS) > + ipstat.ips_odropped++; > + else if (error != 0) > + ipstat.ips_odropped++; > + else { > + ro.ro_rt->rt_rmx.rmx_pksent++; > + ipstat.ips_forward++; > + ipstat.ips_fastforward++; > + } > + RTFREE(ro.ro_rt); > + return 1; > +} > + From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 15:11:09 2003 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 A06AD16A4CE for ; Wed, 12 Nov 2003 15:11:09 -0800 (PST) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAA3643FDD for ; Wed, 12 Nov 2003 15:11:08 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 7180 invoked from network); 12 Nov 2003 23:11:08 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Nov 2003 23:11:08 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hACNAice028230 for ; Wed, 12 Nov 2003 18:10:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 12 Nov 2003 18:10:42 -0500 (EST) From: John Baldwin To: current@FreeBSD.org X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: HEADSUP: I toasted SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 23:11:09 -0000 My turnstile changes have toasted SMP on current. Symptoms include a page fault in the priority propagation code. If I can't get it fixed tomorrow I will back out the turnstile changes. For now you can do 'set kern.smp.disabled=1' at the loader prompt to disable SMP and your kernel should still work fine as a UP kernel. Sorry for the inconvenience. :( -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 15:13:19 2003 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 6253416A4DD for ; Wed, 12 Nov 2003 15:13:19 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5AE343FDF for ; Wed, 12 Nov 2003 15:13:15 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 33232 invoked from network); 12 Nov 2003 23:16:07 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 23:16:07 -0000 Message-ID: <3FB2BE8A.6C880085@pipeline.ch> Date: Thu, 13 Nov 2003 00:13:14 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jesper Skriver References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 23:13:19 -0000 Jesper Skriver wrote: > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > Hello all, > > > > this patch contains three things (to be separated for committing): ... > > ip_fastforward > > > > - removes ip_flow forwarding code > > - adds full direct process-to-completion IPv4 forwarding code > > - handles ip fragmentation incl. hw support (ip_flow did not) > > - supports ipfw and ipfilter (ip_flow did not) > > - supports divert and ipfw fwd (ip_flow did not) > > - drops anything it can't handle back to normal ip_input > > I have a few comments to this code, see inline, look for #jesper Answers also inline. [All whitespace bugs are fixed and omitted here] > Apart from that it looks good. Thanks for reviewing! > /Jesper > > > +int > > +ip_fastforward(struct mbuf *m) > > +{ ... > > + > > + /* > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > + * no multicast, no INADDR_ANY > > + */ > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > #jesper > You will never see packets with a multicast source address. I hope so but we can never be sure. Here we look at what we've got straight from the wire. Everything is possible there. I only need to craft an apropriate packet... > > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) || > > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) || > > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) || > > + (ip->ip_dst.s_addr == INADDR_ANY) ) > > + goto fallback; ... > > + /* > > + * Or is it for a local IP broadcast address on this host? > > + */ > > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) { > > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) { > > + if (ifa->ifa_addr->sa_family != AF_INET) > > + continue; > > + ia = ifatoia(ifa); > > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr) > > + goto fallback; > > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == > > + ip->ip_dst.s_addr) > > + goto fallback; > > + continue; > > +fallback: > > + /* drop the packet back to netisr */ > > + ip->ip_len = htons(ip->ip_len); > > + ip->ip_off = htons(ip->ip_off); > > + return 0; > > + } > > + } > > + ipstat.ips_total++; > > #jesper > If we stored special "for us" /32 routes in the routing table for > addresses configured on this host, we could avoid the above 2 loops, > which can quite expensive. Good idea. I will look at that after 5.2 code freeze. > These special routes will simply mean that the packet is for us, and > needs to given to ip_input > > > + /** > > + ** Third: incoming packet firewall processing > > + **/ > > + > > + odest = dest = ip->ip_dst.s_addr; > > #jesper > You could save a few cycles by doing Well, you're right. However I don't think it makes any difference and I'd like to keep it the current way for clarity and ease of reading and understanding the code. > #ifdef PFIL_HOOKS > odest = ip->ip_dst.s_addr; > /* > * Run through list of ipfilter hooks for input packets > */ > if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > m == NULL) > return 1; > > M_ASSERTVALID(m); > M_ASSERTPKTHDR(m); > > ip = mtod(m, struct ip *); /* if m changed during fw processing */ > dest = ip->ip_dst.s_addr; > #else > odest = dest = ip->ip_dst.s_addr; > #endif > > Thus avoiding writing to dest twice. > > > +#ifdef PFIL_HOOKS > > + /* > > + * Run through list of ipfilter hooks for input packets > > + */ > > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > > + m == NULL) > > + return 1; > > + > > + M_ASSERTVALID(m); > > + M_ASSERTPKTHDR(m); > > + > > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > > + dest = ip->ip_dst.s_addr; > > +#endif ... > > +passin: > > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > > + > > + /* > > + * Destination address changed? > > + */ > > + if (odest != dest) { > > + /* > > + * Is it now for a local address on this host? > > + */ > > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) > > + goto forwardlocal; > > + } > > #jesper > > Same comment as above - and do we really want to see if the original > destination address was ours if we're doing NAT ? Yes, we have to do that for ipfw fwd and ipfilter address rewrite (from ipnat). It may be that the packet has been hijacked in a transparent proxy situation and has to be delivered to a local socket. > > + /* > > + * Go on with new destination address > > + */ ... > > + /* > > + * Destination address changed? > > + */ > > + if (odest != dest) { > > + /* > > + * Is it now for a local address on this host? > > + */ > > #jesper > > Again, do we really want to look for packets destined for us after being > translated ? Same answer as above. > > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > > +forwardlocal: ... -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 15:23:47 2003 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 42D7516A4CE; Wed, 12 Nov 2003 15:23:47 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21F4143F85; Wed, 12 Nov 2003 15:23:44 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id BD2793850A; Thu, 13 Nov 2003 00:23:41 +0100 (CET) Date: Thu, 13 Nov 2003 00:23:41 +0100 From: Jesper Skriver To: Andre Oppermann Message-ID: <20031112232341.GJ41949@skriver.dk> Mail-Followup-To: Jesper Skriver , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org, sam@errno.com, mb@imp.ch, ume@freebsd.org References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB2BE8A.6C880085@pipeline.ch> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 23:23:47 -0000 On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote: > Jesper Skriver wrote: > > > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > > Hello all, > > > > > > this patch contains three things (to be separated for committing): > ... > > > ip_fastforward > > > > > > - removes ip_flow forwarding code > > > - adds full direct process-to-completion IPv4 forwarding code > > > - handles ip fragmentation incl. hw support (ip_flow did not) > > > - supports ipfw and ipfilter (ip_flow did not) > > > - supports divert and ipfw fwd (ip_flow did not) > > > - drops anything it can't handle back to normal ip_input > > > > I have a few comments to this code, see inline, look for #jesper > > Answers also inline. [All whitespace bugs are fixed and omitted here] One comment at the bottom. > > Apart from that it looks good. > > Thanks for reviewing! > > > /Jesper > > > > > +int > > > +ip_fastforward(struct mbuf *m) > > > +{ > ... > > > + > > > + /* > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > > + * no multicast, no INADDR_ANY > > > + */ > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > > > #jesper > > You will never see packets with a multicast source address. > > I hope so but we can never be sure. Here we look at what we've got > straight from the wire. Everything is possible there. I only need > to craft an apropriate packet... True, but do we really care if forwarded such a packet ? And if we want to check, we should just drop it directly instead of giving the packet to ip_input. /Jesper From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 15:43:35 2003 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 DCF9C16A4CE for ; Wed, 12 Nov 2003 15:43:35 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF6043F3F for ; Wed, 12 Nov 2003 15:43:33 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 34994 invoked from network); 12 Nov 2003 23:46:24 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 23:46:24 -0000 Message-ID: <3FB2C5A3.E6F33B07@pipeline.ch> Date: Thu, 13 Nov 2003 00:43:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jesper Skriver References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> <20031112232341.GJ41949@skriver.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 23:43:36 -0000 Jesper Skriver wrote: > > On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote: > > Jesper Skriver wrote: > > > > > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > > > Hello all, > > > > > > > > this patch contains three things (to be separated for committing): > > ... > > > > ip_fastforward > > > > > > > > - removes ip_flow forwarding code > > > > - adds full direct process-to-completion IPv4 forwarding code > > > > - handles ip fragmentation incl. hw support (ip_flow did not) > > > > - supports ipfw and ipfilter (ip_flow did not) > > > > - supports divert and ipfw fwd (ip_flow did not) > > > > - drops anything it can't handle back to normal ip_input > > > > > > I have a few comments to this code, see inline, look for #jesper > > > > Answers also inline. [All whitespace bugs are fixed and omitted here] > > One comment at the bottom. > > > > Apart from that it looks good. > > > > Thanks for reviewing! > > > > > /Jesper > > > > > > > +int > > > > +ip_fastforward(struct mbuf *m) > > > > +{ > > ... > > > > + > > > > + /* > > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > > > + * no multicast, no INADDR_ANY > > > > + */ > > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > > > > > #jesper > > > You will never see packets with a multicast source address. > > > > I hope so but we can never be sure. Here we look at what we've got > > straight from the wire. Everything is possible there. I only need > > to craft an apropriate packet... > > True, but do we really care if forwarded such a packet ? Yes, never forward anything that should not be. Stop the problem right here instead of letting it become a problem somewhere else. > And if we want to check, we should just drop it directly instead of > giving the packet to ip_input. Makes sense. Can we ever have a packet that has a source address with INADDR_BROADCAST or IN_MULTICAST? I can't think of such a case. Can we ever have a packet with destination address INADDR_ANY? Maybe for BOOTP? But then the source address would be 0.0.0.0 too? With fallback to ip_input() in all those cases I wanted to make sure that I don't break any obscure hack or protocol I didn't think of. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 16:17:56 2003 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 52AF716A4CE for ; Wed, 12 Nov 2003 16:17:56 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6243F43FBF for ; Wed, 12 Nov 2003 16:17:55 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAD0G4Mg096195 for ; Wed, 12 Nov 2003 19:16:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAD0G4No096192 for ; Wed, 12 Nov 2003 19:16:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 12 Nov 2003 19:16:04 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-current@freebsd.org In-Reply-To: <200311121738.13783.x@Vex.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Still getting NFS client locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 00:17:56 -0000 On Wed, 12 Nov 2003, Tim Middleton wrote: > On November 11, 2003 11:36 pm, Janet Sullivan wrote: > > So far I only have problems in a mixed -STABLE/-CURRENT environment. > > When the client & server are both -CURRENT I haven't had any problems. > > I just installed another -STABLE box to see if keeping them both -STABLE > helps. I haven't really tested the NFS yet as I didn't want to risk > locking the box up in the middle of a buildworld. If we can demonstrate the problem with both systems as -STABLE, that rules out a lot of things, and might also raise some questions about the hardware. > So i just mounted the NFS drive on the new test box and left it.... > Within an hour the NFS server box doing the build world was locked up > solid. I can't say if it was NFS mount related or not; nfsd wasn't > really doing anything. Doesn't seem like it would have been. Beginning > to wonder if it is some strange hardware problem on this box; which > coincidentally only shows up when there's an nfs mount! But that doesn't > explain why my normally rock solid desktop system tanked when being > tested as an NFS client to that STABLE box. Hmmm... One of the problems that can occur in -STABLE is a cascading failure when one file system is jammed up (i.e., an NFS mount from another system). Processes hang holding locks in NFS because the NFS session is stalled; other processes try to aquire the hold locks while holding additional locks, and before you know it a lot of very useful locks are held and can't be released due to an inability to free up locks at the cause. Many aspects of this problem are believed to be resolved in -CURRENT, but it's a touch cookies to crack without redoing VFS locking. If you have a spare system, it might be really interesting to install -STABLE on it, replicate data from your file server, point the client at that, and see if the problem still occurs there with the same load. You might also try swapping network cards: perhaps we're looking at a network device driver problem where loss of key packets, or packets over a certain size, is causing an unrecoverable failure. > Back to testing. I'm doing heavy disk I/O tests without any NFS mounts > now. If they go okay, back to the NFS mounting and testing... > > It seems to me there is something desperately wrong with NFS is mixing > -CURRENT and -STABLE NFS server/clients causes either side (in my case both > sides) to lock up solid. I mean, problems are problems... but solid lockups > with no crash messages or anything is ... nasty. Clearly there's a substantial problem, but it sounds like we're still having a lot of trouble identifying the circumstances that trigger the problem, and attempting to narrow things down. One of the problem with distributed system debugging is that it's often hard to track the problem down to a particular source when you catch it partway through a cascading failure. For example, it could well be that a server problem is triggering client symptoms, or it could be that a serious client problem might consume resources on the server such that other clients couldn't operate. Under these circumstances, it can be very difficult to track it down to a particular cause (a missing unlock on the server, for example). > > Are the folks seeing hangs getting any kind of console error messages? > > I see nothing. My server is completely locks up. Nothing responds. The > drive light (the times i've noticed) is frozen "on". On my desktop box > the mouse is dead as well. I can't help but wonder if the server isn't suffering an under-reported hardare failure. It might be interesting to see how quickly the problem vanishes when exchanging various elements. > > I don't see anything - performance just tanks to the point of being > > unusable. > > When testing with my desktop box as client, i noticed just before or > just when the NFS locked up the mouse and keyboard response would be > very erratic ... slow and jerky. This might suggest a high RPC load, deep queues in processing, or key locks held for extended periods of time. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 17:10:01 2003 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 B69E516A4CE for ; Wed, 12 Nov 2003 17:10:01 -0800 (PST) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05EE643FDD for ; Wed, 12 Nov 2003 17:10:00 -0800 (PST) (envelope-from Matthew.Thyer@dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id hAD19s66002155 for ; Thu, 13 Nov 2003 11:39:54 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au for ; Thu, 13 Nov 2003 11:39:49 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81])hAD10io27816 for ; Thu, 13 Nov 2003 11:30:44 +1030 (CST) Received: by ednex501.dsto.defence.gov.au with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 11:30:32 +1030 Message-ID: <5F13229E7BA2D611BD0300306E010DB08C9790@ednex503.dsto.defence.gov.au> From: "Thyer, Matthew" To: "'current@freebsd.org'" Date: Thu, 13 Nov 2003 11:30:51 +1030 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: undelete for FreeBSD 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: Thu, 13 Nov 2003 01:10:01 -0000 I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ after a rm -rf of /usr/local I've kept the file system relatively quiet since then. Is there a port that can achieve this? Otherwise pointers to web sites or mail archives regarding the use of fsdb to achieve this would be helpful. Please no replies about backups. Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax: +61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 EDINBURGH South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 17:26:53 2003 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 742D716A4CE for ; Wed, 12 Nov 2003 17:26:53 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7565143F93 for ; Wed, 12 Nov 2003 17:26:52 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id hAD1Qmp4046408; Wed, 12 Nov 2003 20:26:48 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id hAD1QmkY046407; Wed, 12 Nov 2003 20:26:48 -0500 (EST) (envelope-from barney) Date: Wed, 12 Nov 2003 20:26:48 -0500 From: Barney Wolff To: "Thyer, Matthew" Message-ID: <20031113012648.GA46137@pit.databus.com> References: <5F13229E7BA2D611BD0300306E010DB08C9790@ednex503.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5F13229E7BA2D611BD0300306E010DB08C9790@ednex503.dsto.defence.gov.au> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: "'current@freebsd.org'" Subject: Re: undelete for FreeBSD 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: Thu, 13 Nov 2003 01:26:53 -0000 On Thu, Nov 13, 2003 at 11:30:51AM +1030, Thyer, Matthew wrote: > I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ after a rm -rf of /usr/local > > I've kept the file system relatively quiet since then. TCT may help. http://www.porcupine.org/forensics/tct.html but I don't think it's been tested with current/ufs2. Also, don't expect to build it on the system and then find a deleted file. But if you have a clue of what you're looking for, just grepping /dev/da or /dev/ad might work. (grep -a -A100 -B100) -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 17:43:03 2003 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 9BC5616A4CE for ; Wed, 12 Nov 2003 17:43:03 -0800 (PST) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C5AF43F75 for ; Wed, 12 Nov 2003 17:43:03 -0800 (PST) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id 5DB7615227; Wed, 12 Nov 2003 17:43:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id 5CB5115226 for ; Wed, 12 Nov 2003 17:43:02 -0800 (PST) Date: Wed, 12 Nov 2003 17:43:02 -0800 (PST) From: Mike Hoskins To: current@freebsd.org In-Reply-To: <1068096637.688.276.camel@leguin> Message-ID: <20031112173910.A31339@fubar.adept.org> References: <20031105211716.U93921@fubar.adept.org> <1068096637.688.276.camel@leguin> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: drm, irqs, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 01:43:03 -0000 [ updating for completeness ] On Wed, 5 Nov 2003, Eric Anholt wrote: > On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: > > i've got XFree86 4.3.0 installed, from the "X-4" meta port. that went > > smoothly. using the mga driver with a matrox g450 (dual head). no dri on > > head 2 as expected, but again no obvious problems. > > what i've noticed (this is 5.1-p8) is that after X has been running for > > awhile, trying to exit X causes a hang. > 5.1 is -current, not -stable, so you should be mailing the -current > list. I've reset the cc: appropriately. i'm always confused about that, since i cvsup RELENG_5_1 not "." -- and don't usually view something that's been tagged as a RELEASE the same as CURRENT. ;) but thanks for moving this to the correct list. > If you're not using up to date -current, please upgrade to -current past > October 24th, which included some DRM IRQ fixes. If the problem > persists, could you check that it doesn't happen with the DRI disabled > in your XF86Config? same configuration, now running: FreeBSD mojo.sfo.televoke.net 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 #0: Mon Nov 10 16:33:20 PST 2003 mike@mojo.sfo.televoke.net:/usr/obj/usr/src/sys/MOJO i386 has not exhibited the behavior... if it reoccurs i will update the list, but it appears to happy for now. thanks, -mrh -- From: "Spam Catcher" To: spam-catcher@adept.org Do NOT send email to the address listed above or you will be added to a blacklist! From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 18:04:02 2003 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 239E716A4CE for ; Wed, 12 Nov 2003 18:04:02 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8254043FB1 for ; Wed, 12 Nov 2003 18:04:01 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B53F166B0C; Wed, 12 Nov 2003 18:04:00 -0800 (PST) Date: Wed, 12 Nov 2003 18:04:00 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20031113020400.GA44619@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Who needs these silly statfs changes... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 02:04:02 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0a 205434 123332 65668 65% / devfs 1 1 0 100% /dev /dev/da0e 7957764 7133368 187776 97% /usr rot13:/mnt2 56595176 54032286 18014398507517260 0% /rot13/mnt2 Kris "Now accepting payment for data hosting" Kennaway --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/suaQWry0BWjoQKURAshvAKCwDjKWNTIzvj63lZtpZv2EPIQXmgCgit/Z puy7WoyUP4+kNa+j6RHe16c= =Ha1G -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 18:42:41 2003 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 8B30E16A4CE for ; Wed, 12 Nov 2003 18:42:41 -0800 (PST) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF6EB43FBF for ; Wed, 12 Nov 2003 18:42:40 -0800 (PST) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id MUA74016; Wed, 12 Nov 2003 18:42:39 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 46B905D07; Wed, 12 Nov 2003 18:42:39 -0800 (PST) To: Mike Hoskins In-Reply-To: Message from Mike Hoskins <20031112173910.A31339@fubar.adept.org> Date: Wed, 12 Nov 2003 18:42:39 -0800 From: "Kevin Oberman" Message-Id: <20031113024239.46B905D07@ptavv.es.net> cc: current@freebsd.org Subject: Re: drm, irqs, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 02:42:41 -0000 > Date: Wed, 12 Nov 2003 17:43:02 -0800 (PST) > From: Mike Hoskins > Sender: owner-freebsd-current@freebsd.org > > [ updating for completeness ] > On Wed, 5 Nov 2003, Eric Anholt wrote: > > On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: > > > i've got XFree86 4.3.0 installed, from the "X-4" meta port. that went > > > smoothly. using the mga driver with a matrox g450 (dual head). no dri on > > > head 2 as expected, but again no obvious problems. > > > what i've noticed (this is 5.1-p8) is that after X has been running for > > > awhile, trying to exit X causes a hang. > > 5.1 is -current, not -stable, so you should be mailing the -current > > list. I've reset the cc: appropriately. > > i'm always confused about that, since i cvsup RELENG_5_1 not "." -- and > don't usually view something that's been tagged as a RELEASE the same as > CURRENT. ;) but thanks for moving this to the correct list. In reality, 5.0 and 5.1 are neither, but questions have to go somewhere and it was announced some time ago that until a V5 version was declared 'STABLE', that questions should go to CURRENT and not STABLE. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:30:21 2003 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 5A42016A4CE for ; Wed, 12 Nov 2003 19:30:21 -0800 (PST) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD46143FE0 for ; Wed, 12 Nov 2003 19:30:19 -0800 (PST) (envelope-from dgerow@afflictions.org) Received: from dementia.afflictions.org (dementia [172.16.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 3E6935E594 for ; Wed, 12 Nov 2003 22:43:35 -0500 (EST) Date: Wed, 12 Nov 2003 22:30:12 -0500 From: Damian Gerow To: current@freebsd.org Message-Id: <20031112223012.2aec54be.dgerow@afflictions.org> In-Reply-To: References: <3FAE68FB.64D262FF@pipeline.ch> Organization: Afflictions Hosting and Consulting Services X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 03:30:21 -0000 I've been thinking about this all day... Thus spake Jesper Skriver [23:53:26 11/12/03: : > + /* : > + * Only unicast IP, not from loopback, no L2 or IP broadcast, : > + * no multicast, no INADDR_ANY : > + */ : > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || : > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || : : #jesper : You will never see packets with a multicast source address. Do you mean: Any packets with a multicast source address will be dropped by the kernel before this point, or that no host will ever send a packet with a multicast source address? In the former, that's fine. In the latter, how does one guarantee that there isn't a malicious host out there sending spoofed multicast-source packets? - Damian From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:31:20 2003 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 1C46216A4CE for ; Wed, 12 Nov 2003 19:31:20 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B72E43F3F for ; Wed, 12 Nov 2003 19:31:19 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAD3TNMg097721; Wed, 12 Nov 2003 22:29:23 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAD3TNCP097718; Wed, 12 Nov 2003 22:29:23 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 12 Nov 2003 22:29:23 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Barney Wolff In-Reply-To: <20031113012648.GA46137@pit.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Thyer, Matthew" cc: "'current@freebsd.org'" Subject: Re: undelete for FreeBSD 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: Thu, 13 Nov 2003 03:31:20 -0000 On Wed, 12 Nov 2003, Barney Wolff wrote: > On Thu, Nov 13, 2003 at 11:30:51AM +1030, Thyer, Matthew wrote: > > I've done a bad thing and need to recover a single file in /usr/local/etc/rc.d/ after a rm -rf of /usr/local > > > > I've kept the file system relatively quiet since then. > > TCT may help. http://www.porcupine.org/forensics/tct.html but I don't > think it's been tested with current/ufs2. Also, don't expect to build > it on the system and then find a deleted file. > > But if you have a clue of what you're looking for, just grepping > /dev/da or /dev/ad might work. (grep -a -A100 -B100) Assuming that the file system had a fair amount of free space, and therefore wasn't fragmented, I've always found the "strings" command quite helpful in recovering text files after loss or deletion. It can also be nicely applied to /dev/mem if you accidentally close that pesky editor window without save... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 19:51:36 2003 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 D9BC416A4CE for ; Wed, 12 Nov 2003 19:51:35 -0800 (PST) Received: from hyperreal.net (marduk.tessellated.net [64.46.156.14]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B57F43F85 for ; Wed, 12 Nov 2003 19:51:34 -0800 (PST) (envelope-from jd@teq.org) Received: (qmail 85852 invoked by uid 1009); 13 Nov 2003 03:51:26 -0000 Date: Wed, 12 Nov 2003 22:51:26 -0500 (EST) From: John Dhmioyrgos X-X-Sender: John Dhmioyrgos To: freebsd-current@FreeBSD.org Message-ID: <0311122151440.-1077937228.pimpmail@mailhub> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-667128169-1068695315=:64941" Content-ID: <0311122249200.138569984.pimpmail@mailhub> Subject: new interrupt code breaks fbsd as VMWare guest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 03:51:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-667128169-1068695315=:64941 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <0311122249201.138579040.pimpmail@mailhub> 5.1-CURRENT-20031110-JPSNAP causes VMWare Workstation 4.0.5 on XP to throw a NOT_IMPLEMENTED message and die, while 20031025-JPSNAP works fine. The last few lines displayed during verbose boot are: ioapic0: routing intpin 1 (IRQ 1) to cluster 0 ioapic0: routing intpin 3 (IRQ 3) to cluster 0 ioapic0: routing intpin 4 (IRQ 4) to cluster 0 ioapic0: routing intpin 6 (IRQ 6) to cluster 0 ioapic0: routing intpin 7 (IRQ 7) to cluster 0 ioapic0: routing intpin 8 (IRQ 8) to cluster 0 setting kern.smp.disabled=1 at the loader prompt doesn't help. Verbose boot messages attached. regards, John --0-667128169-1068695315=:64941 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="tip.record" Content-Transfer-Encoding: BASE64 Content-ID: <0311122248350.0.pimpmail@mailhub> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="tip.record" U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAw MDAwMDA5ZjgwMA0KU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDAwMDA5Zjgw MCBsZW49MDAwMDAwMDAwMDAwMDgwMA0KU01BUCB0eXBlPTAyIGJhc2U9MDAw MDAwMDAwMDBkYzAwMCBsZW49MDAwMDAwMDAwMDAwNDAwMA0KU01BUCB0eXBl PTAyIGJhc2U9MDAwMDAwMDAwMDBlNDAwMCBsZW49MDAwMDAwMDAwMDAxYzAw MA0KU01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDEwMDAwMCBsZW49MDAw MDAwMDAwM2UwMDAwMA0KU01BUCB0eTNmMDAwMDAgbGVuPTAwMDAwMDAwMDAx MDAwMDANClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmVjMDAwMDAgbGVu PTAwMDAwMDAwMDAwMTAwMDANClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAw ZmVlMDAwMDAgbGVuPTAwMDAwMDAwMDAwMDEwMDANClNNQVAgdHlwZT0wMiBi YXNlPTAwMDAwMDAwZmZmZTAwMDAgbGVuPTAwMDAwMDAwMDAwMjAwMENvcHly aWdodCAoYykgMTk5Mi0yMDAzIFRoZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5 cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODks IDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCglUaGUgUmVnZW50cyBvZiB0aGUg VW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVk Lg0KRnJlZUJTRCA1LjEtQ1VSUkVOVC0yMDAzMTExMC1KUFNOQVAgIzA6IE1v biBOb3YgMTAgMDU6MjU6MDYgR01UIDIwMDMNCiAgICByb290QHVzaGkuanAu ZnJlZWJzZC5vcmc6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQw0KUHJl bG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4 YzBlYWQwMDAuDQpQcmVsb2FkZWQgbWZzX3Jvb3QgIi9ib290L21mc3Jvb3Qi IGF0IDB4YzBlYWQyNTQuDQpNUFRhYmxlOiA8SU5URUwgICAgNDQwQlggICAg ICAgPg0KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4uIGk4MjU0IGNsb2NrOiAx MjMzNzAxIEh6DQoxMjMzNzAxIEh6IGRpZmZlcnMgZnJvbSBkZWZhdWx0IG9m IDExOTMxODIgSHogYnkgbW9yZSB0aGFuIDElDQpUaW1lY291bnRlciAiaTgy NTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KQ2FsaWJyYXRp bmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDEwNzQwMzI2NjQgSHoNCkNQ VTogQU1EIER1cm9uKHRtKSBQcm9jZXNzb3IgKDEwNzQuMDMtTUh6IDY4Ni1j bGFzcyBDUFUpDQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4 NjcxICBTdGVwcGluZyA9IDENCiAgRmVhdHVyZXM9MHgzODNmYmZmPEZQVSxW TUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQ R0V4YzA0ODAwMDA8TVAsQU1JRSxEU1AsM0ROb3chPg0KRGF0YSBUTEI6IDMy IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlDQpJbnN0cnVjdGlvbiBUTEI6 IDE2IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlDQpMMSBkYXRhIGNhY2hl OiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMvdGFnLCAyLXdh eSBhc3NvY2lhdGl2ZQ0KTDEgaW5zdHJ1Y3Rpb24gY2FjaGU6IDY0IGtieXRl cywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0 aXZlDQpMMiBpbnRlcm5hbCBjYWNoZTogNjQga2J5dGVzLCA2NCBieXRlcy9s aW5lLCAxIGxpbmVzL3RhZywgOC13YXkgYXNzb2NpYXRpdmUNCnJlYWwgbWVt b3J5ICA9IDY3MTA4ODY0ICg2NCBNQikNClBoeXNpY2FsIG1lbW9yeSBjaHVu ayhzKToNCjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZWZm ZiwgNjQ3MTY4IGJ5dGVzICgxNTggcGFnZXMpDQoweDAwMDAwMDAwMDAxMDAw MDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3MjggYnl0ZXMgKDc2OCBw YWdlcykNCjB4MDAwMDAwMDAwMTAyOTAwMCAtIDB4MDAwMDAwMDAwM2ViOWZm ZiwgNDg4Mjg0MTYgYnl0ZXMgKDExOTIxIHBhZ2VzKQ0KYXZhaWwgbWVtb3J5 ID0gNTE0NTM5NTIgKDQ5IE1CKQ0KYmlvczMyOiBGb3VuZCBCSU9TMzIgU2Vy dmljZSBEaXJlY3RvcnkgaGVhZGVyIGF0IDB4YzAwZjcwNDANCmJpb3MzMjog RW50cnkgPSAweGZkODgwIChjMDBmZDg4MCkgIFJldiA9IDAgIExlbiA9IDEN CnBjaWJpb3M6IFBDSSBCSU9TIGVudHJ5IGF0IDB4ZmQ4ODArMHgxMjANCnBu cGJpb3M6IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmNzBhMA0KcG5w YmlvczogRW50cnkgPSBmMDAwMDo5ODVkICBSZXYgPSAxLjANCk90aGVyIEJJ T1Mgc2lnbmF0dXJlcyBmb3VuZDoNCmlvYXBpYzA6IEFzc3VtaW5nIGludGJh c2Ugb2YgMA0KaW9hcGljMDogaW50cGluIDAgLT4gRXh0SU5UIChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAxIC0+IGlycSAxIChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAyIC0+IGlycSAyIChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAzIC0+IGlycSAzIChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA0IC0+IGlycSA0IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA1IC0+IGlycSA1IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA2IC0+IGlycSA2IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA3IC0+IGlycSA3IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA4IC0+IGlycSA4IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiA5IC0+IGlycSA5IChlZGdlLCBh Y3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAxMCAtPiBpcnEgMTAgKGVkZ2Us IGFjdGl2ZWhpKQ0KaW9hcGljMDogaW50cGluIDExIC0+IGlycSAxMSAoZWRn ZSwgYWN0aXZlaGkpDQppb2FwaWMwOiBpbnRwaW4gMTIgLT4gaXJxIDEyIChl ZGdlLCBhY3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAxMyAtPiBpcnEgMTMg KGVkZ2UsIGFjdGl2ZWhpKQ0KaW9hcGljMDogaW50cGluIDE0IC0+IGlycSAx NCAoZWRnZSwgYWN0aXZlaGkpDQppb2FwaWMwOiBpbnRwaW4gMTUgLT4gaXJx IDE1IChlZGdlLCBhY3RpdmVoaSkNCmlvYXBpYzA6IGludHBpbiAxNiAtPiBp cnEgMTYgKGxldmVsLCBhY3RpdmVsbykNCmlvYXBpYzA6IGludHBpbiAxNyAt PiBpcnEgMTcgKGxldmVsLCBhY3RpdmVsbykNCmlvYXBpYzA6IGludHBpbiAx OCAtPiBpcnEgMTggKGxldmVsLCBhY3RpdmVsbykNCmlvYXBpYzA6IGludHBp biAxOSAtPiBpcnEgMTkgKGxldmVsLCBhY3RpdmVsbykNCmlvYXBpYzA6IGlu dHBpbiAyMCAtPiBpcnEgMjAgKGxldmVsLCBhY3RpdmVsbykNCmlvYXBpYzA6 IGludHBpbiAyMSAtPiBpcnEgMjEgKGxldmVsLCBhY3RpdmVsbykNCmlvYXBp YzA6IGludHBpbiAyMiAtPiBpcnEgMjIgKGxldmVsLCBvKQ0KaW9hcGljMDog aW50cGluIDIzIC0+IGlycSAyMyAobGV2ZWwsIGFjdGl2ZWxvKQ0KaW9hcGlj MDogaW50cGluIDEgdHJpZ2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDEg cG9sYXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGljMDogUm91dGluZyBJUlEgMCAt PiBpbnRwaW4gMg0KaW9hcGljMDogaW50cGluIDIgdHJpZ2dlcjogZWRnZQ0K aW9hcGljMDogaW50cGluIDIgcG9sYXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGlj MDogaW50cGluIDMgdHJpZ2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDMg cG9sYXJpdHk6IGFjdGluIDQgdHJpZ2dlcjogZWRnZQ0KaW9hcGljMDogaW50 cGluIDQgcG9sYXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGljMDogaW50cGluIDUg dHJpZ2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDUgcG9sYXJpdHk6IGFj dGl2ZS1oaQ0KaW9hcGljMDogaW50cGluIDYgdHJpZ2dlcjogZWRnZQ0KaW9h cGljMDogaW50cGluIDYgcG9sYXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGljMDog aW50cGluIDcgdHJpZ2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDcgcG9s YXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGljMDogaW50cGluIDggdHJpZ2dlcjog ZWRnZQ0KaW9hcGljMDogaW50cGluIDggcG9sYXJpdHk6IGFjdGl2ZS1oaQ0K aW9hcGljMDogaW50cGluIDE3IHRyaWdnZXI6IGxldmVsDQppb2FwaWMwOiBp bnRwaW4gMTcgcG9sYXJpdHk6IGFjdGl2ZS1sbw0KaW9pbnRwaW4gMTAgdHJp Z2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDEwIHBvbGFyaXR5OiBhY3Rp dmUtaGkNCmlvYXBpYzA6IGludHBpbiAxMSB0cmlnZ2VyOiBlZGdlDQppb2Fw aWMwOiBpbnRwaW4gMTEgcG9sYXJpdHk6IG50cGluIDEyIHBvbGFyaXR5OiBh Y3RpdmUtaGkNCmlvYXBpYzA6IGludHBpbiAxMyB0cmlnZ2VyOiBlZGdlDQpp b2FwaWMwOiBpbnRwaW4gMTMgcG9sYXJpdHk6IGFjdGl2ZS1oaQ0KaW9hcGlj MDogaW50cGluIDE0IHRyaWdnZXI6IGVkZ2UNCmlvYXBpYzA6IGludHBpbiAx NCBwb2xhcml0eTogYWN0aXZlLWhpDQppb2FwaWMwOiBpbnRwaW4gMTUgdHJp Z2dlcjogZWRnZQ0KaW9hcGljMDogaW50cGluIDE1IHBvbGFyaXR5OiBhY3Rp dmUtaGkNCmxhcGlJTlQxIHRyaWdnZXI6IGVkZ2UNCmxhcGljOiBMSU5UMSBw b2xhcml0eTogYWN0aXZlLWhpDQppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJx cyAwLTIzIG9uIG1vdGhlcmJvYXJkDQpjcHUwIEJTUDoNCiAgICAgSUQ6IDB4 MDAwMDAwMDAgICBWRVI6IDB4MDAwNDAwMTEgTERSOiAweDAxMDAwMDAwIERG UjogMHgwZmZmZmZmZg0KICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgw MDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmDQp3bGFu OiA8ODAyLjExIExpbmsgTGF5ZXI+DQpudWxsOiA8bnVsbCBkZXZpY2UsIHpl cm8gZGV2aWNlPg0KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2U+DQptZW06IDxt ZW1vcnkgJiBJL08+DQpDUFUgc3VwcG9ydHMgTVRSUnMgYnV0IG5vdCBlbmFi bGVkDQptZDA6IFByZWxvYWRlZCBpbWFnZSA8L2Jvb3QvbWZzcm9vdD4gNDQy MzY4MCBieXRlcyBhdCAweGMwYTczODUwDQogICAgQUNQSS0wMTU5OiAqKiog RXJyb3I6IEFjcGlMb2FkVGFibGVzOiBDb3VsZCBub3QgZ2V0IFJTRFAsIEFF X05PX0FDUElfVEFCTEVTDQogICAgQUNQSS0wMjEzOiAqKiogRXJyb3I6IEFj cGlMb2FkVGFibGVzOiBDb3VsZGxlIGxvYWQgZmFpbGVkOiBBRV9OT19BQ1BJ X1RBQkxFUw0KbnB4MDogW0ZBU1RdDQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+ IG9uIG1vdGhlcmJvYXJkDQpucHgwOiBJTlQgMTYgaW50ZXJmYWNlDQpwY2lf b3BlbigxKToJbW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDAz OTA0DQpwY2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAw MDAwMDApDQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAwMDBd IFtoZHI9MDBdIGlzIHRoZXJlIChpZD03MTkwODA4NikNCnBjaWJpb3M6IEJJ T1MgdmVyc2lvbiAyLjEwDQpVc2luZyAkUElSIHRhYmxlLCA5IGVudHJpZXMg YXQgMHhjMDBmZGYzMA0KUENJLU9ubHkgSW50ZXJydXB0czogbm9uZQ0KTG9j YXRpb24gIEJ1cyBEZXZpY2UgUGluICBMaW5rICBJUlFzDQpzbG90IDEgICAg ICAwICAgMTUgICAgQSAgIDB4NjAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1DQpzbG90IDEgICAgICAwICAgMTUgICAgQiAgIDB4NjEgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDEgICAgICAwICAgMTUgICAgQyAg IDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDEgICAg ICAwICAgMTUgICAgRCAgIDB4NjMgIDMgNCA1ICAgIDE2ICAgIEEgICAweDYx ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0Kc2xvdCAyICAgICAgMCAg IDE2ICAgIEIgICAweDYyICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0K c2xvdCAyICAgICAgMCAgIDE2ICAgIEMgICAweDYzICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQ0Kc2xvdCAyICAgICAgMCAgIDE2ICAgIEQgICAweDYw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0Kc2xvdCAzICAgICAgMCAg IDE3ICAgIEEgICAweDYyICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0K c2xvdCAzICAgICAgQiAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1DQpzbG90IDMgICAgICAwICAgMTcgICAgQyAgIDB4NjAgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDMgICAgICAwICAgMTcgICAgRCAg IDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDQgICAg ICAwICAgMTggICAgQSAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1DQpzbG90IDQgICAgICAwICAgMTggICAgQiAgIDB4NjAgIDMgNCA1IDYg NyA5IDEwIDExbG90IDQgICAgICAwICAgMTggICAgQyAgIDB4NjEgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDQgICAgICAwICAgMTggICAg RCAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDUg ICAgICAwICAgMTkgICAgQSAgIDB4NjAgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1DQpzbG90IDUgICAgICAwICAgMTkgICAgQiAgIDB4NjEgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDUgICAgICAwICAgMTkgICAg QyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDUg ICAgICAwICAgMTkgICAgRCAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1DQpzbG90IDYgICAgICAwICAgMjAgICAgQSAgIDB4NjEgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDYgICAgICAwICAgMjAgICAg QiAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpzbG90IDYg ICAgICAwICAgMjAgICAgQyAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1DQpzbG90IDYgICAgICAwICAgMjAgICAgRCAgIDB4NjAgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1DQplbWJlZGRlZWRkZWQgICAgMCAgICAw ICAgIEIgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KZW1i ZWRkZWQgICAgMCAgICAwICAgIEMgICAweDYyICAzIDQgNSA2IDcgOSAxMCAx MSAxMiAxNCAxNQ0KZW1iZWRkZWQgICAgMCAgICAwICAgIEQgICAweDYzICAz IDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KZW1iZWRkZWQgICAgMCAgICA3 ICANCgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGY4MDAwMDAw LCBzaXplIDI2LCBlbmFibGVkDQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDcxOTAsIHJldmlkPTB4MDENCglidXM9MCwgc2xvdD0wLCBmdW5jPTAN CgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21k cmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChkd29y ZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDcxOTEsIHJldmlkPTB4MDENCglidXM9MCwgc2xvdD0xLCBmdW5j PTANCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wDQoJ Y21kcmVnPTB4MDExZiwgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0wIChk d29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDgwICgz MjAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHg3MTEwLCByZXZpZD0weDA4DQoJYnVzPTAsIHNsb3Q9 NywgZnVuYz0wDQoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQ0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCW1hcFsyMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDEwNTAsIHNpemUgIDQsIGVuYWJs ZWQNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzExMSwgcmV2aWQ9 MHgwMQ0KCWJ1cz0wLCBzbG90PTcsIGZ1bmM9MQ0KCWNsYXNzPTAxLTAxLThh LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1LCBzdGF0 cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0w eDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykNCgltYXBbOTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDAxMDQwLCBzaXplICA0LCBlbmFibGVkDQpmb3VuZC1ldmlkPTB4MDgNCgli dXM9MCwgc2xvdD03LCBmdW5jPTMNCgljbGFzcz0wNi04MC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAy ODAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJ bWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTA4MCwgc2l6 ZSAgNCwgZW5hYmxlZA0KCW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJh c2UgZmQwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQNCgltYXBbMThdOiB0eDE1 YWQsIGRldj0weDA0MDUsIHJldmlkPTB4MDANCglidXM9MCwgc2xvdD0xNSwg ZnVuYz0wDQoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MA0KCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 OCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCW1hcFsxMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDEwNjAsIHNpemUgIDUsIGVuYWJs ZWQNCnBjaWIwOiBzbG90IDE2IElOVEEgcm91dGVkIHRvIGlycSAxNw0KZm91 bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgyMDAwLCByZXZpZD0weDEwDQoJ YnVzPTAsIHNsb3Q9MTB4MDAwMSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdu dD0weDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4ZmYgKDYzNzUwIG5zKQ0KCWlu dHBpbj1hNw0KYWdwMDogPEludGVsIDgyNDQzQlggKDQ0MCBCWCkgaG9zdCB0 byBQQ0kgYnJpZGdlPiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmIGF0IGRl dmljZSAwLjAgb24gcGNpMA0KYWdwMDogYWxsb2NhdGluZyBHQVRUIGZvciBh cGVydHVyZSBvZiBzaXplIDY0TQ0KcGNpYjE6IDxQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDEuMCBvbiBwY2kwDQpwY2liMTogICBzZWNvbmRhcnkgYnVz ICAgICAxDQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxDQpwY2liMTog ICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYNCnBjaWIxOiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4ZmZmMDAwMDAtMHhmZmZmZg0KcGNpYjE6ICAg cHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmDQpwY2kxOiA8 UENJIGJ1cz4gb24gcGNpYjENCnBjaTE6IHBoeXNpY2FsIGJ1cz0xDQppc2Fi MDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTANCmlz YTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDogPEludGVsIFBJSVg0 IFVETUEzMyBjb250cm9sbGVyPiBwb3J0IDB4MTA1MC0weDEwNWYgYXQgZGV2 aWNlIDcuMSBvbiBwY2kwDQphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQxPTAwDQphdGEwLW1hc3Rlcjogc3RhdD0weDUwIGVycj0w eDAxIGxzYj0weDAwIG1zYj0weDAwDQphdGEwLXNsYXZlOiAgc3RhdD0weDAw IGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwDQphdGEwOiByZXNldCB0cDIg bWFzaz0wMyBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFT VEVSPg0KYXRhMDogYXQgMHgxZjAgaXJxIDE0IG9uIGF0YXBjaTBhdGEwOiBb TVBTQUZFXQ0KYXRhMTogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9z dGF0MT1mZg0KYXRhMS1tYXN0ZXI6IHN0YXQ9MHgwMCBlcnI9MHgwMSBsc2I9 MHgxNCBtc2I9MHhlYg0KYXRhMTogcmVzZXQgdHAyIG1hc2s9MDEgc3RhdDA9 MDAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPg0KYXRhMTog YXQgMHgxNzAgaXJxIDE1IG9uIGF0YXBjaTANCmF0YTE6IFtNUFNBRkVdDQpw aWl4MDogPFBJSVggVGltZWNvdW50ZXI+IHBvcnQgMHgxMDQwLTB4MTA0ZiBh dCBkZXZpY2UgNy4zIG9uIHBjaTANClRpbWVjb3VudGVyICJQSUlYIiBmcmVx dWVuY3kgMzU3OTU0NSBIenBjaTA6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmlj ZSAxNS4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQpsbmMwOiA8UENOZXQvUENJ IEV0aGVybmV0IGFkYXB0ZXI+IHBvcnQgMHgxMDYwLTB4MTA3ZiBpcnEgMTcg YXQgZGV2aWNlIDE2LjAgb24gcGNpMA0KbG5jMDogQXR0YWNoaW5nIFBDTmV0 L1BDSSBFdGhlcm5ldCBhZGFwdGVyDQpsbmMwOiBicGYgYXR0YWNoZWQNCmxu YzA6IFBDbmV0LVBDSSBhZGRyZXNzIDAwOjBjOjI5OmNlOjc3OjJjDQphdGE6 IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphdGE6IGF0YTEg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQpsbmM6IGxuYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0DQpUcnlpbmcgUmVhZF9Qb3J0IGF0IDIw Mw0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMNClRyeWluZyBSZWFkX1BvcnQg YXQgMjgzDQpUcnlpbmcgUmVhZF9Qb3J0IGF0IDJjMw0KVHJ5aW5nIFJlYWRf UG9ydCBhdCAzMDMNClRyeWluZyBSZWFkX1BvcnQgYXQgMzQzDQpUcnlpbmcg UmVhZF9Qb3J0IGF0IDM4Mw0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMNCnBu cGJpb3M6IDIwIGRldmljZXMsIGxhcmdlc3QgMTcwIGJ5dGVzDQpQTlAwYzAy OiBhZGRpbmcgaW8gcmFuZ2UgMHg4MC0weDgwLCBzaXplPTB4MSwgYWxpZ249 MHgxDQpQTlAwYzAyOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHhm ZmZlMDAwMC0weGZmZmZmZmZmLCBzaXplPTB4MjAwMDANCnBucGJpb3M6IGhh bmRsZSAwIGRldmljZSBJRCBQTlAwYzAyICgwMjBjZDA0MSkNClBOUDBjMDE6 IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAwLTB4OWZmZmYsIHNpemU9 MHhhMDAwMA0KUE5QMGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdl IDB4ZTgwMDAtMHhmZmZmZiwgc2l6ZT0weDE4MDAwDQpQTlAwYzAxOiBhZGRp bmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHgxMDAwMDAtMHgzZGZmZmZmLCBz aXplPTB4M2QwMDAwMA0KcG5wYmlvczogaGFuZGxlIDEgZGV2aWNlIElEIFBO UDBjMDEgKDAxMGNkMDQxKQ0KUE5QMDIwMDogYWRkaW5nIGlvIHIweGMwLTB4 ZGYsIHNpemU9MHgyMCwgYWxpZ249MHgxDQpQTlAwMjAwOiBhZGRpbmcgZG1h IG1hc2sgMHgxMA0KcG5wYmlvczogaGFuZGxlIDIgZGV2aWNlIElEIFBOUDAy MDAgKDAwMDJkMDQxKQ0KUE5QMDEwMDogYWRkaW5nIGlvIHJhbmdlIDB4NDAt MHg0Mywgc2l6ZT0weDQsIGFsaWduPTB4MQ0KUE5QMDEwMDogYWRkaW5nIGly cSBtYXNrIDB4MQ0KcG5wYmlvczogaGFuZGxlIDQgZGV2aWNlIElEIFBOUDAx MDAgKDAwMDFkMDQxKQ0KUE5QMGIwMDogYWRkaW5nIGlvIHJhbmdlIDB4NzAt MHg3MSwgc2l6ZT0weDIsIGFsaWduPTB4MQ0KUE5QMGIwMDogYWRkaW5nIGly cSBtYXNrIDB4MTAwDQpwbnBiaW9zOiBoYW5kbGUgNSBkZXZpY2UgSUQgUE5Q MGIwMCAoMDAwYmQwNDEpDQpQTlAwMzAzOiBhZGRpbmcgaW8gcmFuZ2UgMHg2 MC0weDYwLCBzaXplPTB4MSwgYWxpZ249MHgxDQpQTlAwMzAzOiBhZGRpbmcg aW8gcmFuZ2UgMHg2NC0weDY0LCBzaXplPTB4MSwgYWxpZ249MHgxDQpQTlAw MzAzOiBhZGRpbmcgaXJxIG1hc2sgMHgyDQpwbnBiaW9zOiBoYW5kbGUgNiBk ZXZpY2UgSUQgUE5QMDMwMyAoMDMwM2QwNDEpDQpQTlAwYzA0OiBhZGRpbmcg aW8gcmFuZ2UgMHhmMC0weGZmLCBzaXplPTB4MTAsIGFsaWduPTB4MQ0KUE5Q MGMwNDogYWRkaW5nIGlycSBtYXNrIDB4MjAwMA0KcG5wYmlvczogaGFuZGxl IDcgZGV2aWNlIElEIFBOUDBjMDQgKDA0MGNkMDQxKQ0KUE5QMDgwMDogYWRk aW5nIGlvIHJhbmdlIDB4NjEtMHg2MSwgc2l6ZT0weDEsIGFsaWduPTB4MQ0K cG5wYmlvczogaGFuZGxlIDggZGV2aWNlIElEIFBOUGcgbWVtb3J5MzIgcmFu Z2UgMHhkYzAwMC0weGRmZmZmLCBzaXplPTB4NDAwMCwgYWxpZ249MHg0MDAw DQpwbnBiaW9zOiBoYW5kbGUgOSBkZXZpY2UgSUQgUE5QMGMwMiAoMDIwY2Qw NDEpDQpQTlAwYTAzOiBhZGRpbmcgaW8gcmFuZ2UgMHhjZjgtMHhjZmYsIHNp emU9MHg4LCBhbGlnbj0weDENCnBucGJpb3M6IGhhbmRsZSAxMCBkZXZpY2Ug SUQgUE5QMGEwMyAoMDMwYWQwNDEpDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFu Z2UgMHg0ZDAtMHg0ZDEsIHNpemU9MHgyLCBhbGlnbj0weDENClBOUDBjMCBz aXplPTB4NDAsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdl IDB4MTA0MC0weDEwNGYsIHNpemU9MHgxMCwgYWxpZ249MHgxDQpQTlAwYzAy OiBhZGRpbmcgaW8gcmFuZ2UgMHgxMC0weDE4LCBzaXplPTB4YW5nZSAweDFm LTB4MWYsIHNpemU9MHgxLCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBp byByYW5nZSAweDI0LTB4MjUsIHNpemU9MHgyLCBhbGlnbj0weDENClBOUDBj MDI6IGFkZGluZyBpbyByYW5nZSAweDI4LTB4MjksIHNpemU9MHgyLCBhbGln bj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweDJjLTB4MmQsIHNp emU9MHgyLCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAw eDMwLTB4MzEsIHNpemU9MHgyLCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGlu ZyBpbyByYW5nZSAweDM0LTB4MzUsIHNpemU9MHgyLCBhbGlnbj0weDENClBO UDBjMDI6IGFkZGluZyBpbyByYW5nZSAweDM4LTB4MzksIHNpemU9MHgyLCBh bGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweDNjLTB4M2Qs IHNpemU9MHgyLCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5n ZSAweDUwLTB4NTIsIHNpemU9MHgzLCBhbGlnbj0weDENClBOUDBjMDI6IGFk ZGluZyBpbyByYW5nZSAweDcyLTB4NzcsIHNpemU9MHg2LCBhbGlnbj0weDEN ClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweDkwLTB4OWYsIHNpemU9MHgx MCwgYWxpZ249MHgxDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHhhNC0w eGE1LCBzaXplPTB4MiwgYWxpZ249MHgxDQpQTlAwYzAyOiBhZGRpbmcgaW8g cmFuZ2UgMHhhOC0weGE5LCBzaXplPTB4MiwgYWxpZ249MHgxDQpQTlAwYzAy OiBhZGRpbmcgaW8gcmFuZ2UgMHhhYy0weGFkLCBzaXplPTB4MiwgYWxpZ249 MHgxDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHhiMC0weGJkLCBzaXpl PTB4ZSwgYWxpZ249MHgxDQpwbnBiaW9zOiBoYW5kbGUgMTEgZGV2aWNlIElE IFBOUDBjMDIgKDAyMGNkMDQxKQ0KUE5QMGMwMjogYWRkaW5nIGZpeGVkIG1l bW9yeTMyIHJhbmdlIDB4ZmVjMDAwMDAtMHhmZWMwZmZmZiwgc2l6ZT0weDEw MDAwDQpQTlAwYzAyOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHhm ZWUwMDAwMC0weGZlZTAwZmZmLCBzaXplPTB4MTAwMA0KcG5wYmlvczogaGFu ZGxlIDEyIGRldmljZSBJRCBQTlAwYzAyICgwMjBjZDA0MSkNClBOUDBjMDI6 IGFkZGluZyBtZW1vcnkzMiByYW5nZSAweGU0MDAwLTB4ZTdmZmYsIHNpemU9 MHg0MDAwLCBhbGlnbj0weDQwMDANCnBucGJpb3M6IGhhbmRsZSAxMyBkZXZp Y2UgSUQgUE5QMGMwMiAoMDIwY2QwNDEpDQpwbnBiaW9zOiBoYW5kbGUgMTUg ZGV2aSBoYW5kbGUgMTYgZGV2aWNlIElEIFBOUDBmMTMgKDEzMGZkMDQxKQ0K UE5QMDUwMTogYWRkaW5nIGlvIHJhbmdlIDB4M2Y4LTB4M2ZmLCBzaXplPTB4 OCwgYWxpZ249MHgxDQpQTlAwNTAxOiBhZGRpbmcgaXJxIG1hc2sgMHgxMA0K cG5wYmlvczogaGFuZGxlIDE3IGRldmljZSBJRCBQTlAwNTAxICgwMTA1ZDA0 MSkNClBOUDA1MDE6IGFkZGluZyBpbyByYW5nZSAweDJmOC0weDJmZiwgc2l6 ZT0weDgsIGFsaWduPTB4MQ0KUE5QMDUwMTogYWRkaW5nIGlycSBtYXNrIDB4 OA0KcG5wYmlvczogaGFuZGxlIDE4IGRldmljZSBJRCBQTlAwNTAxICgwMTA1 ZDA0MSkNClBOUDA0MDA6IGFkZGluZyBpbyByYW5nZSAweDM3OC0weDM3Ziwg c2l6ZT0weDgsIGFsaWduPTB4OA0KUE5QMDQwMDogYWRkaW5nIGlycSBtYXNr IDB4ODANCnBucGJpb3M6IGhhbmRsZSAyMyBkZXZpY2UgSUQgUE5QMDQwMCAo MDAwNGQwNDEpDQpQTlAwNzAwOiBhZGRpbmcgaW8gcmFuZ2UgMHgzZjAtMHgz ZjUsIHNpemU9MHg9MHg4DQpQTlAwNzAwOiBhZGRpbmcgaW8gcmFuZ2UgMHgz ZjctMHgzZjcsIHNpemU9MHgxLCBhbGlnbj0weDENClBOUDA3MDA6IGFkZGlu ZyBpcnEgbWFzayAweDQwDQpQTlAwNzAwOiBhZGRpbmcgZG1hIG1hc2sgMHg0 DQpwbnBiaW9zOiBoYW5kbGUgMjQgZGV2aWNlIElEIFBOUDA3MDAgKDAwMDdk MDQxKQ0KZXhfaXNhX2lkZW50aWZ5KCkNCnNjOiBzYzAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0DQp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0DQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAg ZGV2aWNlcw0KaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAg ZGV2aWNlcw0Kb3JtMDogPE9wdGlvbiBST01zPiBhdCBpb21lbSAweGU0MDAw LTB4ZTdmZmYsMHhkYzAwMC0weGRmZmZmLDB4YzAwMDAtMHhjN2ZmZiBvbiBp c2EwDQpwbXRpbWVyMCBvbiBpc2EwDQphZHYwOiBub3QgcHJvYmVkIChkaXNh YmxlZCkNCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KYWljMDogbm90 IHByb2JlZCAoZGlzYWJsZWQpDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJv bGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjQsMHg2MCBvbiBpc2EwDQphdGti ZDA6IDxBVCBLZXlib2FyZD4gZmxhZ3MgMHgxIGlycSAxIG9uIGF0a2JkYzAN CmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5 dGUgMDA0Nw0KYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikNCmtiZGM6 IFJFU0VUX0tCRCByZXR1cm4gY29kZTowMGZhDQprYmRjOiBSRVNFVF9LQkQg c3RhdHVzOjAwYWENCmtiZDAgYXQgYXRrYmQwDQprYmQwOiBhdGtiZDAsIEFU IDEwMS8xMDIgKDIpLCBjb25maWc6MHgxLCBmbGFnczoweDNkMDAwMA0KcHNt MDogY3VycmVudCBjb21tYW5kIGJ5dGU6MDA0Nw0Ka2JkYzogVEVTVF9BVVhf UE9SVCBzdGF0dXM6MDAwMA0Ka2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2Rl OjAwZmENCmtiZGM6IFJFU0VUX0FVWCBzdGF0dXM6MDBhYQ0Ka2JkYzogUkVT RVRfQVVYIElEOjAwMDANCmtiZGM6IFJFU0VUX0FVWCByZXR1cm4gY29kZTow MGZhDQprYmRjOiBSRVNFVF9BVVggc3RhdHVzOjAwYWENCmtiZGM6IFJFU0VU X0FVWCBJRDowMDAwDQpwc206IHN0YXR1cyAwMCAwMiA2NA0KcHNtOiBzdGF0 dXMgMTAgMDAgNjQNCnBzbTogc3RhdHVzIDEwIDAzIDY0DQpwc206IHN0YXR1 cyAxMCAwMyA2NA0KcHNtOiBkYXRhIGZmZmZmZmZmIDEwIDAzDQpwc206IGRh dGEgZmZmZmZmZmYgMDIgNjQNCnBzbTA6IGZhaWxlZCB0byBnZXQgZGF0YS4N CnBzbTogc3RhdHVzIDEwIDAyIDY0DQpwc20wOiA8UFMvMiBNb3VzZT4gaXJx IDEyIG9uIGF0a2JkYzANCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2 aWNlIElEIDMtMDAsIDMgYnV0dG9ucw0KcHNtMDogY29uZmlnOjAwMDAwMDAw LCBmbGFnczowMDAwMDAwMCwgcGFja2V0IHNpemU6NA0KcHNtaXRzOjAwDQpi dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KY3MwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkNCmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpmZGMwOiA8 RW5oYW5jZWQgZmxvcHB5IGNvbnRyb2xsZXIgKGk4MjA3NywgTkU3MjA2NSBv ciBjbG9uZSk+IGF0IHBvcnQgMHgzZjcsMHgzZjAtMHgzZjUgaXJxIDYgZHJx IDIgb24gaXNhMA0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVz aG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl IDANCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQppZTA6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQ0KbGUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCnBj aWMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2UwIGlvbWVtIDB4ZDAw MDAgb24gaXNhMA0KcGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KcHBj MDogcGFyYWxsZWwgcG9ydCBmb3VuZCBhdCAweDM3OA0KcHBjMDogdXNpbmcg ZXh0ZW5kZWQgSS9PIHBvcnQgcmFuZ2UNCnBwYzA6IFNQUA0KcHBjMDogPFBh cmFsbGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNh MA0KcHBjMDogR2VuZXJpYyBjaGlwc2V0IChOSUJCTEUtb25seSkgaW4gQ09N UEFUSUJMRSBtb2RlDQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0cGxpcDA6IDxQ TElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czANCnBsaXAwOiBicGYg YXR0YWNoZWQNCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IElu dGVycnVwdC1kcml2ZW4gcG9ydA0KcHBpMDogPFBhcmFsbGVsIEkvTz4gb24g cHBidXMwDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAg b24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MzAwPg0Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBz YyAoc3lzY29ucyB0ZXJtaW5hbCkNCnNpbzA6IGlycSBtYXBzOiAweDQxIDB4 NTEgMHg0MSAweDQxDQpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBpc2EwDQpzaW8wOiB0eXBlIDE2NTUwQSwgY29uc29s ZQ0Kc2lvMTogaXJxIG1hcHM6IDB4NDEgMHg0OSAweDQxIDB4NDENCnNpbzEg YXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwDQpzaW8xOiB0eXBl IDE2NTUwQQ0Kc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpzaW8zOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkNCnNuMDogbm90IHByb2JlZCAoZGlzYWJs ZWQpDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4 M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpmYjA6IHZnYTAs IHZnYSwgdHlwZTpWR0EgKDUpLCBmbGFnczoweDcwMDdmDQpmYjA6IHBvcnQ6 MHgzYzAtMHgzZGYsIGNydGM6MHgzZDQsIG1lbToweGEwMDAwIDB4MjAwMDAN CmZiMDogaW5pdCBtb2RlOjI0LCBiaW9zIG1vZGU6MywgY3VycmVudCBtb2Rl OjI0DQpmYjA6IHdvdzoweGMwMGI4MDAwIHNpemU6MzJrIGdyYW46MzJrLCBi dWY6MCBzaXplOjMyaw0KVkdBIHBhcmFtZXRlcnMgdXBvbiBwb3dlci11cA0K NTAgMTggMTAgMDAgMDAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUg ODEgDQpiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwNyA4MCA5YyA4ZSA4ZiAy OCAxZiA5NiANCmI5IGEzIGZmIDAwIDAxIDAyIDAzIDA0IDA1IDE0IDA3IDM4 IDM5IDNhIDNiIDNjIA0KM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAgMDAg MDAgMDAgMTAgMGUgMDAgZmYgDQpWR0EgcGFyYW1ldGVycyBpbiBCSU9TIGZv ciBtb2RlIDI0DQo1MCAxOCAxMCAwMCAxMCAwMCAwMyAwMCAwMiA2NyA1ZiA0 ZiA1MCA4MiA1NSA4MSANCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDAwIDAw IDljIDhlIDhmIDI4IDFmIDk2IA0KYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQg MDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgDQozZCAzZSAzZiAwYyAwMGUgMDAg ZmYgDQpFR0EvVkdBIHBhcmFtZXRlcnMgdG8gYmUgdXNlZCBmb3IgbW9kZSAy NA0KNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIg NTUgODEgDQpiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4 ZiAyOCAxZiA5NiANCmI5IGEzIGZmIDAwIDAxIDAyIDAzIDA0IDA1IDE0IDA3 IDM4IDM5IDNhIDNiIDNjIA0KM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAg MDAgMDAgMDAgMTAgMGUgMDAgZmYgDQp2dDA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQ0KaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2Vz DQphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4ODAgc3BlY2lmaWVkLiBO ZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9i ZS4NCmFkdjE6IEludmFsaWQgYmFzZXBvcnQgb2YgMHgwIHNwZWNpZmllZC4g TmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAweDEwMC4gIEZhaWxpbmcgcHJv YmUuDQphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4NDAgc3BlY2lmaWVk LiBOZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBw cm9iZS4NCmFkdjE6IEludmFsaWQgYmFzZXBvcnQgb2YgMHg3MCBzcGVjaSB2 YWxpZCBiYXNlcG9ydCBpcyAweDEwMC4gIEZhaWxpbmcgcHJvYmUuDQp1bmtu b3duOiA8UE5QMDMwMz4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkN CnVua25vd246IDxQTlAwMzAzPiBhdCBwb3J0IDB4NjAgb24gaXNhMA0KYWR2 MTogSW52YWxpZCBiYXNlcG9ydCBvZiAweGYwIHNwZWNpZmllZC4gTmVhcmVz dCB2YWxpZCBiYXNlcG9ydCBpcyAweDEwMC4gIEZhaWxpbmcgcHJvYmUuDQph ZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4NjEgc3BlY2lmaWVkLiBOZWFy ZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9iZS4N CnVua25vd246IDxQTlAwODAwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAw eDYxIG9uIGlzYTANCnVua25vd246IDxQTlAwYzAyPiBjYW4ndCBhc3NpZ24g cmVzb3VyY2VzIChtZW1vcnkpDQp1bmtub3duOiA8UE5QMGMwMj4gYXQgaW9t ZW0gMHhkYzAwMC0weGRmZmZmIG9uIGlzYTANCmFkdjE6IEludmFsaWQgYmFz ZXBvcnQgb2YgMHhjZjggc3BlY2lmaWVkLiBOZWFyZXN0IHZhbGlkIGJhc2Vw b3J0IGlzIDB4MzMwLiAgRmFpbGluZyBwcm9iZS4NCnVua25vd246IDxQTlAw YzAyPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzIChwb3J0KQ0KdW5rbm93bjog PFBOUDBjMDI+IGF0IHBvcnQgMHg0ZDAtMHg0ZDEgb24gaXNhMA0KdW5rbm93 bjogPFBOUDBjMDI+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMgKG1lbW9yeSkN CnVua25vd246IDxQTlAwYzAyPiBhdCBpb21lbSAweGU0MDAwLTB4ZTdmZmYg b24gaXNhMA0KdW5rbm93bjogPFBOUDBmMTM+IGNhbid0IGFzc2lnbiByZXNv dXJjZXMgKGlycSkNCnVua25vd246IDxQTlAwZjEzPiBhdCBpcnEgMTIgb24g aXNhMA0KdW5rbm93bjogPFBOUDA1MDE+IGNhbid0IGFzc2lnbiByZXNvdXJj ZXMgKHBvcnQpDQp1bmtub3duOiA8UE5QMDUwMT4gYXQgcG9ydCAweDNmOC0w eDNmZiBvbiBpc2EwDQp1bmtub3duOiA8UE5QMDUwMT4gY2FuJ3QgYXNzaWdu IHJlc291cmNlcyAocG9ydCkNCnVua25vd246IDxQTlAwNTAxPiBhdCBwb3J0 IDB4MmY4LTB4MmZmIG9uIGlzIGFzc2lnbiByZXNvdXJjZXMgKHBvcnQpDQp1 bmtub3duOiA8UE5QMDQwMD4gYXQgcG9ydCAweDM3OC0weDM3ZiBvbiBpc2Ew DQp1bmtub3duOiA8UE5QMDcwMD4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAo cG9ydCkNCnVua25vd246IDxQTlAwNzAwPiBhdCBwb3J0IDB4M2YwLTB4M2Y1 IG9uIGlzYTANCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLg0KcHJv Y2ZzIHJlZ2lzdGVyZWQNClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAx MDc0MDMyNjY0IEh6IHF1YWxpdHkgODAwDQpUaW1lY291bnRlcnMgdGljayBl dmVyeSAxMC4wMDAgbXNlYw0KbG8wOiBicGYgYXR0YWNoZWQNCmF0YTAtbWFz dGVyOiBwaW89MHgwYyB3ZG1hPTB4MjIgdWRtYT0weDQyIGNhYmxlPTQwcGlu DQphZDA6IEZBSUxVUkUgLSBTRVRGRUFUVVJFUyBzdGF0dXM9NTE8UkVBRFks RFNDLEVSUk9SPiBlcnJvcj00PEFCT1JURUQ+DQphZDA6IHNldHRpbmcgVURN QTMzIG9uIEludGVsIFBJSVg0IGNoaXANCkdFT006IGNyZWF0ZSBkaXNrIGFk MCBkcD0weGMxZTk4ODcwDQphZDA6IDxWTXdhcmUgVmlydHVhbCBJREUgSGFy ZCBEcml2ZS8wMDAwMDAwMT4gQVRBLTIgZGlzayBhdCBhdGEwLW1hc3Rlcg0K YWQwOiA0MDk2TUIgKDgzODg2MDggc2VjdG9ycyksIDgzMjIgQywgMTYgSCwg NjMgUywgNTEyIEINCmFkMDogMTYgc2Vjcy9pbnQsIDEgZGVwdGggcXVldWUs IFVETUEzMw0KWzBdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTow LzAvMCBzOjAgbDowDQpbMV0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShD SFMpOjAvMC8wIHM6MCBsOjANClsyXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAv MCBlKENIUyk6MC8wLzAgczowIGw6MA0KWzNdIGY6ODAgdHlwOjE2NSBzKENI Uyk6MC8wLzEgZShDSFMpOjEwMjMvMjU0LzYzIHM6MCBsOjUwMDAwDQphcjog RnJlZUJTRCBjaGVjazEgZmFpbGVkDQphdGExLW1hc3RlcjogcGlvPTB4MGMg d2RtYT0weDIyIHVkbWE9MHg0MiBjYWJsZT00MHBpbg0KYWNkMDogc2V0dGlu ZyBQSU80IG9uIEludGVsIFBJSVg0IGNoaXANCmFjZDA6IDxWTXdhcmUgVmly dHVhbCBJREUgQ0RST00gRHJpdmUvMDAwMDAwMDE+IENEUk9NIGRyaXZlIGF0 IGF0YTEgYXMgbWFzdGVyDQphY2QwOiByZWFkIDE3MUtCL3MgKDE3MUtCL3Mp LCAzMktCIGJ1ZmZlciwgUElPNA0KYWNkMDogUmVhZHM6IENEREEgc3RyZWFt DQphY2QwOiBXcml0ZXM6DQphY2QwOiBBdWRpbzogcGxheSwgMiB2b2x1bWUg bGV2ZWxzDQphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxv Y2tlZA0KYWNkMDogTWVkaXVtOiBDRC1ST00gMTIwbW0gZGF0YSBkaXNjDQpp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJUlEgMSkgdG8gY2x1c3RlciAw DQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAzIChJUlEgMykgdG8gY2x1c3Rl ciAwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJUlEgNCkgdG8gY2x1 c3RlciAwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA2IChJUlEgNikgdG8g Y2x1c3RlciAwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA3IChJUlEgNykg dG8gY2x1c3RlciAwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA4IChJUlEg OCkgdG8gY2x1c3RlciAwDQppb2Fw --0-667128169-1068695315=:64941-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 20:51:06 2003 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 0BF0716A4CE for ; Wed, 12 Nov 2003 20:51:06 -0800 (PST) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5F743FF7 for ; Wed, 12 Nov 2003 20:50:54 -0800 (PST) (envelope-from wa1ter@myrealbox.com) Received: from myrealbox.com wa1ter@smtp-send.myrealbox.com [66.126.109.253] $ on Novell NetWare via secured & encrypted transport (TLS); Wed, 12 Nov 2003 21:50:58 -0700 Message-ID: <3FB37EFD.2040604@myrealbox.com> Date: Thu, 13 Nov 2003 04:54:21 -0800 From: walt Organization: none User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6a) Gecko/20031108 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: GNOME users should recompile gnomevfs2 after today update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 04:51:06 -0000 I found that the new statfs changes cause nautilus to crash on startup. The fix is to recompile/reinstall devel/gnomevfs2. From owner-freebsd-current@FreeBSD.ORG Wed Nov 12 21:05:52 2003 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 47ECC16A4CF for ; Wed, 12 Nov 2003 21:05:52 -0800 (PST) Received: from minime.wossname.net (12-222-100-53.client.insightBB.com [12.222.100.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A250E43F93 for ; Wed, 12 Nov 2003 21:05:48 -0800 (PST) (envelope-from bhlewis@wossname.net) Received: from akira.wossname.net (akira.wossname.net [192.168.1.2]) by minime.wossname.net (Postfix) with ESMTP id D8BEA266; Thu, 13 Nov 2003 00:04:14 -0500 (EST) Received: from wossname.net (unknown [127.0.0.1]) by akira.wossname.net (Postfix) with ESMTP id 879AF54BF; Thu, 13 Nov 2003 00:05:45 -0500 (EST) Message-ID: <3FB31128.1030709@wossname.net> Date: Thu, 13 Nov 2003 00:05:44 -0500 From: Benjamin Lewis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031101 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: multipart/mixed; boundary="------------070606060000040601020204" cc: bhlewis@purdue.edu Subject: Recent -current hangs on Tyan S2460 before finishing boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 05:05:52 -0000 This is a multi-part message in MIME format. --------------070606060000040601020204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I'm having trouble getting recent (post- "device apic", pre- turnstile) kernels to boot on my Tyan S2460 (Tiger MP) system with dual AMD Athlons. What happens is that the machine seems to get "stuck" soon after the "Waiting for SCSI devices to settle" message is printed -- it appears to be willing to wait forever rather than the SCSI_DELAY time. Disabling ACPI in the BIOS has no apparent effect on the hang. Using SCHED_4BSD or SCHED_ULE likewise makes no difference. I've been following the current@ list hoping to see someone else report a problem similar to mine but haven't seen anything yet. I do have a serial console attached to the machine and DDB enabled so I'm able to provide some information and get more if needed. I'm including a copy of the boot messages from my last attempt to boot "FreeBSD 5.1-CURRENT #2: Tue Nov 11 17:35:40 EST 2003" which was cvsup'ed shortly prior to the build date. Included in the messages are the output of "ps" and "trace" once I broke into ddb. I'm also including output from "acpidump -t" and "mptable -verbose" since I've seen that information requested in the past. Some details about the system that may be pertinent: 1. It has two 1Ghz Athlon "Thunderbird" (Not MP) processors. That hasn't been a problem so far. 2. The BIOS is version 1.04 (latest is 1.05). The last time I tried updating to 1.05 (some time ago) I saw lots of error messagess complaining about undefined ACPI stuff so I reverted. 3. There is a Tekram 390F (I think that's the model -- it uses the sym driver) and an Adaptec 3944 SCSI controller. A single internal SCSI drive is connected to the Tekram and 10 external drives are connected to the two ports on the 3944. The external drives are configured as a Vinum Raid10 array. There's also a single IDE drive connected to one of the built-in IDE controllers. Please let me know if there is anything more you want to know. Thanks, -Ben --------------070606060000040601020204 Content-Type: text/plain; name="boot.hung" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="boot.hung" Type '?' for a list of commands, 'help' for more detailed help. OK boot -sv -\|/-\|SMAP type=01 base=0000000000000000 len=000000000009f400 SMAP type=02 base=000000000009f400 len=0000000000000c00 SMAP type=02 base=00000000000e4800 len=000000000001b800 SMAP type=01 base=0000000000100000 len=000000000fef0000 SMAP type=03 base=000000000fff0000 len=000000000000fc00 SMAP type=04 base=000000000ffffc00 len=0000000000000400 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff80000 len=0000000000080000 Copyright (c) 1992-2003 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.1-CURRENT #2: Tue Nov 11 17:35:40 EST 2003 bhlewis@akira.wossname.net:/export/obj/usr/src-all/current/src/sys/AKIRA.ULE Preloaded elf kernel "/boot/kernel/kernel" at 0xc089d000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc089d250. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc089d2fc. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc089d3a8. Preloaded elf module "/boot/kernel/usb.ko" at 0xc089d458. Preloaded elf module "/boot/kernel/ums.ko" at 0xc089d500. Preloaded elf module "/boot/kernel/agp.ko" at 0xc089d5a8. Preloaded elf module "/boot/kernel/random.ko" at 0xc089d650. Calibrating clock(s) ... i8254 clock: 1192972 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1000041373 Hz CPU: AMD Athlon(tm) Processor (1000.04-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183fbff AMD Features=0xc0440000 Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 268369920 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000000fb3dfff, 250695680 bytes (61205 pages) avail memory = 251088896 (239 MB) ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00f7480 bios32: Entry = 0xfd6c0 (c00fd6c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6c0+0x120 pnpbios: Found PnP BIOS data at 0xc00f74d0 pnpbios: Entry = f0000:9ece Rev = 1.0 Other BIOS signatures found: MADT: Found IO APIC ID 2, Vector 0 at 0xfec00000 ioapic0: intpin 0 -> ExtINT (edge, activehi) ioapic0: intpin 1 -> irq 1 (edge, activehi) ioapic0: intpin 2 -> irq 2 (edge, activehi) ioapic0: intpin 3 -> irq 3 (edge, activehi) ioapic0: intpin 4 -> irq 4 (edge, activehi) ioapic0: intpin 5 -> irq 5 (edge, activehi) ioapic0: intpin 6 -> irq 6 (edge, activehi) ioapic0: intpin 7 -> irq 7 (edge, activehi) ioapic0: intpin 8 -> irq 8 (edge, activehi) ioapic0: intpin 9 -> irq 9 (edge, activehi) ioapic0: intpin 10 -> irq 10 (edge, activehi) ioapic0: intpin 11 -> irq 11 (edge, activehi) ioapic0: intpin 12 -> irq 12 (edge, activehi) ioapic0: intpin 13 -> irq 13 (edge, activehi) ioapic0: intpin 14 -> irq 14 (edge, activehi) ioapic0: intpin 15 -> irq 15 (edge, activehi) ioapic0: intpin 16 -> irq 16 (level, activelo) ioapic0: intpin 17 -> irq 17 (level, activelo) ioapic0: intpin 18 -> irq 18 (level, activelo) ioapic0: intpin 19 -> irq 19 (level, activelo) ioapic0: intpin 20 -> irq 20 (level, activelo) ioapic0: intpin 21 -> irq 21 (level, activelo) ioapic0: intpin 22 -> irq 22 (level, activelo) ioapic0: intpin 23 -> irq 23 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: active-hi lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-hi ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x01000000 VER: 0x00040010 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff mem: Pentium Pro MTRR support enabled null: random: acpi0: on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x800000b4 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=700c1022) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0x8080-0x80ff,0x8000-0x807f,0xcf8-0xcff iomem 0xdc000-0xdffff on acpi0 ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base ec000000, size 26, enabled map[14]: type 3, range 32, base e8106000, size 12, enabled map[18]: type 4, range 32, base 00001c90, size 2, port disabled found-> vendor=0x1022, dev=0x700c, revid=0x11 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x700d, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x63 (2970 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7410, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[18]: type 4, range 32, base 00000000, size 3, enabled map[1c]: type 4, range 32, base 00000000, size 2, enabled map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x1022, dev=0x7411, revid=0x01 bus=0, slot=7, func=1 class=01-01-8e, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 found-> vendor=0x1022, dev=0x7413, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 000dc000, size 12, enabled pcib0: matched entry for 0.7.INTD (source ) pcib0: device is hardwired to IRQ 19 found-> vendor=0x1022, dev=0x7414, revid=0x07 bus=0, slot=7, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=19 map[10]: type 4, range 32, base 00001000, size 8, enabled map[14]: type 1, range 32, base e8105000, size 8, enabled map[18]: type 1, range 32, base e8101000, size 12, enabled pcib0: matched entry for 0.9.INTA (source ) pcib0: device is hardwired to IRQ 17 found-> vendor=0x1000, dev=0x000f, revid=0x03 bus=0, slot=9, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x8c (4200 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=a, irq=17 map[10]: type 4, range 32, base 00001400, size 8, enabled map[14]: type 1, range 32, base e8102000, size 12, enabled pcib0: matched entry for 0.11.INTA (source ) pcib0: device is hardwired to IRQ 19 found-> vendor=0x9004, dev=0x7895, revid=0x04 bus=0, slot=11, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=19 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001800, size 8, enabled map[14]: type 1, range 32, base e8103000, size 12, enabled pcib0: matched entry for 0.11.INTB (source ) pcib0: device is hardwired to IRQ 16 found-> vendor=0x9004, dev=0x7895, revid=0x04 bus=0, slot=11, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=b, irq=16 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c00, size 6, enabled pcib0: matched entry for 0.12.INTA (source ) pcib0: device is hardwired to IRQ 16 found-> vendor=0x1274, dev=0x5880, revid=0x02 bus=0, slot=12, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=16 powerspec 1 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base e8104000, size 12, enabled map[14]: type 4, range 32, base 00001c40, size 6, enabled map[18]: type 1, range 32, base e8000000, size 20, enabled pcib0: matched entry for 0.13.INTA (source ) pcib0: device is hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=13, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: port 0x1c90-0x1c93 mem 0xe8106000-0xe8106fff,0xec000000-0xefffffff at device 0.0 on pci0 agp0: allocating GATT for aperture of size 64M agp0: gatt -> ag_pdir 0x252000 agp0: allocating GATT for 16384 AGP page entries pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe9000000-0xe9ffffff pcib1: prefetched decode 0xf0000000-0xf7ffffff ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base e9000000, size 24, enabled map[14]: type 3, range 32, base f0000000, size 27, enabled pcib1: matched entry for 1.5.INTA (source ) pcib1: device is hardwired to IRQ 18 found-> vendor=0x10de, dev=0x0110, revid=0xb2 bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7 at device 7.1 on pci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] amdpm0: port 0x80e0-0x80ff at device 7.3 on pci0 smbus0: on amdpm0 smb0: on smbus0 ohci0: mem 0xdc000-0xdcfff irq 19 at device 7.4 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ums0: Logitech USB-PS/2 Mouse M-BA47, rev 1.00/1.20, addr 2, iclass 3/1 ums0: 4 buttons and Z dir. sym0: <875> port 0x1000-0x10ff mem 0xe8101000-0xe8101fff,0xe8105000-0xe81050ff irq 17 at device 9.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. ahc0: port 0x1400-0x14ff mem 0xe8102000-0xe8102fff irq 19 at device 11.0 on pci0 ahc0: Defaulting to MEMIO off ahc0: Reading SEEPROM...done. ahc0: internal 50 cable not present, internal 68 cable not present ahc0: external cable is present ahc0: BIOS eeprom is present ahc0: High byte termination Enabled ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 412 instructions downloaded ahc0: Features 0x16235, Bugs 0x15, Flags 0x20405440 aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x1800-0x18ff mem 0xe8103000-0xe8103fff irq 16 at device 11.1 on pci0 ahc1: Defaulting to MEMIO off ahc1: Reading SEEPROM...done. ahc1: internal 50 cable not present, internal 68 cable not present ahc1: external cable is present ahc1: BIOS eeprom is present ahc1: High byte termination Enabled ahc1: Low byte termination Enabled ahc1: Downloading Sequencer Program... 412 instructions downloaded ahc1: Features 0x16235, Bugs 0x15, Flags 0x20485440 aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs pcm0: port 0x1c00-0x1c3f irq 16 at device 12.0 on pci0 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features AMAP pcm0: sndbuf_setmap 274000, 1000; 0xc2d40000 -> 274000 pcm0: sndbuf_setmap 296000, 1000; 0xc2d42000 -> 296000 fxp0: port 0x1c40-0x1c7f mem 0xe8000000-0xe80fffff,0xe8104000-0xe8104fff irq 17 at device 13.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:d0:b7:83:e5:1e fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached psmcpnp0 irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x1d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data ffffffff 00 03 psm: status 00 00 64 psm: status 00 02 64 psm: data ffffffff 02 64 psm0: failed to get data. psm: status 00 02 64 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:00, syncbits:00 sio0: irq maps: 0xc001 0xc011 0xc001 0xc001 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1: irq maps: 0xc001 0xc009 0xc001 0xc001 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP 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/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 npx0: [FAST] nstray irq13 px0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: